Hello,

We’ve been using Windows 10 in our public spaces for little over a year now with widespread use enacted over the summer. Adoption was positive. No one came out with torches and pitchforks as I had feared.

That is not to say we were not completely without issues. The strangest of which was a habit noticed by some users of the Windows clock, the one in the system tray, freezing or losing time. This became an issue when faculty were giving tests and using the PC’s clock to time the exam. Students were being shortchanged on the apparent time.

My first thought was to check the BIOS’ clock. I make sure that is right before I image the PC for the first time. There is a bunch of changes I make to a new PC before it is imaged and brought into service. The oldest machine exhibiting symptoms is just three years old. The CMOS battery should not be going yet. It’s possible, but not probable. As expected, all was fine.

The time zone is correct (EST vs. PST). Windows setup defaults to Pacific time (GMT -7:00) for Redmond, WA.

The computers can get their timing from one of several sources. By default, Windows 10 will try to sync with Microsoft’s time server (time.windows.com). Computers on a Windows active directory domain can get their time from the domain controller (DC) that holds the PDC Emulator FSMO (the first DC in the domain by default). A group policy object (GPO) can be used to control the complete operation of the Windows NTP client, including which server to use. Lastly, the option exists to inject the NTP settings directly into the registry.

I typically use a GPO to point our Windows clients to the university’s own NTP servers. Simple. To test NTP connectivity to the NTP server, execute the following in a command prompt.

w32tm /stripchart /computer:us.pool.ntp.org

The affected clients were all set to the correct time, and they were using the university’s own time servers, which I am positive are correct. What gives?

The Event logs on Windows were not showing any indicators of failure around the reported times the displays froze. Another thought was that the Crestron display systems we use in the classrooms was freezing the output to the monitor/screen as a power-saving measure of sort and thus not showing the clock’s progression. It wouldn’t be unheard of for Crestron to skew something in Windows. We’ve had numerous issues with audio output in these circumstances. I tested out the classroom Windows 10 image on identical hardware in my office sans the Crestron system and it the clock froze. Crestron cannot be the culprit, at least in this case.

So, despite my concerted attempts in every job I have ever held to not be a clockwatcher, I am in this case… To demonstrate and test for this issue, myself and others (if interested), log into a PC as a regular user and watch for the clock to not change when the time on our phones or watches does.

Is it the image of Windows 10 that we are using? Before deploying Windows and software to our classroom computers, we perform a heavy series of changes to ensure that everything works and that an instructor will get the exact same computing experience no matter which classroom from which they are teaching. Profile customizations…

I took a classroom computer (Lenovo M93/M900 “Tiny”) and installed Windows 10 on it from the Microsoft ISO. I then used our endpoint management software to install most of the software we use in the classrooms. Some titles are too big to be deployed in this manner. I’m writing about you MATLAB and you SAS. This all took about a day with little input from me. I joined the domain, placed the computer in the same OU as the rest of the classrooms and logged in as a regular user. No clock changes. The time kept up in the task bar until our auto-logoff settings took effect.

So, it is the image? The next question is what in the image is the problem? The list of customizations and changes we make is several pages long and gets smaller every year. We use a domain-based group policy to provide the overall configuration profile to classroom users. From the desktop environment to power settings and everything in-between group policy is the driver of the end result. Local GPOs are helpful, but not in examples of mass-deployment. The only thing we set in the local GPOs are those that we are certain we will never ever need. The truly onerous, useless features or settings that Microsoft includes for who knows what reason. That approach takes a great deal of work and testing to achieve a reliable and desired state configuration.

The version of Windows 10 we piloted in a couple of computing labs, initially was the first RTM version (1507). No problems aside from UI issues some users did not like. When taking Windows 10 to the next level, our 200+ classrooms, Windows 10 “Anniversary Update” (1607) was the latest available in Microsoft’s Software as a Service design (SaaS). Our pilot encompassed two labs of about sixty computers in total. If there were a time-related issue, I am sure I would have heard about it at some point.

Either way, where it stands now the problem IS with Windows 10 Enterprise x64 1607 and group policy for our domain. I’ll update with more information when it becomes available.