Directiva de grupo: Unidades asignadas que no se cargan, Active Directory de Windows Server 2012 y Windows Pro 10

Red:

• Dominio multisitio.
• Cada sitio tiene 2 controladores de dominio de Windows Server 2012 R2 locales (en el sitio, la misma subred).
• Los sitios están definidos correctamente en Sitios y servicios de Windows.
• Los registros DNS para cada sitio SOLO tienen definidos los dos servidores DNS locales.
• TODOS los clientes son Windows 10 Pro de 64 bits con todas las actualizaciones.
• Ambas redes se ejecutan completamente en gigabit en conmutadores Cisco con cableado CAT6 certificado.
• Cada sitio tiene un servidor de almacenamiento local (en el sitio, la misma subred) de Synology.
• Como parte de la Política de grupo, dos unidades de red se asignan a recursos compartidos en el servidor Synology.

Diagnóstico de conectividad:

• dcdiag /test:dns /v /c /einformes PASSpara TODOS los servidores y TODAS las pruebas
• echo %logonserver% siempre devuelve un DC local
• nltest /dsgetdc siempre muestra un DC local y una IP local correcta
• En el sitio A, se muestran ambas unidades de red, con un 0,5% de posibilidades de falla (he experimentado algunas botas donde las unidades no se muestran correctamente).

Problema:

En el Sitio B, las unidades de red no aparecen quizás el 30% del tiempo. A veces son ambas unidades, a veces es una u otra. El problema es mayormente aleatorio y no parece seguir a ningún usuario o estación de trabajo en particular.

Síntomas

Del 30% del tiempo en que se presenta un problema:

• 5% de las veces una gpupdateo gpupdate /forceva a solucionar el problema y aparecerá de inmediato las unidades. Si gpupdateno funciona en el primer intento, casi nunca funcionará después de eso (para ese arranque)
• 5% de las veces a gpupdateo gpupdate /forcehará que aparezca una sola unidad
• 20% del tiempo, a gpupdateno solucionará el problema, pero el próximo arranque estará bien
• El 50% del tiempo, a gpupdateno solucionará el problema, pero después de un arranque y otro gpupdate , aparecerán las unidades

• El 20% del tiempo, se necesitarán varios reinicios (y gpupdatepara cada inicio) antes de que aparezcan las unidades. A veces son 2 botas, pero rara vez he tenido que reiniciar una computadora 6 o 7 veces antes de que aparezcan las unidades.

  • Durante este último 20% del tiempo, a veces recibiré errores del proceso gpupdate.

    The processing of Group Policy failed. Windows attempted to read the file 
    \domain\SysVol\domain.local\Policies{5898270F-33D0-41E8-A516-56B3E6D2DBAB}\gpt.ini 
    from a domain controller and was not successful. Group Policy settings may not be 
    applied until this event is resolved. This issue may be transient and could be 
    caused by one or more of the following:  
    
    a) Name Resolution/Network Connectivity to the current domain controller.  
    b) File Replication Service Latency (a file created on another domain controller 
       has not replicated to the current domain controller).  
    c) The Distributed File System (DFS) client has been disabled.
    

  • Este error es en realidad, generalmente pero no siempre, una buena señal porque generalmente después de recibir este error, la próxima 'gpupdate' o el próximo arranque y 'gpupdate' harán que las unidades vuelvan a aparecer.

Diagnóstico del mapa de unidad:

1. gpresult /h gpresult.html muestra:

   Drive Map (Drive: X)
    The following settings have applied to this object. Within this category, settings nearest the top of the report are the prevailing settings when resolving conflicts.
      X:
       Winning GPO  DriveMaps 
        General Settings
         Result: Success
   

