Weingeist

Ist zwar auch OT, aber passt hier trotzdem. Klar wurde er vor-vor-vorgestern erfunden. Aber nicht alles was alt ist, ist auch automatisch überholt. Wäre dem so, wäre er nicht so beliebt. Wenn etwas so bequem und beliebt bei den Anwendern ist - jung und alt -, sollte man mit und nicht dagegen arbeiten. Finde ich. Egal was die persönliche Einstellung dazu ist. Vor allem ist er X-Win-Versionen übergreifend identisch aufgebaut und tut folglich immer. Ich pflege die sogar aktiv mit Links, weil sie dann nicht auf dem Desktop speichern sondern auf die Ziele (erscheint in den Dialogen ja generell zuoberst) Das W10 Design finde ich zwar sehr hübsch anzusehen, für meine eigene Mühle wo ich unzählige verschiedene Tools brauche auch sehr viel übersichtlicher als der Desktop, aber bringt für - ich behaupte - 99% der Mitarbeiter keinerlei Mehrwert. Eher im Gegenteil, das Ding ist viel zu überladen, irgendwelche Live-Apps lenken nur vom Arbeiten ab. Die meisten Leute/Arbeitsplätze brauchen zum Arbeiten max. 10 Programme, meist eher gegen 5-6. Ob das nun via Desktop, Taskleiste oder Starmenü geschieht, ist eher zweitrangig. Hier wird nicht die relevante Zeit vergeudet. Den Aufwand der Startmenü-Pflege in W10 für die paar Programme zu betreiben ist meiner Meinung nach eher sinnbefreit. Dann lieber der Desktop und die Taskleiste ;)

@TO: Und ganz genau deshalb wäre es grundsätzlich auch fair das andere Szenario zu lösen. Den da lag das Problem. Sprich z.Bsp. das vorgeschlagene Logging umzusetzen. Wurde ja immerhin recht viel Zeit durch andere investiert. Finde ich persönlich zumindest enorm unbefriedigend wenn man ne halbe Ewigkeit ein Problem versucht zu lösen und nachher wird es einfach umschifft weil jemandem dann diese Zeit zu Schade ist. Just my 2ct und wie immer, mag jeder wieder anders sehen.

Also wenigstens die OS-Version die es betrifft sollte man schon im Anfangspost auf die Reihe kriegen. Ist ja obermühsam so Hilfestellung zu bieten. Allerdings ist es tatsächlich so, dass auch 2012R2 das nicht kann. Habe ich komplett falsch im Kopf gehabt aber grad vorher nachgeprüft. Also eine andere Variante nehmen. 3. Anbieter Backupprogramm, neues OS (2012R2 läuft Anfang nächstes Jahr aus) oder wenn es eine VM ist, Festplatte von einem anderen Speicherort einbinden, dann ist sie für Windows auch lokal.

Ganz Vergessen, den Standard-Tipp bei Unerklärlichen Problemen mit Hängers: Mal alle Energieeinstellungen auf Höchstleitung. Unter Umständen etwas suboptimal bei Notebooks, aber hilft halt auch oft weil irgendwelche Geräte irgendwo hängen. Gerade bei alter und eher günstiger Hardware ist das oft katastrophal umgesetzt und die Probleme werden mit neueren OS-Versionen immer akuter. Auch Standby oder Hibernate funkt da gerne mal rein. Sogar Log/Telemetrie-Aufzeichnungen hatte ich mal in diesem Zusammenhang.

Eine Funktionalität die nicht vorhanden ist, ist halt einfach nicht vorhanden. Incremental geht erst ab 2012/8 auf Shares. Das kann man drehen und wenden wie man möchte. Du könntest mehrere Backupziele und Task verwenden um mehrerere Versionsstände vorzuhalten. Oder auf ein Backupziel mit Dedupe sichern und Ordnernamen immer neu erstellen lassen oder eben ein Fremdanbieter Tool verwenden. Ein Dedupe-Ziel nehme ich auch heute noch gerne für Applikations-Sicherungen aus 0815 Programmen heraus. Ansonsten: Mir ist grad keine Software bekannt - auch keine ältere - die auf 2008 läuft, nicht jedoch auch auf neueren Systemen zum laufen zu bewegen ist. Also wozu sich da lange die Mühe machen wenn eine gewünschte Funktionalität fehlt, in neueren Versionen aber vorhanden ist? Just my 2cts. Nur direkte Hardware-Zugriffe oder hochspezifische einlinkungen in Basic-OS-Kram kann da einen Strich durch die Rechnung machen.

