Server 2000 DC umbenannt - wie Probleme beheben?

[Whistleblower 45]

Hi,

 

schlage mich schon seit längerem mit einem scheinbar inkonsistenten ADS auf einem Server2003 DC herum.

Mittlerweile weiss ich mehr über die Vorgeschichte des Server und somit über die potentiellen Ursachen des Problems.

Der Server läuft aktuell mit Server2003 Std, war früher aber ein 2000 Server.

Zu 2000-Zeiten hat mein Vorgänger sowohl Server als auch Domäne umbenannt.

Jetzt konnte ich der Domäne zwar einen weiteren DC hinzufügen, aber nicht erfolgreich alle Rollen übertragen, außerdem kann ich den neu hinzugefügen DC nicht wieder herunterstufen. Laut Ereignisprotokoll antwortet (u.a.) wohl der RPC-Dienst auf dem alten DC nicht.

Der komplette thread zu dem Thema findet sich schon hier.

 

Meine Frage ist jetzt, ob es überhaupt noch eine Möglichkeit gibt, den Server soweit gerade zu ziehen, dass ein neuer DC mit dem aktuellen Domänennamen in Betrieb gehen kann.

Ich investiere gerne noch etwas Gehirnschmalz in die Fehlersuche und -behebung statt gleich eine neue Domäne parallel aufzuziehen, aber wenn die Chancen eh gegen null gehen, wird wohl kein Weg daran vorbeiführen... :(

 

Bin für jeden Tipp dankbar !!!

[Daim 12]

Servus,

 

Zu 2000-Zeiten hat mein Vorgänger sowohl Server als auch Domäne umbenannt.

 

einen DC kann man unter Windows 2000 aber nur dann umbenennen, wenn der DC VORHER heruntergestuft wird. Also DC herutnerstufen, Server umbenennen und anschließend wieder zum DC hochstufen. Die Domäne konnte man unter Windows 2000 auch nicht so einfach umbenennen. Dazu muss man die Domäne neu aufsetzen. Wenn die Domöne aber nur durch einem DC bestand, dann kann man beides in "einem Rutsch" durchführen.

 

 

Jetzt konnte ich der Domäne zwar einen weiteren DC hinzufügen, aber nicht erfolgreich alle Rollen übertragen,

 

Du konntest nicht alle Rollen übertragen, aber einen Teil von den fünf Rollen?

Wie lautete die Fehlermeldung?

 

 

außerdem kann ich den neu hinzugefügen DC nicht wieder herunterstufen. Laut Ereignisprotokoll antwortet (u.a.) wohl der RPC-Dienst auf dem alten DC nicht.

 

Dann führe doch auf beiden DCs das DCDIAG sowie NetDIAG aus den Windows Support Tools aus. Das DNS ist in einer AD-Umgebung elementar, werfe auch darauf einen Blick. Auf dem neuen DC hast du noch den alten DC als primären DNS-Server eingetragen?

 

DCDiag and NetDiag in Windows 2000 Facilitate Domain Join and DC Creation

Windows Server 2003 Service Pack 1 Support Tools

Download details: Windows Server 2003 Service Pack 2 32-bit Support Tools

 

 

Meine Frage ist jetzt, ob es überhaupt noch eine Möglichkeit gibt, den Server soweit gerade zu ziehen, dass ein neuer DC mit dem aktuellen Domänennamen in Betrieb gehen kann.

 

Mit Know-How, Zeit und Troubleshooting sicherlich. Ob man das alles selbst kann, ist eine andere Frage. Deine bestehenden Probleme lassen sich auch schwer über ein Forum lösen. Evtl. solltest du über einen Dienstleister nachdenken.

 

 

Ich investiere gerne noch etwas Gehirnschmalz in die Fehlersuche und -behebung statt gleich eine neue Domäne parallel aufzuziehen, aber wenn die Chancen eh gegen null gehen, wird wohl kein Weg daran vorbeiführen...

 

Das gilt es eben abzuschätzen, ob die Fehlersuche selbst in adäquater Zeit gelöst werden kann oder das neuaufsetzen der Domäne, der schnellere Weg ist.

[Whistleblower 45]

einen DC kann man unter Windows 2000 aber nur dann umbenennen, wenn der DC VORHER heruntergestuft wird. Also DC herutnerstufen, Server umbenennen und anschließend wieder zum DC hochstufen. Die Domäne konnte man unter Windows 2000 auch nicht so einfach umbenennen. Dazu muss man die Domäne neu aufsetzen. Wenn die Domöne aber nur durch einem DC bestand, dann kann man beides in "einem Rutsch" durchführen.

In welcher Form das damals geschah, kann leider keiner mehr nachvollziehen. Bekannt ist nur, das der Server einen anderen Namen hatte und die Domäne ebenfalls anders benannt war. Reste davon fanden sich u.a. noch unter Standorte und tw. im DNS.

Bekannt ist auch noch, dass es bei der späteren Schemaerweiterung für Exchange (bereits zu 2003-Zeiten) diesbezüglich noch Probleme gab. Ein MS-Techniker, der das ganze damals wohl betreute, meinte auch, dass wir wohl immer mit Problemen aufgrund der damaligen Umbenennung rechnen müssten...

 

Dann führe doch auf beiden DCs das DCDIAG sowie NetDIAG aus den Windows Support Tools aus. Das DNS ist in einer AD-Umgebung elementar, werfe auch darauf einen Blick. Auf dem neuen DC hast du noch den alten DC als primären DNS-Server eingetragen?

Habe ich gemacht, habe auch einiges (im alten Thread) klären können, aber irgendwo muss noch ein Problem bestehen. Ich füge die Ergebnisse gleich nochmal an.

Auf dem neuen DC ist der alte als primäre DNS eingetragen.

 

Mit Know-How, Zeit und Troubleshooting sicherlich. Ob man das alles selbst kann, ist eine andere Frage. Deine bestehenden Probleme lassen sich auch schwer über ein Forum lösen. Evtl. solltest du über einen Dienstleister nachdenken.

Den Ehrgeiz habe ich (noch) selber - man lernt dadurch besser als durch ausschalten und neuaufsetzen :D

MCSA/MCSE steht als Fernziel bei mir ja auch noch auf dem Plan...

Dienstleister kommt nicht in Frage, evtl. werde ich direkt auf Microsoft zurückgreifen, wenn alle Stricke reissen. Ist ja nicht so, dass der Betrieb momentan eingeschränkt wär - aber zu dem Thema kämen wir bei Ausfall des DCs... :(

[Steven2007 10]

Hallo BNice,

 

also wenn du dir nicht 100% sicher bist, was du tust, würde ich wirklich die Domäne neu aufsetzen, wenn es vom Aufwand her vertretbar ist. Du kannst das ja, wie du schon sagtest, parallel auf nem zweiten Server machen, z.B. deinem jetzigen 2. DC

 

Mein Tip: Lieber ein schreckliches Ende, als ein Schrecken ohne Ende!

 

Mein Vorgehen wäre so:

Images von beiden Servern machen

VM des FSMO Masters ziehen

2. DC aus der Domäne entfernen (falls du keinen weiteren "freien" Server hast)

Auf zweitem DC (falls du keinen weiteren "freien" Server hast, falls doch nimm natürlich den) die Domäne neu hochziehen

Benutzer, Daten, Anwendungen migrieren

 

Wenn du Lust hast kannst du ja dann mit der VM deines alten Servers testen/troubleshooten. In der Produktivumgebung würde ich das, wenn ich mir nicht ganz arg sicher wäre, nicht.

 

Du kannst auch noch Einstellungen von Anwendungen oder des Betriebssystems aus der VM auslesen, somit hast du immer einen kleinen "Spickzettel", falls die Doku nicht so besonders ausführlich sein sollte ^^

 

Beste Grüße,

 

Steven

[Whistleblower 45]

Hi Steven,

 

paralleles Aufsetzen einer neuen Domäne war anfangs auch mein Favorit.

Habe dann allerdings (aufgrund der anschließend notwendigen Wiederherstellung der lokal gespeicherten User-Profile) die erwähnten Versuche unternommen, in die alte Domäne einen zweiten DC zu bekommen.

 

Grundsätzlich sehe ich auch kein großes Problem in einer neuen Domäne, da wir bis jetzt wirklich nur die Basics des ADS nutzen, sprich zentrale Benutzerverwaltung und einige Richtlinien.

Nur das Übertragen der Profile auf den Clients wird mit einiger Fleißarbeit verbunden sein, und da kenne ich bisher noch keine Lösung, die mir die Arbeit deutlich vereinfacht... :(

Von jedem PC die lokal gespeicherten Profile sichern und nach Umzug in die neue Domäne wieder herstellen wird sicher nicht bei jedem User problemlos funktionieren...

[Christoph35 10]

Schau Dir mal das USMT an. AFAIK unterstützt das auch Interdomain Scenarios:

 

User State Migration Tool 3.0

 

Christoph

[Whistleblower 45]

Hm, stimmt, das werde ich mir mal näher anschauen und mit einem Client testen. Danke erstmal für den Tip!!

[Steven2007 10]

Hallo Bnice,

 

schau mal hier:

 

USMT domain to domain question? - Windows Deployment

 

Bei der Gelegenheit würde ich dann auch gleich Servergespeicherte Profile implementieren.

 

Gruß,

 

Steven

[Whistleblower 45]

Hallo Bnice,

 

Bei der Gelegenheit würde ich dann auch gleich Servergespeicherte Profile implementieren.

 

Hm, mit servergespeicherten Profile haben wir bisher nicht so gute Erfahrungen gemacht, evtl. aufgrund der bisherigen ADS-Probleme, zum anderen aber auch dadurch, dass dann wieder viele Feinheiten wie beispielsweise Speicherort von Outlook pst usw anzupassen sind ... Überlegt habe ich es auch schon öfters, aber es gab bisher immer zuviele Stolperfallen in der Praxis. Beispielsweise auch, dass ich (zum jetzigen Zeitpunkt mit nur einem DC) Ausnahmen für unseren zweiten Standort definieren müsste. Zukünftig soll dort auch ein DC stehen, bevorzugt mit R2 und erweitertem DFS...

[Steven2007 10]

Hallo,

 

die Outlook PST sollte eigentlich nur lokal auf dem Client liegen bleiben - d.h. sie liegen nie auf dem Server (auch bei Servergespeicherten Profilen nicht).

Falls jemand Outlook ohne Exchange nutzt, lege ich die PST Files aber eh immer auf dem Server auf ein seperates Share, ist einfach sicherer und man muss nichts synchronisieren.

Beispielsweise auch, dass ich (zum jetzigen Zeitpunkt mit nur einem DC) Ausnahmen für unseren zweiten Standort definieren müsste

Verstehe ich nicht, hat das was mit deinem DFS-Tree zu tun?

R2 oder nicht R2 ist deiner Domäne (bis aufs neue Schema) und damit auch deinen Profilen, egal.

Mit DFS kenne ich mich nicht aus.

 

Gruß,

 

Steven