İncelemek istediğimiz loglar nerede duruyor ?
Windows XP, Group Policy ile ilgili log dosyalarını C:\windows\debug\UserMode altında userenv.log adıyla metin formatında oluşturmaktadır. Bu dosyaların boyu maksimum 1 MB olabileceği için dosya boyunun aşılması halinde, userenv.bak ismiyle arşivlenmekte ve yeni bir dosya açılmaktadır.
Loglama seviyesini nasıl arttırırım ?
XP, varsayılan modda düşük seviyede loglama yapmaktadır. Registry’de yapılacak değişikliklerle loglamayı maksimum seviyeye çıkartmak mümkündür. Bunun için aşağıdaki değerler kullanılabilir. Daha detaylı bilgi için bkz : http://support.microsoft.com/default.aspx?scid=kb;en-us;221833
Subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Entry: UserEnvDebugLevel
Type: REG_DWORD
Value data: 10002 (Hexadecimal)
UserEnvDebugLevel can have the following values:
NONE 0×00000000
NORMAL 0×00000001
VERBOSE 0×00000002
LOGFILE 0×00010000
DEBUGGER 0×00020000
Kişisel not olarak, loglamayı maksimum seviyeye çekince (0×00010002) makinayı yeniden başlatmaya gerek kalmadan loglama seviyesinin arttığını söyleyebilirim. Ancak loglama bu seviyede gerçekten çok fazla kayıt üretiyor. Sorunsuz bir PC’de sıradan bir Gpupdate /force sonrası 600 satıra yakın kayıt eklendiğini belirteyim. Bu nedenle, iş bitiminde loglama seviyesinin eski haline döndürülmesi kesinlikle önemli bir detay.
Loglardaki bu kayıtlar ne anlama geliyor ?
Group policy’nin istemci tarafındaki loglaması çoğunlukla anlaşılabilir bir dilde hazırlanmış ve kodlardan çok anlamlı cümleler şeklinde geçiyor. Ancak bazı noktalarda hata kodlarını ve “Return code”ları bilmek gerekiyor. Bu konudaki en detaylı kaynak aşağıda yer alıyor.
http://technet.microsoft.com/en-us/library/cc786775.aspx
Loglarda görülen en büyük eksiklik, saatle birlikte tarih kaydının olmaması. Bu durumda biraz tahmin yürütmek gerekiyor. Aşağıdaki prosesi soldan sağa doğru okuyacak olursak şöyle sıralanıyor.
İşlem kodu, işlemin saati, İşlemin adı, hatanın kısa açıklaması.
Nelere dikkat etmeli
Her GPO’nun bir master ve de bir DC replikası olduğunu hatırlıyoruz. Zaman zaman FRS problemleri nedeniyle replikasyon eksikleri olan şube DC’lerinde GPO’ların eksiksiz kopyalanmadığını da görmüştük. Bir PC’de GPO’nun sağlıklı uygulanıp uygulanmadığını anlayabilmek için aşağıdaki kayıtlara da dikkat etmek gerekiyor. Örnekteki gibi her GPO’nun GPC ve GPT numaraları aynı olmalı. Aynı olması GPO’nun senkron olduğu anlamına gelecektir.
Aşağıda sıralanmış hata örnekleri sıkça karşınıza çıkabilir ancak bizim aradığımız hatalar bunlar değil. Gözardı edebilirsiniz.
1- USERENV(3b8.3bc) 19:13:56:917 MyRegUnLoadKey: Failed to unmount hive 00000005
2- USERENV(3b8.3bc) 19:01:33:705 UnloadUserProfileP: Didn’t unload user profile <err = 5>
Daha yakışıklı hatalar arıyoruz J. Bunlar gibi :
1- USERENV(2c0.c4) 08:39:20:562 GetWbemServices: CoCreateInstance returned 0x800401f0
2- USERENV(2c0.280) 23:28:22:072 ProcessGPOs: GetGPOInfo failed.
Elbette daha dikkat edilmesi gereken bir çok detay var ama bunları da başka bir yazıda aktarmaya çalışacağım.
Microsoft tarafında GPO’larda scriptlerin çalışmasıyla ilgili bir dizi makale yayınlanmış. Bunları okumak da çok yardımcı olacaktır.
The two sides of group policy script extension processing
http://www.microsoft.com/technet/scriptcenter/topics/gp/extension1.mspx
http://www.microsoft.com/technet/scriptcenter/topics/gp/extension2.mspx
İşiniz bittiğinde loglama seviyesini eski haline getirmeyi unutmayın lütfen. Kolay gelsin.
Tercih tabi ki kullanacak kişiye kalmış.
