Migration VON SBS2K8 auf Server16

tesla1337

Ensign
Registriert
Okt. 2010
Beiträge
162
Hallo Leute,
ich stehe aktuell vor einem "kleinen" Problem. Ein mittlerweile gewachsener Kunde von uns hat ein alten SBS2008 der aus dem letzten Loch pfeift und migriert werden möchte / müsste.
Ich habe es über den einfachsten Weg probiert, über Vertrauensstellung dem Migrationstool von MS auf eine SQL Datenbank.
Allerdings hab ich das Problem, dass SBS2008 eine Fehlermedung ausspuckt von wegen "Verttrauensstellung nicht möglich".
Im Internet steht dass der SBS kein ADMT unterstützt, soweit so schlecht.

Es ist mir bewusst, dass es die Möglichkeit gibt einen SVR2016 in die aktuelle Domain aufzunehmen und dem SBS nach und nach die Luft zu entziehen. Das ist zwar alles gut und schön, allerdings gibt es eine zweite Bedingung, die innerhalb der Migration erfüllt werden müsste: eine neue Domäne an sich.

Innerhalb der Migration soll von kunde.local auf ort.kunde.de gewechselt werden. Klar könnte man sagen "mach doch einfach alles neu", Problem an der Sache ist, der Kunde hat gefühlt 1000 Security Groups über sehr sehr viele Projektordner verteilt.

Gibt es da eine (einigermaßen) machbare Lösung ? Leider funktioniert das ADMT je nicht mit SBS2008 :-/

LG tesla
 
SQL Server? Was? Pro-Tipp -> lass das einen Fachmann machen, deine Fragen gehen in die ganz falsche Richtung, das geht in die Hose.
Bei weniger als 50 Mitarbeitern würd ich das ganze auch neu aufsetzen. Klingt mir nicht nach einer gepflegten Umgebung, da wird eine Migration nicht ohne Fachwissen funktionieren und Support gibts auf das Ding eh nicht mehr.
 
  • Gefällt mir
Reaktionen: pseudopseudonym
Man sollte vielleicht erst einmal eine Aufstellung machen was alles genutzt wird da es den SBS ja nicht mehr gibt in 2016/2019.
Dann sollte man überlegen wie man die notwendigen Sachen auf der neuen Plattform mit Migrationen unterbringen kann.

Und sollte man dann feststellen das das eigene KnowHow nicht reicht sollte man ein Systemhaus zu Rate ziehen.
 
  • Gefällt mir
Reaktionen: nosti
McClane schrieb:
SQL Server? Was? Pro-Tipp -> lass das einen Fachmann machen, deine Fragen gehen in die ganz falsche Richtung, das geht in die Hose.
Bei weniger als 50 Mitarbeitern würd ich das ganze auch neu aufsetzen. Klingt mir nicht nach einer gepflegten Umgebung, da wird eine Migration nicht ohne Fachwissen funktionieren und Support gibts auf das Ding eh nicht mehr.

Es sind weniger als 50 Mitarbeiter, allerdings würden die ganzen Gruppen Stunden dauern.
leipziger1979 schrieb:
Man sollte vielleicht erst einmal eine Aufstellung machen was alles genutzt wird da es den SBS ja nicht mehr gibt in 2016/2019.
Dann sollte man überlegen wie man die notwendigen Sachen auf der neuen Plattform mit Migrationen unterbringen kann.

Und sollte man dann feststellen das das eigene KnowHow nicht reicht sollte man ein Systemhaus zu Rate ziehen.
DHCP, DNS, NTP, Exchange, AD/DC,
 
Moin,
auch Lizenzmäßig könnte das eine interessante Konstellation werden.
Wenn auf eine neue Domain gewechselt werden soll, solltest du dir einen Gesamtüberblick über alle Anwendungen, Schnittstellen, Benutzer und Gruppen verschaffen und prüfen was man sinnvoll übernehmen kann.
Eine Domainmigration ist DIE Gelegenheit sowas mal ordentlich neu zu machen und Altlasten abzuwerfen, allerdings auch, je nach Dokumentation und Wissensstand viel Arbeit.

Grüße
 
@nosti
Naja, Lizenzen müssen eh da sein. Das ist kein Grund sowas nicht zu machen.

