117471
25.11.2015
1147
3
0
SBS2011 - Migration auf Hyper-V durch Neuinstallation
Ich habe bei einem Kunden einen SBS2011 gefunden, der "unglaublich kaputtgespielt ist". Unter Anderem wurde mehr oder weniger erfolgreich versucht, den SharePoint- und den WSUS zu deaktivieren. Von den ursprünglichen Gruppenrichtlinien existieren nur noch Fragmente, es wurde an der Registry gebastelt usw. usf.
Die Domäne und der Exchange laufen aber (noch).
Ich möchte dort einen Hyper-V-Host anbieten und den SBS zukünftig als Gast betreiben. Mein grundlegender Gedanke ist, den SBS in der VM neu zu installieren und "möglichst wenig" aus der bestehenden Domäne zu übernehmen. Mit "möglichst wenig" denke ich in erster Linie an die Benutzer inklusive SIDs und an die Exchange-Postfächer.
Im Anschluss möchte ich das alte Blech ebenfalls mit einem frischen Hyper-V versehen den SBS dort (als Backup) hin replizieren.
Was ich vorab schon einmal gemacht habe ist, dass ich das komplette Szenario mit identischen Hostnamen, IP-Adressen usw. auf einem isolierten Testnotebook installiert habe. Somit hätte ich zumindest schon einmal eine Vorlage, wie es "eigentlich aussehen müsste" bzw. "mal ausgesehen hat".
Geht das?
Macht das Sinn?
Worauf muss ich achten?
Die Domäne und der Exchange laufen aber (noch).
Ich möchte dort einen Hyper-V-Host anbieten und den SBS zukünftig als Gast betreiben. Mein grundlegender Gedanke ist, den SBS in der VM neu zu installieren und "möglichst wenig" aus der bestehenden Domäne zu übernehmen. Mit "möglichst wenig" denke ich in erster Linie an die Benutzer inklusive SIDs und an die Exchange-Postfächer.
Im Anschluss möchte ich das alte Blech ebenfalls mit einem frischen Hyper-V versehen den SBS dort (als Backup) hin replizieren.
Was ich vorab schon einmal gemacht habe ist, dass ich das komplette Szenario mit identischen Hostnamen, IP-Adressen usw. auf einem isolierten Testnotebook installiert habe. Somit hätte ich zumindest schon einmal eine Vorlage, wie es "eigentlich aussehen müsste" bzw. "mal ausgesehen hat".
Geht das?
Macht das Sinn?
Worauf muss ich achten?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 289305
Url: https://administrator.de/forum/sbs2011-migration-auf-hyper-v-durch-neuinstallation-289305.html
Ausgedruckt am: 23.04.2025 um 05:04 Uhr
3 Kommentare
Neuester Kommentar
Mit "möglichst wenig" denke ich in erster Linie an die Benutzer inklusive SIDs und an die Exchange-Postfächer.
Das kann dann nur eine Migration sein und keine alleinstehende Neuinstallation wie du sie jezt in der Testumgebung hast.
LG Günther
Zitat von @117471:
Ich habe bei einem Kunden einen SBS2011 gefunden, der "unglaublich kaputtgespielt ist". Unter Anderem wurde mehr oder weniger erfolgreich versucht, den SharePoint- und den WSUS zu deaktivieren. Von den ursprünglichen Gruppenrichtlinien existieren nur noch Fragmente, es wurde an der Registry gebastelt usw. usf.
Ich habe bei einem Kunden einen SBS2011 gefunden, der "unglaublich kaputtgespielt ist". Unter Anderem wurde mehr oder weniger erfolgreich versucht, den SharePoint- und den WSUS zu deaktivieren. Von den ursprünglichen Gruppenrichtlinien existieren nur noch Fragmente, es wurde an der Registry gebastelt usw. usf.
Ja, das gibt es, besonders beim SBS.
Die Domäne und der Exchange laufen aber (noch).
Der SBS verträgt so einiges an Schandtaten, hab' ich auch schon festgestellt.
Ich möchte dort einen Hyper-V-Host anbieten und den SBS zukünftig als Gast betreiben. Mein grundlegender Gedanke ist, den SBS in der VM neu zu installieren und "möglichst wenig" aus der bestehenden Domäne zu übernehmen. Mit "möglichst wenig" denke ich in erster Linie an die Benutzer inklusive SIDs und an die Exchange-Postfächer.
Das wird, glaube ich, so nicht gehen. Du weißt sicherlich, daß der SBS ein "Highlander" ist (es darf nur einen geben). Führst Du eine komplette Neuinstallation durch, gründest Du damit eine neue SBS-Domäne. Was in der Folge bedeutet, daß die ganzen Sicherheitsprinzipale der zu übernehmenden User, Userdaten und Exch.-Postfächer verloren gehen, die wirst Du so wie von Dir geplant nicht mehr 1:1 funktionierend zum Laufen kriegen.
Deshalb folgende Fragen u. Anmerkungen:
- was spricht dagegen, alles neu zu machen?
- wieviel Mehrarbeit wäre das, ist Dein Kunde bereit, dies zu bezahlen?
- gibt es bisher nur den SBS oder auch noch andere Server (irgendwohin werden SharePoint und WSUS vermutlich ausgelagert worden sein, oder wurden sie nur deaktiviert, weil sie nicht gebraucht wurden?)
- Nutzdaten (Userhomes) könnten auch bei einer Neuinstallation wieder eingespielt werden und erhalten durch Vererbung die neuen Prinzipale der neu angelegten Nutzer
- neuangelegte Postfächer können aus dem Backup des alten Servers per PST-Import befüllt werden
Ich würde somit ernsthaft darüber nachdenken, wirklich alles neu zu machen, ob nun virtualisert oder nicht (beachte aber insbesondere bei der Virtualisierung des SBS 2011, daß Du ihm 32 GB virtuellen RAM gibst).
Viele Grüße
von
departure69
SharePoint und WSUS wurden abgeschaltet, "da sie ständig auf Fehler gelaufen sind und zu viel Plattenplatz gefressen haben" 
Dagegen spricht:
- dass ich die Befürchtung habe, die Verbindung zwischen den AD-Benutzern und den (lokalen) Profilen auf den Arbeitsplatzrechnern zu verlieren und ich mich scheue, jeden Client anzufassen
- auf dem Terminal- und Fileserver ein relativ großer Verzeichnisbaum liegt, bei dem die Vererbung an diversen - teilweise mir unbekannten Stellen - aufgebrochen wurde
- es ein schier unüberschaubares Konstrukt an lokalen und serverbasierten Filterregeln auf dem Exchange-Server gibt, welche sich auch irgendwie zuarbeiten. Zusätzlich läuft auf dem Terminalserver ein easy2sync mit einem lokalen Outlook 2003, dass da auch noch reingreift
- teilweise parallel mit lokalen Installationen und Terminalsitzungen gearbeitet wird
- die Erfordernis besteht, dass das ganze Szenario während der gesamten Migration einsatzbereit bleibt. D.h., wenn ich z.B. den Terminal- und Fileserver migriere, wird sich das auf die lokalen Netzlaufwerke auswirken (die z.B. noch über die alten Domäne abgebildet werden), der neue Terminalserver verwendet dann jedoch u.U. schon das neue ActiveDirectory und kann die Zugriffsrechte aus der alten Domäne nicht korrekt interpretieren...
Dagegen spricht:
- dass ich die Befürchtung habe, die Verbindung zwischen den AD-Benutzern und den (lokalen) Profilen auf den Arbeitsplatzrechnern zu verlieren und ich mich scheue, jeden Client anzufassen
- auf dem Terminal- und Fileserver ein relativ großer Verzeichnisbaum liegt, bei dem die Vererbung an diversen - teilweise mir unbekannten Stellen - aufgebrochen wurde
- es ein schier unüberschaubares Konstrukt an lokalen und serverbasierten Filterregeln auf dem Exchange-Server gibt, welche sich auch irgendwie zuarbeiten. Zusätzlich läuft auf dem Terminalserver ein easy2sync mit einem lokalen Outlook 2003, dass da auch noch reingreift
- teilweise parallel mit lokalen Installationen und Terminalsitzungen gearbeitet wird
- die Erfordernis besteht, dass das ganze Szenario während der gesamten Migration einsatzbereit bleibt. D.h., wenn ich z.B. den Terminal- und Fileserver migriere, wird sich das auf die lokalen Netzlaufwerke auswirken (die z.B. noch über die alten Domäne abgebildet werden), der neue Terminalserver verwendet dann jedoch u.U. schon das neue ActiveDirectory und kann die Zugriffsrechte aus der alten Domäne nicht korrekt interpretieren...
