1.What is Active Directory? #

What is Active Directory?

Active Directory Domain Services is Microsoft’s Directory Server. It provides authentication and authorization mechanisms as well as a framework within which other related services can be deployed (AD Certificate Services, AD Federated Services, etc). It is an LDAP compliant database that contains objects. The most commonly used objects are users, computers, and groups. These objects can be organized into organizational units (OUs) by any number of logical or business needs. Group Policy Objects (GPOs) can then be linked to OUs to centralize the settings for various users or computers across an organization.

When people say “Active Directory” they typically are referring to “Active Directory Domain Services.” It is important to note that there are other Active Directory roles/products such as Certificate Services, Federation Services, Lightweight Directory Services, Rights Management Services, etc. This answer refers specifically to Active Directory Domain Services.

What is a domain and what is a forest?

A forest is a security boundary. Objects in separate forests are not able to interact with each other, unless the administrators of each separate forest create a trust between them. For example, an Enterprise Administrator account for domain1.com, which is normally the most privileged account of a forest, will have, no permissions at all in a second forest named domain2.com, even if those forests exist within the same LAN, unless there is a trust in place.

If you have multiple disjoint business units or have the need for separate security boundaries, you need multiple forests.

A domain is a management boundary. Domains are part of a forest. The first domain in a forest is known as the forest root domain. In many small and medium organizations (and even some large ones), you will only find a single domain in a single forest. The forest root domain defines the default namespace for the forest. For example, if the first domain in a new forest is named domain1.com, then that is the forest root domain. If you have a business need for a child domain, for example – a branch office in Chicago, you might name the child domain chi. The FQDN of the child domain would be chi.domain1.com. You can see that the child domain’s name was prepended forest root domain’s name. This is typically how it works. You can have disjoint namespaces in the same forest, but that’s a whole separate can of worms for a different time.

In most cases, you’ll want to try and do everything possible to have a single AD domain. It simplifies management, and modern versions of AD make it very easy to delegate control based on OU, which lessens the need for child domains.

I can name my domain whatever I want, right?

Not really. dcpromo.exe, the tool that handles the promotion of a server to a DC isn’t idiot-proof. It does let you make bad decisions with your naming, so pay attention to this section if you are unsure. (Edit: dcpromo is deprecated in Server 2012. Use the Install-ADDSForest PowerShell cmdlet or install AD DS from Server Manager.)

First of all, don’t use made up TLDs like .local, .lan, .corp, or any of that other crap. Those TLDs are not reserved. ICANN is selling TLDs now, so your mycompany.corp that you’re using today could actually belong to someone tomorrow. If you own mycompany.com, then the smart thing to do is use something like internal.mycompany.com or ad.mycompany.com for your internal AD name. If you use mycompany.com as an externally resolvable website, you should avoid using that as your internal AD name as well, since you’ll end up with a split-brain DNS.

Domain Controllers and Global Catalogs

A server that responds to authentication or authorization requests is a Domain Controller (DC). In most cases, a Domain Controller will hold a copy of the Global Catalog. A Global Catalog (GC) is a partial set of objects in all domains in a forest. It is directly searchable, which means that cross-domain queries can usually be performed on a GC without needing a referral to a DC in the target domain. If a DC is queried on port 3268 (3269 if using SSL), then the GC is being queried. If port 389 (636 if using SSL) is queried, then a standard LDAP query is being used and objects existing in other domains may require a referral.

When a user tries to log in to a computer that is joined to AD using their AD credentials, the salted and hashed username and password combination are sent to the DC for both the user account and the computer account that are logging in. Yes, the computer logs in too. This is important, because if something happens to the computer account in AD, like someone resets the account or deletes it, you may get an error that say that a trust relationship doesn’t exist between the computer and the domain. Even though your network credentials are fine, the computer is no longer trusted to log into the domain.

Domain Controller Availability Concerns

I hear “I have a Primary Domain Controller (PDC) and want to install a Backup Domain Controller (BDC)” much more frequently that I would like to believe. The concept of PDCs and BDCs died with Windows NT4. The last bastion for PDCs was in a Windows 2000 transitional mixed mode AD when you still had NT4 DCs around. Basically, unless you’re supporting a 15+ year old install that has never been upgraded, you really don’t have a PDC or a BDC, you just have two domain controllers.

