Lunga pausa durante l'accesso allo spazio dei nomi DFS

Di recente abbiamo migrato la nostra rete Windows per utilizzare DFS per i file condivisi. DFS funziona bene, tranne per un fastidioso problema: gli utenti riscontrano un ritardo significativo quando provano ad accedere a uno spazio dei nomi DFS a cui non hanno avuto accesso per un po 'di tempo. Ho provato a risolvere il problema, ma finora non ho avuto successo, e speravo che qualcuno qui potesse avere alcuni suggerimenti per aiutare a risolvere il problema.

Innanzitutto, alcuni retroscena sulla nostra rete:

La rete utilizza un dominio Active Directory a livello funzionale di Windows 2008 con due controller di dominio di Windows 2008 e due server DNS (uno su ciascuno dei controller di dominio). La rete è solo DNS - nessun WINS. Tutti i computer si trovano nello stesso sito e collegati tramite Gigabit Ethernet. Abbiamo circa 20 spazi dei nomi DFS basati su dominio in modalità Windows 2008 e ogni spazio dei nomi DFS ha due server dello spazio dei nomi DFS di Windows 2008 (gli stessi due server per tutti gli spazi dei nomi). Tutti i server dello spazio dei nomi sono in modalità FQDN e tutte le destinazioni delle cartelle sono specificate usando il loro FQDN. Tutti i computer sono aggiornati con Service Pack e patch.

Le destinazioni delle cartelle effettive (ovvero le condivisioni SMB alle quali puntano le nostre cartelle DFS) sono distribuite su più file e server applicazioni, tutti con Windows 2008 a barre su due server applicazioni che eseguono Windows 2003 R2, senza alcuna configurazione di replica (ad esempio tutte le cartelle DFS attualmente ha solo una destinazione cartella).

Qualche dettaglio in più sul problema:

Il ritardo di accesso allo spazio dei nomi è generalmente compreso tra 1 e 10 secondi e sembra verificarsi quando un determinato computer non ha avuto accesso allo spazio dei nomi richiesto per circa cinque minuti o più.

Ad esempio, se l'utente non ha avuto accesso a \\ domain.name \ namespace1 \ per più di cinque minuti e ha tentato di accedere a \\ domain.name \ namespace1 \ tramite Esplora risorse, la finestra di Explorer si bloccherà per 1 - 10 secondi prima che finalmente riprendere e visualizzare le cartelle esistenti in \\ domain.name \ namespace1. Se poi chiudono la finestra di Explorer e tentano di accedere nuovamente a \\ domain.name \ namespace1 \ entro cinque minuti, i contenuti verranno visualizzati quasi istantaneamente - se aspettano più di cinque minuti, passeranno di nuovo la pausa di 1 - 10 secondi.

Una volta "dentro" lo spazio dei nomi tutto è bello e scattante, è solo la connessione iniziale allo spazio dei nomi che è lenta.