Und ich gehe davon aus, dass dem Kunden vom TE bewusst ist, dass Server 2016 auch ein neues Lizenzmodell besitzt.

@tesla1337
Du solltest in Erwägung ziehen gleich auf Server 2019 zu setzen.

Server 2016 ist teilweise eine Qual.
 
  • Gefällt mir
Reaktionen: konkretor
nosti schrieb:
Moin,
auch Lizenzmäßig könnte das eine interessante Konstellation werden.
Wenn auf eine neue Domain gewechselt werden soll, solltest du dir einen Gesamtüberblick über alle Anwendungen, Schnittstellen, Benutzer und Gruppen verschaffen und prüfen was man sinnvoll übernehmen kann.
Eine Domainmigration ist DIE Gelegenheit sowas mal ordentlich neu zu machen und Altlasten abzuwerfen, allerdings auch, je nach Dokumentation und Wissensstand viel Arbeit.

Grüße
Die AD ist soweit schon an Usern/Gruppen/... zurück gestutzt worden, wie es ging.
Darkblade08 schrieb:
@nosti
Naja, Lizenzen müssen eh da sein. Das ist kein Grund sowas nicht zu machen.

Und ich gehe davon aus, dass dem Kunden vom TE bewusst ist, dass Server 2016 auch ein neues Lizenzmodell besitzt.
Lizenzen sind alles kein Problem. Der Kunde weiß dass da (neue) Lizenzkosten auf ihn zu kommen können.
 
Gruppen und so, kann man scripten wenn man fit ist. Sollte einen nicht abhalten etwas neu zu machen, wenn der andere Weg sehr steinig wird.
Der Migrationsassistent fällt mag es gar nicht wenn am SBS viel verstellt wurde. Reicht schon wenn man mal einen User von Hand angelegt hat und vom SBS Standard abweicht. Dann gehts ganz schnell als Logfiles studieren und versuchen die Fehler zu beheben. Und dann steht man mittendrin und kommt ggfs. nicht weiter.
Habs selbst schon erlebt vor über 6 Jahren. Und da gabs noch Support von MS. Nicht schön.
 
McClane schrieb:
Gruppen und so, kann man scripten wenn man fit ist. Sollte einen nicht abhalten etwas neu zu machen, wenn der andere Weg sehr steinig wird.
Der Migrationsassistent fällt mag es gar nicht wenn am SBS viel verstellt wurde. Reicht schon wenn man mal einen User von Hand angelegt hat und vom SBS Standard abweicht. Dann gehts ganz schnell als Logfiles studieren und versuchen die Fehler zu beheben. Und dann steht man mittendrin und kommt ggfs. nicht weiter.
Habs selbst schon erlebt vor über 6 Jahren. Und da gabs noch Support von MS. Nicht schön.
Das Problem ist nicht die Gruppen ansich, also das neue Anlegen.
Sondern um die Gruppen mit sID. Es geht hier um eine Architektenbüro mit >200.000 Ordnern, die teilweise sehr alt sind und deren Rechte über Gruppen geregelt wurde.
Circa 1-2x im Jahr wurde dann vom Kunden ein neues Template erstellt mit neuen Einstellungen innerhalb der Ordnerstruktur für ein Einzelnen Projekt (mit >40 Unterordnern und Ordner Ebenen).

Und genau deshalb will ich (sofern nicht irgendwie anders zu lösen) nicht alles nochmal von vorne anlegen :-/
 
Ist in beiden Fällen viel Arbeit. Wenn du Pech hast, darfst du mitt in der Migration von vorn anfangen, weil der AD Connector irgendein Objekt nicht mag.
Es gab früher ein Tool zum evaluieren ob die Migration klappen könnte, wenn es das noch gibt kannst du schon mal einen Vorgeschmack bekommen.
 
Wir haben hier bei unserer Fileservermigration ein ähnliches Problem und konnten das nur mittels Drittanbietersoftware sinnvoll lösen. Kostet aber natürlich wieder Geld und Zeit. Eine Manuelle Anpassung war für uns keine Option. Die Ausgangssituation bei uns war ganz ähnlich, ausgehend von SBS03...

Grüße
 
