The World According to Mitch

**DISCLOSURE: While I am contracted to Microsoft Corporation, I am not an employee. The articles that I write are not meant to represent the company, nor are they meant to represent me as an employee or spokesman for the company. As has always been the case, all articles on this website represent me and nobody else.

**NOTE: All of the command line entries in this article are performed in PowerShell. To differentiate between the PowerShell cmdlets and Command Line Interpreter commands, the PowerShell cmdlets are in blue, and the Commands are in black.

—

Yes, I know… the company line is that Active Directory Domain Services (ADDS) is the past, Azure Active Directory (AAD) is the future. That is a true statement… but ADDS is not going extinct like dinosaurs at a specific point in time; rather, over the course of many years, our organizations will evolve to be using AAD more and more, until one day in the distant future our identity will be managed completely in the cloud. Until that day comes, ADDS is still the premiere identity management solution, and you still need to know how to use it… even if it is now chiefly configured for Hybrid Azure Active Directory Joined (HAADJ) environments.

The heart and brain of your Active Directory is and has always been the domain controller. That has not changed significantly in twenty years. What has changed, beginning in Server 2008 but evolving tremendously since, is the ability to run our domain controllers on Server Core, with much smaller attack surface, patch footprint, and storage requirements than the same server with the Desktop Experience (Server with a GUI).

There are some people who have always loved working entirely in the command line, while others do so grudgingly because people like Mitch Garvis tell them it is the better way to manage their environments. What has, in my experience, always been the greatest factor in convincing the skeptics that Server Core is the way to go for their servers is the ability to manage their tools remotely using MMC consoles. That is a subject for another time.

In this article I will show you how to build a new domain controller using PowerShell.

Step 1: Log onto your domain-joined member server with a Domain Admin account. For best results, the account should be a member of the Enterprise Admins and Schema Admins groups as well.

Step 2: Run Windows PowerShell

PowerShell.exe

Step 3: Install the Active Directory Domain Services components.

Install-WindowsFeature AD-Domain-Services –IncludeManagementTools

Step 4: Promote the system to be a domain controller.

(Sticking with my recently created environment, we are using the domain behike.ca. You should replace that with whatever your domain name is.)

Install-ADDSDomainController -DomainName “behike.ca” -NoGlobalCatalog:$false -CreateDnsDelegation:$false -CriticalReplicationOnly:$false -InstallDns:$true -NoRebootOnCompletion:$false -Force:$true

(If you want to split this up onto multiple lines that may be more manageable (and do not scroll in weird places) try this:

Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DomainName “behike.ca” `
-InstallDns:$true `
-NoRebootOnCompletion:$false `
-Force:$true

You will be asked to enter the Safe Mode Administrator Password (twice).

At this point, you should see some warnings flash by, but after a few minutes you should see the following on your screen:

When the reboot is completed, you should see the following:

Yes, you are going to have to delete all of that and enter your credentials as behike\Administrator (or whatever your domain and user are).

We are all done with the actions, but let’s look at a few things to be sure it all worked.

Am I really a domain controller?

From PowerShell, type the following cmdlet:

Get-ADDomainController

You should get a response like this:

Really and Truly a legitimate name server?

Let’s use the following cmdlet to verify that an NS record was created for our newly promoted domain controller:

Get-DnsServerResourceRecord –ZoneName behike.ca –RRType NS

You should get a response that looks like this:

Incidentally, if you did that on your newly promoted domain controller, that is also proof that when promoting it, the DNS Server role was installed as well. However, if you are still a Doubting Thomas who wants to go back to the training wheels environment that is the GUI server, you can open your DNS Manager on the server with Desktop Experience installed (or to a management workstation with the DNS RSAT Tools) and verify your zone:

 

Yessir, you have created a new domain controller… and you saved about 9gb of disk space (as seen in the following comparisons from my server with a GUI to the Server core install (using the following cmdlet):

Get-CimInstance -Class CIM_LogicalDisk | Select-Object @{Name=”Size(GB)”;Expression={$_.size/1gb}}, @{Name=”Free Space(GB)”;Expression={$_.freespace/1gb}}, @{Name=”Free (%)”;Expression={“{0,6:P0}” -f(($_.freespace/1gb) / ($_.size/1gb))}}, DeviceID, DriveType | Where-Object DriveType -EQ ‘3’

Server with Desktop Experience:

Server Core:

Conclusion:

The Windows Desktop experience is a great environment to use when you are working in the graphical user interface. However, it does take resources (9gb storage, not to mention the RAM requirements). It also presents a larger attack surface. With the Remote Server Administration Tools available to us in Windows 10 (and Windows Server), why would you install the GUI on every server? I promise you will get used to working remote, and once you do, you will save a ton of resources!