Domäne migrieren, mit Backup vom aktuellen DC möglich?

[lefg 276]

 

Ich sage nur: USN Rollback und Lingering Objects. Da

 

@.Assassin, Du wiesst was das bedeutet?

 

und ein Rollback ist es ja nicht, da das Image nicht auf dem selben Server widerhergestellt wird sondern eben in einer testumgebung, sodass das Produktivsystem unangetastet weiterlaufen wird.

 

Das Herstellen, Erzeugen einer sicher isoliertenTestumgebung aus einem Backkup der Produktionsumgebung ist natürlich möglich. Unter einem Wiederherstellen verstehe ich etwas anderes, es geschieht in der ursprünglichen Umgebung nach einem verlust.

 

Knackpunkt ist die wirklich sichere Isolierung. Der Soldat kann gar nicht so dumm denken wie es kommen kann. Klar?

bearbeitet 10. November 2016 von lefg

[magheinz 110]

Ich glaube ehrlich gesagt du trollst oder das ist eine schulaufgabe oder so.
Was sollen denn das bitte für serverkurse gewesen sein bei denen das als "fortgeschrittenes Thema" zählt? Seid ihr ein Linuxsystemhaus?

bearbeitet 10. November 2016 von magheinz

[NilsK 2.969]

Moin,

 

"Assassin", nichts für ungut, aber zum Vermitteln von Grundlagen oder tiefsten technischen Details ist ein Forum nicht geeignet.

 

Für das, was du vorhast, gibt es ein Standardverfahren, das seit 17 Jahren bewährt ist. Das Verfahren, das du skizziert hast, ist nicht geeignet. Eine Diskussion, welche technischen Abläufe in dem nicht geeigneten Verfahren eventuell oder auch nicht und vielleicht dann doch - führt zu gar nichts. Sie kostet nur Zeit.

 

 

Edit: Ich kann mich dunkel an einen "Sonderfall" erinnern: An einen fernen, neu einzurichtenden Standort war das Blech für den DC eingetroffen, eine Replikation mit dem DC im Higher Echolon wurde wegen der Leitungskapzität als nicht möglich angenommen.

Es wurde eine Sicherung des Systemstate angefertigt, die Datei an den fernnen Standort transportiert(LuTrans LTG 61) und daraus der DC hergestellt. Die genaue Vorgehensweise, der Parameter dafür ist mir nicht mehr gegenwärtig. Auch weiss ich nicht mehr, ob der Systemstate mit einem speziellen Parameter gesichert wurde oder der beim Herstellen des DC angewendet wurde. Ich habe die Operation damals lediglich begleitet.

 

das Verfahren nennt sich "Replicate from media" und ist auch nur genau für diesen einen Sonderfall gedacht. Mit Migrationen oder Domänenupdates hat es nichts zu tun.

 

Gruß, Nils

bearbeitet 10. November 2016 von NilsK

[Assassin 13]

Ich will nicht trollen oderr sowas...die lehrgänge waren jeweils 1 wöchige lehrgänge über SBS2011, oder Server 2008R2, und 2012R2, aber das waren mehr die "Basic" lehrgänge. Ein 2. DC innerhalb der Domäne wurde da nie mit angesprochen - obwohl mich genau das interessiert...

 

und die testumgebung ist natürlich isoliert, darum ist es ja eine testumgebung. Es hängt in keinster weise im selben Netzwerk wie das produktivsystem.

 

Und warum ich immer wieder frage? nun - ich komme aus dem tiefsten Osten, da wird viel improvisiert oder selber nachgeforscht wie man es auch machen könnte - den es heißt immer: Es gibt immer mehrere wege zum Ziel. Es gibt aus erfahrung nicht nur die wege wie sie im Buch'e stehen. Das herrausfinden dieser wege kostet zwar zeit - das ist richtig, allerdings spart es auch imens zeit wenn man das ganze mal öffter machen muss.

Fragt ihr euch den nicht, bzw. habt ihr es den noch nie geteste was passieren würde? Ich meine, man kann doch nicht alles glauben was einem gesagt wird. ein einfaches "Geht nicht" ist für mich kein grund dies nicht zutun (zumal ein "geht nicht" gibt es nicht), daher brauche ich eine erklärung, wo es dann scheitern wird, oder warum es nicht geht.

[magheinz 110]

On "geht nicht" ausreicht hängt vor allem davon ab wer das sagt.

Solange best practices zu einem Thema bestehen sollte man sich dran halten oder sie Abweichung gut begründen können.