Soweit ich mich richtig erinnere ist in 2008 das alles noch etwas hemdsärmelig per Kommandozeile und eben in der Funktion recht bescheiden. Habe aber grad keine 2008er zur Hand. In 2012 kommt die Server-Sicherung-MMC wenn mann wbadmin eingibt.

Ich würde bei alter Hardware im Grundsatz immer einen LTSC-Build nehmen. Dann ist sehr oft Ruhe im Karton. Auch wenn Updates kommen. So meine Erfahrung. Treiber dann nach Möglichkeit direkt vom Hersteller der Module und nicht vom Hersteller des Notebooks wie bereits empfohlen wurde. Versuchen würde ich es mit 1809. Wenn das nicht geht halt 1607. Beide dürften vermutlich noch genügend lange im Support-Bereich liegen bis Du neue Notebooks bekommst =)

Nun, das Tool an sich ist nicht sooooo enorm flexibel. Macht also keine komplexen Dinge wie inkrementelle Backupas (siehe auch kommandozeile>wbadmin start backup /?) ;) Dazu kannst die Server-Sicherung verwenden. Oder ein Backuptool wie Veeam.

Um es direkt zu sagen: Schlüssel in einem zweiten Mail zu schicken ist schwachsinnig. Das ist reine Pseudo-Sicherheit. Wer die erste Mail abfangen kann, fängt auch die zweite ab. Entweder den Schlüssel auf einem anderen Weg wie z.Bsp. Handy oder Post zukommen lassen oder man lässt es besser bleiben und schafft andere Möglichkeiten.

Beschäftige mich schon seit einiger Zeit mit der Windows-Firewall. Die Einstellungen der Firewall sind alle in der Registry abgelegt. Man kann also auch darüber Modifikationen tätigen. GPO oder lokal. Damit Outbound-Block zielführend ist, sind folgende Befehle hilfreich: Englisches OS: auditpol.exe /set /category:"Object Access" /subcategory:"Filtering Platform packet drop" /success:enable /failure:enable Deutsches OS: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:enable /failure:enable Alle Sprachen: auditpol.exe /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable Damit erscheinen die Drops und Success-Versuche im Sicherheits-Event-Log und man kann entsprechende Regeln erstellen. Mit Befehlen Tasklist.exe /svc sowie netstat -a -b und -n erhält man nütztliche Infos zu den betroffen Prozessen. Die Lernkurve ist übrigens nur auf den ersten Moment steil. Sobald man tiefer geht, wird es lästig. ;) - Moderne Apps sind enorm mühsam im Handling - Filterungen auf Dienste welche die svchost zugrunde haben, funktionieren in neueren OS nicht mehr korrekt weil die SID maskiert werden - Kopien/alias/hardlinks der svshost.exe ermöglich eine effektive Filterung auf Dienstebene. Ist etwas aufwändiger, dafür erkennt man auch welche Programme effektiv wann wie Zugriff via svchost tätigen (ich blockiere dann standardmässig die originale svchost.exe und erlaube nur traffic auf die aliase) - Apps Entscheidet man sich für eine Aufdröselung der Dienste in verschiedene svchost.exe Hardlinks, sollte man folgende Dienste auf eine gemeinsame gleiche svchost.exe datei zeigen lassen, sonst gibt es ärger (diese sind auch sonst gruppiert und haben einen gemeinsamen prozess, die anderen wurden weitesgehend von MS bereits aufgedröselt) - DcomLaunch, brokerinfrustructure, SystemEventsBroker, Power (warum auch immer Power hier reinkommt) - RpcSs, RpcEptMapper - mpssvc, BFE - UserDataSvc, OneSyncSvc, PimIndexMaintenanceSvc, UniStoreSvc Die Systeminternen Rules müssen dann ebenfalls angepasst werden, sonst laufen sie ins leere bzw. muss sie selber erstellen. Wo liegen alle Rules?: HKLM\System\CurrentControlSet\services\sharedaccess\Parameters\ Unterordner Static von Restricted Services sind die System-regeln die weder mit Powershell noch mit GPO's verändert werden können noch in der GUI erscheinen und somit auch nicht mit GPO's geändert werden können. Unterordner configurable: sind die Regeln die mit NetSH oder Powershell geändert werden können aber nicht in der GUI erscheinen. Die Regeln für Apps sind je nach W10 Build anders aufgebaut und abgelegt. Ziemlich mühsame Sache. Auch deren Pflege ist Horror weil sie auf Benutzerebene angelegt werden. Eine enorme Anzahl ausnahmen die jegliche Kommunikation mit diesen Apps erlaubt und nicht auf Anhieb ersichtlich sind. --> Deren Erstellung kann man theoretisch verhindern wenn man den Zugriff auf die Reg-Hives beschränkt, nur scheitert dann die Installation von Apps auf Benutzerebene beim erstmaligen Anmelden. Sprich kein Startmenü etc. --> Ich finde das ganz praktisch auf Servern und Industriemaschinen. Der Desktop an sich funktioniert trotzdem. Quasi minimale Gui Hier noch ein alter Thread von mir: - Audit der Filter-Engine hilft bei Block-Out, die Standardregeln von MS sind leider nicht vollständig für einen normalen Domänenbetrieb.

