Grundsätzlich sind Snapshots eine feine Sache. Kann man doch schnell und unkompliziert Daten Sichern oder Wiederherstellen oder in Virtuellen Welten mal schnell etwas testen. Seit heute hängt über dieser Annahme ein gewaltiges Fragezeichen. Zumindest Domain Controller können das Anwenden von Snapshots sehr übel nehmen.

In Umgebungen mit mehr als einem DC finden bekanntlich Replikationen statt. Wendet man nun einen alten Snapshot an ist dies für den betroffenen Domain Controller wie eine Wiederherstellung der AD Datenbank einer älteren Version. Grundsätzlich nimmt man nun an hier wird es zu keinen größeren Problem kommen. Durch die „Update Sequence Numbers” (USN) sollten die veralteten Einträge des „wiederhergestellten” DC einfach durch die aktuelleren überschrieben werden.

Leider falsch. Dies kann funktionieren, muss es aber nicht! Der Domain Controller kann diese Prozedur auch als „nicht unterstützte Wiederherstellung” erkennen, was einen NetLogon Dienst im Status „angehalten” und diesen Eintrag im Eventlog nach sich ziehen kann:

ActiveDirectory_DomainService / NTDS General:  Event 2103

The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. User Action See previous event logs for details. For more information, see Help and Support Center at http://…

Was auch als “USN Rollback” bezeichnet wird. Zudem finden sich zahlreiche Einträge zum Thema „Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)” in den Logs.

Was war passiert?

Die Umgebung betroffene Umgebung war eine „grüne Wiese” Installation für eine größere Migration bei einem Kunden. Zwar war sie noch nicht produktiv, dennoch steckte schon eine Menge Arbeit in der Einrichtung, inklusive Exchange 2010, PKI, etc.  Zum Zeitpunkt des Vorfalls bestand die Gesamtstruktur aus 1 Root- sowie 5 Child Domains auf Basis Windows Server 2008 R2. Alle DC’s wurden als virtuelle Server in einem Hyper-V 2 Cluster bereitgestellt. Für die Root Domain sowie eine Child Domain existierte bereits ein 2., physikalischer DC auf den alle FSMO Rollen übertragen wurden.

Durch einen „Unfall” ging die LUN verloren, auf der alle Hyper-V Gastsysteme abgespeichert waren. Die LUN konnte aus einem SAN Snapshot wiederhergestellt werden. Dieser Snapshot war jedoch rund 15-30 Minuten alt. Zunächst konnten alle Systeme wieder problemlos gestartet werden. Jedoch waren die Eventlogs voll mit Replikationsproblemen (Event IDs 1388, 1988, 2042). Im Falle des virtuellen DC der Root Domain erschien auch der Event 2103. Zudem war der Dienst „NetLogon” im Zustand „paused”.

Leider finden sich auf Anhieb nicht wirklich viele Informationen in der Microsoft Knowledge Base oder einschlägigen Foren. Der allgemeine Tenor zum Event 2103 lautete: AD auf dem DC entfernen und neu installieren. Sicher eine Lösung, aber nicht unbedingt eine befriedigende.

Und an dieser Stelle gilt unser Gruß und Dank Jan Kappen, der unter Einsatz von Blut Schweiß und reichlich Kaffee dieses Problem bereits mit dem Microsoft Support gelöst und freundlicherweise dokumentiert hat!

Hier die Schritte in der Kurzfassung:

Beseitigung Event 2103:

• HKLM\System\CurrentControlSet\Services\NTDS\Parameters
  • “Dsa Not Writable” von 4 auf 0 setzen
  • REG_DWORD “Ignore USN Rollback” anlegen und auf 0 setzen
• Server neu starten (NetLogon sollte nun laufen)
• Replikation wieder aktivieren:
  • repadmin /options “Servername” -DISABLE_OUTBOUND_REPL
  • repadmin /options “Servername” -DISABLE_INBOUND_REPL