Viel Zeit ist auch viel Geld...

 

Ich habs übrigens noch mal nachgelesen: Im ersten post willst du aus deiner Testumgebung den DC später produktiv nehmen oder zumindest wissen ob das geht. Die einhellige Antwort hier im Forum lautet: Blöde Idee. Akzeptiers oder bring neue Argumente.

bearbeitet 10. November 2016 von magheinz

[tesso 375]

Ich habe genügend Baustellen die abzuarbeiten sind. Da muß ich nicht noch Wege testen, die nicht empfohlen werden. Mein Tag hat nur 24 Stunden, die Nacht habe ich schon hinzugenommen.

[Dukel 457]

Ich will nicht trollen oderr sowas...die lehrgänge waren jeweils 1 wöchige lehrgänge über SBS2011, oder Server 2008R2, und 2012R2, aber das waren mehr die "Basic" lehrgänge. Ein 2. DC innerhalb der Domäne wurde da nie mit angesprochen - obwohl mich genau das interessiert...

 

und die testumgebung ist natürlich isoliert, darum ist es ja eine testumgebung. Es hängt in keinster weise im selben Netzwerk wie das produktivsystem.

 

Es geht nicht um die Testumgebung, sondern das du die Produktive am Ende in die Testumgebung dazuhängen willst.

Du kannst ein Backup deines DC's in der Testumgebung einspielen, kannst dort das richtige Vorgehen durchspielen und das was du dort gemacht hast in der Produktiven Umgebung nachspielen.

[Assassin 13]

hmm, da müsste ich ein backup von einem client-pc mit in die testumgebung nehmen, um dies richtig zu testen...hmm ja das geht natürlich auch :D

[monstermania 53]

Ich will nicht trollen oderr sowas...die lehrgänge waren jeweils 1 wöchige lehrgänge über SBS2011, oder Server 2008R2, und 2012R2, aber das waren mehr die "Basic" lehrgänge. Ein 2. DC innerhalb der Domäne wurde da nie mit angesprochen - obwohl mich genau das interessiert...

 

und die testumgebung ist natürlich isoliert, darum ist es ja eine testumgebung. Es hängt in keinster weise im selben Netzwerk wie das produktivsystem.

 

Und warum ich immer wieder frage? nun - ich komme aus dem tiefsten Osten, da wird viel improvisiert oder selber nachgeforscht wie man es auch machen könnte - den es heißt immer: Es gibt immer mehrere wege zum Ziel. Es gibt aus erfahrung nicht nur die wege wie sie im Buch'e stehen. Das herrausfinden dieser wege kostet zwar zeit - das ist richtig, allerdings spart es auch imens zeit wenn man das ganze mal öffter machen muss.

Fragt ihr euch den nicht, bzw. habt ihr es den noch nie geteste was passieren würde? Ich meine, man kann doch nicht alles glauben was einem gesagt wird. ein einfaches "Geht nicht" ist für mich kein grund dies nicht zutun (zumal ein "geht nicht" gibt es nicht), daher brauche ich eine erklärung, wo es dann scheitern wird, oder warum es nicht geht.

Boah,

was gibt es denn für 1 wöchige Lehrgänge zum SBS 2011!? Und warum dann noch Lehrgänge zum 2008R2 und 2012R2!?  :nene:

Das sind 3 Wochen Lehrgänge für sehr ähnliche Produktgruppen. Davon hätte ich nicht mal zu träumen gewagt. Mein erster und einziger 2-tägiger Lehrgang war seinerzeit irgendwas mit Windows NT Server. Seither war komplettes "Learning by Doing" bzw. Selbststudium angesagt. 

 

Grundsätzlich sollte man sich in der IT an die Empfehlungen/Best-Practices der jeweiligen Produkthersteller halten. Nur weil etwas prinzipiell irgendwie funktioniert bzw. funktioneren könnte, muss man dass nicht auch machen! Spätestens, wenn Dir ein 2nd-Level-Support eines Herstellers sagt, dass Deine Installation gegen die Systemvoraussetzungen verstößt und Sie daher leider keinen Produktsupport leisten, stehst Du b***d da. Den Fehler machst man genau einmal!

Es gibt nur einen guten Weg zum Ziel zu kommen. Mach es von Anfang an richtig!  :D

Ich teste ja auch nicht, ob ich nicht evtl. doch auch ohne Fallschirm aus dem Flugzeug springen könnte! Das haben schon Einige vor mir versucht. Und das Ergebnis war irgendwie nie schön!