Eine Domäne umbenennen ist das kleinste Problem, wenn die unbedingt jetzt hyper.xyz heissen muss. Aber mir scheint, hier brauchst du einen Profi
tesla1337 schrieb:
Es sind weniger als 50 Mitarbeiter, allerdings würden die ganzen Gruppen Stunden dauern.
Über Powershell Gruppen + Mitglieder auslesen (gibt halt kein Klickibunti) und in die neue Domäne wieder reinpumpen, FS-Struktur-Berechtigungen mittels icacls auslesen und wieder einspielen, dauert in Summe vlt. 30min, aber wichtig ist: Aufräumen & Archivieren, bei 50 MA kann es gar nicht soviel Geheimnisse geben, dass man die Kundenprojekte hinter Tonnen von Berechtigungen verstecken muss.
 
... und wenn der Exchange auch migriert werden soll kannst dich auf noch viel mehr Arbeit einstellen.
Von Exchange 2007 nach 2019 muss es über einen zwischenschritt 2013 gehen. von der Abhängigkeiten was die Domänenfunktionsebenen und DC Versionen angeht mal ganz zu schweigen....

Ich würde es neu machen.
 
... und wenn der Exchange auch migriert werden soll kannst dich auf noch viel mehr Arbeit einstellen.
Vor allem wenn auch tatsächlich Öffentliche Ordner genutzt werden. :D

Aber ansonsten: Bloß neu machen. Wir haben bei Kunden einige 2016/2019-Domänen, die aus einer "SBS"-Domäne herausstammen. Die funktionieren zwar, aber da ist immer noch viel Kroppzeug drin (vorgefertigte OUs; vorgefertige Gruppenetc.), das man lieber nicht aufräumen will weil man nicht hunderprozentig einschätzen kann, was dann passiert.
 
Kann ich bestätigen, neu machen ist beim SBS Umzug sinnvoller.
  • GPOs dokumentieren
  • verwende Konten von Diensten dokumentieren
  • lokale SQL Admins anlegen so SQL genutzt wird
  • parallel neue Domäne hochziehen, Exchange vorbereiten
  • Zum Stichtag alle Rechner in die neue Domäne hiefen mit leeren Postfächern, Dateiserver etc ebenfalls reinziehen, Berechtigungen setzen etc.
  • danach Exchange Migration über PST Dateien machen, Öffentliche Ordner gehen auch schon vorher.
  • SQL Berechtigungen neu für die Domäne einstellen, das Migrationskonto kann dann weg

Bei uns lief das mit 2-3 Wochen Vorbereitung, zu diesem Zeitpunkt stand die neue Domäne vollständig fertig da, Teil des Exchange war für Testzwecke schon portiert. Die eigentliche Migration lief dann Sa/So für etwa 50 Systeme, Rest dank Urlaub in der Folgewoche migriert.

Ich glaube das schlimmste waren die leeren Benutzerkonten für die Leute, Katastrophe, Leben verloren, am besten Selbstmord. :-X
 
Ich glaube das schlimmste waren die leeren Benutzerkonten für die Leute, Katastrophe, Leben verloren, am besten Selbstmord. :-X
https://www.forensit.com/de/domain-migration.html
/thread

Aber ernsthaft. Es ist eine Sache die Domäne komplett neu zu machen inkl. dem ganzen Aufwand, aber es ist eine andere Sache dann den Nutzern ein "mir doch egal das du von vorne anfangen musst" hinzuwerfen. Kostet alles Nerven, Goodwill, Zeit (und damit Geld). Das Geheule und Zähnegeklapper kann man sich damit auch gleich sparen (oder stark reduzieren) wenn während der Migration die Profile migriert werden. Letztlich müssen ja die Benutzer mit dem Krempel arbeiten. Nichts passiert hier zum Selbstzweck.
 
Kann ja auch jeder selber entscheiden ob und was er migriert. Ich wollte keine Altlasten des SBS mitschleifen und habe mich deshalb für komplett neu entschieden. Der Admin ist auch nicht kostenlos wenn er bei etwaigen Problemen hinterherrennen darf.
"Mir doch egal" hatte zumindest ich nicht behauptet. Es beschrieb grundsätzlich das Verhalten der Leute wenn sich irgendwas ändert, egal was.
 
Zurück
Oben