Derek’s Musings

You may be wondering if it’s a bright idea to install VMware Server on a Windows domain controller (DC). People may have told you it isn’t a great idea…and it isn’t. But the last time I checked most small businesses don’t have a coffer full of gold lying around, so sometimes us IT folk have to compromise and work with what we’ve got–more often than not a single server (often a DC) or at most two or three (personally I never recommend a single server setup, but there are plenty of them out there).

So…given maybe one or two servers, it’s going to be difficult to get everything running smoothly without a little virtual machine (VM) magic. Sorry folks–installing just about anything other than the built-in roles on a Windows server is opening up the possibility of conflicts, so let’s minimize that probability by installing only one third-party software that’s been hammered on by millions of companies: VMware Server. I think we’ll take our chances.

So what do we need to do to make things with VMware smoother? A few things:

• Evaluate and upgrade the hardware if necessary. Hopefully a $100 of RAM won’t be a hard sell. I wouldn’t recommend anything less than 4GB on a Windows Server 2008 box with one (1) VM, 6GB for two (2) VM’s, etc. It’s worth noting if you’re running Windows Server 2003 in the VM (or Linux) you can probably get away with halving those figures.
• If you’re running a domain controller as a VM never pause or take a snapshot of it. Active Directory (AD) depends on servers being able to increment sequence numbers (USN’s) to keep things in sync. If the VM is reverted to an old snapshot the USN’s will get out of sync, and you’ll start noticing differences in the AD database. Needless to say that’s not good.
• You should disable any NAT or host-only interfaces in VMware and only use bridging. Multi-homed DC’s (more than one network card) are a no-no, something that is well documented around the Net. Just make sure all the VM’s are configured accordingly. Your architecture might include host-to-guest communication over a private subnet–but I’ve found that most small business setups aren’t quite that “complicated”. VMware bridged connections use an existing network interface and don’t create new ones like the NAT and host-only options do. In a nutshell a DC will register all of its NIC’s in DNS even if you tell it not to (via TCP/IP | DNS properties page). If one of those registered NIC’s is unaccessible to the primary subnet (the one to which all the domain-joined workstations are attached) then you’ll start noticing timeouts in your DNS and AD queries. Depending on the number of registered NIC’s, DNS timeout configuration, network speed and other variables you may not notice any immediate problem, however there will most definitely be intermitent slowdowns with file sharing, login and password changes, along with various other issues specific to the environment.

In short just be careful when configuring and administering the host environment and you should have a smooth VMware/DC experience.