Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Wednesday, September 13, 2006
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!
 
 Wednesday, September 13, 2006

Welche Schritte müssen beachtet werden, wenn man einen Windows Server 2000 auf Windows Server 2003 R2 aktualisieren möchte ?

 

Ich gehe an diesem Beispiel davon aus, dass auf dem 2000er Domänencontroller das DNS, Active Directory-integriert installiert ist.

 

1. Bevor man anfängt, sollte natürlich ein Backup der Daten und vorallem vom SYSTEM STATE existieren: 

http://support.microsoft.com/kb/240363/de

Desweiteren muss sich auf allen DCs die Datei "NTDSA.DLL" im Pfad %windir%\system32 befinden, die einen höheren Datumsstempel als den 04. Juni 2001
sowie eine höhere Dateiversion als 5.0.2195.3673 hat. Der Virenscanner sollte während dem Update deaktiviert werden.

 

2. Zuerst sollte mit der Option „/checkupgradeonly“ das System auf Kompatibilität geprüft werden und falls die Routine an etwas meckert, sollten
zuerst die gemeldeten Probleme beseitigt werden.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/1e2541bb-d42c-49ef-9f8a-18e30b4f2667.mspx?mfr=true

 

3. Zuallererst gilt es auf dem Windows 2000 DC, dass EFS – Zertifikat zu sichern (falls dieser der erste DC in der Domäne ist):

http://www.faq-o-matic.net/2003/08/18/was-muss-ich-tun-um-den-ersten-dc-zu-deinstallieren/

http://support.microsoft.com/kb/241201/de

 

4. Auf dem Windows Server 2000 Domänencontroller muss mindestens das SP 2 installiert sein (heutzutage schon das SP4)
(http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/win2k/w2ktows03-2.mspx).

Die Zeiten der Domänencontroller sollten synchronisiert und auf allen gleich sein.
Danach muss auf dem 2000er DC, der die Rolle des Schemamasters innehat (idealerweise trägt dieser DC alle Rollen sowie den GC),
die Windows Server 2003 CD eingelegt und auf der Kommandozeile (START – AUSFÜHREN – CMD) ins Verzeichnis I386 gewechselt werden, 
um
„ADPREP /FORESTPREP“ auszuführen. Anschließend muss auf dem DC, der die Rolle des Infrastrukturmasters innehat in der Domäne,
in der der neue DC hinzugefügt werden soll, noch das „ADPREP /DOMAINPREP /GPPREP“ ausgeführt werden.
Das Active Directory Preparation Tool - ADPREP


Möchte man auf Windows Server 2003
R2 aktualisieren, so gilt es ADPREP von der zweiten R2 CD auszuführen und nicht von der ersten:
Schemaupdate beim Windows Server 2003 R2
 

5. Migriert man auf "Windows Server 2003 mit SP1" (oder R2), sollte noch das „ADPREP /DOMAINPREP /GPPREP“ ausgeführt werden.
Näheres siehe: http://support.microsoft.com/kb/324392/en-us

 

6. Anschließend führt man auf dem Windows 2000 Domänencontroller das SETUP von der CD aus und folgt den Anweisungen,
damit das Update auf den Windows Server 2003 beginnen kann.

 

7. Folgendes ist zu beachten, falls Exchange 2000 auf der gleichen Maschine laufen sollte:
Zuerst muss das Exchange 2000 auf Exchange 2003 upgedatet werden. Denn Exchange 2003 läuft unter Windows Server 2000,
aber nicht umgekehrt (Exchange 2000 auf Windows Server 2003), dass geht nicht.

Daher MUß zuerst ein Exchange update gemacht werden und dann das Betriebssystemupdate von Windows Server 2000 auf Windows Server 2003
(es müssen zwei Schemaupdates durchgeführt werden, einmal für Exchange und dann für das Active Directory).
Bevor man mit dem Betriebssystemupdate beginnt, sollte von der Exchange-CD aus dem Verzeichnis "support\exdeploy" das Tool "policytest.exe" ausgeführt werden,

um sicher zu gehen, dass die entsprechenden Berechtigungen im Active Directory bestehen.

 

 

How to upgrade Windows 2000 domain controllers to Windows Server 2003

Migration Exchange 2000 auf 2003

 

Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers

http://redmondmag.com/columns/article.asp?EditorialsID=663

 

 

Hier noch weitere hilfreiche Links: 

 

What do I need to do to prepare my Windows 2000 forest for the installation of the first Windows Server 2003 DC?

http://www.petri.co.il/windows_2003_adprep.htm

Common Mistakes When Upgrading Exchange 5.5/2000 To a Exchange 2003

http://support.microsoft.com/kb/555262/en-us

Considerations when you upgrade to Exchange Server 2003

http://support.microsoft.com/kb/822942/en-us

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain

http://support.microsoft.com/kb/555040/en-us

Cannot Upgrade Windows 2000 Server to Windows Server 2003 with Windows Services for UNIX 2.0 Installed

http://support.microsoft.com/kb/293783/en-us

When you run the "Adprep /forestprep" command to prepare Windows 2000 Active Directory for Windows Server 2003, the forest preparation operation fails

http://support.microsoft.com/kb/924175/en-us

Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392

http://support.microsoft.com/kb/324392/en-us - sowie

http://technet2.microsoft.com/WindowsServer/en/library/bc5ebbdb-a8d7-4761-b38a-e207baa734191033.mspx?mfr=true

 

Wednesday, September 13, 2006 9:01:37 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Migration  | 

