Is domain controller virtualization really a good

idea?
Editor's note: For the latest on domain controller virtualization, check out Gary's follow-up article
on virtualizing Ds from !une "#$#%
Server virtualization has received increased attention from IT managers who see it as a way to
stretch their already thin budgets. Getting one machine to act like and do the work of two or more
machines is a really powerful tactic and one that is gaining popularity for application servers. With
virtualization software supporting 6!bit platforms and soon to be supporting I"!6 Itanium
microprocessors# the limits may be e$panding !! and that%s good news for IT managers.
In general# virtual application servers are working &uite nicely# but many IT managers are also
e$ploring the idea of virtualizing domain controllers '()s*. That enthusiasm# however# leaves the
administrator with several unanswered &uestions+ Is it really a good idea to virtualize domain
controllers, What are the ramifications, (oes -icrosoft support it,
Microsoft's view of domain controller virtualization
-icrosoft has published a white paper# .unning (omain )ontrollers in /irtual Server 0112# as well
as 34 article 55567# entitled 8)onsiderations when hosting "ctive (irectory domain controllers in
virtual hosting environments8 to address this issue. We can deduce that it is indeed possible to host
()s on virtual machines merely by the fact that these documents provide 89ow to8 guidelines for
accomplishing the task.
9owever# there are some very specific guidelines for virtual ()s. Some important points include+
.ecommended placements of virtual ()s include branch office sites with a
small population '01 or less*
.ecommendations for where not to place virtual ()s+
:. (on%t place them in locations where mission!critical services like
;$change re&uire a domain controller
0. (on%t use them to host <le$ible Single -aster =peration '<S-=* roles
>. (on%t use them as Global )atalogs for ;$change servers
. (on%t use them for bridgehead roles
Note: &his, of course, assumes the use of 'icrosoft's (irtual )erver product%
Ramifications of domain controller virtualization
In evaluating the feasibility of virtualizing any server role# it is important to note that the main
resources used on a busy () are ."- and (isk# which are also the two things that virtualization
isn%t the greatest for sharing. .emember that the ."- of the physical machine is divided up
between the host and the virtual machines# so physical ."- becomes a very critical resource. To be
sure# disk space is a big issue# especially if you make backups by saving snapshots of the virtual
machines. )?@ resources on ()s are usually a non!issue# yet they are the primary reason given to
Austify virtualizing servers.
I personally only know of a few companies that actually implement virtual ()s in production. <or
e$ample# there is one large global corporation with an "ctive (irectory architecture that is only
virtualizing 8Bag Site8 ()s 'See my tech target article ?reventing "ctive (irectory disaster+ The
replication B"G site*. This company does not virtualize all ()s because of possible IC=
bottlenecks. "nother issue is security. In a virtual server# since the domain controller is basically a
file# it could get saved and later mistakenly booted from that file# having the effect of an out!of!date
() coming back online and inAecting lingering obAects in the "(. =f course# that file can be
compromised# mistakenly deleted or even copied to steal data.
What about support?
"nother issue to keep in mind is supportability. (oes -icrosoft support virtualization of ()s if you
call for it, The answer is D it depends. "ccording to -icrosoft 34 article 5766:2# -icrosoft will
support ()s loaded on its /irtual Server product. 9owever# if you use ;-) )orp.%s /-ware
product 'which I prefer*# then the level of support will vary.
9ere are some other points to remember# according to 34 5766:2+
If you are not a -icrosoft ?remier Support customer# then you will have to
reproduce the problem on a single physical machine to remove the virtualization
software.
If you are a -icrosoft ?remier Support customer# then the company has said it
will make efforts to investigate any potential issues# but may still re&uire you to
reproduce it on a physical machine.
In other words# if you aren%t using /irtual Server# then all bets are off. Thus# when deciding whether
to virtualize your domain controllers# you must determine if you are prepared to live with this
support condition. "re you really willing to reproduce a critical error that is stopping replication and
affecting application of Group ?olicy on a separate machine rather than the one it is failing on, This
will obviously take time Aust to set up and you may never be able to repro the problem# which may
or may not be the fault of the virtualization software.
Best practices for virtualizing DCs
To summarize a few best practices for virtualizing ()s+
:. <ollow the guidelines in -icrosoft 34 55567 and the -icrosoft white paper
8.unning a (omain )ontroller in /irtual Server 0112.8
0. Start out by implementing virtual ()s in non!critical roles such as B"G ()s.
>. <ollow specific policies and procedures that detail backing up and physical
management of the backups of the files that comprise the virtual machines
including physical access to the host machine and disks.
. .emember that pausing a virtual machine or turning it off and then turning it on
again later will have the same effect as removing a () or Global )atalog from
the physical network. That is# starting it up again can inAect lingering obAects into
the "ctive (irectory.
2. -ake sure the host can handle the load 'IC=# memory# disk space and
performance*.
6. Eou will probably F;/;. want to put all or even a maAority of your ()s on
virtual machines. If you follow -icrosoft%s recommendation# you won%t
virtualize G)s that are used for ;$change# <S-= role holders or other roles
where performance is critical.
6. .emember the supportability issue. (o you really want -icrosoft to tell you that
you%ll have to install the () on a physical machine and reproduce the problem,
If you have a critical outage# it will make a bad situation even worse# forcing you
to add in the time to reproduce the problem to the problem!resolution time. I
don%t know how many times -icrosoft has re&uired a customer to do this# but it
is definitely worth considering.
"ny domain controller virtualization design should come with a great deal of analysis and testing.
While there are not a lot of case studies out there to prove or disprove many of the points made
here# it should be sufficient to convince any IT manager or administrator that virtualization of ()s
is possible and supported. Eour mileage may vary+ Implement it in very limited# non!critical roles#
and go from there.
AB!" "#$ A!"#R%
Gary Olsen is a systems software engineer for *ewlett-+ackard in Glo,al )olutions Engineering%
*e authored -indows "###: .ctive Directory Design and Deployment and co-authored -indows
)erver "##/ on *+ +ro0iant )ervers% Gary is a 'icrosoft '(+ for Directory )ervices and formerly
for -indows File )ystems%
http+CCsearchwindowsserver.techtarget.comCtipCIs!domain!controller!virtualization!really!a!good!
idea
"a&ing a second loo& at domain controller
virtualization
" while back I wrote an article about the then controversial issue of virtualizing domain controllers
'()s*. The big issue at the time was -icrosoft%s aversion to providing support for ()s hosted on
virtual machines for anything other than its own virtualization software# /irtual Server 0112. 4ack
then# -icrosoft re&uired admins to reproduce their ()s on physical hardware G something that is
pretty tough to do with domain controllers.
With the entire IT industry going fast and furious down the virtualization path and so much new
technology available# it seems appropriate to take another look at the issue of domain controller
virtualization.
The first thing to understand about virtualizing domain controllers is that you can%t treat a () as
you would any other serverH it isn't any other server. " domain controller is a key security
component in your infrastructure# and it simply plays by different rules than a member server
running applications.
=f course# you could make the argument that there is really no 8one size fits all8 method for
determining how a server can be virtualized. <or instance# you wouldn%t use the same criteria for
virtualizing ;$change Server that you would for SIB Server. Servers use different resources in
different ways# and they have different backup re&uirements and recovery methods. (omain
controllers are different for similar reasons.
!nderstanding the issues
The biggest argument to be made against virtualizing domain controllers involves security and
administration. Barge and medium!size companies will usually have different admins for "ctive
(irectory '"(* and server virtualization. Simply stated# you might not want the administrator for
the virtual server hosts to have "( domain admin rights and vice!versa.
In the "ctive (irectory world# it%s a best practice to limit domain admin rights to those who are
highly skilled and trusted. If these folks don%t have admin rights to the virtual server host that the
domain controller /-s run on# it may prevent them from a timely restore of the (). <or instance# if
the domain controller goes down# you must have access to the virtualization software%s console to
start it up or configure it. This right may be limited to virtualization admins.
There are many e$amples of crossing over security responsibilities# but you get the idea !!
implementing a domain controller as a virtual machine creates additional comple$ity.
"nother key component of virtualizing domain controllers involves backups. 4ackups for other
types of virtual servers can be accomplished by backing up /9( files# making snapshots of virtual
host machines# or taking and restoring images. These methods# however# don%t work when it comes
to backing up a domain controller.
-icrosoft 3nowledge 4ase article 55567 refers to this issue as @SF rollback# which is used
intentionally for authoritative restores. This works when the domain controller is properly backed
up# resetting the invocation I(. When the host machine creates and restores a virtual () from a
snapshot# however# it will not reset the invocation I(. Therefore this older set of data is not updated
and the problem domain controller is unable to tell other ()s that it is out of date in relation to
them# thus preventing replication.
This is very difficult to detect# as there are no events or errors that say 8We can%t replicate because
you have e$ecuted @SF rollback without resetting the invocation I(.8 The problem leads to
inconsistencies such as certain obAects being on some domain controllers and not others. The only
fi$ for this is to demote the problem () and re!promote it.
(on%t confuse this process with doing /olume Shadow )opy Service '/SS* backups within the
/-. I like "ctive (irectory e$pert Sean (euby%s statement that you should never do anything to a
virtual () that the () itself G and the directory service G isn%t aware of. <or instance# copying or
e$porting a virtual machine%s /9( is done on the host while the /- itself is unaware of what is
going on. I saw one scenario where there were two virtual domain controllers on different hosts. "s
a backup strategy# each night the admins would e$port the virtual machine from each () and store
it on the other. This is in violation of (euby%s rule described above. (oes the guest machine G the
() itself G know about this e$port and save, =f course notH therefore# it should not be done.
Instead# Aust back up the /- from within the /- and you%ll be fine.
Time synchronization is also an issue. System time in the virtual domain controller should not be
tied to the host. The host is not a ()# so why should it participate in the time services
infrastructure, =nly domain controllers% sync times are used as time servers. The primary domain
controller '?()* is the authoritative time server for the domain# so synching the host%s time service
to drive the domain controller%s time would circumvent the root () being authoritative for the
domain. Eou would not sync a physical () from two separate time sources.
The domain controller is a foundational element of the domain structure and it must stay running or
be able to boot up immediately if it does go down. It isn%t a big problem to pause a virtual () for a
short period of time# Aust like it isn%t a problem to shut a physical () off for a while. "s long as the
downtime is less than the tombstone lifetime period# it will properly replicate when it comes online
and get itself up to date. Ees# there will be complaints in the event log# but this can be done for
maintenance# reconfiguring resource settings for the /- and more# Aust as you would shut it down
for maintenance with a physical computer.
Wor&arounds for domain controller virtualization
In his blog# -icrosoft%s 4en "rmstrong offers some interesting options for resolving the security
and administration issues noted above# including how to make the host a standalone server and
creating a separate domain for the host. In the end# he suggests putting the host in the domain with
the virtual domain controller. 9e also makes some other e$cellent recommendations for virtual
()s+
:. )onfigure virtual ()s to start when the host 'parent* machine starts. .emember# the host
machine needs maintenance and updates# so that will add to the possibility of taking the
virtual () offline. This will make the domain controller start up without manual
intervention.
0. =ther virtual machines on the host that are not ()s should be configured to have a delayed
start time# giving boot priority to the virtual ()s. This provides resources for the virtual ()
that will help facilitate a faster boot.
>. )onfigure the virtual domain controllers to shut down without saving state if the host shuts
down.
. (omain admins should have a way to access the host machine and the virtualization
software%s console in case the () fails to start. This could be accomplished via an operator
who is physically near the host as well and can start it manually without needing "ctive
(irectory privileges. ' would also add the following suggestions%
2. (on%t put all of your virtual ()s on one physical host. I know of one admin who had two
domain controllers and built them as /-s on one host machine. The host had a disk go bad
and he lost both ()s# making recovery limited or non!e$istent. It%s better to spread them out
among multiple hosts for each domain.
6. Few advancements in virtualization technology will make domain controller virtualization
more attractive. 9yper!/ for Windows Server 0115 .0 S?: includes support for dynamic
memory and better connection support for ()s. 9ot!add memory and storage in 9yper!/
.0 allows for e$pansion of resources without re&uiring downtime.
6. @se common sense !! avoid single points of failure and make sure your backup and recovery
plan works. "lso# monitor performance to make sure the domain controller is handling the
load# Aust as you would for a physical server.
I%ve heard some discussion about the wisdom of putting all domain controllers on virtual machines#
or maybe leaving Aust one or two as physical machines. I have talked to one admin who said# due to
budget restraints# he was forced to virtualize all of his ()s. 9e has run them all on virtual machines
for several months and 'so far* has not e$perienced any trouble. I think most people want to hold on
to physical machines simply because they are comfortable with them.
So the takeaway here is that it is possible to successfully virtualize domain controllers# but you must
follow the best practices noted here and in the -icrosoft references to ensure success.
?erhaps someday we will feel comfortable in a completely virtualized "ctive (irectory
environment.
AB!" "#$ A!"#R%
Gary Olsen is a systems software engineer for *ewlett-+ackard in Glo,al )olutions Engineering%
*e authored -indows "###: .ctive Directory Design and Deployment and co-authored -indows
)erver "##/ on *+ +ro0iant )ervers% Gary is a 'icrosoft '(+ for Directory )ervices and formerly
for -indows File )ystems%
http+CCsearchwindowsserver.techtarget.comCtipCTaking!a!second!look!at!domain!controller!
virtualization