10
Globaler Katalog bei Umzug DC von SBS 2011 auf Windows Server 2016
Hallo Gemeinde,
momentan beschäftige ich mich mit einer AD Migration von einem Windows SBS 2011 auf Windows Server 2016. Auf dem SBS läuft außerdem noch ein Exchange Server, der aber im Anschluss nicht mehr benötigt wird.
Was bisher geschah:
- Windows Server 2016 installiert und in die bisherige Domäne des SBS mit aufgenomnmen
- Auf dem Server 2016 die Rollen für AD installiert und DC heraufgestuft
- DNS angepasst (Reverse Zone eingerichtet)
- Netzwerkeinstellungen: Beide DCs zeigen beim DNS auf sich selbst sowie jeweils auf den anderen DC
- NSLOOKUP - erfolgreich
- FSMO-Rollen erfolgreich auf den Server 2016 übertragen, netdom query fsmo zeigt das die jeweiligen Betriebsmaster auf dem neuen Server 2016 liegen
- Globaler Katalog unter "Active Directory-Standorte und -Dienste" unter den "NTDS-Einstellungen" für den Server 2016 aktiviert und für den SBS 2011 deaktiviert
Wie kann ich nun prüfen, ob der Gloable Katalog auf dem Server 2016 korrekt übertragen worden ist bzw. dieser DC dafür zuständig ist?
Leider konnte ich mich, nachdem ich testweise den SBS 2011 heruntergefahren hatte, nicht mehr mit einer AD Kennung an einem Client anmelden. Auch im Server 2016 konnte ich unter "AD Benutzer und Gruppen" keine Einträge mehr finden, hier kam nur der Hinweis, dass die Gegenseite fehlt. Nun traue ich mich deswegen auch icht auf dem SBS 2011 das AD über dcpromo zu deinstallieren.
Viele Grüße
Holger
momentan beschäftige ich mich mit einer AD Migration von einem Windows SBS 2011 auf Windows Server 2016. Auf dem SBS läuft außerdem noch ein Exchange Server, der aber im Anschluss nicht mehr benötigt wird.
Was bisher geschah:
- Windows Server 2016 installiert und in die bisherige Domäne des SBS mit aufgenomnmen
- Auf dem Server 2016 die Rollen für AD installiert und DC heraufgestuft
- DNS angepasst (Reverse Zone eingerichtet)
- Netzwerkeinstellungen: Beide DCs zeigen beim DNS auf sich selbst sowie jeweils auf den anderen DC
- NSLOOKUP - erfolgreich
- FSMO-Rollen erfolgreich auf den Server 2016 übertragen, netdom query fsmo zeigt das die jeweiligen Betriebsmaster auf dem neuen Server 2016 liegen
- Globaler Katalog unter "Active Directory-Standorte und -Dienste" unter den "NTDS-Einstellungen" für den Server 2016 aktiviert und für den SBS 2011 deaktiviert
Wie kann ich nun prüfen, ob der Gloable Katalog auf dem Server 2016 korrekt übertragen worden ist bzw. dieser DC dafür zuständig ist?
Leider konnte ich mich, nachdem ich testweise den SBS 2011 heruntergefahren hatte, nicht mehr mit einer AD Kennung an einem Client anmelden. Auch im Server 2016 konnte ich unter "AD Benutzer und Gruppen" keine Einträge mehr finden, hier kam nur der Hinweis, dass die Gegenseite fehlt. Nun traue ich mich deswegen auch icht auf dem SBS 2011 das AD über dcpromo zu deinstallieren.
Viele Grüße
Holger
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 342889
Url: https://administrator.de/contentid/342889
Printed on: April 24, 2024 at 17:04 o'clock
10 Comments
Latest comment
Server 2016 konnte ich unter "AD Benutzer und Gruppen" keine Einträge mehr finden
Dann hast du Probleme mit der AD Replikation. Erster Anlaufspunkt dazu die Ereignisanzeige.
Nun traue ich mich deswegen auch icht auf dem SBS 2011 das AD über dcpromo zu deinstallieren.
Um den SBS 2011 herunterzustufen muss vorher sowiso der Exchange deinstalliert werden.
LG Günther
Hallo,
leider finde ich folgendes in der Erreignisanzeige:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\sbs01.local\SysVol\sbs01.local\Policies\{B5746CE1-69C5-4C55-8F5A-A4756DA1ABF1}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
Weiter finde ich Fehler hinsichtlich des GC:
Die Active Directory-Domänendienste konnten keine Verbindung mit dem globalen Katalog herstellen.
Zusätzliche Daten
Fehlerwert:
1355 Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden.
Interne ID:
320137a
Benutzeraktion
Überprüfen Sie, ob der globale Katalog in der Gesamtstruktur verfügbar ist und von diesem Domänencontroller erreicht werden kann. Zur Diagnose dieses Problems können Sie das Hilfsprogramm "nltest" verwenden.
Wobei nltest /server:DC2016 /dsgetdc:sbs01.local mir als Kennzeichen den GC auswirft...
Mit den Gruppenrichtlinien bin ich etwas überfragt, wo könnte man hier nach schauen?
leider finde ich folgendes in der Erreignisanzeige:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\sbs01.local\SysVol\sbs01.local\Policies\{B5746CE1-69C5-4C55-8F5A-A4756DA1ABF1}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
Weiter finde ich Fehler hinsichtlich des GC:
Die Active Directory-Domänendienste konnten keine Verbindung mit dem globalen Katalog herstellen.
Zusätzliche Daten
Fehlerwert:
1355 Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden.
Interne ID:
320137a
Benutzeraktion
Überprüfen Sie, ob der globale Katalog in der Gesamtstruktur verfügbar ist und von diesem Domänencontroller erreicht werden kann. Zur Diagnose dieses Problems können Sie das Hilfsprogramm "nltest" verwenden.
Wobei nltest /server:DC2016 /dsgetdc:sbs01.local mir als Kennzeichen den GC auswirft...
Mit den Gruppenrichtlinien bin ich etwas überfragt, wo könnte man hier nach schauen?
Moin,
vielen Dank für den Hinweis! Leider hat das Setzten der Freigabe-Berechtigungen auf dem Server 2016 nichts gebracht, ein gpupdate /force läuft weiterhin mit Fehlern.
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\sbs01.local\SysVol\sbs01.local\Policies\{DD625D9A-3651-4979-882F-7BBE99DCC958}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich.
Auf dem dem SBS 2011 funktionier jedoch das gpupdate.
Du sprichts von möglichen DNS-Problemen, wo sollte ich hier am besten nachschauen? NSLOOKUP brachte keine Fehler.
vielen Dank für den Hinweis! Leider hat das Setzten der Freigabe-Berechtigungen auf dem Server 2016 nichts gebracht, ein gpupdate /force läuft weiterhin mit Fehlern.
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\sbs01.local\SysVol\sbs01.local\Policies\{DD625D9A-3651-4979-882F-7BBE99DCC958}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich.
Auf dem dem SBS 2011 funktionier jedoch das gpupdate.
Du sprichts von möglichen DNS-Problemen, wo sollte ich hier am besten nachschauen? NSLOOKUP brachte keine Fehler.
also..
stimt die neue IP adresse des DNS Server auf den client´s und auf den Servern
hast du dir sorgfältig die einträge angesehen angesehen?
hast du die alten sbs2011 DNS einträge als DNS etc.. gelöscht?
sind DFS Server und Client überall Aktiv?
und nicht zu vergessen, die Zeitsychronisierung? stimmt die Zeit auf beiden Servern?
wa sagt auf beiden Servern ein
?
gemacht ?
hast du das gelesen? und ausgeführt?
ach mir fallen noch 1000 sachen ein...
Frank
stimt die neue IP adresse des DNS Server auf den client´s und auf den Servern
hast du dir sorgfältig die einträge angesehen angesehen?
hast du die alten sbs2011 DNS einträge als DNS etc.. gelöscht?
sind DFS Server und Client überall Aktiv?
und nicht zu vergessen, die Zeitsychronisierung? stimmt die Zeit auf beiden Servern?
wa sagt auf beiden Servern ein
netdom query fsmo$currentForest = get-adforest
$currentDomain = get-addomain
set-adforestmode $currentforest -forestmode 4
set-addomainmode $currentdomain -domainmode 4hast du das gelesen? und ausgeführt?
ach mir fallen noch 1000 sachen ein...
Frank
Hi,
DCDIAG auf beiden DC's ausführen.
Der neue DC hat die beiden Freigaben SYSVOL und NETLOGON automatisch erstellt und nicht etwa Du manuell? Es ist wichtig, dass man das dem DC allein überlässt!
Die Meldung mit der GPO hat mit der nicht funktionierenden Anmeldung am Client erstmal nichts zu tun. Sie ist aber ein Indiz dafür, dass die SYSVOL-Replikation nicht richtig funktioniert oder dass SYSVOL schon an der Quelle (den alten DC) Fehler aufweist.
Ich würde in etwa so vorgehen:
E.
DCDIAG auf beiden DC's ausführen.
Der neue DC hat die beiden Freigaben SYSVOL und NETLOGON automatisch erstellt und nicht etwa Du manuell? Es ist wichtig, dass man das dem DC allein überlässt!
Die Meldung mit der GPO hat mit der nicht funktionierenden Anmeldung am Client erstmal nichts zu tun. Sie ist aber ein Indiz dafür, dass die SYSVOL-Replikation nicht richtig funktioniert oder dass SYSVOL schon an der Quelle (den alten DC) Fehler aufweist.
- Windows Server 2016 installiert und in die bisherige Domäne des SBS mit aufgenomnmen
- Auf dem Server 2016 die Rollen für AD installiert und DC heraufgestuft
Hier hättest Du schon alles überprüfen müssen, bevor Du weitere Anpassungen vornimmst. Das ist ein klassischer Fehler. AD braucht Zeit, auch bei nur 2 DC's. Eile mit Weile!- Auf dem Server 2016 die Rollen für AD installiert und DC heraufgestuft
- DNS angepasst (Reverse Zone eingerichtet)
Reverszonen sind für dieses Fehlerbild irrelevant- Netzwerkeinstellungen: Beide DCs zeigen beim DNS auf sich selbst sowie jeweils auf den anderen DC
Das würde ich dann genau anders herum einstellen.- NSLOOKUP - erfolgreich
Was hast Du da wo getestet?- FSMO-Rollen erfolgreich auf den Server 2016 übertragen, netdom query fsmo zeigt das die jeweiligen Betriebsmaster auf dem neuen Server 2016 liegen
s.o. Ist ein klassischer Fehler, wenn man nicht vorher die volle Funktionstüchtigkeit des neuen DC's überprüft hat.- Globaler Katalog unter "Active Directory-Standorte und -Dienste" unter den "NTDS-Einstellungen" für den Server 2016 aktiviert und für den SBS 2011 deaktiviert
Man kann zwar auch einen GC "aus dem Nichts" aufbauen, aber sollte natürlich immer erst abwarten, bis der neue GC aufgebaut wurde, bevor man den alten rausnimmt. Unabhängig davon wird ein DC keinen funktionstüchtigen GC aufbauen können, wenn er schon als DC Probleme hat.Ich würde in etwa so vorgehen:
- alten DC zum GC machen
- 15 min später den GC vom neuen DC entfernen
- GC kannst Du z.B. damit testen, dass Du einen neuen AD-Benutzer anlegst und Dich dann damit am Client anzumelden versuchst. Wenn kein funktionstüchtiger GC da ist, dann sollte die erste Anmeldung dieses neuen Benutzers an einem Windows Computer >Win2000 nicht funktionieren.
- dann die FSMO wieder an den alten DC abgeben
- jetzt in Ruhe den Fehler suchen
- wenn der neue DC seinen Dienst tut (Eventlogs "sauber", DCDIAG "sauber") dann nochmal explizit mit den MMC's testen (MMC's explizit mit dem neuen DC verbinden und schauen ob, alle Daten vorhanden sind (Benutzer, Gruppen, GPO usw.)
- erst dann dem neuen DC weitere Aufgaben geben
- Wenn der neue DC dann alle Aufgaben übernommen hat dann den alten DC nicht sofort demoten sondern erstmal nur ausschalten oder vom LAN nehmen. Wenn das Netz dann immer noch funktioniert (u.a. mit neu angelegtem Testbenutzer testen) dann erst den alten DC demoten.
E.
Hallo,
auf den Clients habe ich als 1. DNS jeweils den neuen DC eingetragen, als 2. DNS die 8.8.8.8 (oder sollte hier eher der SBS eingetragen werden?).
Wo meinst du sollen die DNS Einträge vom SBS gelöscht werden?
Der Befehl netdom query fsmo zeigt auf beiden Servern, dass die Betriebsmaster auf dem Server 2016 liegen, sollte also passen.
Die DFS Server und Client Dienste laufen auf beiden Servern, auch die Zeitsychronisierung passt.
Danke für den Hinweis für die SYSVOL Migration, diese habe ich nun durchgeführt, ebenso currentForest und currentDomain gesetzt.
gupdate /force ist erfolgreich durchgelaufen
dcdiag bringt einen Fehler:
Fehler bei der Verarbeitung der Gruppenrichtlinie (genauer gesagt die für Windows SBS CSE Policy)
nltest /server:DC2016 /dsgetdc:sbs01.local zeigt nun als Kennzeichen den GC an
Also bleibt noch ein Fehler bei dcdiag übrig, jedoch hat die Migration von SYSVOL funktioniert.
auf den Clients habe ich als 1. DNS jeweils den neuen DC eingetragen, als 2. DNS die 8.8.8.8 (oder sollte hier eher der SBS eingetragen werden?).
Wo meinst du sollen die DNS Einträge vom SBS gelöscht werden?
Der Befehl netdom query fsmo zeigt auf beiden Servern, dass die Betriebsmaster auf dem Server 2016 liegen, sollte also passen.
Die DFS Server und Client Dienste laufen auf beiden Servern, auch die Zeitsychronisierung passt.
Danke für den Hinweis für die SYSVOL Migration, diese habe ich nun durchgeführt, ebenso currentForest und currentDomain gesetzt.
gupdate /force ist erfolgreich durchgelaufen
dcdiag bringt einen Fehler:
Fehler bei der Verarbeitung der Gruppenrichtlinie (genauer gesagt die für Windows SBS CSE Policy)
nltest /server:DC2016 /dsgetdc:sbs01.local zeigt nun als Kennzeichen den GC an
Also bleibt noch ein Fehler bei dcdiag übrig, jedoch hat die Migration von SYSVOL funktioniert.
als 2. DNS die 8.8.8.8 (oder sollte hier eher der SBS eingetragen werden?).
Und du glaubst jetzt wirklich, der Google DNS kann mit sbs01.local etwas anfangen? In der lokale Domäne gibt es ausschließlich deinen eigenen DNS.
LG Günther
also wie Günter schon angemerkt hat, 8.8.8.8 soll da raus!
Frank
Frank
Der 8.8.8.8 als zweites solltest Du am DNS-Server als Weiterleitung eintragen, wenn Du keinen Proxy für Internetzugriff hast. Wenn Du eh über Proxy rausgehst, dann brauchst Du das für die Clients sowieso nicht.
