15
Windows Server Migration 2012r2 auf 2022
Hallo zusammen,
ich habe ein Problem. Ich habe einen alten 2012 r2 Server welcher dringend gewechselt werden musste. Da aber relativ viel an der Kiste hängt habe ich den neuen Server ins Netzwerk eingebunden und mit in die Domäne als zweiten DC eingebunden. Nachdem ich ihn hab replizieren lassen, wurden die Rollen auf den neuen Server übertragen. netdom query fsmo gibt auch bei allen Punkten den neuen DC an. DHCP umgezogen etc. Nun ist mir aufgefallen, dass ich aber auf dem neuen Server kein Sysvol Verzeichnis habe. DCDIAG ergibt auf dem alten Server folgende Fehler:
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
Starting test: LocatorCheck
Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Dom„nencontroller ist nichtverfügbar.
auf dem neuen Server habe ich:
Starting test: Advertising
Achtung: Bei dem Versuch, SRVDC2 zu erreichen, wurden von DsGetDcName Informationen für \\SRVDC.xxx.local zurückgegeben. DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
und
Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\SRVDC2\netlogon) [SRVDC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten, Der Netzwerkname wurde nicht gefunden.
Hat jemand vielleicht einen Tipp für mich, wie ich es hinbekomme das ich auf dem neuen Server wenigstens das Sysvol drinnen habe? Denn dann könnte ich ja den alten DC zur Not manuell entfernen. Denn bei einem aktuellen entfernen kommt auf dem alten im Server Manager:
Es konnte kein anderer Domänencontroller erreicht werden, aber im Verzeichnis befinden sich andere Domänencontrollerobjekte. Wenn Sie sicher sind, dass die der letzt Domänencontroller für die Domäne ist und dern Vorgang fortsetzen möchten, bestätigen Sie, dass dies der letzte Domänencontroller in der Domäne ist.
Danke für eventuell Tipps und Trickes.
ich habe ein Problem. Ich habe einen alten 2012 r2 Server welcher dringend gewechselt werden musste. Da aber relativ viel an der Kiste hängt habe ich den neuen Server ins Netzwerk eingebunden und mit in die Domäne als zweiten DC eingebunden. Nachdem ich ihn hab replizieren lassen, wurden die Rollen auf den neuen Server übertragen. netdom query fsmo gibt auch bei allen Punkten den neuen DC an. DHCP umgezogen etc. Nun ist mir aufgefallen, dass ich aber auf dem neuen Server kein Sysvol Verzeichnis habe. DCDIAG ergibt auf dem alten Server folgende Fehler:
Starting test: DFSREvent
Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
Starting test: LocatorCheck
Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Dom„nencontroller ist nichtverfügbar.
auf dem neuen Server habe ich:
Starting test: Advertising
Achtung: Bei dem Versuch, SRVDC2 zu erreichen, wurden von DsGetDcName Informationen für \\SRVDC.xxx.local zurückgegeben. DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
und
Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\SRVDC2\netlogon) [SRVDC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten, Der Netzwerkname wurde nicht gefunden.
Hat jemand vielleicht einen Tipp für mich, wie ich es hinbekomme das ich auf dem neuen Server wenigstens das Sysvol drinnen habe? Denn dann könnte ich ja den alten DC zur Not manuell entfernen. Denn bei einem aktuellen entfernen kommt auf dem alten im Server Manager:
Es konnte kein anderer Domänencontroller erreicht werden, aber im Verzeichnis befinden sich andere Domänencontrollerobjekte. Wenn Sie sicher sind, dass die der letzt Domänencontroller für die Domäne ist und dern Vorgang fortsetzen möchten, bestätigen Sie, dass dies der letzte Domänencontroller in der Domäne ist.
Danke für eventuell Tipps und Trickes.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2086415181
Url: https://administrator.de/contentid/2086415181
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
15 Kommentare
Neuester Kommentar
Moin,
ich nehm an der 2012 läuft noch mit FRS, der 2022 kann nur DFSR
PS
ich nehm an der 2012 läuft noch mit FRS, der 2022 kann nur DFSR
PS
\\SRVDC.xxx.local
Und wehe es kommt jetzt wieder mit dem mDNS Gespenst um die Ecke!! :D
1
Vielen Dankeuch beiden ich arbeite mich mal durch.
Vielleicht irre ich mich, aber wirft der Server dann nicht schon beim Promoten eine Fehlermeldung aus?
Und wehe es kommt jetzt wieder mit dem mDNS Gespenst um die Ecke!! :D
Aber mal etwas lesen zur Horizonterweiterung damit der TO solche fatalen DNS Design Fehler nicht wiederholt kann ja sicher nicht schaden. 
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
https://www.heise.de/select/ct/2017/26/1513540412603853
https://en.wikipedia.org/wiki/.local#Microsoft_recommendations
damit der TO solche marginalen DNS Design Fehler, die in der Praxis keinerlei Auswirkungen auf den AD Betrieb haben, nicht
FTFY
Moin
Da solltest Du mal als erstes einsteigen. Ohne PDC-Emulator wird Deine Domäne nicht korrekt funktionieren.
Was sagt Dir denn ein netdom query fsmo ?
Und immer wieder diese Diskussion, ob es sinnvoll ist, eine ggf. vor über 20 Jahren nach den damals gültigen BestPractices installierte Domäne umzubennennen, um dieses meist nur kosmetische "Problem" aus der Welt zu schaffen...
Gruß
Zitat von @letstryandfindout:
Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Dom„nencontroller ist nichtverfügbar.
Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Dom„nencontroller ist nichtverfügbar.
Da solltest Du mal als erstes einsteigen. Ohne PDC-Emulator wird Deine Domäne nicht korrekt funktionieren.
Was sagt Dir denn ein netdom query fsmo ?
Zitat von @148523:
Aber mal etwas lesen zur Horizonterweiterung damit der TO solche fatalen DNS Design Fehler nicht wiederholt kann ja sicher nicht schaden.
Aber mal etwas lesen zur Horizonterweiterung damit der TO solche fatalen DNS Design Fehler nicht wiederholt kann ja sicher nicht schaden.
Und immer wieder diese Diskussion, ob es sinnvoll ist, eine ggf. vor über 20 Jahren nach den damals gültigen BestPractices installierte Domäne umzubennennen, um dieses meist nur kosmetische "Problem" aus der Welt zu schaffen...
Gruß
Zitat von @Hubert.N:
Moin
Da solltest Du mal als erstes einsteigen. Ohne PDC-Emulator wird Deine Domäne nicht korrekt funktionieren.
Was sagt Dir denn ein netdom query fsmo ?
Und immer wieder diese Diskussion, ob es sinnvoll ist, eine ggf. vor über 20 Jahren nach den damals gültigen BestPractices installierte Domäne umzubennennen, um dieses meist nur kosmetische "Problem" aus der Welt zu schaffen...
Gruß
Moin
Zitat von @letstryandfindout:
Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Dom„nencontroller ist nichtverfügbar.
Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 1355 Es wurde kein primärer Domänencontroller gefunden. Der Server mit der Rolle für den primären Dom„nencontroller ist nichtverfügbar.
Da solltest Du mal als erstes einsteigen. Ohne PDC-Emulator wird Deine Domäne nicht korrekt funktionieren.
Was sagt Dir denn ein netdom query fsmo ?
Zitat von @148523:
Aber mal etwas lesen zur Horizonterweiterung damit der TO solche fatalen DNS Design Fehler nicht wiederholt kann ja sicher nicht schaden.
Aber mal etwas lesen zur Horizonterweiterung damit der TO solche fatalen DNS Design Fehler nicht wiederholt kann ja sicher nicht schaden.
Und immer wieder diese Diskussion, ob es sinnvoll ist, eine ggf. vor über 20 Jahren nach den damals gültigen BestPractices installierte Domäne umzubennennen, um dieses meist nur kosmetische "Problem" aus der Welt zu schaffen...
Gruß
Also egal auf welchem Server ich das eingebe werden Schemamaster, Domänennamen-Master, PDC, RID-Pool-Manger, Infrastrukturmaster als der neue Server SRVDC2 angegeben. Bestünde die Möglichkeit den alten DC manuell vom neuen zu entfernen und dann das Sysvol auf dem neuen erstellen zu lassen? Oder wäre es eine möglichkeit die FSMO Rollen wieder zurück zu spielen, zu schauen ob das mit dem DFSR Format stimmt, was ja gerade nicht geht um dann eventuell danach diese wieder zu verschieben?
Eine Frage wegen dem Format. Ich hatte irgendwann mal bei einem anderen Kunden eine Warnung das ich den neuen Server gar nicht integrieren konnte, da er eben noch im alten Format lief. Das hatte ich hier jedoch nicht. Vor allem habe ich beim check von dfsrmig /getglobalstate die Meldung das der alte Server eben keine Verbindung zum PDC-Emulator herstellen kann. Daher dachte ich eventuell ist es ja schon DFSR aber Get-DfsrState gibt mir leider kein Ergebnis aus. Wenn ich den PDC aber abfrage auf dem alten Server per dsquery server -hasfsmo pdc dann wird CN=SRVDC2 angegeben.
Also egal auf welchem Server ich das eingebe werden Schemamaster, Domänennamen-Master, PDC, RID-Pool-Manger, Infrastrukturmaster als der neue Server SRVDC2 angegeben.
Was ja eher suboptimal ist, weil das Einbinden des neuen DCs ja nicht funktioniert hatBestünde die Möglichkeit den alten DC manuell vom neuen zu entfernen und dann das Sysvol auf dem neuen erstellen zu lassen?
Ich verstehe die Frage nicht so ganz... "den alten vom neuen entfernen" ??
Oder wäre es eine möglichkeit die FSMO Rollen wieder zurück zu spielen (...)
In Deiner Situation würde ich immer erst mal alles auf Ausgang setzen. Also die FSMOs wieder auf den alten DC bringen. Wobei es mich wundert, dass das Übertragen überhaupt funktionieren konnte.(...) zu schauen ob das mit dem DFSR Format stimmt, was ja gerade nicht geht um dann eventuell danach diese wieder zu verschieben?
Ich denke, ohne DFSR hätte sich der neue DC nicht installieren lassen. Das wird bei der Installation geprüft und ohne geht es erst mal nicht weiter. Du kannst es aber auch durch dfsrmig /getglobalstate überprüfenIch würde erst mal alles auf Ausgangszustand bringen. Also: FSMO-Rollen auf den alten DC und diesen auf Fehler prüfen. Den neuen DC entfernen und erst wenn sichergestellt ist, dass der alte DC sauber läuft die Instalallation starten.
Checke auf dem alten DC die Ereignsianzeige.
Denke auch daran, die DFSR-Protokolle zu prüfen. Irgendwie sagt mir gerade meine keine Kristallkugel, dass der alte DC mal auf DFSR umgestellt wurde, dabei aber nicht sichergestellt war, dass FSR überhaupt funktionierte. Das fällt bei einem Single_DC halt nicht unbedingt auf.
Kann aber natürlich auch sein, dass die Kugel sich irrt...
Gruß
Erst einmal vielen lieben Dank für deine Hilfe. Ich weiss das sehr zu schätzen. Ich habe nun mal alle FSMO Rollen zurück gemach. Die DFSR Abfrage ergibt:
Aktueller globaler DFSR-Status: "Entfernt".
Erfolgreich aus.
Beim DCDIAG habe ich nur noch die Meldung das es beim replizieren in den letzten 24 Std. Fehler gab. Da habe ich nun im alten Log drinnen:
Der DFS-Replikationsdienst beendet die Kommunikation mit Partner SRVDC2 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 9033 (Die Anforderung wurde durch Herunterfahren abgebrochen.)
Verbindungs-ID: 08BE0AE9-98CD-487A-8455-840B2BE4AC47
Replikationsgruppen-ID: C1D1EBB5-C4C6-43F9-B0F2-619B95A185B5
Das mit dem SRVDC einfach aus der Domäne nehmnen ist so eine Sache, da ich den schon aktiv im gebrauch habe. Ist aber leider auch das erste mal das sowas knallt.
Beim neuen Server im DCDIAG sind nun noch:
Server wird getestet: Default-First-Site-Name\SRVDC2
Starting test: Advertising
Achtung: Bei dem Versuch, SRVDC2 zu erreichen, wurden von DsGetDcName Informationen für \\SRVDC.xxx.local zurückgegeben.
DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
......................... Der Test Advertising für SRVDC2 ist fehlgeschlagen.
und
Starting test: NetLogons
Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\SRVDC2\netlogon)
[SRVDC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten, Der Netzwerkname wurde nicht gefunden..
......................... Der Test NetLogons für SRVDC2 ist fehlgeschlagen.
drinnen.
Lieben Gruss
Aktueller globaler DFSR-Status: "Entfernt".
Erfolgreich aus.
Beim DCDIAG habe ich nur noch die Meldung das es beim replizieren in den letzten 24 Std. Fehler gab. Da habe ich nun im alten Log drinnen:
Der DFS-Replikationsdienst beendet die Kommunikation mit Partner SRVDC2 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen.
Weitere Informationen:
Fehler: 9033 (Die Anforderung wurde durch Herunterfahren abgebrochen.)
Verbindungs-ID: 08BE0AE9-98CD-487A-8455-840B2BE4AC47
Replikationsgruppen-ID: C1D1EBB5-C4C6-43F9-B0F2-619B95A185B5
Das mit dem SRVDC einfach aus der Domäne nehmnen ist so eine Sache, da ich den schon aktiv im gebrauch habe. Ist aber leider auch das erste mal das sowas knallt.
Beim neuen Server im DCDIAG sind nun noch:
Server wird getestet: Default-First-Site-Name\SRVDC2
Starting test: Advertising
Achtung: Bei dem Versuch, SRVDC2 zu erreichen, wurden von DsGetDcName Informationen für \\SRVDC.xxx.local zurückgegeben.
DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
......................... Der Test Advertising für SRVDC2 ist fehlgeschlagen.
und
Starting test: NetLogons
Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\SRVDC2\netlogon)
[SRVDC2] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten, Der Netzwerkname wurde nicht gefunden..
......................... Der Test NetLogons für SRVDC2 ist fehlgeschlagen.
drinnen.
Lieben Gruss
Guten Morgen
Solange der SRVDC noch der Meinung ist, mit dem nicht funktionierenden SRVDC2 replizieren zu wollen, hast Du das noch nicht zum Abschluss gebracht...
Den alten DC sollst Du ja auch nicht aus der Domäne nehmen - wenn Du das machst, hast Du keine Domäne mehr...
Gruß
Zitat von @Hubert.N:
Ich würde erst mal alles auf Ausgangszustand bringen. Also: FSMO-Rollen auf den alten DC und diesen auf Fehler prüfen. Den neuen DC entfernen und erst wenn sichergestellt ist, dass der alte DC sauber läuft die Instalallation starten.
Ich würde erst mal alles auf Ausgangszustand bringen. Also: FSMO-Rollen auf den alten DC und diesen auf Fehler prüfen. Den neuen DC entfernen und erst wenn sichergestellt ist, dass der alte DC sauber läuft die Instalallation starten.
Solange der SRVDC noch der Meinung ist, mit dem nicht funktionierenden SRVDC2 replizieren zu wollen, hast Du das noch nicht zum Abschluss gebracht...
Den alten DC sollst Du ja auch nicht aus der Domäne nehmen - wenn Du das machst, hast Du keine Domäne mehr...
Gruß
Hi,
also ich meinte auch nicht den alten DC sondern den neuen. Der wird aktuell nämlich schon benutzt mit Shares, Drucker etc. das ist gerade mein Problem.
Lieben Gruss
also ich meinte auch nicht den alten DC sondern den neuen. Der wird aktuell nämlich schon benutzt mit Shares, Drucker etc. das ist gerade mein Problem.
Lieben Gruss
Tja was soll ich dazu schreiben...
Wenn Du ein Haus baust und am Fundament was schief läuft, ist es sicherlich nicht die beste Idee, wenn Du schon mal anfängst, das Haus hochzuziehen. Wäre sicherlich besser gewesen, erst einmal zu schauen, dass der DC fehlerfrei läuft, bevor Du anfängst, die Dienste zu verschieben. Aber ich dachte mir ja schon so was in der Richtung., Die FSMOs verschieben sich ja auch nicht von alleine...
Wenn Du den Server halten willst, musst Du halt die Protokolle abarbeiten und den Fehler suchen, finden und dann nur noch beheben ;)
Ich denke halt, mit einer frischen Installation wäre es sicherlich schneller gegangen...
Meine Kristallkugel sagt mir, dass Du vlt. ein Problem im Bereich DFSR hast. Aber das solltest Du halt in den Protokollen sehen können...
Gruß
Wenn Du ein Haus baust und am Fundament was schief läuft, ist es sicherlich nicht die beste Idee, wenn Du schon mal anfängst, das Haus hochzuziehen. Wäre sicherlich besser gewesen, erst einmal zu schauen, dass der DC fehlerfrei läuft, bevor Du anfängst, die Dienste zu verschieben. Aber ich dachte mir ja schon so was in der Richtung., Die FSMOs verschieben sich ja auch nicht von alleine...
Wenn Du den Server halten willst, musst Du halt die Protokolle abarbeiten und den Fehler suchen, finden und dann nur noch beheben ;)
Ich denke halt, mit einer frischen Installation wäre es sicherlich schneller gegangen...
Meine Kristallkugel sagt mir, dass Du vlt. ein Problem im Bereich DFSR hast. Aber das solltest Du halt in den Protokollen sehen können...
Gruß
Hallo zusammen,
ich wollte euch erst einmal Danke sagen für eure Tipps. Am Ende habe ich es nun hinbekommen. Folgender Ansatz war die Lösung:
1. FSMO Rollen wieder zurück auf den alten SRVDC geschoben.
2. DFS Replication Dienst auf SRVDC (alter DC) gestoppt.
3. ADSI Edit aufgemacht und und unter Domain Controllers msDFSR-Enabled auf False gesetzt und msDFSR-Options auf 1.
4. Ebenfalls beim SRVDC2 msDFSR-Enabled auf False gesetzt.
5. Powershell auf SRVDC mit repadmin /syncall / SRVDC /APed ausgeführt und keine Fehler bekommen
6. DFS Replication Dienst auf SRVDC wieder gestartet.
7. Auf SRVDC msDFSR-Enabled auf True gesetzt
8. Powershell auf SRVDC mit repadmin /syncall / SRVDC /APed ausgeführt und keine Fehler bekommen
9. SRVDC auch msDFSR-Enabled auf True gesetzt
10. Invoke-Command -Computername SRVDC, SRVDC2 -ScriptBlock {Stop-Service DFSR} und Invoke-Command -Computername SRVDC, SRVDC2 -ScriptBlock {Start-Service DFSR} ausgeführt.
Das wars
ich wollte euch erst einmal Danke sagen für eure Tipps. Am Ende habe ich es nun hinbekommen. Folgender Ansatz war die Lösung:
1. FSMO Rollen wieder zurück auf den alten SRVDC geschoben.
2. DFS Replication Dienst auf SRVDC (alter DC) gestoppt.
3. ADSI Edit aufgemacht und und unter Domain Controllers msDFSR-Enabled auf False gesetzt und msDFSR-Options auf 1.
4. Ebenfalls beim SRVDC2 msDFSR-Enabled auf False gesetzt.
5. Powershell auf SRVDC mit repadmin /syncall / SRVDC /APed ausgeführt und keine Fehler bekommen
6. DFS Replication Dienst auf SRVDC wieder gestartet.
7. Auf SRVDC msDFSR-Enabled auf True gesetzt
8. Powershell auf SRVDC mit repadmin /syncall / SRVDC /APed ausgeführt und keine Fehler bekommen
9. SRVDC auch msDFSR-Enabled auf True gesetzt
10. Invoke-Command -Computername SRVDC, SRVDC2 -ScriptBlock {Stop-Service DFSR} und Invoke-Command -Computername SRVDC, SRVDC2 -ScriptBlock {Start-Service DFSR} ausgeführt.
Das wars
