Win2k DC soll neue Hardware bekommen

[SEMA 10]

Hallo zusammen!

 

Um gleich zum Thema zu kommen:

Ich habe hier eine Domäne mit drei DCs die alle mit Win2k laufen. Die sollen nach und nach neue Hardware spendiert bekommen. Win2k als Betriebssystem soll auf alle Fälle bleiben (das liegt leider nicht in meinen Händen).

Der/die neuen Server müssen ihre Namen sowie ihre IP-Adressen beibehalten.

 

Die richtige Vorgehensweise wäre ja normalerweise

- FSMO-Funktionen des zu tauschenden Servers auf die anderen übertragen

- Herabstufen zum Mitgliedsserver

- Aus der Domäne nehmen

- Abschalten

- Neuen Server ins Netz und zum Mitgliedsserver

- Heraufstufen zum DC, FSMO-Funktionen wieder übertragen

 

Der erste Server der getauscht werden soll ist mit sehr viel Anwendungen und einer relativ grossen Datenbank bestückt. Das alles auf einem neuen Server mit genau den passenden Einstellungen nochmal zu installieren wird eine fast unmögliche Aufgabe.

 

Testweise habe ich den Server heruntergefahren, mittels Ghost eine Kopie der Systempartition auf eine neue HDU gemacht und diese in die neue Hardware eingebaut. Die Installation ist tatsächlich gestartet, ich habe die fehlenden Treiber nachinstalliert und dann alle überflüssigen Treiber entfernt.

Dieser Server läuft jetzt (natürlich alleine für sich ohne Netzwerkanbindung) seit 1 Woche schön stabil vor sich hin. Über ein angeschlossenes Laptop habe ich die ganzen Anwendungen getestet. Auch diese würden bestens funktionieren.

Gedauert hat das ganze ca. 1 Stunde. Sprich der DC wäre eine Stunde lang nicht in der Domäne.

 

Meine irrwitzige Idee wäre jetzt das genau so in der echten AD-Umgebung zu machen

Was aber passiert wenn ich das in der richtigen AD-Umgebung versuche? Was machen die anderen beiden DCs? Wo ist der Stolperstein?

Was habe ich übersehen?

 

Bin für jeden guten Tip dankbar.

 

 

Danke und viele Grüße

Joachim

[Daim 12]

Servus,

 

Der/die neuen Server müssen ihre Namen sowie ihre IP-Adressen beibehalten.

 

das geht, aber bedenke, bei 2000 kannst du den Server nicht umbenennen wenn dieser ein DC ist. Bedeutet, den ursprungs-DC mit DCPROMO demoten, umbenennen´und der neuen Maschine den NAmen verpassen.

 

Für die IP-Adresse, siehe:

Yusuf`s Directory - Blog - Die IP - Adresse eines Domänencontrollers ändern

 

Die richtige Vorgehensweise wäre ja normalerweise

- FSMO-Funktionen des zu tauschenden Servers auf die anderen übertragen

- Herabstufen zum Mitgliedsserver

- Aus der Domäne nehmen

- Abschalten

- Neuen Server ins Netz und zum Mitgliedsserver

- Heraufstufen zum DC, FSMO-Funktionen wieder übertragen

 

Je nachdem, beachte:

Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen

 

Der Server muss nicht zuerst ein Memberserver werden, du kannst ihn direkt mit DCPROMO heraufstufen. Denk an den Computernamen!

 

Was aber passiert wenn ich das in der richtigen AD-Umgebung versuche? Was machen die anderen beiden DCs? Wo ist der Stolperstein?

 

Was das Thema Imaging betrifft, würde ich die Finger davon lassen.

Gerade bei Datenbank-Applikation (wie z.B. AD, DB-Anwendungen etc.) oder einer Domäne mit mehreren DCs, würde ich es vermeiden. Auch wenn es sich um ein offline Imaging handeln würde.

 

Dazu empfehle ich diese Seite mit samt den darin verlinkten Artikeln:

Yusuf`s Directory - Blog - Images als Sicherung ?

[lefg 276]

Die vom TO beschriebene Methode habe ich vom Grundgedanken her mehrfach erfolgreich angewand, allerding nur bei DC und Fileserver, keine DB.

 

Ein Beispiel : Eine Umsetzung von EIDE/SCSII nach SDATA. Ich habe den S-Controller eingebaut, den Treiber dafür installiert, die alten auf die neuen Platten cloned mit Ghost, montieren; voila, es lief und es läuft immer noch.

 

Es war aber ansonsten der selbe Server, das selbe MB.

[SEMA 10]

Schonmal vielen Dank für die Antworten.

 

Dass man DCs wegen dem USN-Rollback nicht mit Images sichern sollte ist mir bekannt. Das habe ich ja so auch gar nicht vor.

 

Hier nochmal ganz genau das was ich eigentlich gerne versuchen würde:

 

- Den aktuellen DC herunterfahren.

