DFS ad alanına erişirken uzun duraklama

Kısa süre önce, paylaşılan dosyalar için DFS kullanmak üzere Windows ağımızı taşıdık. DFS can sıkıcı bir sorun dışında iyi çalışıyor: kullanıcılar bir süredir erişemedikleri bir DFS ad alanına erişmeye çalışırken önemli bir gecikme yaşarlar. Bu sorunu gidermeye çalıştım ancak şu ana kadar bir başarı elde etmedim ve burada birisinin sorunun çözülmesine yardımcı olacak bazı göstergeleri olabileceğini umuyordum.

Öncelikle, ağımızdaki bazı bilgiler:

Ağ, iki Windows 2008 DC'si ve iki DNS sunucusu olan (her bir DC'de bir tane) bir Windows 2008 işlev düzeyinde Active Directory etki alanı kullanır. Ağ yalnızca DNS'dir - WINS yok. Tüm bilgisayarlar aynı sitede bulunur ve Gigabit Ethernet ile bağlanır. Windows 2008 modunda yaklaşık 20 Etki Alanı tabanlı DFS ad alanımız var ve her DFS ad alanında iki Windows 2008 DFS ad alanı sunucusu (tüm ad alanları için aynı iki sunucu) bulunuyor. Tüm ad alanı sunucuları FQDN modundadır ve tüm klasör hedefleri FQDN'si kullanılarak belirtilir. Tüm bilgisayarlar Servis Paketleri ve yamalar ile günceldir.

Asıl klasör hedefleri (yani SMB, DFS klasörlerimizi işaret eder) birkaç dosya ve uygulama sunucusuna dağılmıştır, Windows 2008 çalıştıran tüm Windows 2003 R2 çalıştıran iki uygulama sunucusu, çoğaltma ayarları yoktur (örneğin şu anda tüm DFS klasörleri) yalnızca bir klasör hedefi var).

Sorun hakkında biraz daha detay:

Ad alanı erişim gecikmesi genellikle 1 - 10 saniye uzunluğundadır ve belirli bir bilgisayar istenen ad alanına yaklaşık beş dakika veya daha uzun bir süre boyunca erişmediğinde ortaya çıkar.

Örneğin, kullanıcı beş dakikadan fazla bir süredir \\ domain.name \ namespace1 \ 'e erişmediyse ve Windows Gezgini üzerinden \\ domain.name \ namespace1 \' e erişmeye çalışırsa, Explorer penceresi nihayet önce 1 - 10 saniye donacak \\ domain.name \ namespace1 içindeki klasörleri devam ettirmek ve görüntülemek. Daha sonra Explorer penceresini kapatırlar ve \\ domain.name \ namespace1 \ 'e beş dakika içinde tekrar erişmeye çalışırlarsa içerikler neredeyse anında görüntülenir - beş dakikadan uzun süre beklerlerse tekrar 1 - 10 saniye duraklar.

Bir kez ad alanının "içinde" her şey güzel ve çabuk, bir yavaş sadece ad alanına ilk bağlantı.

Gezinme gecikmeleri, kullandığımız Windows'un tüm çeşitlerini etkiliyor gibi görünüyor (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - muhtemelen Windows XP / 2003'te Windows 2008'den biraz daha kötü farkın sadece psikolojik olup olmadığından emin değilim.

Temeldeki klasör hedeflerine doğrudan erişmek hiçbir gecikme göstermez - yani, DFS'nin işaret ettiği SMB hisselerine doğrudan erişilirse (DFS'yi atlayarak) duraklama olmaz.

Sorun giderme sırasında, tüm DFS köklerimiz için "Önbellek süresi" nin 300 saniye - 5 dakika olarak ayarlandığını fark ettim. Bu duraklamayı tetiklemek için gereken zamanın aynı olduğu göz önüne alındığında, bu önbelleğe alma işleminin bir şekilde ilişkili olduğunu varsayalım, ancak tam olarak müşteride önbelleğe alınanın tam olarak ne olduğundan emin değilim ve bu nedenle 5 dakika geçtikten sonra tekrar aranması gerekiyor.

Sorunu çözmeye çalışırken aşağıdakileri zaten denedim / kontrol ettim (başarı olmadan):

