Jump to content

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


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Recommended Posts

MoinMoin,

 

Wir wollen unseren alten 2008r2 server ersetzen gegen ein neues Blech, wo Server 2016 drauf soll. Die Domäne möchten wir migrieren, damit die Clients kein neues profil bekommen. Nun möchte ich aber ungern den neuen DC mit unserem aktuellen produktiv-DC koppeln um diesenzu migrieren (böse erfahrung in der vergangenheit was einige Graue haare sprießen lassen hat ;-( )

Da stellt sich mir die Frage: was ist, wenn ich ein image-backup von unserem aktuellen 2008r2 DC nehme, dieses auf einem normalen Test PC widerherstelle, und dann dieses system zu migrationszwecke in einem abgetrennten netzwerk nutze, um somit den neuen 2016er server vorzubereiten, sodas wenn alles fertig ist, wir nur den alten 2008erR2 abstecken brauchen, den neuen dafür dran, und es direkt weitergehen kann?

 

Ist das möglich? oder bekommt der aus eineem backup migrierter DC es mit, das seine DNS, bzw. AD Daten älter sind als die auf den Clients?

 

Es soll nur einen DC geben.

die restlichen daten liegen alle auf andere Server, da ist der umzug weniger kompliziert.

 

Exchange gibt es zwar auch noch, aber da wird es ja nur mit einer "live-Migration" gehen, es sei den ich knipse für eine weile das Port25 Forwarding aus, sodass ich auch das exchage aus einem backup migrieren könnte.

 

 

 

Ich möchte einfach nicht mehr mit produktiv-systemen solche migrationen machen, da ich wie gesagt in der vergangenheit schoneinmal böse überraschungen bekommen hatte...wie abstürzende Quell-Server, oder das es migrationsfehler gab...

Link to comment

Hi,

 

nein, so (definitiv) nicht! Du könntest ein Backup machen und in einem getrennten Netz restoren und dann die Migration als Test durchgehen. Wenn es dann keine Probleme gibt, sollte das auch im produktiven Netz ebenso gelingen.

Migrationsfehler sitzen leider meistens vorm Bildschirm. Ein AD ist eigentlich sehr schwer kaputt zu kriegen.

 

Gruß

Jan

Link to comment

Moin,

 

ihr wollt nicht migrieren, sondern eure Domäne aktualisieren.

 

Windows Server 2016 installieren, in die Domäne aufnehmen, zum zusätzlichen DC der Domäne hochstufen. Schema-Upgrade usw. läuft von selbst, Replikation sowieso. Clients bekommen nichts mit. Risiko praktisch Null.

Deinen bisherigen Plan wirfst du bitte in den Papierkorb.

 

Nur einen DC zu haben, ist in einer Umgebung mit mehr als 10 Arbeitsplätzen grob fahrlässig.

 

Gruß, Nils

Link to comment

Theoretisch könnte das Vorhaben aber unter gewissen Umständen durchaus funktionieren..

Dafür würde ich aber weder Zeit in einer Testumgebung verschwenden geschweige denn das ganze in einem produktiven Netz machen. Zumal die supporteten Wege deutlich einfacher und eben supportet sind ;)

 

Nichtsdestotrotz schiebst du den Gedanken mit gedrückter Shift Taste in den Papierkorb!

Link to comment

Moin,

 

Theoretisch könnte das Vorhaben aber unter gewissen Umständen durchaus funktionieren..

 

wird das hier ein Jehova-Wettbewerb? ;)

 

Ich sage nur: USN Rollback und Lingering Objects. Das einzige, was mit Sicherheit funktioniert, ist das Erzeugen von vermeidbaren Schäden.

 

Der wichtige Satz ist der mit der Shift-Taste. :D

 

Gruß, Nils

Link to comment
wird das hier ein Jehova-Wettbewerb? wink.gif

Er hat Jehova gesagt!

 

Das wäre eher so die "Probe aufs Exempel", dass so ein AD eben doch sehr robust und schwer kaputtbar ist, selbst wenn man da mutwillig rangeht. Und in den "gewissen Umständen" war ein anschließendes ordentliches "durchwischen" im AD inkludiert.

 

Alleine der Restore des Images dürfte ebenfalls länger dauern wie der empfohlene Weg.

Link to comment

Ich frage mich aber, wieso das nicht funktionieren wird? ein USN rollback gibt es doch meines wissens nach nur, wenn man einen 2. DC innerhalb der Domäne mit einem einfachen Image-Backup zurücksetzt - dann wird dieser DC nicht mehr akzeptiert werden...zumindest konnte ich es so mal testen - habs allerdings in meiner testumgebung auch nicht hinbekommen, das sich die beiden server wieder vertragen, also die konflikte aufgehoben wurden :-/

 

