Windows Time Service

[Hank Oen]

For regression test purposes, I:
1. Set the time source in all machines in my domain to my
PDC IP address [net time /setsntp=192.168.10.100] and
2. changed the registry time skew variable in my PDC from
5 seconds to 98000 seconds and
3. changed the system date back 60 days in the PDC and
4. restarted the windows time service in my Windows 2000
server SQL server which sychronized date and time with the
PDC just fine and
5. restarted time service in my Windows 2000 Professional
Workstation which would not synchronize date with the PDC.

Why do the servers resynchronize date and the workstations
fail to resynchronize the date when their time services
are restarted or when the w32tm -s \\computername is run
on the PDC?

 

[SaltPeter]

#1 Time is more critical to a W2K domain than your heart beat is to your
body.
#2 The "PDC emulator" is the authoritative time keeper for the domain, "net
time /setsntp" or not.
#3 Time skew modification from 5 secs to 98000 secs will guarentee that
clients won't be able to log on and replications will fail.
#4 a procedure that requires changing the time parameters on a W2K domain IS
guarenteed to fail.

There is no excuse to using such behaviour with SQL when the SQL language
does provide support for time specific queries. The only unit that needs
synchronization to an outside source is the FSMO role "PDC emulator".

For regression test purposes, I:
1. Set the time source in all machines in my domain to my
PDC IP address [net time /setsntp=192.168.10.100] and
2. changed the registry time skew variable in my PDC from
5 seconds to 98000 seconds and
3. changed the system date back 60 days in the PDC and
4. restarted the windows time service in my Windows 2000
server SQL server which sychronized date and time with the
PDC just fine and
5. restarted time service in my Windows 2000 Professional
Workstation which would not synchronize date with the PDC.

Why do the servers resynchronize date and the workstations
fail to resynchronize the date when their time services
are restarted or when the w32tm -s \\computername is run
on the PDC?

That's because the workstations can't log on. The grand majority of all
interaction between members of a W2K domain (IPCs, Kerberos, AD replication)
are all based on time stamps. Breaking the link between a workstation and
it's time authority breaks the link between the workstation and it's domain.

 

[Guest]

All the servers and workstations are physically located in
the same room, are connected to the same subnet, and are
members of the same isolated domain (behind a firewall)
that is not trusted by the other domains on the other side
of the firewall.

Through trial and error, I have found a manual procedure
that works:
1. Log on to PDC as Enterprise Administrator.
2. Log on to all other servers and workstations as
Enterprise Administrator.
3. Change time skew variable in PDC registry from 5
minutes to 98000 minutes.
4. In a DOS box on all servers and workstations, change
the DATE back 60 days.
5. In the PDC, change the DATE back 60 days.
6. Run w32tm -s \\server2
7. Run w32tm -s \\workstation1
8. Run w32tm -s \\workstation2

At this point, the DATE and TIME in the whole domain is
resynchronized to a DATE that is 60 days earlier than
today. It works the other way -- into the future -- too.

It is a pain to have to physically log on to all machines
and manually do these DATE changes.

My real question is this: is there any way to automate
this DATE and TIME change / resynchronization with scripts
or programs that can all be run from the PDC?

Thanks, Henry Oen

-----Original Message-----
#1 Time is more critical to a W2K domain than your heart beat is to your
body.
#2 The "PDC emulator" is the authoritative time keeper for the domain, "net
time /setsntp" or not.
#3 Time skew modification from 5 secs to 98000 secs will guarentee that
clients won't be able to log on and replications will fail.
#4 a procedure that requires changing the time parameters on a W2K domain IS
guarenteed to fail.

There is no excuse to using such behaviour with SQL when the SQL language
does provide support for time specific queries. The only unit that needs
synchronization to an outside source is the FSMO role "PDC emulator".

For regression test purposes, I:
1. Set the time source in all machines in my domain to my
PDC IP address [net time /setsntp=192.168.10.100] and
2. changed the registry time skew variable in my PDC from
5 seconds to 98000 seconds and
3. changed the system date back 60 days in the PDC and
4. restarted the windows time service in my Windows 2000
server SQL server which sychronized date and time with the
PDC just fine and
5. restarted time service in my Windows 2000 Professional
Workstation which would not synchronize date with the PDC.

Why do the servers resynchronize date and the workstations
fail to resynchronize the date when their time services
are restarted or when the w32tm -s \\computername is run
on the PDC?

That's because the workstations can't log on. The grand majority of all
interaction between members of a W2K domain (IPCs, Kerberos, AD replication)
are all based on time stamps. Breaking the link between a workstation and
it's time authority breaks the link between the workstation and it's domain.


.