Jump to content

Migration W2k auf Srv 2008/Anmeldeserver


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

ich habe ein Problem mit der Migration eines DC von einem Windows 2000 (hps-1)

Server auf einen Windows 2008 Server (hps-2). Der neue Server hat zwar schon

alle FSMO-Rollen, ein Exchange 2007 Server ist auch installiert und

funktioniert. Nur fungiert der neue Server nicht als Anmeldeserver.

Schaltet man den "alten" Server aus, so können sich einige Cleints gar

nicht mehr anmelden, andere haben Probleme beim Zugriff auf

Netzwerklaufwerke. Die Feigaben "netlogon" und "syslog" sind auf dem

neuen Server auch nicht vorhanden.

 

Führt man dcdiag aus fällt als erstes der fehlgeschlagene

Advertising-Test auf:

Starting test: Advertising
  Achtung: Bei dem Versuch, HPS-2 zu erreichen, wurden von DsGetDcName
  Informationen für \\hps-1.cgn.meinedomäne.de zurückgegeben.
  DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
  ......................... HPS-2 hat den Test Advertising nicht
  bestanden.
Starting test: FrsEvent
  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.

 

 

Aufgrund der Meldung über die Fehlgeschlagen Replizierung habe ich mach

Microsofts KBs Artikel auf schon eine manuelle "Replizierung" (kopieren

der Inhalte der ensprechenden Verzeichnisse) druchgeführt - leider ohne

Erfolg.

 

Die Klassiker (falschen (alten) DNS-Server angegeben, nicht zum GC

gemacht) habe ich schon getestet. Stutzig macht mich aber, dass in der

Registry der z.B. im Blog von Yusuf

Yusuf`s Directory - Blog - Globaler Katalog Sein oder nicht sein

beschriebene

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

existiert und den Wert 1 hat, aber ein

nltest /dsgetdc:DOMAINNAME /server:SERVERNAME

folgendes ausgibt:

 

C:\Users\Administrator.CGN>nltest /dsgetdc:cgn.meinedomäne.de /server:HPS-2
    Domänencontroller: \\hps-1.cgn.meinedomäne.de
    Adresse: \\192.168.0.10
    Domänen-GUID: d5258e89-1d5f-4a22-ab10-ae68a7e19adb
    Domänenname: cgn.meinedomäne.de
    Gesamtstrukturname: cgn.meinedomäne.de
    DC-Standortname: Standardname-des-ersten-Standorts
    Unserer Standortname: Standardname-des-ersten-Standorts
       Flags: GC DS LDAP KDC TIMESERV BESCHREIBBAR DNS_DC DNS_DOMAIN 
DNS_FOREST
CLOSE_SITE
Der Befehl wurde ausgeführt.

 

Das lässt mich wieder zweifeln, das der hps-2 wirklich ein DC der Domände ist.

 

Hat jemand eine Idee?

Link zu diesem Kommentar

Ok, also ganz von vorne:

 

1. Auf neuer Hardware Windows Server 2008 aufgesetzt

2. adprep /forestprep auf altem W2k (hps-1) ausgeführt

3. adprep /domainprep /gpprep auf altem W2k (hps-1) ausgeführt

4. Konfigurieren des neuen Servers (hps-2) als DC / Promoten des neuen Server als zusätzlichen DC

5. DNS eingerichtet / Konfiguriert

6. FSMO auf den neuen Server übertragen

7. GC auf 2008 eingerichtet

 

Ich befürchte, das die Beschreibung Kleinigkeiten auslässt, z.B. wurde die Domäne während der Prozedur von mir noch auf nativ gestellt.

Link zu diesem Kommentar

Moin,

 

z.B. wurde die Domäne während der Prozedur von mir noch auf nativ gestellt.

 

wann genau hast du dabei was genau getan?

 

Der Grundablauf sieht erst mal unverdächtig aus. Insbesondere wenn du die FSMO-Rollen erfolgreich online (?) übertragen konntest, tippe ich mal, dass die Fehler erst hinterher entstanden sind.

 

Seit wann bemerkst du denn die angegebenen Probleme? Was gibt das Eventlog her?

 

Gruß, Nils

Link zu diesem Kommentar

Servus Frank,

 

so trifft man sich wieder. ;)

 

 

Nur fungiert der neue Server nicht als Anmeldeserver.

Schaltet man den "alten" Server aus, so können sich einige Cleints gar

nicht mehr anmelden, andere haben Probleme beim Zugriff auf

Netzwerklaufwerke.

 

Bekommen denn die Clients den neuen DC auch als DNS-Server mitgeteilt?

 

Die Feigaben "netlogon" und "syslog" sind auf dem neuen Server auch nicht vorhanden.

 

Dann ist ja bereits beim Heraufstufen etwas schief gelaufen.

Wurde denn der DCPROMO-Vorgang ERFOLGREICH abgeschlossen?

Du könntest mal das DCPROMOUI.LOG kontrollieren.

Yusuf`s Directory - Blog - Debug Protokollierung

 