Wann muss beim hinzufügen des ersten Windows Server 2003 R2 zu einer Windows 2000/2003 Gesamtstruktur,
ein Schemaupdate durchgeführt werden?

  1. Möchte man den ersten Windows Server 2003 R2 Domänencontroller in eine Windows 2000/2003 Gesamtstruktur hinzufügen,
    dann ist ein Schemaupdate auf dem Schemamaster von der zweiten R2-CD notwendig.
    Siehe: Wie aktualisiert man einen DC auf Windows Server 2003 R2
    Mit dem Schalter /Forestprep werden die neuen R2-Features (die unter den Punkten zwei bis vier aufgezählt sind) dem Schema hinzugefügt.
    Falls die Domäne bereits auf Windows 2003 läuft, so ist der Schalter /Domainprep nicht anzuwenden.
    Nur wenn man in einer Windows 2000 Domäne, den ersten Windows Server 2003 R2 Domänencontroller hinzufügen möchte,
    so muss das ADPREP (neben dem Schalter /Forestprep) zusätzlich mit dem Schalter /Domainprep /Gpprep ausgeführt werden.
  2. Bei Nutzung von DFS-R (die neue DFS Replikation). DFS und DFS-R speichern Konfigurationsoptionen im Active Directory. Das DFS (Namespace) Schema gibt es schon, das Replikationsschema ist neu, da bisher FRS (File Replication Service) benutzt wurde, dass ja weiterhin (parallel) für die SYSVOL-Replikation genutzt wird. Das Schemaupdate für DFS ist auch dann notwendig, wenn DFS nur auf Memberservern läuft.
  3. Für das neue Druckermanagement in R2 ist ein Schemaupdate erforderlich. Bei diesem Schemaupdate werden dem Schema neue Objekt-Klassen hinzugefügt
  4. Auch für das "Indentity Management for Unix" ist ein Schemaupdate fällig und auch hier, werden dem Schema neue Objekt-Klassen hinzugefügt.


Wichtig ist, dass man ADPREP von der zweiten R2-CD auf dem Schemamaster ausführt (dabei wird das Schema auf die Version 31 aktualisiert) und nicht von der ersten, denn das ADPREP befindet sich auf beiden CDs.
Siehe auch: Das Geheimnis der Tombstone Lifetime
Auf der ersten R2-CD ist nichts weiter als ein Windows Server 2003 mit integriertem SP1 oder SP2 drauf. Erst mit der zweiten R2-CD werden die R2 Erweiterungen installiert bzw. das System auf R2 erweitert. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann.
Wenn man im Ordner DOCS auf der zweiten R2-CD schaut, kann man in der dortigen Datei R2SETUP.CHM alle Informationen über R2 nachlesen.

Wer es noch genauer wissen möchte, der schaut sich die Datei "Sch31.ldf" auf der zweiten R2-CD an.

Möchte man einen Windows Server 2003 R2 Mitgliedsserver in eine 2000 oder 2003 (nicht R2) Domäne hinzufügen, auf dem die oben aufgeführten Punkte
(zwei bis vier) nicht in Frage kommen, so ist keine Schemaaktualisierung notwending und man kann den Mitgliedsserver mit beiden R2-CDs installieren und ihn in die Domäne hinzufügen.

 

Erster Windows Server 2003 R2 64 Bit Domänencontroller in einer Windows Server 2003 32 Bit Domäne

Falls der erste Windows Server 2003 R2 in der 64 Bit Edition in eine 32 Bit Windows Server 2003 Domäne hinzugefügt werden soll,
so kann diesmal
nicht das ADPREP von der zweiten R2-CD verwendet werden. Denn es enthält nicht das ADPREP in
der 32 Bit Version das dazu benötigt wäre. Stattdessen gibt es einen Hotfix,
den man sich beim Microsoft Product Support Service (MS-PSS) kostenlos bestellen kann.
You cannot deploy a Windows Server 2003 R2 x64 Edition-based domain controller in a Windows Server 2003 forest

Als weitere Möglichkeit kann man auch die 32Bit Windows Server 2003 R2 Trial-Version downloaden und von dort das ADPREP ausführen.
Installing Windows Server 2003 R2 Standard or Enterprise Edition with SP2 (32-bit x86)

 

Erster Windows Server 2003 R2 Domänencontroller in einer SBS 2003 Domäne

Wenn man einen weiteren Domänencontroller mit der Version "Windows Server 2003 R2 Standard/Enterprise" in eine bestehende SBS 2003 oder SBS 2003 R2 Domäne hinzufügen möchte, so muss mit der zweiten CD des "Windows Server 2003 R2 Standard/Enterprise" das Schema der SBS 2003/R2 Domäne erweitert werden.
Dort gilt es ebenfalls, die zweite CD des Windows Server 2003 R2 Standard/Enterprise in den SBS einzulegen und durch Ausführen von ADPREP,
das Schema der SBS-Domäne auf die Version 31 zu aktualisieren.

Hinweis: Ein SBS 2003 R2 ist nicht die gleiche Version, wie ein Windows Server 2003 R2 Standard/Enterprise.
Wenn ein SBS 2003 R2 DC existiert und man einen Windows Server 2003 R2 Standard/Enterprise als zusätzlichen DC der SBS Domäne hinzufügen möchte,
muss ebenfalls das ADPREP mit dem Schalter /Forestprep von der zweiten Windows Server 2003 Standard/Enterprise R2-CD auf dem Schemamaster (SBS) ausgeführt werden. 



Weitere Informationen:
Active Directory Schema Update
Extending Your Active Directory Schema for New Features in Windows Server 2003 R2
Optimizing File Replication over Limited-Bandwidth Networks using Remote Differential Compression
Error message when you run the Active Directory Installation Wizard: "The version of the Active Directory schema of the source forest is not compatible with the version of Active Directory on this computer"

Wednesday, September 13, 2006 7:56:20 AM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Migration  | 
 Tuesday, September 12, 2006

Falls die Active Directory-Datenbank (NTDS.DIT) einen Schaden haben oder Inkonsistent sein sollte, kann man diese versuchen zu reparieren.
Dazu geht man folgendermaßen vor:

  • Zuerst muss der Domänencontroller unter Windows 2000 sowie Windows Server 2003 im Modus Verzeichnisdienstwiederherstellung (Windows-Domänencontroller) gestartet werden.
    Auf das Auswahl-Menü gelangt man, wenn man im Bootvorgang des DCs die F8-Taste drückt. Die Anmeldung erfolgt dabei mit dem "Kennwort für den Wiederherstellungsmodus" das beim Heraufstufen des DCs vergeben wurde.

  • Ab Windows Server 2008 ist es nicht zwingend notwendig den DC im Modus Verzeichnisdienstwiederherstellung zu starten, denn es kann im laufenden Betrieb der Dienst Active Directory-Domänendienste (AD-DS) samt den abhängigen Diensten Dateireplikationsdienst, Kerberos-Schlüsselverteilungsdienst, Standortübergreifender Messagingdienst und DNS-Server angehalten werden. Dazu ist entweder in der Dienstesteuerung (services.msc) der Dienst Active Directory-Domänendienste oder in der Kommandozeile mit net stop ntds anzuhalten.

  • Danach gilt es unter START-AUSFÜHREN oder aus der Kommandozeile heraus, dass NTDSUTIL aufzurufen.
    Ab Windows Server 2008 muss nach dem Starten von NTDSUTIL anschließend die Active Directory-Instanz aktiviert werden. Dieses ist mit dem Befehl activate instance ntds möglich.

  • In der NTDSUTIL-Kommandozeile gibt man FILES ein, um in die File-Maintenance Eingabeaufforderung zu gelangen.

  • Zuerst sollte ein Integritätstest der NTDS.DIT mit dem Befehl Integrity durchgeführt werden. Falls nach dem Test Fehler angezeigt werden, könnte man mit NTDSUTIL versuchen diese zu beheben. Nach dem Integritätstest wird ein Protokoll im Verzeichnis "%windir%\ntds\ntds.integ.raw" erstellt, in dem Informationen zum Gesundheitszustand der AD-Datenbank enthalten sind.

 

 

    • Mit "q" (oder quit) gilt es die File-Maintenance Ebene zu verlassen, um in die NTDSUTIL Ebene zu gelangen.

    • Hier gilt es den Befehl SEMANTIC DATABASE ANALYSIS einzugeben, damit man in die "Semantic Checker" Ebene gelangt.

    • Dort angelangt, aktiviert man mit dem Parameter VERBOSE ON die Option, um detaillierte Informationen zu erhalten.

    • Als nächstes gibt man den Befehl GO FIXUP ein, um eine Reparatur über die NTDS.DIT laufen zu lassen. Anschließend wird zum einen in der Kommandozeile eine Zusammenfassung angezeigt und zum anderen wird ein Protokoll im Verzeichnis "C:\dsdit.dmp.0" mit ausführlichen Informationen erstellt.

 

    • Anschließend verlässt man mit zweimaliger Eingabe von "q" die Kommandozeile und startet den Domänencontroller im normalen Modus neu.
      Ab Windows Server 2008 startet man den Dienst Active Directory-Domänendienste in der Dienstesteuerung oder in der Kommandozeile mit net start ntds.


Nach dem Neustart des DCs, gilt es die Funktionsfähigkeit der NTDS.DIT zu überprüfen.
Sollten immer noch Probleme existieren, können mit den Windows Support Tools DCDIAG [1] und NetDIAG, weiteres Troubleshooting betrieben werden. Falls auch dieses nicht zum Erfolg führt, sollte die Active Directory-Datenbank aus einer System State Sicherung wiederhergestellt und nach dem Restore, die Konsistenz der Datenbank überprüft werden.



Weitere Informationen:

[1] Domänencontroller mit DCDIAG prüfen
DCDiag and NetDiag in Windows 2000 Facilitate Domain Join and DC Creation

Tuesday, September 12, 2006 3:34:55 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration  | 

Es kommt immer wieder auch heute noch vor, dass Administratoren in den TCP/IP-Einstellungen ihrer Domänencontroller die das DNS installiert haben, als "Ersten DNS"-Server ihn selbst eintragen, aber mit der Localhost-Adresse 127.0.0.1. Dort sollte die "echte" IP-Adresse eingetragen werden, nicht zuletzt wegen:
RAS Clients Receive 127.0.0.1 for DNS Server Address 

Trägt man den DC selbst als ersten DNS-Server ein, können bei einem Neustart die bekannten Fehlermeldungen mit der Fehler-ID: 4000, 4004, 4015 ...usw. in der Ereignisanzeige auftauchen, da dass DNS starten möchte, es aber nicht kann weil dass Active Directory noch nicht geladen wurde bzw. bereit ist.

Weiterhin könnte es unter Windows 2000 zu gravierenden Fehlern kommen, das Microsoft als DNS Server becomes an island [1] bezeichnet.
Dieser Fall kann eintreten, wenn als „Bevorzugter DNS-Server“ oder „Alternativer DNS-Server“ der Domänencontroller selbst eingetragen wird.
Stattdessen empfiehlt Microsoft, als primären DC/DNS-Server den allerersten DC/DNS-Server in der Gesamtstruktur und als sekundären,
einen anderen DC/DNS-Server einzutragen.


 

Daher habe ich die möglichen DNS-Server Einstellungen hier mal aufgeführt:

  • Gängige Praxis ist auch die "Überkreuz" Einstellung. Existieren zwei DCs in der Domäne, so trägt man jeweils den anderen DC als "Bevorzugter DNS-Server" in den TCP/IP-Einstellungen des DCs ein und sich selbst dann als zweiten.
  • Einziger DC/DNS: Diesen trägt man selbst mit seiner echten IP (kein Localhost) ein. Es gibt ja bloß diesen einen.
  • Mehrere DCs/DNS: Wenn man einen zweiten DC/DNS installiert, trägt man in den TCP/IP Einstellungen einen bestehenden (i.d.R. den ersten
    DC/DNS) als "Bevorzugter DNS-Server" ein und erst wenn die Replikation stattgefunden hat, stellt man diesen wenn gewünscht um.
  • Man kann unter Windows Server 2003 jeden DC als DNS-Server installieren, wo jeder sich selbst als ersten und einzigsten DNS-Server eingetragen hat.
  • Man setzt alle DCs auf den ersten installierten DC/DNS, der der einzige zentrale DNS Server ist und bleibt.
  • Eine Kombination wäre, als ersten DNS trägt man einen "zentralen" DNS ein um z.B. bei einem Serverstart den typischen Fehlern aus dem Weg zu gehen, wo DNS loslegen möchte, aber der Verzeichnisdienst noch nicht geladen/bereit ist - und als zweiten trägt man ihn selbst ein.

 

Die Empfehlung geht unter Windows Server 2003 dahin, einen zentralen/anderen DC/DNS-Server als ersten DNS-Server in den TCP/IP-Einstellungen und den DC/DNS-Server selbst, als sekundären DNS-Server einzutragen.
Inseleffekt vermeiden

 


Weitere Informationen:
[1] DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain
Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

Tuesday, September 12, 2006 9:03:26 AM (W. Europe Standard Time, UTC+01:00)  #      DNS  | 
 Monday, September 11, 2006

Seit Windows 2000 gibt es nicht mehr die beiden Funktionen BDC (Backup Domain Controller) sowie PDC (Primary Domain Controller), die es zu Zeiten von NT gab. Damals konnten Änderungen nur auf dem PDC ausgeführt werden (Single Master Replikation). Das Active Directory (AD) ab Windows 2000 verhält sich grundlegend anders als Windows NT 4.0-Domänen, denn eine Unterscheidung (ob BDC oder PDC) gibt es in einer Active Directory-Domäne nicht mehr. Vielmehr sind alle Domänencontroller (DC) einer Active Directory-Domäne (fast) gleichberechtigt. Somit können in einer AD-Domäne die Änderungen an Attributen und Objekten die auf einem DC getätigt wurden, unter allen DCs mitgeteilt, sprich repliziert werden (Multimaster-Replikation).  

 

Nun gibt es Situationen, in denen eine ausschließliche Multimaster-Replikation eher zu Konflikten führen würde.
Das betrifft beispielsweise eine Active Directory-Schema Erweiterung, die aus Gründen der Konsistenz lediglich von einem einzigen Domänencontroller ausgeführt werden sollten (nämlich dem DC, der die Rolle des Schemamasters innehat). Daher findet beim Active Directory zusätzlich zur Multimaster-Replikation für die Verzeichnispartition bzw. Namenskontexte für bestimmte Aufgaben, ein Einzelmaster-Betrieb statt. Denn für spezielle Aufgaben, darf nur ein einziger DC entweder in der Domäne oder Gesamtstruktur, diese ausführen. Aus diesem Grund spricht Microsoft auch von „Flexible Single Master Operations“, kurz FSMO.

Ab Windows 2000 kamen fünf Betriebsmaster hinzu, die eine besondere Rolle in einer Domäne/Gesamtstruktur einnehmen.
Die fünf FSMO-Rollen wären:

  1. Schemamaster (existiert nur einmal pro Gesamtstruktur)
  2. Domänennamenmaster (existiert nur einmal pro Gesamtstruktur)
  3. RID-Master (Relative ID) (existiert nur einmal pro Domäne)
  4. PDC-Emulator (existiert nur einmal pro Domäne)
  5. Infrastrukturmaster (existiert nur einmal pro Domäne)
  6. Des Weiteren existiert je eine Infrastrukturmasterrolle pro Anwendungsverzeichnispartition, wie es z.B. ab Windows Server 2003 die ForestDNSZones und DomainDNSZones darstellt.

 

 

Es gibt Vorgaben, was die Aufteilung der FSMO-Rollen auf einem oder mehreren DCs betrifft:

  1. Der Schemamaster sowie Domänennamenmaster sollten zusammen auf einem DC liegen (und dieser sollte auch ein GC sein).
  2. Der RID-Master sowie PDC-Emulator sollten ebenfalls auf dem gleichen DC liegen.
  3. Wenn mehrere Domänen in einer Gesamtstruktur existieren, darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs (GC=Global Catalog) trägt, es sei denn, man deklariert jeden DC dieser Domäne zum GC.

    Genauer gesagt, es muß jeder DC einer Domäne auch GC sein, wenn der Infrastrukturmaster dieser Domäne auf einem GC liegt.
    Unabhängig davon, wieviele DCs in anderen Domänen der Gesamtstruktur existieren.

    Wenn allerdings jeder Domänencontroller einer Domäne, der Bestandteil einer Gesamtstruktur mit mehreren Domänen ist, auch den globalen Katalog enthält, gibt es keine Arbeit für den Infrastrukturmaster. Der Infrastrukturmaster kann auf einen beliebigen Domänencontroller in dieser Domäne gestellt werden.

    Oder wenn die Umgebung aus einem Single-Domänen Forest besteht, dann spielt es auch keine Rolle, ob der DC auf dem der Infrastrukturmaster liegt ebenfalls auch globaler Katalog ist oder nicht.

    Der Infrastrukturmaster, der globale Katalog und der AD-Papierkorb

    FSMO placement and optimization on Active Directory domain controllers


  4. Ansonsten wird auf dem Infrastrukturmaster auf dem der GC aktiviert ist, ständig die EventID 1419 protokolliert.
    Dieser Fehler wird nur dann behoben, wenn der Infrastrukturmaster auf einen DC verschoben wird der kein GC ist oder der GC
    auf einem DC aktiviert wird, der nicht die Rolle des Infrastrukturmasters innehat. Der Fehler wird auch dann nicht mehr
    protokolliert, wenn auf jedem DC einer Domäne (sei es ein Single-Domänen oder Multi-Domänen Forest) der GC aktiviert wurde.

    Event ID 1419 Generated on a Domain Controller

     

  5. In 99% der Umgebungen ist es empfehlenswert, alle Rollen auf einem DC zu halten.

 

