Nach Übertr. FSMO-Rollen verbleibt SYSVOL + NETLOGON auf Altsystem

Hallo Leute,

ich habe heute meine FSMO-Rollen von meinem alten 2012 Essentials auf meinen neuen 2019 Essentials übertragen.

Dies wurde auch alles ohne Fehler ausgeführt.

netdom query fsmo

Schemamaster 2019dc.local
Domänennamen-Master 2019dc.local
PDC 2019dc.APD.local
RID-Pool-Manager 2019dc.local
Infrastrukturmaster 2019dc.local
Der Befehl wurde ausgeführt.

Leider ist das SYSVOL + NETLOGON-Share, weiterhin nur auf dem alten Server freigegeben. Gibt es hier noch einen Trick oder habe ich was vergessen?

Die Übertragung der Rollen ist jetzt ~ 20 Minuten her.

Altserver meldet 2213

Vom DFS-Replikationsdienst wurde die Replikation für das Volume "C:" beendet. Dieser Fall tritt ein, wenn eine DFSR-JET-Datenbank nicht ordnungsgemäß heruntergefahren wird und die automatische Wiederherstellung deaktiviert ist.   

Neuserver meldet 4612.

Das riecht irgendwie nach:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/ ...

Vielen Dank für eure Ideen.

Stefan.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3167186436

Url: https://administrator.de/contentid/3167186436

Ausgedruckt am: 22.11.2024 um 12:11 Uhr

9 Kommentare

Neuester Kommentar

Moin

dann hast Du ein ganz anders Problem...

Sysvol und netlogon hat nichts mit den FSMO-Rollen zu tun. Die Freigaben müssen auf jedem DC vorhanden sein.
Anscheinend funktioniert also Dein neuer DC nicht korrekt.

Gruß

Hi,

hatte jetzt im EventLog 2213 im Altsystem gefunden.

Vom DFS-Replikationsdienst wurde die Replikation für das Volume "C:" beendet. Dieser Fall tritt ein, wenn eine DFSR-JET-Datenbank nicht ordnungsgemäß heruntergefahren wird und die automatische Wiederherstellung deaktiviert ist. Sichern Sie zum Beheben dieses Problems die Dateien in den betroffenen replizierten Ordnern, und setzen Sie die Replikation anschließend mithilfe der WMI-Methode "ResumeReplication" fort.   
 
Weitere Informationen: 
Volume: C: 
GUID: 15AD2C61-608B-11E2-93ED-806E6F6E6963 
 
Wiederherstellungsschritte 
1. Sichern Sie die Dateien in allen replizierten Ordnern auf dem Volume. Andernfalls gehen möglicherweise aufgrund einer unerwarteten Konfliktauflösung im Rahmen der Wiederherstellung der replizierten Ordner Daten verloren. 
2. Setzen Sie die Replikation für dieses Volume mithilfe der WMI-Methode "ResumeReplication" der DfsrVolumeConfig-Klasse fort. Geben Sie hierzu an einer Eingabeaufforderung mit erhöhten Rechten beispielsweise den folgenden Befehl ein:   
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="15AD2C61-608B-11E2-93ED-806E6F6E6963" call ResumeReplication   

Jetzt sind die Freigaben da und synchronisiert :D

C:\Users\Administrator>For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\micr  
dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,sta  
SRV01
ReplicatedFolderName  ReplicationGroupName  State
SYSVOL Share          Domain System Volume  4

2019DC
ReplicatedFolderName  ReplicationGroupName  State
SYSVOL Share          Domain System Volume  4

4 = Normal

Na dann stell mal auf gelöst

Frank

Und schon wieder ein Opfer der falschen Root Domain .local!!!

Hinweise zur Verwendung der Domäne .local in DNS und mDNS

Zitat von @148523:
Und schon wieder ein Opfer der falschen Root Domain .local!!!

Hinweise zur Verwendung der Domäne .local in DNS und mDNS

Ich verstehe den Zusammenhang gerade nicht. Was hat die Replikation mit der Domain zu tun?

Zitat von @Hubert.N:

Zitat von @148523:
Und schon wieder ein Opfer der falschen Root Domain .local!!!

Hinweise zur Verwendung der Domäne .local in DNS und mDNS

Ich verstehe den Zusammenhang gerade nicht. Was hat die Replikation mit der Domain zu tun?

Er wollte darauf hinweisen, dass die Domain ".local" nicht exklusiv für private Netze vorgesehen ist und es deshalb u.u. zu Problemen führt. Das ist aber nur zutreffend, wenn tatsächlich hostname.local verwendet wird.

In meinem Fall, hatte ich das nur so anonymisiert. Ich verwende hostname.kundenkuerzel.local, was die Situation entschärft.