2. He habilitado el registro de depuración del entorno de políticas de grupo (según http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx creó la entrada de registro [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). El archivo de registro c:\Windows\debug\UserMode\gpsvc.logno me ha mostrado ningún error claro, ni he podido encontrar mucha ayuda a través de google. Aquí hay algunos mensajes interesantes que he recibido:

   GPSVC(158.33c) 23:33:24:921 CheckGPOs: No GPO changes but extension Group Policy Drive Maps's returned error status 183 earlier.  
   GPSVC(158.c24) 23:38:12:203 ProcessGPOs(Machine): Extension Group Policy Drive Maps skipped with flags 0x110057. 
   GPSVC(158.157c) 23:08:08:216 ProcessGPOs(User): Extension Group Policy Drive Maps ProcessGroupPolicy failed, status 0xb7.
   

3. He habilitado la depuración de preferencias de política de grupo para Drive Maps (según http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the -rsat.aspx conjunto Drive Map Policy Processinga Enabledy encendido Event Loggingen propiedades de \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). El archivo de inicio de sesión C:\ProgramData\GroupPolicy\Preference\Trace\User.logno ha devuelto ningún error.

   2015-11-21 17:47:38.849 [pid=0x22c,tid=0xcd0] Starting class <Drive> - X:.
   2015-11-21 17:47:38.864 [pid=0x22c,tid=0xcd0] Adding child elements to RSOP.
   2015-11-21 17:47:38.880 [pid=0x22c,tid=0xcd0] Beginning drive mapping.
   2015-11-21 17:47:38.896 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] User does not have a split token.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] Drive doesn't exist (full token).
   2015-11-21 17:47:39.114 [pid=0x22c,tid=0xcd0] Connected with access name x:.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification Session ID is 2.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification discovered drive mask of 8388608.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] SendNotification drive event broadcast sent.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] SendNotification to Shell.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Properties handled.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Handle Children.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] EVENT : The element of user preferences 'X:' of the group policy object 'DriveMaps {06FEB8B9-632C-4A1C-A7C9-5A05E1041BEE}' was applied correctly.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] Completed class <Drive> - X:.
   

4. También tengo varias capturas de netmon de un inicio de sesión con unidades que no se cargan, pero la captura tiene tanta información que no estoy seguro de dónde comenzar.

5. Si, después de un inicio de sesión fallido, intento buscar directamente \\SynologyServer\ShareName\, el recurso compartido siempre se carga inmediatamente sin ningún error. No hay signos de problemas de conexión o permiso.

Pregunta:

¿Por qué ocurre este problema con tanta frecuencia en un sitio, pero casi nunca en el otro, cuando ambos están en el mismo dominio, tienen la misma política y ejecutan el mismo software?

La única diferencia de software que se me ocurre es que en el Sitio A, todas las computadoras estaban ejecutando Windows 8.1 Pro y se actualizaron a Windows 10 Pro, mientras que en el Sitio B, todas las computadoras tienen nuevas instalaciones de Windows 10 Pro.

Como casi no tengo representante, aún no puedo hacer preguntas, así que intentaré hacer una pregunta mientras publico una respuesta y espero no quedarme en lata. ;)

Asumiré que ha asegurado que la parte de GPO de este caso no es un problema, al probar este GPO contra un recurso compartido "tradicional" de UNC en otro sistema de Windows. Sin embargo, la información importante que falta en mi opinión es si los dispositivos Synology están o no unidos al dominio. Muchas unidades NAS basadas en Linux como Synology, QNAP, y otros, tienen componentes de software integrados que les permiten participar en dominios de Active Directory. Si este dispositivo participa o no en el dominio afecta la solución.

Dicho esto, tengo instalaciones remotas en mi red interconectadas con circuitos T1. Requerimos el uso de copias de seguridad de imágenes de Acronis en todos los sistemas debido a los requisitos del sistema. Por lo tanto, la copia de seguridad remota de imágenes de varios GB de estaciones de trabajo de Windows en T1 no es un iniciador. Así que colocamos unidades NAS Drobo en cada segmento local para superar esto y darnos un poco de tolerancia a fallas. Estos Drobos particulares no tienen la capacidad de participar en el dominio AD.