I ritardi di navigazione sembrano influenzare tutte le varianti di Windows che utilizziamo (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - è probabilmente un po 'peggio in Windows XP / 2003 rispetto a Windows 2008, ma io non sono sicuro che la differenza non sia solo psicologica.

L'accesso ai target delle cartelle sottostanti non mostra direttamente alcun ritardo, ovvero se si accede direttamente alle condivisioni SMB indicate da DFS (ignorando DFS), non vi è alcuna pausa.

Durante la risoluzione dei problemi ho notato che la "Durata della cache" per tutte le nostre radici DFS è impostata su 300 secondi - 5 minuti. Dato che questo è lo stesso tempo necessario per innescare la pausa, presumo che questa memorizzazione nella cache sia in qualche modo correlata, anche se non sono sicuro di cosa sia memorizzato nella cache sul client e quindi di cosa debba essere cercato nuovamente dopo che sono trascorsi 5 minuti.

Nel tentativo di risolvere il problema ho già provato / verificato quanto segue (senza successo):

• Esegui dcdiag su entrambi i controller di dominio - non sono stati rilevati problemi
• Eseguito alcuni controlli di base del server DNS senza trovare alcun problema: non so come controllare in dettaglio i server DNS, ma aggiungerei che la rete non presenta altri comportamenti strani che potrebbero indicare un problema DNS
• Anti-virus disabilitato su client e server
• Rimozione di uno dei server dello spazio dei nomi da un paio di spazi dei nomi - nessuna differenza

Ecco dove sto andando - e sono senza idee. Qualcuno può suggerire cosa potrebbe causare i ritardi e / o cosa dovrei provare dopo?

Bene, finalmente sembriamo aver risolto questo problema nel nostro ambiente. Per i vantaggi degli altri, ecco cosa abbiamo scoperto e come abbiamo risolto il problema:

Per cercare di ottenere ulteriori informazioni su ciò che stava accadendo prima / durante / dopo i ritardi, abbiamo utilizzato Wireshark su un computer client per acquisire / analizzare il traffico di rete mentre quel client ha tentato di accedere a una condivisione DFS.

Queste acquisizioni hanno mostrato qualcosa di strano: ogni volta che si verificava il ritardo, tra la richiesta DFS inviata dal client a un controller di dominio e il riferimento a un server root DFS che tornava dal controller di dominio al client, il controller di dominio inviava diversi nomi di trasmissione ricerche nella rete.

In primo luogo, il controller di dominio trasmetterà una ricerca NetBIOS per DOMAIN (dove DOMAIN è il nostro nome di dominio Active Directory pre-Windows 2000). Pochi secondi dopo, trasmetterà una ricerca LLMNR per DOMAIN. Questo sarebbe seguito da un'altra ricerca NetBios broadcast per DOMAIN. Dopo che queste tre ricerche erano state trasmesse (e presumo scaduto) il controller di dominio avrebbe finalmente risposto al client con un riferimento (corretto) a un server root DFS.

Queste ricerche di nomi di trasmissione per DOMAIN venivano inviate solo quando si verificava il lungo ritardo nell'apertura di una condivisione DFS e dalla cattura di Wireshark si vedeva chiaramente che il controller di dominio non restituiva un riferimento a un server radice DFS fino a quando non venivano inviate tutte e tre le ricerche ( e sono trascorsi ~ 7 secondi). Quindi, queste ricerche sui nomi delle trasmissioni sono state ovviamente la causa dei nostri ritardi.

Ora che sapevamo quale fosse il problema, abbiamo iniziato a cercare di capire perché si stavano verificando queste ricerche dei nomi delle trasmissioni. Dopo un po 'più di Google e alcuni tentativi, abbiamo trovato la nostra risposta: non avevamo impostato la chiave di registro DfsDnsConfig sui nostri controller di dominio su 1, come è necessario quando si utilizza DFS in un ambiente solo DNS.

Quando abbiamo originariamente DFS di impostazione nel nostro ambiente abbiamo fatto leggere i vari articoli su come configurare DFS per un ambiente solo DNS (ad esempio Microsoft KB244380 ed altri) ed erano a conoscenza di questa chiave di registro, ma aveva misintepreted le istruzioni su quando / come usalo.

KB244380 dice:

La chiave del Registro di sistema DFSDnsConfig deve essere aggiunta a ciascun server che parteciperà allo spazio dei nomi DFS affinché tutti i computer possano comprendere nomi completi.

Pensavamo che ciò significasse che la chiave di registro doveva essere impostata solo sui server dello spazio dei nomi DFS , senza renderci conto che era richiesta anche sui controller di dominio. Dopo aver impostato DfsDnsConfig su 1 sui nostri controller di dominio (e riavviato il servizio "Spazio dei nomi DFS"), il problema è svanito.

Ovviamente siamo contenti di questo risultato, ma aggiungerei che non sono ancora convinto al 100% che questo è il nostro unico problema - mi chiedo se l'aggiunta di DfsDnsConfig = 1 ai nostri controller di dominio abbia solo aggirato il problema, piuttosto che risolverlo . Non riesco a capire perché i controller di dominio tenterebbero di cercare DOMAIN (il nome di dominio stesso, anziché un server nel dominio) durante il processo di riferimento DFS, anche in un ambiente non solo DNS, e so anche che non ha impostato DfsDnsConfig = 1 sui controller di dominio in altri ambienti (solo molto più piccoli / semplici) DNS e non ha avuto lo stesso problema. Tuttavia, abbiamo risolto il nostro problema, quindi siamo felici.

Spero che ciò sia utile per gli altri che stanno riscontrando un problema simile - e grazie ancora a quelli che hanno offerto suggerimenti lungo la strada.

Ciò potrebbe essere causato dall'ordinamento della maschera di rete del server DNS. Ci siamo imbattuti di recente in Server 2003. Questo dipende dalla sottorete corrente.

Esempio.

Sito 1: sottorete IP 10.0.0.0/24 Sito 2: sottorete IP 10.0.1.0/24

Il client nel sito 2 esegue una query DNS per lo spazio dei nomi basato sul dominio e verrà assegnato il server DFS nel sito 1 per impostazione predefinita poiché il server DNS non è a conoscenza dei confini IP del sito. È necessario indicare ai server DNS quale subnet mask utilizzare per identificare gli indirizzi IP con cui rispondere.

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

Il blog del team di Active Directory contiene un articolo in tre parti TUTTO sui ritardi DFS.

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

Descrive le basi del processo di riferimento e quindi mostra come utilizzare vari strumenti tra cui dfsUtil e dfsDiag per scoprire la causa effettiva dei ritardi.

Mi ha aiutato a trovare il mio problema. Che si è rivelato essere senza autorizzazioni di lettura sulla directory di condivisione per gli utenti del dominio.

HTH, Daniel

Odora di un problema DNS ma va bene qualsiasi cosa. Preferivo di gran lunga il vecchio FRS perché gli strumenti diagnostici come Ultrasound erano così utili: 7

Ricevi qualcosa nel registro eventi replica DFS sulle destinazioni? (il rapporto DFS Health trarrà i suoi avvisi dal registro eventi)

Correre senza WINS è un obiettivo piacevole e ammirevole, anche se sono praticamente contrario a questo se ci sono sistemi Windows pre-Vista / 2008 in giro perché le cose non funzionano sempre come previsto o velocemente senza WINS nella mia esperienza, anche se in realtà non dovrebbe importare.

Il client memorizza nella cache un riferimento DFS, ovvero quando si immette \ domain.name \ namespace, memorizzerà nella cache il nome dominio.name del server effettivo. Una volta scaduto il riferimento dalla cache, il client deve sostanzialmente "scoprire" di nuovo la topologia DFS, quindi il ritardo.

Dai un'occhiata qui: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx e qui http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx per ulteriori informazioni su come funziona.

Possibili soluzioni? Un modo bizzarro di fare ciò potrebbe essere quello di scrivere un piccolo programma che fa "rimanere in vita" ogni pochi minuti; ad es. un programma C che apre il primo file che trova e lo chiude immediatamente. Non ho provato o testato questo, e avresti sicuramente bisogno di prendere attentamente in considerazione se lo avessi fatto.

Si è verificato un problema simile, in cui gli utenti potrebbero riscontrare ritardi (fino a un minuto) tra il clic su un'unità mappata su una condivisione DFS e la possibilità di visualizzare e sfogliare le cartelle all'interno della condivisione.

Gli utenti avevano anche le unità home mappate su una diversa condivisione DFS sullo stesso volume e non avevano alcun ritardo nell'accedere alle cartelle lì.

La differenza tra i due è Enumerazione basata sull'accesso (ABE) - la condivisione del problema ha abilitato questa opzione (è un'unità comune per gli utenti, con migliaia di cartelle - ABE significa che gli utenti vedono solo quelle cartelle per le quali dispongono delle autorizzazioni).