Wurde früher wohl so gemacht. Mir wars immer zu mühsam. Ja klar geht auch das redundant, aber wozu? Läuft genau wie der zweite DC auch in die unnötige Komplexität rein bei KMU. Man kanns beliebig weiterspinnen, wenn man bei Redundanz anfängt, ist man bei Lizenzkosten die selten Sinn machen. DHCP + DC auf zwei verschiedenen Servern frisst bereits zwei Standard-Lizenzen für je zwei VM's + laufende Kosten mit SA. Ohne das die Umgebung weiterlaufen würde im Fehlerfall, weil z.Bsp. der Fileserver und Applikationsserver fehlt. Intervention ist bei einem Ausfall sowieso notwendig und die max. 5 Minuten für die Wiederherstellung einer DC-VM (sofern überhaupt notwendig) fällt nun wirklich nicht ins Gewicht. Dazu der Zusatz-Aufwand für Einrichtung, Betrieb, Unterhalt, Vorsichtsmassnahmen etc. Also wozu das Ganze? Ich setze die Kohle lieber in eine Überdimensionierte Stromversorgung (Doppel Online-USV mit viele Akkus, Netzumschalter für Single Netzteile usw.)+zusätzliches lokales Backupziel, dann habe ich 90% der Problemverursacher und der Behebung in Kleinumgebungen schonmal erschlagen. Die restlichen kommen dann von fehlerhaften Applikationen auf die ich keinen Einfluss habe. Aber eben, viele Wege führen nach Rom.

Na klar... Diese Debatte gibts auf Seite 1. Ein richtig oder falsch gibt es in diesem Fall nicht, es gibt Gründe dafür und dagegen. Entscheiden muss das am Ende jeder für sich selbst. Den von MS gewünschte Zustand bekommt man in 30 Sekunden zurück sollte man wirklich Support brauchen/sich das antun wollen und MS ist der Meinung IPv6 bräuchte es für den support.

Bei Type 0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table. Bin ich mir nicht zu 100% sicher, dass es auch immer korrekt gesetzt wird bzw. welche Voraussetzungen gegeben sein müssen. Auch schon Probleme gehabt. Besser gleich selbst umschreiben. ;)

Haha kann man so sehen. *grinz* Ich sehe die Beweggründe aus Sicht des Aufwands und den grundsätzlich möglichen Komplikationen und den daraus entstehenden Problemen. Wodurch auch immer sie Verursacht werden. Und das steht nunmal im kleinen nicht wirklich im Verhältnis zu den Vorteilen von mehreren DC's. Klar weder prüfen ob die Sync noch läuft, noch reaktivierung von DFS-Replikation von Sysvol, noch löschen eines DC's der down ist, noch neuerstellen eines DC ist viel Aufwand. All das ist normalerweise kein Akt. Aber in der Summe übers Jahr gesehen eben deutlich mehr Arbeit für sehr wenig Mehrwert. Aber das ist nur meine persönliche Meinung die nicht jeder teilen muss. Der DHCP war nur so ein Beispiel, ich persönlich lasse den nicht mehr auf DC bei Neuinstallation oder Umgebungen die ich aktualisiere laufen. Aber ist oder war halt oft so üblich. Meist ist ja Ärger nach einem Stromausfall, Host BlueScreen, Festplattenausfall, RAID-Probleme oder was auch immer und dann sind auch die Leases weg. Die physische Maschine dürfte ja die gleiche sein. Also ist kaum nur DC oder nur DHCP betroffen. Geteilte DCHP-Bereiche schaffen wiederum mehr Verwaltungsaufwand und die Umgebung ist immer noch down. Also wozu sich das alles antun? Von beidem eine Maschine, im Fehlerfall Wiederherstellen und fertig. Mit lokalen Sicherungen dauert das ein paar Minuten.

