Welcome to Dirteam.com/ActiveDir.org Blogs Sign in | Join | Help

The things that are better left unspoken

a blog by Sander Berkouwer

Related

AD Manager Plus
 

Blog roll

News



Archives

Active Directory in Hyper-V environments, Part 1

Virtualization offers huge benefits in flexibility, cost-effectiveness and eco-friendliness. However, some design choices need to be made towards deploying Active Directory Domain Controllers in virtual environments. Some of these choices are general choices, but some of them apply to Hyper-V enabled environments specifically.

When deploying an Active Directory environment, either for test or production purposes, either virtual or physical, be sure to deploy at least two Domain Controllers per Active Directory domain, whenever possible. When either Domain Controller fails you don't lose your Active Directory information and any applications, services and users depending on it can continue to operate, unless specifically pointed to.

   

To virtualize or not

You could opt to deploy both Domain Controllers as virtual machines. Other choices would be to deploy one or both Domain Controllers as non-virtualized machines.

Note:
When you deploy your Domain Controllers in virtualization software not validated in the Windows Server Virtualization Validation Program you may be forced to recreate your Domain Controllers as non-virtualized machines when you need to troubleshoot problems with the assistance of Microsoft Product Support Services (PSS) and don't have a Premier-level support agreement.

Single points of failure

When you place one Domain Controller on one Virtual Host and place the other Domain Controller on another Virtual Host you rule out the Single Point of Failure (SPoF) that is apparent when you use a single Virtual Host, It won't protect you against failures in the virtualization platform though.

Failures of the virtualization platform

When you deploy all your Domain Controllers virtually you place your faith in your virtualization software vendor: When your virtualization vendor screws up (example here) you won't have any available Domain Controller, since all your Domain Controllers resided inside your virtualized environment.

Scheduled outages

With two hosts or Hyper-V fail-over clustering you can update and restart one Virtual Host while the other host still offers a virtualized Domain Controller. This protects against misconfigurations and defects to one of the hosts, but it won't help you against scheduled outages and wide power failures though. The latter may be circumvented by investing in long-term uninterruptible power solutions, (mostly diesel-powered) but this isn't an option for everyone.

     

Parent partition as DC

In scenarios with Windows based Virtual Hosts you can opt to make your Virtual Host (in Hyper-V terms: your Parent Partition) an Active Directory Domain Controller as well.

Architectural point of view

From on architectural point of view this is not a desired configuration. From this point of view you want to separate the virtualization and platforms from the services and applications. This way you're not bound to a virtualization product, a platform, certain services or applications. Microsoft's high horse from an architectural point of view is the One Server, One Server Role thought, in which one server role per server platform gets deployed. No need for a WINS server anymore? Simply shut it down...

The Windows Server 2008 Enterprise Edition SKU allows you to deploy unlimited virtual Windows Server 2008 machines per physical processor, which makes it ideally suitable for these scenarios.

Performance point of view

From a performance point of view it doesn't matter whether you install your Domain Controller in the Hyper-V parent partition or in a Hyper-V child partition, since virtualization is about effectively using processor power and RAM.

Creating the Domain Controller as a Virtual Guest ("child partition") on the other hand allows you to edit the RAM and Disk settings when your environment changes and gives you more flexibility.

      

Recommendations

In a Hyper-V environment I recommend placing one Domain Controller per domain outside of your virtualized platform and making this Domain Controller a Global Catalog. (especially in environments with Microsoft Exchange)

Note:
Microsoft recommends you locate critical server roles on domain controllers that are installed directly on physical hardware. These include Global Catalog servers, Domain Name System (DNS) servers, Flexible Single Master Operations (FSMO) roles and replication bridgeheads

The normal Best practices for securing access to Domain Controllers applies to both these systems. (VHD files of running Domain Controllers need to be secured as well as physically running Domain Controllers.)

Note:
Be sure that only reliable and trusted administrators are allowed access to the Domain Controller VHD files. Create a folder for storing all virtual machine domain controller files  and assign permissions to the folder that contains the files so that only domain administrators  and the service account for your Virtualization software have access to the folder. Audit Read\Write access to the folder and monitor the security logs for unauthorized access attempts.