La disabilitazione di ABE ha rimosso completamente il problema. Ovviamente questa non è una soluzione poiché gli utenti vedono tutte le cartelle, confondendole. Ho replicato la condivisione DFS su un server con alcuni dischi di riserva come misura temporanea e anche con ABE abilitato su questo nuovo target, il ritardo è andato.

Il server problematico è 2k3R2 e ha un tempo di attività di oltre 150 giorni (!), Quindi verrà riavviato e far funzionare CHKDSK sul volume offensivo. Riporterò qui se questo fa la differenza per il problema. Il nuovo target si trova su un server 2k8.

dfsutil / spcflush e dfsutil / pktflush possono essere una soluzione anche in una rete multi-sito, assicurarsi che il collegamento DFS del sito principale provenga dal server locale e non dalla cache.

So che il poster originale non utilizzava WINS, ma sto pubblicando a beneficio di altri, poiché abbiamo utilizzato maggiormente questo post per aiutare a risolvere un problema molto simile. Per noi è finito per essere qualcuno che ha deciso di nominare la propria workstation con lo stesso nome del dominio. Quindi, ogni volta che il controller di dominio eseguiva una ricerca sul nome di dominio per il riferimento DFS, desiderava risolversi su quella workstation e causava un notevole ritardo di più di 10 secondi. Una voce statica 20 è stata inserita nel WINS che punta a un controller di dominio e questo ha risolto il problema. Se non avessi WINS, potresti provare a posizionare il nome di dominio come nome di macchina nel file LMHOSTS puntato a un controller di dominio per ottenere la ricerca 20 e impostare la priorità affinché LMHOSTS sia il primo posto in cui cercare la risoluzione dei nomi netbios.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Questa pagina menziona effettivamente sia i controller di dominio che DFSN, se ciò aiuta.

