Domänen Migration Sysvol wird nicht repliziert

Hallo Zusammen
Ich habe eine kleine Testumgebung mit einem Windows Server 2012 und einem Windows Server 2016 (Testversion).

Windows Server 2012 = 192.168.1.30
Windows Server 2016 = 192.168.1.31

Folgende Schritte habe ich gemacht:
Auf dem neuen WS2016 die Domänen Rolle hinzugefügt und der bestehenden Domäne hinzugefügt.
Beide DC werden unter "Active Directoy Users and Computers" -> Domänen Controller angezeigt und auch unter "DNS Manager" -> Name Server.
Der WS2012 bekommt als alternativen DNS Server 192.168.1.31
Der WS2016 bekommt als alternativen DNS Server 192.168.1.30

Ich habe danach den DHCP noch auf dem WS2016 installiert und mit folgenden Scripts die DHCP Leases bzw. Einstellungen importiert. Ebenfalls habe ich die DHCP Einstellungen angepasst das der WS2016 als DNS verteilt wird.
Export-dhcpServer –ComputerName WS2012 -Leases -File C:\export\dhcpexp.xml –verbose
Import-DhcpServer –ComputerName WS2016 -Leases –File C:\export\dhcpexp.xml -Verbose

Den Umzug der FISMO Rollen habe ich auch vollzogen:
Move-ADDirectoryServerOperationMasterRole -Identity WS2012 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Der WS2012 wurde noch nicht entfernt, auch das Functional Level ist immer noch Windows Server 2012 und wurde noch nicht erhöht.

Jetzt wollte ich die Gruppenrichtlinien auf dem WS2016 anpassen, doch es heisst "Failed to open the Group Policy Object. You might not have the appropriate rights."
In den Details: "The network name cannot be found"

Ich habe danach bisschen geschaut und gesehen das ich unter C:\Windows\SYSVOL\domain keine Gruppenrichtlinien habe, auch keine SYSVOL oder Netlogon Freigabe auf dem Server existiert.

Im EventViewer habe ich den DFSR Error 4612 und 5002 auf dem WS2016.

Irgendwo ist bei der Migration der Rollen etwas schiefgegangen oder ich habe einen Schritt vergessen.
Kann mir da jemand weiterhelfen, da ich nicht gerade viel Ahnung habe von der DFS Replikation die es nutzt bei 2 Domänen Controller.

Vielen Dank für eure Hilfe

Gruss Dark_Masta

Hi Dark_Masta,

Mit diesem Blogeintrag solltest du das eigentlich wieder zum Laufen kriegen:
http://www.jniesen.de/?p=1292

grüsse

Das Hauptproblem bei solchen Konfigurationen ist der DNS Server. Du nutzt AD integriertes DNS, dummerweise braucht AD aber DNS um richtig zu funktionieren. Das ist ein Kreis, den Microsoft trotz mehrmaligen Nachbesserungen und so kleinen Umgebung nie anständig gelöst bekommen hat.

Was möchtest du am "Ende" erreichen? Das die Migration einmal durchläuft oder, beide Server nebeneinander betreiben?

Ein Pro Tipp von mir.

Vergiss die ganzen Empfehlungen von Microsoft, die haben schon lange vergessen, dass EDV in kleinen Umgebungen anders funktioniert. Richte auf dem neuen Server die DNS Zone so ein, dass sie Dateien und nicht AD nutzt (2 Klicks), trage den DNS Server auf beiden Servern ein und starte die nacheinander neu.

Voila! Keine DNS Probleme mehr und vermutlich auch eine problemlose Synchronisation.

Dark_Masta schrieb:

Der WS2012 bekommt als alternativen DNS Server 192.168.1.31
Der WS2016 bekommt als alternativen DNS Server 192.168.1.30

Zum Vergrößern anklicken....

Das ist der Fehler. Auf einem DC wird als primärer DNS-Server niemals die eigene IP eingetragen (es sei denn, es gibt nur einen DC), sondern immer ein anderer DC. Du musst die DNS-Server "über Kreuz" eintragen. So:
Server 2012: 1. DNS 192.168.1.31, 2. DNS. 192.168.1.30, 3. DNS 127.0.0.1
Server 2016: 1. DNS 192.168.1.30, 2. DNS. 192.168.1.31, 3. DNS 127.0.0.1
Die Loopbackadressen sind bei dieser Konfiguration optional, ich schreib sie trotzdem immer mit rein.

