| Time Synchronization and VMware View |
|
|
|
| Written by Tom Hirt | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Saturday, 02 May 2009 10:34 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
View Cloning ErrorI recently did a VMware View (VDI) deployment (using linked clones) for a customer and came across a new error which took me quite a bit of time to get resolved: Windows cannot connect to the domain, either because the domain controller is down or otherwise unavailable, or because you computer account was not found. Please try again later. If this message continues to appear, contact your system administrator for assistance After deploying the pool, I would randomly receive the above error while attempting to login to the workstation. Initially, I had thought the issue was related to QuickPrep since QuickPrep does not generate new SID's for the cloned VM's. But after spending several hours investigating the event logs of my cloned workstations and domain controllers, I was able to determine that this issue (although indicating there was a problem with the computer account) had nothing to do with the VM's SID. In a domain, a computer's SID is almost irrelevant since domain accounts have SID's based on the domain's SID. Therefore, with a few exceptions, the only time a SID is really important is in a workgroup scenario where a workgroup might not be able to determine security based on the local accounts SID which was not the case here. I eventually discovered that although my ESX host had been configured with NTP (Network Time Protocol) support (acquiring its time from the customers domain controllers) time synchronization between the customers domain controllers were not in sync thus producing the above error. Since I could not find any related posts in the forms, I decided this issue was important enough to merit it's own KB in hopes this article might help someone else. Time Synchronization is best practice with any environment, especially within a virtual environment. When a virtual machine is first powered on, it sets the virtual machine's time (in the BIOS of the VM) to that of the time from the running ESX host. Assuming the virtual machine is part of a Windows domain, Windows will also attempt to synchronize the virtual machines clock with the domain so long as it's current time is within the drift policy of your domains NTP settings. Therefore, I find it best practice to synchronize each ESX host with the system's domain controllers and that your domain controllers are synchronized with a peer that synchronizes to an outside source. This will ensure not only accurate time throughout your domain, but that the VM's clock does not skew from the domains time, between the time they boot-up and the time they get logged into the domain. Lets take a quick look at how to configured NTP on ESX.
Configure NTP Settings on ESX
Verifying Domain Time Synchronization
Once your ESX servers and synchronized with your domain and all your domain controllers are synced with each other, after rebooting the affected virtual machine(s), you should have no further issues logging in with View. Good luck!
!joomlacomment 4.0 Copyright (C) 2009 Compojoom.com . All rights reserved." |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Last Updated on Tuesday, 02 June 2009 11:22 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
