Building a 2008 R2 Core Domain Controller VM on Citrix XenServer

I purchased a throwaway HP ProLiant DL320 G5 server recently from Comprenew, and I started configuring a simple lab environment in order to do some testing with Citrix XenServer and XenDesktop. Because this machine only has 6GB of RAM, and because I wanted a fully-functional Active Directory environment, I decided to build a domain controller using Windows Server 2008 R2 Core to avoid the overhead of the traditional Windows GUI environment. I hadn’t been through the procedure in quite some time, so I decided to document the process here both for my own future reference and to help anyone else trying to do something similar.

I started by downloading, installing, and licensing the free version of Citrix XenServer 6.0.2 so I had a working hypervisor on the DL320. VMware ESXi would work fine, or even Microsoft Hyper-V, but I’ve been wanting to do some further testing with XenServer 6 for while. Use whatever makes sense for you, obviously, even if you’re just installing Windows Server Core directly to a physical box with no hypervisor at all. Configuration of the hypervisor is beyond the scope of this post, but I will make passing mention of a few XenServer settings as we move forward.

In my case, I built a simple new VM from XenServer’s “Windows Server 2008 R2 (64-bit)” template using the default single CPU, 1GB ram, and 24GB virtual disk. I used a volume license ISO file of Windows Server 2008 R2 with SP1 (thank you, TechNet Professional subscription), which is important — if you don’t have SP1 as part of your base installation, make sure to install it immediately as some of the instructions below won’t work without it. During installation of the operating system, simply choose the option to install the Core version of Windows Server (I used Enterprise, but Standard is fine) and do a normal base load.

Once the operating system is installed and you’ve logged in, the command prompt goodness begins. This is the procedure I wanted to document, so here we go…

Step 1: Initial configuration with sconfig.cmd

Use the sconfig.cmd script bundled with R2 to easily perform the initial base configuration. Sconfig is one of my favorite new things in R2, incidentally… it just makes life easier. Thank you, Microsoft VB wizards.

Step 4: Enable the DNS Server service

Since this is a lab environment, the DC will pull double duty as my DNS server.

Note: This step can be done automatically as part of the Dcpromo process documented below, but I like to do it separately. Force of habit, maybe, but I feel better about it this way.

Turn on DNS: Start /w ocsetup DNS-Server-Core-Role

Step 5: Promote the server to a Domain Controller

Create an unattend answer file for Dcpromo (see MS KB947034 for all available options):

Open Notepad or any other text editor.

On the first line, type [DCINSTALL], and then press ENTER.

Type the following entries, one entry on each line:

InstallDNS=yes

NewDomain=forest

NewDomainDNSName=fully qualified domain name (FQDN)

DomainNetBiosName=first label of the FQDN, by default

ReplicaOrNewDomain=domain

ForestLevel=forest functional level number

DomainLevel=domain functional level number

DatabasePath=path to a folder on a local volume, surrounded by double quotation marks

LogPath=path to a folder on a local volume, surrounded by double quotation marks

SYSVOLPath=path to a folder on a local volume, surrounded by double quotation marks

SafeModeAdminPassword=password

Note: In my lab environment, I’m using defaults for all the path definitions referenced above. Those entries can simply be left out of the answer file.

Save the answer file to a location on the installation server from which it will be called by Dcpromo.

Finally, at the command prompt, type the following command and press ENTER:dcpromo /unattend:"(path to the answer file)"

Wait for the forest & domain configuration to complete. The server will reboot automatically, after which you should log in and verify there were no logged errors and that the environment was configured correctly.

Step 6: Install the XenServer (or other) Tools:

Obviously, you might ignore this if you aren’t running in a hypervisor — it should be noted, however, that additional tools/drivers should probably be installed at this point no matter what your configuration. Consult your hardware vendor.

Warning: Without the proper tools installed, this new installation won’t be optimized for your environment, and you may (read: will) experience problems.

The important thing to realize is that AutoRun is disabled, so the XenServer and/or VMware tools won’t install automatically when you choose that option from within your hypervisor’s management interface. Compensate accordingly. As an example, to install the XenServer Tools:

Choose “Install XenServer Tools” from the “VM” menu in XenCenter.

Note that the installation doesn’t happen automatically.

From a command prompt, switch to the D: drive (or whichever is applicable).

Manually run xensetup.exe to install the tools.

Step 7: Activate Windows Server Core:

Only activate your server after verifying that everything works correctly and you’re happy with the installation. The slmgr.vbs script is used for this purpose in Server Core.

Input the product key: slmgr -ipk (product key)

Activate Windows: slmgr -ato

Final considerations:

Although I initially configured this VM with the default 1024MB of RAM, it could easily operate with less. As I build out the test environment further, I’ll reduce the amount of allocated RAM in order to better utilize scarce resources.

So far, so good. I’m quite happy with the setup, and it’s working as intended. Let me know if you’ve used Server Core in a similar way, either in a lab or in production — for some reason, production instances of Server Core seem to be rare in the companies I’ve worked with.