Hallo Zusammen
Vielen Dank für eure schnellen Antworten.

Mit diesem Blogeintrag solltest du das eigentlich wieder zum Laufen kriegen:
http://www.jniesen.de/?p=1292

Zum Vergrößern anklicken....

Habe diesen Befehl abgeben auf dem WS2012 und der Error ist bis jetzt nicht mehr aufgetaucht. Allgemein könnte man nach den EventViewer meinen es würde jetzt funktionieren.
Es hat mir dafür jetzt unter "C:\Windows\Sysvol\domain" einen neuen Ordner "DfsrPrivate" erstellt.
Trotzdem auf dem WS2016 ist der Ordner "C:\Sysvol\sysvol"Domäne"\leer" auch der Ordner "C:\Windows\SYSVOL\domain".

Was möchtest du am "Ende" erreichen? Das die Migration einmal durchläuft oder, beide Server nebeneinander betreiben?

Zum Vergrößern anklicken....

Ich möchte einen neuen Windows Server 2016 der alle Rollen übernimmt, das ich danach den WS2012 DC löschen kann und alles funktioniert.

Vergiss die ganzen Empfehlungen von Microsoft, die haben schon lange vergessen, dass EDV in kleinen Umgebungen anders funktioniert. Richte auf dem neuen Server die DNS Zone so ein, dass sie Dateien und nicht AD nutzt (2 Klicks), trage den DNS Server auf beiden Servern ein und starte die nacheinander neu.

Zum Vergrößern anklicken....

Also die DNS Zone hat es mir ja von dem WS2012 übernommen, welche 2 Klicks soll ich jetzt genau machen?

Das ist der Fehler. Auf einem DC wird als primärer DNS-Server niemals die eigene IP eingetragen (es sei denn, es gibt nur einen DC), sondern immer ein anderer DC. Du musst die DNS-Server "über Kreuz" eintragen. So:
Server 2012: 1. DNS 192.168.1.31, 2. DNS. 192.168.1.30, 3. DNS 127.0.0.1
Server 2016: 1. DNS 192.168.1.30, 2. DNS. 192.168.1.31, 3. DNS 127.0.0.1
Die Loopbackadressen sind bei dieser Konfiguration optional, ich schreib sie trotzdem immer mit rein.

Zum Vergrößern anklicken....

Ups, ja das macht noch Sinn
Habe ich geändert und beide Server neugestartet.

Ich habe selbst auf dem WS2012 Probleme die Gruppenrichtlinien zu öffnen.
Dort kommt der angegebene Domänencontroller kann nicht kontaktiert werden.
Davon sind alle Standorte der Konsole für folgende Gesamtstruktur betroffen
Gesamtstruktur: "Domäne"

Dark_Masta schrieb:

Also die DNS Zone hat es mir ja von dem WS2012 übernommen, welche 2 Klicks soll ich jetzt genau machen?

Zum Vergrößern anklicken....

Einfach die Einstellungen der Zone aufrufen und den Haken bei AD integriert herausnehmen. Dann wird die DNS Zone in einer Datei gespeichert und nicht mehr im AD und hat auch das Henne/Ei Problem nicht. Beide Server sollten dann logschwerweise nur noch diesen DNS Server nutzen.

Das was Evil E-Lex vorschlägt mag vom grundsätzlichen Ok sein, funktioniert im richtigen Betrieb aber nicht oder nur schlecht, wieso?

Nehmen wir einen einfachen Beispiel. Beide Server werden zur Datensicherung heruntergefahren und wieder gestartet. Dann haben beide bein hochfahren keinen DNS Server um das AD zu starten. Zudem werden beide dann zunächst mit dem falschen Netzwerkprofil hochgefahren, da sie keinen DNS Server finden. Im klassischen Fall fahren sie dann nach einem Neustart mit dem Profil "Öffentliches Netzwerk" hoch und können dann erst recht auch nachträglich keinen DNS Server erreichen, außer man deaktiviert die Firewall ganz oder erlaubt die Erreichbarkeit der DNS Server auch in diesem Profil.

Es gibt Wege wie man sowas umgehen kann indem man Einträge in der Hosts Datei anlegt und den NLA Dienst verzögert starten lässt etc. Aus der Praxis kann ich dir nur das wiederholen was ich weiter oben geschrieben habe. EIN DNS Server, KEINE AD Integration, beide zeigen auf diesen einen Server. Problem gelöst.

