Server 2012 ad auf server 2012 r2 migrieren
Hallo zusammen,
Ich habe vor ein paar Jahren den Anfänger Fehler schlecht hin gemacht und habe alle Server Rollen auf einen physischen Server gelegt ohne vms. Das spürt man auch deutlich an der Geschwindigkeit, da ja der write cache deaktiviert wird.
Momentan sind also alle Rollen auf einem Server 2012. Ich habe bereits eine VM mit Server 2012 r2, darauf würde ich jetzt gerne die ad migrieren. Wir sind ein kleines Unternehmen mit 10 Usern allerdings geht es mir primär um die gpo Einstellungen die ich ungern alle neu machen würde.
Welche Methode würdet ihr mir empfehlen um die active directory zu migrieren?
LG,
Thomas
Ich habe vor ein paar Jahren den Anfänger Fehler schlecht hin gemacht und habe alle Server Rollen auf einen physischen Server gelegt ohne vms. Das spürt man auch deutlich an der Geschwindigkeit, da ja der write cache deaktiviert wird.
Momentan sind also alle Rollen auf einem Server 2012. Ich habe bereits eine VM mit Server 2012 r2, darauf würde ich jetzt gerne die ad migrieren. Wir sind ein kleines Unternehmen mit 10 Usern allerdings geht es mir primär um die gpo Einstellungen die ich ungern alle neu machen würde.
Welche Methode würdet ihr mir empfehlen um die active directory zu migrieren?
LG,
Thomas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 332636
Url: https://administrator.de/forum/server-2012-ad-auf-server-2012-r2-migrieren-332636.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
10 Kommentare
Neuester Kommentar
Moin.
Neuen Server in die bestehende Domain aufnehmen, als DC promoten, alle FSMO Rollen auf den neuen DC übertragen, DNS Server für Clients anpassen, vollständige Synchronisierung inkl. DNS abwarten, den alten Server demoten eine Zeit lang beobachten ob alles nach Wunsch läuft, und Ihn dann abschliessend aus der Domäne nehmen. Alternativ das Blech weiterhin als Fallback-DC weiterbetreiben, falls dein VM-HOST abraucht.
Gruß p.
Welche Methode würdet ihr mir empfehlen um die active directory zu migrieren?
Ein Klassiker:Neuen Server in die bestehende Domain aufnehmen, als DC promoten, alle FSMO Rollen auf den neuen DC übertragen, DNS Server für Clients anpassen, vollständige Synchronisierung inkl. DNS abwarten, den alten Server demoten eine Zeit lang beobachten ob alles nach Wunsch läuft, und Ihn dann abschliessend aus der Domäne nehmen. Alternativ das Blech weiterhin als Fallback-DC weiterbetreiben, falls dein VM-HOST abraucht.
allerdings geht es mir primär um die gpo Einstellungen die ich ungern alle neu machen würde.
Zur Info: Die lassen sich immer auch separat exportieren.Gruß p.
.. und als kleine Anmerkung
Das ist kein Anfängerfehler. Es gilt noch immer als Best Practice in einer virtuellen Umgebung einen DC als physischen Server zu betreiben.
Bei einem AD mit 10 Clients darfst du das nicht spüren. Bzw. wie definierst du "spüren"?
LG Günther
Ich habe vor ein paar Jahren den Anfänger Fehler schlecht hin gemacht und habe alle Server Rollen auf einen physischen Server gelegt ohne vms
Das ist kein Anfängerfehler. Es gilt noch immer als Best Practice in einer virtuellen Umgebung einen DC als physischen Server zu betreiben.
Das spürt man auch deutlich an der Geschwindigkeit, da ja der write cache deaktiviert wird.
Bei einem AD mit 10 Clients darfst du das nicht spüren. Bzw. wie definierst du "spüren"?
LG Günther
@thomasreischer:
Terminalanwendungen? Bedeutet das, daß Du den DC auch als zentralen Anwendungsserver, oder - schlimmer - als Terminalserver nutzt? Das wäre in der Tat nicht ideal. Deine virtuelle Umgebung erlaubt es Dir doch eigentlich, solche Dinge auf eigenen Servern zu separieren!?!
S-Firm in der Netzwerkvariante kopiert beim Starten am Client viele hundert MB vom Server zum Client. Auch wenn ich finde, daß keine Anwendungen auf einen DC/DNC/DHCP gehören, nach der Beschreibung Deiner Hardware sollte S-Firm trotzdem keine Probleme machen, es sei denn, Du betreibst nur ein Ethernet-LAN mit 10 Mbit/s.
Viele Grüße
von
departure69
Terminalanwendungen? Bedeutet das, daß Du den DC auch als zentralen Anwendungsserver, oder - schlimmer - als Terminalserver nutzt? Das wäre in der Tat nicht ideal. Deine virtuelle Umgebung erlaubt es Dir doch eigentlich, solche Dinge auf eigenen Servern zu separieren!?!
S-Firm in der Netzwerkvariante kopiert beim Starten am Client viele hundert MB vom Server zum Client. Auch wenn ich finde, daß keine Anwendungen auf einen DC/DNC/DHCP gehören, nach der Beschreibung Deiner Hardware sollte S-Firm trotzdem keine Probleme machen, es sei denn, Du betreibst nur ein Ethernet-LAN mit 10 Mbit/s.
Viele Grüße
von
departure69
Hallo,
Terminalserver auf einem DC sollte eh nicht sein...
Wenn Du auf dem Server selber alle Rollen und Hyper-V installiert hast und dann eine VM mit Terminalserver betreibst solltest Du auf Youtube mal HyperV Videos anschauen, denn das ist keine gute Idee.
Gruß
Chonta
llerdings laufen unsere terminal Anwendungen nicht immer perfekt.
Beschreibe Dein setup mal bitte etwas genauer.Terminalserver auf einem DC sollte eh nicht sein...
Wenn Du auf dem Server selber alle Rollen und Hyper-V installiert hast und dann eine VM mit Terminalserver betreibst solltest Du auf Youtube mal HyperV Videos anschauen, denn das ist keine gute Idee.
da ja der write cache deaktiviert wird
Wenn die systempartition ein eigener RAID ist oder zumindest unterschiedliche Partitionen verwendet werden, sollte für alles was nicht System ist auch der Cache aktiviert werden können (vorausgesetzt, die AD Datenbank ist nicht wo anders abgelegt)Gruß
Chonta
Sfirm läuft komplett auf dem Terminalserver - da läuft nichts über smb freigaben.
Ja, ich habe in meiner ursprünglichen Frage ja schon gesagt, dass das ein großer Fehler war..
Nein, das, was Du zunächst als Fehler bezeichnetest, nämlich, den DC in Hardware aufgesetzt zu haben, ist kein Fehler, sondern nach wie vor Microsoft-Best-Practise, wie auch @GuentherH weiter oben schon schrieb.
Aber ich kapier' noch nicht, wo die anderen Sachen, die Du so nach und nach alle aufzählst, laufen.
Hast Du (insgesamt) nur die eine physische Maschine und hast die per Rolleninstallation auch noch zusätzlich zum HYPER-V und zum TS/RDS gemacht? Das wäre tatsächlich fatal. Solche Dinge gehören auf jeden Fall voneinander getrennt.
Falls meine Annahme stimmt, besorg Dir noch ein weiteres Blech (bissel schwächer als das jetzige reicht), installiere Windows Server (2008 R2 oder höher), nimm ihn in die Domäne auf, stufe ihn zum DC hoch und verschiebe alle FSMO auf diesen.
Den stärkeren Server danach backuppen, plattmachen und mit Windows Server neu installieren. Darin nur die HYPER-V-Rolle installieren. Dann hast Du erstmal einen (noch leeren) HYPER-V, der nur HYPER-V ist (so, wie sich das auch gehört).
Und in dem HYPER-V kannst Du dann einen virtuellen TS/RDS aufsetzen sowie einen virtuellen Server, der alles andere macht, was noch übrigbleibt (Filedienste, AV-Dienste, Druckdienste, Anwendungsdienste).
Das nenne ich dann erst sauber, vorher nicht.
Müßte an einem seeeehr langen Wochenende (Nächte mitgerechnet) hinzukriegen sein .
Viele Grüße
von
departure69
Ja, alle Rollen auf einem blech.
Wir sind ein sehr kleines Unternehmen,
Wir sind ein sehr kleines Unternehmen,
Deswegen auf dem Blech NUR Hyper-V Rolle und alles weitere über VM bei Server 2012 und 2012R2 darf man wenn man auf dem Blech nur Hyper-V installiert 2 VM mit dem Server OS betreiben und darüber kann man dann z.B. eine VM als DC die andere Als exchange oder Fileserver machen, wobei auch der DC dann Fileserver machen kann.
Wenn man das su macht, hat man auch weniger Einbußen.
Wenn man umbedingt alles auf dem Blech machen will, muss man RAID und Partitionen halt so auslegen, das der Chace für alles nicht DC an sein kann.
Gruß
Chonta
Irgendwie weicht das jetzt alles von seiner ursprünglichen Frage ab. Die übliche Methode zur Migration des AD wurde ja eigentlich schon oben beschrieben.