Tenemos un problema en el que algunas computadoras no parecen captar todos sus GPO. Al buscar en el editor de administración de políticas de grupo, vemos muchos GPO con "x roja" y "archivo no encontrado" (y que no especifican qué GPO son).
Un poco sobre nuestro entorno, contamos con 4 controladores de dominio a nivel funcional Server 2008 R2. 2 DC son Server2k8R2 locales, otros 2 son instancias AWS EC2 externas que ejecutan Server 2016.
La ejecución de "net share" muestra NETLOGON y SYSVOL compartidos en rutas DIFERENTES para los 2 DC 2K8R2 frente a los DC 2K16 (no sé si esto es un problema).
Server2016 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL\sysvol\domain.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL\sysvol
Server 2008 R2 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL_DFSR\sysvol\superior.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL_DFSR\sysvol
En todos los casos, C:\Windows\SYSVOL\sysvol está vacío excepto la carpeta domain.local.
La ejecución de "DCDIAG" muestra un error en la prueba "SystemLog" para los cuatro y advertencias en la prueba DFSREvent:
AWSDC01 & AWSDC02:
SystemLog test-
"The Netlogon service encountered a client using RPC signing instead of RPC sealing".
"The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account.
DFSREvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
"
OnSite-DC1:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
SystemLog test - "An error event occurred. Event ID 0xC2000001. Unexpected failure. Error code 490@01010004"
OnSite-DC2:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
and
"This computer could not authenticate with \\AWSDC01.domain.local, a Windows domain controller for domain DOMAINNAME, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized."
Algunas cosas adicionales a tener en cuenta:
-Event viewer logs (on on-site DC1 and on-site DC2) under application and services > DFS replication show only information about replication between each other. No mention of replication between the AWS DC's.
- Every hour the on-prem DCs show a DFS error "the dfs replication service is stopping communication with partner {other on-prem DC} for replication group Domain System Volume due to an error. Error 9036.
AWS DC02 only shows error logs regarding DFS replication with on-prem DC02. Same error 9036 "replication service stopping due to an error".
AWS DC01, same thing - only shows logs regarding DFS replication with on-prem DC01. Error 9036 "replication service stopped due to an error".
¿Alguna idea de qué podría estar pasando aquí o dónde buscar a continuación?
Respuesta1
Los errores sugieren un problema de autenticación, por lo que la reciente actualización de Kerberos, a la que hace referencia Greg Askew, bien puede ser la causa, especialmente si actualizó recientemente y el problema comenzó en ese momento. Si cree que sí, considere eliminar esa actualización temporalmente y luego, cuando todo vuelva a funcionar, planee realizar una promoción continua de los servidores 2008 lo antes posible.
Podrías probar esta herramienta: https://www.microsoft.com/en-us/download/details.aspx?id=30005
Estoy seguro de que también he usado otra herramienta de monitoreo de replicación de MS antes, pero no recuerdo cómo se llama en este momento. ¡Fue una instalación de MSI, es todo lo que puedo recordar! Quizás fue solo diagnóstico FRS, no dfrs.
AD Replication depende en gran medida del DNS y del tiempo de sincronización, por lo que definitivamente verifique tres veces toda esa configuración. Podrías comparar tiempos con:
net time \\server
Vea si hay alguna disparidad, si funciona (es decir, si no hay problemas de conexión entre servidores al ejecutar el comando). De lo contrario, considere sincronizarlos todos desde la misma fuente de hora externa, pool.ntp.org, por ejemplo.
Para probar DNS, haga ping a cada servidor fqdn desde todos los demás servidores, compare los resultados entre sí y con lo que espera. Supongo que tiene alguna VPN o enrutamiento L3 no nat similar entre el sistema local y AWS. Por ejemplo, 192.168.1.10 puede hacer ping a 10.0.0.2, o cualesquiera que sean las IP "internas" locales y en AWS (solo estoy familiarizado con Azure, por lo que puede que no sea lo mismo, perdóneme si AWS funciona de manera diferente de alguna manera).
Es posible que también desee verificar tanto AWS como los sitios y servicios locales de AD, profundizar en NTDS y observar las relaciones de replicación. Puede hacer clic derecho y replicar, ver si dice (parafraseando) "ok" o "no puedo hacerlo"; podría ayudar a reducir el problema.