AD für Testumgebung clonen

[Mag 11]

Hallo allerseits,

 

ich wollte teile unserer AD Umgebung clonen um eine Testumgebung zu erstellen, für das Inplace Update auf Windows 2008.

 

Ich habe dazu 4 Images (Dauer insg. ca. 2-3h) erstellt und diese in einer virtuellen Umgebung wiederhergestellt. Allerdings nervt mich nun das Eventlog u.a mit Events 1988. Ich habe gelesen, dies bedeutet, das veraltete Objekte das Zusammenspiel stören.

 

Ich konnte nicht richtig rausfinden, welches Objekt nun das veraltete ist. Die DCs konnten halt unter einander während meiner Imagephase noch hin und her replizieren. Gibts eine bessere Möglichkeit eine Testumgebung zu erstellen oder sollte man sich die Arbeit machen und das AD ans Laufen bringen?

 

Leider kann man ja nicht alle DCs gleichzeitig ausschalten.

Zur Umgebung:

Forest (20 DCs, nur 4 davon sind relevant)

1 Root Domäne 2 DCs Win2k3 Rs 64bit, beide GC

1 Subdomäne 2 DCs Win 2k3 Rs 64bit, beide GC

andere subdomänen sollen abgeschafft werden, müssen im Moment nicht weiter beachtet werden, keine GC's

bearbeitet 7. Juni 2010 von Mag

[Daim 12]

Hola,

 

Allerdings nervt mich nun das Eventlog u.a mit Events 1988.

 

dann erscheint diese Fehlermeldung auch in der produktiven Umgebung?

 

Ich habe gelesen, dies bedeutet, das veraltete Objekte das Zusammenspiel stören.

 

Genau. Auf einem DC existieren noch herumlungernde Objekte (Lingering Objects). Das bedeutet, auf einem (oder mehreren) DC existieren noch Objekte, die auf den anderen DCs bereits gelöscht wurden. Die Ursachen können Konnektivitäts-, Namensauflösungs- oder AD-Replikationsprobleme sein.

 

Ich konnte nicht richtig rausfinden, welches Objekt nun das veraltete ist.

 

Mit dem folgenden Befehl kannst du dir die Objekte anzeigen lassen:

 

REPADMIN /removelingeringobjects <FQDN des “veralteten” DCs> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten

Objekte befinden> /Advisory_Mode

 

Anschließend wird für jedes veraltete Objekt im Eventlog die EventID 1946 protokolliert. Diese kannst du dann entweder mit dem gleichen Befehl allerdings ohne den Parameter /Advisory_Mode oder mit ADSIEdit entfernen.

 

Lies dir diesen Artikel durch, dann sollte es klarer werden:

 

LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte)

 

Die DCs konnten halt unter einander während meiner Imagephase noch hin und her replizieren.

 

Die Vorgehensweise war ungeschickt. Du hättest z.B. mit dem kostenlosen VMWare Converter dir eine VM eines DCs erstellen können und dort dein Inplace Update (was im Übrigen nicht empfohlen ist) durchführen.

 

Gibts eine bessere Möglichkeit eine Testumgebung zu erstellen oder sollte man sich die Arbeit machen und das AD ans Laufen bringen?

 

Siehe vorherigen Absatz.

[Mag 11]

Einen schönen guten Morgen und danke für die Antwort :)

 

Die Fehlermeldung erscheint in der Live Umgebung nicht. Eventuell war ich zu hastig mit dem Löschen, der 16 nicht relevanten DCs, wie oben beschrieben.

 

Der Tip mit dem Eventeintrag 1946 war sehr gut, dass wusste ich nicht. Das werde ich dann auf jeden Fall gleich noch testen.

 

Ich wollte es erst mit dem VM Converter machen. Das dauert nur etwas lange und dann bin ich auf die Imagevariante gewechselt, damit die Zeitspanne der Images bzw. Kopien nicht noch größer wird. Dachtest du an Coldcloning, also mit Reboot, oder im Betrieb?

 

Ich hatte das Inplace Update favorisiert, weil ich dann die Hardware für die DCs und Namen, Dienste, Rollen auch genau so weiterbetreiben kann.

 

Das Inplace-Update wollte ich ehm, nach dieser Anleitung durchführen *hust* :D

Danke für die Tipps.

[Daim 12]

Die Fehlermeldung erscheint in der Live Umgebung nicht.

 

Das ist auch gut so.

 

Eventuell war ich zu hastig mit dem Löschen, der 16 nicht relevanten DCs, wie oben beschrieben.

 

Wo genau hast du nochmal geschrieben, dass du die 16 DCs in der Testumgebung entfernt hast? ;)

 

Das dauert nur etwas lange

 

Wenn es sich um "echte" DCs handelt die keine weiteren Dienste zur Verfügung stellen, ist das doch in kurzer Zeit durch.

 

Dachtest du an Coldcloning, also mit Reboot, oder im Betrieb?

 

