- This topic is empty.
-
AuthorPosts
-
November 5, 2010 at 4:11 pm #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? Thanks
November 7, 2010 at 9:27 pm #19303Why not use a Timeserver on the client?
CG
November 8, 2010 at 9:46 am #19314CG
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?
November 9, 2010 at 4:26 am #19327Have 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:ffffffffUsual 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)
November 9, 2010 at 9:56 am #19330Gavin001
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 timeFor 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.
November 9, 2010 at 3:09 pm #19336This is disabled because the little tool Neutron is doing the timesync instead of the inbuild Windows timesync.
CG
-
AuthorPosts
- You must be logged in to reply to this topic.