- Im Offlinebetrieb mittels Ghost alle Laufwerke und Partitionen auf neue Festplatten übertragen

- Diese neuen Platten in die neue Hardware einbauen

 

Jetzt kommt der Punkt bei dem ich unsicher werde:

- Der Server muss ja jetzt mit seiner neuen Hardware gestartet werden, damit die Treiber dafür installiert werden können. Z.B. auch der treiber für die Netzwerkkarte. Ab diesem Moment laufen ja prinzipiell die beiden noch im Netz hängenden DCs und der neue "auseinander". Bis der dann endlich seine Funktion wieder aufnehmen könnte, hätte ich ca. 1 Stunde in der die DCs nicht "synchron" gelaufen sind.

 

Kann hierbei irgendwas schiefgehen? Das ist meine eigentliche Frage oder Befürchtung.

[PAT 10]

Wieso? Wenn Du den Server korrekt installierst (inkl. Treiber) und ihn danach in die Domäne nimmst und heraufstufst, dürfte das keine Probleme bereiten.

Oder habe ich Dich da falsch verstanden?

[Daim 12]

Die vom TO beschriebene Methode habe ich vom Grundgedanken her mehrfach erfolgreich angewand, allerding nur bei DC und Fileserver, keine DB.

 

Was letztenendes jeder daraus macht, bleibt jedem selbst überlassen (ich erinnere an den Support).

Du wirst von mir aber niemals ein fürsprechen für diese Methode lesen ;).

[lefg 276]

Ich hätte auch lieber eine andere Methode angewand, ich bin konserativ. Nun, manchmal geht es nicht anders, nicht unbedingt aus technischen Gründen. Mir blieb besonders beim Erstenmal nichts anderes übrig als zu folgen. Ich konnnte keine Argumente aufführen gegen das Klonen, das müsse doch so funktionieren, so hiess es von den Leuten mit Hut auf und Geld in der Patte. Die entscheiden über meine Stelle und Gehalt.

[SEMA 10]

Wieso? Wenn Du den Server korrekt installierst (inkl. Treiber) und ihn danach in die Domäne nimmst und heraufstufst, dürfte das keine Probleme bereiten.

Oder habe ich Dich da falsch verstanden?

 

Ich denke Du hast tatsächlich was falsch verstanden.

Wenn ich das so mache dann handelt es sich um diesen hardwaretechnisch neuen Server um eine exakte Kopie des alten (abgesehen von den Treibern). Der muss nicht mehr heraufgestuft werden.

 

- Alter Server ausschalten

- Via Ghost auf neue HDU kopieren

- Neue HDU in neue Hardware einbauen

- Server in neuer Hardware starten

- Treiber installieren

- Mit dem Netzwerk verbinden

 

Erst wenn die Netzwerkkartentreiber installiert sind, kann ich dieses Gerät wieder mit dem Netzwerk verbinden.

Vom ersten Start weg bis zu dem Moment in dem ich den ans Netz hänge läuft die Domäne und der Server in der neuen Hardware unabhängig voneinander. Also ca. 1 Stunde.

 

Und da frage ich mich ob das was ausmacht. Was wäre wenn sich die restlichen beiden DCs genau in dieser Zeit replizieren?

[Daim 12]

Das Bedürfnis zu Imagen, kann ich verstehen, gerade wegen dem Aufwand. Es ist verlockend.

Man muss sich eben immer im klaren sein, im Fall der Fälle - steht man dann von seitens Microsoft verständlicherweise ohne Hilfe da. Wenn das auch noch ein Kunde akzeptiert ... sind (oder sollten) sich alle beteiligten der Lage bewußt sein und müsse nbei Probleme selbst zusehen, was sie daraus machen.

[SEMA 10]

Das Bedürfnis zu Imagen, kann ich verstehen, gerade wegen dem Aufwand. Es ist verlockend.

Man muss sich eben immer im klaren sein, im Fall der Fälle - steht man dann von seitens Microsoft verständlicherweise ohne Hilfe da. Wenn das auch noch ein Kunde akzeptiert ... sind (oder sollten) sich alle beteiligten der Lage bewußt sein und müsse nbei Probleme selbst zusehen, was sie daraus machen.

 

Es handelt sich aber doch im eigentlichen Sinne um KEIN Image.

Ich könnte ja auch genau so gut die Festplatten aus dem aktuellen Server ausbauen und in den neuen Server einbauen.

[Daim 12]

Ich weiss jetzt nicht was du genau meinst.

Meine Aussagen betrafen das Imaging eines Servers, auf dem eine transaktionale Datenbank enthalten ist (so wie es z.B. das AD darstellt).

Ich denke LEFG weiß, was ich meine.

 

Du hast geschrieben:

 

Testweise habe ich den Server heruntergefahren, mittels Ghost eine Kopie der Systempartition auf eine neue HDU gemacht und diese in die neue Hardware eingebaut.

 

