Pausa larga al acceder al espacio de nombres DFS

Recientemente hemos migrado nuestra red de Windows para usar DFS para archivos compartidos. DFS funciona bien, excepto por un problema molesto: los usuarios experimentan un retraso significativo cuando intentan acceder a un espacio de nombres DFS al que no han accedido por algún tiempo. He intentado solucionar el problema, pero hasta ahora no he tenido éxito, y esperaba que alguien aquí tenga algunos consejos para ayudar a resolver el problema.

En primer lugar, algunos antecedentes en nuestra red:

La red utiliza un dominio de Active Directory de nivel funcional de Windows 2008 con dos DC de Windows 2008 y dos servidores DNS (uno en cada uno de los DC). La red es solo DNS, no WINS. Todas las computadoras están ubicadas en el mismo sitio y conectadas por Gigabit Ethernet. Tenemos aproximadamente 20 espacios de nombres DFS basados ​​en dominio en modo Windows 2008, y cada espacio de nombres DFS tiene dos servidores de espacio de nombres DFS de Windows 2008 (los mismos dos servidores para todos los espacios de nombres). Todos los servidores de espacio de nombres están en modo FQDN y todos los destinos de carpeta se especifican usando su FQDN. Todas las computadoras están actualizadas con Service Packs y parches.

Los objetivos de carpeta reales (es decir, el SMB comparte nuestras carpetas de DFS) están dispersos en varios servidores de archivos y aplicaciones, todos ejecutan Windows 2008, excepto dos servidores de aplicaciones que ejecutan Windows 2003 R2, sin ninguna configuración de replicación (por ejemplo, todas las carpetas DFS actualmente solo tiene una carpeta de destino).

Algunos detalles más sobre el problema:

El retraso de acceso al espacio de nombres generalmente es de 1 a 10 segundos y parece ocurrir cuando una computadora en particular no ha accedido al espacio de nombres solicitado durante aproximadamente cinco minutos o más.

Por ejemplo, si el usuario no ha accedido a \\ domain.name \ namespace1 \ durante más de cinco minutos e intenta acceder a \\ domain.name \ namespace1 \ a través del Explorador de Windows, la ventana del Explorador se congelará de 1 a 10 segundos antes de finalmente reanudar y mostrar las carpetas que existen en \\ domain.name \ namespace1. Si luego cierran la ventana del Explorador e intentan acceder a \\ dominio.nombre \ nombreespacio1 \ nuevamente dentro de cinco minutos, el contenido se mostrará casi instantáneamente; si esperan más de cinco minutos, pasará por la pausa de 1 a 10 segundos nuevamente.

Una vez "dentro" del espacio de nombres, todo es agradable y ágil, es solo la conexión inicial al espacio de nombres que es lenta.

Los retrasos en la exploración parecen afectar a todas las variantes de Windows que utilizamos (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3): posiblemente sea un poco peor en Windows XP / 2003 que en Windows 2008, pero yo No estoy seguro de si la diferencia no es solo psicológica.

Acceder directamente a los destinos de la carpeta subyacente no presenta ningún retraso, es decir, si se accede directamente a los recursos compartidos SMB señalados por DFS (sin pasar por DFS), entonces no hay pausa.

Durante la resolución de problemas, noté que la "Duración de la caché" para todas nuestras raíces DFS está establecida en 300 segundos - 5 minutos. Dado que esta es la misma cantidad de tiempo requerida para activar la pausa, supongo que este almacenamiento en caché está relacionado de alguna manera, aunque no estoy seguro de qué es exactamente lo que se almacena en caché en el cliente y, por lo tanto, lo que debe buscarse nuevamente después de que hayan transcurrido 5 minutos.

Al intentar resolver el problema, ya he intentado / verificado lo siguiente (sin éxito):

• Ejecute dcdiag en ambos controladores de dominio: no se encontraron problemas
• Hice algunas comprobaciones básicas del servidor DNS sin encontrar ningún problema: no sé cómo verificar los servidores DNS en detalle, pero agregaría que la red no exhibe ningún otro comportamiento extraño que pueda indicar un problema de DNS
• Antivirus deshabilitado en clientes y servidores
• Eliminar uno de los servidores de espacio de nombres de un par de espacios de nombres: no hay diferencia

Así que ahí es donde estoy, y no tengo ideas. ¿Alguien puede sugerir qué puede estar causando los retrasos y / o lo que debería intentar a continuación?

Bueno, finalmente parece que hemos resuelto este problema en nuestro entorno. Para los beneficios de los demás, esto es lo que descubrimos y cómo solucionamos el problema:

Para intentar obtener más información sobre lo que estaba ocurriendo antes / durante / después de los retrasos, utilizamos Wireshark en una máquina cliente para capturar / analizar el tráfico de red mientras ese cliente intentaba acceder a un recurso compartido DFS.

Estas capturas mostraron algo extraño: cada vez que ocurría la demora, entre el envío de la solicitud DFS del cliente a un DC y la referencia a un servidor raíz DFS que regresaba del DC al cliente, el DC enviaba varios nombres de difusión búsquedas a la red.

