I have a Windows Server 2008 Domain Controller running on a VMware virtual machine. There is a Best Practices Analyzer warning appearing in Server Manager with the following message:

"The domain controller ... should comply with the recommended best pratices guidelines because it is running on a VM."

My question is merely related to clearing the warning. We are aware of the best practices guidelines and I believe we are following them. I don't see any specific tasks to perform which would clear the warning.

Do I need to just exclude the warning from the BPA scans, or will it clear automatically when I do something that brings the machine into compliance with the guidelines?

  • 2
    What do you mean by "Primary Domain Controller?" There haven't been PDCs since Windows NT4. – MDMarra Sep 30 '11 at 18:30
  • It has the PDC emulator role, as well as others. I don't think the "Primary" part of it is really relevant either way. Just old terminology that's never gotten out of my system. – J.W. Mosley Sep 30 '11 at 18:52
  • Is it possible to track which requirement exactly isn't satisfied? – Anatolii Reva Feb 10 '12 at 15:48

I don't think it's complaining just because you are running the DC in a VM. It's complaining because there are specific additional configuration steps you have take when running a DC in a VM, not only for the DC itself, but also on the host machine and hosting hardware. It detects that you didn't do one of them.


Short Answer:

Excluding that test is probably your best bet.

But... (Long Answer:)

Honestly you are begging for problems if you're running a production environment on a VM DC (esp if it has the PDC Emulator role).

I answered similarly here: Domain controller not advertising as time server / PDC role is down (in the post and comments.)

Active Directory is very reliant on the time. Regular physical system clocks have the potential to be erratic enough (especially in places with poorly-conditioned power, high electrostatic noise, or even just faulty hardware), that when adding a software-layer-pretending-to-be-hardware, time itself gets 'sloppy'.

While taking a Quantum Leap as a person might be cool, it makes Active Directory angry.

When recommending site setups, I start with two physical DCs at the main site. (For resiliency.) From there they may be supplemented with VM DCs at that site. If you have other sites that warrant DCs on-premises, I start with one Physical DC (optionally supplemented with DCs). The VMs are not to have the major FSMO roles, but I typically make everything a GC. The VMs are only there to help handle load if the physical DCs are overloaded.

  • 1
    Time synchronization in VM's isn't that challenging. Lots of best practices on VMware's site. All of our Windows 2003+ VMs (and yes, some are DCs) keep offsets of less than 30 ms when running on VMware ESX. Been doing it that way for years. You might need to tweak some of the Windows Time Service defaults via Group Policy to increse the correction frequency and rates if you have overloaded VMware host machines. We do monitor time offsets just in case though. – rmalayter Sep 30 '11 at 20:29
  • I'm not in a Windows shop currently, but previously (up until about a year ago) even following Microsoft's and VMware's best-practice recommendations we would catch problems in monitoring. – gWaldo Sep 30 '11 at 20:32
  • -1 - All of the time sync issues I've run across for DCs in virtualized environments have been config related issues to MS or the Hypervisor as rmalayter said. Skipping the check isn't an answer. Understanding why the BPA is identifying that check as a flag is a better answer. If you are seeing that item, then your virtualized DC is in a precarious state -- that is, it might not be causing issues NOW but the check is there because there are KNOWN cases where one of the characteristics identified in the TechNet article will cause problems -- fix it or roll the dice. – thepip3r Nov 3 '15 at 5:02

I think the following recommendation is probably what's tripping it but we've never followed this recommendation and never had any serious issues. We do however use write protective hardware, battery backed raid controllers and such,

"To ensure durability of Active Directory writes, do not deploy a virtual domain controller’s database files (the Active Directory database (NTDS.DIT), logs and SYSVOL) on virtual IDE disks. Instead, create a second VHD attached to a virtual SCSI controller and ensure that the database, logs, and SYSVOL are placed on the virtual machine’s SCSI disk during domain controller installation"
Source: Virtualization deployment practices to avoid on technet.microsoft.com

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.