Man kann alle Rollen auf einen anderen DC im laufenden Betrieb, ohne das die Benutzer dadurch beeinträchtigt werden geschweige denn davon etwas mitbekommen, seit Windows 2000 entweder über die grafische Oberfläche oder in der Kommandozeile mit NTDSUTIL verschieben. Mittels der MMCs lassen sich die FSMO-Rollen in den Snap-Ins Active Directory-Schema, Active Directory-Domänen- und -Vertrauensstellungen sowie Active Directory-Benutzer und -Computer übertragen.

Die Rollen werden aber auch automatisch während dem Herunterstufen des Rolleninhabers auf einen anderen DC übertragen.

Die FSMO-Rollen mit DCPROMO verschieben


Tipp: Es ist empfehlenswert das Übertragen der Rollen in der grafischen Oberfläche direkt von dem zukünftigen Rolleninhaber durchzuführen. Somit ist es nicht notwendig weder in den MMCs noch mit NTDSUTIL zuerst eine Verbindung zum Ziel-DC herzustellen und es sind vor allem weniger "Schritte" notwendig.


 

Die Besonderheit der Infrastrukturmasterrolle ab Windows Server 2003

Es gibt ab Windows Server 2003 eine Besonderheit was die Rolle des Infrastrukturmasters anbetrifft. Denn mit Windows Server 2003 wurden Anwendungsverzeichnispartitionen eingeführt, wie z.B. im DNS die ForestDNSZones und DomainDNSZones. Ab Windows Server 2003 existiert nämlich zusätzlich je ein Infrastrukturmaster pro Anwendungsverzeichnispartition (1 Infrastrukturmaster für ForestDNSZones und je ein Infrastrukturmaster pro DomainDNSZones).

Das bedeutet für eine Gesamtstruktur mit zehn Domänen in der lediglich die Standard-Anwendungsverzeichnispartition (im DNS) genutzt werden, folgende Aufteilung der FSMO-Rollen:

  1. Ein Schemamaster
  2. Ein Domänennamenmaster
  3. Zehn RID-Master (Relative ID)
  4. Zehn PDC-Emulatoren
  5. Zehn Infrastrukturmaster für die Domänen bzw. Domänenpartitionen
  6. Ein Infrastrukturmaster für die Anwendungsverzeichnispartition "ForestDNSZones"
  7. Zehn Infrastrukturmaster für die Anwendungsverzeichnispartition "DomainDNSZones"

Es existieren also insgesamt 21 Infrastrukturmaster in der Gesamtstruktur. Leider werden aber die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen beim Übertragen (Rolleninhaber ist online) auf einen anderen DC weder über die GUI noch über NTDSUTIL (NTDSUTIL - Transfer) mit "verschoben". Diese müssen zusätzlich noch händisch auf einen anderen DC übertragen werden. Auch beim übernehmen (Rolleninhaber ist offline, z.B. DC-Crash) der FSMO-Rollen auf einen anderen DC, müssen zusätzlich die Infrastrukturmaster der Anwendungsverzeichnispartitionen händisch übernommen werden.



Die Infrastrukturmasterrollen der Anwendungsverzeichnispartitionen "ForestDNSZones und "DomainDNSZones" lassen sich wie folgt auf einen anderen DC verschieben:

  1. Unter Windows 2000 und Windows Server 2003 gilt es zuerst die Windows Support Tools (auf der Server-CD im Verzeichnis Support\Tools) zu installieren.
  2. Danach startet man das ADSIEdit, was ab Windows Server 2008 bereits "on Bord" ist.
  3. Im ADSIEdit wählt man mit einem Rechtsklick auf den Eintrag "ADSI Edit" die Option "Connect to..." aus.
  4. Im darauffolgenden Fenster "Connection Settings" ist im Bereich "Connection Point" die Option "Select or type a Distinguished Name or Naming Context" auszuwählen.
  5. In dem Feld trägt man dann den Distinguished Name (DN) der entsprechenden Anwendungsverzeichnispartition ein, um sich mit dieser Verzeichnispartition zu verbinden. Im Fall der "ForestDNSZones" würde der DN so lauten:
    DC=ForestDNSZones,DC=Root-Domäne,DC=TLD
  6. Anschließend verbindet man sich noch mit den einzelnen (je nach Anzahl der Domänen) "DomainDNSZones" Partitionen. Der DN lautet wie folgt:
    DC=DomainDNSZones,DC=Domäne,DC=TLD
  7. Wenn man nun im ADSIEdit auf der linken Seite die einzelnen Verzeichnispartitionen mit denen man sich verbunden hat erweitert, findet man auf der rechten Seite das Objekt CN=Infrastructure. Mit einem Rechtsklick auf dieses Objekt ruft man die Eigenschaften des Objekts auf und ändert dort den Wert im Attribut fSMORoleOwner.
  8. Der Wert im Attribut sieht z.B. so aus:
    CN=NTDS Settings,CN=DCON01,CN=Servers,CN=<Standort>,CN=Sites,CN=Configuration,DC=intra,DC=dikmenoglu,DC=de


