SBS2003 -> "Spezialmigration" -> eine Antwort fehlt noch

[dippas]

Hallo Leute,

ich habe da die Kleinigkeit einer SBS-Migration von SBS2003 alte HW auf SBS2003 neue HW.

Die alte HW und auch die alte Installation ist fritte und unbrauchbar zerlegt. Läuft nur noch im "Notbetrieb", d.h. mit vielen Event-Fehlern und wenig Backup.

Wer jetzt auf den Gedanken kommt, die Events doch zu reparieren und einen "normalen" Migrationspfad zu wählen, den schicke ich gerne die über 30 MB Eventlogs mit den Fehlern . Da ist was für jeden dabei Unterm Strich: Kaputtreparieren kann jeder, Fertigreparieren kostet zuviel Zeit und somit Geld, also besser gleich neu. Sind auch nur 30 User.

Die neue HW ist schon da und auf dieser wurde auch schon ein SBS out of the box installiert. Dabei ist so vorgegangen worden, dass alle Einstellungen des alten SBS auf den neuen "übertragen" wurden. In diesem Falle heißt "übertragen" links abgeschrieben und rechts eingetragen. Das betrifft ALLE Einstellungen, also Domainname ebenso wie IP-Adresse und Rechnername.

User sind auf dem neuen auch schon angelegt. Im Grunde wartet die Büchse nur noch auf Scharfschaltung.

Die Userdaten/Profile etc. werden via Robocopy auf USB-Platte gesichert, die Exchangedaten via Exmerge. Das ganze dann auf den neuen Server kopiert.

Berechtigungen werden ebenfalls passend manuell gesetzt.

Wir haben unterschiedliche Migrationspfade überlegt, aber das ist der Beste.

Jetzt zur Frage:

Die PCs (alles XP, teilweise SP1, teilweise SP2) müssen ja auch in die neue "alte" Domäne.

Wie bekomme ich die PCs nun am Besten/schnellsten/sinnvollsten rüber?

Klar, der Weg raus aus alter Domain in Arbeitsgruppe und rein in neue Domain (mit gleichem Namen!) wird funzen, aber ich bin eher auf der Suche nach einer Lösung, bei der die User möglichst wenig im Arbeitsfluß beeinträchtigt werden. Zudem habe ich ja das Problem, dass ich nicht beide SBS gleichzeitig laufen lassen kann in einem Netz (Namens- und IP-Gleichheit).

Des weiteren stellt sich mir die Frage, wie die Rechner reagieren, wenn sie schon Profile des alten drauf haben.

Auch würde ich gerne wissen, ob jemand Erfahrung hat, was passiert, wenn der Rechner auf das servergespeicherte Profil stößt, was auf dem neuen Server liegt. Wir werden natürlich vorher die Besitzrechte auf den User des neuen AD umbiegen.

Was ist mit den SIDs? Hilft newsid samt neuem Rechnernamen vielleicht weiter?

danke

dippas

[lefg]

Hallo dippas,

das Sichern und Restore des Systemstatus hast du in Betracht gezogen?

Gruß

Edgar

[dippas]

ja, wir haben da einiges in Betracht gezogen.

Dummerweise ist das System derart verranzt, das ich mir mit dem Systemstatus wohl wieder das eine oder andere Problem einhandeln würde.

Dennoch kurze Rückfrage hierzu:
was GENAU wird beim Systemstatus gesichert?

grüße

dippas

[lefg]

Zitat von dippas was GENAU wird beim Systemstatus gesichert?

Ich möchte es mal andersherum ausdrücken: Nach meiner Kenntniss, Es wierden nicht die Einstellungen der Hardware gesichert, die sind ja Geräteabhängig. Wesentlich sind ja Dinge wie SIDs, Konten, Rechnername. Sinn ist es ja mittel des Systemstatus einen abgestürzten Server, einen Dc auf einer neu installierter Hardware schnell Wiederherstellen zu können. Es gibt sogar eine Option zum Erzeugen weiterer DCs aus der Sicherung. Man sichert an den Status des 1.DC an Standort A, bringt die Sicherung an Standort B, mach ein Restore mit einer bestimmten Option aufeinen weiteren Server, dieser wird zum 2.DC. Sinn dieser Aktion ist, die langwierige Replikation des AD über eine schmale Leitung zu vermeiden.

Falls du also den Systemstatus fehlerfrei sichern kannst, würde ich doch das Restore auf einen neuen Server mal machen, probieren. Erst neulich hat hier jemand ganz erstaunt positiv darüber berichtet.

[IThome]

