none
Windows 10 Conflicting Time Issue

    Question

  • Windows 10 Conflicting Time

    I have a very strange issue with the time service. I have created a very basic build on Windows 10 Education 1511 x64. I have removed a few Microsoft Store Apps (see below), and installed Office 2016. All this has been done in audit mode. I’ve sysprep’d the image using the answer file below. I then capture it to WDS and deploy it to various clients, physical and virtual. It deploys successfully and I can login as a domain user. The client picks up time from the PDC emulator and all is well. However, after anywhere from a few minutes to a few hours the time on the client reverts back to the time it was captured. I think start getting errors in the event log (please see below). Any help would be greatly appreciated.

    App Packages Removed

    'Microsoft.3DBuilder'

    'Microsoft.BingFinance'

    'Microsoft.BingNews'

    'Microsoft.BingSports'

    'Microsoft.BingWeather'

    'Microsoft.CommsPhone'

    'Microsoft.Getstarted'

    'Microsoft.Messaging'

    'Microsoft.MicrosoftOfficeHub'

    'Microsoft.MicrosoftSolitaireCollection'

    'Microsoft.Office.OneNote'

    'Microsoft.Office.Sway'

    'Microsoft.People'

    'Microsoft.SkypeApp'

    Microsoft.Windows.Photos'

    'Microsoft.WindowsAlarms'

    microsoft.windowscommunicationsapps'

    Microsoft.WindowsMaps'

    'Microsoft.WindowsPhone'

    'Microsoft.XboxApp'

    Microsoft.ZuneMusic'

    'Microsoft.ZuneVideo'

    'king.com.CandyCrushSodaSaga'

    'Microsoft.Appconnector'

    '9E2F88E3.Twitter'

    Sysprep Answer File

    <?xml version="1.0" encoding="utf-8"?>

    <unattend xmlns="urn:schemas-microsoft-com:unattend">

        <settings pass="generalize">

            <component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

                <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls>

            </component>

        </settings>

        <settings pass="specialize">

            <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

                <CopyProfile>true</CopyProfile>

                <RegisteredOwner>XXXXXXXXXXXXXXXX</RegisteredOwner>

            </component>

        </settings>

        <cpi:offlineImage cpi:source="wim://xxxxxx/xxxxxx/downloads/win10entoriginalmedia.wim#Windows 10 Enterprise" xmlns:cpi="urn:schemas-microsoft-com:cpi" />

    </unattend>

    Client Event Log Error

    TIME-SERVICE EventID 34

    The time service has detected that the system time needs to be  changed by 349871 seconds. The time service will not change the system time by more than 4294967295 seconds. Verify that your time and time zone are correct, and that the time source DEPLOYSERVER.DEPLOYTEST.local (ntp.d|0.0.0.0:123->192.168.121.1:123) is working properly.


    Daniel Wingfield

    Tuesday, February 23, 2016 11:17 AM

Answers

  • Having encountered same, here is what I've learned.

    There is a known bug where system time on domain joined Windows 10 computers Version 1511 OS Build 10586.xx) computers that boot on a private network after previously booting from a public network that has access to SSL time servers on the internet incorrectly reverts to a previous date and time

    This defect is resolved in the RS1 release of Windows 10. A resolving fix could be backported to TH2 with a support case opened by a Premier customer but no one has pursued that yet

    Workaround 1:

    Once the machine is connected to the non-internet accessible network follow these commands, omitting the portion inside parenthesis:
    1. Net stop w32time (stop Time Service)
    2. W32tm /unregister (unregister Time Service)
    3. W32tm /register (register time service)
    4. W32tm /start (starts Time Service)
    5. W32tm /resync /force (Force sync the time ignoring the time delta between internal NTP/NT5DS server and the client)

    Workaround 2:

    The issue clears itself when the client machine connects to the internet. This may not always be possible, in which case the previous workaround should work.

    Friday, March 25, 2016 6:32 PM