Im Eventlog müsste ja "Karneval in Rio" sein.

 

 

......................... HPS-2 hat den Test Advertising nicht

bestanden.

 

Der DC kann sich nicht im AD als DC bekannt geben.

Kontrolliere ob z.B. der Anmeldedienst gestartet ist.

 

 

Das lässt mich wieder zweifeln, das der hps-2 wirklich ein DC der Domände ist.

 

Die Ausgabe von NLTEST sieht aber korrekt aus.

Letztenendes ist dein Problem, dass das SYSVOL-Verzeichnis fehlt und evtl. der NETLOGON-Dienst nicht läuft.

Trotz alledem solltest du noch weiter den DC überprüfen, in dem du z.B. kontrollierst ob das userAccountControl-Attribut in den Eigenschaften des DCs den Wert 532480 enthält. Halte dich dazu an diesen Artikel:

 

Domain controller is not functioning correctly

 

Des Weiteren überprüfe auch diesen Artikel:

Troubleshooting missing SYSVOL and NETLOGON shares on Windows 2000 domain controllers

Link zu diesem Kommentar

@yusuf: Entschuldige bitte die PM - das war sicher gedankenlos. Ich kannte dieses Forum noch nicht. Danke!

 

Zu den Logs: Sehr guter Tipp! Im DCPROMO Log sehe ich jetzt nichts, was aufeinen Fehlschlag deutet:

05/16/2008 13:02:33 [iNFO] Die Domänenverzeichnispartition wird repliziert...
05/16/2008 13:02:35 [iNFO] Replikation von DC=cgn,DC=meinedomäne,DC=de: 12955 Objekte von ungefähr 12955 Objekten empfangen.
05/16/2008 13:02:36 [iNFO] Replikation von DC=cgn,DC=meinedomäne,DC=de: 13155 Objekte von ungefähr 13155 Objekten empfangen.
05/16/2008 13:02:36 [iNFO] Cleaning up old Netlogon information
05/16/2008 13:02:37 [iNFO] Stopped the DS
05/16/2008 13:02:37 [iNFO] Der Dienst NTDS wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service NTDS to 16 returned 0
05/16/2008 13:02:37 [iNFO] Der Dienst IsmServ wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service IsmServ to 16 returned 0
05/16/2008 13:02:37 [iNFO] Der Dienst kdc wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service kdc to 16 returned 0
05/16/2008 13:02:37 [iNFO] Der Dienst TrkWks wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service TrkWks to 32 returned 0
05/16/2008 13:02:37 [iNFO] Der Dienst NETLOGON wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service NETLOGON to 144 returned 0
05/16/2008 13:02:37 [iNFO] Der Dienst DFS wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service DFS to 16 returned 0
05/16/2008 13:02:37 [iNFO] Der Dienst NtFrs wird konfiguriert.
05/16/2008 13:02:37 [iNFO] Configuring service NtFrs to 128 returned 0
05/16/2008 13:02:37 [iNFO] DsRolepClearCachedCredentials returns with status 0x00000000, and protocol status is 0x00000000
05/16/2008 13:02:37 [iNFO] Der Domänencontrollervorgang wurde abgeschlossen.
05/16/2008 13:02:37 [iNFO] DsRolepSetOperationDone returned 0

 