Para habilitar los recursos compartidos UNC como se configuraron, tuvimos que configurar dos cosas principales. Primero, creamos entradas DNS estáticas en los servidores DNS para permitir una resolución de nombre adecuada. Y segundo, tuvimos que "aflojar" dos políticas que DISA normalmente recomienda para la mayoría de los miembros del dominio. Solo soltamos estas políticas en el servidor de respaldo, y las estaciones de trabajo se respaldaron en sitios de "enlace lento", ya que estos eran los únicos sistemas que necesitaban acceder a los recursos compartidos respectivos:

• Configuración de la computadora \ Configuración de Windows \ Configuración de seguridad \ Opciones de seguridad:
  • Microsoft Network Client: firmar digitalmente las comunicaciones (siempre) = deshabilitado
  • Microsoft Network Client: Enviar contraseña sin cifrar a servidores SMB de terceros = Habilitado
  • Servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre) = deshabilitado

Los GPO para "firmar digitalmente las comunicaciones si se negocian" todavía están configurados en Habilitados, lo que mitiga un poco el riesgo de seguridad involucrado. Una vez que habilitamos estos cambios, se podía acceder de inmediato a los recursos compartidos a través de la ruta UNC, mientras que anteriormente era imposible.

Es por eso que dije antes que dependiendo de si sus NAS pueden participar en el dominio o no, determina la ruta de la solución. Si pueden participar, entonces el DNS y las políticas de grupo "SMB" no deberían ser un problema para usted y, por lo tanto, la solución estaría en otra parte. Si NO PUEDEN participar (como mis NAS), entonces esta puede ser su solución.

Bueno, encontré estos hilos, y parece una situación casi idéntica a la mía:

Windows 10: la directiva de grupo no se aplica directamente después del arranque, se realiza con éxito más tarde

Las unidades asignadas de Windows 8.1 / 10 GPO no se conectarán

Aparentemente, este problema es causado por Microsoft habilitando UNC Hardening en Windows 10 de forma predeterminada. Esto es para corregir una falla de seguridad, pero aparentemente involuntariamente hace que las unidades mapeadas se monten de manera poco confiable. No es sorprendente que parezca que Microsoft aún no ha abordado este error (¿o sí?)

Esto también explica por qué no estaba teniendo problemas en el Sitio A. Dado que todas las computadoras se actualizaron de Windows 8.1 Pro a Windows 10, supongo que la configuración con respecto al endurecimiento UNC se transfirió desde Windows 8 y permaneció apagada , mientras que las computadoras con la nueva instalación de Windows 10 utiliza el valor por defecto de la UNC endurecimiento en .

Todavía no he probado la solución, pero parece demasiado perfecta para mis síntomas como para no ser relevante. Me preocupa una solución que abra mi sistema a más amenazas de seguridad, por lo que estoy buscando alternativas. No me gusta la idea de configurar esto a través de la política de grupo, y me pregunto si es posible desactivar UNC Hardening solo editando manualmente el registro. Quiero experimentar en algunas computadoras primero antes de decidir qué hacer a continuación. Sin embargo, actualmente solo puedo encontrar pasos para cambiar la configuración a través de GPO o GPP ...

¿Alguna idea?

Solo quiero actualizar esto y decir que en algún momento una de las principales actualizaciones de Windows 10 solucionó este problema. Esta es una vieja pregunta, pero no me gusta dejar las cosas colgadas, por si acaso.

Después de leer todo lo que proporcionó en la actualización de Daniel, sugeriría que el endurecimiento de UNC, si bien está relacionado, no es la causa principal aquí, y que en realidad puede ser la opción de "arranque rápido" que el OP de la segunda publicación dijo que solucionó su problema . Toda esa información sobre el endurecimiento de UNC se refirió a los recursos compartidos SYSVOL y NETLOGON que se endurecieron de manera predeterminada. Si bien ese problema evitaría que sus clientes reciban actualizaciones de GP, el hecho es que Drive Map GPO ya se ha aplicado al menos una vez a los clientes en cuestión, y NO NECESITA volver a aplicar después de cada reinicio (aunque lo haga) para ejecutar El mapeo.

Obviamente, querrá probar cada opción independientemente de la otra, pero independientemente de qué opción pueda funcionar o no, esta línea de razonamiento parece estar cerca de la causa raíz de su problema.