Server Core installations of Windows Server 2008 are perfect candidates for these Domain Controllers, since they don't require much resources and offer native console security since most of the graphical user interface isn't available.

You might opt to reuse abandoned hardware without support from the hardware vendor for this purpose. Alternatively you can use a different virtualization platform when you need a lot of Domain Controllers.

Related DirTeam posts

Installing Server Core Domain Controllers 
Virtualization - is it only a sweet? 

Further reading

Active Directory Best practices: Active Directory 
Best Practice Active Directory Design for Managing Windows Networks 
Support policy for Microsoft software running in non-Microsoft virtualization software
Download details: Running Domain Controllers in Virtual Server 2005
Download details: Hyper-V Planning and Deployment Guide
Considerations when hosting Active Directory domain controllers in virtual environments
Running a Domain Controller as a Virtual Machine 
Is domain controller virtualization really a good idea? 
Halfbaked ideas: A virtual domain controller 
Virtualisation, Time Sync & Domain Controllers 
Domain controller virtualization
Microsoft TechNet Forums: Domain Controller in Hyper-V and std core... 
Microsoft TechNet Forums: Hyper-V Blue Screens the host OS (Beta 1 timeframe)
Microsoft TechNet Forums: Connecting Host to AD running in Hyper-V
Microsoft TechNet Forums: Hyper-v as DC  
Petri.co.il Forums: Run domain controller as a guest OS or host?

Posted: Wednesday, August 13, 2008 7:06 PM by Sander Berkouwer

Comments

PEPE101de said:

Hi Sander,

the issue of disaster recovey a virtualized domain controller has an important consequence. As you probably know, only one restore from the VHD file is not enough.

regd

SBL - Steffen Brendler

# August 14, 2008 6:11 AM

Sander Berkouwer said:

Hi Steffen, Thank you for your reply. In part 2 of this series I will look at virtual Domain Controllers do's and don'ts. Correctly backing up and restoring virtual Active Directory Domain Controllers is part of it of course.
# August 14, 2008 6:43 AM

cwegener said:

Hi Sander,

Great series!

In part one, the note about non-Microsoft virtualization platforms should probably be updated to refer to non-SVVP products.

Cheers,

Christoph Wegener

# September 23, 2008 3:24 PM

Sander Berkouwer said:

Thanks for the heads up, Christoph!

I'm always pleased when readers and co-bloggers have meaningful additions to my posts.

I've updated the post to reflect the changes to this policy from Microsoft Knowledgebase article 897615. (released two weeks after this blogpost was posted)

# September 24, 2008 7:40 AM

Schweizer IT Professional und TechNet Blog said:

Nachdem Hyper-V nun verfügbar ist, sind einige Anfragen bzgl. dem "korrekten Sizing" von Virtualisierungsumgebungen eingegangen. Nachfolgend finden Sie eine erste kurze Uebersicht von momentan verfügbarer Guidance.

Unterschiedliche Guidance für Windows Server 2008 Workloads wie AD und weitere sind Teil der WS deployment guidance:

  • Considerations when hosting Active Directory domain controllers in virtual environments.
  • Active Directory Best practices: Active Directory
  • http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2008/08/13/active-directory-in-hyper-v-environments-part-1.aspx
# September 26, 2008 7:12 AM

TrackBack said:

Nelle scorse settimane mi si è presentato più volte il problema di disegnare una corretta implementazione di diversi workload in macchine virtuali su Hyper-V.

Così mi sono messo a cercare delle linee guida/tool sull’argomento, che non è sempre semplice da affrontare.

Qui sotto trovate una piccola raccolta di quanto ho trovato.

Al momento non esistono ancora delle linee guida per l’implementazione di SQL Server su Hyper-V, ma so che il team di prodotto ci sta lavorando.

Se voi avete trovato altre linee guida che mi sono sfuggite, segnalatelo che provvederò ad aggiungerle (assicurando i credits).

# October 8, 2008 11:37 PM

TrackBack said:

