24
Domaincontroller wechsel nur teilweise erfolgreich
Hallo,
in unseren W2k3 Netzwerk haben wir den DC umziehen müssen. Zunächst haben wir einen 2nd Domaincontroller mit DNS eingerichtet, danach den Betriebsmaster gewechselt und danach die Rolle als PDC vom alten Domaincontroller deinstalliert. Die Domäne an sich funktioniert dahingehen, dass Anmeldungen möglich sind. Die Systemvariable %LOGONSERVER% verweist auch auf den neuen PDC.
Manche Clients versuchen jedoch die Gruppenrichtlinien vom alten PDC zu beziehen und verwenden alte Richtlinien. Über den Befehl nslookup kann ich sehen, dass diese Clients noch den alten Server als PDC verwenden möchten. Ein Netdiag bestätigt das. Der DNS der Clients verweist auf den neuen PDC.
Wie kann ich den Clients mitteilen, wer der neue PDC ist?
Vielen Dank, mexx
in unseren W2k3 Netzwerk haben wir den DC umziehen müssen. Zunächst haben wir einen 2nd Domaincontroller mit DNS eingerichtet, danach den Betriebsmaster gewechselt und danach die Rolle als PDC vom alten Domaincontroller deinstalliert. Die Domäne an sich funktioniert dahingehen, dass Anmeldungen möglich sind. Die Systemvariable %LOGONSERVER% verweist auch auf den neuen PDC.
Manche Clients versuchen jedoch die Gruppenrichtlinien vom alten PDC zu beziehen und verwenden alte Richtlinien. Über den Befehl nslookup kann ich sehen, dass diese Clients noch den alten Server als PDC verwenden möchten. Ein Netdiag bestätigt das. Der DNS der Clients verweist auf den neuen PDC.
Wie kann ich den Clients mitteilen, wer der neue PDC ist?
Vielen Dank, mexx
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: 158346
Url: https://administrator.de/forum/domaincontroller-wechsel-nur-teilweise-erfolgreich-158346.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
24 Kommentare
Neuester Kommentar
Hi mexx,
sofern die IP-Settings stimmen, müsste doch ein "gpupdate /force" auf den Clients diese dazu zwingen sich die neuen Richtlinien auch vom neuen Server zu holen.
Probier das mal bitte aus.
sofern die IP-Settings stimmen, müsste doch ein "gpupdate /force" auf den Clients diese dazu zwingen sich die neuen Richtlinien auch vom neuen Server zu holen.
Probier das mal bitte aus.
Weder ein gpupdate /force noch ein gpupdate /sync funktioniert. Force bricht nach Timeout ab. Lange Zeit passiert nix und dann bricht er wegen Zeitüberschreitung ab. Sync versucht vom alten PDC zu beziehen. Im Ereignisprotokoll ist zu lesen, dass der Domaincontroller nicht gefunden wurde.
Die IP Settings erachte ich als korrekt, wenn der DNS auf den neuen Domaincontroller verweist, der ja auch DNS macht.
Die IP Settings erachte ich als korrekt, wenn der DNS auf den neuen Domaincontroller verweist, der ja auch DNS macht.
Hallo mexx,
habt ihr denn die schon mal kontrolliert ob die FSMO Rollen übertragen wurden?
es müssen alle Rollen übertragen werden, damit der neue DC einwandfrei arbeiten kann.
schau mal hier: http://support.microsoft.com/kb/255504/de
habt ihr denn die schon mal kontrolliert ob die FSMO Rollen übertragen wurden?
es müssen alle Rollen übertragen werden, damit der neue DC einwandfrei arbeiten kann.
schau mal hier: http://support.microsoft.com/kb/255504/de
Ich kann bestätigen, dass der neue DC Schemamaster, RID, PDC und Infrastruktur Rollen trägt. Bei Domänennamen-Master bin ich mir nicht sicher, wo ich das auslesen kann. Die in den Link beschrieben Vorgehensweise wurde so nicht umgesetzt, aber über dcpromo habe ich die Rolle des alten PDC als Domaincontroller deinstalliert. Wo kann ich die Rollen des neuen DC auslesen?
Hier mal noch ein paar Hinweise bzgl. des Fehlverhaltens an den Client.
Ein Ping auf den Domainnamen.intern bringt nichts. Der Name kann nicht aufgelöst werden, obwohl die DNS Konfiguration am Client stimmt und der DNS Eintrag auf den DC ist ebenfalls korrekt.
nslookup verweist ebenfalls noch auf den alten PDC
Ein Ping auf den Domainnamen.intern bringt nichts. Der Name kann nicht aufgelöst werden, obwohl die DNS Konfiguration am Client stimmt und der DNS Eintrag auf den DC ist ebenfalls korrekt.
nslookup verweist ebenfalls noch auf den alten PDC
Wie schaut's mit den Forward-Lookupzoneneinträgen aus bei DNS?
das hört sich sehr stark nach DNS Problem an! Was bekommt man denn für Antworten wenn man vom neuen DC
nslookup ausführt?
Es könnte auch am Globalen Katalog Server liegen. In den Standorten und Diensten in den NTDS einstellungen bitte mal
kontrollieren ob der neue Server "Katalog-Server" auch ist.
FSMO-Rollen lassen sich über "netdom query fsmo" auslesen netdom ist in den Support Tools zu finden.
nslookup ausführt?
Es könnte auch am Globalen Katalog Server liegen. In den Standorten und Diensten in den NTDS einstellungen bitte mal
kontrollieren ob der neue Server "Katalog-Server" auch ist.
FSMO-Rollen lassen sich über "netdom query fsmo" auslesen netdom ist in den Support Tools zu finden.
Führe ich am DC nslookup aus, erhalte ich den DC und dessen IP als Antwort.
Der neue DC ist Globaler Katalog Server
netdom query fsmo liefer in allen Rollen den neuen DC aus.
Der Zustand ist mir so unklar. Der DC stellt sich völig korrekt dar, aber die Clients scheinen von dem Wechsel nichts zu wissen. Ich bin nach wie vor, für jeden Tipp dankbar!!
Der neue DC ist Globaler Katalog Server
netdom query fsmo liefer in allen Rollen den neuen DC aus.
Der Zustand ist mir so unklar. Der DC stellt sich völig korrekt dar, aber die Clients scheinen von dem Wechsel nichts zu wissen. Ich bin nach wie vor, für jeden Tipp dankbar!!
Ich würde mal sagen korrekt. Der neue DC02 wird als Domaincontroller angezeigt, der alte wurde entfernt. Worauf sollte ich denn explizit achten?
Hi.
Und, was sagt dann netdom query fsmo? Wenn du nämlich tatsächlich so wie im Eingangspost beschrieben vorgegangen bist, dann fehlen dir einige Schritte
LG Günther
Ich bin nach wie vor, für jeden Tipp dankbar!!
Und, was sagt dann netdom query fsmo? Wenn du nämlich tatsächlich so wie im Eingangspost beschrieben vorgegangen bist, dann fehlen dir einige Schritte
LG Günther
Hinweis: Wen ich neue Rechner in die Domäne aufnehme, funktioniert alles bestens. Nur die alten verstehen es nicht. Sie aus der Domäne entnehmen und wieder rein nehmen funktioniert zwar, aber sie suchen die Richtlinien nach wie vor auf den alten PDC. Als ob im neuen PDC Verweise auf den alten sind.
gibt es nach der Anmeldung eines Clients Fehler in den Ereignissanzeige des Clients "Userenv" Fehler oder "Netlogon" Fehler? wenn ja bitte mal posten.
Zitat von @GuentherH:
Hi.
> Ich bin nach wie vor, für jeden Tipp dankbar!!
Und, was sagt dann netdom query fsmo? Wenn du nämlich tatsächlich so wie im Eingangspost beschrieben vorgegangen bist,
dann fehlen dir einige Schritte
LG Günther
Hi.
> Ich bin nach wie vor, für jeden Tipp dankbar!!
Und, was sagt dann netdom query fsmo? Wenn du nämlich tatsächlich so wie im Eingangspost beschrieben vorgegangen bist,
dann fehlen dir einige Schritte
LG Günther
netdom query fsmo liefert in allen Rollen den neuen DC aus.
Hinweis:
Da die Clients ja alte Richtlinien verwenden, wollen Sie auch ein Loginscript starten, dass auf dem alten PDC lag. Den neuen Pfad wollen sie ja nicht ziehen. Um zu prüfen, welche Clients nun die aktuellen Richtlinien inkl. neuen Pfad des Loginscripts ziehen, habe ich den alten Pfad künstlich erzeugt. Somit wird definitiv das Script ausgeführt, jedoch mit einen Unterschied. Ich schreibe in den beiden Scripten Loginfiles an nun unterschiedlichen Orten. Das merkwürdige ist nun, dass die Clients mal das alte und mal das neue Script laden. Als ob beim Connect mit dem neuen PDC ein Verweis auf den alten mitkommt und kurze Zeit später wieder auf den neuen verweist.
Da die Clients ja alte Richtlinien verwenden, wollen Sie auch ein Loginscript starten, dass auf dem alten PDC lag. Den neuen Pfad wollen sie ja nicht ziehen. Um zu prüfen, welche Clients nun die aktuellen Richtlinien inkl. neuen Pfad des Loginscripts ziehen, habe ich den alten Pfad künstlich erzeugt. Somit wird definitiv das Script ausgeführt, jedoch mit einen Unterschied. Ich schreibe in den beiden Scripten Loginfiles an nun unterschiedlichen Orten. Das merkwürdige ist nun, dass die Clients mal das alte und mal das neue Script laden. Als ob beim Connect mit dem neuen PDC ein Verweis auf den alten mitkommt und kurze Zeit später wieder auf den neuen verweist.
Zitat von @schober:
gibt es nach der Anmeldung eines Clients Fehler in den Ereignissanzeige des Clients "Userenv" Fehler oder
"Netlogon" Fehler? wenn ja bitte mal posten.
gibt es nach der Anmeldung eines Clients Fehler in den Ereignissanzeige des Clients "Userenv" Fehler oder
"Netlogon" Fehler? wenn ja bitte mal posten.
Quelle: Userenv
Kennung: 1517
Die Registrierung des Benutzers "Domainname/benutzername" wurde gespeichert, obwohl eine Anwendung oder ein Dienst auf die Registrierung während der Abmeldung zugegriffen hat. Der von der Registrierung des Benutzers verwendete Speicher wurde nicht freigegeben. Der Upload der Registrierung wird durchgeführt, wenn diese nicht mehr verwendet wird.
Dies wird oft durch Dienste verursacht, die unter einem Benutzerkonto ausgeführt werden. Versuchen Sie diese so zu Konfigurieren, dass sie unter den Konten "Lokaler Dienst" oder "Netzwerkdienst" ausgeführt werden.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie
Quelle: Userenv
Kennung: 1085
Die clientseitige Erweiterung Internet Explorer Zonemapping der Gruppenrichtlinien konnte nicht ausgeführt werden. Überprüfen Sie, ob diese Erweiterung bereits früher Fehler verursacht hat.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.
was lifert denn ein Client bei "gpresult"? Zumindest das sollte dir ja einen Anhaltspunkt geben.
Er läd Richtlinien, die richtigen was den Namen betrifft, aber sie beinhalten die falschen Einstellungen. Ich kann nicht sagen woher. Auch wenn ich vom Server aus einen Richtlinienergebnisssatz lese, sehe ich, dass er alte Richtlinien verwendet. Das verhalten ist nach jeden Neustart anders. Fast schon abwechselnd. Mal läd er das richtige, mal nur teilweise, mal läd er komplett das falsche. Dann mal wieder ein paar Handgriffe mit ipconfig /flushdns, ein gpupdate /sync, 1-2 mal neustarten und als User anmelden und es stimmt wieder. Dann noch mal neustarten und es ist wieder der alte PDC der Zielserver. Wo holt der sich nur die Information her? Gibt es nicht ein Tool mit dem man den Clients sagen kann, wer nun der PDC ist?
Hier eine Meldung vom neuen DC:
Während der letzten 4,13 Stunden gab es 33 Verbindungen zu diesem Domänen- controller von Clientcomputern, deren IP-Adressen keinem existierenden Standort in der Organisation zugeordnet werden können. Diese Clients haben demzufolge undefinierte Standorte und können sich mit jedem Domänencontroller, einschließlich solcher, die weit von den Clients entfernt sind, verbinden. Der Standort eines Clients wird bestimmt durch die Zuordnung seines Subnetzes zu einem existierenden Standort. Erstellen Sie Subnetzobjekte, die die oben angegeben IP-Adressen abdecken und die einem existierenden Standort zugeordnet sind, um die oben angegebenen Client einem der Standort zuzuordnen. Die Namen und IP-Adressen der betroffenen Clients sind auf diesem Computer in der folgenden Protokolldatei protokolliert: "%SystemRoot%\debug\netlogon.log" und möglicherweise auch in der Protokoll- datei "%SystemRoot%\debug\netlogon.bak", die erstellt wird, falls die erste Datei voll sein sollte. Die Protokoller enthalten möglicherweise zusätzliche Debuginformationen. Suchen Sie nach Zeilen, die folgenden Text enthalten: "NO_CLIENT_SITE:", um die erforderlichen Informationen herauszufiltern. Das erste Wort, das auf dieser Zeichenkette folgt, ist der Clientname und das zweite Wort ist die IP-Adresse des Clients. Die maximale Größe der Protokolle wird durch folgenden DWORD-Wert in der Registrierung festgelegt: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize". Der Standardwert beträgt 20000000 Bytes. Die aktuelle maximale Größe beträgt 20000000 Bytes. Erstellen Sie den obigen Registrierungswert, und legen Sie gewünschte maximale Größe in Bytes fest, um die maximale Größe zu verändern.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie
Während der letzten 4,13 Stunden gab es 33 Verbindungen zu diesem Domänen- controller von Clientcomputern, deren IP-Adressen keinem existierenden Standort in der Organisation zugeordnet werden können. Diese Clients haben demzufolge undefinierte Standorte und können sich mit jedem Domänencontroller, einschließlich solcher, die weit von den Clients entfernt sind, verbinden. Der Standort eines Clients wird bestimmt durch die Zuordnung seines Subnetzes zu einem existierenden Standort. Erstellen Sie Subnetzobjekte, die die oben angegeben IP-Adressen abdecken und die einem existierenden Standort zugeordnet sind, um die oben angegebenen Client einem der Standort zuzuordnen. Die Namen und IP-Adressen der betroffenen Clients sind auf diesem Computer in der folgenden Protokolldatei protokolliert: "%SystemRoot%\debug\netlogon.log" und möglicherweise auch in der Protokoll- datei "%SystemRoot%\debug\netlogon.bak", die erstellt wird, falls die erste Datei voll sein sollte. Die Protokoller enthalten möglicherweise zusätzliche Debuginformationen. Suchen Sie nach Zeilen, die folgenden Text enthalten: "NO_CLIENT_SITE:", um die erforderlichen Informationen herauszufiltern. Das erste Wort, das auf dieser Zeichenkette folgt, ist der Clientname und das zweite Wort ist die IP-Adresse des Clients. Die maximale Größe der Protokolle wird durch folgenden DWORD-Wert in der Registrierung festgelegt: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize". Der Standardwert beträgt 20000000 Bytes. Die aktuelle maximale Größe beträgt 20000000 Bytes. Erstellen Sie den obigen Registrierungswert, und legen Sie gewünschte maximale Größe in Bytes fest, um die maximale Größe zu verändern.
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie
den PDC kann man über "set" ändern, ist ja auch nur eine Variable im Windows.
Hinweis:
In der Reverse-Lookupzone des Subnetzes tauchen nicht alle Clients auf. Speziell die Fehlerclients. Warum?
In der Reverse-Lookupzone des Subnetzes tauchen nicht alle Clients auf. Speziell die Fehlerclients. Warum?
Ich kenne nur die Systemvariable %LOGONSERVER% und die trägt bereits den Namen des richtigen PDCs.
Hinweis: Die Clients (selbst neuinstallierte) ziehen mit jeden Neustart unterschiedliche Revisionen von GPOs bis Sie einen Stand erreichen, wo sie mit nslookup wieder auf den alten DC verweisen und keine Richtlinien mehr ziehen können, weil sie dort ja nichts finden. Kann damit jemand was anfangen?
WICHTIGER HINWEIS:
Wir haben 2 weitere Standorte.
1. Die Replikation scheint nicht zu funktionieren, weil ich beim Aufruf des Pfades \\Standortdomaincontroller\sysvol\domain.intern\Policies alte Einträge drin stehen
2. Die Clients im Hauptstandort ziehen willkürlich die Richtlinien aus den anderen Standorten, welche ja zusätzlich noch veraltet sind. Ein Ping von den Clients im Hauptstandort verweist auf den DC im Hauptstandort, aber ein Aufruf des Freigabenamens \\Domain.intern landet willkürlich auf einen anderen Standort. Wo wird entschieden, welcher Client welchen DC per \\Domain.intern anspricht?
Wir haben 2 weitere Standorte.
1. Die Replikation scheint nicht zu funktionieren, weil ich beim Aufruf des Pfades \\Standortdomaincontroller\sysvol\domain.intern\Policies alte Einträge drin stehen
2. Die Clients im Hauptstandort ziehen willkürlich die Richtlinien aus den anderen Standorten, welche ja zusätzlich noch veraltet sind. Ein Ping von den Clients im Hauptstandort verweist auf den DC im Hauptstandort, aber ein Aufruf des Freigabenamens \\Domain.intern landet willkürlich auf einen anderen Standort. Wo wird entschieden, welcher Client welchen DC per \\Domain.intern anspricht?
Lösung gefunden:
1. Im DNS stand noch der alte DC als DC drin.
2. Die Replikation war defekt und die Clients haben mit unter alte Richtlinien von den DCs der anderen Standorte gezogen.
1. Im DNS stand noch der alte DC als DC drin.
2. Die Replikation war defekt und die Clients haben mit unter alte Richtlinien von den DCs der anderen Standorte gezogen.
