To make Active Directory a reliable service in any networking environment, the domain controllers need to be available with high integrity. Any changes an administrator needs to make to a deployed domain controller might diminish the availability. Any component or configuration that is misbehaving might diminish the integrity. Therefore, let's look at how to properly prepare a Windows Server installation to become a domain controller, before we actually promote it to becoming a domain controller.

There are three ways to promote a Windows Server installation to a domain controller:

• Using Server Manager and the Active Directory Domain Services Configuration Wizard
• Using dcpromo.exe with an answer file
• Using the Install-DDSDomainController, Install-ADDSDomain or Install-ADDSForest cmdlets from the Active Directory module for Windows PowerShell

In this recipe, we will cover the steps to promote a server using the preceding three ways.

In some organizations, changes can only be made using scripts and must be accompanied by roll-back scripts. In these cases, the answer file and the PowerShell cmdlets offer the best method. On Server Core installations of Windows Server...

Read-only domain controllers were introduced with Windows Server 2008. They have been hugely popular for providing Active Directory Domain Services to branch offices and small perimeter networks.

Read-only domain controllers are the ideal type of domain controllers for environments with the following:

• Poor physical security
• Relatively few user accounts and/or devices
• Relatively poor bandwidth to central datacenters with domain controllers
• Little local IT knowledge and/or experience

These characteristics are typically true for branch offices. Before read-only domain controllers, administrators had to make the hard choice between doing nothing, placing fully (read-write) domain controllers in these locations, or upgrading the available bandwidth and/or resiliency of the networking connections between the branch offices and the...

For Active Directory environments with really low bandwidth or networking resiliency between locations with domain controllers, regardless of whether these are read-only domain controllers or fully-writable domain controllers, promoting a Windows Server installation to a domain controller can take a long time or even fail.

In these kinds of scenarios, for adding an additional domain controller or read-only domain controller to an existing domain, Microsoft offers the Install From Media (IFM) option.

IFM consists of two steps:

• Creating the IFM package
• Leveraging the IFM package

The IFM feature for promoting domain controllers leverages the fact that the contents of the Active Directory database and the Active Directory SYSVOL are largely identical throughout all domain controllers within the domain. The domain controller cloning feature takes this one step further, and leverages the fact that all domain controllers are largely identical; not just the Active Directory-related files, but all operating system files, most agent installations, information security measures, and most configuration items.

When a domain controller is properly prepared and promoted, it can serve as a template.

The domain controller cloning feature requires the following:

• A hypervisor...

One of the requirements for Active Directory Virtualization Safeguards and domain controller cloning is the ability of the hypervisor platform to provide the VM-GenerationID to the virtual domain controller.

To determine whether a virtual domain controller has the VM-GenerationID, perform these steps:

1. Sign in to the virtual domain controller.
2. Open Device Manager (devmgmt.msc).
3. In the taskbar of Device Manager, open the View menu and select Show hidden devices.
4. In the main pane of Device Manager, expand System devices.
5. Search for the Microsoft Hyper-V Generation Counter system device. The existence of such a device means the virtual domain...

Every domain controller has a life cycle. After a certain period of time, it should make room for newer, better, more agile, or even more cost-efficient, domain controllers or other solutions, such as Azure Active Directory (Domain Services).

Before you can demote a domain controller, you should make sure of the following:

• It no longer hosts any FSMO roles.
• It no longer offers networking services, such as DNS, LDAP, RADIUS, or WINS. These protocols are largely manually configured on networking devices and other servers. Demoting a domain controller that offers these services might negatively impact the networking infrastructure. Reconfigure networking devices and servers to use alternative...

It's also an option to forcefully remove a domain controller from Active Directory. While graciously demoting should be the preferred option, you might have to resort to this option.

The process of demoting a domain controller forcefully, consists of these steps:

1. Performing a metadata cleanup
2. Deleting the domain controller from DNS
3. Deleting the computer object for the domain controller
4. Deleting the SYSVOL replication membership

5. Deleting the domain controller from Active Directory Sites and Services
6. Seizing any FSMO roles that were hosted by the domain controller (you can do this first to ensure no impacts for domain members)
7. Taking care of the existence of global catalog servers

If the domain controller was the last domain controller for a domain in an existing forest, the domain will need to be removed as it is now an orphaned...

It's a good thing to know all of the domain controllers throughout an Active Directory domain. This activity doesn't just show the management burden for Active Directory administrators; it also allows them to make smart choices, especially when the environment is breached.

There are two ways to get a good overview of the domain controllers in an Active Directory domain:

• Using Active Directory Users and Computers to inventory...

One of the benefits of deploying read-only domain controllers is their ability to recover quickly from an information security breach.

Since only the passwords for a subset of users is cached on the read-only domain controller when these users signed on through the read-only domain controller and the passwords for really sensitive accounts weren't allowed to be cached on the read-only domain controller, the impact of a stolen read-only domain controller is small, compared to a fully-writable domain controller.

To render the read-only domain controller useless to an attacker or thief, perform these steps:

1. Open Active Directory Users and Computers...