Dette er en kort beskrivelse af de ting man skal være opmærksom på, når man kører sine Domain controllere i et virtuelt miljø.
Administrer den virtuelle dc’ere, som havde det været på en fysisk server. Det betyder følgende:
Sikre at du kører på godkendt/supporteret hardware.
http://www.windowsservercatalog.com/default.aspx
Sæt aldrig den virtuelle DC i save state
Sæt aldrig den virtuelle DC i pause state
Brug ikke “undo disk” kommandoen
Udfør ikke snapshots backup, kør i stedet en almindelig system state backup med en agent installeret i guest systemmet.
Vælg “Shut Down” under “automatic stop action”.
Fravælg at lade Hyper-V hostmaskinen synkronisere tiden ud til de virtuelle guest. Det er især vigtigt for den DC’er der PDC emulator.

Reference til ovenstående:
Active Directory in Hyper-V environments, Part 1
Active Directory in Hyper-V environments, Part 2
Active Directory in Hyper-V environments, Part 3

Considerations when hosting Active Directory domain controller in virtual hosting environments
http://support.microsoft.com/kb/888794

# October 14, 2008 11:10 PM

AD Doc Team said:

Microsoft has published guidance on this topic at http://technet.microsoft.com/en-us/library/dd363553.aspx

# February 6, 2009 9:29 AM

Tim Anderson’s ITWriting - Tech writing blog » Mixing Hyper-V, Domain Controller and DHCP server said:

My one-box Windows server infrastructure is working fine, but I ran into a little problem with DHCP. I’d decided to have the host operating system run not only Hyper-V, but also domain services, including Active Directory, DNS and DHCP. I’m not sure this is best practice. Sander Berkouwer has a useful couple of posts in which he explains first that making the host OS a domain controller is poor design:

From an architectural point of view this is not a desired configuration. From this point of view you want to separate the virtualization and platforms from the services and applications. This way you’re not bound to a virtualization product, a platform, certain services or applications. Microsoft’s high horse from an architectural point of view is the One Server, One Server Role thought, in which one server role per server platform gets deployed. No need for a WINS server anymore? Simply shut it down…

Next, he goes on to explain the pitfalls of having your DC in a VM:

Virtualizing a Domain Controller reintroduces possibilities to mess up the Domain Controller in ways most of the Directory Services Most Valuable Professionals (MVPs) and other Active Directory enthusiasts have been fixing since the dawn of Active Directory.

He talks about problems with time synchronization, backup and restore, saved state (don’t do it), and possible replication errors. His preference after all that:

In a Hyper-V environment I recommend placing one Domain Controller per domain outside of your virtualized platform and making this Domain Controller a Global Catalog. (especially in environments with Microsoft Exchange).

Sounds good, except that for a tiny network there are a couple of other factors. First, to avoid running multiple servers all hungry for power. Second, to make best user of limited resources on a single box. That means either risking running a Primary Domain Controller (PDC) on a VM (perhaps with the strange scenario of having the host OS joined to the domain controlled by one of its VMs), or risking making the host OS the PDC. I’ve opted for the latter for the moment, though it would be fairly easy to change course. I figure it could be good to have a VM as a backup domain controller for disaster recovery in the scenario where the host OS would not restore, but the VMs would – belt and braces within the confines of one server.

# February 8, 2009 10:32 AM

How can a small business set up a domain (hardware questons). | keyongtech said:

SBS is in my opinion the best solution. Exact made for your needs. If users
access a data share on another drive, it will be also ok. So they do not
access any part of the OS, just a file share.

If you still will not use SBS, install 2008 with hyper-v and create a physical
DC on it, then install the other servers as VM. But the underlaying hardware
should need powerful processors and you need lot RAM, in my opinion minimum
12GB, 4 for each machine.

For installing DC on VM have a look here.

# March 6, 2009 1:08 PM

Windows 2008 Hyper V - MCSEboard.de MCSE Forum said:

Hallo. Auf einem Server habe ich Windows 2008 und die Rolle Hyper V installiert. Der Server hat XEON Prozessoren, 16 GB...also genug Power.

Nun will ich diverse Systeme virtualisieren. Kann der Host trotzdem der DC sein? Der langweilt sich ja sonst...
# April 1, 2009 11:11 AM

The things that are better left unspoken said:

Designing and implementing a virtual environment on top of Hyper-V can be challenging. In the first four

# April 21, 2009 12:52 PM

Arņa piezīmes said:

Vēlamies virtualizēt domeina kontrolierus? Laba ideja! Tomēr ir dažas lietas, kuras ir jāizlasa un jāsaprot par virtuālo vidi un kā AD kontrolieri tur uzvedīsies.

Informācijas izklāstu sāksim ar šo oficiālo Technet rakstiņu:
Running Domain Controllers in Hyper-V
Šajā rakstā atradīsim plānošanas, ieviešanas un darbības apsvērumus.

Tomēr paliek vēl nianses par kurām būtu nepieciešams padomāt un iespējams plānošanas laikā var ieviest izmaiņas, lai izvairītos no iespējamajām problēmām, kuras aprakstītas šajā rakstu sērijā:

Active Directory in Hyper-V environments, Part 1
Active Directory in Hyper-V environments, Part 2
Active Directory in Hyper-V environments, Part 3
Active Directory in Hyper-V environments, Part 4
Active Directory in Hyper-V environments, Part 5

# July 8, 2009 2:10 AM

SW-IT Internal Procedures » Blog Archive » Why Configure an External NTP Server on an Active Directory Domain? said:

Having all machines on a same domain with the time synchronized by a unique server is crucial for several reasons. Just to mention a few:

  • Security matters: Ensure security of Kerberos authentication within Active Directory environment. To prevent replay attacks, Kerberos tickets presented to domain controllers by clients are time-stamped. The authenticating domain controller checks to make sure the timestamp is unique and falls within an allowable skew before accepting the ticket and authenticating the client. To ensure this system works properly, both the client and the domain controller clocks must be loosely synchronized within the allowable skew, and W32Time ensures this is the case.
      
  • Several services that can be used within a domain depend that the time service on all participants is synchronized, otherwise several issues or malfunctions may appear.
      
  • Logging options within a domain service (for example source control) will have inconsistent and incorrect data on their records if the time is not properly synchronized.

The server that provides the Time Synchronization for the whole domain is the Domain Controller that holds the PDC FSMO role.

With all that been said, there are common best practices about using domain controllers on a virtualized environment. One of them is that the virtual machine must never enable the feature of host time synchronization (option that sets the virtual machine clock that automatically syncs with the physical host where is located). See sources below.

The best practice regarding about using virtual domain controllers (as well as physical domain controllers) is that the server must be configured with an external time service provider, to prevent that any related issue (regarding to virtualization platform, physical host or hardware issues) gets involved on the time synchronization of a whole domain or forest.

There are several external servers that can be configured on a domain controller to guarantee that proper time synchronization is offered always. Example: tock.usno.navy.mil.

# September 30, 2009 10:52 AM

John Policelli's Blog » Blog Archive » Active Directory in Hyper-V Environments said:

There’s no doubt that virtualization is hot these days. The following articles, posted on the Dirteam.com Blog, will answer virtually all (no pun intended) questions that you have when it comes to Active Directory in Hyper-V environments.

  • Active Directory in Hyper-V environments, Part 1
  • Active Directory in Hyper-V environments, Part 2
  • Active Directory in Hyper-V environments, Part 3
  • Active Directory in Hyper-V environments, Part 4
  • Active Directory in Hyper-V environments, Part 5
  • Active Directory in Hyper-V environments, Part 6
# October 27, 2009 4:48 PM

Active Directory in Hyper-V environments said:

Encontrei por aí, fica a dica de leitura para os interessados no tema.

  • Active Directory in Hyper-V environments, Part 1
  • Active Directory in Hyper-V environments, Part 2
  • Active Directory in Hyper-V environments, Part 3
# July 15, 2010 7:59 PM

Active Directory in Hyper-V Environments. | Alex Silva said:

Encontrei essas dicas em blog muito interessante, fica a dica de leitura aos interessados no tema.

  • Active Directory in Hyper-V environments, Part 1
  • Active Directory in Hyper-V environments, Part 2
  • Active Directory in Hyper-V environments, Part 3

Alex Silva

# October 19, 2010 12:46 AM
Anonymous comments are disabled