Replikation ist in der heutigen VM Welt sowieso so eine Sache. In Umgebungen bis 50 Server stellst du lieber EINEN reinen AD/DNS Server hin und kannst ihn bei Bedarf jederzeit zurück sichern. Jegliche Replikationsprobleme sind damit vom Tisch. Umgekehrt war es früher immer eine Katastrophe wenn du ein Snaphot zurück sichern musstest und plötzlich die Replikation nicht mehr übereinstimmte.

EDIT:
Wenn du mit einem Assistenten die Rollen installiert hast, überprüfe bitte die Weiterleitungen auf dem DNS Server. Assistenten legen gerne schon mal den bestehenden DNS Server in der Weiterleitungstabelle ein. Entferne zunächst einmal jegliche Weiterleitungen. Später kannst du dort den DNS Server deines Providers hinzufügen oder es leer lassen.

xexex schrieb:

Beide Server werden zur Datensicherung heruntergefahren und wieder gestartet.

Zum Vergrößern anklicken....

Man muss dafür Sorge tragen, dass immer ein DC erreichbar ist, daher fährt man die auch nicht gleichzeitig herunter. Wobei das für ein Backup auch völlig unnötig ist.

Dark_Masta schrieb:

Ich habe selbst auf dem WS2012 Probleme die Gruppenrichtlinien zu öffnen.
Dort kommt der angegebene Domänencontroller kann nicht kontaktiert werden.
Davon sind alle Standorte der Konsole für folgende Gesamtstruktur betroffen
Gesamtstruktur: "Domäne"

Zum Vergrößern anklicken....

Prüfe bitte auf beiden Servern die DNS-Servereinstellungen für IPv6. Es kann sein, dass dort jeweils ::1 drinsteht. Ändere das dann auf "DNS-Server automatisch beziehen".

Evil E-Lex schrieb:

Man muss dafür Sorge tragen, dass immer ein DC erreichbar ist, daher fährt man die auch nicht gleichzeitig herunter. Wobei das für ein Backup auch völlig unnötig ist.

Zum Vergrößern anklicken....

Ich könnte dir mindestens 10 Fälle nennen wo sich das nicht vermeiden lässt. Von Datensicherung, über einen Stromausfall, bis zum Systemabsturz oder einer fehlgeschlagenen VM Migration ist alles dabei. In all diesen Fällen stehst du mit 2 nicht funktionsfähigen AD/DNS Servern da.

Da der TE sowieso das Ziel hat, nur den neuen Server zu nutzen, ist dein Vorschlag sowieso unnötig und kontraproduktiv. Am Ende sollte er einen DNS Server stehen haben, der seine DNS Zonendaten in eine Datei und nicht im AD speichert, sonst kriegt bei jedem Start des Servers Fehler.

IPv6 gehört außerdem konfiguriert oder deaktiviert. Sonst ist alles was wir beide besprochen haben Makulatur und die beiden Server versuchen eh die Kommunikation über IPv6 abzuwickeln. Auch das ist eine häufige Fehlerquelle. Dein Vorschlag führt zu einem FEHLER, da die Server dann vermutlich den DNS Server vom RA des Routers bekommen und dort nicht die für AD benötigten Einträge registriert bekommen.

Zusammengefasst.
IPv6 deaktivieren.
DNS Zone auf dem Server 2016 auf Dateispeicherung umstellen.
DNS Zeiger auf den Server 2016 umstellen (kein Backup DNS!)
Server 2016 neu starten
Server 2012 neu starten
Freuen


Im Nachtrag kann sich der TE noch immer mit IPv6 beschäftigen, falls sein Provider und der Router es unterstützt. In der heutigen Zeit sollte man sich dem nicht mehr verschließen.

xexex schrieb:

IPv6 gehört außerdem konfiguriert oder deaktiviert. Sonst ist alles was wir beide besprochen haben Makulatur und die beiden Server versuchen eh die Kommunikation über IPv6 abzuwickeln. Auch das ist eine häufige Fehlerquelle. Dein Vorschlag führt zu einem FEHLER, da die Server dann vermutlich den DNS Server vom RA des Routers bekommen und dort nicht die für AD benötigten Einträge registriert bekommen.

