New Domain Controller Best Practices and Troubleshooting

A lot of guides and how-to videos out there show you the basics and the bare-bones – this is real world, git’r’done right stuff!

The first step to setting up a new domain, or creating a new domain controller for an existing domain, is, of course, to install the OS. We’ll assume that has already been done.

If you are adding a 2019 DC to an existing Domain, you will probably need to migrate the domain to use DFSR instead of FRS for syncing Active Directory and DNS – see the DFSR Migration section.

In the video above, I may do things in a different order, but here are the first steps:

A. Set a static IP address and Public DNS servers. The DNS servers you set here will become the DNS Forwarders of your new Domain Controller.

B. Name the new server something those who come after you will understand. This means your organization name, year it was created and the server’s role should be in the name of the server. For a business named Kearan Company, our first domain controller could be Kearan-19-DC – created in 2019, acting as a Domain Controller. -DCFS, -RDS, -APP, -SQL, -Web, -Intranet are all possibly good role names to use. Just make sure that it is not a very long name – there are limits! 16 Characters for the server name should be fine. (Changing the name requires a reboot!) (Update:) It has come to my attention that Domain Controller In-Place-Upgrades are easier and more reliable than before, so maybe having the OS in the name is not a perfect idea, in case you update from 2012 to 2019 OS. If this is something you would be comfortable with, make a naming convention – Kearan-DC-001 ; Kearan-RDS-002 ; Kearan-RDS2-003 ; etc.

C. Use Server Manager to install the Active Directory Domain Services role and DNS Server – see the above video for a walk-thru on that process.

D. With the roles installed and the server rebooted, promote to a domain controller! Document the DSRM Password!

• Domain name is very important – keep it short and informative. For a company named Contoso Specialty Products Supply Company, a domain such as “Contoso” or “CSPSC” would be perfect. The dot-local (Contoso.local) is preferred, as it is the default. You can use another such as .corp or .main – I have even seen .private – but stay away from the major top level domain extensions such as .com, .net and .org as these can cause a conflict between local DNS and Public DNS. So, New info has come to light – .local and other ‘private’ extensions are being sold as a TLDs (Top Level Domains) now, so the new Best Practice is to make your domain a sub-domain of a domain you own. So, you own Contoso.net (but not .com), you would want to make your local domain something like ad.contoso.net or internal.contoso.net. This way, you can also get SSL certs for your local domain names.
• Document the DSRM password where it can be found in the future! Just in case.
• Netbios name is just a short version of the domain name – so if you’re using ad.contoso.com – make the netbios “contoso” – it has a 15 character limit, so be brief.
• Reboot and Log in to your new Domain!

E. Set some important DNS settings to squash problems before they happen

• Set Aging/Scavanging for all zones
• Apply to existing Active Directory-integrated zones
• Allow zone transfers to servers listed on the Name Servers tab
• Automatically notify the severs listed on the Name Servers tab
• Check and/or set forwarders

F. Open AD Users and Computers and create a good AD structure!

You will need to move newly added users and computers from their default “Users” and “Computers” containers into your structure, but it will make organization and group policy much easier to manage in the future.

(See below for an AD User Import powershell!)

G. Copy the Administrator user and create a domain admin user based on your company – such as KearanIT. Add the new admin to the Backup Operators group. Log off of Administrator and log in with the new domain admin account. Now, DISABLE ADMINISTRATOR!
Move the new Admin account into the Service Accounts OU created as part of the good structure.

H. Make the Domain Controller a Reliable Time Server using the commands below:

w32tm /config /manualpeerlist:"1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /config /reliable:yes 
net stop w32time && net start w32time     
w32tm /query /peers   

Powershell, CMD Line and Troubleshooting for
Domain Controllers

DFSR Migration

First, raise the Forest functional level to as high as possible – must be at least 2008 R2. Now get the Global State:

DFSRMig /GetGlobalState

Start the migration –

DFSRMig /SetGlobalState 1

