Install Active Directory on a Windows Server 2019 member server
This is easy enough, login to your WS2019 server with an account that has Domain Admin rights and Enterprise Admin rights on the member server. These rights are required in order to add a domain controller into Active Directory as well as extend the schema.
- Start up a PowerShell prompt and type in the command Install-WindowsFeature AD-Domain-Services. This will install the binaries on your server.
- Install the ADDSDeployment module by running Import-Module ADDSDeployment in order to continue to work configuring Active Directory from PowerShell.
- Once those additional tools have been installed run Test-ADDSDomainControllerInstallation -DomainName tailwindtraders.com to test for any prerequisites.
– In this example my domain is TailwindTraders.com
– You will be prompted for the Active Directory safe mode administrator password.
Note the warning regarding “Allow cryptography algorithms compatible with Windows NT 4.0” – this is a reminder that old clients and applications pre-dating Windows Vista will not be able to establish connections or logon to domain controllers running this more modern OS of windows Server 2019.
- Promote this member server into a domain controller by running Install-ADDSDomainController -CreateDnsDelegation:$false -InstallDns:$true -DatabasePath ‘C:WindowsNTDS’ -DomainName ‘tailwindtraders.com’
- After prompting you for an ADSafeMode password and confirming a reboot will take place – this will kick off the installation process.
– It will initiate the install, while not bothering to make a new DNS delegation zone.
– It will install DNS service when promoting this machine to a Active Directory domain
controller. It will add itself (127.0.0.1) to its DNS name server list
– It will place the Database (and logs) in the in C:windowsNTDS directory
– It will contact any domain controller using a standard AD query to locate one in the
tailwindtraders.com domain in order to proceed
– You COULD target a domain controller if you like by adding -ReplicationSourceDC and
using the fully qualified domain name of a DC if you prefer
- You can see various informational messages appear in the PowerShell window as the install, schema extension and replication are Progress.
A restart will now take place once the steps are completed.
Transferring the FSMO (Flexible Single Masters of Operations) roles
If this was a real environment you would want to wait a while to allow for replication to take place around your Active Directory. You need to login to the new domain controller with Enterprise Admin rights in order to do these next steps in order to transfer FSMO roles.
- You can check for replication errors by opening up a Powershell window an running Get-ADReplicationFailure -scope SITE -target default-first-site | FT Server, FirstFailureTime, FailureClount, LastError, Partner -AUTO
NOTE: If this were a PRODUCTION migration of my Active Directory and I had NOT finished switching from SYSVOL replication to DFSR replication as of yet – I would stop everything I was doing and read NedPyle’s simplified article on how to do this.
No, really… GO READ IT NOW if you have not read it yet or made the switch.
You could use the old school NDTSUTIL command line utility to transfer the FSMO roles to the new domain controller. Since we’re using PowerShell for this blog – we’ll do it all in one command. Lets figure out which domain controllers have the roles now:
- To list off the two AD Forest wide roles and find out which DC currently holds them – run Get-ADForest tailwindtraders.com | Format-List SchemaMaster,DomainNamingMaster
- To list off the three AD Domain wide roles and find out which DC currently holds them – run Get-ADDomain tailwindtraders.com | Format-List PDCEmulator,RIDMaster,InfrastructureMaster
You can see here I have them split across both DC01 and DC02.
- To transfer all five FSMO roles from their current location to the new DC03 – run Move-ADDirectoryServerOperationMasterRole -identity DC03 -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster
It will prompt you to confirm before completing the task of transferring the roles. Once you confirm – it’s all done. You can confirm with commands listed above to see that DC03 is the new owner of all the roles.
It should be said – the preference is to ALWAYS transfer FSMO roles between DCs instead of Seizing them. If for some reason a Domain Controller is down – you would have to seize it (by adding a -force to the command) but that DC can NEVER be added back into the Active Directory domain again without causing issues.
If this were a production environment – I would once again wait until replication has worked it’s way through all my domain controllers before proceeding. I would also do the following in order to continue this migration from 2008R2 to Windows Server 2012:
- I would bring up an additional Windows Server 2012 Domain controller
- I would ensure any clients I had were using the new 2019 DC as its primary DNS. I had DC01 with an address of 192.168.10.100 as the primary DNS in this lab.
- I would run DCPROMO on both DC01 and DC02 boxes in order to demote and remove them from the Active Directory.
- Once all downlevel domain controllers have been removed (and replicated) I would raise the Domain functional level to Windows2016Domain domain mode
- run Set-ADDomainMode -identity tailwindtraders.com -DomainMode Windows2016Domain
- Once all domains have been raised to Windows2018Domain mode, I would raise the Forest functional level to Windows2016Forest
- run Set-ADForestMode -Identity tailwindtraders.com -ForestMode Windows2016Forest
That’s about it. I hope you found this quick walkthrough useful in learning the steps required to migrating FSMO roles from 2008R2 to 2019 while performing an upgrade of Active Directory. What do you think of this format and content – is it something you found useful and would like more of it? Feel free to reach out and share your answers below in the comment area and suggest other topics you’d like to see the team cover.