Wozu ein AD-Recovery? Man stellt einfach den ganzen Server wieder her. AD-Stand ist quasi egal. Backupprogramm in AD integriert: das meine ich ja, schauen dass man lokale Konten hat für eine Wiederherstellung. Ein DC = Konflikte von vornherein ausgeschlossen. Ich hatte in meiner Laufzeit deutlich mehr Probleme mit mehreren DC als mit einem. Sei es wegen Sync-Problemen, Wiederherstellung, Versionsstände usw. Bedarf einfach insgesamt mehr Pflege bei verhältnissmässig wenig Gewinn in Kleinumgebungen. Mit Cloud sieht das teilweise anders aus. Korrekt. Soweit ich das verstanden habe, sprechen wir hier von On-Premise. Ich und viele KMU im Produktionssektor mögen die Cloud auch nicht. Aber das ist ein anderes Thema. Und wie bereits gesagt, DC mit einem Footprint von 20-25Gb ist in ein paar Minuten wiederhergestellt und wieder Up. Insbesondere wenn man lokal ein Backup vorhält. Egal ob er Imagebasiert, Replikat oder AD-Konform gesichert/wiederhergestellt wurde, man hat nie ein Risiko von Versions-Konflikten wie mit mehreren DC's. Viele nehmen zum Beispiel DHCP mit auf den ersten DC. Was hilft hier also ein zweiter DC wenn DHCP down ist? Nix, es bringt nur Probleme. Ist der DC noch ein Filer (was ich gerne vermeide) wird es noch lästiger. Aber eben, jeder wie er mag. Ich mag es möglichst einfach. Solange eben keine normalen Anwendungen im AD herumschreiben. Dann sieht es logischerweise anders aus. Bei einem DC ist es fast egal WIE wiederhergestellt/gesichert wird, man muss sich schon von vornherein nicht um die korrekten AD-Stände kümmern. Den Client interessiert das nämlich nicht besonders.