Existieren evtl. noch selbst erstellte Anwendungsverzeichnispartitionen, so müssen die Infrastrukturmasterrollen dieser Vezeichnispartitionen ebenfalls auf einen anderen DC verschoben werden, wenn der Ursprungsrollenträger aus der Domäne entfernt werden soll oder nicht mehr zur Verfügung steht.



Der folgende Befehl kann dazu verwendet werden, die Verzeichnispartitionen die in der Gesamtstruktur existieren sich anzeigen zu lassen:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne -attr ncname


Möchte man sich lediglich die Anwendungsverzeichnispartitionen die in der Gesamtstruktur existieren anzeigen lassen, so ist das mit diesem Befehl möglich:
Dsquery * CN=Partitions,CN=Configuration,DC=Root-Domäne -filter (systemflags=5) -attr ncname


Die Infrastrukturmasterrollen der jeweiligen DomainDNSZones-Partition lässt sich wie folgt herausfinden:
Dsquery * CN=Infrastructure,DC=DomainDNSZones,DC=<die jeweilige Domäne>,DC=TLD -attr fSMORoleOwner



Siehe auch:
Die Infrastrukturmaster der Anwendungsverzeichnispartitionen


 

 

Den Schemamaster in der grafischen Oberfläche online übertragen


Die Rolle des Schemamasters kann innerhalb einer Gesamtstruktur, auf jeden DC egal aus welcher Domäne übertragen werden. Um die Rolle des Schemamasters vom ursprünglichen auf einen anderen Domänencontroller über die grafische Oberfläche zu übertragen, muss zuerst das Schema Snap-In registriert werden. Dazu geht man auf „Start-Ausführen“ und gibt dort folgenden Befehl ein regsvr32 schmmgmt.dll. Danach lässt sich das Schema Snap-In in einer MMC hinzufügen. Das Schema Snap-In erscheint nicht unter „Start-Programme-Verwaltung“ wie die bereits existierenden AD-Snap-Ins.

Die genaue Vorgehensweise ist wie folgt, wozu Schema-Admins Rechte benötigt werden:

  1. Unter Start-Ausführen öffnet man mit der Eingabe von MMC eine leere MMC-Konsole.

  2. In der MMC klickt man auf Datei - Snap-In hinzufügen/entfernen...

  3. Unterhalb von Verfügbare Snap-Ins: wählt man das Snap-In Active Directory-Schema aus und klickt auf die Schaltläche Hinzufügen und anschließend auf OK.

  4. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf Active Directory-Schema [FQDN] im Kontextmenü den Eintrag Active Directory-Domänencontroller ändern... auszuwählen.

  5. Es muss der DC ausgewählt werden, auf dem die Schemamasterrolle übertragen werden soll.

    Hinweis: Führt man das übertragen der Schemamasterrolle gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.

  6. Mit einem erneuten Rechtsklick auf Active Directory-Schema [FQDN] muss diesmal im Kontextmenü der Eintrag Betriebsmaster... ausgewählt werden.

  7. Im Dialogfenster Schemamaster ändern klickt man auf die Schaltfläche Ändern und bestätigt die nachfolgende Abfrage mit Ja.

  8. Die fehlerfreie Übertragung auf den Ziel-DC ist mit OK zu bestätigen.

  9. Zum Schluss schließt man mit einem Klick auf Schließen das Dialogfenster Schemamaster ändern.

 


Den Domänennamenmaster in der grafischen Oberfläche online übertragen

Die Rolle des Domänennamenmasters kann innerhalb einer Gesamtstruktur, auf jeden DC egal aus welcher Domäne übertragen werden. Die Rolle des Domänennamenmasters lässt sich vom ursprünlglichen auf einen anderen DC in der MMC Active Directory-Domänen und -Vertrauensstellungen mit Organisations-Admins Rechten übertragen.
Die einzelnen Schritte wären folgende:

  1. Zuerst ruft man das Snap-In Active Directory-Domänen und -Vertrauensstellungen unter Start-Programme-Verwaltung auf.

  2. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen [FQDN] die Option Domänencontroller ändern... auszuwählen.

  3. Nun muss der DC ausgewählt werden, auf den die Betriebsmasterrolle übertragen werden soll.

    Hinweis: Führt man das übertragen der Domänennamenmasterrolle gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.

  4. Dann ist mit einem Rechtsklick auf den Eintrag Active Directory-Domänen und -Vertrauensstellungen [FQDN] der Eintrag Betriebsmaster... auszuwählen.

  5. Im Dialogfenster Betriebsmaster wird mit einem Klick auf Ändern und bestätigen der nachfolgenden Abfrage mit Ja die Domänennamenmasterrolle auf den angegebenen DC übertragen. 

  6. Mit OK ist die fehlerfreie Übertragung auf den Ziel-DC zu bestätigen.

  7. Zum Schluss schließt man mit einem Klick auf Schließen das Dialogfenster Betriebsmaster.

 



Den RID-Master in der grafischen Oberfläche online übertragen

Der RID-Master kann ausschließlich innerhalb der Domäne auf einen anderen DC übertragen werden. Zum übertragen der RID-Master-Rolle, werden Domänen-Administratorrechte der entsprechenden Domäne benötigt. Das Übertragen des RID-Masters funktioniert wie folgt:

  1. Unter Start-Ausführen-dsa.msc oder unter Sart-Programme-Verwaltung gilt es die MMC Active Directory-Benutzer und -Computer zu starten.

  2. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf den Domänennamen im Kontextmenü die Option Domänencontroller ändern... auszuwählen.

  3. Danach muss der DC ausgewählt werden, auf dem die Rolle des RID-Masters übertragen werden soll.

    Hinweis: Führt man das übertragen des RID-Masters gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.

  4. Es gilt erneut mit einem Rechtsklick auf den Domänennamen, aus dem Kontextmenü den Eintrag Betriebsmaster... auszuwählen.

  5. Ist das Dialogfenster Betriebsmaster geöffnet, kann im Register RID mit einem Klick auf Ändern und anschließender Bestätigung der nachfolgenden Abfrage mit Ja, die RID-Master-Rolle übertragen werden.

  6. Das die Betriebsmasterrolle auf den betreffenden DC fehlerfrei übertragen wurde, muss mit einem Klick auf OK bestätigt werden.

  7. Das Dialogfenster Betriebsmaster kann mit einem Klick auf die Schaltfläche Schließen geschlossen werden.

 

