19
Migration von SBS 2008 nach Windows Server 2008 R2
Liebe Forenmitglieder,
wir möchten von SBS 2008 nach Windows Server 2008 R2 migrieren, wobei wir auch die Domain firma.local durch intranet.firma.de ablösen möchten. Problem hierbei ist, dass der SBS keine Vertrauensstellung erlaubt und somit die Verwendung von ADMT nicht möglich ist. Weiterhin soll der NETBIOS Name (firma) möglichst erhalten bleiben. Meine Idee ist folgende: Ich ergänze den SBS bzw. firma.local um einen weiteren DC auf Basis von Windows Server 2008 R2. Weiterhin setze ich einen DC für intranet.firma.de auf mit NETBIOS Name "temporaer". Zwischen diesen DC auf Basis von Windows Server 2008 R2 stelle ich dann die Vertrauensstellung her, migriere mit ADMT die Benutzer, Gruppen und Computer und benenne anschließend in der Zieldomäne den NETBIOS Namen von "temporaer" in "firma" um. Der SBS, der noch für Exchange verwendet wird, zieht in ein anderes Netz um, damit es bei NETBIOS keine Konflikte gibt. Ja, wir haben dann für Exchange weiterhin die alte Domain mit den alten Konten. Aber das ist nur temporär bis Exchange ebenfalls migriert wird. Frage an Euch: Kann das mit der Vertrauensstellung über den Umweg eines zweiten DC auf Basis von Windows Server 2008 R2 funktionieren? Falls nicht, wie kann ich mein Ziel dennoch erreichen?
Vielen Dank vorab!
tonabnehmer
wir möchten von SBS 2008 nach Windows Server 2008 R2 migrieren, wobei wir auch die Domain firma.local durch intranet.firma.de ablösen möchten. Problem hierbei ist, dass der SBS keine Vertrauensstellung erlaubt und somit die Verwendung von ADMT nicht möglich ist. Weiterhin soll der NETBIOS Name (firma) möglichst erhalten bleiben. Meine Idee ist folgende: Ich ergänze den SBS bzw. firma.local um einen weiteren DC auf Basis von Windows Server 2008 R2. Weiterhin setze ich einen DC für intranet.firma.de auf mit NETBIOS Name "temporaer". Zwischen diesen DC auf Basis von Windows Server 2008 R2 stelle ich dann die Vertrauensstellung her, migriere mit ADMT die Benutzer, Gruppen und Computer und benenne anschließend in der Zieldomäne den NETBIOS Namen von "temporaer" in "firma" um. Der SBS, der noch für Exchange verwendet wird, zieht in ein anderes Netz um, damit es bei NETBIOS keine Konflikte gibt. Ja, wir haben dann für Exchange weiterhin die alte Domain mit den alten Konten. Aber das ist nur temporär bis Exchange ebenfalls migriert wird. Frage an Euch: Kann das mit der Vertrauensstellung über den Umweg eines zweiten DC auf Basis von Windows Server 2008 R2 funktionieren? Falls nicht, wie kann ich mein Ziel dennoch erreichen?
Vielen Dank vorab!
tonabnehmer
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 207238
Url: https://administrator.de/contentid/207238
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
19 Kommentare
Neuester Kommentar
Moin,
obwohl ich den Sinn nicht ganz verstehe ... auch wenn Du sechs DC in das SBS-Netz hängst, ist und bleibt das eine SBS-Domäne, FSMO hält der SBS himself. Vertrauensstellungen sind IMHO auch dann nicht möglich, wenn Du den SBS "ausschaltest". Die Beschränkungen der Domäne sollten weiterhin gelten.
Eine Migration per se ist das ganze Vorhaben auch nicht - hier würde die alte Domäne erhalten bleiben.
Welchem Ziel soll das ganze eigentlich dienen - Firma zu gross geworden?
LG, Thomas
obwohl ich den Sinn nicht ganz verstehe ... auch wenn Du sechs DC in das SBS-Netz hängst, ist und bleibt das eine SBS-Domäne, FSMO hält der SBS himself. Vertrauensstellungen sind IMHO auch dann nicht möglich, wenn Du den SBS "ausschaltest". Die Beschränkungen der Domäne sollten weiterhin gelten.
Eine Migration per se ist das ganze Vorhaben auch nicht - hier würde die alte Domäne erhalten bleiben.
Welchem Ziel soll das ganze eigentlich dienen - Firma zu gross geworden?
LG, Thomas
Hi,
der eigentliche Sinn ist es, die firma.local Domäne durch intranet.firma.de zu ersetzen, da .local Probleme mit OS X Rechnern macht. Benutzerkonten, Gruppen und Computer sollen in die neue Domäne migriert werden, so dass SIDs, lokale Profile und Berechtigungen erhalten bleiben. Exchange wird später nachgezogen und von 2007 auf 2010 oder 2013 aktualisiert, sobald unsere Backup Software die neueren Versionen unterstützt. Knackpunkt ist die Vertrauensstellung, ohne die ADMT nicht funktioniert. Daher die Idee, mittels weiteren DC die Vertrauensstellung herzustellen.
Viele Grüße,
tonabnehmer
der eigentliche Sinn ist es, die firma.local Domäne durch intranet.firma.de zu ersetzen, da .local Probleme mit OS X Rechnern macht. Benutzerkonten, Gruppen und Computer sollen in die neue Domäne migriert werden, so dass SIDs, lokale Profile und Berechtigungen erhalten bleiben. Exchange wird später nachgezogen und von 2007 auf 2010 oder 2013 aktualisiert, sobald unsere Backup Software die neueren Versionen unterstützt. Knackpunkt ist die Vertrauensstellung, ohne die ADMT nicht funktioniert. Daher die Idee, mittels weiteren DC die Vertrauensstellung herzustellen.
Viele Grüße,
tonabnehmer
Hallo.
Aktuelle OSX Versionen sollten das nicht mehr tun. Ich würde daher die Macs auf die aktuelle Version updaten, dann ersparst du dir das Basteln.
LG Günther
der eigentliche Sinn ist es, die firma.local Domäne durch intranet.firma.de zu ersetzen, da .local Probleme mit OS X Rechnern macht.
Aktuelle OSX Versionen sollten das nicht mehr tun. Ich würde daher die Macs auf die aktuelle Version updaten, dann ersparst du dir das Basteln.
LG Günther
Nein, wir haben das 3-fach getestet: produktive .local Domain, Testdomain mit .local und Testdomain mit .de. Bei .local gibt es Probleme, bei .de läuft es. OS X sind aktuelle Mountain Lions (10.8). Probleme sind konkret die Anmeldezeiten mit Domain-Benutzern. Bei .de im Sekunden-Bereich, bei .local teilweise Minuten. mDNS Timout auf den OSX Clients herabsetzen hilft ein bisschen, ist aber keine schöne Lösung.
Viele Grüße,
tonabnehmer
Viele Grüße,
tonabnehmer
Hi nochmal,
ich habe zwar (wie üblich) keine-ahnung mit dem Apfelgedrösel ... aber ob es sich dafür lohnt, ein funktionierendes AD zu destruieren? Um wieviele clients handelt es sich denn eigentlich?
LG, Thomas
ich habe zwar (wie üblich) keine-ahnung mit dem Apfelgedrösel ... aber ob es sich dafür lohnt, ein funktionierendes AD zu destruieren? Um wieviele clients handelt es sich denn eigentlich?
LG, Thomas
mDNS Timout auf den OSX Clients herabsetzen hilft ein bisschen, ist aber keine schöne Lösung.
Aber immer noch schöner als die Bastelei die du mit dem AD durchführen willst. Und auch ich hänge mich an die Frage von Thomas an, um wieviele User, Clients geht es den?
LG Günther
Das funktionierende AD ohne Apfel Support wird durch ein funktionierendes AD mit Apfel Support ersetzt. Die Anzahl der Äpfel ist bei uns erheblich.
Das mit dem mDNS hilft auch nur ein bisschen und die betroffenen Apfel-Nutzer sitzen eine Ebene über mir
Grüße,
tonabnehmer
Das mit dem mDNS hilft auch nur ein bisschen und die betroffenen Apfel-Nutzer sitzen eine Ebene über mir
Grüße,
tonabnehmer
Die Anzahl der Äpfel ist bei uns erheblich.
Was heißt erheblich. Mehr als 1, mehr als 5, mehr als 10
LG Günther
Mehr als 10 bzw. mehr als die Hälfte der physischen Arbeitsplatzrechner. Windows VMs haben sie trotzdem noch. Ist bei uns sehr heterogen. AD benötigen wir in jedem Fall für Exchange, vSphere, unsere zahlreichen Windows Server. Open Directory etc. ist keine Alternative.
Viele Grüße,
tonabnehmer
Viele Grüße,
tonabnehmer
Bist Du vom BND? MAD? Du willst von uns was wissen. Wir fragen nach, was wir glauben dafür von Dir wissen zu müssen. Dann gibt es irgendwelche nebulösen Sprüche - 50.000 sind im Übrigen auch mehr als 10.
Du hattest hier schon mal einen ähnlichen thread ... wenn Du Dir nicht helfen lassen willst, dann frag doch nicht erst.
Ich bin raus, trotzdem
LG, Thomas
Du hattest hier schon mal einen ähnlichen thread ... wenn Du Dir nicht helfen lassen willst, dann frag doch nicht erst.
Ich bin raus, trotzdem
LG, Thomas
Du willst Hilfe, lieferst aber keine Infos. Komischen Verhalten, aber sei's drum.
Sinnvollst Lösung. Migration in eine Windows Standard Domäne, also inkl Exchange und allem drum und dran.
Anschließend den SBS aus der Domäne nehmen.
Anschließend kannst du dann die neue Domäne erstellen.
LG Günther
Sinnvollst Lösung. Migration in eine Windows Standard Domäne, also inkl Exchange und allem drum und dran.
Anschließend den SBS aus der Domäne nehmen.
Anschließend kannst du dann die neue Domäne erstellen.
LG Günther
Die genaue Zahl habe ich nicht im Kopf, es dürften aber so ca. 18-20 OS X Rechner sein. Von denen hat fast jeder noch eine Windows VM. Native Windows Arbeitsplätze haben wir nur noch eine Hand voll neben einer Hand voll Linux. Serverseitig haben wir einen Mix aus Windows und Linux. Zusammen ca. 160 VMs, die Hälfte davon aktiv.
Warum ist die Zahl der OS X Rechner denn so wichtig? Technisch macht es doch keinen unterschied, ob nun 1, 10 oder 50 OSX in der Domäne sind, oder?
Viele Grüße,
tonabnehmer
Warum ist die Zahl der OS X Rechner denn so wichtig? Technisch macht es doch keinen unterschied, ob nun 1, 10 oder 50 OSX in der Domäne sind, oder?
Viele Grüße,
tonabnehmer
Hallo,
wenn du möchtest kannst du bei 1 oder 500 Mac OS X Rechner die notwendigen Schritte zur Fehlerbehebung vor Ort am Gerät und per Fuß erledigen. Technisch macht das sehr wohl einen Unterschied.
Grüße
wenn du möchtest kannst du bei 1 oder 500 Mac OS X Rechner die notwendigen Schritte zur Fehlerbehebung vor Ort am Gerät und per Fuß erledigen. Technisch macht das sehr wohl einen Unterschied.
Grüße
Zitat von @GuentherH:
Sinnvollst Lösung. Migration in eine Windows Standard Domäne, also inkl Exchange und allem drum und dran.
Anschließend den SBS aus der Domäne nehmen.
Anschließend kannst du dann die neue Domäne erstellen.
Sinnvollst Lösung. Migration in eine Windows Standard Domäne, also inkl Exchange und allem drum und dran.
Anschließend den SBS aus der Domäne nehmen.
Anschließend kannst du dann die neue Domäne erstellen.
D.h. ich migriere innerhalb von firma.local zu zwei neuen 2008R2, einmal DC, einmal Exchange. Dann entferne ich den SBS aus der Domäne. Anschließend setze ich intranet.firma.de auf, stelle die Vertrauensstellung zu firma.local her und migriere mit ADMT und PrepareMoveRequest. Im Ergebnis bleiben insbesondere die lokalen Benutzerprofile auf den Windows Rechnern erhalten und die Berechtigungen auf Ressourcen wie Network-Shares und lokale Adminrechte. Ist das so korrekt?
VG,
tonabnehmer
Ja, im Prinzip sollte es so klappen.
Mutig, 160 Clients in einer SBS Umgebung
LG Günther
Zusammen ca. 160 VMs, die Hälfte davon aktiv
Mutig, 160 Clients in einer SBS Umgebung
LG Günther
Ich denke nicht, dass eine Migration vom SBS so klappen wird 
Aber lassen wir ihn noch ein paar Tage drüber stolpern.
LG
Aber lassen wir ihn noch ein paar Tage drüber stolpern.
LG
Ich muss mich korrigieren. Wir haben zwar ca. 160 Server als VMs, aber davon ist nur ein Teil in der firma.local Domain. Der Rest ist Linux oder in der DMZ. Arbeitsplätze haben wir ca. 35, von denen die Windows Rechner (physisch, VM) in der Domäne sind, die OS X zum Teil, Linux bisher gar nicht.
VG,
tonabnehmer
Wenn Du einen besseren Vorschlag hast, dann her damit
VG,
tonabnehmer
Hi,
ich möchte noch mal auf die Vertrauensstellung zurück kommen. Ich habe in einem anderen Thread die gleiche Konstellation gelesen, also Migration von SBS2008 zu 2008R2. Dort ging es wohl die Vertrauensstellung vom 2008R2 aus beidseitig aufzubauen und anschließend mit ADMT 3.2 zu migrieren. Hier der entsprechende Kommentar: Migration Small Business 2008 Exchange 2007 nach Windows Server 2008 R2 Exchange 2010. Hat jemand eine Erklärung, warum das dort ging und bei mir nicht?
Danke und Grüße,
tonabnehmer
ich möchte noch mal auf die Vertrauensstellung zurück kommen. Ich habe in einem anderen Thread die gleiche Konstellation gelesen, also Migration von SBS2008 zu 2008R2. Dort ging es wohl die Vertrauensstellung vom 2008R2 aus beidseitig aufzubauen und anschließend mit ADMT 3.2 zu migrieren. Hier der entsprechende Kommentar: Migration Small Business 2008 Exchange 2007 nach Windows Server 2008 R2 Exchange 2010. Hat jemand eine Erklärung, warum das dort ging und bei mir nicht?
Danke und Grüße,
tonabnehmer