• Her iki Etki Alanı Denetleyicisinde de dcdiag çalıştırın - sorun bulunamadı
• Bazı temel DNS sunucusu kontrolleri sorun olmadan tamamlandı - DNS sunucularını ayrıntılı olarak nasıl kontrol edeceğimi bilmiyorum, ama ağın bir DNS sorununa işaret edebilecek başka garip davranışlar göstermediğini de ekleyeceğim.
• İstemcilerde ve sunucularda Engelli Anti-virüs
• Ad alanı sunucularından birini birkaç ad alanından kaldırma - fark yok

Demek istediğim yer burası - ve fikirlerim dışında. Herhangi biri gecikmelere neyin neden olabileceğini ve / veya daha sonra ne denemem gerektiğini önerebilir mi?

Sonunda , bu sorunu çevremizdeki çözüme kavuştuk. Başkalarının yararları için, işte keşfettiklerimiz ve sorunu nasıl çözdüklerimiz:

Gecikmelerin öncesinde / sırasında / sonrasında neler olduğuna dair daha fazla bilgi edinmek ve denemek için, Wireshark'ı bir istemci makinede ağ trafiğini yakalamak / analiz etmek için kullandık.

Bu yakalamalar garip bir şey gösterdi: Gecikme gerçekleştiğinde, istemciden bir DC'ye gönderilen DFS isteği ile DC'den istemciye geri gelen bir DFS kök sunucusuna yapılan başvuru arasında, DC birkaç yayın adı gönderiyordu. ağa bakar.

İlk olarak, DC DOMAIN için bir NetBIOS araması yayınlardı (burada DOMAIN, Windows 2000 öncesi Active Directory alan adımızdır). Birkaç saniye sonra DOMAIN için bir LLMNR araması yayınlayacaktı . Bunu DOMAIN için başka bir yayın NetBios araması izleyecek. Bu üç arama yayınlandıktan sonra (ve zaman aşımına uğradığımı varsaydım) DC müşteriye nihayet bir DFS kök sunucusuna (doğru) bir yönlendirme ile cevap verecekti.

DOMAIN için bu yayın adı aramaları yalnızca bir DFS paylaşımını açmanın uzun gecikmesi gerçekleştiğinde gönderiliyordu ve Wireshark yakalamasından DC'nin DFS kök sunucusuna bir başvuru döndürmediğini açıkça görebiliyorduk. ve ~ 7 saniye geçti). Bu nedenle, bu yayın adı aramaları açık bir şekilde gecikmelerimizin nedeni idi.

Şimdi sorunun ne olduğunu öğrendiğimize göre, bu yayın adı aramalarının neden gerçekleştiğini anlamaya çalıştık. Biraz daha Googling ve bazı deneme-yanılma hatalarından sonra cevabımızı bulduk: DFSDnsConfig kayıt defteri anahtarını etki alanı denetleyicilerimizdeki DFS'yi yalnızca DNS ortamında kullanmak için gereken şekilde 1 olarak ayarlamamıştık.

İlk olarak DFS'yi ortamımıza kurduğumuzda , DFS'yi yalnızca DNS ortamı için (örn. Microsoft KB244380 ve diğerleri) nasıl yapılandıracağımızla ilgili çeşitli makaleler okuduk ve bu kayıt defteri anahtarının farkında olduklarını ancak ne zaman / nasıl yapılacağına ilişkin talimatları yanlış yorumladık kullan.

KB244380 diyor ki:

DFSDnsConfig kayıt defteri anahtarı, tüm bilgisayarların tam olarak nitelenmiş adları anlayabilmesi için DFS ad alanına katılacak olan her sunucuya eklenmelidir.

Bunun, kayıt defteri anahtarının yalnızca DFS ad alanı sunucularında ayarlanması gerektiğini, etki alanı denetleyicilerinde de gerekli olduğunun farkında olmadığını düşündük . Etki alanı denetleyicilerimizde DfsDnsConfig öğesini 1 olarak ayarladıktan sonra (ve "DFS Ad Alanı" hizmetini yeniden başlattıktan sonra) sorun ortadan kalktı.

Açıkçası bu sonuçtan memnunuz, ancak hala% 100 olmadığımı, bunun tek sorunumuz olduğuna ikna olmadığımı ekleyeceğim - acaba DC'lere DfsDnsConfig = 1 ekleyerek sorunu çözmek yerine sadece sorun çözüldüğünü merak ediyorum . DC'lerin neden DAN başvuru işlemi sırasında, yalnızca DNS dışı bir ortamda bile DOMAIN (etki alanındaki bir sunucu yerine etki alanı adı) aramaya çalıştığını anlayamıyorum ve ben de biliyorum. etki alanı denetleyicilerinde DfsDnsConfig = 1 değerini yalnızca diğer DNS ortamlarında (kuşkusuz daha küçük / basit) ayarlamadım ve aynı sorunu yaşamadım. Yine de sorunumuzu çözdük, böylece mutluyuz.

