3. First Domain Controller AD Installation Guide
Install Active Directory Roles
Selecting the Server Roles
Confirm Installation Selections
Promoting the Server to a Domain Controller (DC)
Domain Controller Options
The Global Catalog server
The Importance of FSMO Roles
The Schema Master
The Domain Naming Master
The Relative Identifier
The Primary Domain Controller Emulator
The Infrastructure Master
Where are the FSMO Roles Located?
This is a comprehensive document that details every step to installing and configuring the 1st Domain controller in a new 2016 Active Directory
Here is the system that we are using for this build, note we are using a physical server not a vm as we are lucky enough to have some spare capacity in our lab (more on why that can be relevant to some of the new 2016 features sets in later articles)
Things you’ll need prior to starting:
For the 1st DC in a new Domain/Forrest
- Active Directory Name (more on this later, but there are a few considerations to consider when naming your new
baby, Active Directory Domain).
- A server with 2016 installed and activated (in a lab you “could” run in demo mode but 2016 likes to be activated for full benefits, updates etc. can have a grumble on an inactivated server).
- An account with Full Administrator access to the above server.
- A static IP Address for the DC
For an additional DC in an existing Domain/Forrest
- A domain admin account in the existing domain
- The Forrest Functional Level of the existing domain
- The Domain Functional Level of the existing domain
- A Static IP Address for the DC
This point is critical, once it’s named you’re stuck with it, for good or bad,
Bootnote: There “is” an MS util build into AD called RENDOM, that “renames” a domain, but its not for the faint hearted and even MS best practice states to create a new domain and do a migration rather than use it, it is a complete last option so just try and get your name right to start with.
In the past there was 2 accepted/best practice options that most companies used.
- A Generic top-level domain
The most common being .local, .lan, .corp, .ad & .hq amongst others, but… some of these are now being sold by the internet’s governing body ICANN, so the domain you’re using internally today – such as headoffice.local could potentially become another company’s public property tomorrow. Even worse, they could become internet routable, imagine your network trying to send network requests to a public website!
- Matching your public/website domain name
If you do want to match your external public domain name such as mycompany.com, you should avoid using the same domain as your internal AD name because you’ll end up with a split brain DNS. Split brains are when you have two separate DNS servers managing the exact same DNS Forward Lookup Zone, such as your internal ones “&” your public ones that are being hosted by your ISP. Increasing the administrative overhead as you need to keep both updated correctly.
So what do you recommend I hear you cry?
Your first (possible) option is to use a unique sub-domain of a domain that you use publicly. For example: ad.company.com is a common one, or network.company.com.
The advantages to this option include:
- You only need one domain name registered – even if you later decide to make part of your internal name publicly accessible
- Enables you separately manage internal and external domains with minimal overhead
- All internal domain names will be globally unique
- You can buy a simple wild card ssl cert of the top domain name and use that as a one cert fits all for your AD needs.
Remember though that if you go this route and your website name is a long one you’re your FQDNs on your internal network will also be long, eg.
So make your subdomain name as short as possible, to avoid if you have to go to a server or workstation and you have a long naming convention:
Its very Clunky and it could cause you issues in the long run with UNC paths only allowing 256 characters!
Another option and our “recommended” is for you to purchase another domain, (why not when you can buy one for £1 a year??) which isn’t going to be used for anything other than AD.
For example, if your public web presence is mycompany.com, your internal domain can be named mycompany.net, but this is only if you own the .net domain and you’re not using it for anything else.
The main advantage to this is that you have a “unique” internal domain name that you know will not be used anywhere else, there is no additional management overhead as you don’t need to do anything or publish any external record for it.
Another advantage is that you “could” publish external subdomain records for it to use for such things as VPN, external access intranets etc.
We are installing our first Domain Controller (DC) in a new active directory (AD), isn’t it exciting!!
So what do we do first?
We have already allocated the static IP address to our servers single NIC as part of our base server 2016 install, we cover that in another article so please refer to that if you are unsure how to do that. Or practice your Google-Fu…
Open Server Manager and click on “Add Roles and Features”
Click “Next” on the before you begin page
Select “Role-Based or feature-based installation” and click “Next”
Select the server we are going to be installing the role on to, this is an easy one as the local server is the only one in the pool (again we shall be covering server pools at a later date, so you will have to hold in your curiosity). And click “Next”
Tick the “Active Directory Domain Services” box
Another window will pop up to tell you that it also needs extra features, just leave the default box ticked (to include management tools) and click “Add Features”
It will go back to the “Server Roles” page but should now have the “Active Directory Domain Services” box Ticked, so you can just click “Next”
At this point you don’t need to select anything, just leave the defaults set and click “Next” as Server 2016 has already pre-populated the needed features (as per the previous).
We now get a quick re-cap screen of what we are doing (worth a quick skim if you have never done this before) you also get some links to more details on Azure (MS’s Cloud offering) and how to connect your AD to it (If you want/need to do that kinda thing) you can just click on “Next”
We now get a final review of what is about to be installed, we shall tick the box to “Restart the destination server automatically if required” box
This will pop up an additional box just asking you to confirm that you are happy for it to reboot on its own, just click “Yes”
Bootnote: This should not actually requre a reboot, but occasioanly you may come across a reboot pending (ususally from a windows update) and this will automaticaly resolve any issues.
You can now go ahead and click “Install”
You will see the std Server 2016 “I’m working on it” Page
As expected the server didn’t actually need to reboot!
At first glance the screen hasn’t actually changed that much, you just have a “Configuration required. Installation succeeded on SERVERNAME” message, and a list of additional steps.. All one of them according to the output, “Promote this server to a domain controller”…
So let’s do that then, click on the “Promote this server to a domain controller” (it’s a hyper link, web style)
You should now see the Deployment Configuration window; this is the point where we start making the big (and permanent) decisions
We are selecting “Add a new forest” as this is the 1st DC in our soon to be domain.
We have also specified the domain name as bigisp.uk, this is an internet routable domain name that we have purchased specifically for the lab, as per our recommendation
As new versions of the server operating system comes out, it brings with it new features.
To maintain backward compatibility with the older versions of the server operating systems, we maintain domain and forest functional levels. Some features of the new OS are not available until the functional levels are raised, but that can mean that older technology will stop working, so this becomes a choice rather than something that is enforced, as this is the 1st DC in a new domain, we can take advantage of leaving the domain and forest functional levels at 2016.
If you click on the arrow next to forest functional level you will see the below list,
If you are adding a new DC to an existing domain, set this to these levels what the existing domain and forest are at, you will note that 2003 is no longer a valid option but if you still have 2003 DC’s in your environment
burn them with fire set your level to the basic 2008.
You can also change these at any time after installation, but you can only increase the level safely, not lower it. So for example you could install 2 2016 DC’s at a 2008r2 functional, decommission all of your older 2008r2 DC’s then promote your domain and forest to a 2016 functional level.
Bootnote: The Domain functional level can never be lower than the current forest level but may be set higher, this just enables whatever additional schema updates exist in the newer version..
Again as this is the 1st DC in our environment and we have no existing DNS servers we shall leave the “Domain Name System (DNS) server” box ticked as this will install that role as part of the setup process
You will notice that there is a “Global Catalog (GC)” box ticked and you cant change it, so what is the Global Catalog I hear you ask??
The Global Catalog server is the server which is the master searchable index to all objects in forest in every domain in a multi-domain Active Directory Domain Services (AD DS) forest.
The Global Catalogue server performs the same role as the Infrastructure Master Role in Active Directory.
Now there “are” some rules around the placement of Global Catalogue Servers in relation to the Infrastructure Master FSMO role:
- The Infrastructure Master is not allowed to run on a Global Catalog Server if either
- there are multiple Domains in the Forest (not an issue for us)
- there are Domain Controllers in the same Domain which are not Global Catalog Servers
- The Infrastructure Master is allowed to run on a Global Catalog Server in a Domain if either
- there’s only one Domain in the Forest
- every Domain Controller in the Domain in question is Global Catalog Server
When you create an Active Directory forest, the first domain controller in the forest is automatically assigned the Global Catalog server roll, because every forest requires at least one Global Catalog server.
This is allowed based on the rules above as all DC’s are GC’s!
If all domain controllers are Global Catalogue servers, then the Infrastructure Master Role becomes redundant in the AD infrastructure.
Important note: If a Global Catalog server is not available in a domain, then nobody will be able to log into the domain except for the Administrator!!
But now you’re asking, what’s a FSMO Role??
I will talk more about the specific functions of the FSMO roles in the next article in this series. I do however want to quickly mention what these roles are. There are three domain specific roles, and two forest specific roles.
The domain specific roles include the Relative identifier, the Primary Domain Controller Emulator, and the Infrastructure Master. Forest level roles include the Schema Master and the Domain Naming master. Below is a brief description of what these roles do:
Domain Specific – 1 per domain
- Relative Identifier Master: responsible for ensuring that every Active Directory object at a domain receives a unique security identifier.
- Primary Domain Controller Emulator: acts as the Primary Domain Controller in domains containing domain controllers running Windows NT.
- Infrastructure Master: the Infrastructure Master is responsible for updating an object’s security identifier and distinguished name in a cross domain object reference.
Forest Specific – 1 per Forest
- Schema Master: maintains the authoritative copy of the Active Directory database schema.
- Domain Naming Master: maintains the list of domains within the forest.
In order to be able to function, the Active Directory requires that the DNS services are accessible and that the domain have at least one domain controller.
When an Active Directory based network is initially created, the first domain controller to be brought online is almost always configured to act as the network’s DNS server. This same domain controller is also assigned all five of the FSMO roles.
If other domains are created within the forest, then the first domain controller within each domain will host the FSMO roles for that domain. The forest level FSMO roles are only hosted on a single domain controller regardless of the number of domains in the forest.
Usually, there are no immediate consequences to an FSMO role failure should the role holder server die, but some rather strange symptoms will develop later on if the problem is not corrected. That being the case, it is important to know the signs of an FSMO role failure. It is also important for you to know how to determine which server is hosting each FSMO role. That way, if symptoms matching that of an FSMO failure occur, you can check to see which server is hosting the role that may have failed, and can then begin the troubleshooting process on that server.
The Active Directory is really nothing more than a database, and like any other database, the Active Directory contains a schema. Unlike many other databases, the Active Directory’s schema is not static. There are any number of operations that require extending the schema. For example, installing Exchange Server requires the Active Directory schema to be extended. Any time that changes are made to the Active Directory schema, those changes are applied to the Schema Master. The Schema Master is by far the most critical of the FSMO roles, so Microsoft hides it from view.
As I have already explained, an Active Directory forest can contain multiple domains. It’s the Domain Naming Master’s job to keep track of these domains. If the Domain Naming Master were to fail, then it would be impossible to create or remove domains until the Domain Naming Master comes back online.
As you know, the Active Directory allows administrators to create Active Directory objects on any domain controller. The catch is that each object must have a unique relative identifier number. To prevent relative identifier numbers from being duplicated, the Relative Identifier Master allocates a pool of relative identifiers to each domain controller. When a new object is created within a domain, the domain controller that the object is being created on takes one of its relative identifiers out of its pool and assigns it to the object. When the pool is exhausted, the domain controller must contact the Relative Identifier Master for additional relative identifiers. As such, the eventual symptom of a Relative Identifier Master failure is the inability to create objects in the Active Directory.
The PDC emulator is necessary to synchronize time in an enterprise. In a Windows domain, the PDC emulator role holder retains the following functions:
- Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
- Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
- Account lockout is processed on the PDC emulator.
- The PDC emulator role was also created to allow Active Directory domain controllers to co-exist with Windows NT4 domain controllers. The basic idea was that when an organization is being upgraded from Windows NT4 to Windows 2000 or to Windows Server 2003, the PDC is the first domain controller to be upgraded. At that point, the newly upgraded domain controller functions both as an Active Directory domain controller and as a PDC to the domain controllers that are still running Windows NT4.
In an Active Directory environment, a forest can contain multiple domains. Of course the implication of this is that Active Directory domains are not completely independent entities. They must occasionally communicate with the rest of the forest. This is where the Infrastructure Master comes into play. When you create, modify, or delete an object within a domain, the change will naturally be propagated throughout the domain. The problem is that the rest of the forest is not aware of the change. It’s the Infrastructure Master’s job to make the rest of the forest aware of the change.
If an Infrastructure Master server fails, then changes to objects will not be visible across domain boundaries. For example, if you were to rename a user account, the user account would still appear to have its old name when viewed from other domains in the forest.
For the most part, the FSMO roles pretty much take care of themselves. It is important however for you to know which domain controllers host these roles. By default, the first domain controller in the forest hosts all five roles. As additional domains are created, the first domain controller brought online in each domain holds all three of the domain level FSMO roles.
The reason why it is so important to know which domain controllers hold these roles is because hardware eventually gets old and is decommissioned or the server can fail. If you decommission a server without transferring the FSMO roles, then all of a sudden the Active Directory began to experience numerous problems. If a situation like this does occur, then there is a way of seizing the FSMO roles from the deceased server so that your network can resume normal operations.
So, after that brief diversion, let’s go back to the Domain Controller Options Screen (Remember that?)
The next option is the DSRM password, To quote MS DSRM stands for Directory Services Restore Mode (DSRM) and is a safe mode boot option for Windows Server domain controllers. DSRM allows an administrator to repair or recover to repair or restore an Active Directory database.
This is important, set a secure password, confirm it (i.e. type it in again) then you can click “Next”
Bootnote: Store the password somewhere safe that you can get at when you need it, remember that if your needing this password then you may not have access to your domain, so put it on a usb stick and into a firesafe, or in a secure cloud store somewhere.
Next is the DNS Options Page,
You will see a warning at the top regarding Delegation, you can ignore this, if you click on the “Show more” option then you will see this description, we can ignore it as there isn’t an authoritative parent zone yet, that will be created as part of the install.
Go ahead and click on “next”
You will see that the NetBIOS domain name has been prepoulated with the prefix from the domain name I gave it earlier, im happy with this so shall be leaving as is. So go ahead and click on “next”
Next is the Paths for the Database (The actual AD info), the Log Files & the SysVol folders, we are just going to leave these as the default C:\ Drive locations. So click “Next”
We now get a handy review screen to see recap the options we have selected before we proceed. Give your options a review to make sure you’re happy, and there has been no typos or oopsies before committing them. Then, you guessed it.. “Next”
The server will now go off and perform a number of pre-req checks, all you will see is a blue bar scrolling for a bit…
When the Results finally appear, you should see something similar to the below, the relevant bit being the “App prerequisite checks passed successfully” bit
Feel free to review the warnings, they are to be expected, the 1st one is ony relevant when you have NT4 servers on an existing domain, and the 2nd warning is re-iterating the DNS delegation warning from earlier.
Now is the point of no return..
Now go grap a cuppa…
You will be seeing this screen for a while as it installs all the selected options, then the server will reboot.
After the reboot it may do “configuring updates” for a bit before returning to the login screen, that’s fine and can vary so don’t worry if it doesn’t.
As part of the installation it has converted the local administrator login to a domain administrator login,(there is “no” local logins on a domain controller)
You can now Log back in and again wait while it applies its policies for the first time.
At this point there is no fanfare or “it’s complete” messages, you just get good old server manager, if you click on local server you will see that it now has a domain listed
If you check the network settings, you will see that the server also now uses itself as the preferred DNS server (that’s the std. loop back to self-address in there, also known as “Home”), this is normal and necessary, so don’t change it!!
Bootnote: Change the DNS server setting for any clients or servers you want to add to the domain to the fixed ip address of the DC, not the loopback address, if you are using DHCP for any clients or servers you want to add make sure to update your router/DHCP Server settings to give them the DC as its primary DNS server.
Please refer to our next instalment “Adding another 2016 Domain Controller to the domain” for adding a second domain controller.