Nun waren nur noch ein par “Lingering Objects” übrig welche die Replikation blockierten. Diese Objekte können ebenfalls mit dem „repadmin” entfernet werden. Dazu gibt es aber diverse Anleitungen so dass ich es nicht näher beschreibe.

Da unser Snapshot nur 15-30 Minuten alt war mussten wir kein DC Computer Konto zurücksetzen. Dies hat Jan aber auch gut beschrieben.

Viel Erfolg!

Andy

Quelle: Hyper-V, ADS-Controller und angewendete Snapshots [Update]

Ein Server Core stellt für die meisten GUI verwöhnten Windows Administratoren eine gewisse Herausforderung dar. Eine davon ist das Initialisieren neuer Disks mit DISKPART, zumal sich hier auch das Verhalten gegenüber Windows Server 2003 verändert hat. So ist eine neue Disk zunächst „Read Only”.

Dieses Attribut verhindert nach dem Onlinenehmen der Disk jede weitere Bearbeitung. Es kann jedoch recht einfach entfernt werden. Dazu habe ich einmal die üblichen Befehle zum Einrichten einer neuen Disk aufgelistet:

• RESCAN (sofern die Disk im laufenden Betrieb angehängt wurde)
• LIST DISK
• SELECT DISK x (hier besonders aufpassen das es die Richtige ist. )
• ONLINE
• ATTRIBUTE DISK CLEAR READONLY
• CONVERT GPT (optional)
• CREATE PARTITION PRIMRAY
• FORMAT FS=NTFS QUICK LABEL=”<label>”
• ASSIGN LETTER=<X>

Viel Erfolg,

Andy

Es gibt sicherlich diverse Anleitungen zur Migration von LCS 2005 SP1 nach OCS 2007 R2. Jedoch sind die meisten davon an irgendeiner Stelle etwas unverständlich oder uneindeutig. Da eine solche Migration wenig Spielraum für Fehler lässt habe ich sie im Lab durchgespielt und dokumentiert. Ich habe dabei den Weg der Koexistenz gewählt, da dieser den geringsten Einfluss auf laufende Umgebungen hat und daher am häufigsten angewendet wird.

Lab Setup (Hyper-V V2):

• DC Windows Server 2003 R2 x86
  • AD 2003, Forest und Domain 2003 native
• LCS 2005 SP1 SE auf Windows Server 2003 R2 x86
• Communicator 2005 auf Windows XP Pro x86 (2x)
• Communicator 2007 R2 auf Windows XP Pro x86
• Windows Server 2008 SP2 x64 für OCS 2007 R2 SE

Voraussetzungen:

• Active Directory mind. Version Windows Server 2003, Forest und Domain im 2003 native Mode
• LCS 2005 SP mit den Updates KB911996 und KB921543 (in dieser Reihenfolge installieren!)
• Einen Benutzer mit folgenden Privilegien:
  • Enterprise Admin
  • Schema Admin
  • Domain Admin (in Multi Domain Umgebung)
  • RTCDomainServerAdmin

Durchführung:

Schritt 1:

Alle LCS Dienste stoppen

Schritt 2:

Migration der Global Settings aus dem System Container in den Configuration Container. Dieser Schritt verschiebt die Einstellungen des LCS/OCS im Active Directory. Er ist derzeit optional, der bisherige Speicherort ist jedoch nicht optimal und wird wahrscheinlich von künftigen Versionen nicht mehr unterstützt. (mehr dazu siehe technische Referenz)

Wichtig! dieser Schritt MUSS vor dem Schema Update auf Version 1008 (OCS 2007 R2) durchgeführt werden! Danach funktioniert das Tool nicht mehr und OCS muss komplett neu installiert werden (DB Export, AD Bereinigung, etc.)!