Zum Vergrößern anklicken....

Mein Vorschlag behebt erstmal nur die fehlerhafte Standardkonfiguration für den bevorzugten DNS-Server. Die führt nämlich schlicht dazu, dass IPv6 immer bevorzugt genutzt wird, egal ob vorhanden oder nicht. Die Einstellung "DNS-Serveradresse automatisch beziehen" führt bei nicht vorhandenem IPv6 nicht zu einem Fehler. Sollte IPv6 allerdings tatsächlich vorhanden sein, muss das passend konfiguriert werden. Abschalten würde ich es nicht, da MS explizit davon abrät.

xexex schrieb:

Ich könnte dir mindestens 10 Fälle nennen wo sich das nicht vermeiden lässt. Von Datensicherung, über einen Stromausfall, bis zum Systemabsturz oder einer fehlgeschlagenen VM Migration ist alles dabei. In all diesen Fällen stehst du mit 2 nicht funktionsfähigen AD/DNS Servern da.

Zum Vergrößern anklicken....

Dann las mal hören.
Datensicherung zählt nicht, geht online.
Stromausfall auch nicht. Gibt USVs.
Systemabsturz auf allen DCs gleichzeitig? Wohl kaum.
VM-Migration bei einen DC? Man installiert auf der neuen Plattform einen weiteren DC und lässt replizieren.

Du versuchst hier dem AD Schwächen anzudichten, obwohl hier die IT-Konzepte der Schwachpunkt sind.

Evil E-Lex schrieb:

Ergänzung vom 23.03.2017 13:03 Uhr:
Dann las mal hören.
Datensicherung zählt nicht, geht online.
Stromausfall auch nicht. Gibt USVs.
Systemabsturz auf allen DCs gleichzeitig? Wohl kaum.
VM-Migration bei einen DC? Man installiert auf der neuen Plattform einen weiteren DC und lässt replizieren.
Du versuchst hier dem AD Schwächen anzudichten, obwohl hier die IT-Konzepte der Schwachpunkt sind.

Zum Vergrößern anklicken....

Du sprichst von grauer Theorie, ich von gelebter Praxis in mittlerweile 20 Jahren Berufserfahrung. Wenn was schief gehen kann dann geht auch was schief.

Eine USV hält nicht ewig, fahren beide DC runter MUSS du manuell eingreifen oder nach Pfuschlösungen suchen wie die, die ich oben aufgeführt habe. Systemabsturz auf einer VM Kiste auf der sich beide Server befinden? Passiert! Und mit VM Migration meine ich eine Migration der Maschinen unter VMware um Wartung an einer Hardware durchzuführen.

Du kannst gerne weiter dein theoretisches Wissen verbreiten und sich strickt an die Microsoft Guidelines halten. Ich habe oben aber explizit angemerkt das einige davon Bullshit sind, weil Microsoft schon lange nicht mehr an kleine Umgebungen denkt sondern an riesige Serverfarmen oder am Wissen festhält das nicht mehr aktuell ist. In Zeiten der Virtualisierung kann ich einen DC in unter einer Minute zurück sichern und ihn während der Arbeitszeit dank VM Migration immer online lassen. AD/DNS Replikation kommt noch aus Zeiten, als die Software noch fest an die Hardware gebunden war, man einen längerfristigen Ausfall vermeiden wollte und Sinn macht sie erst in großen Umgebungen wo man eine entsprechende Infrastruktur, vielleicht gar mit verteilten Standorten hat.

Dazu hat Microsoft aus guten Gründen lange Zeit autarke DNS Server empfohlen, vermutlich machen sie es heute noch. Gehe ich nach den Richtlinien kann ich schon 4 Server nur für die grundlegende Infrastruktur einplanen. Absoluter Schwachsinn in kleinen Umgebungen.

Ich möchte aber mir dir gar nicht über das Thema diskutieren. TE will einen Server migrieren und nicht eine HA Umgebung schaffen, da führt deine Lösung nicht wirklich zum Ziel. Sowas mache ich praktisch wöchentlich und kenne die Probleme.

Evil E-Lex schrieb:

Abschalten würde ich es nicht, da MS explizit davon abrät.

Zum Vergrößern anklicken....

Dann denke logisch nach und lass MS Gerede mal weg.