Brauchst Ja nur hier im Forum mitzulesen. Irgendwann fällt einem schlechte (Vor)Arbeit immer wieder auf die Füße!

[testperson 1.729]

Ich teste ja auch nicht, ob ich nicht evtl. doch auch ohne Fallschirm aus dem Flugzeug springen könnte! Das haben schon Einige vor mir versucht. Und das Ergebnis war irgendwie nie schön!

https://www.welt.de/vermischtes/article157408836/Skydiver-meistert-Sprung-aus-7600-Metern-ohne-Fallschirm.html

 

SCNR

[Doso 77]

Wir haben bei uns im laufenden Betrieb drei Domain Controller in ein paar Stunden getauscht. Die Migration des Dienstes AD Domain Controller ist so einfach, schnell und stabil da muss man nix basteln oder versuchen schlauer zu sein wie Microsoft. Da machst du eher noch mehr kaputt als das es dir nutzt. So Versuche mit Image Backup wiederherstellen habe ich auch mal gemacht. In einer Testumgebung, die ich danach weggeworfen habe. Wie erwartet, und hier auch beschrieben kam es zu lingering Objects, Domain Controller die sich nicht mehr repliziert haben etc.

 

Um es kurz zu machen: Tue es nicht!

[Assassin 13]

Ok, dann lass ich das lieber. Ich werde aber dennoch - um zu sehen ob es funktionieren würde - ein Backup vom DC und ein backup von einem CLient in einer Testumgebung wiederherstellen, und da die Migration durchspielen um zu überprüfen, ob der DC das ohne probleme mitmachen würde.

Bin da immer etwas vorsichtig was das ganze angeht.

 

Die Frage ist allerdings auch - ob eine Migration bei 9 PCs innerhalb der Domäne lohnt? Es gibt ja auch dieses EasyTransfer tool von Microsoft, was lt. faq-o-matic auch für eine überschaubare anzahl an CLients genutzt werden kann...was ist aber eine überschaubare anzahl von Clients? :D

 

Hinzu kommt ja noch der Exchange 2010, welcher zu 2016 migriert werden soll. Da gibts ja auch verschiedene wege um ans ziel zu kommen, u.a. die PST Migrations art...aber wenn ich mich recht entsinne, war es dann immer so eine sache mit diesen x400 adressen *grübel*

 

 

und wegen den LEhrgängen - die wurden uns kostenlos, bzw. sehr kostengünstig angeboten - darum ;)

an sonsten herrscht auch bei mir: Learning by Doing - damit merkt man es sich wenigstens auch eher.

[NorbertFe 2.096]

Eine Migration sowohl des ad als auch des Exchange ist schneller, einfacher und für den Nutzer fast unspürbar im laufenden Betrieb durchzuführen und hat zusätzlich hinterher kaum wirkliche Altlasten zu beseitigen. Jede Neuinstallation zum "Altlasten bereinigen" verursacht in den meisten Fällen Probleme, die man mit einer Migration gar nicht gehabt hätte. Da das aber meist Leute tun, die beides nicht gegeneinander abwägen können oder wollen, gibt's solche Diskussionen regelmäßig. ;)

[NilsK 2.969]

Moin,

 

vielleicht darf ich noch mal darauf hinweisen, dass du gar keine AD-Migration durchführen willst. Du machst ein Domänen-Update, indem du der bestehenden Domäne einen neuen DC mit einem aktuelleren Betriebssystem hinzufügst. Wenn man nicht mutwillig etwas anstellt, ist das praktisch ohne Risiko.

 

Bei Exchange kann man von einer Migration sprechen, aber auch da ist der Vorgang eigentlich derselbe - weswegen man es eben auch als Update bezeichnen kann. Neue Version von Exchange in die bestehende Umgebung (Alt und Neu kennen einander), Mailboxen verschieben, Verbindungen anpassen. Fertig. Ebenfalls praktisch ohne Risiko, vielleicht gibt es zwei, drei (korrigierbare) Stolperstellen.

 

Bitte nicht aus lauter Unwissenheit einen nicht unterstützten Weg gehen, den am Ende niemand mehr korrigiert bekommt. Es ist ja nicht so, dass die empfohlenen Verfahren nicht dokumentiert wären.

 

Gruß, Nils

PS: Ich mach hier mal Schluss, viel Erfolg und Vergnügen noch.

[NorbertFe 2.096]

Offiziell heißt die "Migration" von Exchangeserver zu Exchangeserver in der selben Domain "Transition" afair. ;)

bearbeitet 13. November 2016 von NorbertFe