• Installation von MigrateOCS.msi auf einem x86 Server (in diesem Fall der LCS, macht die Sache einfacher)
• Ausführen der folgenden Befehle (standard Pfad zum Script ist C:\MigrateOCS):
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateGlobalSettingsTree
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateGlobalSettingsProperties
• Nun muss ForestPrep und DomainPrep für den neuen Speicherort der Konfiguration wiederholt werden. Diese Befehle müssen auf dem LCS Server ausgeführt werden und funktionieren NUR wenn die beiden Updates installiert wurden! Sie dürfen zudem nicht aus der GUI gestartet werden! (standard Pfad: c:\program files\common files\microsoft LC 2005)
  • LcsCmd /Forest /Action:ForestPrep /global:configuration
  • LcsCmd /Domain /Action:DomainPrep
• Im Anschluss werden Server und User Objekte neu Referenziert und die alte Konfiguration wird bereinigt:
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateServerDnReferences /SearchBaseDN:dc=domain,dc=local
  • cscript MigrateOcsGlobalSettings.vbs /Action:MigrateUserDnReferences /SearchBaseDN:dc=domain,dc=local
  • cscript MigrateOcsGlobalSettings.vbs /Action:DeleteSystemGlobalSettingsTree

Hinweis: Je nach Geschwindigkeit und Anzahl von Replikationsverbindungen sollte zwischen den Ausführungen eine ausreichende Zeit gewartet werden! Zudem kann es passieren dass einzelne Schritte mehrfach ausgeführt werden müssen. Dies meldet das Script in seiner Ausgabe!

Schritt 3:

Alle LCS Server neu starten.

Nun sollten alle LCS Clients wieder normal funktionieren.

Schritt 4:

Installation OCS 2007 R2

Die Installation folgt nun der üblichen Vorgehensweise:

• AD Vorbereitung
  • SchemaPrep
  • ForestPrep
  • DomainPrep
• Deployment (siehe auch hier: OCS 2007 und KB974571)

Die DNS Konfiguration benötigt nun noch eine gewisse Planung. Grundsätzlich kann und sollte hier der neue OCS 2007 R2 Pool als Ziel des SRV Eintrags vorgesehen werden. Er wird den Client authentifizieren und an den richtigen (LCS) Front End Server weiterleiten.

Hinweis: Während der Migration ist die Reihenfolge beim Update des Clients wichtig für einen nahtlosen Übergang:

• Während des Verschiebens der Benutzer von LCS nach OCS kann nur der LCS Client verwendet werden.
  • Der Communicator 2007 R2 ist nicht mit dem LCS Server kompatibel!
  • Der LCS Client kann sich mit dem OCS 2007 R2 Front End Server verbinden, jedoch steht “Enhanced Prensence” nicht zur Verfügung.
• “Enhanced Prensence” darf erst aktiviert werden wenn sichergestellt ist dass der Benutzer nur noch Clients ab Version 2007 verwendet. Dies gillt auch für Communicator Web Access oder den Communicator Mobile!
  • Sobald “Enhanced Prensence” aktiviert und ein Client ab Version 2007 erfolgreich angemeldet wurde, können sich ältere Clients nicht mehr verbinden.

Sieh auch: Migrating from LCS 2005 SP1 to OCS 2007 R2 - which client can you use when?

Viel Glück & Erfolg!

Andy

Nach dem Hotfix KB974571 hat es diverse Probleme im Zusammenhang mit LCS/OCS Eval Versionenen gegeben. Nun ist ein Fix namens OCSASNfix.exe erscheinen. Er kann über die Seite des Hotfixes bezogen werden: http://support.microsoft.com/kb/974571 (direkter Download Link hier klicken). Bei bereits installieren Systemen ist dies auch problemlos möglich. Etwas komplizierter wird jedoch eine neue OCS Installation.