Bei meiner idee hier ist es aber so, das es eben nur einen DC innerhalb der Domäne gibt. Wenn man das Backup also auf einer Test-Maschine wiederherstellt, gibt es kein USN rollback, da die maschine ja nur sich selber kennt, und ihr es somit egal ist, zu welchem zeitpunkt die Maschine wiederhergestellt wurde. Wenn ich diese platform dann als quelle für die migration auf den neuen Server2016 nutze sollte es doch eigentlich auch alles klatt laufen.

 

Aber ab wann ist der punkt wo der neue DC dann mitbekommt, das da etwas nicht stimmt? Ich vermute mal wenn sich die Clients anmelden wollen, oder? da die clients ja immernoch den alten, echten 2008r2 kennen, und dann plötzlich die sich auf einen 2016er anmelden sollen, oder?

 

Aber was genau passiert da? das würde mich im kernpunkt interessieren :D

 

 

und wegen dem 2. DC...ich kenne echt sehr viele Admins, die selbst in einer 50 PC Unternehmen nur einen DC haben...allerdings gibt es da eine Hochverfügbarkeitslösung (Stratus everRun enterprise)

 

 

Ich wünschte ich könnte mehr über die sache mit den 2 DCs erfahren, auch wenn man 2 exchange server im einsatz hat, also das ganze so redundant ist, das man bequem windows-updates aufspielen kann, ohne das es für die Clients eine Downtime gibt wenn der Server neugestartet werden soll...

Aber solche lehrgänge bleiben mir verwehrt :( Und zeit um das selber in einer testumgebung zu erlernen fehlt mir da leider...ich meine, ich hatte schon manchmal 2 DCs am laufen, allerdings hat es nie mit dem Failover geklappt, also wenn der "master" DC abgeschaltet wurde, konnten die Clients sich nicht mehr sauber anmelden auf dem 2. DC, obwohl dieser als 2. DNS eintrag auf dem Client eingestellt war. sicherlich muss man da noch etwas mehr einstellen.

Beim Exchange war es sogar so, das sobald der 2. exchange da war, ein Mailing garnicht mehr möglich war, solange der neu hinzugefügte, 2. exchange server aktiv war -.-

 

 

Könnt ihr mir event. Bücher empfehlen, oder Deutsch-sprachige websites wo sowas erklärt wird?

Link to comment

Wenn du keine Zeit hast in einer Testumgebung rumzuspielen, wann willst du die Bücher lesen?

Nix für ungut, es gibt gute Bücher, aber ohne "spielen" zu können nützt das beste Buch nix.

 

Da du schon Probleme bei den Grundlegenden Dingen hast solltest du unbedingt weiter versuchen Schulungen zu bekommen. Wenn du das verbockst, wozu die chancen echt gut stehen, dann ist doch dein Job in Gefahr.

Link to comment

ich bin kein reiner admin...ich mach das eher weil mir das spaß macht, mir neues wissen anzueignen. Und weil ich mich in unserer kleinen Firma damit auch am besten auskenne, weil ich mich schon seit meiner kindheit intensiev mit PC technik befasse, und für manche kunden mitlerweile unverzichtbar bin weil ich einiges hinbekommen habe, wo andere daran gescheitert sind.

Ich habe ja schon einige Domänen sauber migriert, auch exchange, aber einmal hat es eben sowas von garnicht geklappt, und daher ist jetzt immer so ein bitterer beigeschmack dabei :-/

Daher interessiert es mich, warum es zu einem USN Rollback kommen würde, ich möchte es gerne verstehen wa genau da abläuft das es soweit kommt?

 

Ich habe schon viel durch euch hier dazu gelernt, und dafür möchte ich mich bei euch ganz doll bedanken für die tolle Unterstützung:-)

Edited by Assassin
Link to comment

Werter Assassin,

 

hier wird dir von deiner angepeilten Vorgehensweise abgeraten von erfahrenen Profis, Ich habe aber den Eindruck, Du nist ein Amateur. Du kannst den Rat befolgen oder nicht, es ist deine Sache.

 

Ich habe früher auch mal riskante Experimente gemacht, bei einigen lag ich aber nicht richtig, ich ging nicht über Los, ich rutschte direkt in die Sc***e.

 

Wenn eine gesicherte, anerkannte Vorgehensweise zur Verfügung steht, warum dann ein völlig unnötiges Risiko eingehen?

 

Viel Erfolg

 

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.

 

Nochmals deutlich, es wurde kein Full -Backup des DC, des Rechners, der Platte gemacht, es war lediglich der Systemstate.

Edited by lefg
Link to comment

wir sind schon im IT bereich tätig, aber eben nur eine kleine Firma. Ich hatte ja schon einige Serverlehrgänge, aber eben keine solch fortgeschrittene (welcher das thema mit den mehreren DCs innerhalb einer Domäne beinhalten würde)

Und den Rat werde ich auch befolgen, keine frage. Mich würde einfach nur interessieren, warum es da zu fehlern kommen wird.

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.

Link to comment
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...