Setup a Domain Controller with Windows 2012 Server Core
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.
Preparing a DC Using Windows 2012 Server Core
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.
- Logon using an account with administrative privileges on the Server Core system.
- At the Windows Server 2012 Server Core Command Prompt, type sconfig.cmd and press Enter to start the Server Configuration Tool.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
- Type 8 and press Enter to select Network Settings from the menu.
- Type the Index# for the network adapter to change from the displayed list.
- Type 1 and press Enter to select the menu option to Set Network Adapter Address.
- Type S and press Enter to select the option for a Static IP.
- Type the IPv4 static IP address and press Enter.
- Type the subnet mask for the network and then press Enter.
- Type the default gateway for the network and then press Enter.
- The settings will be applied and the Network Settings menu will be redisplayed.
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.
- Type 2 and press Enter to Set DNS Servers.
- Enter the IP address of the preferred, or primary, DNS server for the domain. Press Enter.
- Click OK when prompted that the Primary DNS Server has been set.
- If a secondary DNS server exists for the domain, enter its IP address when prompted for an alternate DNS server. If no secondary DNS server exists, leave blank. Press Enter.
- Click OK when prompted that the Alternate DNS Server has been set. The Network Settings menu will be redisplayed.
- Type 4 and press Enter to exit the Network Settings menu.
- Type 15 and press Enter to exit the Server Configuration Tool.
Domain Controller Setup with PowerShell
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!
- At the Windows Server 2012 Server Core Command Prompt, type PowerShell and press Enter to begin a PowerShell session.
- Get the name of the installed network adapter by typing Get-NetAdapter at the PowerShell prompt and then pressing Enter.
- Pay attention to the name displayed for the adapter you intend to modify. Petri insider’s tip: In a fresh Server Core installation with one network adapter installed, the name will be Ethernet by default.
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.
- Type sconfig.cmd and press Enter to start the Server Configuration Tool.
- Type 5 and press Enter to select Windows Update Settings from the menu.
- Type A and press Enter to change the Windows Update to Automatic. Click OK.
- Type 15 and press Enter to exit the Server Configuration Tool and return to the PowerShell prompt.
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.
- Type Install-ADDSDomainController -DomainName awssol.com -InstallDNS:$True –Credential (Get-Credential) and click Enter. Of course, remember to replace awssol.com with your domain name.
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.
- The system will prompt you to confirm that the server will be configured as a DC and rebooted. Type A and press Enter to confirm everything and get this train rolling.
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?