NT 4 PDC und W2k3 PDC in gleichen Netz möglich ?

[enno27 10]

Hallo,

 

wir haben hier folgende Situation:

 

Derzeit läuft hier im Verwaltungsnetz ein alter NT 4 Server als PDC, und dieser soll nun durch einen neuen W2K3 Server ersetzt werden.

Dieser neue W2K3 Server läuft auch bereits als reiner Fileserver im Verwaltungsnetz, da wir dort schon unsere Kursverwaltungssoftware installiert haben.

Die NT 4 Server PDC User haben wir über eine Gruppe auf dem W2K3 Server eingerichtet, damit diese mit dem Kursprogramm arbeiten können (Dateifreigaben, Gupda SQL Server).

Nun haben wir uns überlegt den W2K3 Server zu einem PDC zu machen und damit gleichzeitig eine neue Domäne einzurichten.

Danach möchten wir die User des alten NT Server nach und nach in die neue Domäne umziehen lassen.

 

Die Frage ist jetzt, die derzeitigen NT Server User müssen auch nach dem der W2K3 Server zum PDC geworden ist, weiterhin auf die Freigabe und den Gupda SQL Server zugreifen können.

 

Kann es da zu Problemen kommen ?

 

Bzw. kann es Probleme geben wenn zwei PDC's im gleichen IP-Netz arbeiten ?

 

Derzeit läuft im gleichen Netz noch ein Samba PDC Server und da hat es keinerlei Probleme gegeben, sollte doch eigentlich so funktionieren oder sehe ich das falsch ?

 

greetz

ennno

[Daim 12]

Salut,

 

Nun haben wir uns überlegt den W2K3 Server zu einem PDC zu machen und damit gleichzeitig eine neue Domäne einzurichten.

 

das könnt ihr zwar tun, jedoch habt ihr damit die meiste Arbeit. Ihr müsstet dann mit z.B. ADMT die Benutzer- sowie Computerkonten von der NT-Domäne in die neue Windows 2003 Domäne migrieren.

 

Die wenigste Arbeit hättet ihr, wenn ihr ein Inplace-Update der NT-Domäne auf Windows 2003 durchführen würdet.

 

Danach möchten wir die User des alten NT Server nach und nach in die neue Domäne umziehen lassen.

 

Ja, dass könnte man mit ADMT erledigen. Aber wenn ihr ein Inplace-Update durchführt, bleibt euch das erspart.

 

Kann es da zu Problemen kommen ?

 

Du musst natürlich vorher klären, ob die Applikationen Windows Server 2003 tauglich sind.

 

Bzw. kann es Probleme geben wenn zwei PDC's im gleichen IP-Netz arbeiten ?

 

Nein, dass funktioniert. Du musst nur die Dienste wie z.B. DHCP richtig konfigurieren.

 

Derzeit läuft im gleichen Netz noch ein Samba PDC Server und da hat es keinerlei Probleme gegeben, sollte doch eigentlich so funktionieren oder sehe ich das falsch ?

 

Das funktioniert, wenn man es richtig macht. ;)

[enno27 10]

Hallo,

 

vielen Dank für deine Antworten, werde das jetzt erstmal in ner Virtuellen Maschine testen.

greetz

enno

[Daim 12]

vielen Dank für deine Antworten

 

Nicht dafür. ;)

 

werde das jetzt erstmal in ner Virtuellen Maschine testen.

 

Tue das. Aber auch würde ich dir empfehlen das Inplace-Update für eure produktive Umgebung, ebenfalls mit einer VM durchzuführen. Denn so bekommst du keine Treiber/Hardware Probleme, da wahrscheinlich der NT-PDC nicht Windows 2003 tauglich sein wird.

 

Deshalb installiere (sofern ihr euch für ein Inplace-Update entscheidet) in der produktiven Umgebung in einer VM einen NT-Server und füge diesen als BDC zur NT-Domäne hinzu. Anschließend stufst du diesen BDC zum PDC herauf und führst mit dieser VM das Inplace-Update auf Windows 2003 durch. Nach der Betriebssystemaktualisierung installierst du dann noch das AD.

[solinske 10]

Ich würde lieber eine echte Migration machen. ADMT per Skript und die Sache läuft fast von alleine. Ich nehme mal an, dass die Hardware des NT4 Rechners etwas in die Jahre gekommen ist. Bei einem Inplace Update schleppst du auch den ganzen "alten" Kram mit.

 

In deinem Fall benötigst du ADMT 3.0 und den Password Export Server 3.0 (ist enthalten).

 

Bei dem SAMBA Server musst du nur sicherstellen, dass er mit der Authentifizierung per Kerberos V5 klar kommt.

 