Voci di registro DFS Domain Controller e Root Server

Le seguenti voci di registro si trovano in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

su server root e controller di dominio. Tutte le voci sono REG_DWORD.

Quindi ho usato questo articolo nella mia ricerca. Ho impostato tutto e ho ancora problemi. Dopo aver trascorso diversi giorni a esaminare il problema ed escludere tutto ciò che "Microsoft", immaginavo fosse legato alla rete. Risulta che il nostro problema sia stato il nostro acceleratore WAN . Ho chiesto ai nostri ragazzi di Networking di disattivare l'accelerazione per i nostri controller di dominio e tutto è migliorato.

Aveva molti controller, così come uno script ( dnsdfs.cmd servername):

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

Dici che hai 20 server DFS ma non riesci a menzionare se tutti i server sono nella stessa struttura.

Se questi server non si trovano nella stessa struttura e ogni altro sito ha il proprio dominio, è possibile assicurarsi che il failback del client sia abilitato.

Per quelli che finiscono qui attraverso una ricerca su Google e che hanno lo stesso problema ...

Per prima cosa controlla che tutti i collegamenti nel tuo spazio dei nomi siano disponibili e validi. Questo è quello che è successo nel mio caso, c'era ancora un collegamento nello spazio dei nomi a un server che era inattivo, quindi la lunga pausa all'apertura di DNS era perché stava cercando quel server e non funzionava. Una volta disabilitato quel collegamento in DFS, la lunga pausa è andata via.

Verificare che il gruppo Utenti autenticati abbia accesso per elencare i contenuti della directory principale su cui si è mappati. Ad esempio, se l'unità x: è mappata su \ domain.local \ departents \ Marketing, l'utente dovrà disporre dell'autorizzazione dell'elenco per \ domain.local \ departments. Nel 2008/2012 è possibile specificare sotto le autorizzazioni avanzate che si applica a "Solo questa cartella" in modo che non sia loro consentito elencare il contenuto di eventuali sottocartelle che potrebbero ereditare le autorizzazioni.