Yavaş aktif dizin girişlerini tanılama

Etki alanı bilgisayarlarında aralıklı yavaş girişleri tanılamakta zorlanıyorum.

Bu sorunu yaşayan ağ hakkında biraz bilgi:

• Alan adım, hepsi VPN bağlantılarına sahip 5 siteye yayılıyor.
• DC'ler 2003, 2008 ve 2012'nin bir karışımıdır. Etki alanı işlev düzeyi 2003'tür.
• İstemciler çoğunlukla Windows 7 x64'tür.
• WMI kullanan gruplar, grup tercihi öğe düzeyinde hedefleme ve GPP yazıcı dağıtımı dahil olmak üzere grup politikaları kullanıyoruz.
• Dolaşım profilleri kullanmıyoruz.

Çoğunlukla, girişler makineyi daha önce kullanan kişiler için iyi ve hızlı bir şekilde çalışır. Yeni bir bilgisayara ilk kez giriş yapmak her zaman yavaştır, ancak bu beklenen bir durumdur.

Sorun çoğunlukla dizüstü bilgisayarlarda görülüyor. Etki alanı olmayan bir ağ bağlantısıyla evde kullanılıyorsa veya farklı bir konuma taşındıysa (yine de bir etki alanı ağında, ancak farklı bir AD sitesinde ve kablolu veya kablosuz olarak önemli görünmüyorsa) girişler 3 sürece kadar sürebilir kullanıcının şifresini girdiği andan masaüstünü göstermeye başladığı dakikaya kadar. Terminal sunucumuz da yavaş yavaş yavaş oturum açma deneyimi yaşar.

Ne yazık ki, bu kesintili bir konudur ve onu yeniden üretmek için güvenilir bir yol bulamadım. Şüphem, bunun grup politikası tercihleriyle ilgili olması gerektiğidir, ancak bunun gerçekten bir kanıtı yok. Yavaş oturumlar için belirli bir öğe düzeyi hedeflemesini suçlayan bir microsoft KB makalesi gördüm, ancak bunun aslında neden olup olmadığını belirlemek için herhangi bir rehberlik vermiyor.

Yavaş girişlere neyin sebep olduğunu bulmak için hangi günlükleri ve araçları kullanabilirim?

Girişleri hızlandırmak için mümkünse hangi grup ilkesi ayarlarını kullanmam veya bunlardan kaçınmam gerekir?

Temel olarak, joeqwerty ile aynı yöne gidiyorum

Birkaç şirkette tanımladığınız belirtileri yaşadım. Deneyimlerime göre, genellikle birden fazla site olduğunda olur. Siteler ve hizmetlerle ilgili olası bir sorunu gidermenin bir yolu şudur. Yavaş oturum açmış bir bilgisayarda, komut istemine gidin, echo% logonserver% yazın. Yanıt, dizüstü bilgisayar veya iş istasyonuyla aynı sitede bir sunucu değilse, deneyimim, alt ağların ayarlanmadığı ve atanmadığıdır. etkin dizin sitelerinde ve hizmetlerinde doğru siteyi seçin.

Sorun gidermenin başka bir yolu da etki alanı denetleyicilerinizdeki bu günlük dosyasına bakmaktır% SystemRoot% \ debug \ netlogon.log

Bunun gibi girişler görürseniz, söz konusu alt ağın sitelere ve hizmetlere girilmesi ve bir site atanması gerekir.
05/16 22:57:31 [4068] AD: NO_CLIENT_SITE: özel sunucuadı 172.16.10.104

Microsoft iş istasyonları ve etki alanı denetleyicileri, siteler ve hizmetler nedeniyle kimlik doğrulama ve ilkeler için doğru etki alanı denetleyicilerine gittiklerinden emin olma yeteneğine sahiptir.

Bu durumda ve sitelerin ve hizmetlerin ayarlanmasına neden oluyorsa, lütfen etki alanı denetleyicilerindeki / etki alanlarındaki değişikliklerin çoğaltılmasının biraz zaman alabileceğini unutmayın. Ayrıca, uç nokta iş istasyonlarının yeni değişiklikleri görmesi daha da zaman alacaktır. Varsayılan çoğaltma süresi, etki alanı denetleyicileri arasında siteler ve hizmetlerde 1 saat olarak ayarlanır. Coğrafyadaki mesafeye ve AD ormanınızın boyutuna bağlı olarak, genellikle 15 dakikaya ayarlıyorum.

Soruya uyan bir cevap veya daha sonra kendim için bir not:

Birkaç alt ağımız için girişlerde aşırı gecikmeler yaşadık. Bu alt ağların AD sunucusunda ters DNS bölgeleri eksik olduğu ortaya çıktı. Ters bölgeleri ekledik, AD PTR girişlerini otomatik olarak ekledi ve o zamandan beri gecikme yaşamadı. Tesadüf de olabilir.