Und auch in Kleinumgebungen ist es sehr viel angenehmer für die Wartung wenn man die Rollen separiert. Lohnt eigentlich immer. Früher mit rein physischen Maschinen sah das etwas anderes aus. Ein paar hundert Euro Lizenzkosten sind viel zu schnell von Stunden aufgefressen wenn was spinnt. Printserver ist so ziemlich der anfälligste Server überhaupt. Ziemlich in jeder Hinsicht. Sicherheit und Ärger. Den würde ich einfach immer separat halten. In Kleinumgebungen wo gerne auch "billig-geräte" vorkommen sowieso, da sind die Treiber ja oft Kernschrott. Gerade mit VM's hat man auch den Vorteil einfach auf Knopfdruck nen Rollback auf einen alten Treiberstand zu machen wenn es Probleme gibt ohne das es Einfluss auf etwas anderes hat. Erster DC: Immer separat ohne weitere Rollen. Sicherheitstechnisch besser und schnell wiederhergestellt. Zweiter DC in Kleinumgebung: Imho ziemlich sinnlos solange man keine Applikation hat, die permanent in AD schreibt. Der Mini-Footrint von 20-25GB ist in ein paar Minuten wiederhergestellt wenn man lokal auf einer separaten Platte eine Kopie/Backup vorhält. Viele Probleme mit AD sind mit einem Server schon von vornherein ausgeschlossen. Replikation, die Chef-Frage, allfälliges Image-Backup usw. Echten Mehrgewinn bringt es selten. Einfach schauen das man ein lokales Konto für den Zugang zum Host hat, welches nicht AD-abhängig ist damit z.Bsp. eine Kopie des Server zurückgespielt werden kann. Und seien wir ehrlich, ist ein physischer Server down, arbeitet man eh nen Moment nicht mehr. Ob dann ein zweiter DC da ist, spielt dann wirklich keine Rolle mehr. Fileserver würde ich auch immer separat halten. Je nach Anzahl und Grösse der Files halte ich sogar deren zwei vor. Bereitgestellt per DFS. Das ist normal der einzige Server der in Kleinumgebungen möglicherweise wirklich eine Ewigkeit braucht bis er wiederhergestellt ist. Insbesondere wenn es über LAN muss. Dann kann man einfach das DFS-Ziel switchen und hat genug Zeit den 1. zu flicken. (Abhängigkeiten PDC und DFS beachten). Also wozu den Server mit anderen Rollen "verunstalten" und Risiko eines Rollbacks auf sich nehmen weil man eine andere Aufgabe etwas falsch installiert/konfiguriert etc. Lizenzserver, WSUS, sonstiger "unwichtiger" Kram kann man gerne konsolidieren. Würde aber schauen, dass der Krempel jeweils auf eigene Platten schreibt. Ein Vollaufen des WSUS auf C bringt z.Bsp. dann nicht gleich alle anderen Rollen bzw. den Server selbst ins Elend. Wenn man sich die Lizenzen gönt, hat mans je nach dem auch hier einfacher wenn Upgrades anstehen. ;) Aber eben, jeder hat so seine Vorgehensweisen und es führen viele Wege nach Rom. Ich separiere mittlerweile immer soviel wie es geht. Egal wie gross die Umgebung ist. Das hat sich bewährt. Und bezüglich GUI habe ich die gleiche Meinung. Tu Dir das nicht an ohne. Auch kannst viele Systeme z.Bsp. für Updates viel einfacher während der Arbeitszeit machen. Bei konsolidierten Rollen ist das viel anspruchsvoller und eben auch die Chance grösser das es schief geht. Ahja, KMU's sind fast immer Inhaber-gesteuert. Die sind selten sehr geduldig. Insbesondere nicht bei der IT. Damit werden ja nicht die Brötchen verdient wie mit einer Maschine und viel dran ist optisch auch nicht. Also sollte man besser zuschauen, dass sie möglichst wenig Ärger macht. Die Kostenrechnung Stunden zu Material/Lizenkosten beherrschen die normal auch. ;)

Wenn man keine spezielle Technolgie nutzt sondern lediglich auf bestimmte bestehende Desktop-VM's direkt per RDP zugreift meines Wissens nicht. Müsste in Enterprise + SA enthalten sein (bis 4 VM's oder so, ähnlich wie bei VDA). Problematisch wird es laut meinem Wissensstand - auch wenn das Gespräch auch wieder ein Moment her ist - erst, wenn spezifische Funktionen von MS für Automatisierung, Loadbalancing, Zugriffsart, Veröffentlichung usw. genutzt werden. Also das was auch bei ServerOS oft genutzt wird. So war zumindest damals die Ansage. Diese Funktionalität wird bei anderen Anbietern wie VmWare meist ebenfalls separat bezahlt, daher möchte wohl MS auch nen Schnippsel davon haben wenn ihr Zeugs genutzt wird.

