Group Policy loglarının incelenmesi

İ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.

Logparser ve faydalari

Uzun zamandır LogParser’ı kullanmayı ihmal etmişim. 2.2 yeni sürümde (en azından benim için yeni) oldukça güzel özellikler katmışlar. Bunları burada saymakla zaman kaybetmeyeceğim. Basit ama etkili bir uygulamamızdan örnek vermek istiyorum.

AD ortamımızda bazı PC’lerin (özellikle uzak noktalardaki PC’ler) Active Directory ile sorunları olduğunu ve Group policy güncellemelerini sağlıklı yapamadıklarını farkettik. Ancak bu makinelerin listesini toplamak zahmetli bir iş olduğundan tüm PC’lerden event log dosyasını belirlediğimiz olay tiplerine göre filtreleyerek araştıracak bir araç aramaya başladık.

Bu noktada tekrar LogParser aklıma geldi

Aşağıda kullandığım komutu bulabilirsiniz.

“c:\program files\Log Parser 2.2\LogParser” -o:CSV “SELECT EventLog, TimeGenerated, EventID, EventType, ComputerName, SID, Message INTO \\XXserver\Pcloglari\%COMPUTERNAME%-%date%.csv FROM Application WHERE TimeGenerated >= TO_LOCALTIME ( SUB ( SYSTEM_TIMESTAMP(), TIMESTAMP( ’01-02′, ‘MM-dd’) ) ) AND (  EventID = 1058 OR EventID = 1059 OR EventID = 1054)”

Bu komutla Application Event Log içinden “dün” oluşan tüm 1058,1059 ve 1054 nolu olayların çıktısını uzaktaki bir sunucuya CSV olarak alabiliyoruz.

Eğer PC adıyla bir log varsa bu GPO sorununa delil olabilir. Log yoksa o gün o PC’de bir sorun olmamıştır. Çok sayıda çıktının hızlıca değerlendirilmesinde bu mantık da kullanılabilir.

Elbette EventComb gibi araçları da kullanmak mümkün ancak, bu şekilde log toplamak ; eş zamanlı olarak uzaktaki bilgisayarlara bağlanıp kısıtlı data hatları üzerinden senkron olarak bilgi çekmeye çalışmaktan daha makul ve maliyeti düşük bir yöntem.

Group Policy / Account Lockout Problemlerini Çözmek

Group Policy ile Account Lockout problemlerini çözmek üzerine çok faydalı bir makale. Ekinde bulunan araçlar da işleri kolaylaştırıyor.