Umarım bu, benzer bir sorunu yaşayan diğerlerine de yardımcı olur - ve yol boyunca öneride bulunanlara tekrar teşekkürler.

Bunun nedeni DNS sunucusu ağ maskesi siparişi olabilir. Bu yakın zamanda Server 2003'te karşılaştık. Bu, mevcut alt ağınıza bağlıdır.

Örnek.

Site 1: IP alt ağı 10.0.0.0/24 Site 2: IP alt ağı 10.0.1.0/24

Site 2'deki istemci, etki alanı tabanlı ad alanınız için bir DNS sorgusu yapar ve DNS sunucusu, site IP sınırlarının farkında olmadığından, varsayılan olarak site 1'deki DFS sunucusuna verilir. Hangi IP adreslerinin cevap vereceğini belirlemek için DNS sunucularınıza hangi alt ağ maskesini kullanmanız gerektiğini söylemeniz gerekir.

Bkz http://support.microsoft.com/kb/842197

Active Directory Ekibi Blogu, DFS Gecikmeleri ile ilgili TÜMÜ bir makale makalesine sahiptir.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

Yönlendirme Sürecindeki temel bilgileri kapsar ve daha sonra gecikmelerin asıl nedenini bulmak için dfsUtil ve dfsDiag gibi çeşitli araçların nasıl kullanılacağını gösterir.

Sorunumu bulmama yardım etti. Etki Alanı Kullanıcıları için paylaşım dizininde Okuma izni olmadığı ortaya çıktı.

HTH, Daniel

DNS sorunu gibi kokuyor ama bir şey yok. Eski FRS'yi çok tercih ettim çünkü Ultrasound gibi teşhis araçları çok faydalıydı: 7

DFS Çoğaltma Olay Günlüğü'nde hedeflerde bir şey var mı? (DFS Sağlık raporu, uyarıları olay günlüğünden alır)

WINS olmadan çalışmak güzel bir amaç ve takdire şayan, ancak Vista / 2008 öncesi Windows sistemleri varsa, işlerim her zaman beklendiği gibi çalışmadığı ya da WINS olmadan hızlı bir şekilde çalıştığım sürece - buna rağmen önemli olmamalı.

İstemci bir DFS yönlendirmesini önbelleğe alır; yani, \ domain.name \ namespace girdiğinizde, hangi asıl sunucu domain.name'nin başvurduğu önbelleklenir. Yönlendirme önbellekten sona erdiğinde, müşteri temel olarak DFS topolojinizi yeniden "keşfetmesi" gerekir; bu nedenle gecikme olur.

Burada bir göz atın: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx ve burada http://blogs.technet.com/filecab/archive/2006/01/20 Bunun nasıl çalıştığı hakkında daha fazla bilgi için /417832.aspx .

Olası çözümler? Bu konuda hack bir yol her birkaç dakikada bir "hayatta tutmak" yapan küçük bir program yazmak olabilir; örneğin, bulduğu ilk dosyayı fopen yapan ve derhal o dosyayı açan bir C programı. Bunu denemedim ya da test etmedim ve kesinlikle yapacak olursanız kesinlikle dikkatli olmanız gerekir.

Kullanıcıların, bir DFS paylaşımına eşlenmiş bir sürücüyü tıklatma ve paylaşım içindeki klasörleri görebilme ve bunlara göz atma arasında gecikmelerle (bir dakikaya kadar) yaşayacağı benzer bir sorun yaşadık.

Kullanıcılar aynı sürücüdeki farklı bir DFS paylaşımına eşlenmiş ev sürücülerine de sahipti ve oradaki klasörlere erişirken gecikme olmadı.

İkisi arasındaki fark Erişim Tabanlı Numaralandırma'dır (ABE) - sorun payı bunu etkinleştirmiştir (binlerce klasöre sahip kullanıcılar için ortak bir sürücüdür - ABE, kullanıcıların yalnızca izinleri olduğu klasörleri görmesi anlamına gelir).

