Surface Go time issue

Question

We are currently seeing an increase in Surface Go devices that have timing issues. We are on EST, some are behind by only a couple of hours, others are a full 24hrs. This is a big problem when students have to take tests and can't access their content due to the time being off. Has anyone else experienced this and have they been able to fix the issue, not by simply syncing the time but fix it completely?

Troubleshooting included: data erase and reimage.

Your help is appreciated.

Answer 1

Settings → Time & Language → Date & Time

Make sure:

Correct Time Zone

“Set time automatically” ON

“Set time zone automatically” OFF

Open Command Prompt as Admin and copy-paste the following:

w32tm /unregister

w32tm /register

net stop w32time

net start w32time

w32tm /resync /force

Answer 2

The behavior described matches known Windows time issues where devices can drift by hours or even a full day, and the problem returns even after manual sync or reimage. Two areas are especially relevant:

1. Secure Time Seeding causing rollbacks
2. Time zone/DST configuration problems

On Surface Go devices joined to a network, incorrect time can break authentication and access to resources (including test platforms), so the goal is to remove the root causes, not just resync.

Actionable steps to fix it more permanently:

1. Verify time zone and DST configuration
   • On each Surface Go, go to Settings > Time & language.
   • Confirm the correct time zone for Eastern Time is selected.
   • Ensure any DST settings are correct for the region.
   • Misconfigured time zone or DST can cause the clock to be off by one hour or more, and in some cases by a day when crossing midnight boundaries.
2. Address Secure Time Seeding–related rollbacks
   • Windows has a Secure Time Seeding feature in the Windows Time service that uses metadata from outbound SSL connections to estimate time.
   • If devices are restarted on networks with no outbound SSL traffic (for example, closed private networks in exam rooms), Windows can reuse stale Secure Time Seeding data stored in the registry and roll the clock back by at least one day.
   • This can override administrator-set time and cause:
     • Event log entries with timestamps in the past
     • Kerberos authentication failures
     • Students being unable to access time‑sensitive content
   • To mitigate this in an enterprise/education environment:
     • Ensure devices can reach a reliable NTP source (for example, domain hierarchy or a dedicated NTP server) when they start up.
     • Avoid scenarios where devices boot only on closed networks with no SSL and no time source.
     • In managed environments, consider centrally configuring Windows Time service to rely on your AD DS hierarchy or a specific NTP server and review Secure Time Seeding behavior as part of your standard image or GPO configuration.
3. Watch for large time rollbacks and their side effects
   • Large time jumps (hours or days) can cause:
     • Password and trust relationship issues
     • Replication problems in AD environments
   • If devices are observed to roll forward or backward significantly, review time service configuration and event logs (for example, Kernel‑General event ID 1) to confirm when and how the time is changing, then standardize configuration across all Surface Go devices.
4. Standardize and test on a reference device
   • Take one Surface Go, configure:
     • Correct time zone/DST
     • Reliable NTP source (domain or dedicated NTP server)
     • Network conditions that match exam rooms (including any closed networks)
   • Reboot multiple times and verify that the time remains correct without manual sync.
   • Once stable, replicate the same configuration (via imaging, Intune, or Group Policy) to all devices.

These steps move beyond one‑off manual syncs and target the underlying Windows time mechanisms that can cause recurring drift or rollbacks, which is critical in a testing environment.

---

References:

• Windows computer clock resets to a previous date and time
• How to configure the Windows Time service against a large time offset
• Incorrect time displayed on 64-bit versions of Windows 7 or Windows Server 2008 R2 after in-place upgrade
• Trouble installing Surface updates?

AI-generated content may be incorrect. Read our transparency notes for more information.