Naja, nicht ganz. Es gibt ja noch die Hauptuser-Klausel. Nur korreliert das mit dem Konsolidierungskonzept das man mit VDI verfolgt weil es den Hauptuser nur in Verbindung mit "persönlich" zugeteilter Hardware gibt. Eigentlich geht folgendes. Immer aus Arbeiter, nicht Admin-Sicht - User hat Windows PC und greift auf Server OS zum arbeiten zu: mindestens RDS-CAL - User hat Windows PC und greift auf Desktop OS auf Server zu (Typisch VDI): Windows Client der zugreift muss Enterprise + SA haben, RDS CAL nicht notwendig - User hat ThinClient oder sonstiges und greift auf Server OS zu: RDS CAL und manche behaupten auch VDA (wurde mir so nicht bestätigt) - User hat ThinClient oder sonstiges und greift auf Desktop OS zu: VDA - User hat ThinClient oder sonstige und greift auf Desktop OS zu und von da baut er eine TS-Session zu einem Server OS auf: VDA + RDS - User greift irgendwie auf seinen persönliche Hardware zu: Keine zusätzlichen Kosten (Hauptuser-Recht), egal wie der Zugriff erfolgt - Hardware ist eine reproduzierbare, definierte Kette mit mehreren, abwechselden, nicht gleichzeitigen Benutzern (z.Bsp. Workstation im Rack, Extender für Bildschirm etc., kein Verteiler) : Keine RDS CAL notwendig, keine SA notwendig, sobald der Kram flexibel auf Endpunkte verteilt wird, wird eine RDS CAL notwendig (sa bin ich nicht sicher, habe den zustand bis dato nirgends) Für Office als Kauflizenz gilt: Jedes End-Gerät von welchem aus der Zugriff erfolgt, muss lizenziert sein. Es gibt wiederum ein Hauptuser-Recht, das zählt aber wie bei Windows nur bei persönlicher Hardware! Sprich es ist mit VDI fast unmöglich das sinnvoll mit Kauflizenzen zu lizenzieren wenn die User X Endgeräte haben. Und auch das nur mit den VL-Lizenzen. Es sei denn, sie haben ihre persönliche Hardware auf welche sie zugreifen und durchlizenziert ist. Bei Miete kann man das einfach pro User bezahlen und hat eine gewisse Anzahl Gerät zugute kann also auch +- bereitstellen wie man möchte. lizenzdoc möge mich zbsp. korrigieren wenn dem nicht so ist, aber auf diese Zusammenfassung kam ich mal mit einem MS-Mitarbeiter sowie einem Lizenzspezi nach gefühlt stundenlangem Gespräch. Schriftlich wollte er mir leider gar nichts geben. Die User-Cal (ich würde immer UserCAL nehmen statt Device CAL in der heutigen Zeit) die immer notwendig ist für Serverzugriffe jeglicher Art, ist natürlich auch quasi immer notwendig. Irgend ein Server mit dem man direkt oder indirekt zu tun hat ist ja immer da. Lästig wird es, wenn die Zugriffe eben unterschiedlicher Natur sind oder von unterschiedlichen Geräten. Manchmal auf Server OS und manchmal auf Desktop OS. Da heisst es dann doppelt lizenzieren, VDA + RDS oder Enterprise+SA+RDS je nach Gerät. Irgendwann ist dann die persönliche Hardware halt vielleicht doch günstiger als Konsolidieren und selbst wenn diese im Rack steht. MS scheint zumindest gewillt zu sein, mit den Mietlizenzen Ordnung schaffen zu wollen und das ganze für die heutigen Umgebungen zu vereinfachen indem einfach Office und Windows pro User gelöst werden kann. Schade ist nur, dass alles mit Preisaufschlägen einhergeht.

Aber der Benutzer macht nur nen Doppelklick auf dem Desktop und es läuft wieder, Du kriegst weniger Telefonate und vor allem: Es wird so neu verbunden wie es eigentlich sollte, via DSF und nicht direkt via Serverfreigabe. Wie gesagt, Netzlaufwerke sind Diven, die werden quasi nicht einfach so aktualisiert. Die sollte man immer trennen und neu verbinden. Zum Beispiel beim anmelden. Die GPO soll auch trennen und neu verbinden und nicht einfach nur schauen ob da und wenn nicht, neu verbinden (ich wiederhole mich). Oder VPN-verbinden im gleichen Script wie Trennen/verbinden, oder auf nen Trigger mit nem Task wenn Verbindung steht. Deren Möglichkeiten gibt es viele. Ich mag die 0815 Variante, User hat auf Desktop nen Link zum Script der ihm das Laufwerk auf Wunsch neu verbindet. Simpel und Effizient.

Wie gesagt, erstelle ein Script unter C:\Scripts oder so welches das was per GPO ankommt neu macht. Sprich Netzlaufwerk trennen + wieder neu verbinden. Oder auch unter dem Netlogon-Share. Wenn etwas falsches zwischengespeichert ist, bekommst ein Netzlaufwerk selten wieder einfach so geradegebogen. Zumal immer noch die Frage ist, ob es nur neu erstellt wird per GPO wenn nicht bereits vorhanden (auch wenn falsch) oder komplett ersetzt wird. Wird es nicht ersetzt, dann gibt genau der eigene Work-Around nachher probleme wenn sie einen spezifischen Fileserver angeben jedoch nicht immer der gleiche verfügbar ist. --> Daher mache ich das normal per Script (auch wenn per GPO ausgelöst oder Startup), dann bin ich sicher das es getrennt und neu verbunden wird und so mancher Ärger erspart wird.

