When booting a published machine (for instance, the template VM for MCS) the first time, the local time for Windows is wrong by hours. The timezone is correct, but the initial time is set incorrectly for that time zone.  This can break Windows and Office activation, and potentially cause other problems.

You can always manually set the time once the machine starts, but that might be a pain to remember to do every time you publish a new image.

The initial clock time in Windows on a physical machine comes from a battery-powered clock on the motherboard (called TOD for Time Of Day), which is set to the local time in Windows' current timezone.  In a virtual machine, the virtualized TOD clock is set by the hypervisor at bootup. Since hypervisors normally know the time in GMT rather than a local timezone, your hypervisor has to know what "local time" is for your Windows instance in your virtual machine before it powers on.  If the hypervisor doesn't know the conversion factor for the VM's local timezone, the initial time can be off by hours.  Hypervisors learn the machine's local time zone pretty quickly, but it means that the first boot for any VM is usually wrong.

In a published App Layering image, unless your template is derived from a VM that was originally a full Windows machine set to the correct timezone, the first boot usually has bad clock time.  However, if your Platform Layer was added to the domain, your published VM should also have the correct information for how to sync its clock with the Domain Controller.

So make sure your Platform Layer was joined to the domain, so it can immediately correct the clock discrepancy.

Otherwise, consider setting this registry key so that Windows will treat the motherboard clock as being in UTC rather than the local timezone:

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=DWORD 1

Some hypervisors store the local timezone offset for a VM as a virtual motherboard resource.  When Windows is running, every time it updates the clock time, it sets the motherboard resource to be the correct time.  This is how your hypervisor finds out what the timezone offset for this VM is: because Windows is always writing local time to the motherboard, all your hypervisor has to do is compare the motherboard resource for the TOD clock to the hypervisor's own clock.  That timezone offset is an attribute of the VM itself, not part of Windows and not part of the virtual disk.

For instance, in vSphere, the time-of-day offset can be set as a parameter in the VMX (or VMTX) file.  You can force the CMOS TOD clock’s offset to be initialized to a specific value at power on. To do so, set the option rtc.diffFromUTC in the virtual machine’s .vmx/.vmtx configuration file to a value in seconds. For example, setting rtc.diffFromUTC = 0 sets the clock to UTC at power on, while setting rtc.diffFromUTC = -25200 sets it to Pacific Daylight Time, seven hours earlier than UTC.

Note that Nutanix does not currently notice and record the time zone offset of a VM.  You would need to set it manually.  See this thread, for instance:

https://next.nutanix.com/installation-configuration-23/windows-vm-time-issues-22562

It may be worthwhile to generate a new template for your Connector, by having (or building) a Windows VM that has booted in the correct time zone.  If you have a template you want to continue using, for instance, convert it to a VM, attach a bootable Windows disk (or boot from PVS or something like that - it's just important that Windows run on this machine), power the machine on, and set the clock correctly.  When you adjust the clock, Windows writes it to the motherboard, and your hypervisor records the offset in the virtual machine parameters.  Then you can shut the machine down, remove any extra disks, and convert it back to a template. 



You can also just take a working Windows machine with a correct local time, shut it down, clone it, remove any extra disks, and convert that to a VM template.  This is one good reason to make a template out of a clone of your original Gold VM that you imported your OS Layer from: it already has all the virtual hardware parameters you want, including the local clock offset.  Now that your template includes the current timezone offset, your hypervisor will be able to set the initial motherboard TOD clock correctly, meaning Windows has the correct time immediately and doesn't need to wait for a jump when AD comes in to set the clock.

Configure your Connector to use this template so that newly published images will be correct.  If you are using PVS, you should also use this template to build your Target Machines so that the virtual hardware of your Target Machines matches the hardware your layers were built from, including the local timezone offset.

Note that it's also possible to have your hypervisor's internal clock wrong.  Also, your PVS server will try to set the machine's clock based on the PVS server's local clock.  If any of these are wrong, you will need to get them synched as well.