Standardmäßig nutzt Windows ab Vista IPv6 IMMER zuerst. IPv6 funktioniert auch ohne jegliche Unterstützung der Router dank Autokonfiguration. Dann gibt es halt bei jeden Systemstart irgendeine Adresse, die im DNS Server vom DHCP Client Dienst registriert wird. Blöd nur, dass beide DNS Server eine Adresse per Autokonfiguration bekommen und noch blöder, dass die Daten dazu im AD gespeichert sind, das ja wieder DNS benötigt. Wenn du damit einer erfolgreiche AD Synchronisation hin bekommst, ist es reine Glückssache.

Wie ich schon weiter oben geschrieben habe. Konfiguriere es oder deaktiviere es! Wenn du an den MS Richtlinien so hängst, MUSST du beiden Servern auch eine feste IPv6 Adressen geben und die Konfigurationsschritte die du für IPv4 genannt hast nochmal unter IPv6 durchführen. Eigentlich kannst du dir gar die IPv4 Konfiguration gleich sparen.

xexex schrieb:

Du sprichst von grauer Theorie, ich von gelebter Praxis in mittlerweile 20 Jahren Berufserfahrung. Wenn was schief gehen kann dann geht auch was schief.

Zum Vergrößern anklicken....

Ich mache den Job lange genug, um zu wissen, dass man am wenigsten Probleme hat, wenn man sich an die Best-Practice hält. Die Probleme passieren immer dort, wo man sich nicht, oder nicht konsequent daran hält. Die Bespiele hast du genannt.
Daraus zu folgern, die Best-Practice wären Bullshit, halte ich für gewagt.

Ich administriere im Übrigen nur Systeme im SMB-Umfeld bis ca. 15 Server. Die von dir geschilderten Probleme treten dort nicht auf, wenn man die Systeme passend konfiguriert.

Systemabsturz auf einer VM Kiste auf der sich beide Server befinden? Passiert! Und mit VM Migration meine ich eine Migration der Maschinen unter VMware um Wartung an einer Hardware durchzuführen.

Zum Vergrößern anklicken....

Und wieder: Fehler im Konzept. Zwei DCs auf einem Storage. Was soll das bringen? Dann kann man es gleich lassen. Best Practice in virtualisierten Umgebungen ist, einen DC auf einem separaten Storage zu haben.

Standardmäßig nutzt Windows ab Vista IPv6 IMMER zuerst. IPv6 funktioniert auch ohne jegliche Unterstützung der Router dank Autokonfiguration. Dann gibt es halt bei jeden Systemstart irgendeine Adresse, die im DNS Server vom DHCP Client Dienst registriert wird. Blöd nur, dass beide DNS Server eine Adresse per Autokonfiguration bekommen und noch blöder, dass die Daten dazu im AD gespeichert sind, das ja wieder DNS benötigt. Wenn du damit einer erfolgreiche AD Synchronisation hin bekommst, ist es reine Glückssache.

Zum Vergrößern anklicken....

Du irrst dich. Die link-lokale Adresse wird nicht im DNS registriert. Steht die DNS-Serveradresse auf automatisch beziehen und es ist kein Router im Netz der RAs verteilt, wird kein zudem auch IPv6-DNS-Server zugewiesen:

Evil E-Lex schrieb:

Daraus zu folgern, die Best-Practice wären Bullshit, halte ich für gewagt.. Best Practice in virtualisierten Umgebungen ist, einen DC auf einem separaten Storage zu haben.

Zum Vergrößern anklicken....

Und natürlich hat jedes kleine Unternehmen zwei autark funktionierende Storage Systeme im Einsatz. Natürlich existieren auch mindestens zwei autarke Stromkreise mit mindestens zwei USVs und einem Generator als Backup. Merkst du was?

Ich habe nie gesagt alle Microsoft Vorschläge wären Bullshit. Ich habe nur gesagt, dass sie schon lange keine Idee mehr haben wie es in kleineren Umgebungen aussieht.

Best Practice sind auch zwei Exchange Server mit DAG und die Nutzung von einzelnen Festplatten zur Datenbankspeicherung, folgst du solchen Vorschlägen auch blind?

Wovon du redest ist graue Theorie für Optimalumgebungen, die sich strikt nach irgendwelchen teils zweifelhaften Richtlinien von Microsoft richten. So hat Microsoft auch noch bis vor kurzem (Server 2012) vorgeschrieben DCs gar nicht als Snapshots zu sichern und sie physikalisch auszulegen, hältst du dich auch daran?