Der Anmeldedienst ist gestartet.

 

Der Wert für userAccountControl-Attribut is 532480.

 

Den Artikel "Troubleshooting missing SYSVOL and NETLOGON shares on Windows 2000 domain controllers" hatte ich auch schon gefunden und durchgearbeitet.

 

Um Replizierungsprobleme auszuschließen habe ich den Schritt "How to temporarily stabilize the domain SYSVOL tree" aus

 

How to rebuild the SYSVOL tree and its content in a domain

 

durchgeführt. Danach den Server neu gestartet - ohne Erfolg. (@LukasB: Das meine ich mit manueller Replizierung)

Du könntest mal das DCPROMOUI.LOG kontrollieren.

Das habe ich nun auch gemacht und nichts auffälliges, was auf einen Fehlschlag deutet gefunden.

Link zu diesem Kommentar
@yusuf: Entschuldige bitte die PM - das war sicher gedankenlos.

 

Kein Problem. Ich wußte, dass das Problem nicht mit ein-zwei Sätzen erledigt wäre, daher habe ich dich hierher verwiesen.

So haben dann auch alle etwas davon und können Tipps geben. ;)

 

 

Ich kannte dieses Forum noch nicht. Danke!

 

Na das wurde aber auch mal Zeit. ;)

 

 

Zu den Logs: Sehr guter Tipp! Im DCPROMO Log sehe ich jetzt nichts, was aufeinen Fehlschlag deutet:

 

Du hast jetzt einen kleinen Ausschnitt davon gepostet, der soweit in Ordnung ist.

Wenn der Rest genauso aussieht und kein Eintrag mit FAILED existiert ist das schon mal ok.

 

 

Der Anmeldedienst ist gestartet.

Der Wert für userAccountControl-Attribut is 532480.

 

OK, dann hängt das Problem "nur" am SYSVOL-Verzeichnis.

 

 

Den Artikel "Troubleshooting missing SYSVOL and NETLOGON shares on Windows 2000 domain controllers" hatte ich auch schon gefunden und durchgearbeitet.

 

Du hast also die beiden Registry-Keys D2 und D4 gesetzt und nichts hat sich getan? Im Eventlog stehen garantiert jede Menge Fehler, gehe diesen auch auf der Seite EventID.Net - Troubleshooting information for Windows event logs nach.

Link zu diesem Kommentar

Ich bin doof! (oder unerfahren?!)

Im Eventlog des alten Servers befinden sich die folgenden Einträge, die bis in das Jahr 2005 (kein Witz!) zurück gehen:

Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\winnt\sysvol\domain" in "c:\winnt\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden. 
Folgendes wurde für diesen Replikatssatz ermittelt: 
   "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 

Die Replikatstammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird. 

[1] Bei der ersten Abfrage, die in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatssatz entfernt. 
[2] Bei der darauffolgenden Abfrage wird der Computer dem Replikatssatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort. 

 

Diesen Fehler habe ichversucht, durch das erstellen der genannten Datei an dem genannten Ort zu beheben, was dan allerdings zu diesem Fehler führte:

 

Der Dateireplikationsdienst hat ermittelt, dass der Replikatssatz "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" sich in JRNL_WRAP_ERROR befindet. 

Replikatssatzname      : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 
Replikatstammpfad      : "c:\winnt\sysvol\domain" 
Replikatstammvolume    : "\\.\C:" 
 Ein Replikatssatz stößt auf JRNL_WRAP_ERROR, wenn der Eintrag, von dem gelesen werden soll, nicht vom NTFS-USN-Journal gefunden wird. Mögliche Ursachen hierfür sind: 