Grundsätzlich kann man natürlich den Hotfix KB974571 auch erst nach der Installation von OCS installieren. Möchte man dies nicht, oder ist er bereits im Windows installiert, wird es bei der Installation von OCS R2 spannend. Der Patch OCSASNfix.exe wirkt erst wenn die OCS Binaries bereits installiert ist. Die Installation scheitert jedoch bei der Aktivierung des Standard Servers mit einer obskuren Meldung, man solle doch Datum und Uhrzeit des Servers prüfen. Dies gilt interessanterweise auch für die nicht Eval Version der OCS Installationsquellen:

Failure: [0xC3EC796C] One or more errors occurred during execution of the wizard; the wizard was unable to complete successfully. Please check the log file for more information.

Failure: [0xC3EC78D8] Failed to read the Office Communications Server version information. This can happen if the computer clock is not set to correct date and time.

Nun muss man einfach die Nerven behalten und folgende Reihenfolge bei der Installation einhalten:

• Installation des Standard Server mit dem Assistenten (wird bei der Aktivierung scheitern)
• OCSASNfix.exe ausführen (wird zwar melden dass keine Eval Version gefunden wurde, ändert aber wohl doch irgendwas)
• Den Installationsassistenten noch einmal ausführen. Er mit der Aktivierung fortfahren, welche jetzt auch gelinngen sollte

Andy

Das Microsoft Deployment Toolkit 2010 eröffnet jedem kleinen und mittleren Unternehmen einen kostengünstigen Einstieg in automatisiertes, standardisiertes  und rationelles Client Deployment. Auch wenn der Fokus dieses Programms eindeutig auf dem Deployment von Windows 7 bzw. der Migration dazu hin liegt, kann auch Windows XP installiert werden.

Neben einigen, designbedingten Einschränkungen bei der Installation von XP gibt es jedoch zumindest ein gravierendes Problem: Mit den vorhandenen Skripts lässt sich kein einfacher Hardware Austausch bewerkstelligen, wenn Windows XP auf den neuen System installiert sein soll. In diesem Fall funktioniert die Übernahme von lokalen Profilen mit Hilfe von USMT nicht. Mit wenigen Handgriffen lässt sich jedoch ein Workaround erstellen.

Update: Bitte beachten Sie auch den Hinweis von Maik in den Kommentaren!

Bei unseren Tests stellte sich rasch heraus dass die MDT Scripts zum Erstellen der User State Sicherungen USMT 4 benutzt. Beim Versuch diese Daten auf einem neu installierten XP wiederherzustellen, scheiterte dies. Die Skripte Benutzen in diesem Fall automatisch USMT3, da USMT4 unter XP nur den User State sichern, nicht aber wiederherstellen kann. Das Script endet mit der Fehlermeldung “no user state folder (USMT3)”. Zudem wären die USMT3 Dateien im AIK für Windows 7 gar nicht vorhanden.

Als Workaround kann nun USMT 3 für Erstellung der User States verwendet werden. Dazu sind folgende Schritte notwendig:

• Download von USMT 3.01
• Speichern der beiden MSI Pakete (x86 und x64) in den jeweiligen Ordnern im <Deployment Share>\Tools Verzeichnis
• Kopieren der Script Datei ZTIUserState.wsf, z.B. in ZTIUserStateUSMT3.wsf
• Ändern der kopierten Script Datei (rot markierte Stellen einfügen bzw. ändern):

Class Header anpassen:

‘//—————————————————————————-
‘// Main Class
‘//—————————————————————————-

Class ZTIUserStateUSMT3

Im weiteren Verlauf USMT3 erzwingen, egal was vom Sctipt ermittelt wird:

‘ Deterine if we are going to run USM3 or USMT4
If Ucase(oEnvironment.Item(”USMT3″)) = “YES” and Left(oEnvironment.Item(”OSCURRENTVERSION”),3) < “6.1″ then
sUSMTVersion = “USMT3″
Else