Multiple DCs are capable of answering authentication requests from different users and computers simultaneously. If one fails, then the others will continue to offer authentication services without having to make one “primary” like you would have had to do in the NT4 days. It is best practice to have at least two DCs per domain. These DCs should both hold a copy of the GC and should both be DNS servers that hold a copy of the Active Directory Integrated DNS zones for your domain as well.

FSMO Roles

“So, if there are no PDCs, why is there a PDC role that only a single DC can have?”

I hear this a lot. There is a PDC Emulator role. It’s different than being a PDC. In fact, there are 5 Flexible Single Master Operations roles (FSMO). These are also called Operations Master roles as well. The two terms are interchangeable. What are they and what do they do? Good question! The 5 roles and their function are:

Domain Naming Master – There is only one Domain Naming Master per forest. The Domain Naming Master makes sure that when a new domain is added to a forest that it is unique. If the server holding this role is offline, you won’t be able to make changes to the AD namespace, which includes things like adding new child domains.

Schema Master – There is only one Schema Operations Master in a forest. It is responsible for updating the Active Directory Schema. Tasks that require this, such as preparing AD for a new version of Windows Server functioning as a DC or the installation of Exchange, require Schema modifications. These modifications must be done from the Schema Master.

Infrastructure Master – There is one Infrastructure Master per domain. If you only have a single domain in your forest, you don’t really need to worry about it. If you have multiple forests, then you should make sure that this role is not held by a server that is also a GC holder unless every DC in the forest is a GC. The infrastructure master is responsible for making sure that cross-domain references are handled properly. If a user in one domain is added to a group in another domain, the infrastructure master for the domains in question make sure that it is handled properly. This role will not function correctly if it is on a global catalog.

RID Master – The Relative ID Master (RID Master) is responsible for issuing RID pools to DCs. There is one RID master per domain. Any object in an AD domain has a unique Security Identifier (SID). This is made up of a combination of the domain identifier and a relative identifier. Every object in a given domain has the same domain identifier, so the relative identifier is what makes objects unique. Each DC has a pool of relative IDs to use, so when that DC creates a new object, it appends a RID that it hasn’t used yet. Since DCs are issued non-overlapping pools, each RID should remain unique for the duration of the life of the domain. When a DC gets to ~100 RIDs left in its pool, it requests a new pool from the RID master. If the RID master is offline for an extended period of time, object creation may fail.

PDC Emulator – Finally, we get to the most widely misunderstood role of them all, the PDC Emulator role. There is one PDC Emulator per domain. If there is a failed authentication attempt, it is forwarded to the PDC Emulator. The PDC Emulator functions as the “tie-breaker” if a password was updated on one DC and hasn’t yet replicated to the others. The PDC Emulator is also the server that controls time sync across the domain. All other DCs sync their time from the PDC Emulator. All clients sync their time from the DC that they logged in to. It’s important that everything remain within 5 minutes of each other, otherwise Kerberos breaks and when that happens, everyone cries.

The important thing to remember is that the servers that these roles run on is not set in stone. It’s usually trivial to move these roles around, so while some DCs do slightly more than others, if they go down for short periods of time, everything will usually function normally. If they’re down for a long time, it’s easy to transparently transfer the roles. It’s much nicer than the NT4 PDC/BDC days, so please stop calling your DCs by those old names. 🙂

So, um…how do the DCs share information if they can function independently of each other?

Replication, of course. By default, DCs belonging to the same domain in the same site will replicate their data to each other at 15 second intervals. This makes sure that everything is relatively up to date.

There are some “urgent” events that trigger immediate replication. These events are: An account is locked out for too many failed logins, a change is made to the domain password or lockout policies, the LSA secret is changed, the password is changed on a DC’s computer account, or the RID Master role is transferred to a new DC. Any of these events will trigger an immediate replication event.