Einfach mal alle möglichen Varianten durchtesten, was anderes bleibt dir nicht übrig. Dazu mit Wireshark analysieren. 1. Laufwerk eben nicht per GPO verbinden sondern wirklich erst wenn VPN voll da ist und Im Netzwerkadapter das Netzwerk angezeigt wird die Verbindung erstellen. 2. Eine Stufe retour, also Laufwerk nicht trennen, neu starten und schauen ob es nach VPN Aufbau wieder tut 3. Wieder eine Stufe retour, Laufwerk trennen, neu starten, manuell verbinden (versuchen), VPN aufbauen schauen obs tut 4. manuell trennen, manuell neu verbinden entweder direkt per Kommandozeile oder testweise erst im Explorer So kriegst evtl. einen Work-Around hin der möglichst ohne Adminrecht und Neustart tut. Damit erstellst ein Script (sofern möglich und das Problem behebt), damit es der User selbst tun kann. Link auf das batch auf den Desktop. (Also Trennen und neu verbinden) Falscher Namespace: Nun da kommen wir der Sache schon etwas näher ;) Schuss ins blaue: Ihr habt zwei aktive DFS-Ziele aber nur eines ist per VPN erreichbar. Arbeitet er am anderen Standort, bekommt er entweder Zugriff auf beide Ziele oder auf genau ein anderes. Im Cache ist aber der Pfad zum "falschen" hinterlegt. Da verbundene Netzlaufwerke so gut wie nie - oder mir nicht erkennbaren System - aktualisiert werden, funktioniert der Zugriff nicht. Ich denke der Workaround mit einem Script welches das Laufwerk trennt und neu verbindet, sollte funktionieren. Aber von unterschiedlichen Sites und Standorten habe ich ehrlich gesagt keine Ahnung. Da ich nur kleine Umgebungen habe, versuche ich auch mehrere Standorte unter einen AD-Standort zu kriegen und die Leute per Fernzugriff auf das Hauptsystem arbeiten zu lassen. Sprich Jumphost Prinzip und möglichst Keep-it-simple. Ansonsten muss dann ein anderer ran.

So wie es aussieht scheitert er schon ziemlich früh. Ohne den Rest gesehen zu haben würde ich sagen, er findet den Pfad im Cache, will auf diesen zugreifen, kann aber den Domänen-Namen nicht auflösen. Mögliches Problem: - Keine saubere DNS-Auflösung in jenem Moment wo die Verbindung aufgebaut werden soll. - Noch keine aktive Domänenzugehörigkeit (Sichtbar beim Netzadapter) - Anderes Sicherheitstoken das nicht mehr gültig ist sobald er sich mit VPN einklinkt, die Verbindung hat er eventuell mit einem alten versucht aufzubauen, was dann scheitert. -->laufwerke trennen und neu verbinden nachdem ein manueller Zugriff geklappt hat. Das gleiche auch mal nach einem Neustart und erst verbinden wenn VPN aufgebaut ist (das meinte ich mit alles rauskicken) - Netzwerkprobleme --> Zu viel Paketloss --> Sicherheitstoken macht Ärger bzw. der Client verliert das Vertrauen des AD, dabei wird es bei verbundenen Netzlaufwerken gar nicht oder nicht sofort wiederhergstellt. Manueller Zugriff funktioniert dann meistens trotzdem, aber nicht zwingend stabil. (Hier hier es mal funktioniert indem ich die Geschwindigkeit gedrosselt habe, ist aber via VPN wohl eher tricky) - Möglicherweise gibt es auch Ärger wenn das Netzlaufwerk via einem anderen Adapter aufgebaut wird, also einmal WLAN und dann LAN oder VPN-Adapter. Dann könnte es sein, dass irgendwo eine definierte Route gecached ist, die dann fehlschlägt. EDIT: Hier findest den Ablauf einen DFS-Requests: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dfsc/1ff7d611-ba19-49fb-95f4-7c5358b86834 Aber eben, hier hilft vermutlich am Ende nur systematischen vorgehen, ausprobieren...