If Left(oEnvironment.Item(”ImageBuild”),3) < “6.0″ and oENvironment.Item(”DeploymentType”) <> “REPLACE” and oEnvironment.Item(”DeploymentMethod”) <> “SCCM” Then
oLogging.CreateEntry “Windows XP is being deployed, assuming USMT 3″, LogTypeInfo
sUSMTVersion = “USMT3″
Else
sScanState=”scanstate.exe”
iRetVal = oUtility.FindFile(sScanState, sFoundScanState)
If iRetVal = Success then
If Left(oFSO.GetFileVersion(sFoundScanState),3) = “6.1″ then
oLogging.CreateEntry “Found USMT 4 executables. Using USMT 4″, LogTypeInfo
sUSMTVersion = “USMT4″
Else
oLogging.CreateEntry “USMT 4 executables were not found, using USMT 3″, LogTypeInfo
sUSMTVersion = “USMT3″
End if
Else
oLogging.CreateEntry “Executables were not found, assuming USMT 3 installer”, LogTypeInfo
sUSMTVersion = “USMT3″
End if

End If
End If

sUSMTVersion = “USMT3″

‘//—————————————————————————-
‘// See what we need to do
‘//—————————————————————————-

• Nun eine neue  Tasksequenz für das Client Replacement erstellen und im Task “Capture User State” den Commandline Befehl auf das zuvor geänderte Skript ändern:

cscript.exe “%SCRIPTROOT%\ZTIUserStateUSMT3.wsf” /capture

Nun kann der Client Replacement Task wie gewohnt ausgeführt und beim Deployment von Windows XP der User State zurückgeschrieben werden.

Dieses Script funktioniert natürlich nicht mehr wenn zu Windows 7 hin migriert werden soll! Dann muss der Replacement unverändert ausgeführt werden.

Andy.

Ganz aktuell ist die Meldung über ein Problem, welches durch den Hotfix KB974571 in Zusammenhang mit dem Live Communications Server und Office Communications Server ausgelößt wird. Nach der Installation befindet sich der LCS / OCS Server im Zustand einer abgelaufenen Evaluierungsphase und startet nicht mehr.

UPDATE: Das Problem betrifft auch den Client! Auch hier darf der Hotfix derzeit nicht installiert werden! Zumindest auf dem Client konnte eine Deinstallation des Hotfix erfolgreich durchgeführt werden und hat das Problem gelöst.

Vom Fehler betroffen sind alle Versionen des LCS 2005, OCS 2007 und OCS 2007 R2. Derzeit ist kein Patch veröffentlicht, so dass die Installation des Hotfixes auf betroffenen Servern verhindert werden sollte! Ob eine Deinstallation erfolgreich durchgeführt werden kann ist derzeit nicht bekannt.

Andy

Quelle: http://blogs.technet.com/dodeitte/archive/2009/10/13/do-not-apply-kb974571-to-lcs-ocs-servers.aspx

Exchange 2007 Service Pack 2 ist verfügbar. Bei der Installation in meiner Testumgebung hat sich allerdings ein kleiner Fehler offenbart. Beim Versuch das Service Pack zu installieren brach der Rediness Check mit folgender Begründung ab:

[03.10.2009 13:57:31] [1] [ERROR] The Active Directory Schema must be modified and this user account has insufficient permissions. It must be a member of both the ‘Schema Admins’ and ‘Enterprise Admins’ groups.
[03.10.2009 13:57:31] [1] [ERROR] Global updates need to be made to Active Directory, and this user account is not a member of the ‘Enterprise Admins’ group.

Meine Testumgebung besteht aus einer einzelnen Active Directory Domain in einem einzelnen Active Directory Forest.  Der für das Upate verwendete Benutzer ist Mitglied in den folgenden Gruppen:

• Domain-Admins
• Schema-Admins
• Exchange Organization Adminstrators