[1] Volume "\\.\C:" wurde formatiert. 
[2] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde gelöscht. 
[3] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde abgeschnitten. Chkdsk kann das Journal abschneiden, falls es beschädigte Einträge am Ende des Journals vorfindet. 
[4] Der Dateireplikationsdienst wurde seit längerer Zeit auf diesem Computer nicht ausgeführt. 
[5] Die Rate der Laufwerks-E/A-Aktivität auf "\\.\C:" war zu schnell für den Dateireplikationsdienst. 
Durch Festlegen des Registrierungsparameters "Enable Journal Wrap Automatic Restore" auf 1, werden die folgenden Wiederherstellungsschritte zum automatischen Beheben des Fehlerzustands durchgeführt. 
[1] Beim ersten Poll, der in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatssatz entfernt. Führen Sie "net stop ntfrs" gefolgt von "net start ntfrs" aus, um den Dienst neu zu starten, wenn Sie nicht 5 Minuten warten wollen. 
[2] Beim darauffolgenden Poll wird der Computer dem Replikatssatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. 

...

 

Beide Fehler führen natürlich zu How to rebuild the SYSVOL tree and its content in a domain bzw. zu den von Dir erwähnten setzten der beiden Registry-Keys D2 und D4.

 

Da es aber bisher nur einen DC gab, der offensichtlcih ein Problem hat, bin ich mir nun nicht so sicher, was ich tun soll. Setzte ich nun D4 auf dem alten Server? Hier scheint es doch schon Probleme mit dem Replikatssatz zu geben?! Einen anderen Replikatssatz habe ich aber nicht und ein Backup-Tape von 2005 zu finden ist ausgeschlossen.

Link zu diesem Kommentar

Es ist vollbracht, die Feigaben sysvol und netlogon sind nun auf dem neuen Server verfügbar.

 

Das Problem lag tatsächlich an den auf dem alten Server seit langen vorhandenen Problemen im Dateireplikationsdienst. Nachdem ich die Datei NTFRS_CMD_FILE_MOVE_ROOT in "c:\winnt\sysvol\domain" erstellt und den Dateireplikationsdienst neu gestartet hatte, waren diese (Event-Id: 13559) Probleme im alten Server weg. Dann habe ich analog zu Yusufs Hinweis und der Anleitung aus How to rebuild the SYSVOL tree and its content in a domain die relpica auf dem alten Server authorativ gemacht, den korrespondierenden RegistryKey D2 auf dem neuen Server gesetzt und dann den Dateireplikationsdienst erst auf dem neuen und dann auf dem alten Server neu gestartet - unmittelbar danach waren die Freigaben sysvol und netlogon auch auf dem neuen Server verfügbar und der Advertising Test (dcdiag /test:Advertising) erfolgreich.

Yusuf hat mich mit seinem insistieren auf die Logfile-Kontrolle wieder auf den richtigen Weg gebracht. Das mich (25 Jahren Unix-Systemadmin-Erfahrung) jemand auf das Logfile-lesen hinweisen muss ist schon fast peinlich!

Danke an alle!

Link zu diesem Kommentar
Ich bin doof! (oder unerfahren?!)

 

Das darfst du in der IT-Welt nie zugeben bzw. nie aussprechen.

Man muss immer Ausreden parat haben, die sich verdammt cool anhören. :p

 

 

Im Eventlog des alten Servers befinden sich die folgenden Einträge, die bis in das Jahr 2005 (kein Witz!) zurück gehen:

 

Ohh haa... das ist natürlich sehr ungeschickt.

Achte in der Zukunft darauf. Ich sage immer, SYSVOL-Probleme sind eklige Probleme.

 

 

Das Problem lag tatsächlich an den auf dem alten Server seit langen vorhandenen Problemen im Dateireplikationsdienst.

 

Im nachhinein ist das klar. Wie soll sich denn der neue DC das SYSVOL replizieren, wenn auf dem UrsprungsDC nichts geht.

 

 

Yusuf hat mich mit seinem insistieren auf die Logfile-Kontrolle wieder auf den richtigen Weg gebracht. Das mich (25 Jahren Unix-Systemadmin-Erfahrung) jemand auf das Logfile-lesen hinweisen muss ist schon fast peinlich!

 

Uii... ein Unix-Admin. Dann gibt es zusätzlich einen extra Bonbon für die Windows-Welt. :p

 

Schön das es nun wieder läuft.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...