Creating a New Forest and Promoting the First Domain Controller with Windows Server 2016
Admittedly, I haven’t touched Windows Server in a few years. I have my MCSE Security on Windows Server 2003, and while things haven’t changed that much in the world of Windows Server since I went from being a systems engineer to a pre-sales engineer in 2010, there are some differences that I’m finding as I am learning Windows Server 2016. On Server 2000 and Server 2003 (and even Server 2008), we used to use the dcpromo.exe utility to promote a Member Server to a Domain Controller, or in the case of a ground-up creation of a forest, create a forest, domain, and create the first Domain Controller. If you attempt to use that utility on Server 2016 however, you get an error that tells you to use the Server Manager utility to complete the process instead.
For the purposes of this demonstration, I’m going to be using a virtual machine that contains a brand new install of Server 2016. I have no existing domain, so I’m going to be completing the creation of a new forest, a new domain, and I’m going to be promoting this standalone server as the first Domain Controller of the new domain by installing some roles and features. This isn’t necessarily any more difficult than the “old way” of doing things, it’s just a little different. For those of you who are new to this, I will explain what every option means along the way so you aren’t left out in the cold. This same procedure will be used to promote new Member Servers to Domain Controllers on our new domain as the domain grows.
Assigning a Static IP Address and Meaningful Hostname
Best practice dictates that we assign static IP addresses for all of our servers, and that we assign meaningful hostnames. The later is not required, but is typically implemented. An IP address chosen outside of the range of the local DHCP pool will lessen the change that a duplicate IP assignment conflict happens within the same IP subnet.
We can easily assign both of these things – the static IP addressing information as well as the hostname – from the Server Manager console. The default view is the Dashboard, but if we click on “Local Server” on the left menu, we’ll get useful information about the server we’re logged in to. All of the items in blue can be conveniently clicked on to change their settings. First, we’ll change the IP address of this server, and set it to a static address.
In my lab, which consists of a copy of VMware Workstation, DHCP is provided by the VMware Workstation software. In a production environment, your DHCP information may be provided by either a server or a piece of networking equipment like a router or switch. Regardless of which device is handing out DHCP addresses to devices on your network, you’ll want to choose an IP address for your server which resides in a part of the LAN segment IP subnet that’s not included in the DHCP pool.
VMware workstation, by default, assigns addresses from 192.168.65.128 to 192.168.65.254 in a Class C (255.255.255.0 or /24) range on the VMnet8 virtual network, which is labeled “NAT” by default. For this reason I’ll be choosing the address 192.168.65.100. You should either choose any address outside of the range of your own pool (or create a reservation for the address you choose for your new server).
You’ll also need your subnet mask / IP segment length, which in most cases is 255.255.255.0 or /24 unless you got creative with subnetting (on VMware Workstation this is the default), and the IP address of your default gateway, which in VMware Workstation on VMnet8 is 192.168.65.2.
Setting fixed IP information on the server does not require a reboot, but changing the hostname does, so we’ll be setting a fixed IP address first to save ourselves time. In Server Manager click the blue text that says “IPv4 address assigned by DHCP, IPv6 enabled.” This will bring up a familiar screen. Right click your network adapter and choose Properties. You’re then able to select “Use the following IP address” and fill in the appropriate IP information that we just discussed.
In an Active Directory environment, clients on the network use Active Directory servers as their DNS servers. At least one Active Directory Domain Controller must have the DNS Server role installed. Since this is the first domain Controller in our environment, we will be installing the DNS Role on this server. Because of this, we’ll be setting the Primary DNS Server address on this machine to itself. Click OK to close that dialog an accept the changes.
Next, we’ll set a hostname for the machine. Back in Server Manager, click the hostname, which by default should be something like “WIN-ESJJK04IA7O.” When the System Properties dialog box appears, click the Change button.
Technically this can be anything you’d like it to be, but I’m a fan of hostnames that make sense when you look at them in terms of what specific role the machine performs. This may be just an old school way of thinking, but it makes sense to me to set hostnames for Domain Controllers to something like “DC01,” “DC02,” etc. as you create new machines. A web server, for instance, could be “WEB01,” “WEB02,” etc. I have been in environments where the hostnames mean nothing though, and servers are named after cartoon characters, cars, dinosaurs, or other things. An argument could be made that if someone malicious scans your network and sees Windows Servers named “DC01,” “DC02,” etc. that he’ll instantly know that those machines are Domain Controllers and that security will in some way be compromised. If you think about it though, if that person is already on your network, you’re already in trouble. Also, a quick port scan with something like nmap would make short work of discerning which machines are Domain Controllers, web servers, etc. based on open ports.
Naming arguments aside, for this demo I’m going to name our machine SVR01.
After you’ve named your server, click Ok twice to close both dialog boxes. The system will prompt you to reboot, which you should do now.
Installing the Active Directory Domain Services Role
When the server finishes rebooting, log in and wait for Server Manager to fully load back up. From the Manage menu (top right), select Add Roles and Features.
We’re going to be adding the Active Directory Domain Servers (AD DS) role.
Click Next on the Before you Begin section of the wizard. For Installation Type, the default selection of Role-based or Feature-based Installation should be left selected. Click Next again. This brings us to the Server Selection section.
Server Manager allows you to remotely install features and roles on other servers in the environment. Since this is the first server in our environment, we don’t have any other servers listed here. Leave the default of Select a server from the pool selected. By default, our only server is highlighted. Click Next. On the Server Roles screen, click the check box next to Active Directory Domain Services. You’ll instantly be presented with a box informing you that other features are required to be installed since you have chosen this role.
Click Add Features to automatically install all of the mentioned features.
This will take you back to the Server Roles dialog, where you’ll again click Next.
On the Features section, all of the features that we’ll need have been pre-selected for us as a result of choosing to add them on the previous screen. How nice. Click Next again to continue. We’ll now see a Confirmation summary of all of the features and roles that we’ve selected to install.
Click Install to install the selected features and roles. This should only take a couple of minutes and does not require a reboot once it has completed. Once this process has completed you’ll see a message that says “Configuration required. Installation succeeded on SVR01″ under the progress bar. From here you can click Close to go back to Server Manager, where we’ll promote our member server to a Domain Controller, and create our forest and domain.
Creating a Forest, Domain, and Promoting our Member Server to Domain Controller
In Server Manager, under the flag icon in the upper right corner you’ll see a yellow warning triangle. This is to let us know that our setup isn’t quite complete. Click the blue hyperlink text that says Promote this server to a Domain Controller.
From here we have several options. We can add this Domain Controller to an existing Windows domain, we can create a new domain and add it to an existing forest, or we can create an entirely new forest and along with it, a first domain. Since we are starting from the ground up all brand new, we’ll choose to create a new forest and domain.
You’ll want to name your domain with a Fully Qualified Domain Name (FQDN). Although you can use an Internet-routable FQDN (like stuffjasondoes.com), a lot of DNS planning has to go in to doing so if you plan to use that domain for an active public-facing domain out on the Internet and as an internal Windows domain at the same time. It’s for this reason that most people choose to use a non-routable domain with the .local suffix. Since this is a dummy environment for me, I’m going to name mine company.local and click Next.
Now that we have a name for our Domain, we need to configure some options in regards to this Domain Controller specifically. On this screen we have several options. The first two deal with the forest functional level and the domain functional level. If you have older Domain Controllers in an existing environment, you need to plan for the lowest common denominator when it comes to dealing with those servers. This requires planning beyond the scope of this tutorial, but know that older versions of Windows Server ran at older functional levels and that having old servers in your environment might require you to run your domain or forest at an older functional level to maintain backward compatibility with those older servers. Also understand that newer features may only be available if the domain and the forest are running at the newest functional level.
Since we are creating a new forest and a new domain, and this is the first Domain Controller, and we’re running Server 2016, we can leave both the forest and domain functional levels at Windows Server 2016.
The next option specifies that we’d like DNS to be installed and used as a part of this promotion. DNS is required for Active Directory to function properly, so this should remain checked.
The next option is grayed out so we can’t deselect it, and that is the Global Catalog option. Each Active Directory domain must contain at least one Global Catalog server. Global Catalog server location planning goes beyond the scope of this tutorial, but since this is our first and only domain controller in the environment, it is required to run the Global Catalog role.
The final check box would allow us to create a Read Only Domain Controller or RODC. This was introduced back in Server 2008, and is a special domain controller that exists for the purpose of putting a read-only copy of the Active Directory database in a location where security might not be at its highest, but Active Directory authentication and rights management still needs to occur, like a branch office location. Since this is the first Domain Controller in our domain, it cannot be read only.
The last requirement we have here is to set an Active Directory Services Restore Mode password. This password will be required if something happens to the Active Directory database and you have to boot the server into Active Directory Restore Mode. Make it secure, and document it. Click Next.
The next few sections aren’t too involved or important, so I’ll just describe them briefly.
DNS Options – This screen will warn you that there’s no authoritative parent zone to be found. This is okay, since there is no DNS service currently running in our domain. The warning can be ignored. Click Next.
Additional Options – The only option here is to set the NETBIOS name. This is a legacy technology that Windows used to use before everything was so heavily reliant on DNS. You may have used a NETBIOS name if you’ve ever logged in to a machine using the format: COMPANY\user. Specifying the NETBIOS name of the domain like that will force the use of NETBIOS vs DNS. To properly format a FQDN DNS login, you’d use user@company.local instead. Because a lot of people still use legacy login syntax like this, and some applications still reference machines based on their NETBIOS name, you should leave this at the default. Click Next.
Paths – This dialog gives you the option to change the paths for the Active Directory database folder, the log files folder, and the SYSVOL folder. Changing these paths could break things down the road, so I would leave them at the default and click Next.
Finally, we can review all of our options.
On this screen you’ll also notice the View Script button. Since in Server 2016 all of these wizards are basically GUIs for PowerShell commands, this button will allow you to see the PowerShell syntax for the options we just configured within this wizard. This is useful because if you wanted to accomplish the same thing on a server running Server Core via the PowerShell command prompt, this is the command you would use. (Or you could just do what everyone else does and manage a Server Core machine from Server Manager on a Server running a desktop.)
When you’re done exploring bloated PowerShell syntax, click Next.
The next screen will run through a prerequisites check. Since we’re promoting a brand new Domain Controller on an empty domain, this shouldn’t take very long. You’ll see a couple of warnings here that can be ignored. The first tells us that by default, weak encryption is enabled to maintain backwards compatibility with Windows NT 4.0. I don’t know why they’d do this. I can’t imagine anyone is still running Windows NT 4.0. It’s almost as if Microsoft is warning you about how insecure they are, and link you to a KB article that explains how you turn off the hampered security that they’ve gifted you by default. You may want to go back and disable this default later. Here’s a link to the KB article in case you don’t catch it before clicking Install.
The second warning we’ve seen before, and it is in regards to the system not being able to find an authoritative parent DNS zone. This can be safely ignored, as it’ll be remedied as a part of this wizard’s completion.
After you’ve read the warnings, click Install. This process should only take a couple minutes. When completed the server should be rebooted one last time, and when it comes back up you can log in as the domain administrator account.
Finishing Up
You should have a full suite of Administrative Tools installed now. Open Active Directory Users and Computers and you’ll find that SVR01 is nestled happily within the Domain Controllers OU. You’ll also see that DNS is running on this server. Windows does not configure any DNS forwarders by default, so you may want to open up the DNS console, right click on your server, choose Properties, go to the Forwarders tab, click Edit, and add some public DNS servers like 1.1.1.1 and 1.1.2.2.
It’s as easy as that. We’ve created a new forest, created a domain within that forest, and promoted our Windows Server 2016 Member Server to a Domain Controller within our new domain. From here you should be able to start building out your Server 2016 infrastructure. I hope this has been informative for anyone who comes from an old dcpromo background like myself, or for someone who is new to Server 2016 and is just starting to learn. If you have any comments or questions, feel free to add them to the Comments section below.