En primer lugar, DC transmitiría una búsqueda de NetBIOS para DOMAIN (donde DOMAIN es nuestro nombre de dominio de Active Directory anterior a Windows 2000). Unos segundos más tarde, transmitiría una búsqueda LLMNR para DOMAIN. Esto sería seguido por otra búsqueda de NetBios de difusión para DOMAIN. Después de que estas tres búsquedas se transmitieron (y supongo que se agotó el tiempo de espera), el DC finalmente respondería al cliente con una referencia (correcta) a un servidor raíz DFS.

Estas búsquedas de nombres de difusión para DOMAIN solo se enviaron cuando se produjo el gran retraso al abrir un recurso compartido DFS, y pudimos ver claramente en la captura de Wireshark que el DC no estaba devolviendo una referencia a un servidor raíz DFS hasta que se enviaron las tres búsquedas ( y ~ 7 segundos pasaron). Entonces, estas búsquedas de nombres de transmisión fueron, obviamente, la causa de nuestros retrasos.

Ahora que sabíamos cuál era el problema, comenzamos a tratar de descubrir por qué estaban ocurriendo estas búsquedas de nombres de difusión. Después de un poco más de búsqueda en Google y algunos ensayos y errores, encontramos nuestra respuesta: no habíamos establecido la clave de registro DfsDnsConfig en nuestros controladores de dominio en 1, como se requiere cuando se usa DFS en un entorno solo de DNS.

Cuando originalmente DFS de configuración en nuestro entorno que nos leemos los diversos artículos acerca de cómo configurar DFS para un entorno sólo DNS (por ejemplo, Microsoft KB244380 y otros) y tenían conocimiento de esta clave de registro, pero habíamos misintepreted las instrucciones sobre cuándo / cómo úsalo.

KB244380 dice:

La clave de registro DFSDnsConfig se debe agregar a cada servidor que participará en el espacio de nombres DFS para que todas las computadoras comprendan los nombres completos.

Pensamos que esto significaba que la clave de registro debía establecerse solo en los servidores de espacio de nombres DFS , sin darnos cuenta de que también era necesaria en los controladores de dominio. Después de establecer DfsDnsConfig en 1 en nuestros controladores de dominio (y reiniciar el servicio "DFS Namespace"), el problema desapareció.

Obviamente estamos contentos con este resultado, pero agregaría que todavía no estoy 100% convencido de que este sea nuestro único problema. Me pregunto si agregar DfsDnsConfig = 1 a nuestros DC solo ha solucionado el problema, en lugar de resolverlo. . No puedo entender por qué los DC intentarían buscar DOMINIO (el nombre de dominio en sí mismo, en lugar de un servidor en el dominio) durante el proceso de referencia DFS, incluso en un entorno que no sea solo DNS, y también sé que no he configurado DfsDnsConfig = 1 en controladores de dominio en otros entornos DNS (ciertamente mucho más pequeños / más simples) y no he tenido el mismo problema. Aún así, hemos resuelto nuestro problema, así que estamos felices.

Espero que esto sea útil para los demás que están experimentando un problema similar, y gracias nuevamente a aquellos que ofrecieron sugerencias en el camino.

Esto podría ser causado por el pedido de la máscara de red del servidor DNS. Nos encontramos con esto recientemente en Server 2003. Esto depende de su subred actual.

Ejemplo.

Sitio 1: subred IP 10.0.0.0/24 Sitio 2: subred IP 10.0.1.0/24

El cliente en el sitio 2 realiza una consulta DNS para su espacio de nombres basado en el dominio y se le dará el servidor DFS en el sitio 1 de forma predeterminada ya que el servidor DNS no conoce los límites de IP del sitio. Debe informar a sus servidores DNS qué máscara de subred usar para identificar con qué direcciones IP responder.

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

El Blog del equipo de Active Directory tiene un artículo de tres partes TODO sobre retrasos DFS.

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

Cubre los aspectos básicos del proceso de referencia y luego muestra cómo utilizar diversas herramientas, incluidas dfsUtil y dfsDiag, para descubrir la causa real de los retrasos.

Me ayudó a encontrar mi problema. Que resultó no tener permisos de lectura en el directorio compartido para usuarios de dominio.

HTH, Daniel

Huele a un problema de DNS pero todo vale. Preferí mucho el viejo FRS porque las herramientas de diagnóstico como Ultrasonido eran muy útiles: 7

¿Obtiene algo en el registro de eventos de replicación DFS en los destinos? (el informe de salud de DFS extraerá sus advertencias del registro de eventos)

Correr sin WINS es un buen objetivo y admirable, aunque estoy bastante en contra de esto si hay algún sistema de Windows anterior a Vista / 2008 ya que las cosas no siempre funcionan como se esperaba o tan rápido sin WINS en mi experiencia, aunque realmente no debería importar

