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

Mi problema es que la Política de grupo no se aplica cuando un cliente se inicia recientemente. Inmediatamente después del arranque, el cliente publica un mensaje de error en el registro de eventos con el origen "GroupPolicy (Microsoft-Windows-GroupPolicy)" y el Id. De suceso 1058: "El procesamiento de la Política de grupo falló. [...]". En la pestaña Detalles, el Código de error es 50, que significa ERROR_NOT_SUPPORTED. No es solo un problema cosmético: las políticas realmente no se aplican correctamente: las unidades de red asignadas no están allí, por ejemplo. Después de esperar un tiempo, ejecutar "gpupdate" funciona y las políticas se aplican normalmente: aparecen las unidades de red asignadas.

El escenario más simple en el que pude reproducir el problema: dominio recién creado en Windows Server 2012R2 recién instalado, el cliente es una máquina Windows 10 de 64 bits recién instalada. El dominio consta de un solo controlador de dominio y no tiene ninguna relación con otros dominios.

Dado que el mensaje de error indica que Windows no puede leer un archivo .GPT del recurso compartido Sysvol del dominio, intenté acceder al mismo archivo desde un símbolo del sistema. Y, de hecho, cuando abro un símbolo del sistema justo después del arranque, obtengo esto:

C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.

Después de esperar un minuto o dos, ejecutar el mismo comando dará una lista de directorio. Ejecutar gpupdate en este punto funcionará bien.

Establecí la configuración de la directiva de grupo "Siempre espere a que la red al iniciar la computadora e inicie sesión" en "Activado", y sé que esta política se aplica: en el mismo objeto de política se especifica una configuración del Registro, y cuando verifico el Registro en el cliente, la configuración especificada está ahí.

Otros factores que podrían ser relevantes:

• NTLM está restringido en el dominio, pero esto no parece importar: incluso después de habilitarlo, actualizar las políticas y reiniciar todas las máquinas, los síntomas siguen siendo los mismos.
• No importa si el servidor está configurado con DHCP o con una configuración estática.
• El servidor DNS para el dominio no admite actualizaciones dinámicas. Los registros necesarios se agregaron manualmente (desde C: \ Windows \ System32 \ config \ netlogon.dns)
• La hibernación está deshabilitada en el cliente (usando powercfg /h off) por lo que cada arranque es un arranque completo, no un arranque rápido
• El tiempo de espera de procesamiento de la política de inicio de la política se establece en 120 segundos
• La conectividad al DC funciona bien. Los pings funcionarán. Apagar el cliente, deshabilitar mi cuenta en AD, encender el cliente dará como resultado que el cliente no inicie sesión: inmediatamente se da cuenta de que la cuenta está deshabilitada.
• Aparte de este problema, no noto nada fuera de lo común.

Esto parece ser más un problema de SMB que un problema de directiva de grupo. Oler la conexión en el lado del servidor muestra algo interesante: la primera vez que ejecuto el comando dir \\domain.example.com\sysvol, lo siguiente se muestra en Microsoft Message Analyzer en DC:

1. El cliente configura una conexión TCP al puerto 445 del DC y se realiza una negociación comercial con éxito (DialectRevision: 0x02FF).
2. Inmediatamente después de eso, se realiza con éxito una negociación. DialectRevision es 0x0302.
3. Inmediatamente después de eso, el cliente cierra la conexión TCP con un TCP RST (??)

Cada vez que emito el comando y obtengo el error, ocurren los pasos 2 y 3.

Cuando el comando comienza a funcionar, se producen los pasos 1 y 2, pero en lugar de que el cliente envíe un TCP RST, se realiza un SessionSetup, luego un TreeConnect y luego se produce una gran cantidad de conversaciones SMB (aparentemente normales).

Por lo tanto, parece que de alguna manera el cliente no hablará SMB correctamente con el DC hasta un minuto o dos después del inicio, y esto hace que falle el procesamiento de la directiva de grupo.

¿Alguien sabe cómo puedo depurar y resolver este problema?

