Server Core, introduced with Windows Server 2008, is a lean and mean installation option for Windows Server 2012. It is a GUI-free, or “headless,” operating system. Eliminating the GUI on the server offers many advantages; in fact, Microsoft believes in Server Core so strongly that it is the default installation option in Windows Server 2012.
One of the best uses for Server Core in Windows Server 2012 is as an Active Directory Domain Controller. Why? For starters, Server Core minimizes the Windows components installed. Fewer components mean fewer security patches and Windows updates. It also means a lower attack surface making the server easier to protect from malware. Less running processes and services reduce the opportunity for system crashes and hangs.
Now it’s time to go from just wanting a Server Core DC to actually having one. Before we get too far along, we better start by making sure our bases are covered and that all prerequisites have been met. It should go without saying Windows Server 2012 Server Core must already be installed. Next, we need to make sure network settings have been correctly configured. We’ll begin by assigning a static IP address.
Down the road, this server will query the existing domain controllers in the domain. It’s essential this works without any hiccups so set a DNS Server address while still in the Network Settings menu.
I bet a number of you are anticipating my usual “Do this in one step with PowerShell” approach. Well, I have no intention of disappointing anyone, so here we go!
Type the following cmdlet, and replace the IPAddress parameter with the static IP to assign this server. The InterfaceAlias parameter is the name of the adapter found using the Get-NetAdapter cmdlet. Also, be sure to set the DefaultGateway parameter appropriately for the network.
Armed with the interface name retrieved earlier using the Get-NetAdapter cmdlet, it’s time to set the DNS servers using the Set-DNSClientServerAddress cmdlet. The IPs entered for the ServerAddresses parameter are the primary and secondary DNS servers.
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses (“10.0.10.151”,”10.0.10.152”)
Okay, technically that’s two cmdlets, but come on – it’s still way faster than the non-PowerShell way!
There’s no sense in slowing down now. Without exiting the PowerShell session, install the Active Directory Services Role using the following cmdlet:
Install-WindowsFeature AD-Domain-Services –IncludeManagementTools
This is a great time to mention a few things about an error you may see: “WARNING: Windows automatic updating is not enabled. To ensure that your newly-installed role or feature is automatically updated, turn on Windows Update.”
First, don’t worry – this has zero impact on the installation of the AD Services Role. If this is the only error you see, rest assured everything installed just fine.
Second, since this server will ultimately be joined to a domain and if Windows Update is enabled in the domain’s Group Policy settings there’s nothing to worry about. Once joined to the domain, the server will automatically turn on Windows Update.
Third, if you absolutely will not sleep well knowing that Windows Update is turned off even for a moment, don’t break out in a sweat just yet: It can be enabled manually. Since I prefer that all IT admins be calm and well rested as they read my Petri articles, here’s the process.
Almost done! It’s now time to move forward with promoting the server to function as a domain controller. In this scenario, the domain tree where this DC will live is called awssol.com. Keep in mind that we’re adding this DC to an existing domain and configuring this server as an additional DNS server for the domain.
The cmdlet will prompt for credentials. This needs to be an account with Domain Admin privileges in the domain where the DC is being created.
Next, it will ask for a SafeModeAdministratorPassword. This is the Directory Services Restore Mode Password used primarily for disaster-recovery scenarios. Type in the password you’d like to set and then press Enter. If you’re a fan of simple passwords, you’re out of luck: A non-blank password that meets the password complexity rules of the domain is required. You’ll need to confirm the password by entering it twice.
There are a couple warnings you’ll probably be presented with as the promotion does its job.
The first warning lets you know that Windows Server 2012 has defaults for certain security settings that can affect very old OSes on the network such as Windows NT 4.0. The second warns that a DNS Server delegation can’t be created. Since we’re installing DNS on this server as part of the DC promotion process, both of these errors are safe to ignore. Unless of course you are still running Windows NT 4.0 systems on the network (in which case, what are you thinking? Get those servers upgraded!)
I’m a big fan of Windows Server 2012 Server Core Active Directory Domain Controllers and of Server Core in general, and I’ll have more Server Core related articles here on Petri in the future. In the meantime, why not turn all your AD DCs into Server Core machines?