Technisch gesehen ist die erste Windows 10 ein 6.4. Also 4. Version von Vista. Das war sogar lange in den Build-Nummern erkennbar. Bis TP3 oder 4. Das stimmte nicht mit dem gigantischen Marketingen-Brimborium überein also hat man kuzerhand 10.0 für den Release daraus gemacht. Mittlerweile wäre die Zahl nach dem Komma aber deutlich höher. Nun macht man das Gegeteil und änderte während X Jahren die erste Nummer nach dem Komma gar nicht obwohl es immer ein neues Windows und nicht nur ein Update war. Wie Windows heisst und wie es vermarktet wird, dafür ist hauptsächlich das Marketing sowie die Strategie-Abteilung von MS zuständig. Bis 2012R2 war dem Marketing egal was die technische Version war. Jetzt fliesst sogar das mit ein. Was diese entscheiden ist wiederum abhängig davon, wo man am meisten Potential für Einnahmen sieht. Deren Ansichten können sich deshalb ändern. ;)

Das ist eben nicht wirklich korrekt. Windows spricht standardmässig priorisiert IPv6 und IPv4 wenn IPv6 nicht funktioniert. Nimmt man die Prio weg, spricht es priorisiert IPv4, solange es verfügbar ist. Wenn nicht versucht es die Kommunikation mit IPv6. Ist das eingeschränkt (Komponenten deaktiviert etc.) dann versucht es Windows meistens gar nicht erst. Das Chaos verursacht dann 6to4/Teredo. Deine Aussage beweist es ja: Ein Level X kann IPv6 durch MS supprted abschalten, auch wenn es dadurch grundsätzlich auch nicht zu 100% aus ist. Welches Level aktuell dafür benötigt wird, ist mir nicht bekannt. Aber es ist wohl immer noch supported möglich. Meist dürfte MS aber den support ablehnen wenn man keine triftigen Gründe hat. Ich blocke IPv6 meist auch in der Windows-Firwall. In der Filter-Engine sieht man nach korrekter IPv4 Priorisierung/IPv6 Deaktivierung dann sehr gut wo Windows tatsächlich noch versucht hat trotz allem per IPv6 zu kommunzieren. Das ist ab und wann mal ein Loopback, mehr nicht. Und auch diese sind sehr selten. Wird die Priorisierung nicht gemacht, dann massenhaft geblockten Traffic und lausige Performance. Mit dem Gegenteil, IPv4 abzuschalten hatte ich dagegen Massenhaft Ärger, mehr Verwaltungsaufwand und und und. Irgendwann dreht das vielleicht, solange das aber anders rum ist, schalte ich IPv6 ab weil ich keine Lust auf doppelte Arbeit habe.

Sage ich ja auch, plump deaktivieren gibt Ärger. Entweder richtig mit allem Pipapo oder eben bleiben lassen. Entweder IPv6 korrekt durchkonfigurieren und alles doppelspurig fahren oder eben soweit möglich abschalten. Hauptproblematik ist die Priorisierung. Insbesondere des Loopbacks. Ist auch der häufigste Fehler den viele machen. Da werden meist nur die Komponenten und die Protokolle der Adapter deaktiviert. MS testet durchaus auch mit reinen IPv4. Auch wenn mein aktuelles Interna ein paar Jahr her ist, denke ich, dass das noch immer gültig ist. Bei Grossfirmen war es sogar möglich, reines IPv4 als supported absegnen zu lassen. Es muss im Grunde auch total wurscht sein, weil die Kommunikation gemäss dem Schwerpukt bzw. Prefixpolicy des IP-Stacks von Windows erfolgt. Die Programme selbst benutzen den Stack nur. Am Stack vorbei geht meines wissens nach nichts. Standardmässig ist einfach IPv6 priorisiert, wodurch es zu massenhaft Verzögerungen kommt, wenn es nicht richtig deaktiviert wird. (Auch wenn es nicht zu 100% inaktiv ist) Bei Problemen ist es einfach so, das MS eventuell das aktivieren von IPv6 erforderlich macht. Egal ob es Hand und Fuss hat oder nicht. Das erreicht man z.Bsp. mittels Script + Reboot.