7.NTP Servers en dominios Microsoft. Chequeos con w32tm y Net Time.

Equipos cliente
En la variable de registro siguiente tenemos el setting para el Time Service de nuestros clientes HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters.
El valor Type, debe ser en cualquier máquina de nuestro dominio NT5DS y significa que nuestra maquina (sea cliente o servidor miembro, o incluso DC) está cogiendo el tiempo de nuestra jerarquía de dominio, entregado por el PDC Emulator.

Si eso no ocurre, haremos lo siguiente, que es básicamente, resetear el Servicio de tiempo en esa máquina que tiene mal dicho servicio. Esto mismo que vamos a hacer es válido en otras situaciones, como por ejemplo, ante un fallo de kerberos el cual se apoya en él (event id 4 o 5).

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Con ello debe haber puesto el valor a NT5DS.

Nota: Si encontramos NTPServer en este valor, puede ser porque aún no lo ha cambiado y antes de estar en el dominio lo tenía puesto. Con los comandos de arriba debe obtener su valor correcto. Respecto a las políticas relativas al time service, lo aconsejable es no tocarlas y dejarlas “not configured” by default. 
(Estan en Compunter configuration\Admin Templates\System\Windows Time Service)


PDC Emulator (mover el rol si es necesario al DC adecuado)

¿Quién es el PDC emulator actualmente en nuestro sistema?¿quién tiene el rol?
C:\Archivos de programa\Support Tools>netdom query fsmo

Schema owner                dc1.midominio.com
Domain role owner           dc1.midominio.com
PDC role                    dc2.midominio.com
RID pool manager            dc2.midominio.com
Infrastructure owner        dc3.midominio.com

The command completed successfully.

Según lo anterior, nuestro PDC actual es dc2 , y éste a su vez obtiene de una fuente externa, que lo aconsejable suele ser nuestro Router Principal si tenemos una LAN o un entorno corporativo. Otros DC tienen los roles de “dominio”, sin embargo aquí debido a que los roles más críticos son el RID Pool y el PDC, o al menos los que más carga soportan están o deben estar en el DC más potente y mejor conectado (buena practica MicroSoft).

Otra consideracion es que el Maestro de Infraestructura no debe ser GC y como DC1 y DC2 lo son, ponemos dicho rol en DC3.

Sabemos que DC1 es el Forest Root Domain(el primer DC que se instaló) y al ser DC2 el más potente y con el objeto de repartir cargas, entendemos que es mejor que albergue el PDC y del RID Manager y el rol de Infraestructura lo pasaremos a otro(DC3). De todos modos la salida anteriormente obtenida es bastante correcta, ya que los roles repartidos en 3 DC tambien es bastante correcto.

En principio actualmente está funcionando todo bien, pero hay casos en los que los equipos, debido a sus distribuciones geograficas en distintos sites no alcanzan o les cuesta más alcanzar a los DCs y en esos casos habrá que pensar como distribuir los roles mejor. Entendemos que DC1 hará el trabajo más eficientemente ya que tiene más conexiones directas con el resto de DCs según la estructura ISTG. Es solo una cuestión de rendimiento para obtener mejoras de respuesta y de sincronización global.

¿Qué settings debe tener el PDC?

Es bueno que nuestro PDC obtenga 1 fuente NTP fiable (en nuestro caso el Router del site principal) y a partir de aquí, entrega al resto de DCs. En principio la fuente podría ser cualquier otro ntp de internet e incluso su propio reloj, la cuestión es que será él quien indique el tiempo al resto de equipos de toda nuestra red.

¿Cómo podemos configurar el PDC?  

Con w32tm /config

w32tm /config /manualpeerlist:”″ /syncfromflags:”” /reliable:”” /update

Este commando, entra en modo configuracion (/config ) para sobrescribir en el registro del PDC los valores necesarios (por ello mejor no tocarlo en las políticas). 

En /maualpeerlist le indicamos el servidor o servidores NTP de donde queremos sincronizar, nuestra fuente original que se propagará al dominio. Esto hará que nuestro Windows envié peticiones a él en modo “cliente” del servicio de tiempo y luego actua como servidor para todo su dominio.

En /syncfromflags , tenemos dos opciones para establecer el tipo de origen de tiempo Manual o DomHier (Domain Hierarchy). En el primero cogemos de la lista Manualpeerlist y en el segundo caso sincronizamos de un DC.

/reliable, es para indicar que la fuente es confiable, realmente al coger del PDC siempre es fiable, por ello si usamos “domhier” no lo ponemos.

El /update es para que los cambios tengan efecto en el servicio w32time. Sería bueno reiniciar el servicio de Windows time y resincronizarlo. Por ello haremos un pequeño bat que ejecute estos comandos. Luego podemos chequear los eventos 35 y 37 en el sistema.

Por tanto nuestro comando, teniendo en cuenta que queremos una fuente de confianza para el PDC que sea el router, la ponemos en manual, pero solo para él. Entonces en el PDC EMULATOR quedaría:

w32tm /config /manualpeerlist:192.168.1.254 /syncfromflags:manual /reliable:yes /update

Sin embargo para un DC o servidor miembro, así como el resto de computadores, todos queremos que cojan el tiempo de la jerarquía de dominio:

w32tm /config /syncfromflags:domhier /update

Chequeo de sincronización de tiempo

La manera más segura es esperar para que la sincronización tenga lugar, o en un reinicio de la máquina, al final lo que obtenemos es un Event ID 35 en el log de Sistema. Aquí se describe como está sincronizando el equipo, ya sea DC, servidor miembro o cliente. Lo mejor es chequearlo en los clientes para asegurarnos que existe un DC final que nos da el tiempo correcto y también asegurar que tu configuración de NTP en el PDC se está usando como quieres.

También podrías forzar una resincronizacion: ¿Cómo? Pues cambiando el tiempo (pero poco, no más de 1 min o 2 de diferencia) y luego ejecutando:

w32tm /resync /rediscover

Después de unos segundos, el evento 35 debe registrarse y debemos haber recuperado la hora correctamente de nuestro PDC (o bien algún otro DC en su lugar).

W32tm /monitor

Nos daría esta salida para todos los dc, la cual interpretaremos más abajo:

 dc2.midominio.com [192.168.1.10]:

    ICMP: 2ms delay.

    NTP: +0.0154641s offset from dc3.midominio.com

        RefID: dc1.midominio.com [192.168.1.11]

....resto DCs

Cada uno de estos grupos de líneas, nos dice lo siguiente;

Para el servidor especificado en la primera línea, el ICMP, nos indica el retardo físico en llegar la señal desde el PDC. En el caso de estar en el mismo site es 0ms y si están en otro site tenemos valores más altos. 

¿Quién entrega el tiempo finalmente?  el RefID es la fuente real, quien le ha dado la hora real (puede ser el PDC o el asociado de hora más rápido para obtener el tiempo según el algoritmo de asignación de “scores” de Microsoft). 

La línea NTP muestra el PDC reconocido por todos, y es quien en situación ideal debe entregar el tiempo a todos, pero finalmente puede haberlo hecho otro asociado de hora (el cual obtuvo de él).

Comando Net Time

Podemos usar el comando net time para resolver problemas con origen W32tm en el visor de eventos. Podemos con este comando hacer lo siguiente, entre otras cosas:

Dar a un DC (o servidor) un Sntp server: net time /setsntp:Windows.time.com /set /yes

Para clientes o servidores miembro: net time /setsntp:DC1

Consultar quien te da la hora: net time /querysntp