ABE'yi devre dışı bırakmak sorunu tamamen ortadan kaldırdı. Açıkçası bu, kullanıcıların tüm klasörleri görerek, kafalarını karıştıran bir çözüm değil. DFS paylaşımını geçici bir önlem olarak bazı yedek diskleri olan bir sunucuya kopyaladım ve bu yeni hedefe yönelik ABE etkin olsa bile gecikme geçti.

Sorunlu sunucu 2k3R2'dir ve 150 günden fazla (!) Çalışma süresi vardır, bu nedenle yeniden başlatılacak ve rahatsız edici birim üzerinde CHKDSK uygulanacaktır. Bu sorun için herhangi bir fark yaratırsa buraya geri göndereceğim. Yeni hedef 2k8 sunucusunda.

dfsutil / spcflush ve dfsutil / pktflush, çok siteli bir ağda da bir çözüm olabilir, ana sitenin DFS bağlantısının önbellekten değil yerel sunucudan geldiğinden emin olun.

Orijinal posterin WINS kullanmadığını biliyorum ama bu yazıyı çok benzer bir sorunu çözmek için en çok kullandığımız gibi başkalarının yararına gönderiyorum. Bizim için, birisinin iş istasyonunu etki alanıyla aynı adla adlandırmaya karar vermesi sona erdi. Bu nedenle, DC, DFS başvurusu için alan adında her arama yaptığında, bu iş istasyonunu çözmek istiyordu ve hatırı sayılır bir çok 10 saniyelik gecikmeye neden olacaktı. WINS'ye bir DC'yi işaret eden statik bir 20 giriş yerleştirildi ve bu problemi çözdü. WINS'iniz yoksa, etki alanı adını LMHOSTS dosyasına bir makine adı olarak bir makine adı olarak yerleştirmeyi deneyerek 20 aramasını elde etmek için bir DC'ye işaret edebilir ve LMHOSTS'un netbios adlarını çözümlemek için ilk bakılan yer olmasını sağlama önceliği belirleyebilirsiniz.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Bu sayfa aslında yardımcı olursa, hem Etki Alanı Denetleyicilerini hem de DFSN'den bahseder.

DFS Etki Alanı Denetleyicisi ve Kök Sunucu Kayıt Defteri Girdileri

Aşağıdaki kayıt defteri girdileri altında bulunur.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

kök sunucularda ve etki alanı denetleyicilerinde. Tüm girişler REG_DWORD.

Bu yüzden araştırmamda bu makaleyi kullandım. Her şeyi ayarladım ve hala sorun yaşıyorum. Sorunu incelemek ve her şeyi 'Microsoft' dışında bırakmak birkaç gün geçirdikten sonra bunun Ağ ile ilgili olduğunu tahmin ettim. Bizim WAN Accelerator'ımızın sorun olduğu ortaya çıktı. Ağ Bağdaştırıcılarımız Etki Alanı Denetleyicilerimiz için ivmeyi kapattılar ve her şey daha iyi oldu.

Bir sürü kontrolcümüz vardı, bir script ( dnsdfs.cmd servername) kullandı:

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

20 DFS sunucunuz olduğunu ancak tüm sunucuların aynı tesiste olup olmadıklarını söyleyemediğinizi belirtiyorsunuz.

Bu sunucular aynı tesiste değilse ve her bir sitenin kendi etki alanı varsa, istemcinin geri dönmesinin etkin olduğundan emin olmak isteyebilirsiniz.

Google arama ile buraya gelenler ve aynı sorunu yaşayanlar için ...

Öncelikle, Ad Alanınızdaki tüm bağlantıların uygun ve iyi olduğunu kontrol edin. Benim durumumda olan da buydu, ad alanında hala kapalı olan bir sunucuya bir bağlantı vardı, bu yüzden DNS'yi açarken geçen duraklama, o sunucuyu aradığı ve başarısız olduğu içindi. DFS'deki bu bağlantıyı devre dışı bıraktıktan sonra uzun duraklama sona erdi.

Kimliği doğrulanmış kullanıcılar grubunun eşlendiğiniz kök dizinin içeriğini listeleme erişimine sahip olduğunu doğrulayın. Örneğin, x: sürücüsü \ domain.local \ departents \ Marketing ile eşlenmişse, kullanıcının \ domain.local \ departments için liste iznine ihtiyacı olacaktır. 2008/2012'de, gelişmiş izinler altında, "Yalnızca bu klasör" için geçerli olacağını, izinleri devralabilecek alt klasörlerin içeriğini listelemelerine izin vermeyeceklerini belirleyebilirsiniz.