Für den SQL ist es wichtig zu wissen mit welchem Account der Server läuft. Wenn es ein Service Account ist, dann kannst du diesem einfach mit ADMT analysieren und dann sauber migrieren.

 

Mach dir ein virtuelles Abbild deiner Umgebung und spiel die Migration durch. Du wirst sehen, dass es mit ADMT einfach geht, wenn man die Vorbereitung sauber durchführt.

 

Willst du auch eine neue Domäne schaffen, oder soll der bekannte Name bestehen bleiben?

 

Ansonsten können wir dazu auch mal telefonieren. Manches ist zum Schreiben einfach zu viel.

[Daim 12]

Hi Franky goes to Hollywood (mit -14 Respekt! ;) ),

 

Bei einem Inplace Update schleppst du auch den ganzen "alten" Kram mit.

 

das hört man oft, aber was wäre denn konkret der "alte Kram"?

Denn wenn ein Administrator seinen Job halbwegs ernst nimmt und die Domäne wie es sich gehört administriert, sollten z.B. weder alte Benutzer- oder Computerkonten existieren. Wie ich bereits erwähnt hatte, vom Arbeitsaufwand her die "schnellste" Variante mit dem wenigsten Aufwand.

 

Mach dir ein virtuelles Abbild deiner Umgebung und spiel die Migration durch. Du wirst sehen, dass es mit ADMT einfach geht, wenn man die Vorbereitung sauber durchführt.

 

Also das ADMT zu bedienen bekommt man sicherlich schnell in den Griff. Aber eine Migration als solches ist schon eine große Herausforderung.

[solinske 10]

Für mich ist alles was zum OS gehört schon alter Kram.

Angesehen von den Treibern, Druckertreibern, System Richtlinien, die das System tätovieren. Allein diese Punkte reichen aus, um ein Inplace zu vergessen. Hinterher hat man viel zu viele Baustellen, wenn man auf einen Fehler läuft.

 

Die Systeme die immer sauber administriert werden gibt es leider nicht.

 

Aber eine Migration als solches ist schon eine große Herausforderung.

 

Deswegen sollte man vernüftig planen und nicht mit wildem Aktionismus drüber installieren.

 

Und so groß ist die Herausforderung auch nicht. Der ADMT Guide ist eine gute Hilfe und wenn man das Szenario in der VM durchspielt, dann sollte es am produktiv System keine Probleme geben.

[Daim 12]

Allein diese Punkte reichen aus, um ein Inplace zu vergessen.

 

Deine aufgezählten Punkte können vielleicht "hier und da" Probleme bereiten, aber das ist immer noch kein Grund ein Inplace-Update vom Tisch zu wischen und eine Migration anzustreben. Abgesehen davon kommt es sehr auf die Größe der Umgebung an.

 

Hinterher hat man viel zu viele Baustellen, wenn man auf einen Fehler läuft.

 

Auch dabei würde es auf den Fehler ankommen. Natürlich können Fehler nie ausgeschlossen werden, aber auch nicht vorher bestimmt werden das welche auftauchen. Wenn ein Fehler auftritt, muss dieser von Fall zu Fall bewertet werden.

 

Die Systeme die immer sauber administriert werden gibt es leider nicht.

 

Naja, zumindest ist es denkbar das zumindest die Benutzerkonten von ausgeschiedenen Mitarbeitern und nicht mehr existierende Computerkonten zeitnah gelöscht werden. Das ist natürlich nur ein Part um die Domäneninformationen schlank zu halten.

 

Deswegen sollte man vernüftig planen und nicht mit wildem Aktionismus drüber installieren.

 

Natürlich! Aber an der Aussage das bei einem Inplace-Update der geringste Arbeitsaufwand entsteht gibt es nichts zu rütteln. ;) Probleme können beim Inplace-Update und bei einer Migration auftauchen, können aber bei beiden Varianten wie bereits erwähnt, nicht schon im Vorfeld prognostiziert werden.

 

Und so groß ist die Herausforderung auch nicht.

 

Das sehe ich ebenfalls anders. Es gilt nicht nur die technische Herausforderung zu beachten (salopp gesagt: das ADMT zu bedienen), sonden auch die organisatorische.

 

Der ADMT Guide ist eine gute Hilfe und wenn man das Szenario in der VM durchspielt, dann sollte es am produktiv System keine Probleme geben.

 

Das Whitepaper zu ADMT sollte stets, wenn man sich zu einer Migration entschließt, durchgearbeitet werden. Das Whitepaper ist mehr als eine gute Hilfe, denn eine Migration mit ADMT durchzuführen ohne das Dokument gelesen zu haben würde glatt in die Hose gehen.

[NilsK 2.789]

Moin,

 

ich stimme Yusuf zu. Wenn man es richtig macht und das Szenario stimmt (was hier anscheinend gegeben ist), ist ein Inplace Upgrade eine stabile und sinnvolle Sache. Da man nach Best Practice einen eigenen Upgrade-PDC dafür nutzt (den alten wird man wohl auch kaum upgraden wollen), gibt es auch kaum "Kram" den man mitschleppen könnte. Diesen PDC nimmt man hinterher wieder außer Betrieb, und alles ist auf dem aktuellen Stand.

 

Die tätowierenden Policies sind in erster Linie ein Clientproblem, und das hat man bei ADMT genauso (oder eben in beiden Fällen nicht).

 

Gruß, Nils

[solinske 10]

Nur wurde der Upgrade PDC nicht empfohlen. Sicher ist eine Migration nicht auf die leichte Schulter zu nehmen. Genauso wenig sollte man denken, dass ein "einfaches" Inplace Update die Lösung aller Probleme ist.

 

Mit guter Vorbereitung und wenn man sein System kennt, dann sind beide Wege möglich. Ich würde allerdings lieber die Migration machen als das Inplace Update.

 

Und die angeführten Gegenargumente zu meiner Ausführung überzeugen mich nicht wirklich. Und wenn man in der Realität guckt, dann werden so gut wie keine Konten deaktiviert oder sogar gelöscht. Glaub es mir einfach.

 

ES kommt zu guter letzt immer auf den Admin/Berater an welcher Weg gegangen wird und jeder hat so seine Vorlieben.

[Steven2007 10]

Hallo,

 

so wie der TO das Szenario beschreibt, gehe ich mal davon aus, dass es sich hier nicht um soo viele Benutzer handeln kann.

Eventuell ist es tatsächlich einfacher eine ganz neue Domäne aufzusetzen und die User + die eine Gruppe neu zu erstellen?

 

Somit würde ich, wie es der TO ursprünglich vorhatte, alles auf dem alten Server weiterlaufen lassen, dabei den neuen hochziehen und wenn alles getestet ist, entweder migrieren oder neu erstellen und mit USMT den Rest erledigen :)

Anders wäre die Sache natürlich, wenn bereits ein Exchange vorhanden wäre oder so...

 

PS: Du kannst dem Samba auch sagen, dass er via LDAP deine Domänenbenutzer authentifizieren soll, dann musst du nur an einem Server Konten pflegen (DC) und deine Benutzer brauchen sie nicht extra am Samba anmelden.

 

Gruß

[Daim 12]

Nur wurde der Upgrade PDC nicht empfohlen.

 

Wie meinen? Ich hatte in meiner zweiten Antwort in diesem Thread empfohlen, im Falle eines Inplace-Update die Domänenaktualisierung mit einer VM durchzuführen.

 

Sicher ist eine Migration nicht auf die leichte Schulter zu nehmen. Genauso wenig sollte man denken, dass ein "einfaches" Inplace Update die Lösung aller Probleme ist.

 

Ich behaupte aber, dass der Arbeitsaufwand bei einem Inplace Update geringer ist als bei einer Migration. Des Weiteren behaupte ich Felsenfest, dass bei einer Migration mehrere Steine im Weg stehen können als bei einem Inplace- Update.

 

Mit guter Vorbereitung und wenn man sein System kennt, dann sind beide Wege möglich.

 

Logo, dass zweifelt ja auch keiner an.

 

Ich würde allerdings lieber die Migration machen als das Inplace Update.

 

Also bei mir würde es der Kunde entscheiden. Ich würde ihm nur die Wege aufzeigen, mit all seinen Vor- und Nachteilen, doch letztenendes muss er sich zu einer Variante entscheiden.

 

Und die angeführten Gegenargumente zu meiner Ausführung überzeugen mich nicht wirklich.

 

Müssen sie auch nicht. Dem OP sollen nur die Möglichkeiten aufgezeigt werden.

 

Und wenn man in der Realität guckt, dann werden so gut wie keine Konten deaktiviert oder sogar gelöscht. Glaub es mir einfach.

 

Das ist doch bloß ein banales Beispiel. Ob noch alte Konten existieren wird sicherlich nicht das Entscheidungskriterium für den einen oder anderen Weg sein.

 

ES kommt zu guter letzt immer auf den Admin/Berater an welcher Weg gegangen wird und jeder hat so seine Vorlieben.

 

Der Berater "berät" den Kunden. Entscheiden tut der Kunde.

[solinske 10]

Ich kann mich Steve nur anschließen. Wenn die Zahl der USer steigt, dann würde sich immer eine MIgration anbieten. Dann wie angesprochen ADMT oder USMT. Dabei wird alles sauber in einer DB geloggt und man kann immer ein gutes Rollback Szenarion realisieren.