Haben mehrere Benutzer die gleiche Anforderung, um zum Beispiel auf die gleiche Ressource oder Freigabe zuzugreifen, ist es empfehlenswert den Zugriff der jeweiligen Gruppe zu erteilen und nicht einzelnen Benutzerkonten.
Wann immer eine Maßnahme nicht nur einen Benutzer, sondern mehrere betrifft, bieten sich Gruppen an.
Wenn die Rede von einer Gruppe ist, betrifft das automatisch auch alle als Mitglieder geführten Benutzer.
Das bedeutet, eine Berechtigung die einer Gruppe zugeteilt wurde, gilt automatisch auch für alle Benutzer die ihr als Mitglied angehören.

Das Active Directory kennt dabei zwei Gruppentypen, von denen einer bei der Erstellung einer Gruppe ausgewählt werden muss.
Falls sich die Domäne im einheitlichen Domänenfunktionsmodus befindet (Windows 2000 pur oder Windows Server 2003), ist es möglich eine Umwandlung des Gruppentyps (über den Umweg einer universelle Gruppe, das geht aber nicht wenn die Mitgliedschaftsregeln nicht eingehalten werden können) zu einem späteren Zeitpunkt zu ändern. In beiden Ebenen wird das Verschachteln von Gruppen, zum Beispiel eine globale Gruppe in eine andere globale Gruppe unterstützt, nicht aber in den Domänenfunktionsebenen "Windows 2000 gemischt" sowie "Windows Server 2003 Interim" (Verteilergruppen können auch im mixed Mode geschachtelt werden). Folgende beiden Gruppentypen existieren:

1. Sicherheitsgruppen:
   Sicherheitsgruppen können Berechtigungen auf Active Directory-Objekte (Drucker etc.) oder für das NTFS-Dateisystem erteilt werden.
   Damit entsprechen Sicherheitsgruppen dem Konzept der Gruppen bei Windows NT.
   Des Weiteren ist es möglich, Sicherheitsgruppen als E-Mail Verteilungslisten zu nutzen. 
2. Verteilergruppen:
   Dieser Gruppentyp ist erstmals mit dem Active Directoy von Windows 2000 eingeführt worden.
   Mit diesem Gruppentyp ist es möglich (in Verbindung mit einer E-Mail Applikation wie es z.B. Exchange darstellt), diese als Verteilerliste zu nutzen
   und Nachrichten über die Verteilergruppe an alle ihr angehörenden Mitglieder schicken zu können.
   Der Nachteil dieser Gruppe: Es lassen sich keine Berechtigungen vergeben, wie es bei einer Sicherheitsgruppe der Fall ist.
   Exchangemäßig kann eine Sicherheitsgruppe gleichzeitig auch eine Verteilergruppe sein.

Diese beiden Gruppen erstrecken sich im Active Directory auf einen bestimmten Bereich, den Gruppenbereich.
Microsoft hat das bereits aus Windows NT bekannte Konzept der Gruppen beim Active Directory erweitert, denn NT kennt lediglich lokale und globale Gruppen, bei denen es sich automatisch um Sicherheitsgruppen handelt.
Das Active Directory kennt zusätzlich lokale Domänengruppen sowie universelle Gruppen.

Domänenlokale Gruppen haben folgende Einstellungen:

1. Sie sind in allen Gesamtstruktur- und Domänenfunktionsebenen vorhanden.
2. Sie können nur auf Windows 2000, Windows XP oder Windows Server 2003-Systemen in einer Domäne angewendet werden, natürlich nur, wenn sich die Domäne im einheitlichen Modus (Native) befindet. Wenn sich die Domäne z.B. in der Funktionsebene "Windows 2000 gemischt" befindet, kann eine domänenlokale Gruppe nur auf Domänencontrollern verwendet werden, ähnlich wie eine lokale Gruppe.
   Oder anders ausgedrückt, befindet sich die Domäne nicht im Domänenfunktionsmodus Windows 2000 pur oder Windows Server 2003,
   werden domänenlokale Gruppen nur auf den DCs und nicht auf den Mitgliedsservern angezeigt.
3. Sie können nur auf Systemen in derselben Domäne angewendet werden, in der die Gruppe definiert ist.
   Es ist z.B. nicht möglich, Berechtigungen für Ressourcen die außerhalb der Domäne einer domänenlokalen Gruppe liegen, dieser domänenlokalen Gruppe zuzuweisen.
4. Eine domänenlokale Gruppe kann Mitglieder von globalen Gruppen in derselben Domäne oder einer beliebigen vertrauenswürdigen Domäne, von universellen Gruppen in derselben Gesamtstruktur oder einer beliebigen vertrauenswürdigen Gesamtstruktur sowie von anderen domänenlokalen Gruppen in derselben Domäne umfassen. Oder auch direkt Benutzer aus vertrauten Domänen.

Hinweis: Es ist empfehlenswert, Benutzerkonten nicht direkt zu einer domänenlokalen Gruppe hinzuzufügen. Stattdessen sollten einzelne Benutzer mit gemeinsamen Merkmalen zu einer globalen Gruppe und diese globale Gruppe in eine domänenlokale Gruppe hinzugefügt werden. Auf diese Weise sind domänenlokale Gruppen einfacher zu verwalten.

Universelle Sicherheitsgruppen besitzen folgende Merkmale:

1. Diese Gruppe ist nur in den Domänenfunktionsebenen Windows 2000 pur und Windows Server 2003 vorhanden
   (Universelle Verteilergruppen gibt es auch im nicht einheitlichen Domänenmodus).
2. Sie können Mitglieder sämtlicher Domänen innerhalb der eigenen Gesamtstruktur enthalten, ebenfalls globale Gruppen und andere universelle Gruppen.
3. Universelle Gruppen werden auf globalen Katalogservern (GC) in der Gesamtstruktur gespeichert, in der die Gruppe definiert wurde (incl. aller Mitglieder).
4. Sie können dazu verwendet werden, um Rechte oder Berechtigungen für Ressourcen einer beliebigen Domäne innerhalb einer Gesamtstruktur zuzuweisen, und auch aller vertrauenden Domänen außerhalb der Gesamtstruktur.

Es ist wichtig den Unterschied zwischen Berechtigungen und Rechte zu kennen. Bei Berechtigungen kann man Benutzern eine bestimmte Zugriffsebene auf gemeinsam genutzte Netzwerkressourcen gewähren, zum Beispiel die Fähigkeit, eine Datei zu lesen oder Dokumente für einen bestimmten Drucker zu verwalten. 
Zum Beispiel ist die Fähigkeit, sich lokal an einem Domänencontroller anzumelden, ein Benutzerrecht; genauso die Fähigkeit, Dateien und Ordner zu sichern.

In der Praxis hat sich folgende Verfahrensweise etabliert: Das A - G - DL - P Prinzip.
Accounts go in Global Groups nested in Domain Local Groups that are granted Permissions.
Man fügt ein Benutzerkonto (Account) in eine Globale Gruppe, anschließend in eine dömänenlokale Gruppe und vergibt die gewünschte Berechtigung auf die Ressource. 

Natürlich sollte man heutzutage die Festplatten sowie die Partitionierung dieser auf den Domänencontrollern, zukunftsorientiert aus- bzw. einrichten.

Falls einem dann doch mal die Systempartition C: worauf die Active Directory-Datenbank sowie Logs darauf liegen, knapp wird, ist es möglich die AD-Datenbank samt Logs auf eine andere Partition zu verschieben.

Das Verschieben unter Windows 2000 und Windows Server 2003

Die Active Directory-Datenbank sowie die Log-Dateien können unter Windows 2000 sowie Windows Server 2003 folgendermaßen verschoben werden:

• Zuerst gilt es den Domänencontroller im Modus Verzeichnisdienstwiederherstellung zu starten.
  Der Eintrag erscheint beim Startvorgang des Servers, mit betätigen der F8-Taste.
  
  