Ich denke an gar kein Imagen. Aber wenn du doch dein Inplace Update testen möchtest, dann erstelle dir doch ein Image von nur einem DC und teste das Inplace Update dann in einer abgeschotteten VM.

 

Ich hatte das Inplace Update favorisiert, weil ich dann die Hardware für die DCs und Namen, Dienste, Rollen auch genau so weiterbetreiben kann.

 

OK, du willst also wenig Arbeit damit haben. ;)

 

Das Inplace-Update wollte ich ehm, nach dieser Anleitung durchführen *hust* :D

 

Sehr gute Wahl. :cool:

[Dopamin 10]

Hallo zusammen,

 

ein kleiner Erfahrungsbericht:

 

Das Inplace Update habe ich bei uns testweise auch mal durchgeführt. Allerdings sind unsere DCs fast alle virtuell auf einem vSphere Server, sodass man schnell einen Snapshot auf einen freien Server schieben kann zum Testen :cool:.

 

Ich musste für das Update erst umständlich die Powershell 1.0 aus dem 2k3er entfernen und nach Abschluss der Installation gab es dann so tolle Sachen im Startmenü wie : Verwaltung & Verwaltung (migriert). Gleiches gabs auch beim Zubehör :suspect:. Ob das die Funktion groß beeinträchtigt kann ich nicht sagen, aber wirklich sauber sah das ganze nicht aus. Daher habe ich das Inplace Update nicht prod. gesetzt.

 

 

Gruß

[Daim 12]

Allerdings sind unsere DCs fast alle virtuell auf einem vSphere Server,

 

Alle virtuellen DCs sind auf einem Host?

 

aber wirklich sauber sah das ganze nicht aus. Daher habe ich das Inplace Update nicht prod. gesetzt.

 

Solche Effekte können eben bei einem Inplace Update vorkommen. Daher sollte die Domänenaktualisierung mit einer zusätzlichen Maschine durchgeführt werden.

[Mag 11]

:cool:

Das mit dem Löschen, ja das ... hatte ich euch wohl verschwiegen. Das war dann ebenfalls ungeschickt!

Die Idee war, weniger Fehlermeldungen zu erhalten, durch die nicht-erreichbaren Server. Aber das lasse ich dann im ersten Schritt mal weg.

 

Ich weiß auch nicht warum der VM Converter pro Server eine Stunde gebraucht hätte.

Aber trotzdem nochmal eine kleine Rückfrage, mit dem VM Converter kann man ja diese 2 Methoden wählen, entweder im Betrieb (es installiert sich ein kleiner Dienst) oder man bootet von der Converter CD (Coldclone). Ich wollte nicht, dass sich ein Dienst installiert, daher hatte ich von CD gebootet. War das in deinem Sinn?

 

Ich wollte nach den Inplace Update auch gerne einmal schauen ob die ganze Domäne noch funktioniert, deshalb auch gleich alle 4

[Daim 12]

Aber das lasse ich dann im ersten Schritt mal weg.

 

Du machst aber auch ein Geweih... ;)

 

Ich weiß auch nicht warum der VM Converter pro Server eine Stunde gebraucht hätte.

 

Das halte ich persönlich für erträglich. Die Zeit des konvertierens hängt von vielen Faktoren ab (größe der HDD, wohin wird konvertiert, Hardware des Quellservers etc.).

 

Ich wollte nicht, dass sich ein Dienst installiert, daher hatte ich von CD gebootet. War das in deinem Sinn?

 

Bei der online Variante installiert sich ein Agent auf dem Server, der wenige MB beträgt. Dieser ist unkritisch. Aber du kannst auch die Cold Clone Variante wählen, um dein Inplace Update zu testen.

 

Ich wollte nach den Inplace Update auch gerne einmal schauen ob die ganze Domäne noch funktioniert, deshalb auch gleich alle 4

 

Dazu benötigt man doch keine vier DCs, wenn dann reichen höchstens zwei.

[NilsK 2.930]

Moin,

 

nur mal so ganz am Rande: Ich halte es in den meisten Situationen überhaupt nicht für eine gute Idee, ein Testsystem durch Cloning zu erzeugen.

 

Kaum ein Tester denkt nämlich daran, dass die so erzeugte Testumgebung exakt so sicherheitskritisch ist wie die Realumgebung: Dieselben Konten, dieselben SIDs, dieselben Kennwörter ... dieselben Realdaten, dieselben vertraulichen Informationen ... usw.

 

Das ist so lange beherrschbar, wie man die Testumgebung entsprechend behandelt. Da die meisten Testumgebungen aber wesentlich laxer behandelt werden (Zurücksetzen von Kennwörtern, Verschieben auf Hosts im Labor, Daten exportieren ...) und sich manchmal physisch in einer Abstellkammer befinden, rate ich ganz dringend vom Cloning für Testzwecke ab!

 