Die Realität im Mittelstand sieht anders aus und da ergeben sich durch solche Konfigurationen Probleme, die man ohne sie nicht hätte. Nenne mir EINEN Grund der dafür spricht bei Einsatz von Virtualisierung und bei <1000 Mitarbeitern an einem Standort mehrere DCs einzusetzen und erzähle nichts von "Weil Microsoft es so empfiehlt".

Ist aber auch genug OT. Wie schon erwähnt, will TE migrieren und keine Microsoft konforme Umgebungen schaffen und bei einem Server ist eine AD Integration von DNS sowieso Schwachsinn und führt immer zu Fehlern. Oder willst du dem TE auch empfehlen, für seine Testumgebung unbedingt 4 DNS und 2 AD Server vorzuhalten? Deine Methode ist nicht grundsätzlich schlecht, sie versagt nur überall dort, wo man sich nicht strikt an die Vorgaben von Microsoft hält und das trifft häufiger zu als umgekehrt.

xexex schrieb:

Und natürlich hat jedes kleine Unternehmen zwei autark funktionierende Storage Systeme im Einsatz. Natürlich existieren auch mindestens zwei autarke Stromkreise mit mindestens zwei USVs und einem Generator als Backup. Merkst du was?

Zum Vergrößern anklicken....

Auch kleine Unternehmen können einen DC als VM und einen weiteren physisch betreiben. Ebenso sind zwei USVs kein Hexenwerk. Was soll eigentlich dieser aggressive Ton deinerseits? Hab ich dir was getan?

Ich habe nie gesagt alle Microsoft Vorschläge wären Bullshit. Ich habe nur gesagt, dass sie schon lange keine Idee mehr haben wie es in kleineren Umgebungen aussieht.

Zum Vergrößern anklicken....

Das ist deine Meinung. Meine sieht anders aus.

Best Practice sind auch zwei Exchange Server mit DAG und die Nutzung von einzelnen Festplatten zur Datenbankspeicherung, folgst du solchen Vorschlägen auch blind?

Zum Vergrößern anklicken....

Damit kenne ich mich nicht aus. Keiner meiner Kunden ist groß genug, so etwas zu benötigen.

Wovon du redest ist graue Theorie für Optimalumgebungen, die sich strikt nach irgendwelchen teils zweifelhaften Richtlinien von Microsoft richten.

Zum Vergrößern anklicken....

Nein, das ist meine Adminpraxis seit zig Jahren. Ich bin allerdings der Meinung, dass MS als Hersteller des OS am besten weiß, wie damit umzugehen ist. Ich würde mir nicht anmaßen das besser zu können.

So hat Microsoft auch noch bis vor kurzem (Server 2012) vorgeschrieben DCs gar nicht als Snapshots zu sichern und sie physikalisch auszulegen, hältst du dich auch daran?

Zum Vergrößern anklicken....

Ja natürlich. Diese Vorgaben hatten gute Gründe. Und ich würde auch jetzt immer noch mindestens einen physischen DC haben wollen.

Die Realität im Mittelstand sieht anders aus und da ergeben sich durch solche Konfigurationen Probleme, die man ohne sie nicht hätte. Nenne mir EINEN Grund der dafür spricht bei Einsatz von Virtualisierung und bei <1000 Mitarbeitern an einem Standort mehrere DCs einzusetzen und erzähle nichts von "Weil Microsoft es so empfiehlt".

Zum Vergrößern anklicken....

Alle 1000 Mitarbeiter arbeiten an einem Standort in einem Netz? Dann mag das gehen. Ansonsten würde man aber für verschiedene Standorte einzelne Sites mit lokalen DCs für die Anmeldung haben wollen. Und außerdem: Redundanz. Nur ein DC ist blöd, wenn die Backupinfrastruktur am Ende vom AD abhängig ist und man mangels AD nicht an das Backup des einen DC kommt. Ich mag nicht ausschließen, dass man da drumherum designen kann, aber ich würde diese Aufwand nicht treiben.