El cliente almacena en caché una referencia DFS, es decir, cuando ingresa \ domain.name \ namespace, almacenará en caché a qué servidor real se refiere domain.name. Una vez que la referencia expira del caché, el cliente básicamente tiene que "descubrir" su topología DFS nuevamente, de ahí la demora.

Eche un vistazo aquí: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx y aquí http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx para obtener más información sobre cómo funciona esto.

¿Soluciones posibles? Una manera poco hábil de hacerlo podría ser escribir un pequeño programa que "mantenga vivo" cada pocos minutos; por ejemplo, un programa en C que es el primer archivo que encuentra e inmediatamente lo cierra. No he intentado ni probado esto, y definitivamente necesitarías considerarlo detenidamente si lo ibas a hacer.

Hemos tenido un problema de sonido similar, en el que los usuarios experimentarían demoras (hasta un minuto) entre hacer clic en una unidad asignada a un recurso compartido DFS y poder ver y explorar las carpetas dentro del recurso compartido.

Los usuarios también tenían unidades de inicio asignadas a un recurso compartido DFS diferente en el mismo volumen, y no tuvieron demoras al acceder a las carpetas allí.

La diferencia entre los dos es la enumeración basada en el acceso (ABE): el problema compartido lo tiene habilitado (es una unidad común para los usuarios, con miles de carpetas; ABE significa que los usuarios solo ven aquellas carpetas para las que tienen permisos).

Deshabilitar ABE eliminó el problema por completo. Obviamente, esta no es una solución, ya que los usuarios ven todas las carpetas y las confunden. He replicado el recurso compartido DFS en un servidor con algún disco de repuesto como medida temporal, e incluso con ABE habilitado en este nuevo objetivo, la demora se ha ido.

El servidor con problemas es 2k3R2 y tiene un tiempo de actividad de más de 150 días (!), Por lo que se reiniciará y CHKDSK se ejecutará sobre el volumen ofensivo. Volveré a publicar aquí si esto hace alguna diferencia en el problema. El nuevo objetivo está en un servidor 2k8.

dfsutil / spcflush y dfsutil / pktflush pueden ser una solución también en una red de sitios múltiples, asegúrese de que el enlace DFS del sitio de origen provenga del servidor local y no del caché.

Sé que el póster original no estaba usando WINS, pero estoy publicando para el beneficio de otros, ya que usamos esta publicación para ayudar a resolver un problema muy similar. Para nosotros terminó siendo alguien que decidió nombrar su estación de trabajo con el mismo nombre que el dominio. Por lo tanto, cada vez que el DC hizo una búsqueda en el nombre de dominio para la referencia DFS, quería resolver en esa estación de trabajo y causaría un retraso considerable de varios 10 segundos. Se colocó una entrada estática 20 en WINS apuntando a un DC y esto ha resuelto el problema. Si no tenía WINS, podría experimentar colocando el nombre de dominio como nombre de máquina en el archivo LMHOSTS apuntado a un DC para obtener la búsqueda 20, y establecer la prioridad para que LMHOSTS sea el primer lugar para buscar la resolución de nombres de netbios.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Esta página en realidad menciona los controladores de dominio y DFSN, si eso ayuda.

Controlador de dominio DFS y entradas de registro del servidor raíz

Las siguientes entradas de registro se encuentran en

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

en servidores raíz y controladores de dominio. Todas las entradas son REG_DWORD.

Así que usé este artículo en mi búsqueda. Configuré todo y aún tuve problemas. Después de pasar varios días investigando el problema y excluyendo todo 'Microsoft', supuse que estaba relacionado con la red. Resulta que nuestro Acelerador WAN fue el problema. Hice que nuestros muchachos de redes desactivaran la aceleración de nuestros controladores de dominio y todo mejoró.

Tenía muchos controladores, también un script ( dnsdfs.cmd servername):

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

Usted menciona que tiene 20 servidores DFS pero no menciona si todos los servidores están en la misma instalación.

Si estos servidores no están en la misma instalación y cada otro sitio tiene su propio dominio, es posible que desee asegurarse de que la recuperación del cliente esté habilitada.

Para aquellos que terminan aquí a través de una búsqueda en Google y que tienen el mismo problema ...

Primero verifique que todos los enlaces en su espacio de nombres estén disponibles y sean buenos. Eso es lo que sucedió en mi caso, todavía había un enlace en el espacio de nombres a un servidor que estaba inactivo, por lo que la larga pausa al abrir DNS fue porque estaba buscando ese servidor y estaba fallando. Una vez que desactivé ese enlace en DFS, la larga pausa desapareció.

Verifique que el grupo de usuarios autenticados tenga acceso para enumerar el contenido del directorio raíz al que está asignado. Por ejemplo, si la unidad x: está asignada a \ domain.local \ departents \ Marketing, el usuario necesitará permiso de lista para \ domain.local \ departamentos. En 2008/2012, puede especificar bajo permisos avanzados que se aplica a "Esta carpeta solamente" para que no se les permita enumerar el contenido de ninguna subcarpeta que pueda estar heredando permisos.