Geeks With Blogs

News Clicky Web Analytics

web stats View David Caddick ('s profile on LinkedIn

Search this Site!

Locations of visitors to this page
View My Stats eXTReMe Tracker
This posting is provided "AS IS" with no warranties, and confers no rights. The opinions expressed within are my own and should not be attributed to any other Individual, Company or the one I work for. I just happen to be a classic techie who is passionate about getting things to work as they should do (and are sometimes advertised and marketed as being able to?) and when I can I drop notes here to help others falling in to the same traps that I have fallen in to. If this has helped then please pass it on - if you feel that I have commented in error or disagree then please feel free to discuss with me either publically or privately? Cheers, Dave
Thin Clients, VDI and Linux integration from the front lines.... Raw and sometimes unedited notes based on my experiences with VMware, Thin Clients, Linux etc.

Hi All,

Just a note regarding an issue I had to help resolve a little while back?

We had a pre-sealed image of an XPe intended for a customer, who wanted to join it to the domain, come through and during testing at our location and on site for the customer it was found that it simply refused to get it's time in sync 

What we able to narrow down to is that the Registry Entry for:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters was listed as Type = NoSync and what was really needed to be changed to NT5DS.

What we were also able to identify is that while we are quite certain that any *Local* user on an XPe device will always get “access denied” when trying to run NET TIME as they are not a valid domain user – what can be done though is run the w32tm /resync command (if the module/executable is available? AND ONLY if the time is within the default 5 minute max…) *OR* alternatively simply restart the Windows Time Service. Both of these commands can be run without issue using Local credentials.

Looking deeper in to why the W32Time Type was incorrect we managed to come up with this little gem from Microsoft:

Registry entries for the W32Time service and within this we found the following:

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
The Nt5DS setting may not use a manual configured source.
Note When you join a Microsoft Windows Server 2003-based computer to a domain, the computer may not synchronize its time setting with the time setting of the domain controller if the Automatically synchronize with an Internet time server check box in the Date and Time Properties dialog box is not selected. The default option (NTP) for Windows Server 2003 workgroup computers is disabled if the Automatically synchronize with an Internet time server check box is not selected. When you join the computer to a domain that has this setting, the default synchronization type (Nt5DS) for computers that are joined to a domain is not set and the time service does not synchronize from the domain hierarchy.

I have highlighted the interesting section in red. After further testing we found that the default image had this check box unchecked, however, once this was checked before joining the domain then the NT5DS setting would be in place immediately after the reboot following the Joining to the Domain and as a consequence the device would time sync correctly as soon as it was booted.

From what we can see this is an issue that is not restricted to purely XPe but XP as well and hopefully thi info might be useful to others?

Posted on Saturday, October 11, 2008 10:03 PM IT Management , Thin Clients | Back to top

Comments on this post: Reminder regarding time sync in a domain

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Dave Caddick | Powered by: