time is 10 mins fast

[mikeymike]

win 2003 the time is out by about 10 mins.

have tried resetting to correct time but keeps going back to 10 mins fast again.

it is a fairy new server so cant imagine the watch battery playing up,

we are remotely connected via another server elsewhere if this could cause probs??

[powdarrmonkey]

Yes, Windows machines in a domain will sync to each other, which is why your time drifts. Who controls your domain?

[mikeymike]

Yes, Windows machines in a domain will sync to each other, which is why your time drifts. Who controls your domain?

 

we are controlled by the priory group whos HQ is in bristol somewhere i think,

we are Lyndhurst, Southampton.

 

Its a pain as quite alot of the staff use that time to know when change of lessons etc.

[matt40k]

Yer AD uses kerbious which is time-based. Check your (DNS\DHCP) NTP\router settings.

 

EDIT:

 

Moan at HQ. Get them to check NTP settings.

[DrPerceptron]

Lucky... we changed the time by 1 minutes and locked everyone out of the domain...

 

I'd love to get it 5 minutes slower!

[powdarrmonkey]

Lucky... we changed the time by 1 minutes and locked everyone out of the domain...

 

I'd love to get it 5 minutes slower!

 

Yes, changing the time by more than 5 minutes (by default) will break Kerberos (everybody's tickets become invalid, including machines') so don't. Get it changed upstream by one minute every 48 hours.

[matt40k]

Surely changing the DHCP to use a correct NTP server, then manually changing the servers NTP server would be better. The worst thing would be getting the clients to restart.

[powdarrmonkey]

Surely changing the DHCP to use a correct NTP server, then manually changing the servers NTP server would be better. The worst thing would be getting the clients to restart.

 

But at the moment it works; a gradual alignment is much less upheaval.

 

Besides, this isn't a DHCP problem, it's to do with Kerberos and domain-based NTP.

[matt40k]

Fair point about less upheaval.

 

My point about DHCP would be to define the new time servers (NTP) within DHCP so when the machine requests and IP (pre-joining the domain) it should get the NTP servers and update BEFORE trying to connect to the AD.

 

Still this is just on paper, so I could be talking out of my arse.

[powdarrmonkey]

Fair point about less upheaval.

 

My point about DHCP would be to define the new time servers (NTP) within DHCP so when the machine requests and IP (pre-joining the domain) it should get the NTP servers and update BEFORE trying to connect to the AD.

 

Still this is just on paper, so I could be talking out of my arse.

 

If the machine is already a member, the time replication is built into AD as part of logon, so DHCP has very little to do with it. And if you're joining the domain, the time is synced at this point so that when you reboot, you're able to get a Kerberos ticket straight away.

[matt40k]

So changing the server should update the clients. Doing it 1min at a time would stop people being kicked? Right?

[powdarrmonkey]

So changing the server should update the clients. Doing it 1min at a time would stop people being kicked? Right?

 

Right. But you should allow at least 48 hours between changes, assuming that most clients are used during this time, and assuming that you haven't changed Kerberos to be less tolerant (eg. you've set the tolerance to 1 min instead of the default of 5).