Domain in a box

This article tells you how to set up a self-contained domain on a single computer under Virtual Server. Ed Reed, a virtualization developer here at Microsoft helped me out with it. Thanks Ed!

Although you can set up a production domain controller on Virtual Server with lots of caveats (see Notes), the best reason to deploy a “domain in a box” is for development and testing purposes. For example, you might want to validate architecture or perform unit testing. For other types of testing, such as network analysis, function testing, capacity planning and resource utilization, you’d probably want to replicate the domain infrastructure in a test lab with multiple physical servers, rather than using the “domain in a box” configuration described in this article.

To set up a domain in a box, you create and configure virtual machines running one or more domain controllers to reproduce the domain configuration that you want to test. You’ll probably want to create at least one virtual machine as a domain member as well. It isn’t a good idea to use the host operating system as a domain member because the domain controller must be available for the domain member to log onto the network. This would create a “chicken and egg” problem following a restart of the host computer.

To configure networking, connect each virtual machine in the domain, including the domain controllers, to the “Internal” virtual network. This will isolate the network communication between the virtual machines to the internal virtual network on the host. You’ll also need to either assign static IP addresses to the virtual machines or else set up the DHCP server on the domain controller (not the virtual DHCP server provided by Virtual Server).

The obvious way to test a domain configuration is to create a set of base VHDs and then enable differencing or undo disks before making the configuration changes that you want to test. Using differencing or undo disks with a domain controller, however, isn’t supported. The problem is that the base VHDs can become out of date and thus will be tombstoned. This happens when domain replication data is discarded when you discard the differencing or undo disk. To avoid this problem, let the domain controller(s) run when you’re not running a test so that they periodically replicate and never go beyond 180 days between replications. (Keep in mind that even if you do this, Microsoft Product Support won’t support using differencing and undo disks with a domain controller.)

Notes:

• In addition to this article, you should read the “Running Domain Controllers in Virtual Server 2005” whitepaper, especially if you’re considering setting up a production domain controller in a virtual machine. The whitepaper provides considerations and caveats, and explains the Microsoft support policy. It’s available at https://www.microsoft.com/downloads/details.aspx?FamilyId=64DB845D-F7A3-4209-8ED2-E261A117FC6B.
• Before you perform a test using your domain in a box, you should back up your virtual hard disk (.vhd) files.
• If you want to allow networking between the domain controllers running in your virtual machines and computers on an external network, you’ll need to connect the virtual machines to a virtual network that is attached to a physical network adapter with access to the external network. You would set this environment up the same way you would if the virtual machines were physical computers.
• You can also configure a domain in a box on Virtual PC, but it is not supported. In this case, you’d attach the virtual machines to the Local Only network. Otherwise, the configuration would be the same.