• Am Anmeldebildschirm angelangt, muss man sich als Administrator und dem "Kennwort für den Wiederherstellungsmodus" (das während dem Heraufstufen zum DC vergeben wurde) anmelden.
  
  
• Wenn man angemeldet ist gilt es entweder unter Start-Ausühren oder aus einer Kommandozeile (CMD) heraus, dass NTDSUTIL zu starten um in den speziellen Active Directory-Bearbeitungsmodus zu gelangen. Wie bei allen Windows Tools, kann man sich auch hier mit dem Schalter /? eine Hilfe anzeigen lassen
  
  
• An der NTDSUTIL-Eingabeaufforderung gibt man folgendes ein: FILES
  
  
• In der "File Maintenance" - Eingabeaufforderung, kann zwischen zwei Optionen gewählt werden:
  
  
  • Zum Verschieben der Active Directory-Datenbank "NTDS.DIT", kann mit dem Befehl move db to <Laufwerk:\\Zielort> die NTDS.DIT an ihren neuen Zielort (z.B. "D:\NTDS\") verschoben werden.
    
    
  • Zum Verschieben der Active Directory Log Dateien "EDB*.LOG" (mit je 10 MB Größe), tippt man den Befehl move logs to <Laufwerk:\\Zielort> ein.
    Wenn der <Zielort> (bei der Datenbank sowie Logs) Leerzeichen im Verzeichnisnamen enthält, gilt es die Bezeichnung in Anführungszeichen zu setzen.
    
    
• Mit dem Befehl info wird eine Übersicht und der neue Speicherort der Active Drectory-Datenbank sowie Log-Dateien angezeigt.
  
  
• Um die Integrität der NTDS.DIT an dem neuen Speicherort zu überprüfen, gibt man den Befehl integrity ein.
  
  
• Mit der zweimaligen Eingabe von quit gelangt man zur Eingabeaufforderung.
  
  
• Anschließend gilt es noch sicherzustellen, dass die Dateiberechtigung auf NTFS-Ebene für das neue Verzeichnis in der die Active Directory-Datenbank sowie Log-Dateien gespeichert sind stimmen.
  Die vier Gruppen "Administratoren, Ersteller-Besitzer, Lokaler Dienst und System" müssen eingetragen sein und die Rechtevergabe hat folgendermaßen auszusehen:
  
  Administratoren=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Ersteller-Besitzer=Vollzugriff. Als Vererbung ist einzustellen "Nur Unterordner und Dateien".
  SYSTEM=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Lokaler Dienst=Ordner erstellen, Daten anhängen. Als Vererbung ist einzustellen "Dieser Ordner und Unterordner".
  
  Die Berechtigungen sind direkt auf dem neuen Verzeichnis zu setzen und sollten nicht vererbt werden!
  
  
• Nun startet man den Domänencontroller im normalen Modus.

Das Verschieben ab Windows Server 2008

Ab Windows Server 2008 kann man die AD-Datenbank sowie die Log-Dateien, ohne das der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden muss, verschieben.
Denn eines der Neuerungen ab Windows Server 2008, ist die Möglichkeit des Stoppen und Starten des Dienstes Active Directory-Domänendienste (AD-DS). Die Vorgehensweise wäre wie folgt:

• Im ersten Schritt muss der Dienst Active Directory-Domänendienste in der Dienstesteuerung (services.msc) oder in der Kommandozeile mit dem Befehl net stop ntds gestoppt werden. Zeitgleich werden dann die abhängigen Dienste Dateireplikationsdienst, Kerberos-Schlüsselverteilungsdienst, Standortübergreifender Messagingdienst und DNS-Server ebenfalls mit angehalten.
  
  
• Es gilt zunächst das NTDSUTIL aufzurufen, entweder unter Start-Ausführen oder direkt in der Kommandozeile. 
  
  
• In NTDSUTIL muss anschließend die Active Directory-Instanz aktiviert werden. Dieses ist mit dem Befehl activate instance ntds möglich.
  
  
• Danach wechselt man mit dem Befehl Files in das File maintenance Submenü.
  
  
• In der "File Maintenance" - Eingabeaufforderung, kann zwischen zwei Optionen gewählt werden:
  
  

  • Zum Verschieben der Active Directory-Datenbank "NTDS.DIT", kann mit dem Befehl move db to <Laufwerk:\\Zielort> die NTDS.DIT an ihren neuen Zielort (z.B. "D:\NTDS\") verschoben werden.
    
    
  • Zum Verschieben der Active Directory Log Dateien "EDB*.LOG" (mit je 10 MB Größe), tippt man den Befehl move logs to <Laufwerk:\\Zielort> ein.
    Wenn der <Zielort> (bei der Datenbank sowie Logs) Leerzeichen im Verzeichnisnamen enthält, gilt es die Bezeichnung in Anführungszeichen zu setzen.
    
    
• Mit dem Befehl info wird eine Übersicht und der neue Speicherort der Active Drectory-Datenbank sowie Log-Dateien angezeigt.
  
  
• Um die Integrität der NTDS.DIT an dem neuen Speicherort zu überprüfen, gibt man den Befehl integrity ein.
  
  
• Mit der zweimaligen Eingabe von quit gelangt man zur Eingabeaufforderung.
  
  
• Anschließend gilt es noch sicherzustellen, dass die Dateiberechtigung, auf NTFS-Ebene für das neue Verzeichnis in der die Active Directory-Datenbank sowie Log-Dateien gespeichert sind, stimmen. Doch zuvor muss man den Dienst Active Directory-Domänendienste samt den abhängigen Diensten, entweder in der Dienstesteuerung oder in der Kommandozeile mit dem Befehl net start ntds starten. Das ist deshalb notwendig, da ansonsten nicht alle Namen aufgelöst und lediglich die SIDs angezeigt werden. Das erschwert unnötig das Sicherstellen der Dateiberechtigung.
  
  Die vier Gruppen "Administratoren, Ersteller-Besitzer, Lokaler Dienst und System" müssen eingetragen sein und die Rechtevergabe hat folgendermaßen auszusehen:
  
  Administratoren=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Ersteller-Besitzer=Vollzugriff. Als Vererbung ist einzustellen "Nur Unterordner und Dateien".
  SYSTEM=Vollzugriff. Als Vererbung ist einzustellen "Dieser Ordner, Unterordner und Dateien".
  Lokaler Dienst=Ordner erstellen, Daten anhängen. Als Vererbung ist einzustellen "Dieser Ordner und Unterordner".
  
  Die Berechtigungen sind direkt auf dem neuen Verzeichnis zu setzen und sollten nicht vererbt werden!
  
  
  

Wichtig: Vor- und nach dem Verschieben der Datenbank sowie Protokolldateien, sollte zwingend eine Datensicherung des System States existieren!
Gerade nach dem Verschieben ist es wichtig eine System State-Sicherung zu tätigen, da bei einem Restore einer älteren Sicherung, der Pfad zur NTDS.DIT nicht mehr stimmt.

 
Weitere Informationen:
Die Active Directory-Datenbank reparieren
Relocating SYSVOL Manually
Reset the File Replication service staging folder to a different logical drive
How To Move the Ntds.dit File or Log Files
When you perform a system state backup on a domain controller that is running Windows Server 2003 with Service Pack 1, Backup may fail
"Directory Services cannot start" error message when you start your Windows-based or SBS-based domain controller

Prinzipiell ist es möglich, die IP-Adresse eines Domänencontrollers (DC) zu ändern.

Allerdings gibt es ein paar Grundregeln, die zu beachten wären:

1. Die IP-Adresse des DCs ist den Namensservern WINS und DNS bekannt
   bzw. eingetragen und steht ebenfalls im lokalen NetBIOS- und DNS-Cache eines jeden Mitgliedsservers sowie Clients drin.
   Deshalb ist es empfehlenswert, die Änderung der IP-Adresse nur in einer "ruhigen Minute" zu erledigen,
   idealerweise wenn die Clients nicht online sind.
   
   
2. Nach der Änderung der IP-Adresse, sollte in den WINS- und DNS-Servern, der alte IP-Eintrag des DCs gelöscht und überprüft werden,
   ob sich der DC mit der neuen IP dort eingetragen hat. Dieses kann man durch die Befehle mit "NBTSTAT -RR" (für WINS) und "IPCONFIG /Registerdns" (für DNS)
   manuell anstoßen. Die DNS-Einträge aus der "_msdcs-Zone" lassen sich mit dem folgenden NLTEST-Befehl entfernen:
   Nltest /DSDEREGDNS:DC01.Domäne.TLD
   
   
3. Falls der DC das DNS installiert hat, gilt es zu kontrollieren, ob von einer übergeordneten DNS-Zone eine Zonen Delegierung auf diesen
   DC/DNS-Server existiert. Wenn dies der Fall ist, so gilt es die IP-Adresse für diese Delegierung zu aktualisieren. 
   
   
4. Anschließend gilt es, auf allen anderen Servern (Memberserver und DCs) manuell die lokalen Namenscaches zu löschen,
   damit diese Server erneut die Namensserver abfragen um die neue IP-Adresse des geänderten DCs zu erhalten:
   "NBTSTAT -R" für den NetBIOS - Namenscache (WINS). Achtung auf die Gross- und Kleinschreibung des Schalters !  
   "IPCONFIG /Flushdns" zum löschen des DNS-Namenscaches. Bei Arbeitsplätzen die rund um die Uhr laufen müssen, wäre dies auch notwendig.
   

Das ganze kann man sich auch ersparen, wenn die Systeme neu gestartet werden, denn dabei werden die lokalen Caches ebenfalls gelöscht.

Nach der IP-Adressänderung des DCs kann es kurzzeitig vorkommen, dass diverse Fehlermeldungen in den Ereignisprotokollen der Systeme
temporär auftreten, da die Systeme es nicht sofort "merken", dass sich die IP-Information des DCs geändert hat.

Dieses kann man aber vernachlässigen, denn das regelt sich von alleine in dem Moment, in dem die neue IP-Adresse überall bekannt ist.

Es wäre ebenfalls die gleiche Vorgehensweise, wenn ein Microsoft Exchange- oder Terminalserver darauf installiert wäre.
Ich möchte aber daran erinnern, dass Microsoft es nicht empfiehlt einen Exchange Server auf einem DC zu installieren.

Zum Schluss gilt es noch zu überprüfen, ob nicht die alte IP-Adresse vielleicht irgendwo manuell in die lokale Lmhosts- bzw. Hosts-Datei
eines Systems eingetragen wurde. Wenn dies der Fall sein sollte, muss das natürlich auch geändert werden.

Weitere Informationen:

The Internet Protocol (TCP/IP) Properties dialog box displays the default IP address settings after you manually configure a static IP address in Windows 2000 Server or in Windows Server 2003

Change the static IP address of a domain controller

Irgendwann muss auch der letzte Mohikaner gehen bzw. ausgetauscht werden.

Was ist alles zu beachten, wenn man den ersten und einzigsten Domänencontroller austauschen möchte/muss:

1. Zu allererst sollte ein aktuelles Backup vom System State sowie den Daten existieren.

2. In den TCP/IP Einstellungen des neuen Servers trägt man als ersten und einzigsten DNS-Server den bereits bestehenden DC ein. Erst wenn die AD-Replikation (bei einer AD-integrierten Forward Lookup Zone, kurz FLZ) nach dem Heraufstufen zwischen den beiden DCs stattgefunden hat, trägt man den neuen DC sich selbst als ersten DNS-Server in seinen TCP/IP-Einstellungen
ein bzw. Welcher DNS-Server sollte eingetragen werden ?.

3. Der neue Server ist als zusätzlicher DC der Domäne hinzuzufügen. Außerdem muss das DNS entweder vor oder nach dem Heraufstufen des DCs installiert werden. Das DNS muss aber lediglich installiert und nicht noch zusätzlich konfiguriert werden, da das DNS bereits auf dem ersten DC konfiguriert ist. Es ist darauf zu achten, dass auf dem ersten DC die FLZ AD-integriert gespeichert ist, denn nur dann werden die DNS-Informationen automatisch dank der AD-Replikation auf den neuen DC repliziert. Des Weiteren ist es nur bei einer AD-integrierten FLZ möglich, die Option "Nur sichere" Updates zuzulassen (was anzuraten ist).
Einen zusätzlichen DC in die Domäne hinzufügen


4. Falls der neue Server, der erste Windows Server 2003 R2 Domänencontroller werden soll, so muss vorher das ADPREP von der zweiten R2-CD ausgeführt
werden. Für weitere Details siehe: Schemaupdate beim Windows Server 2003 R2

Ist der neue Server der erste Windows Server 2008 DC, so muss das Schema wie folgt aktualisiert werden:
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Wenn es sich dagegen um den ersten Windows Server 2008 R2 DC handelt, so ist das Schema folgendermaßen zu aktualisieren:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen


5. Danach müssen die 5 FSMO Rollen, samt den Infrastrukturmasterrollen der einzelnen Anwendungsverzeichnispartitionen (ab Windows Server 2003) auf den neuen DC verschoben werden:

- Schemamaster
- Domänennamenmaster
- RID-Master
- PDC-Emulator
- Infrastrukturmaster

Die FSMO-Rollen verschieben

6. Zusätzlich sollte der neue DC zum Global Catalog-Server (GC) deklariert werden. Dazu ist im Snap-In Active Directory-Standorte und -Dienste in den Eigenschaften
des NTDS-Settings Objekt, das sich unterhalb des neuen DC-Objekts befindet, der Haken bei "Globaler Katalog" zu setzen.
Globaler Katalog (Global Catalog - GC)

7. Bevor der alte DC mit DCPROMO aus der Domäne entfernt wird, gilt es noch das EFS-Zertifikat zu sichern:
Was muss ich tun, um den ersten DC zu deinstallieren?

8. Falls der DC auch ein DHCP-Server wäre, ist es möglich, die DHCP-Datenbank vom "alten" DC zu exportieren und auf dem neuen zu importieren:
How to move a DHCP database from a computer that is running Windows NT Server 4.0, Windows 2000, or Windows Server 2003 to a computer that is running Windows Server 2003
Die DHCP-Konfiguration samt den Leases, kann man mit folgendem Befehl (unter Windows Server 2003) sichern:
"netsh dhcp server export C:\Dhcp.txt all".

Um die exportierte Datei einzuspielen, gilt es folgenden Befehl einzugeben:
"netsh dhcp server import C:\Dhcp.txt all".

Wird der DHCP-Server von einem Windows Server 2003 auf Windows Server 2008 verschoben, so gilt es den folgenden Artikel durchzuführen:
How to move a DHCP database from a computer that is running Windows Server 2003 to Windows Server 2008

9. Ein WINS-Server sollte auch heute noch in einer Domäne existieren.
Der WINS erleichtert einem das tägliche Leben und kostet nicht viel Arbeit:
Wie sollte WINS konfiguriert werden?

10. Falls der DC auch Freigaben zur Verfügung stellt, können diese ebenfalls exportiert und auf dem neuen DC importiert werden:
Start - Ausführen - Regedit - HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
Anschließend ist der Serverdienst neu zu starten.

... oder man benutzt das File Server Migration Toolkit (FSMT).
Mit diesem Tool werden die Daten samt Berechtigungen kopiert und die Freigaben automatisch wieder erstellt:
http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en

Das Whitepaper zum FSMT kann hier heruntergeladen werden.

11. Drucker können mit dem Print Migrator kopiert/verschoben werden:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9B9F2925-CBC9-44DA-B2C9-FFDBC46B0B17&displaylang=en

12. Danach gilt es noch die Anmeldeskripte anzupassen.

Die Daten können z.B. mit NTBACKUP gesichert und auf dem neuen DC wiederhergestellt werden. 
ROBOCOPY oder XCOPY /O würden ebenfalls funktionieren, sowie diverse andere Programme/Tools.
Komfortabel lassen sich die Dateien allerdings mit dem File Server Migration Toolkit (FSMT) oder RichCopy auf den neuen Server kopieren.
Mit beiden Tools bleiben die Berechtigungen erhalten.

Wenn alle Daten sowie Dienste vom "alten" DC auf den neuen DC übernommen wurden, muss der Domänencontroller mit DCPROMO
aus dem Active Directory entfernt werden, damit die DC-Informationen ordnungsgemäß aus den Metadaten des AD entfernt werden.
Entfernt man jedoch den DC nicht mit DCPROMO aus der Domäne, sondern schaltet diesen einfach aus und installiert z.B. das Betriebssystem neu, so müssen die DC-Informationen in mühseliger Handarbeit aus den Metadaten des AD entfernt werden. 
Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Falls man jetzt noch möchte, dass der neue DC die IP-Adresse sowie den Computernamen des alten DCs erhält,
so kann man beides folgendermaßen durchführen: Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen?
Die IP - Adresse eines Domänencontrollers ändern
Anschließend ist ein Neustart des Servers fällig.

Es sei an dieser Stelle angemerkt das es ratsam ist in jeder Domäne mindestens zwei DCs zu installieren, um die Ausfallsicherheit im Falle eines DC-Crashs zu gewährleisten!