- This topic is empty.
5. November 2010 at 16:11 #6218
Following the instructions in the Wyse document “Prepping an XPe Image for Deployment”, I’ve taken an image of a V90LE. This image is then being applied to other terminals which are being added to our domain and they are sitting in an OU which has its own GPO’s applied to it. The problem we’re having is that the GPO’s aren’t being applied. On looking in the event viewer on a terminal that has the image applied, there is event ID 1097 which says “Windows cannot find the machine account. The clocks on the client and server machines are skewed.” On looking at the date and time of the terminal, it appears to be the exact date and time of when the image was taken from the original terminal. Is this right? Why is the terminal which is having the image applied to it not getting the correct date and time. Could I have missed something out when taking the image? I’ve found a document on the Microsoft website (http://support.microsoft.com/kb/886516/en-us) and followed what’s suggested, but it makes no difference. The only way I’ve so far found to resolve the issue is to manually set the date and time to the correct one, but this isn’t a practical fix as we have 1000 terminals we need to deploy ASAP! Anyone got any ideas? Thanks7. November 2010 at 21:27 #19303ConfGenKeymaster
- Total Post: 11428
- Jedi Master
Why not use a Timeserver on the client?
CG8. November 2010 at 9:46 #19314
Our time servers are our DC’s, so I was under the impression that the terminals would pick up the correct date and time once they’d joined the domain? Would the write filter being enabled cause any problems with this?9. November 2010 at 4:26 #19327gavin0001Member
- Total Post: 23
- Regular Joe
Have you checked to make sure that the client can actually see/use the timeserver? If you need to check that the timeserver is set after you’ve joined the domain, you should be able to open up regedit and goto [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters] and check that NtpServer is set to your sntp server.
Also, something we did with our terminals was to extend the MaxPhaseCorrection registry settings so that (hopefully) the client will not fail to sync if the time is out of skew too much.
Open up regedit and navigate to [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig] and set “MaxNegPhaseCorrection” and “MaxPosPhaseCorrection” to dword:ffffffff
Usual disclaimers apply, I take no responsibility if this breaks your machine, etc etc
EDIT: Something I forgot to mention is that we also shortened the UpdateInterval to dword:00000e10 (3600 seconds)9. November 2010 at 9:56 #19330
Thanks for that post. Finally figured out what it was. In that HKLMSystemCurrentControlSetW32TimeParameters key, there’s a value called Type and this was set to NoSync. Did a bit of digging round on the web and found an MS article which explained:
Type : REG_SZ
Used to control how a computer synchronizes.
Nt5DS = synchronize to domain hierarchy [default]
NTP = synchronize to manually configured source
NoSync = do not synchronize time
For some reason the default on these terminals is NoSync and not Nt5DS. Once I changed the setting to Nt5DS and rebooted the terminal, it’s now picking up the correct date and time.
Thanks for your help.9. November 2010 at 15:09 #19336ConfGenKeymaster
- Total Post: 11428
- Jedi Master
This is disabled because the little tool Neutron is doing the timesync instead of the inbuild Windows timesync.
- You must be logged in to reply to this topic.