Gruß, Nils

[Dopamin 10]

Alle virtuellen DCs sind auf einem Host?

 

Nein natürlich nicht. Und einen physikalischen Server gibt es auch :cool:

 

Kaum ein Tester denkt nämlich daran, dass die so erzeugte Testumgebung exakt so sicherheitskritisch ist wie die Realumgebung: Dieselben Konten, dieselben SIDs, dieselben Kennwörter ... dieselben Realdaten, dieselben vertraulichen Informationen ... usw.

 

Dem Stimme ich zu, wobei solche Leute dann auch lieber nicht "Tester" sein sollten ;). Liegt die Testmaschine allerdings auf einem Server, welcher physikalisch neben dem Mainsystem platziert ist und welcher mit Isolierten Netzen etc. arbeitet; sehe ich bei einem DC da keinerlei Probleme bezüglich der Datensicherheit. Schließlich sollte das Inplace Update (in diesem Falle) getestet werden und danach die VM wieder gelöscht werden...

[Daim 12]

Huhuu,

 

Kaum ein Tester denkt nämlich daran, dass die so erzeugte Testumgebung exakt so sicherheitskritisch ist wie die Realumgebung

 

doch, dass tun die meisten Unternehmen sogar. Denn in vielen Firmen existiert doch bloß eine "Test" und keine produktive Umgebung. Und ein Clone von einem Testsystem kann ja nicht so schlimm sein. SCNR! :cool:

[blub 115]

die Lösung, die nicht nur für die Bereitstellung und Pflege einer Parallelumgebung Vorteile bietet, ist eine durchgängige Automation. Änderungen an der Umgebung erfolgen nur über Skripte und Pakete, gesteuert durch einen Releaseprozess.

 

Dann kannst du jederzeit Parallelumgungen auch unter anderem DomainNamen hochziehen und weisst, was rauskommen wird.

Testumgebungen und Produktionsumgebungen unter gleichem Namen, verwaltet von denselben Leuten evtl. mit gleichem Account, bergen ein ziemliches Risiko administrativer Fehler!

 

cu

blub

[Mag 11]

Um alle Freunde der Sicherheit zu beruhigen. Die absolut identische Kopie des Forest ist in einem abgeschlossenen Netzbereich auf dem ESX Host, mit geänderten Passwörtern, roten "Warn" Farbschema und nur von einem Bruchtteil der Admins aus der Live Umgebung zugänglich.

 

Zudem finde ich wiegt das Sicherheitsrisiko der Kopie wesentlich geringer, als das verfummeln der Live-Umgebung.

 

- Update -

 

Wäre es möglich als alternative zum Inplace Update unter Nutzung eines zusätzlichen DCs während der Migration, immer einen alten DC aus dem AD zu entfernen und einen neuen mit dem gleichen Namen wieder einzugliedern?

bearbeitet 8. Juni 2010 von Mag

[Daim 12]

Wäre es möglich als alternative zum Inplace Update unter Nutzung eines zusätzlichen DCs während der Migration

 

Merke: Du führst keine Migration, sondern eine Domänenaktualisierung durch. ;)

 

immer einen alten DC aus dem AD zu entfernen und einen neuen mit dem gleichen Namen wieder einzugliedern?

 

Ja, dass ist möglich. Wenn der "alte" DC erfolgreich mit DCPROMO heruntergestuft wurde solltest du sicherstellen, das der Server nicht mehr im DNS und ggf. WINS zu finden ist. Dann kannst du einen zusätzlichen Server mit gleicher IP-Adresse und gleichem Computernamen zum DC stufen.

[Mag 11]

===================================

Update:

Kommando zurück, es hat sich eingependelt :)

===================================

 

Sorry für die längere Bearbeitungszeit eurer vielen Tipps. Ich habe es heute endlich geschafft die 4 beschriebenen DCs mit dem VMware Converter auf den ESX zu clonen.

 

Nun habe ich nach dem Start und einstellen der IP Adressen folgendes Problem, welches mir DCDIAG anzeigt:

 

The directory service on dc-1 has not finished initializing. In order for the directory service to consider itself synchronized, it must attempt an initial synchronization with at least one replica of this server's writeable domain. It must also obtain Rid information from the Rid FSMO holder.

 

The directory service has not signalled the event which lets other services know that it is ready to accept requests. Services such as the Key Distribution Center, Intersite Messaging Service, and NetLogon will not consider this system as an eligible domain controller.

 

Pendelt sich das wieder von alleine ein oder muss ich da irgendwo nachhelfen. Es steht nun schon seit ner Weile in dem Zustand, daher die Frage.

 

Im Moment geht der DNS Dienst, da er keine Verbindung zur AD aufbauen kann. Ohne den, geht natürlich wenig. Bisher habe ich nur mal einen Neustart gemacht, der leider nicht geholfen hat.

bearbeitet 7. Juli 2010 von Mag