We set the time correctly in the BIOS, we've set the time correctly on our image,... but immediately when SCCM OSD takes over in PEand starts putting the image down it changes the time to 3 hours ahead?? Even though in our apply network settings it is set for the correct time zone. The Server(s) that it is getting stuff from and talking to are all in the same room too, so they have the right time?

When the PC is done being built the timezone is correct but the time stays at 3 hours ahead?

Any ideas?

Thanks,

Terry

are there any collection variable settings that could be setting the timezone ?
are the machines using a sysprep.inf or unattend.xml file with timezone settings specified

Been awhile but nope, neither.
I ended up just putting in a script that changes the time back to what it should be, but am curious what was going on.
Terry

What time zone are you in?

Possible causes I can think of off the top of my head:

-Group Policy
-A mandatory advertisement that's still kicking around that you may have forgotten
-A login script

Is this a domain environment?  Are you able to log in using domain accounts after OSD is done?  Generally, when your machines get joined to the domain, their time gets synched with the domain controller, and if the time drifts too far apart (I can't think of what the threshold is, but i'm pretty sure it's in minutes), the domain controller won't authenticate users.

For debugging purposes, perhaps you could write a batch file that echos the current time and date of the machine, then pauses, and drop it every few steps in your TS to help you narrow down at what point within the TS the time is getting changed.

At the start of the SMSTS.log file, there is a number of log lines regarding the setting of the time and time zone. You can take a look at that and see if it is the TS client that is changing the time settings.

One of the first things that the TS client does is to contact the MP and ask for its time information. It then applies these time settings to the client. This is done to prevent certificate validation errors that could occur due to time mismatch between the client and the server.

If you post those SMSTS log lines, I could take a look at it.

Several years later, I am noticing the same issue on SCCM 2012 R2 SP1.  The correct time is 8:26:50... For some reason TS sets it to 3 hours later... No idea why.  The client I am testing on is a Hyper-v 2012 R2 VM.

==========[ TsProgressUI started in process 1044 ]========== TsProgressUI 8/14/2015 8:26:50 AM 1048 (0x0418)
Command line: "X:\sms\bin\x64\TsProgressUI.exe" /Register:WinPE TsProgressUI 8/14/2015 8:26:50 AM 1048 (0x0418)
Registering COM classes TsProgressUI 8/14/2015 8:26:50 AM 1048 (0x0418)
sbModulePath = X:\sms\bin\x64\TsProgressUI.exe TsProgressUI 8/14/2015 8:26:50 AM 1048 (0x0418)
Unregistering class objects TsProgressUI 8/14/2015 8:26:50 AM 1048 (0x0418)
Shutdown complete. TsProgressUI 8/14/2015 8:26:50 AM 1048 (0x0418)
Process completed with exit code 0 TSMBootstrap 8/14/2015 8:26:50 AM 568 (0x0238)
Successfully registered TS Progress UI. TSMBootstrap 8/14/2015 8:26:50 AM 568 (0x0238)
Setting time zone to 360,0,-60,0,11,0,1,2,0,0,0,0,3,0,2,2,0,0,0,Central Standard Time,Central Daylight Time TSMBootstrap 8/14/2015 8:26:50 AM 568 (0x0238)
Setting time zone info to: 360, Central Standard Time, [0 11 0 1 2 0 0 0], 0, Central Daylight Time, [0 3 0 2 2 0 0 0], -60 TSMBootstrap 8/14/2015 8:26:50 AM 568 (0x0238)
TimeZone successfully set TSMBootstrap 8/14/2015 11:26:50 AM 568 (0x0238)
Found network adapter "Intel 21140-Based PCI Fast Ethernet Adapter (Emulated)" with IP Address 138.236.1.207. TSMBootstrap 8/14/2015 11:26:50 AM 568 (0x0238)
Starting Task Sequence Manager. TSMBootstrap 8/14/2015 11:26:50 AM 568 (0x0238)