Server Core installations can be specifically targeted at situations where single server roles are needed. Combining some of these roles on one server might also be very powerful, as I will show you in this post of my Easter SC’enarios series, where I’ll try to construct the ultimate Branch Office server using Server Core roles.
Roles and features
The roles and features I’ll be using are:
- Active Directory Read Only Domain Controller
- Active Directory Integrated Dynamic DNS Server and DHCP Server
- File Server with Distributed File System and Bitlocker Drive Encryption
- Windows Backup
This will result in a headless server, that can be safely stored in a kitchen cupboard of a remote location of your company. Management can be safely performed from the Main Location using a combination of MMC Snap-Ins, WinRS and WinRM. The Domain Controller will become a Domain Controller for a new Active Directory Site. I’ll assume you have the servers at the Main Office and Active Directory (domain.local) set up and configured properly.
Microsoft strongly advised in the FAQ not to place more than one Read Only Domain Controller in one Active Directory Site. You can place multiple Read Only Domain Controller in one Active Directory Site however when certain requirements are being met:
- The Password replication policy is configured identical for all Read Only Domain Controllers in the same site
- The Passwords for all the accounts in the Active Directory site are pre-populated for on all Read Only Domain Controllers in the same site
Here’s a picture to give you an idea from a birds view on how this SC’enario works:
The configuration of Server Core in this rather lengthy SC’enario is divided in the following sections:
- Initial configuration
- Changing the hostname
- Configuring IP addressing
- Configuring Name resolution
- Configuring partitions
- Allow Remote Management
- Protecting the drive with Bitlocker
- Prepare the boot volume
- Initializing the TPM chip
- Encrypting the System volume
- Encrypting the Data and Active Directory volume
- Running DCPROMO
- Installing and configuring the DHCP Server
- Installing the DHCP Server Role
- Starting the DHCP Server
- Configuring the DHCP Server
- Setting up the File Server Role
- Installing the DFS Roles
- Adding the Server Core as DFS Namespace Server
- Replicating the Branch Office Data folder
- Backing up the server regularly
Since I’m using the default DVD to install Windows Server 2008, I’ll end up with a server, installed with a random hostname and a dynamically assigned IP address. In order to use the server in this SC’enario we need to perform essential tasks, ensuring the correct configuration of the Operating System. These tasks include:
Changing the hostname
Since WIN-Something isn’t really what I want my end-users to see when they try to access the data on the server I’ll be changing it into something more useful. In this case I’ll be changing it to BO01, which in my book is short for Branch Office Server 1. To change the hostname, simply type:
netdom renamecomputer /newname:BO01
Press Y to continue. When the command completes successfully you can restart your Server Core box, using the following command:
shutdown -r -t 0
Configuring IP addressing
Because our server is going to act as a Domain Controller we need to configure it with a static IP address. A Full installation of Windows Server 2008 will actually throw an error when you attempt to promote a server to a Domain Controller when it isn’t configured with static IP addresses. Let’s configure it right now, using the following command:
netsh interface ipv4 set address name=”Local Area Connection” source=static address=192.168.2.1 mask=255.255.255.0 gateway=192.168.2.254
Configuring Name resolution
Since we’ve already discovered setting a static IP address without setting the DNS Server setting is not recommended, we’ll also configure DNS properly. In this case we’ll configure DC01 as the primary DNS Server for our server, using the following command:
netsh interface ipv4 set dnsserver name=”Local Area Connection” source=static address=192.168.1.1
When putting a server in a remote location it’s highly advised to take a good look at the partitions you’re going to use. You don’t want your users clog the C:\ drive with their important data, do you? You’ll want a separate data partition. Since we’ll also be implementing Bitlocker we also need a small partition where Windows can boot from, that is not going to be encrypted. We’ll need at least three partitions. In my case I used server hardware with two 300GiB hard drives in RAID1, which leads to:
This can be easily achieved by shrinking the default partition that covers the whole disk and create the additional partitions. Here are the commands:
DISKPART> select disk 0
DISKPART> select partition 1
DISKPART> shrink desired=267782
DISKPART> create partition primary size=1539
DISKPART> select partition 2
DISKPART> format fs=ntfs label=”Boot”
DISKPART> assign letter=E
DISKPART> create partition primary size=256003
DISKPART> select partition 3
DISKPART> format fs=ntfs label=”Data”
DISKPART> assign letter=F
DISKPART> create partition primary size=10243
DISKPART> select partition 4
DISKPART> format fs=ntfs label=”ActDir”
DISKPART> assign letter=G
You might notice I’m using strange sizes for my partition. Actually I’m using sizes that in the Graphical User Interface will show up as perfectly rounded sizes. When sharing the data on the data partition with my end-users the size of the share shows up as exactly 250GB. (unless quota are used)
Allow Remote Management
Since the box might be hundreds or even thousands of miles away it’s useful to open up the Server Core box for some remote management. To allow most of the essential Microsoft Management Console (MMC) Snap-Ins to be able to connect, type the following command on the console of your Server Core box:
netsh advfirewall firewall set rule group=”Remote Administration” new enable=yes
Enabling the Windows Remote Shell (WinRS) in combination with Windows Remote Management (WinRM) can also make your life as an administrator a breeze. Enable this feature by typing the following command on the console of your Server Core box:
Protecting the drive with Bitlocker
Now that we’ve made a partition available for booting the Operating System we can begin preparations for encrypting the other partitions of our Server Core box using Bitlocker.
Your server will need to have an activated Trusted Platform Moldule (TPM) v1.2 chip and you will need to have your Windows Server 2008, Windows Vista or Windows PE media to complete this step. For other methods to enable Bitlocker take a look at the BitLocker TechNet Step by Step pages.
First, start off by installing the Bitlocker feature to your Server Core box by running the following command:
start /w ocsetup BitLocker
The ocsetup.exe command is case-sensitive on roles.
Prepare the boot volume
Boot your Server Core box from your Windows Server 2008, Windows Vista or Windows PE media and get to the Command Prompt option. Perform the following commands:
xcopy c:\boot d:\boot /h /e (this is a directory)
xcopy c:\bootmgr d:\bootmgr /h (this is a file)
DISKPART> select disk 0
DISKPART> select partition 2
Now reboot your system.
Initializing the TPM chip
Perform the following commands on the console of your Server Core box:
cscript manage-bde.wsf –tpm –takeownership –P@ssw0rd
Where P@ssw0rd is my own choice for the master password for the TPM chip. You may come up with your own password, but please write this password down… When this command completes successfully you are ready to use your TPM chip with Bitlocker.
Encrypting the System volume
We can now actually begin encrypting the Windows volume and your data volume. We’ll begin with the Windows volume. Perform the following command. It will output a Numerical password which you really need to write down.
cscript manage-bde.wsf -on -recoverypassword C:
After writing down the 48 character long password reboot your Server Core box. After reboot the system will start encrypting the C:\ drive of your Server Core box. You can use the following command to check the status of the encryption process:
cscript manage-bde.wsf -status
Encrypting the Data and Active Directory volume
After the Windows volume has been encrypted you can continue encrypting your Data and Active Directory volume. Basically the process is identical to encrypting the system volume:
cscript manage-bde.wsf -on -recoverypassword F:
cscript manage-bde.wsf -on -recoverypassword G:
Write down the password again. This partition will also begin encrypting, but when it’s done you won’t be able to access the drive anymore. No need for panic though, since we haven’t placed any data on it (yet). Actually, this behavior is by default and the situation can be easily solved by turning autounlock on, with the following command:
cscript manage-bde.wsf -autounlock -enable F:
cscript manage-bde.wsf -autounlock -enable G:
Your system is now ready to be used in a fashion where the contents of your hard disk is encrypted using the onboard TPM chip.
Part of the Ultimate Branch Office Server is the Read Only Domain Controller functionality. The Read Only Domain Controller is not aimed at providing additional fault-tolerance for your Active Directory forest, but is an additional Domain Controller aimed at branch office situations. These situations typically include:
- relatively few users
- poor physical security
- relatively poor bandwidth to central Domain Controllers
- little local IT knowledge
The classic question was to place a (writable) Domain Controller in the Branch Office or increase bandwidth to the central Domain Controllers to facilitate authentication.
Branch Offices also typically have specific needs. Most of the time central restrictions don’t get taken very seriously and the only real restriction seems to be budget. This results in the kitchen cupboard servers most of us will have encountered. (along with the coffee machine hooked up to the same UPS?) The Read Only Domain Controllers functionality offers branch offices fast authentication, while being more secure than writable Domain Controllers, mitigating the risks when the box gets compromised or stolen.
In this SC’enario I will be setting up the Domain Controller using the command line. Other options include using an answer file and staged promotion using the /CreateDCAccount switch for dcpromo.exe. My preference this time is the command line since it can be scripted and since it can be performed using WinRS and WinRM.
The following command assumes you already have your Active Directory running, already created the Active Directory site for the Branch Office, already performed adprep /rodcprep and already have at least one Windows Server 2008 Domain Controller deployed.
The command to promote the server to a Read Only Domain Controller for this SC’enario is:
dcpromo.exe /createOrjoin:join /replicaDomainDNSName:domain.local
/Password:P@ssw0rd /InstallDNS:Yes /ConfirmGc:Yes
Your Server Core will automatically reboot when dcpromo is successful. Don’t forget to log on as Domain\Administrator after this first reboot.
Installing and configuring the DHCP Server
Since the DCPROMO command already mentioned to install a DNS Server on our Branch Office server we only need to install DHCP to accommodate the users in our Branch Office with automatic IP addressing.
Installing the DHCP Server Role
Install the DHCP server role with the following command:
start /w ocsetup DHCPServerCore
First add the DHCP server to the scope of Netsh, using the following commands:
netsh dhcp> add server bo01.domain.local 192.168.2.1
netsh dhcp> exit
Starting the DHCP Server
To set the DHCP Server Service to start automatically and start the DHCP Server Service type the following commands:
sc config DHCPServer start=auto
net start DHCPServer
Configuring the DHCP Server
A DHCP Server that is part of an Active Directory environment needs to be authorized before it can start providing IP addressing to computers. After that you can begin configuring scopes on your DHCP Server and start spreading IP addresses. Use the following commands:
netsh> dhcp server
netsh dhcp server> initiate auth
netsh dhcp server> add scope 192.168.2.0 255.255.255.0 BOscope
netsh dhcp server> scope 192.168.2.0
netsh dhcp server scope> set optionvalue 003 IPAddress 192.168.2.1
netsh dhcp server scope> set optionvalue 006 IPAddress 192.168.2.254
netsh dhcp server scope> set optionvalue 015 String domain.local
netsh dhcp server scope> set state 1
netsh dhcp server scope> exit
Alternatively to setting up a DHCP server on your Branch Office Server you can use a DHCP Server on your router. This would not make much sense from a management standpoint, unless your router supports RFC1542 and is able to offer DHCP relaying for a centrally managed DHCP server.
Setting up the File Server Role
Although we’re putting information from our Main Office on this Branch Office server we haven’t reached the point where business critical information is placed on the Branch Office only. One of the advantages of placing a Branch Office is reduced bandwidth requirements, but how to make the Branch Office server a file server while still not placing files on the Branch Office server only? Distributed File System is the answer!
Installing the DFS Roles
Your Server Core server is a file server by default, so installing the File Server role isn’t really necessary. Installing the Distributed File System Namespaces (DFSN) role is. Since we’ll be using the new Distributed File System Replication (DFS-R) you need to install this role as well. This proces is identical to point-and-clicking DFS together in the Server Manager of a Full Installation of Windows Server 2008. Use the following commands:
start /w ocsetup DFSN-Server
start /w ocsetup DFSR-Infrastructure-ServerEdition
Adding the Server Core as DFS Namespace Server
I’ll assume you already have Distributed File System set up on your Main Location, running your Active Directory in Windows Server 2008 functional mode and benefiting from the new Windows Server 2008 Domain-based Namespaces. Adding your Server Core Branch Office server to your already existing DFS namespace is as easy as adding the Server Core box as a Namespace server in the DFS Management MMC Snap-In on the file server in the Main Location. The error stating that the DFS Service isn’t started is to be expected and the Add Namespace Server can fix this for you.
Why struggle with a command line tool to do this? I thought our goal was to have central management…
Replicating the Branch Office Data folder
All that is left to do is make a folder on the F:\ drive of your Server Core box and share it. To make a folder on your F:\ drive with appropriate permissions, you can use the following commands:
net share data=F:\Data /Remark:”Branch Office Data”
Once you make a share on the File Server in the Main Office (FS01), you can and add both shares to the same replicated folder. Making the share on the Branch Office Server the primary member for the replication group will get you going. If you need to set any permissions you might find it useful to open up the firewall to allow for remote Computer Management (compmgmt.msc)
Backing up the server regularly
We’ve been busy for a while to configure this Branch Office Server. Although the server doesn’t hold any business critical data it would be a pain in the behind when the server would fail. This first time configuring this server type might take you longer than the next one, but you would still feel bumped out. Especially since you’re only two commands away from making automatic backups of the system to the replicated DFS folder you created in the previous step:
start /w ocsetup WindowsServerBackup
wbadmin.exe start backup -backuptarget:\\BO01\Data
-allCritical -VSSfull -quiet
If you want you can make a separate replicated DFS folder to replicate backups. DFS-R offers additional settings over FRS, like a replication schedule and bandwidth throttling. A separate replicated DFS folder would allow you to benefit from these settings.
It’s a lot of work to configure a Server Core Branch Office Server, but once you’re done it becomes clear this setup really showcases the benefits of Server Core:
- Since your Server Core installation is only 2GB on disk, your backups can more easily be replicated in contrast to a Full Installation (8GB). Optionally you might even consider installing the server remotely using a built-in DRAC/ILO card.
- You can use 10GB more of your hard disk to store your users’ data, since Microsoft requires 10GB for Server Core in contrast to 20GB for a Full Installation’s hard disk.
- Although the hard disk of the server is encrypted and the server can be deprovisioned from Active Directory easily (RODC) there’s an additional layer of ‘security’ since the server doesn’t offer a familiar graphical user interface. Peter R. de Vries wouldn’t know where to start investigating.
A kitchen cupboard suddenly sounds like a good location for a little server to happily hum away and make your coworkers days more effective.
BitLocker command line interface
So, you want to BitLocker an existing computer?
The BitLocker Command Line Interface…
A best practice guide on how to configure BitLocker (Part 1)
A best practice guide on how to configure BitLocker (Part 2)
Distributed File System (DFS)
Distributed File System Replication
New Domain-Based Namespaces On The Way!
Choose a Namespace Type
Migrate a Domain-based Namespace to Windows Server 2008 Mode
Managing shared folders from the command line