I also would like clarification on the very last bullet regarding SCSI disks on the VM running as a DC. I used SCSI disks for the NTDS DB and Logs, and of course I am getting warnings in the Event Logs about write caching being enabled, which I cannot disable on the virtual SCSI disks. Can I ignore these warnings?

Thanks.

There's some implicit assumptions being made when advising that host time synchronisation be disabled for domain controller VMs that need to be called out. Specifically that the PDC Emulator at least needs an external time source configured, and that other domain controller VMs will need a manual time set performed when the drift exceeds the "Maximum tolerance for computer clock synchronization" Group Policy setting (which should be bumped for virtualised DCs IMO).

If your Hyper-V hosts are part of the same domain where all the domain controllers are virtualised, then you will run into constant time drift issues if the domain hierarchy is used as a time source, with and without the PDC Emulator using an external NTP server. This is due to the step-wise updates that occur when syncing with the external NTP source(s) and the large variation in a clock tick for the VM, especially if it's running in a loaded environment with other VMs.

In my experience time updates are far more consistent when the Hyper-V hosts are each configured to obtain their time via external NTP servers (either an identical set, overlapping sets, or exclusive sets of NTP servers) and the domain controller VMs are configured to use the Hyper-V host time synchronisation BUT with the VMICTimeProvider disabled as a provider for W32Time. This then allows for the domain controller VMs to have their time adjusted to the locally NTP-synced time upon VM startup, so that W32Time has minimal clock drift before syncing with the domain hierarchy. Otherwise you will get isolated domain controllers when they start up with too much time variation from the PDC Emulator.

Can you please update the Time Service section to be far more explicit in the assumptions you're making regarding time synchronisation configuration if you're advising that host time synchronisation be disabled in the manner you suggest.

The final point on this article

Because ofthe nature of CPU thread splicing/sharing I dont feel relying on a service within the child partition/guest provides the best solution or most accurate time rseults and would recomend contrary to this tehcnet article. With a hypervisor host properly setup, using integration tools would provide much more accurate time with alot less drift overall, and would only require minor modification to the Domain Controller in order to function properly.

For those curious, the root problem is that the w32time service AND the Integration Tools attemptign to fix the clock on the child partition at the same time can cause abnormal swings in time in excess of 5 minutes which will break Kerberos and thus replciation/authentication for the DC and general annoyances all around. However, DCs (along with other roles out there like cluster services) require the w32time service to be running.

The better fix is to modify HKLM/System/CurrentCOntrolSet/Service/W32Time/Parameters/Type and change it from "NT5DS" to "NoSync" so that the time server still participates as a valid time source but doesn't attempt to actually synchronize time, trusting it's clock and thus the Integration Tools. Then you simply modify your Hypervisor to use a reliable source and not Domain Time (to prevent a possible time-lookup loop).

Doing it this way is only slightly more involved than clearing a checkbox in integration services but puts an RTC back into the equasion and thus creates MUCH more reliable time less succeptible to drift due to over-subscribing your CPUs on the host.

At the minimum this should be listed as an option IMO.

==============
It seems that this comment and recommendation is based on the assumption that the domain controllers hosted on the virtual server as well as the virtual server are all part of the same forest and need to be synchronized to a single common clock. If that is indeed the case, configuring the time service as discussed here seems like it would work. However, the product team wants our documentation to recommend that the domain controllers synchronize their time from only the domain time hierarchy and not the virtual host. This prevents a time drift from a virtual host from causing infrastructure time drift issues (as those cited previously). Also, if you contact Microsoft Customer Support Services (CSS) and a time issue appears to be a suspect related to an issue you are having, they will likely tell you to disable host integration services and synchronize with the time hierarchy (as recommended by the product team).

If you have technical questions related to the subjects covered in this document, you can pose your questions at the Microsoft forums. The two Microsoft forums related to the subject material covered in this document are:



http://social.technet.microsoft.com/Forums/en-US/winserverDS

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv

Why not? Does this mean that a Hyper-V virtualized domain controller cannot be run within the context of a Hyper-V failover cluster?

[tfl - 12 06 09] Hi - and thanks for your post.You should post questions like this to the Technet Forums at http://forums.microsoft.com/technet or the MS Newsgroups at

http://www.microsoft.com/communities/newsgroups/en-us/. You are much more likely get a quick response using the forums than through the Community Content. For specific help about:
Exchange : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.exchange%2C&;;
SQL Server : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.sqlserver%2C&;;
Windows : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.windows%2C&;;
Windows Server : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.windows.server%2C&;;
Virtual Server : http://groups.google.com/group/microsoft.public.virtualserver/topics?lnk
Full Public : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public%2Co

Response from Kurt Hudson: No, that is not what is meant by not using the export feature. The export feature is used for migrating virtual machines from one server to another. This could also be used to essentially create a copy of the VM. This can lead to duplicates and USN rollback. A cluster is a different story. A cluster is supposed to include different machines (different security identifers and Active Directory database identifiers). There are some important issues to consider if you are planning to cluster domain controllers, which are discussed in article 281662 in the Microsoft Knowledge base (http://support.microsoft.com/default.aspx/kb/281662). /KurtHudson