Ist aber auch genug OT. Wie schon erwähnt, will TE migrieren und keine Microsoft konforme Umgebungen schaffen und bei einem Server ist eine AD Integration von DNS sowieso Schwachsinn und führt immer zu Fehlern. Oder willst du dem TE auch empfehlen, für seine Testumgebung unbedingt 4 DNS und 2 AD Server vorzuhalten? Deine Methode ist nicht grundsätzlich schlecht, sie versagt nur überall dort, wo man sich nicht strikt an die Vorgaben von Microsoft hält und das trifft häufiger zu als umgekehrt.

Zum Vergrößern anklicken....

An dem OT bist du nicht unschuldig. Du schriebst:

Das Hauptproblem bei solchen Konfigurationen ist der DNS Server. Du nutzt AD integriertes DNS, dummerweise braucht AD aber DNS um richtig zu funktionieren. Das ist ein Kreis, den Microsoft trotz mehrmaligen Nachbesserungen und so kleinen Umgebung nie anständig gelöst bekommen hat.

Zum Vergrößern anklicken....

Deine Aussage liest sich aber so, als wäre MS nicht Lage, korrekt funktionierende Produkte ausliefern. Was stimmt ist: Die Standardwerte sind schlecht gewählt (insbesondere die Loopbackadressen bei den DNS-Servereinstellungen). Hier aber hat der TE eine simple DNS-Fehlkonfiguration, die man einfach korrigieren kann.

Zwei DNS und DC (beide Rollen auf dem gleichen OS installiert) reichen aus und lassen einen die AD-Replikation stabil betreiben und eine DC-Migration sieht nun einmal eine Replikation vor.

Eine DC-Migration sieht bei mir immer so aus:
1. Neuen DC installieren
2. DNS-Einstellungen auf beiden DCs anpassen
3. Replikation abwarten
4. FSMO-Rollen übertragen
5. Alten DC herabstufen
6. DNS-Einstellungen auf dem neuen DC anpassen

Da habe ich wohl eine heftige Diskussion ausgelöst =)

Bei mir wird es ja eine Migration und nicht ein Dauerbetrieb von 2 Domänen Controller, daher werde ich den WS2016 DC nach dem ich den WS2012 heruntergefahren habe wieder umkonfigurieren das er auf sich selbst schaut als DNS.

Ich habe das Problems jedenfalls gelöst und zwar ist mir ein riesen Mist passiert.
Ich hatte ein Chaos zwischen den VLANs daher hat auch kein Tipp oder Link von euch geholfen

Habe jetzt eine WS2016 Domänen Controller mit allen FSMO Rollen und mit einem SysVol das repliziert wird.

Dafür taucht jetzt ein neues Problem auf und zwar habe ich ja bei den GPOs einen Central Store und beim öffnen der Gruppenrichtlinien sagt er mir: "\"Domäne"\sysvol"Domäne"\Policies\PolicyDefinitions\adfs.admx (error =2): The system cannont find the file specified.

Was mir aufgefallen ist das auf dem WS2012 der auf Deutsch aufgesetzt ist liegt unter de-DE ein adfs.adml aber der en-US Ordner ist leer. Jetzt der neue WS2016 ist auf Englisch aufgesetzt und bräuchte wohl ein adfs.adml in dem en-US Ordner oder?
Doch auf dem WS2016 unter C:\Windows\PolicyDefinitions finde ich keine adfs.admx geschweige im Ordner en-US das passende Sprachfile.

Ich müsste ja jetzt eigentlich auf dem WS2016 die Datein unter C:\Windows\PolicyDefinitions in den CentralStore kopieren um die neuen Windows Server 2016 und Windows 10 GPO zu bekommen doch auch hier habe ich ja nur eine Englische Variante was mir wohl auf dem WS2012 sofort den selben Fehler generieren würde oder?

Gruss Dark_Masta

Dark_Masta schrieb:

Ich müsste ja jetzt eigentlich auf dem WS2016 die Datein unter C:\Windows\PolicyDefinitions in den CentralStore kopieren um die neuen Windows Server 2016 und Windows 10 GPO zu bekommen doch auch hier habe ich ja nur eine Englische Variante was mir wohl auf dem WS2012 sofort den selben Fehler generieren würde oder?

Zum Vergrößern anklicken....

Korrekt. Aber du kannst die Templates hier herunterladen, da sind diverse Sprachen dabei: https://www.microsoft.com/en-us/download/details.aspx?id=53430
Allerdings benötigst du bei nur einem DC eigentlich keinen CentralStore.