Der RID-Master und sein RID-Pool


 

Den PDC-Emulator in der grafischen Oberfläche online übertragen

Die Rolle des PDC-Emulators kann nur innerhalb der Domäne auf einen anderen DC übertragen werden. Mit Domänen-Administratorrechten der entsprechenden Domäne, kann diese Rolle in der MMC Active Directory-Benutzer und -Computer übertragen werden. Dazu geht man wie folgt vor:

  1. Als erstes gilt es unter Start-Ausführen-dsa.msc oder unter Sart-Programme-Verwaltung die MMC Active Directory-Benutzer und -Computer zu öffnen.

  2. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf den Domänennamen im Kontextmenü die Option Domänencontroller ändern... auszuwählen.

  3. Als nächstes muss der zukünftige Rolleninhaber ausgewählt werden.

    Hinweis: Führt man das übertragen des PDC-Emulators gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.

  4. Mit einem erneuten Rechtsklick auf den Domänennamen ist aus dem Kontextmenü der Eintrag Betriebsmaster... auszuwählen.

  5. Im Dialogfenster Betriebsmaster wechselt man zum Register PDC, klickt dort auf die Schaltfläche Ändern und bestätigt die nachfolgende Abfrage mit einem Klick auf Ja.

  6. Die fehlerfreie Übertragung der Betriebsmasterrolle auf den angegebenen DC ist mit einem Klick auf OK zu bestätigen.

  7. Anschließend schließt man mit einem Klick auf Schließen das Dialogfenster Betriebsmaster.

 

 

Den Infrastrukturmaster in der grafischen Oberfläche online übertragen


Mit Domänen-Administratorrechte kann die Infrastrukturmaster-Rolle innerhalb der Domäne auf einen anderen DC übertragen werden. Die Betriebsmasterrolle kann im Snap-In Active Directory-Benutzer und -Computer wie folgt auf einen anderen DC übertragen werden:

  1. Es gilt im zuerst unter Start-Ausführen-dsa.msc oder unter Sart-Programme-Verwaltung die MMC Active Directory-Benutzer und -Computer aufzurufen.

  2. Auf dem ursprünglichen Rolleninhaber gilt es mit einem Rechtsklick auf den Domänennamen, im Kontextmenü den Eintrag Domänencontroller ändern... auszuwählen.

  3. Es muss der DC ausgewählt werden, der die Rolle des Infrastrukturmasters erhält.

    Hinweis: Führt man das übertragen des PDC-Emulators gleich auf dem zukünftigen Rolleninhaber durch, so ist das verbinden zum Ziel-DC nicht notwendig da man sich bereits auf diesem befindet.

  4. Mit einem weiteren Rechtsklick auf den Domänennamen, ist aus dem Kontextmenü der Eintrag Betriebsmaster... auszuwählen.

  5. Ist das Dialogfenster Betriebsmaster geöffnet, wechselt man zum Register Infrastruktur, klickt dort auf die Schaltfläche Ändern und bestätigt die nachfolgende Abfrage mit einem Klick auf Ja.

  6. Die fehlerfreie Übertragung auf den vorher ausgewählten DC ist mit einem Klick auf OK zu bestätigen.

  7. Am Ende schließt man das Dialogfenster Betriebsmaster mit einem Klick auf Schließen.



 

Die FSMO-Rollen in der Kommandozeile mit NTDSUTIL online übertragen
 

Alle fünf FSMO-Rollen lassen sich auch in der Kommandozeile auf einen anderen DC übertragen. Das Übertragen der Betriebsmasterrollen mit "Transfer" funktioniert jedoch nur, wenn der ursprüngliche Rolleninhaber noch online und funktionstüchtig ist! Per NTDSUTIL können die FSMO-Rollen folgendermaßen übertragen werden:

  1. Als erstes muss in der Eingabeaufforderung (Start-Ausführen-CMD) oder unter "Start - Ausführen" das NTDSUTIL aufgerufen werden.

  2. Mit dem Befehl ROLES wechselt man zur "fsmo maintenance" Ebene.

  3. In der „fsmo maintenance“ Ebene gibt man Connections ein.

  4. Mit dem Befehl "Connect to Server <Servername>“, gilt es den Ziel-DC (zukünftiger Rolleninhaber) zu fokussieren.

  5. In der „server connections“ Ebene muss man mit "quit" oder „q“ erneut zur „fsmo maintenance“ Ebene wechseln.

  6. Nun können mit dem folgenden Befehl, die Betriebsmasterrollen auf den fokussierten DC übertragen werden: Transfer <Rolle>

    Transfer schema master
    Transfer domain naming master (gilt bis einschließlich Windows Server 2003!)
    Transfer naming master (gilt ab Windows Server 2008!)
    Transfer RID master
    Transfer PDC
    Transfer infrastructure master


     
  7. Die folgende Abfrage ist mit einem Klick auf OK zu bestätigen.

  8. Nach dem übertragen gilt es mit „q“ (zweimal), die NTDSUTIL - Kommandozeile zu verlassen.


Falls dieser nicht mehr online ist, weil er einen Hardware-Crash erlitten hat, muss man die Rollen zwangsweise mit der „seize <Funktion>“ übertragen (bei gleicher Vorgehensweise wie beim "transfer").  
Funktionieren würde das Verschieben, wenn der DC (für immer) offline wäre, auch über die GUI, bis auf den RID-Master, dieser muss per „seize“ verschoben werden.

 

Befindet sich der Rolleninhaber nur vorübergehend offline, so ist es nicht notwendig die Rollen auf einen anderen DC zu verschieben!

 

 

 

 

Die FSMO-Rollen offline übernehmen

 

Das Übertragen der Betriebsmasterrollen funktioniert nur, wenn der ursprüngliche Rolleninhaber online ist. Falls jedoch der Rolleninhaber durch einen Hardwaredefekt dauerhaft ausgefallen ist, so können die Rollen nicht einfach auf einen anderen DC übertragen werden. Die Rollen müssen vielmehr von einem anderen DC übernommen werden. Da aber der ursprüngliche "defekte" Rolleninhaber von der Übernahme der Betriebsmasterrollen durch einen anderen DC nichts mitbekommt, kann es zu schwerwiegenden Problemen kommen, wenn der "defekte" Rolleninhaber repariert und erneut in Betrieb genommen wird. Wenn die FSMO-Rollen durch einen anderen DC übernommen wurden, darf der ursprüngliche Rolleninhaber nie mehr online gehen!

 

Sind stattdessen nur die Rollen PDC-Emulator oder Infrastrukturmaster ausgefallen und wurden diese inzwischen von einem anderen DC übernommen, so stellt die Wiederinbetriebnahme des ursprünglichen Rolleninhabers kein Problem dar. Nur der Rolleninhaber dieser beiden Rollen darf nach der Übernahme von einem anderen DC erneut online gehen. Wird der ursprüngliche Rolleninhaber wieder online gebracht, repliziert sich dieser mit seinen Replikationspartnern und erfährt dabei, dass die Rollen mittlerweile von einem anderen DC ausgeführt werden. Die Änderung wird vom DC übernommen und er führt die beiden Rollen nicht mehr aus.

 

Ist der Träger der FSMO-Rollen nur für eine absehbare kurze Zeit offline, so ist es nicht notwendig das die Rollen auf einen anderen DC übertragen oder von einem anderen DC übernommen werden.

Die FSMO-Rollen können alle bis auf den RID-Master über die grafische Oberfläche oder mit NTDSUTIL übernommen werden. Der RID-Master muss zwingend in der Kommandozeile mit NTDSUTIL übernommen werden. Die Übernahme der Betriebsmasterrollen mit NTDSUTIL ist seit Windows 2000 folgendermaßen möglich:

  1. Auf einem DC muss zuerst unter "Start-Ausführen" oder in einer Eingabeaufforderung (Start-Ausführen-CMD) das NTDSUTIL aufgerufen werden.

  2. Als nächstes wechselt man mit ROLES zur fsmo maintenance Ebene.

  3. Dann muss der Befehl Connections eingegeben werden.

  4. Mit dem Befehl Connect to Server <Servername>, gilt es den zukünftigen Rolleninhaber zu fokussieren.

  5. In der „server connections“ Ebene muss man mit "quit" oder „q“ erneut zur „fsmo maintenance“ Ebene wechseln.

  6. Die Übernahme der gewünschten FSMO-Rollen auf den fokussierten DC, kann mit den folgenden Befehlen erfolgen:

    Seize schema master

    Seize domain naming master (gilt bis einschließlich Windows Server 2003!)
    Seize naming master (gilt ab Windows Server 2008!)
    Seize RID master
    Seize PDC
    Seize Infrastructure master



    Nach der Ausführung dieser Befehle wird trotzdem zuerst versucht, die Rollen "online" zu übertragen. Daher erscheint zwar in der Kommandozeile eine irreführende Meldung, doch letztenendes werden die Rollen dann doch von einem anderen DC übernommen. Die Meldung in der Kommandozeile sollte "nur" sorgfältig gelesen werden.

  7. Die jeweils folgende Abfrage ist mit einem Klick auf OK zu bestätigen.




Wo befinden sich die FSMO-Rollen?

Auf welchem DC die FSMO-Rollen liegen, kann man sich recht einfach mit dem Kommandozeilen-Befehl NETDOM (aus den Windows Support Tools) anzeigen lassen.
Der Befehl dazu lautet: NETDOM QUERY FSMO.

Die etwas aufwändigere Abfrage wäre mit DSQUERY:

dsquery server -hasfsmo schema
dsquery server -hasfsmo name
dsquery server -hasfsmo rid
dsquery server -hasfsmo pdc
dsquery server -hasfsmo infr


Oder mit DCDIAG: DCDIAG /Test:Knowsofroleholders /v


Wer diese Informationen gerne über die grafische Oberfläche erfahren möchte, der kann sich dazu die Windows Support Tools installieren und startet anschließend unter Windows 2000 und Windows Server 2003 das REPLMON. Im nächsten Schritt verbindet man sich mit einem DC und wählt mit einem Rechtsklick auf den NetBIOS-Namen des DCs, die Option Properties aus. Im Reiter FSMO Roles bekommt an dann die oder den Träger der FSMO-Rollen zu sehen.

 

Weitere Informationen:
Die FSMO-Rollen mit der AD-Powershell verschieben
Reagieren auf Betriebsmasterausfälle
How Operations Masters Work
How To Find Servers That Hold Flexible Single Master Operations Roles
How to view and transfer FSMO roles in Windows Server 2003
How to view and transfer FSMO roles in the graphical user interface
Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
How to Find the FSMO Role Owners Using ADSI and WSH

Monday, September 11, 2006 7:44:29 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration  | 
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: