odeutschbein 10 Geschrieben 3. Juni 2008 Melden Teilen Geschrieben 3. Juni 2008 Guten Tag liebe Experten, W2003 Netzwerk / W2003 Server Standard nun ist es bald soweit ! Mein Primay Domain Controller soll aus dem AD herausgenommen werden und durch einen neuen DC ersetzt werden. Folgende Tätigkeiten sind bereits erledigt: 1. DNS läuft auf neuem DC - alle Server / Clients schauen & fragen den neuen DNS ab 2. DHCP ist auf neuem DC aktiviert - Clients bekommen Config vom neuen DHCP 3. Neuer DC ist zusätzlich zum alten DC von mir zum Catalog Server gemacht worden Eigentlich sieht jetzt alles OK aus. Nun habe ich noch Bauchschmerzen mit der Übertragung der Rollen. Kann ich das Ganze in Ruhe angehen und was muß ich beachten ?? Ich wollte jetzt eigentlich alle 5 FSMO's auf den neuen DC moven !! Ist hier eine spezielle Reihenfolge zu beachten ! Kann ich das wärend des Betriebes machen ? Bekommen die Benutzer etwas davon mit ?? Wenn die Rollen dann übertragen sind kann ich doch den alten Server per DCPromo aus dem AD herausnehmen oder ? Muss der alte DC sofort aus dem AD herausgenommen / herabgestuft werden ?? Danach können sich die Clients dann normal über den neuen DC einloggen oder habe ich da noch etwas zu beachten ? Ach, kleines Problem noch mit WINS !! Läuft bei mir noch auf dem alten DC !! Muss ja auch noch rüber auf den neuen aber wie ?? Gibt es einen Befehl mit dem ich die ipconfig von einem entfernten Client abfragen kann ? Zum Test ob auch wirklich alle IP settings auf dem Client auf die neue Server Config verweisen ? Sory, aber ist mein erster DC Tausch in einer aktiven Umgebung deswegen auch meine Sorgen. Vielen Dank im Voraus. Gruß Olli Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 3. Juni 2008 Melden Teilen Geschrieben 3. Juni 2008 Salut, Ich wollte jetzt eigentlich alle 5 FSMO's auf den neuen DC moven !! Ist hier eine spezielle Reihenfolge zu beachten ! Kann ich das wärend des Betriebes machen ? Bekommen die Benutzer etwas davon mit ?? das verschieben der FSMO-Rollen geht schnell und schmerzlos. Die Benutzer bekommen von diesem Vorgang nichts mit und du kannst das während dem Betrieb durchführen. Lies dir dazu bitte KOMPLETT diesen Artikel durch, denn dann erfährst du, was für die Durchführung dieser Tätigkeit zu beachten ist: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Wenn die Rollen dann übertragen sind kann ich doch den alten Server per DCPromo aus dem AD herausnehmen oder ? Muss der alte DC sofort aus dem AD herausgenommen / herabgestuft werden ?? Du kannst den DC wenn alle Daten sowie Dienste auf dem anderen DC verschoben wurden, irgendwann mit DCPROMO aus der Domäne nehmen. Aber bevor du das tust, solltest du zumindest noch das EFS-Zertifikat sichern, wenn es der allererste DC in der Domäne sein sollte. Beachte dazu diesen und die weiterführenden Artikeln: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Danach können sich die Clients dann normal über den neuen DC einloggen oder habe ich da noch etwas zu beachten ? Genau so ist es. Wichtig ist eben, dass auf dem neuen DC sich bereits die DNS-Informationen repliziert haben und den Clients dieser DC als DNS-Server bekannt ist. Zu Testzwecken könntest du ja bevor du den DC herutnerstufst erstmal ausschalten und schauen ob alles so funktioniert wie du es dir vorstellst. Danach kannst du den DC immer noch herunterstufen. Ach, kleines Problem noch mit WINS !! Läuft bei mir noch auf dem alten DC !! Muss ja auch noch rüber auf den neuen aber wie ?? Bemühe doch dazu die Sichmasvhine deines Vertrauen. Da gibt es einige Links dazu. Dieser hier z.B. ist zwar für NT, sollte aber auch weiterhin seine Gültigkeit haben: How to Move a WINS Database to Another Server Gibt es einen Befehl mit dem ich die ipconfig von einem entfernten Client abfragen kann ? Zum Test ob auch wirklich alle IP settings auf dem Client auf die neue Server Config verweisen ? Mit PSEXEC z.B.: PsExec v1.92 Abgesehen davon, wenn du den alten DC zwei Wochen aus hast, wirst du schon merken welche IP-Informationen die Clients haben. ;) Zitieren Link zu diesem Kommentar
odeutschbein 10 Geschrieben 3. Juni 2008 Autor Melden Teilen Geschrieben 3. Juni 2008 Hi Yusuf, respekt !! Vielen, vielen Dank für deine tollen Beiträge und für deine immer sehr wertvolle Unterstützung. Ich kann Also Einfach den alten DC auschalten ? Ich dachte, das ich da mal etwas gehört habe, dass der alte DC nach dem übertragen der Rollen nie wieder in die Domaine gestartet werden darf, bevor er nicht komplett neu aufgesetzt wurde ?? Danke & Gruß Olli Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 3. Juni 2008 Melden Teilen Geschrieben 3. Juni 2008 respekt !! Vielen, vielen Dank für deine tollen Beiträge und für deine immer sehr wertvolle Unterstützung. Uii... ich bedanke mich sehr für das Lob. :) Ich kann Also Einfach den alten DC auschalten ? Na klar. Ich dachte, das ich da mal etwas gehört habe, dass der alte DC nach dem übertragen der Rollen nie wieder in die Domaine gestartet werden darf, bevor er nicht komplett neu aufgesetzt wurde ?? Fast richtig. ;) Wenn du die FSMO-Rollen "mit Gewalt" verschieben würdest, dann dürfte der Ursprungsträger der FSMO-Rollen nie mehr online gehen. Mit Gewalt bedeutet, der DC der die FSMO-Rollen inne hatte ist gecrasht. Die Rollen müssen aber ja trotzdem wieder in der Domäne verfügbar sein, denn ansonsten müsste man die Domäne neu aufsetzen, um die FSMO-Rollen wieder zu bekommen. Daher muss es natürlich auch in solch einem Fall (DC-Crash) die Möglichkeit geben, trotzdem die Rollen zu verschieben. In solche einem Fall kannst du die Rollen auch über die GUI auf einen anderen DC übertragen, obwohl der Ursprungsträger nicht mehr online ist. Dann werden die Rollen eben mit Gewalt verschoben. Du kannst zwar die Rollen über die GUI verschieben, aber den RID-Master MUSST Du zwingend in der Kommandozeile mit NTDSUTIL - SEIZE übertragen, dieser lässt sich nicht durch die GUI verschieben. Du kannst aber auch alle FSMO-Rollen mit NTDSUTIL verschieben. Der Befehl den du dazu benötigst, lautet: NTDSUTIL - TRANSFER. Warum darf nun der Ursprungsrollenträger nie mehr online gehen? Ganz einfach, er bekommt von dieser Aktion in solch einem Fall doch nichts mit. Also, der Ursprungsträger ist - warum auch immer - gecrasht, dann wurden die Rollen "mit Gewalt" auf einen anderen DC verschoben. Ein Kollege hat aber den gecrashten DC repariert (weil nur der CPU-Lüfter defekt war, hat er den Lüfter ausgetauscht). Du fährst der gecrashten DC wieder hoch... und was für einen Zustand hätte man dann? Richtig, es existieren nun zwei DCs die beide ALLE Rollen haben. Jede Rolle existiert nun zwei Mal in der Domäne und das darf eben nie sein, denn ansonsten fängt der Spass erst richtig an. ;) Gerade wenn man zwei RID-Master in der Domäne hätte, wäre das richtig amüsant. Zitieren Link zu diesem Kommentar
odeutschbein 10 Geschrieben 3. Juni 2008 Autor Melden Teilen Geschrieben 3. Juni 2008 Hi Yusuf, nun sind die Rollen endlich auf dem neuen DC !! Folgendes kleines Problem habe ich jetzt im Application LOG - EventID 53258 Quelle ist MSDTC die Warning Meldung kommt 2 mal hintereinander und dann kommt EventID 4193 auch Quelle MSDTC als Info Message im LOG. Muss ich mir Sorgen machen ?? Dann habe ich noch die Merkwürdigkeit dass der time32 Service immer noch die Zeit vom alten DC syncronisiert und nicht vom neuen DC Was kann ich tun ?? Nachmals danke im Voraus Gruß Olli Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 3. Juni 2008 Melden Teilen Geschrieben 3. Juni 2008 Muss ich mir Sorgen machen ?? Den Fehler mit der EventID 53258 kannst du vernachlässigen, der ist nicht tragisch. Falls du die Meldung aber los haben möchtest (natürlich willst du das), dann befolge diesen Artikel: Event ID 53258 is logged in Event Viewer after you install or remove Active Directory in Windows Server 2003 Evtl. verschwindet dann auch der Feler 4193, dass musst du beobachten. Dann habe ich noch die Merkwürdigkeit dass der time32 Service immer noch die Zeit vom alten DC syncronisiert und nicht vom neuen DC Führe diesen Befehl auf dem neuen PDC-Emulator aus: w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES Auf den anderen DCs, die nicht die Rolle des PDC-Emulators inne haben, führst du diesen Befehl aus: w32tm /config /update /syncfromflags:_DOMHIER /reliable:YES Auf einem Memberserver führst du diesen Befehl aus: w32tm /config /update /syncfromflags:_DOMHIER /reliable:NO An einem XP-Client kannst du dann auch diesen Befehl händisch eingeben: "w32tm /config /update /syncfromflags:_DOMHIER" Anschließend überprüfe auf den Maschinen das Eventlog. P.S. Bei den Befehlen darfst du nicht den Unterstrich eingeben! Wenn ich den Befehl aber ohne den Unterstrich poste, erscheint dieser Smiley :D . Das führt zur Verwirrung. Zitieren Link zu diesem Kommentar
odeutschbein 10 Geschrieben 4. Juni 2008 Autor Melden Teilen Geschrieben 4. Juni 2008 Moin Yusuf, also, auf dem neuen PDC habe ich den Befehl ausgeführt und allles sieht OK aus. Jetzt möchte ich die anderen DC bearbeiten. Meinst du mit dem _DOMHIER den Namen meiner eigenen Domain ?? Danke und Gruß Olli Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 4. Juni 2008 Melden Teilen Geschrieben 4. Juni 2008 Moin Yusuf, Morsche. Jetzt möchte ich die anderen DC bearbeiten. Meinst du mit dem _DOMHIER den Namen meiner eigenen Domain ?? Ich weiß, es ist verwirrend. Aber ich meine genau den Befehl so wie er da steht nur eben ohne den Unterstrich direkt hintereinander, sonst hätte ich dich schon darauf hingewiesen. Das DOMHIER bedeutet, dass die DOMänen-HIERarchie verwendet werden soll. Zitieren Link zu diesem Kommentar
odeutschbein 10 Geschrieben 4. Juni 2008 Autor Melden Teilen Geschrieben 4. Juni 2008 Yusuf, nun habe ich festgestellt, dass die Fire Wall ein Abfragen einer externen Zeitgeberquelle nicht zulässt. Der EventLog des neuen DC's wurde mit ID 47 & 29 beschickt. Die FireWall Einstellungen dürfen wir bei uns nicht ändern. Wie sollte ich dann den w32 Service auf dem DC konfigurieren ? Nochmals Danke Olli Zitieren Link zu diesem Kommentar
Sunny61 812 Geschrieben 4. Juni 2008 Melden Teilen Geschrieben 4. Juni 2008 nun habe ich festgestellt, dass die Fire Wall ein Abfragen einer externen Zeitgeberquelle nicht zulässt. Und wie habt ihr das vorher gemacht? Der EventLog des neuen DC's wurde mit ID 47 & 29 beschickt. Die FireWall Einstellungen dürfen wir bei uns nicht ändern. Wie sollte ich dann den w32 Service auf dem DC konfigurieren ? Kannst Du denn nicht Veränderungen beantragen? BTW: Du plenkst: Volkers Usenet-Seiten - Glossar des Usenet-Jargons Zitieren Link zu diesem Kommentar
odeutschbein 10 Geschrieben 4. Juni 2008 Autor Melden Teilen Geschrieben 4. Juni 2008 Yusuf, ich hatte noch nie eine externe Zeitquelle in meinem Netz. Ich wollte eigentlich nur den neuen DC als Zeitserver im Netz haben, das dessen Zeit die "Masterzeit" im Netzwerk ist und alle anderen Rechner sich die Zeit von ihm holen. Geht das ? Olli Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 4. Juni 2008 Melden Teilen Geschrieben 4. Juni 2008 nun habe ich festgestellt, dass die Fire Wall ein Abfragen einer externen Zeitgeberquelle nicht zulässt. Schade aber auch. Auf der Firewall müsste der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden sollte. Du kannst ja mal nachfragen, dabei gibt es auch kein erwähnenswertes Risiko, denn es ist bisher noch kein Fall bekannt, dass durch einen offenen Port 123 etwas "verbrochen" wurde, was natürlich nichts heißen mag. Wenn es sich einrichten lassen könnte diesen Port auf der Firewall zu öffnen, dann tut es es. Falls nicht, dann eben nicht. Wie sollte ich dann den w32 Service auf dem DC konfigurieren ? Der PDC-Emulator der Root-Domäne sollte sich zwar entweder mit einer externen Zeitquelle oder aus dem Internet die reale Zeit abgleichen, es ist aber kein muss. Denn die reale Zeit spielt für die interne Domäne keine große Rolle, bzgl. Kerberos. Du kannst nun dem PDC-Emulator der Root-Domäne sagen, dass er die zuverlässige Zeitquelle dieser Gesamtstruktur ist. Dazu schaltest du den Dienst "Windows-Zeitgeber" auf dem PDC-Emulator ab. Dann solltest du aber für die Zukunft darauf achten, dass die Zeit auf dem PDC-Emu. mit der realen Zeit stimmt und ggf. nachstellen. Es ist aber kein muss. Wie gesagt, zwingend ist das die Synchronisation der Zeit innerhalb des Netzwerks sich nicht um mehr als plus/minus 5 Minuten abweicht, denn ansonsten gibt es Probleme mit den Kerberos-Tickets sowie der AD-Replikation. Das bedeutet dann, den Befehl für den PDC-Emu bräuchtest du nicht ausführen, aber die restlichen auf den weiteren DCs, Memberservern sowie Clients aber schon. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.