In meinen Augen sollte dies die vollständige Macht über meine Testumgebung erlauben. Besonders die Anforderung an die Mitgliedschaft in der “Enterprise Admins” Gruppe machte mich stutzig, da diese in meiner single Domain die gleiche Verschachtelung in die Gruppe “Builtin\Administrators” hat wie die “Domain Admins” Gruppe.

Ich habe dann einmal den vordefinierten “Administrator” verwendet. Dieses Konto wurde vom Rediness Check akzeptiert. Schließlich war es die direkte Mitgliedschaft in der Gruppe “Builtin\Administrators” welche den Ausschlag über Erfolg oder Misserfolg des Rediness Checks gibt. Anscheinend funktioniert beim Rediness Check die Prüfung verschachtelter Gruppenmitgliedschaften nicht richtig.

Andy

Unter Hyper-V kann es auf Windows 2003 Domain Controllern zu regelmäßigen Eventlog Einträgen kommen, welche augenscheinlich keine Ursache haben. So wird alle 10 Minuten folgender Event protokolliert:

ID: 1054
Source: Userenv
Version: 5.2
Symbolic Name: EVENT_FAILED_DSNAME
Message: Windows cannot obtain the domain controller name for your computer
network. (An unexpected network error occurred). Group Policy processing aborted.

Ähnliche Probleme treten z.B. bei multihomed Servern, DNS Problemen oder AMD Mehrprozessorsystemen ohne entsprechende Treiber auf.

Diese Ursachen konnten jedoch ausgeschlossen werden. Da sich der Event durch ein manuelles Update der Gruppenrichtlinien (GPUPDATE) nicht erzwingen lies lag die Vermutung nahe, dass die Ursachen weder im Netzwerk noch bei DNS zu suchen war. Blieb nur ein Problem mit dem System Timer. Die Option /usepmtimer war schnell in die boot.ini eingefügt und getestet und hat sich als Lösung erwiesen.

Siehe auch KB895980

Andy

In Windows Vista wurde die User Account Control (UAC) erstmals eingeführt. Die im Grunde sehr sinnvolle Funktion verhindert das ungewollte Ausführen von Prozessen mit administrativen Rechten wenn ein entsprechender Benutzer angemeldet ist. Bei den meisten Heimanwendern ist es nun mal der Normalfall dass mit vollen, administrativen Rechten gearbeitet wird. In der Folge wird auch jede Schadsoftware mit Admin Rechten ausgeführt und kann sich ungebremst installieren. Die UAC verhindert dies sehr zuverlässig. Auch Benutzer mit administrativen Rechten arbeiten zunächst mit reduzierten Privilegien. Sollen erhöhte Rechte eingesetzt werden macht Windows darauf optisch und akustisch aufmerksam und fragt nach einer Bestätigung dieser Aktion.

Bei Windows Vista wurde diese Funktion aber schnell als lästig empfunden. Die Abfragen kamen sehr häufig und teilweise mehrfach bei ein und derselben Aktion. Daher haben viele Anwender die UAC komplett abgeschaltet. Ein Schritt welcher absolut nicht zu empfehlen ist, reduziert er doch drastisch die Sicherheit des Systems!

In Windows 7 ist es nun möglich die UAC in verschiedenen Stufen einzustellen. Leider reduziert bereits die zweitschärfste Stufe die Sicherheit so drastisch dass die UAC leicht ausgehebelt werden kann und somit faktisch wirkungslos ist. Um die Abfragen zu reduzieren wurde unter Anderem die sog. „AutoElevate” Funktion eingeführt. Damit können bestimmte Anwendungen, welche mit einer von Microsoft vergebenen Signatur versehen sind, automatisch erhöhte Privilegien anfordern. Leider höhlt diese Funktion die strikte Trennung von administrativen und eingeschränkten Konten aus. Es kursieren bereits Exploits um diese Schwächen auszunutzen. Dies scheint in einigen Fällen gar nicht notwendig zu sein. So lassen sich z.B. in der Standard Einstellung Antiviren Programme ohne Nachfrage der UAC entfernen.