Password changes fall somewhere between urgent and non-urgent and are handled uniquely. If a user’s password is changed on DC01 and a user tries to log into a computer that is authenticating against DC02 before replication occurs, you’d expect this to fail, right? Fortunately that doesn’t happen. Assume that there is also a third DC here called DC03 that holds the PDC Emulator role. When DC01 is updated with the user’s new password, that change is immediately replicated to DC03 also. When thee authentication attempt on DC02 fails, DC02 then forwards that authentication attempt to DC03, which verifies that it is, indeed, good, and the logon is allowed.

Let’s talk about DNS

DNS is critical to a properly functioning AD. The official Microsoft party line is that any DNS server can be used if it is set up properly. If you try and use BIND to host your AD zones, you’re high. Seriously. Stick with using AD Integrated DNS zones and use conditional or global forwarders for other zones if you must. Your clients should all be configured to use your AD DNS servers, so it’s important to have redundancy here. If you have two DCs, have them both run DNS and configure your clients to use both of them for name resolution.

Also, you’re going to want to make sure that if you have more than one DC, that they don’t list themselves first for DNS resolution. This can lead to a situation where they are on a “replication island” where they are disconnected from the rest of the AD replication topology and cannot recover. If you have two servers DC01 – and DC02 –, then their DNS server list should be configured like this:

Server: DC01 (
Primary DNS –
Secondary DNS –

Server: DC02 (
Primary DNS –
Secondary DNS –

OK, this seems complicated. Why do I want to use AD at all?

Because once you know what you’re doing, you life becomes infinitely better. AD allows for the centralization of user and computer management, as well as the centralization of resource access and usage. Imagine a situation where you have 50 users in an office. If you wanted each user to have their own login to each computer, you’d have to configure 50 local user accounts on each PC. With AD, you only have to made the user account once and it can log into any PC on the domain by default. If you wanted to harden security, you’d have to do it 50 times. Sort of a nightmare, right? Also imagine that you have a file share that you only want half of those people to get to. If you’re not using AD, you’d either need to replicate their username and passwords by hand on the server to give seemless access, or you’d have to make a shared account and give each user the username and password. One way means that you know (and have to constantly update) users’ passwords. The other way means that you have no audit trail. Not good, right?

You also get the ability to use Group Policy when you have AD set up. Group Policy is a set of objects that are linked to OUs that define settings for users and/or computers in those OUs. For example, if you want to make it so that “Shutdown” isn’t on the start menu for 500 lab PCs, you can do that in one setting in Group Policy. Instead of spending hours or days configuring the proper registry entries by hand, you create a Group Policy Object once, link it to the correct OU or OUs, and never have to think about it again. There are hundreds of GPOs that can be configured, and the flexibility of Group Policy is one of the major reasons that Microsoft is so dominant in the enterprise market.

2.Install first Domain Controller #

Installing Active Directory

Before the AD install however it is important to understand what is the minimum requirement to install windows server 2016. However the manual can be used for 2008 R2/2012R2 and 2016.


• 1.4 GHz 64-bit processor

• Compatible with x64 instruction set

• Supports NX and DEP

• Supports CMPXCHG16b, LAHF/SAHF, and PrefetchW

• Supports Second Level Address Translation (EPT or NPT)

Coreinfo is a tool you can use to confirm which of these capabilities you CPU has.


• 512 MB (2 GB for Server with Desktop Experience installation option)

• ECC (Error Correcting Code) type or similar technology

Storage controller and disk space requirements

Computers that run Windows Server 2016 must include a storage adapter that is compliant with the PCI Express architecture specification. Persistent storage devices on servers classified as hard disk drives must not be PATA. Windows Server 2016 does not allow ATA/PATA/IDE/EIDE for boot, page, or data drives.

The following are the estimated minimum disk space requirements for the system partition.

Minimum: 32 GB

Network adapter requirements


• An Ethernet adapter capable of at least gigabit throughput

• Compliant with the PCI Express architecture specification.

• Supports Pre-boot Execution Environment (PXE).

A network adapter that supports network debugging (KDNet) is useful, but not a requirement.

1) Once Active directory setup on the server, it also going to act as DNS server. There for change the DNS settings in network interface and set the server IP address (or local host IP as the primary DNS server.


2) Then open the server manager. Go to PowerShell (as administrator) and type ServerManager.exe and press enter.


3) Then on server manager click on add roles and features


4) Then it opens the add roles and features wizard. Click on next to proceed.


5) Then in next window keep the default and click next


6) Since its going to be local server, in next window keep the default selection.


7) In next window from the roles put tick box for active directory domain services. Then it will prompt to show you what are the associated features for the role. Click on add features to add those. Then click next to continue.




8) The features page, keep it default and click on next to proceed.


9) In next windows it gives brief description about AD DS service. Click next to proceed.


10) Then it will give the confirmation about install, click on install to start the role installation process.


11) Once done, it will start the installation process


12) Once installation completes, click on option promote this server to a domain controller.


13) Then it will open the active directory configuration wizard. In my demo I am going to setup new forest. But if you adding this to existing domain you can choose relevant option. (I am going to write separate article to cover how you can upgrade from older version of Active Directory). Select the option to add new forest and type FQDN for the domain. Then click next.


14) In next page you can select the domain and forest functional levels. I am going to set it up with latest. Then type a password for DSRM. Then click next


15) For the DNS options, this going to be the first DNS server in new forest. So no need any modifications. Click next to proceed.


16) For the NETBIOS name keep the default and click next 


17) Next page is to define the NTDS, SYSVOL and LOG file folders. You can keep default or define different path for these. In demo I will be keeping default. Once changes are done, click next to continue


18) Next page will give option to review the configuration changes. If everything okay you can click next to proceed or otherwise can go back and change the settings.


19) In next windows it will do prerequisite check. If it’s all good it will enable option to install. Click on install to begin installation process.


20) Then it will start the installation process.


21) After the installation system will restart automatically. Once it comes back log in to the server as domain admin.

22) Once log in open the powershell (as administrator) and type dsac.exe and press enter. It will open up the active directory administrative center. There you can start managing the resources.



23) Also you can use Get-ADDomain | fl Name,DomainMode and Get-ADForest | fl Name,ForestMode from powershell to confirm domain and forest functional levels


3.AD replication check #

Check Active directory replication

Before promoting your domain controller.

After you installed your domain controller role and before promoting the server to be a Domain controller you should be checking if your Active Directory replication is in good condition.

To do so run the following command in an administrator mode in PowerShell.

  • Run through your AD Replication checks.

Dcdiag for onscreen result:

  • dcdiag /s:mydcservername
  • repadmin /replsummary
  • repadmin /showrepl * /errorsonly
  • dcdiag /s:mydcservername /test:replications

For a good readable report in a text file:

dcdiag /test:dns /e /s:mydcservername /DnsBasic /f:c:\dcdiagfull.txt

You can also use the Active directory replication tool to check for any errors:

Download Gui replication tool here.

If you come across any errors then you should solve this first before promoting your new DC.

4.Install Read only DC #

Installing a Read-only domain Controller

Read-only domain controllers are ideal in remote location where system security cannot be guaranteed. They allow the remote site to have local authentication point, without storing vulnerable data about every object in the domain. The only information stored on a read-only domain controller is that of users and computers it has been authorized to authenticate. Any other object that is queried or authorized against is forwarded by the read-only DC to writable domain controller.

A newly deployed RODC will not authenticate users or computers. It will forward all authentication and access requests to writable domain controller. We must specific which users, groups, or computers the RODC will cache credentials for in order for authentication and access rights to be done by it.

This step-by-step will guide you through deploying a read-only domain controller in your environment.


  • Deploy a read-only domain controller in an existing domain.
  • Configure user and computer account caching.


Before a read-only domain controller can be deployed in your environment, the following criteria must be met. Make sure your environment meets or exceeds the following requirements.

  • An existing Active Directory domain.
  • 2003 domain and forest function level, or higher.
  • At least one writable domain controller that is running Windows Server 2008 or higher.
  • One Windows Server 2012 R2 server for the RODC role.

Server Configuration

The Active Directory domain used in the lab for this tutorial has the following servers. The last one, CALDC01, is what will be configured as a read-only domain controller.

Hostname Site Role
TORDC01 Toronto, Ontario Domain Controller
TORDC02 Toronto, Ontario Domain Controller
CALDC01 Calgary, Alberta Read-only Domain Controller (RODC)

Site Configuration

The lab used for this tutorial had the following site configuration in Active Directory.

Site Name Subnets

Preparing an Upgraded Forest\Domain for RODC

If your forest or domain had its domain controllers upgraded from Windows Server 2003, you may have to extend your schema to allow read-only domain controllers. The reason for this is that Windows Server 2003 and Server 2003 R2 did not support read-only domain controllers. The role became available again in Windows Server 2008. You can skip this section if your forest was created on Server 2008 or Server 2012.

You may will know that your domain was not prepared for RODC when you attempt to promote a domain controller as on. A message will be displayed, seen in the fig1, stating that the default accounts used by RODC cannot be found.

Errors message when promoting a RODC when domain not prepared.

FIG1 – Errors message when promoting a RODC when domain not prepared.

  1. Mount a Windows Server 2012 R2 ISO or disc in the domain controller running a 64-bit version of Windows Server. The server should ideally be hosting the schema FSMO role.
  2. Execute the following command, replacing D:\ with the drive letter of the mounted image.

D:\support\adprep\adprep /rodcprep

  1. Follow the onscreen instructions and then wait for schema changes to be replicated to all domain controllers in the domain. Depending on the number of sites and size of your domain, this may take a while.

Preparing the RODC

The following steps will install the Active Directory role and promote the server to be a domain controller. The steps are very similar to promoting a full, writable domain controller.

  1. Launch Server Manager.
  2. Click the Manage link at the top-right of the Server Manager console.
  3. On the Before you begin screen, click Next.
  4. On the Select installation type screen, ensure Role-based or feature-based installation is selected, and then click Next.
  5. On the Select destination server screen, click Next.
  6. On the Select server roles screen, select Active Directory Domain Services, and then click Next.
  7. If Add Roles and Features Wizard dialog box appears, click Add Features.
  8. On the Select features screen, click Next.
  9. On the Active Directory Domain Services screen, Click Next.
  10. On the Confirmation screen, ensure Restart the destination server automatically if required is checked, and then click Install.
  11. When the installation completes, click Promote this server to a domain controller.

FIG2 - Promote server to domain controller

FIG2 – Promote server to domain controller

Promoting Server to Domain Controller

  1. On the Deployment Configuration screen, ensure Add a domain controller to an existing domain is selected, enter the fully qualified domain name in the Domain text field, and add credentials for an administrator of the domain.

FIG3 - Deployment configuration screen

FIG3 – Deployment configuration screen

  1. On the Domain Controller options screen, ensure Read only domain controller (RODC) is checked, select the site for the server by using the Site name drop-down, and set the DSRM password. When done, click Next.


FIG4 – Domain Controller Options screen

As can be seen in the FIG4, we are also installing the DNS role onto our RODC. When a DNS role is installed on a RODC, the DNS role also becomes read only. All DNS record registration requests submitted to this server will be forwarded to a full domain controller.

  1. On the RODC Options screen, we can configure which accounts or groups are allowed to have their passwords replicated to the RODC. By default, a RODC replicates passwords of any account in the Allowed RODC Password Replication Group. This may be too global for our liking, so I’ve created a security group just for the Calgary users. The next step would be to remove the default Allowed RODC Password Replication group. Click Next when done.

FIG5 - RODC options screen

FIG5 – RODC options screen

It’s important to remember that a read only domain controller will only cache credentials for accounts added to the security groups listed under Accounts that are allowed to replicate passwords to the RODC. IF you do not add accounts of the computers and users for this site, their passwords will not be stored on the RODC and they will not be able to log onto any computer or resources if the link between this site and a site with a writable domain controller goes down.

  1. On the Additional Options screen, you may select which domain controller to replicate from or let that be decided automatically. Click Next when done.
  2. On the Paths screen, you may select locations for the Active Directory database, log files, and SYSLOG files. A best practice is to move them onto a separate volume. When done, click Next.
  3. On the Review Options screen, review your settings and then click Next.
  4. On the Prerequisites Check screen, review the results and then click Install.
  5. After the installation and replication of Active Directory objects completes, the server will reboot.

5.Deploy DC using offline media IMF #

Deploy DC using offline Media.

As an IT Administrator, what happens when you get instruction from your superior that you need  to deploy a new Domain Controller in a remote site, but your ntds.dit file is over Gigabytes of size, and your WAN is very slow?

So, to solve this issue, we can always deployed the additional Domain Controller using the install from media (IFM) method.

Using the IFM method, you can dramatically reduce the amount of replication traffic that is introduced during the installation of an additional DC.  Only objects that were modified, added, or deleted since the installation media was created will be replicated.

This is just a simple step but workable in my LAB environment.

For this demo, i will be using ntdsutil.exe and will continue will normal domain installation.

1 – On your DC server (DC1), open CMD and type ntdsutil.exe, next type

  • Activate instance ntds then enter.
  • next, type IFM and enter
  • next, type create sysvol full c:\ifm and enter


2 – If the process successfully, you will see information in the CMD stated that “IFM media created successfully in c:\ifm”


3 – Next, in your ADDS Server, open explorer and browse to IFM folder to verify the existence of the folder.


4 – Next, make sure you share the IFM folder so that the other remote server can access to ADDS server and copy IFM server from the ADDS Server to remote side server…


5 – Once you successfully copy the IFM folder into remote site server (in my demo the server name is OSI-ADDS-IFM), on the server open Server Manager and click on the exclamation mark, and then click promote this server to a domain controller…


6 – On the Deployment Configuration, click Add a domain controller to an existing domain, and then in the Domain box, key in your domain name and click next…


7 – Next, on the Domain Controller Options, make sure Domain Name System (DNS) and Global Catalog (GC) is selected and then key in your password and proceed with Next…


8 – Continue next on the DNS Options…


9 – On the Additional Options, click Install from Media and browse for the ifm folder that you copy from the ADDS primary server… and then click verify button to confirm. And then click next…


10 – On the Path click next to continue…


11 – On the Review Options click next…


12 – On the last step, check on the Remote Side Server (DC1) to confirm that all the Domain Controller information has been deploy successfully.



6.Client check AD tools #

Check or change logged on domain controller.

You may need to switch the domain controller a client computer is connecting to if you are troubleshooting a Windows domain issue. Doing so has helped me a few times to determine if there is a problematic domain controller on the network. Here’s how it’s done.

Find Current Domain Controller

You can grab the domain controller that the computer is currently connected to with these steps:

Select the “Start” button.

Type “CMD“.

Hold “Shift” and right-click “Command Prompt“.

Select “Run as different user“.

Type credentials for a Domain Admin user account.

At the Command Prompt, type:

  • nltest /dsgetdc:domainname
  • echo %logonserver%

Switch Domain Controller Command

Actually switch the domain controller computer is using with these steps.

Select the “Start” button.

Type “CMD“.

Hold “Shift” and right-click “Command Prompt“.

Select “Run as different user“.

Type credentials for a Domain Admin user account.

At the command prompt, type:

nltest /Server:ClientComputerName /SC_RESET:DomainName\DomainControllerName


echo %logonserver% 
set  logonserver=\\server1

set logonserver

open Command Prompt
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\user>echo %logonserver%

C:\Users\user>set logonserver

C:\Users\user>set logonserver=\\ServerName2

C:\Users\user>set logonserver

C:\Users\user> echo %logonserver%

Note: This option is not permanent, as a restart of the computer may grab a different DC.

Set Domain Controller Via Registry

Hold the Windows Key and press “R” to bring up the Windows Run dialog.

Type “Regedit“, then press “Enter“.

Navigate to:







Create a String value called  “SiteName“, and set it to the domain controller you wish the computer to connect to. (i.e. DC1.domain.com)


ClientComputerName = Name of the client computer you want to switch domain for.

DomainName = Name of Domain.

DomainControllerName = Computer name of domain controller.

Help Guide Powered by Documentor
Suggest Edit