Check on progress –

DFSRMig /GetMigrationState

Once the migration state says all domain controllers are synced, then go to SetGlobalState 2 – GetMigrationState until that is synced, then SetGlobalState 3 until that is synced. 3 is the Final state – you are all on DFSR now!

Powershell to Move FSMO Roles

Run the following in an Admin Powershell window on the server you want to be the new FSMO role holder:

Move-ADDirectoryServerOperationMasterRole -Identity $env:computername -OperationMasterRole 0,1,2,3,4

Don’t forget to Move the Last Two FSMO Roles using ADSIEdit.

Powershell to Import Users from a CSV file

You will need to copy the powershell code below into a new Powershell ISE module, then save it as a .ps1 and edit it for your needs. Create the CSV file with the two lines after “format of file:”

# - Imports given CSV file
# format of file:
# Firstname,Lastname,SAM,OU,Password,Description,EmailAddress
# bobby,kearan,bkearan,"OU=Employees,OU=Users,OU=_Kearan,DC=kearan,DC=local",Pl3asech@ngeme,Awesome IT Engineer,[email protected]
#
 $csvPath = "C:\KearanCode\ADUserImport.csv" # Read-Host -Prompt 'path to the csv file'
 $Servername = $env:computername # Read-Host -Prompt 'Name of the DC (servername)'
#
 $Users = Import-Csv -Path $csvPath        
 foreach ($User in $Users)            
 {            
     $Displayname = $User.'Firstname' + " " + $User.'Lastname'            
     $UserFirstname = $User.'Firstname'            
     $UserLastname = $User.'Lastname'            
     $OU = $User.'OU'            
     $SAM = $User.'SAM'                     
     $Description = $User.'Description'            
     $Password = $User.'Password'            
     $Email = $User.'EmailAddress'
     New-ADUser -Name "$Displayname" -DisplayName "$Displayname" -samaccountname $SAM -UserPrincipalName $SAM -GivenName "$UserFirstname" -Surname "$UserLastname" -Description "$Description" -Emailaddress "$Email" -AccountPassword (ConvertTo-SecureString $Password -AsPlainText -Force) -Enabled $true -Path "$OU" -ChangePasswordAtLogon $false –PasswordNeverExpires $false -server $Servername            
 } 

You will need to set them all to not need to change their password on first logon by using the following two commands:

Import-Module ActiveDirectory
Get-ADUser -Filter * -SearchBase "OU=_Kearan,DC=Kearan,DC=Local" | Set-ADUser -ChangePasswordAtLogon:$False 

DCDiag Commands

The following does a report and saves it in a txt file on the root of C:\ (adjust to your preferred file path)

DCDiag /c /v /f:c:\dcdiag.txt

The following does a report and attempts to fix any issues it found and puts the txt file in the root of C:\

DCDiag /fix /v /f:c:\dcdiag.txt

Force a Time Zone Change

For some reason, Windows has become a bit difficult about changing the time zone. Below is a command line to see the time zone and change it. Last line outputs a list of time zone names that can be used. Open the cmd window as admin to run this.

tzutil /g
tzutil /s "Central Standard Time"
tzutil /l

Group Policy Central Store

A central store for Group Policy is a good thing to implement.  This allows all domain controllers to access the same policies no matter what version of server they are running.  To set this up, follow the below steps:

1. Create the Central Store on a Domain Controller by creating the policy definitions folder: C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions
2. Copy all of the contents of C:\Windows\PolicyDefinitions into the newly created folder.

You now have a Central Store – as this gets replicated to all domain controllers.

Now you can download more up to date .admx files – such as windows 10 and windows 11 policies – or Google Chrome templates.  Extract those and then copy over to the central store.  Put the .admx files with the rest of the .admx files, and copy the language files from the “en” folder to the “en” folder in the central store.  You do not need to copy all the other language files unless you will be using them.

— what would you like to see covered next? Comment below —