Comenzando con Windows 8, Microsoft introdujo esta noción de "arranque rápido", donde, cuando apaga el sistema operativo, hibernan la huella de la memoria del sistema operativo al igual que Hibernate funciona en escenarios de hibernación normales. Esto da como resultado que el sistema operativo se ejecute más rápido, pero también tiene el efecto secundario de deshabilitar el procesamiento GP por computadora en el inicio. Eso es probablemente lo que está viendo y esto puede deshabilitarse deshabilitando la política en Configuración del equipo \ Políticas \ Plantillas administrativas \ Sistema \ Apagado \ Requerir el uso de inicio rápido

Si eso no resuelve el problema, lo más probable es que se trate de un problema de sincronización de la pila de red, donde el procesamiento GP para la computadora se inicia antes de que la pila de red se inicialice por completo. Esto ha existido desde XP y a partir de Windows 7, Microsoft agregó una política en Configuración del equipo \ Políticas \ Plantillas administrativas \ Sistema \ Política de grupo \ Proceso de política de inicio Tiempo de espera donde puede aumentar el tiempo que GP espera antes de iniciar. Intente configurarlo en 60 segundos y vea si eso ayuda.

Darren

Me las arreglé para resolver este problema yo mismo. Como referencia, esto es lo que resolvió mi problema:

Primero, me equivoqué en que deshabilitar todo bloqueo de NTLM resultó en los mismos síntomas. Resultó en un síntoma diferente , que resultó tener el mismo efecto. Sin ninguna política de bloqueo NTLM vigente, el dircomando ahora resultó en un error de acceso denegado. La directiva de grupo todavía no se aplicaría, lo que tiene sentido: SYSVOL todavía no era accesible.

Un poco de búsqueda en la web me dijo que sé que tenía un problema más común. aunque. Aparentemente, los clientes de Windows 10 pueden tener problemas para acceder al recurso compartido SYSVOL de los controladores de dominio (y quizás también para el recurso compartido NETLOGON). Supuestamente, Windows 10 cambió algo en la forma en que accede a esos recursos compartidos, lo que puede ocasionar problemas. La solución consiste en deshabilitar el endurecimiento de ruta UNC en el cliente para estos recursos compartidos, estableciendo la Política de grupo "Rutas UNC endurecidas" para los clientes de Windows 10 de esta manera:

\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

(Si tiene problemas para acceder al recurso compartido de Netlogon desde clientes de Windows 10, también podría ayudar establecer los tres parámetros a cero para ese recurso compartido).

Consulte el artículo de Microsoft sobre MS15-011 para obtener más información. Contiene una buena descripción de las implicaciones de seguridad de cambiar esta configuración, así como pasos detallados sobre cómo cambiar la política.

Advertencia : ¡Tenga en cuenta que la configuración anterior desactiva algunas o todas las protecciones contra el problema de seguridad para el que se creó MS15-011! No solo los copie / pegue ciegamente, sino que tome una decisión informada basada en los riesgos involucrados. Además, es probable que este problema se resuelva en algún momento en el futuro. Cuando eso suceda, no olvide establecer esta política en los valores recomendados como se describe en MS15-011.

Intenté varias sugerencias, incluidos los cambios en el registro y los cambios en la política de grupo local, ninguno de los cuales resolvió el problema: las unidades mapeadas todavía estaban eliminadas en el arranque. Un gpupdate lo arreglaría cada vez, pero ese fue un paso adicional para el usuario.

Lo que terminó solucionando fue mapear manualmente las unidades de red, reemplazando las entradas de GPO en cada una de ellas. No es necesario desconectar y reemplazar, los mapeé de la misma manera que se mapearon, solo manualmente.

Solo para su información para cualquier persona que encuentre este hilo, desactivar el endurecimiento de UNC mediante la configuración de autenticación mutua a 0 está deshabilitando parte de su seguridad. Estamos teniendo el mismo problema con los clientes de win7, y estaba tratando de trabajar con Microsoft en eso. Me dijeron que es un error, pero hasta ahora no me han dado una forma de rastrear cuándo se abordará el error.

Consulte este otro hilo para obtener más información https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise -x64