Selbst Microsoft bezeichnet die UAC nicht mehr als „Security Feature” sondern als Funktion zur Erhöhung der Systemstabilität. Allerdings ist es möglich den gleichen Schutz wie unter Windows Vista zu erlangen. Dazu muss lediglich die Einstellung auf die höchste Stufe  „Immer Benachrichtigen” gestellt werden (Start -> UAC). Dann erhöht sich zwar die Anzahl der Nachfragen, es sind aber dennoch weniger als bei Vista da z.B. mehrfache Anfragen nicht mehr auftauchen.

Leider hat Microsoft diese höchste Stufe nicht als Standardeinstellung vorgegeben. Dies ist insbesondere dadurch tragisch als dass sich viele Anwender in falscher Sicherheit glauben. Ich kann daher nur empfehlen diese Einstellung sofort auf jedem Windows 7 Client vorzunehmen!

Andy

Ich hatte wieder einmal mit der Fehlersuche von Client Boot- und Anmeldevorgängen zu tun. Augenscheinlich werden Gruppenrichtlinien nicht korrekt verarbeitet, was zum Verlußt von lokalen Berechtigungen führte. Informationen zur Anhebung von Protokollierungsleveln sind spärlich. Glücklicherweise bin ich über einen aktuellen Blog Eintrag gestolpert der alle wichtigen Einstellungen für Windows XP / Vista zusammen fasst.

• User Login General:
  • Registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
    • Name: UserEnvDebugLevel
    • Data Type: REG_DWORD
    • Data Value: 30002
  • File: %windir%\debug\usermode\UserEnv.log
• Group Policy Security:
  • Registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GpExtensions\{827d319e-6eac-11d2-a4ea-00c04f79f83a}\
    • Name: ExtensionDebugLevel
    • Data Type: REG_DWORD
    • Data Value:  0×2
  • File: %windir%\security\logs\winlogon.log
• Folder Redirection:
  • Registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
    • Name: FdeployDebugLevel
    • Data Type: REG_DWORD
    • Data Value:  0×0f
  • File: windir%\debug\usermode\fdeploy.log
• Software Installation via GPO:
  • Registry: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
    • Name: Appmgmtdebuglevel
    • Data Type: REG_DWORD
    • Data Value:  0000009b
  • File: %windir%\debug\usermode\appmgmt.log
• Netlogon:
  • Registry (delete the current value is exist): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
    • Name: DBFlag
    • Data Type: REG_DWORD
    • Data Value:  2080FFFF (hexadecimal)
  • File: %windir%\debug\netlogon.log
• GPP:
  • Done via GPO: Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and Tracing* The GPO is writing to the Registry in the following location (for example Printers Mapping): HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{BC75B1ED-5833-4858-9BB8-CBF0B166DF9D}
    • In the GPO you determine the log creation, the default on XP systems is “%SYSTEMDRIVE%\Documents and Settings\All Users\Application Data\GroupPolicy\Preference\Trace\user.log”. On Vista OS the location is : “%systemdrive%\ProgramData\GroupPolicy\Preference\Trace\user.log”
  • Special Vista GPO Tracing:
    • Event Logs:  Applications and Services Logs\Microsoft\Windows\Group Policy\Operational
    • You can use gplogview with “-m” to view online status of the GPO processing
  • Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics
    • Name: GPSvcDebugLevel
    • Data Type: REG_DWORD
    • Data Value:  00030002
  • File: C:\Windows\debug\UserMode\gpsvc.log

Da diese Logs zum Teil erhebliche Datenmengen produzieren sind in vielen Fällen nicht alle notwendig. Zu den interessantesten Log’s gehört das Netlogon Log. Es enthält eine recht übersichtliche, zeitliche Abfolge des Anmeldevorgangs und kann auf Verzögerungen hinweisen.

Andy

Quelle: Snir Hoffmann’s Blog