Auf der Systempartition eines DCs liegt i.d.R. auch die AD-DB.

Du wendest ein Dritt-Anbieter Tool an und erstellst - auch wenn es offline ist - ein Image.

Woher soll denn Microsoft wissen, was das Tool beim erstellen alles so anstellt? Daher sagt Microsoft ganz klar, Imaging wird nicht supportet.

 

Wenn du die Platten aus dem alten Server aus- und in einen anderen Server einbaust, hast du kein Dritt-Anbieter Tool angewandt.

[lefg 276]

Ich habe beim Anfertigen eines Images oder Klones schon seltsame Sachen erlebt. Das Umsetzen der Platte von einem in den anderen Rechner erscheint zumindest eine Stufe sicherer zu sein. Was tun aber, falls die (System)Platte auch getauscht werden muss, oder es das eigentlich Ziel ist der Operation?

[SEMA 10]

Ich weiss jetzt nicht was du genau meinst.

Meine Aussagen betrafen das Imaging eines Servers, auf dem eine transaktionale Datenbank enthalten ist (so wie es z.B. das AD darstellt).

Ich denke LEFG weiß, was ich meine.

 

Du hast geschrieben:

 

 

 

Auf der Systempartition eines DCs liegt i.d.R. auch die AD-DB.

Du wendest ein Dritt-Anbieter Tool an und erstellst - auch wenn es offline ist - ein Image.

Woher soll denn Microsoft wissen, was das Tool beim erstellen alles so anstellt? Daher sagt Microsoft ganz klar, Imaging wird nicht supportet.

 

Wenn du die Platten aus dem alten Server aus- und in einen anderen Server einbaust, hast du kein Dritt-Anbieter Tool angewandt.

 

Hmm ... vielleicht gehen hier unsere Definitionen eines "Image" etwas auseinander. Ein Image ist so wie ich es verstehe ein exaktes Abbild einer Partition oder einer gesamten HDU in einem File.

Was ich gemacht habe war eine 100%ige 1:1 Kopie der Systempartition eines Servers im Offlinemodus. Das habe ich im übrigen schon mehrfach erfolgreich durchgeführt wenn die Systemplatte ca. 75% Ihrer Standzeit erreicht hatte oder einfach nur zu klein wurde. Allerdings wurde diese Kopie dann wieder in genau die gleiche Hardware eingebaut.

Dabei gab es definitiv NOCH NIE Probleme irgendwelcher Art.

 

Selbstverständlich hast Du Recht wenn Du sagst dass man nicht wissen kann was das Tool so anstellt. Allerdings gehe ich davon aus, dass bei einer sektorenweise Kopie im Bezug auf irgendwelche Kopierfehler nichts passiert.

Ansonsten wäre ich da sicher schon mehrfach baden gegangen.

 

Ich bin immer noch der Meinung, dass es keinerlei Unterschied macht ob ich die originalen Festplatten oder eine Ghostkopie davon verwende.

 

Die einzige Sache bei der ich mir überhaupt nicht sicher bin, ist ob es was ausmacht wenn dieser spezielle DC in neuer Hardware eine gewisse zeit getrennt vom Rest der Domäne läuft.

Das gleiche wäre doch wenn ich jetzt beim aktuelle DC, welcher mit neuer Hardware versorgt werden soll, für eine Stunde einfach das LAN-Kabel abziehe und dann wieder draufstecke. Normalerweise dürfte das doch überhaupt nichts ausmachen ... zumindest nach meinem sicherlich begrenzten Wissen.

 

Oder bin ich jetzt völlig und total auf dem Holzweg?

[Daim 12]

Die Definition was "Imaging" bedeutet, lass ich mal bei Seite, sie spielt auch keine Rolle in diesem Fall. Denn das entscheidende ist, es wird eben ein Dritt-Anbieter Tool verwendet (bei einem DC) und genau das wird nicht supportet.

 

Wenn du die HDDs aus- und woanders erneut einbaust, wurde KEIN Dritt-Anbieter Tool angewendet!

 

Ich werde jetzt keine Diskussion über Imaging führen, mein Standpunkt steht in meinem Link!

 

Benutze die Boardsuche und du wirst jede Menge dazu finden.

Was du (oder andere) am Ende daraus machst, bleibt jedem selbst überlassen.

Jeder sollte sich nur der Konsequenzen im klaren sein, eben im Fall der Fälle von seitens Microsoft, keinen Support zu bekommen.

[Anakim 10]

Abgesehen vom "Imageing Grundsatzthema" sollte der DC nach dem erneuten einschalten sich wieder mit seinen "Kollegen" unterhalten können.

 

Diese werden in der "Pause" solange ohne ihn weitermachen.

 

Probleme beim Wiedereintritt in die "Hemisphere" könnten hierbei eben durch das Imageing entstehen (AD DB) . Darauf wurde hier schon von Daim ausreichende hingewiesen.

 

Anakim