All replies

  • Hello
    Try these.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time

    In the command prompt, type W32TM /resync, and then press ENTER

    In the command prompt, type W32TM /query /status, and then press ENTER.

    if resynchronizing the time clocks manually does not resolve the issue, you can adjust the local computer's MaxAllowedPhaseOffset value in the registry under the following path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config.

    Regards,

    RR

    Tuesday, February 23, 2016 11:31 AM
  • I have compared the registry of a Vanilla Windows 10 1511 image with a modify Windows image and the only noticeable difference are the following keys,

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits]
    "SecureTimeConfidence"=dword:00000008
    "SecureTimeEstimated"=hex(b):91,cc,ac,36,f8,6a,d1,01
    "SecureTimeHigh"=hex(b):91,34,71,98,00,6b,d1,01
    "SecureTimeLow"=hex(b):91,64,e8,d4,ef,6a,d1,01
    "SecureTimeTickCount"=hex(b):70,11,01,00,00,00,00,00

    When I set the key "SecureTimeConfidence" value to 0 the issue doesn't come back again. I am unable to find any information about the key online, due to this I have spent the last two days recreating the image from fresh hopefully the issue will not come back. 

      

    Daniel Wingfield

    Thursday, February 25, 2016 10:53 AM
  • Hi Dan Wingfield,

    I am glad the issue has been resolved yourself and thanks for updating.

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Friday, February 26, 2016 9:10 AM
    Moderator
  • Hello Daniel

    I have the same Problem. I haven't found the root cause but when I deploy the MS WIM file with ConfigMgr the value of SecureTimeConfidence will stay on 0. If I deploy the same WIM with MDT the value is changed to 8. This change is done during the Windows Setup. Directly after the Setup has finished the value is already changed. I tried it als with the same unattend files but the problem persist. I use the same Hyper-V virtual MAchine for both tests. The resync Command does not solve the problem. With a "w32tm /unregister" and "w32tm /register" the keys will be recreated(With value of 0) and the timesync will work correctly.

    It would be great if Microsoft will publisgh some information about these keys and what setting will change them during Windows Setup.

    Regards

    Thomas


    Cheers,

    Thomas Kurth
    Netree AG, System Engineer
    Blog: http://netecm.netree.ch/blog | Twitter: | LinkedIn: | Xing:
    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, March 01, 2016 10:25 AM
  • I can confirm that the SecureTimeConfidence registry key was the issue for an Windows 10 image a colleague built and passed on to me. Setting it to zero fixed a time reset problem.

    Byron Wright (http://fieldnotes.conexion.ca)

    Tuesday, March 01, 2016 11:11 PM
  • Bryon, I have just stumbled across your blog post that describes the exact issue we are currently having with our custom Windows image. http://fieldnotes.conexion.ca/2016/03/windows-10-time-synchronization-and.html.

    Doing a couple of tests by setting the Value to 0, this does resolve the issue.


    Daniel Wingfield




    Wednesday, March 02, 2016 11:31 AM
  • Yes it resolves the issue, but why is this value set? That would be interesting...

    Great Blog Bryon!


    Cheers,

    Thomas Kurth
    Netree AG, System Engineer
    Blog: http://netecm.netree.ch/blog | Twitter: | LinkedIn: | Xing:
    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Wednesday, March 02, 2016 11:45 AM
  • Yes, I'd love to see some documentation on this. I have an eval version of Win 10 with a value of 0x7 and our VMs with a value of 0x6.

    I looked in WSIM (Windows System Image Manager) and there are no time provider settings that I can see for answer files. I also checked the local group policy in Windows 10 and don't see any settings that have been added for those new registry entries. I was hoping the local GPO might have a description.


    Byron Wright (http://byronwright.blogspot.ca)

    Wednesday, March 02, 2016 9:41 PM
  • Having encountered same, here is what I've learned.

    There is a known bug where system time on domain joined Windows 10 computers Version 1511 OS Build 10586.xx) computers that boot on a private network after previously booting from a public network that has access to SSL time servers on the internet incorrectly reverts to a previous date and time

    This defect is resolved in the RS1 release of Windows 10. A resolving fix could be backported to TH2 with a support case opened by a Premier customer but no one has pursued that yet

    Workaround 1:

    Once the machine is connected to the non-internet accessible network follow these commands, omitting the portion inside parenthesis:
    1. Net stop w32time (stop Time Service)
    2. W32tm /unregister (unregister Time Service)
    3. W32tm /register (register time service)
    4. W32tm /start (starts Time Service)
    5. W32tm /resync /force (Force sync the time ignoring the time delta between internal NTP/NT5DS server and the client)

    Workaround 2:

    The issue clears itself when the client machine connects to the internet. This may not always be possible, in which case the previous workaround should work.

    Friday, March 25, 2016 6:32 PM
  • There is now a KB article about this:

    https://support.microsoft.com/en-us/kb/3160312


    Byron Wright (http://byronwright.blogspot.ca)

    Thursday, June 09, 2016 12:44 PM
  • This problem is apparently fixed in with Anniversary Edition release of Windows 10. Another article has been released describing Secure Time Seeding:


    Byron Wright (http://byronwright.blogspot.ca)

    Thursday, September 29, 2016 1:42 PM