Möchte man die letzte Anmeldung eines Benutzers herausfinden, so führen zu diesem Vorhaben mehrere Wege zum Ziel.
Die benötigte Information lässt sich wie vieles (aufwändig) über das ADSI auslesen.
Das Attribut in dem die letzte Anmeldung gespeichert wird, lautet Last-Logon.
Der Nachteil an diesem Attribut ist, dass es nicht zwischen den Domänencontrollern repliziert wird.
Es gilt also das Attribut Last-Logon auf jedem Domänencontroller in der Domäne abzufragen um das aktuellste Datum herauszufinden.
Additional Account Info - AcctInfo.dll
Eine recht einfache Möglichkeit wäre (unter Windows 2000/2003/2008), sich die Account Lockout and Management Tools herunterzuladen
und die AcctInfo.dll zu nutzen. Diese DLL muss vorher registriert werden. Dazu extrahiert man zuerst die heruntergeladene Datei in ein
Verzeichnis (z.B. C:\Tools), öffnet eine Kommandozeile (CMD) und navigiert zu den entpackten Dateien. Anschließend registriert man mit
folgendem Befehl die DLL: regsvr32 acctinfo.dll. Danach erscheint im Snap-In Active Directory-Benutzer und -Computer in den
Eigenschaften der Benutzer ein weiterer Reiter. Dieser neue Reiter zeigt unter anderem die letzte Benutzeranmeldung an:
Hinweis: Wenn ein Benutzer in der MMC über eine Suche aufgerufen wird, ist dieser Reiter nicht zu sehen.
Dieser Reiter erscheint lediglich auf dem Arbeitsplatz/Server, auf dem die DLL registriert wurde. Um den Reiter zu entfernen,
muss der Befehl (über Start – Ausführen) regsvr32 /u <Pad zur AcctInfo.dll> ausgeführt werden.
Das Attribut Last-Logon-Timestamp
Wie vieles andere wurde auch dieses Verhalten in Windows Server 2003 verbessert.
Im Schema des Windows Server 2003 wurde ein neues Attribut namens Last-Logon-Timestamp dem Benutzer-Objekt hinzugefügt.
Wenn sich die Domäne mindestens im Domänenfunktionsmodus Windows Server 2003 befindet, kann man das Attribut Last-Logon-Timestamp nutzen.
Dieses Attribut ist aber vom Attribut Last-Logon abhängig. Würde z.B. bei einer Benutzer-Anmeldung das Attribut Last-Logon nicht gesetzt,
wird auch das Attribut Last-Logon-Timestamp nicht aktualisiert. Es bietet allerdings den Vorteil, dass es auf andere DCs repliziert wird und somit
einem das durchsuchen aller DCs erspart bleibt. Jedoch wird Last-Logon-Timestamp (um die Replikationslast gering zu halten) standardmäßig alle 14 Tage,
abzüglich einer zufällig gewählten Differenz von bis zu 5 Tagen aktualisiert. Das Attribut wird also zwischen zehn und vierzehn Tagen repliziert.
Wird nun das Attribut Last-Logon aktualisiert, überprüft der DC ob das Aktualisierungsintervall das in dem Attribut ms-DS-Logon-Time-Sync-Interval
angegeben ist, erreicht wurde, um dann Last-Logon-Timestamp zu aktualisieren.
Das Aktualisierungsintervall von Last-Logon-Timestamp wird im Attribut ms-DS-Logon-Time-Sync-Interval gesteuert.
Dieses Attribut befindet sich in den Eigenschaften der Domänenpartition und lässt sich z.B. mit ADSIEdit bearbeiten.
Der Wert dieses Attributs ist standardmäßig <Not Set> und bedeutet einen Standardwert von 14 Tagen.
Dieser Wert kann zwischen 1 und 100.000 Tage betragen. Trägt man als Wert 0 ein, wird das Attribut Last-Logon-Timestamp nicht mehr aktualisiert.
Ein zweimonatiger Test mit 50 Benutzerkonten in einer produktiven Umgebung hat ergeben, dass die Aktualisierung von Last-Logon-Timestamp
(mit einem Standardwert im Attribut ms-DS-Logon-Time-Sync-Interval) bei 80% der Benutzerkonten, ausgeglichen zwischen zehn und elf Tagen lag.
Wenn ein DC unter Windows Server 2003 (ohne SP1) läuft, kann es unter Umständen vorkommen, dass dieses Attribut nicht aktualisiert wird:
A network logon that uses NTLM authentication does not update the lastLogonTimestamp attribute in the Active Directory schema of a Windows Server 2003-based domain controller
Sowohl das Attribut Last-Logon, als auch Last-Logon-Timestamp, sind Integer8 Datentypen.
Diese haben eine Länge von 8 Byte bzw. 64 Bit. Die Zeit wird ab dem 1. Januar 1601 12:00 AM im 100 Nanosekunden Intervall berechnet.
Der Wert aus Last-Logon oder Last-Logon-Timestamp wird in der Greenwich Mean Time (GMT) Zone im Active Directory gespeichert und muss
in ein leserliches Datumsformat konvertiert werden, da man ansonsten mit dem Wert (der in etwa so aussieht: 128362271633877741) nicht
sonderlich viel anfangen kann. Zum konvertieren gibt man in der Kommandozeile den Befehl w32tm /ntte <Wert> ein.
Benutzer die sich länger nicht an der Domäne angemeldet haben
Benutzerkonten die sich seit längerem an der Domäne nicht authentifiziert haben, lassen sich recht schnell auf verschiedene Weise herausfinden.
Hinweis: Die folgenden Beispiele benötigen die Domänenfunktionsebene Windows Server 2003!
1. Das Snap-In Active Directory-Benutzer und –Computer (ADBuC)
In der MMC ADBuC kann man sich eine Allgemeine Abfrage durch eine Suche (Rechtsklick auf die Domäne) oder durch eine Gespeicherte Abfrage erstellen.
Dort gilt es die Auswahl bei der Option Tage seit der letzten Anmeldung zwischen 30, 60, 90, 120 oder 180 zu treffen.
Der Wert ist nicht frei definierbar sondern fest vorgegeben:
2. Dsquery
Mit einem der DS*-Tools die standardmäßig ab Windows Server 2003 integriert sind, lässt sich eine einfache Abfrage erstellen.
Die Rede ist von DSQUERY. Die Abfrage z.B. in einer Kommandozeile, könnte wie folgt aussehen:
dsquery user domainroot –inactive <Anzahl der Wochen>
Damit werden alle Benutzerkonten der Domäne, die während der angegebenen Anzahl an Wochen (oder länger) nicht angemeldet waren angezeigt.
Hinweis: Die Abfrage in ADBuC sowie Dsquery nutzen bei der Abfrage das Attribut Last-Logon-Timestamp.
3. Ab Windows Server 2008 und Windows Vista steht eine weitere Option zur Verfügung, um die letzte interaktive Domänenanmeldung herauszufinden:
Die letzte interaktive Domänenanmeldung anzeigen
4. Mit der AD-PowerShell kann man sich ebenfalls das letzte Anmeldedatum der Benutzer ausgeben lassen. Dazu muss eine Abfrage nach "LastLogonDate" durchgeführt werden. Diese Eigenschaft liest den Wert aus dem Attribut LastLogonTimeStamp aus. Der Befehl lautet:
Get-ADUser -Filter * -Properties LastLogonDate | Sort-Object -Property LastLogonDate -descending | FT -Property Name, LastLogonDate -A
AD-PowerShell Befehle
Weitere Beispiele
Wie bekomme ich heraus, wann ein User sich zuletzt ans AD angemeldet hat?
Die Scipting-Guys haben dazu zwei Artikel veröffentlicht:
http://www.microsoft.com/technet/technetmag/issues/2006/01/ScriptingGuy/default.aspx
http://www.microsoft.com/technet/scriptcenter/topics/win2003/lastlogon.mspx
How can I report all inactive user accounts, and optionally disable them?
TRUELAST.EXE freeware outputs the last logon time a particular user logged onto the current or a specified domain
The Windows Server 2003 Active Directory lastLogonTimeStamp attribute is replicated across all domain controllers
Using the lastLogonTimestamp attribute in Windows Server 2003
Weitere Informationen:
Account Info DLL Version 2
Einen Large Integer Wert umrechnen
The lastLogon attribute is not updated when a client computer runs an LDAP simple bind operation against a Windows Server 2003-based domain controller
Steht eine Domänenaktualisierung von Windows 2000 auf Windows Server 2003/2003 R2 oder auf Windows Server 2008/2008 R2 bevor,
sei es durch ein Inplace-Upgrade oder durch das Hinzufügen des ersten Windows Server 2003/2003 R2/2008/2008 R2 Domänencontroller zur Gesamtstruktur,
so gilt es zuerst das AD-Schema zu aktualisieren.
Doch bevor dieser Schritt durchgeführt wird, wäre es empfehlenswert die Ausgangssituation zu überprüfen.
Die Active Directory- sowie die NTFRS/DFSR- Replikation sollte und muss ohnehin ordnungsgemäß auf allen Domänencontrollern funktionieren.
Das Verzeichnisdienstprotokoll auf den Domänencontrollern sollte weder Warnungen, noch Fehler vorweisen.
Diverse Tests mit den Tools DCDIAG, NetDIAG, FRSDiag sowie REPADMIN sind einem beim sicherstellen der fehlerfreien Funktion der DCs sowie der Replikation hilfreich.
Die genannten Tools befinden sich bis einschließlich Windows Server 2003 in den Windows Support Tools und sind ab Windows Server 2008 bereits "on Bord."
Was noch alles zu beachten und auszuführen wäre, erfährt man aus diesen Artikeln:
Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Den einzigen Domänencontroller austauschen
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Hinweis zu Exchange
Wenn ein Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, so ist zuerst die Exchange Schema-Erweiterung zu „korrigieren“.
Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der
Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren.
Der Befehl dazu lautet:
Ldifde.exe /i /f inetOrgPersonFix.ldf /c "DC=X" "DC=Domäne,DC=TLD".
Führt man diesen Schritt vorher nicht aus, würde es zu entstellten Attributen kommen:
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Soll im Zuge der AD Migration gleichzeitig auch ein Update auf Exchange 2003 erfolgen, so ist es einfacher,
erst das Exchangesetup mit dem Schalter /Forestprep durchzuführen. Der oben beschriebene Fix wird dadurch unnötig.
Hinweis: Im weiteren Verlauf ist zwar die Rede von "Windows Server 2003", doch die einzelnen Schritte gelten auch für neuere Serverbetriebssystemversionen.
Das Ausführen von ADPREP
Wenn alles soweit in Ordnung ist, kann die eigentliche Schemaaktualisierung durchgeführt werden.
Dazu ist das Active Directory Preparation Tool (kurz ADPREP) von der Windows Server 2003 CD zum einen auf dem Schemamaster
und zum anderen auf dem Infrastrukturmaster der jeweiligen Domäne, mit jeweils anderen Parametern auszuführen.
Alle Windows 2000 Domänencontroller in der Gesamtstruktur sollten idealerweise das aktuelle Service Pack 4 und alle weiteren Updates installiert haben.
Prepare Your Infrastructure for Upgrade
Hotfixes to install before you run adprep /Forestprep on a Windows 2000 domain controller to prepare the Forest and domains for the addition of Windows Server 2003-based domain controllers
Im ersten Schritt, muss zuerst die Gesamtstruktur mit dem Befehl ADPREP /Forestprep auf dem Domänencontroller,
der die Rolle des Schemamaster innehat, auf eine Windows Server 2003 Gesamtstruktur aktualisiert werden.
Würde die Gesamtstruktur (oder Domäne) nicht auf Windows Server 2003 aktualisiert werden, würde der Active Directory-Assistent DCPROMO
beim Heraufstufen des ersten Windows Server 2003/R2 zum Domänencontroller an entsprechender Stelle bzgl. des ADPREP`s einen Fehler melden.
Danach hat man immer noch Zeit das ADPREP auszuführen um anschließend mit dem Heraufstufen des Servers fortzufahren.
Im zweiten Schritt ist das ADPREP mit dem Parameter /Domainprep /GPPREP auf dem Infrastrukturmaster in der Domäne, in der man
den neuen Windows Server 2003 DC hinzufügen möchte auszuführen. Somit wird die Domäne auf Windows Server 2003 aktualisiert.
Wenn man ab Windows Server 2008 einen Read Only Domain Controller (RODC) zur Domäne hinzufügen möchte, so sollte der Befehl ADPREP /RODCPREP auf einem Infrastrukturmaster ausgeführt werden.
Falls das ADPREP in einer Gesamtstruktur oder Domäne nicht ausgeführt wurde, so wird während dem Heraufstufen eines DCs eine Fehlermeldung
bzgl. ADPREP angezeigt und der Vorgang bleibt stehen. Danach kann man jederzeit das ADPREP nachholen und anschließend mit dem Heraufstufen
des DCs fortfahren.
Wie stellt man nun sicher, dass die Änderungen die auf dem Schemamaster mit ADPREP /Forestprep durchgeführt wurden,
auch auf allen Domänencontrollern in der Gesamtstruktur repliziert wurde?
Mit dem Ausführen von ADPREP /Domainprep /GPPREP muss solange gewartet werden, bis die durch ADPREP /Forestprep
vorgenommenen Änderungen vom Schemamaster, auf den Infrastrukturmaster (in der Domäne, in der man den neuen
Windows Server 2003 hinzufügen möchte) repliziert worden ist.
Wenn ADPREP erfolgreich (oder nicht) durchgeführt wurde, wird das in der Kommandozeile angezeigt.
Auf dem Schema-Master wird in der Konfigurationspartition die folgenden beiden Container erstellt und
diese müssen auf allen DCs in der Gesamtstruktur repliziert werden:
CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
CN=Operations,CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
Mit Ausführen von Adprep /Forestprep werden 36 Änderungen in der CN=Configuration und CN=Schema Verzeichnispartition des Schemamasters durchgeführt.
Für jede Operation die durch den Befehl ADPREP /Forestprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations.
Jede GUID stellt eine Operation dar.
Wenn alle 36 Operationen erfolgreich durchgeführt wurden, wird anschließend der folgende Container erstellt:
CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC= Domäne,TLD.
Im Container CN=Windows2003Update muss das Attribut Revision den Wert 9 enthalten.
Das ADPREP /Forestprep wird nur einmal auf dem Schemamaster in der Gesamtstruktur ausgeführt.
Welche Änderungen im Detail ausgeführt werden, zeigt dieser Artikel:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest
Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!
Was wird mit ADPREP /Domainprep durchgeführt?
Es werden 50 Änderungen auf dem Infrastrukturmaster vorgenommen.
Auf dem Infrastrukturmaster wird in der Domänenpartition die folgenden beiden Container erstellt und diese müssen auf allen DCs in der Domäne repliziert werden:
CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Für jede Operation die durch den Befehl ADPREP /Domainprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Jede GUID stellt eine Operation dar. Im Container CN=Windows2003Update muss das Attribut Revision den Wert 8 enthalten.
Das ADPREP /Domainprep muss in jeder Domäne, in der ein Windows Server 2003 hinzugefügt werden soll, auf dem Infrastrukturmaster ausgeführt werden.
Für detailierte Infos siehe:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest
Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!
Was macht der Befehl ADPREP /Domainprep /Gpprep?
Dieser Befehl steht ab Windows Server 2003 zur Verfügung und ist bei einer Domänenaktualisierung von Windows 2000 zwingend auszuführen!
Er führt das gleiche wie der Befehl ADPREP /Domainprep aus. Zusätzlich wird durch den Parameter /Gpprep
den Gruppenrichtlinienobjekten im SYSVOL-Verzeichnis vererbbare Zugriffssteuerungseinträge hinzugefügt.
Gibt es etwas vor dem Ausführen von ADPREP zu beachten?
Das Windows 2000 Active Directory-Schema muss eine Schemaaktualisierung zulassen:
Schema Updates Require Write Access to Schema in Active Directory
Des Weiteren wurde in früheren Microsoft-Artikeln empfohlen, den Schemamaster vor dem Ausführen von ADPREP /Forestprep vorübergehend
in ein privates Netzwerk zu isolieren bzw. „offline“ zu nehmen. In der Praxis hat sich diese Vorgehensweise eher als Nachteil erwiesen.
Denn die Schemaänderungen wurden teilweise nach dem Neustart des Schemamasters „zurückgewiesen“.
Wenn man dennoch den Schemamaster vor dem Ausführen von ADPREP /Forestprep isolieren möchte,
dann wäre es empfehlenswert die ausgehende Active Directory-Replikation vorübergehend zu deaktivieren.
Die AD-Replikation lässt sich mit REPADMIN aus den Windows Support Tools deaktivieren. Der Befehl dazu lautet:
REPADMIN /Options +DISABLE_OUTBOUND_REPL
Nach dem Ausführen von ADPREP /Forestprep ist folgendes zu prüfen:
-
Der Befehl Adprep /Forestprep wurde ohne Fehler in der Kommandozeile ausgeführt.
-
Der Container CN=Windows2003Update wurde unter "CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD" erstellt.
Der Wert des Attributs Revision im Container CN=Windows2003Update muss 9 sein.
-
Die Schemaversion wurde auf Version 30 bzw. 31 erhöht. Überprüfen lässt sich die Schema-Version entweder durch die Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\“SchemaVersion“ (die Zahl in Klammern gibt die Version an)
oder durch das Attribut
ObjectVersion das sich unter "CN=Schema,CN=Configuration,DC=Domäne.TLD befindet.
Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Vorausgesetzt dass der Vorgang erfolgreich durchgeführt wurde, ist anschließend die ausgehende Replikation zu aktivieren.
Dazu muss der folgende Befehl in der Kommandozeile ausgeführt werden:
REPADMIN /Options -DISABLE_OUTBOUND_REPL
How to upgrade Windows 2000 domain controllers to Windows Server 2003
Von welcher CD/DVD muss das ADPREP ausgeführt werden?
Das ADPREP muss immer von der Server-CD ausgeführt werden, auf die man aktualisieren möchte.
Das ADPREP befindet sich auf der Windows Server 2003 CD im Verzeichnis CD-Laufwerk:\i386.
Ist der neue DC ein Windows Server 2003 R2, so muss das ADPREP von der zweiten R2-CD aus dem Verzeichnis CD-Laufwerk:\CMPNENTS\R2\ADREP ausgeführt werden.
Unter Windows Server 2008 befindet sich das ADPREP im Verzeichnis: <DVD-Laufwerk>:\Sources\Adprep
Und unter Windows Server 2008 R2 im Verzeichnis: <DVD-Laufwerk>:\Support\Adprep. Achtung: Unter Windows Server 2008 R2 gibt es zwei ADPREP-Versionen.
Eine Version lautet Adprep.exe, mit der man das AD-Schema auf einem x64Bit DC aktualisieren muss. Die andere Version lautet Adprep32.exe, mit der man das AD-Schema auf einem x32Bit DC aktualisieren muss.
Wird hingegen der erste Windows Server 2003 R2 in der 64Bit Version einer 32Bit Windows 2000/2003 Gesamtstruktur hinzugefügt,
so muss von Microsoft entweder ein Hotfix angefordert oder die 32Bit-Trial Version heruntergeladen und von dort das ADPREP ausgeführt werden.
Siehe dazu: Schemaupdate beim Windows Server 2003 R2
Wenn der erste SBS 2003 oder SBS 2003 R2 hinzugefügt werden soll, dann ist das ADPREP von der ersten SBS-CD, im Verzeichnis i386 auszuführen.
In welchen Gruppen muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied sein?
Das Benutzerkonto mit dem das ADPREP ausgeführt wird, muss beim ausführen des Parameters /Forestprep Mitglied in den Gruppen
Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Oder die entsprechenden Berechtigungen müssen dem Benutzerkonto delegiert worden sein.
Beim ausführen von ADPREP mit dem Parameter /Domainprep oder /Domainprep /Gpprep muss das Benutzerkonto Mitglied in der Gruppe
Domänen-Admins sein. Die Delegierung der entsprechenden Berechtigungen an das Benutzerkonto wäre ebenfalls möglich.
Für das Ausführen von ADPREP /RODCPREP muss das Benutzerkonto Mitglied in der Gruppe Organisations-Admins sein.
Auf welche Schema-Version wird das Schema aktualisiert?
Die Schema-Version lässt sich in der Registry (das es unter Start-Ausführen-Regedit aufzurufen gilt) des DCs überprüfen.
Anschließend navigiert man zu folgendem Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters.
Dort kontrolliert man den Eintrag "Schema Version". Die Zahl in Klammern, gibt die Schema-Version an.
Diese wären:
- (13) = Windows 2000 (ohne/mit allen SPs)
- (30) = Windows Server 2003 ohne/mit SP1/SP2 (und höhere SPs)
- (31) = Windows Server 2003 R2 ohne/mit SP2 (und höhere SPs)
- (44) = Windows Server 2008
- (47) = Windows Server 2008 R2
Die Schema-Version lässt sich ebenfalls mit ADSIEdit oder dem Active Directory Explorer überprüfen.
Das zu überprüfende Attribut lautet objectVersion und befindet sich im Container:
CN=Schema,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>.
Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Gibt es auch ein Protokoll vom ADPREP?
Es wird ein ADPREP-Protokoll im Verzeichnis %Systemroot%\System32\Debug\Adprep\Logs
erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
Weitere wichtige Informationen
When you run the "Adprep /forestprep" command to prepare Windows 2000 Active Directory for Windows Server 2003, the forest preparation operation fails
Aktualisieren von einer Windows 2000-Domäne
Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Upgrading from Windows 2000 Server to Windows Server 2003
Wenn im Dateireplikationsdienst-Protokoll die Event-ID 13568 (Journalumbruch-Fehler) protokolliert wird,
liegt ein Problem mit dem System Volume-Verzeichnis (SYSVOL) vor.
Die Erläuterung bzw. das Zustandekommen dieses Fehlers, wird in diesem Artikel beschrieben:
Problembehandlung bei FRS-Ereignis 13568
Im SYSVOL-Verzeichnis werden Dateien, Ordner und Bereitstellungspunkte (Junction Points) gespeichert.
Es ist ein freigegebenes System-Volume auf Domänencontrollern worin sich Gruppenrichtlinienobjekte, Gruppenrichtlinienvorlagen,
Anmeldeskripte und weitere Dateien befinden. Dieses Verzeichnis wird auf alle anderen Domänencontroller der Domäne repliziert.
Je nach Größe und Konfiguration der Active Directory-Domäne, kann das SYSVOL-Verzeichnis recht viel an Festplattenkapazität beanspruchen.
Daher ist darauf zu achten, dass die Partition auf der das SYSVOL-Verzeichnis gespeichert ist, über genügend freien Festplattenspeicher verfügt,
auch in die Zukunft blickend.
Das SYSVOL-Verzeichnis ist auf jedem Domänencontroller mit dem Freigabenamen SYSVOL freigegeben und wird beim Ausführen des
Active Directory-Assistenten DCPROMO automatisch eingerichtet. Es stellt ein wichtiges Verzeichnis in einer Active Directory-Domäne dar.
Denn das ordnungsgemäße Funktionieren von Gruppenrichtlinien, hängt hauptsächlich vom korrekt funktionierenden Betrieb des SYSVOL-Verzeichnisses ab.
Was die Sicherung des SYSVOL-Verzeichnisses anbetrifft, erfolgt diese i.d.R. mit der SYSTEM STATE Sicherung.
Das SYSVOL-Verzeichnis wird vom File Replication Service (NTFRS.exe) und nicht durch die Active Directory-Replikation repliziert.
Sobald eine Änderung in diesem Verzeichnis auftritt, repliziert der FRS automatisch diese Änderung auf die anderen Domänencontroller.
Wenn es um das Troubleshooting des FRS geht, sind in erster Linie die folgenden Tools hilfreich:
Wird nun der Fehler mit der Event-ID 13568 im Dateireplikations-Protokoll eines DCs protokolliert,
wird in der Beschreibung des Fehlers auch gleich die Lösung mitgeliefert.
Diese lautet:
Führen Sie regedit aus, um diesen Registrierungsparameter zu ändern.
Klicken Sie auf "Start", dann auf "Ausführen", und geben Sie dann "regedit" ein.
Erweitern HKEY_LOCAL_MACHINE.
Folgen Sie folgendem Pfad: "System\CurrentControlSet\Services\NtFrs\Parameters"
Doppelklicken Sie auf den Namen des Wertes
"Enable Journal Wrap Automatic Restore"
und aktualisieren Sie den Wert.
Ist der Name des Wertes nicht vorhanden, können Sie ihn mit dem Befehl "Neu" und dann "DWORD-Wert"
im Menü "Bearbeiten" hinzufügen. Geben Sie den Wert genauso ein wie oben gezeigt.
Mit diesem Registry-Eintrag wird eine nicht autorisierte Wiederherstellung des SYSVOL-Verzeichnisses durchgeführt.
Dieser Eintrag macht natürlich nur Sinn, wenn mindestens zwei Domänencontroller in der Domäne existieren.
Ist das System ein Windows 2000 Server mit SP2, so führt das System eigenständig bei Erkennen eines „journal_wrap_errors“ eine
nicht autorisierte Wiederherstellung durch (nicht bei SP1). Dieses Verhalten wurde ab dem SP3 für Windows 2000 Server geändert.
Dafür wurde die Möglichkeit, eines Registry-Eintrags geschaffen. Die Eintragung des Registry-Eintrags funktioniert auch heute,
zu Windows Server 2003 Zeiten noch.
Microsoft empfiehlt aber nicht, diesen Eintrag zu setzen!
Stattdessen wäre folgendes durchzuführen:
-
Es muss geprüft werden, auf welchem Domänencontroller in der Domäne, dass SYSVOL-Verzeichnis komplett
(Policies und Scripts Verzeichnis vorhanden?) und auch freigegeben ist. Ob das SYSVOL freigegeben ist, kann man z.B. in einer
Eingabeaufforderung (CMD) mit dem Befehl NET SHARE überprüfen. Es müsste unter anderem der Pfad „%systemroot%\Sysvol\sysvol“
mit dem Freigabenamen SYSVOL angezeigt werden.
-
Als nächstes sollte sichergestellt werden, dass die NTFS-Junction Points (Bereitstellungspunkte) existieren.
Bereitstellungspunkte stellen Verweise auf andere Verzeichnisse dar. Dieses kann man ebenfalls in einer Eingabeaufforderung überprüfen.
Dazu gibt man in einer Kommandozeile folgenden Befehl ein:
LINKD C:\%windir%\SYSVOL\sysvol\<FQDN>.
Als Ergebnis sollte folgendes angezeigt werden:
Source C:\windows\sysvol\sysvol\<FQDN> is linked to C:\windows\sysvol\domain.
Wie die SYSVOL-Struktur samt den Junction Points weiterhin auszusehen hat, kann man in diesen Artikeln nachlesen:
How to rebuild the SYSVOL tree and its content in a domain
SYSVOL-Administration
Best Practices for Sysvol Maintenance
-
Sollten die Bereitstellungspunkte fehlen, so können diese mit dem Tool LinkD (aus dem Windows Server 2003 Resource Kit) erneut gesetzt werden.
Der Befehl lautet:
Linkd %Systemroot%\SYSVOL\SYSVOL\<DNS-Domänenname> %Systemroot%\sysvol\domain
Linkd %Systemroot%\SYSVOL\staging areas\<DNS-Domänenname> %Systemroot%\SYSVOL\staging\domain
Es gibt auch Tools, mit denen man diese Aufgabe erledigen kann.
Neben dem Tool LINKD könnte auch Junction oder Junction Link Magic verwendet werden.
How to create and manipulate NTFS junction points
Hinweis: Wenn unter Windows Server 2003 das Verzeichnis „%systemroot%\SYSVOL“ kopiert wird, werden nicht die Junction Points mitkopiert.
Unter Windows 2000 wurden die Junction Points ebenfalls kopiert. Daher sollte man generell Vorsicht walten lassen, wenn das SYSVOL
z.B. im Windows Explorer manuell kopiert werden sollte bzw. ganz davon Abstand nehmen!
Denn am Ende hat man nicht das SYSVOL-Verzeichnis kopiert, sondern einen Junction Point.
-
-
Wenn die genannten Punkte erledigt sind, muss auf allen Domänencontrollern der Domäne, der NTFRS Dienst gestoppt werden.
Das stoppen des Dienstes kann einmal in der Kommandozeile erfolgen (net stop ntfrs) oder über die Dienstesteuerung (services.msc).
Der Anzeigename des Dienstes lautet Dateireplikationsdienst.
-
Auf dem Domänencontroller, auf dem das SYSVOL-Verzeichnis ordnungsgemäß vorhanden ist, setzt man unter folgendem Registry-Pfad:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\<GUID>"
den bereits vorhandenen Eintrag Burflags auf den Wert D4 (Authoritative Restore).
Der Wert D4 darf nur auf einem Domänencontroller eingetragen werden.
Hinweis: Unter Cumulative Replica Sets existiert i.d.R. eine GUID, nämlich die des SYSVOL-Verzeichnisses.
Wäre DFS noch im Einsatz, gäbe es noch einen weiteren Eintrag mit einer anderen GUID.
-
Anschließend ist auf den weiteren Domänencontrollern der Domäne (im gleichen Registry-Pfad), im vorhandenen Eintrag Burflags,
der Wert diesmal auf D2 (Non-Authoritative Restore) zu setzen.
-
Nun gilt es zuerst auf dem Domänencontroller, auf dem Burflags auf D4 gesetzt wurde, den NTFRS-Dienst (net start ntfrs) zu starten.
Nach dem Start vom NTFRS bleibt der Burflags Eintrag vorhanden, lediglich der Wert wird auf 0 (genullt) zurückgesetzt.
Danach wird im Dateireplikations-Protokoll der Event-Eintrag 13566 protokolliert. Dieser bedeutet, dass eine autorisierende
Wiederherstellung gestartet wurde. Die Dateien die vom FRS repliziert werden, bleiben unverändert und werden dabei als autorisierend gekennzeichnet.
Zusätzlich wird die FRS-Datenbank neu erstellt. Mit ein wenig Geduld, muss anschließend der Event-Eintrag 13516 protokolliert werden.
Denn erst dann, ist der FRS einsatzbereit.
-
Wenn alles planmäßig ausgeführt wurde, ist auf den restlichen Domänencontrollern der Domäne (auf denen der Wert Burflags D2 gesetzt wurde),
ebenfalls der NTFRS-Dienst zu starten. Der FRS-Dienst setzt dabei ebenfalls den Wert von Burflags zurück auf 0. Des Weiteren werden die Verzeichnisse
Policies sowie Scripts in ein Verzeichnis Namens NtFrs_PreExisting___See_Eventlog verschoben, das sich wiederum unterhalb von
„%systemroot%\SYSVOL\sysvol\FQDN\“ befindet. Das Verzeichnis NtFrs_PreExisting___See_Eventlog wird aus Sicherheitsmaßnahmen vom
Dateireplikationsdienst erstellt und soll einen versehentlichen Datenverlust vermeiden. Im Dateireplikations-Protokoll wird der Event-Eintrag 13565
verzeichnet. Dieser bedeutet, dass eine nicht autorisierte Wiederherstellung gestartet wurde. Anschließend wird die FRS-Datenbank neu erstellt
und es wird eine vollständige Replikation des SYSVOL-Verzeichnisses durchgeführt. Wenn alles ordnungsgemäß ausgeführt wurde,
wird im Dateireplikations-Protokoll der Event-Eintrag 13516 verzeichnet. Danach wäre der FRS betriebsbereit.
Im Anschluss wäre es empfehlenswert, mit den bereits o.g. FRS-Tools oder DCDIAG, die FRS-Replikation zu überprüfen.
Eine abschließende Kontrolle auf allen DCs sollte folgende Aufgaben beinhalten:
-
Existiert auf allen Domänencontrollern das SYSVOL-Verzeichnis und wurde es auch freigegeben?
-
Ist der Inhalt vom SYSVOL-Verzeichnis auf allen Domänencontrollern vollständig und auf allen DCs gleich?
-
Existieren auf allen Domänencontrollern die Junction Points?
-
Werden im Dateireplikations-Protokoll der Domänencontroller noch Fehler gemeldet (was logischerweise nicht der Fall sein sollte)?
-
Melden die Diagnose-Tools Fehler?
Weitere Informationen:
Using the BurFlags registry key to reinitialize File Replication Service replica sets
Troubleshooting journal_wrap errors on Sysvol and DFS replica sets
The Sysvol and Netlogon Shares Are Missing After You Restore a Domain Controller from Backup
Description of FRS entries in the registry
Morphed folders appear in the SYSVOL Group Policy folder after you use Group Policy Object Editor to view a GPO on a Windows Server 2003-based domain controller
How to relocate the SYSVOL tree on a domain controller that is running Windows 2000 Server or Windows Server 2003
You cannot replicate files from a Windows Server 2003-based domain controller and events are logged in the File Replication Service log
Steht eine Migration bevor, z.B. von Windows 2000 auf Windows Server 2003, sollte stets die Ausgangsbasis kontrolliert werden.
Bevor ein solcher Schritt durchgeführt wird, wäre es empfehlenswert, den Zustand der Domänencontroller zu überprüfen um während der
Migration keine bösen Überraschungen zu erleben.
Auf der anderen Seite ist es eines der Routineaufgaben des Administrators, den Status der Domänencontroller regelmäßig zu überprüfen.
In beiden Fällen, sind die beiden Windows Support Tools DCDIAG sowie NetDIAG hilfreich. Mit diesen Tools lassen sich Fehler schnell aufdecken.
Kommt es dabei, beim ausführen von DCDIAG zu folgender Warn-Meldung:
Starting test: MachineAccount
Warning: Attribute userAccountControl of <DC-NAME> is: 0x82020 = ( UF_PASSWD_NOTREQD | UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
Typical setting for a DC is 0x82000 = ( UF_SERVER_TRUST_ACCOUNT | UF_TRUSTED_FOR_DELEGATION )
This may be affecting replication?
......................... <DC-NAME> passed test MachineAccount
ist der Grund für diese Meldung, dass der Wert des Attributs User-Account-Control vom Domänencontroller-Computerobjekt nicht korrekt ist.
Als Wert des Attributs ist 0x82020 (Hex) eingetragen. Allerdings müsste entweder 0x82000 (Hex) bzw. 532480 (Dezimal) darin enthalten sein.
Das Flag PASSWD_NOTREQD ist im Computerobjekt des Domänencontrollers gesetzt, was nicht der Fall sein sollte.
Das gesetzte Flag PASSWD_NOTREQD bedeutet, dass kein Kennwort erforderlich ist.
Der Wert des Attributs lässt sich recht einfach mit LDP.exe oder ADSIEdit.msc korrigieren.
Die Vorgehensweise mit ADSIEdit.msc wäre folgende:
-
Zuerst gilt es über Start-Ausführen-Adsiedit.msc aufzurufen.
-
Danach ist eine Verbindung mit der Domänen-Partition herzustellen, falls keine bestehen sollte.
-
Im nächsten Schritt navigiert man zu der OU bzw. zu dem Container, in dem sich das Domänencontroller-Objekt befindet.
Standardmäßig befinden sich die Domänencontroller-Objekte in der "OU=Domain Controllers".
-
Dort wählt man mit einem Rechtsklick auf dem entsprechenden Domänencontroller-Objekt, die Eigenschaften aus.
-
Im Anschluss gilt es das Attribut User-Account-Control auszurufen und den Wert auf "532480" zu korrigieren.
Das Attribut User-Account-Control lässt sich mit DSQUERY abfragen.
Der Befehl dazu lautet folgendermaßen:
Dsquery * domainroot -filter "(&(objectCategory=Computer)(objectClass=Computer)(Name=DC-NAME))" -attr userAccountControl
Weitere Informationen:
How to use the UserAccountControl flags to manipulate user account properties
|
Copyright © 2013 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|