Der Punkt dabei ist wohl, dass auch Registry, IIS-Metabase, COM+ usw. mit dem Systemstate gesichert werden. Die Option zum Wiederherstellen des Systemstates und zum Installieren eines weiteren DCs aus dieser Sicherung beinhaltet nur das Active Directory (DCPROMO /ADV). Ich befürchte (weiss es aber nicht genau), dass das nicht funktionieren wird. Wenn aber das AD noch läuft, kann man (zumindest erstmal testweise) einen SBS in einer virtuellen Maschine installieren, das Verzeichnis "übernehmen", Rollentausch und den alten SBS abschalten. Dann hat man alle Konten usw. des ADs, der alte SBS ist abgeschaltet und aus dem AD entfernt und man kann einen Funktionstest durchführen, ob das Verzeichnis noch korrekt arbeitet (das wäre jedenfalls das, was ich probieren würde) ...
http://www.administrator.de/2_SBS_20..._Hardware.html
Hier ist auch noch was zum Verschieben einer Installation auf andere Hardware
http://support.microsoft.com/?scid=kb;de;D249694
Ich habe sowas ähnliches vor kurzem mit einem völlig verhunzten SBS 2003 machen müssen. Da habe ich einen Standard 2003 in einer virtuellen Maschine installiert, zum DC gemacht und die Rollen übertragen. Danach den SBS neu installiert, nach dem Microsoft-Artikel der Domäne in der virtuellen Maschine zugefügt, Rollen übernommen und den virtuellen Server mit DCPROMO runtergestuft. Dann noch die Exchange-Datenbanken wieder eingebunden. Danach waren noch ein paar Fehler zu beheben, z.B. Kennwort für IIS-User passte nicht mehr, daher merkwürdige OWA-Anzeige, eine Berechtigung musste via ADSIEDIT gesetzt werden, weil ein Exchange-Dienst nicht starten wollte, aber alles in allem lief es recht gut ...

[dippas]

Das Dumme an der Sache ist ja, dass das AD ebenfalls "schrott" ist.

Der Rechner kennt beispielsweise Gruppenrichtlinien nur noch vom hörensagen. Die seinerzeit mal eingerichteten Gruppenrichtlinien werden von den Clients nicht mehr gezogen und sind auch nicht mehr am Server editierbar.

Es ist so, als würden alle Funktionen zum Thema Gruppenrichtlinien defekt sein. Wie gesagt: 30 MB Eventlogs .... Hab da mal in meiner Freizeit den einen oder anderen Tag dran gesessen und einfach mal nach Lösungen für die Fehler gesucht.

Wenn man aber zwei/drei Tage damit verbringt um zu jedem Eintrag einen sinnvollen Fix zu finden, dann kann man sicherlich nicht behaupten, dass sei rationell.

Daher neuer Server und neue Installation. Systemstate scheint mir nicht der sinnvollste Weg zu sein, wenn ich die alten "Fehler" nicht mitnehmen will.

grüße

dippas

[lefg]

http://www.mcse.ms/archive4-2004-7-906930.html

Möglicherweise hilft dir das weiter.

Suche mit Google mal nach "ad repair"! Möglicherweise gibt es da noch etwas anders wie adfix oder fixad.

Hat an dem SBS jemand am sysvol-path rumgemacht, den verschoben oder so?

[dippas]

tja, wenn ich mal wüsste, wer da an was rumgemacht hat

Ich glaube, die wirklichen Ursachen lassen sich eh´nicht mehr rekonstruieren.

Wie dem auch sei, ich werde mir den Link mal zu Gemüte führen. Danke hierfür.

@ITHome
eine Parallelinstallation für 14 Tage Laufzeit hatte ich auch ins Auge gefasst, aber wie gesagt will ich mir keine alten und mir auch unbekannten Flöhe in den Pelz setzen.

Daher auch meine Frage nach der Computermigration. Für den Rest haben wir einen Migrationspfad.

grüße

dippas

[bfg9000]

Hallo dippas,

hast Du Dir schon einmal www.sbsmigraton.com angesehen?
Jeff Middleton beschreibt unter www.smallbizserver.net in einem speziellen SwingForum (kostenfreier Zugang, lediglich Registrierung nötig) einige Details zu seinem Swing-Kit.

Ich habe das Kit bislang nicht eingesetzt, werde dies aufgrund der vielen posititven Rückmeldungen aber bei der nächsten Migration sicher tun.
Bei 30 Usern lohnt sich die Sache auf jeden Fall, denke ich.

Viele Grüße,
Mirko