Preparing a Windows server to become a domain controller

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 prepare a Windows Server installation to become a domain controller before we promote it to become one.

The following steps are my time-tested recommended practices for production domain controllers within enterprises. I highly recommend these steps to create highly reliable domain controllers.

Intending to do the right thing

The first few items on the list of preparations involve having the right ideas about promoting domain controllers throughout their life cycles:

• Intend to create at least two domain controllers per Active Directory domain: This way, both servers can be advertised to networking clients as LDAP servers and DNS servers. Then, when you have to reboot one of at least two servers, these clients won't be hindered. Also, restoring a domain controller while another domain controller is still available allows for scenarios such as non-authoritative restores, domain controller cloning, and domain controller re-promotion.
• Intend to implement role separation: By any means, do not misuse a domain controller as an exchange server or SQL server, unless it's a Windows Small Business Server. The DNS server, DHCP server, and NPS server roles are gray areas here, which should be addressed with common sense; if it means a domain controller will be harder to restore, manage, or decommission, separate the roles.

Dimensioning the servers properly

Now, let's look at how to dimension intended domain controllers:

• Intend to create equal domain controllers in terms of hardware dimensions: It's tempting to place one big server and one smaller server as domain controllers but consider the possibility of having to move Flexible Single Master Operation (FSMO) roles or other loads from one domain controller to another. Since domain controllers are randomly assigned to networking clients inside an Active Directory site, clients accessing a server with fewer resources may not exhibit a consistent and acceptable user experience.
• Dimension the intended domain controllers properly in terms of hardware: Domain controllers offer the best performance when they can cache the Active Directory database, ntds.dit, in RAM. Plan for ample room in RAM to cache up to 4 KB per Active Directory object, plus a 10 MB minimum for the main objects and partitions. You should start with the minimum RAM required to install Windows Server and then add on the additional memory for Active Directory Domain Services (AD DS). For physical servers, use RAID and separate spindles for storage of Active Directory-related data when possible. Use hardware that will be covered by the manufacturer's (extended) guarantee, support, and life cycle policies for the period in which you need to rely on the domain controller.
• Dimension the intended domain controllers properly in terms of software: Use a version of Windows Server that will be covered by Microsoft's (extended) support and life cycle policies for the period in which you need to rely on the domain controller.
• Implement the Server Core version of Windows Server when possible: Server Core installations of Windows Server offer higher availability and a smaller attack surface compared to Windows Server installations with the Desktop Experience feature. However, some agents and other software components in use within the organization might not properly run on Server Core installations. In the latter scenario, Windows Server installations with the Desktop Experience feature (called Full Installations in previous versions of Windows Server) should be performed, obviously.
• Install the latest firmware for devices and/or integration components: On physical boxes that you intend to use as a domain controller, install the latest stable firmware for the Basic Input/Output System (BIOS), the storage controller(s), the video card(s), and Network Interface Card(s) (NIC(s)). On virtual machines, implement the latest stable version of the integration components or VMware tools and follow the recommended practices from the vendor of the hypervisor platform.
• Use a virtualization platform that offers the VM-GenerationID feature: Place virtual domain controllers on a virtualization platform that offers the VM-GenerationID feature. This will offer the domain controller virtualization safeguards that allow administrators to take snapshots of domain controllers without compromising the integrity of the Active Directory database. Also, domain controller cloning is available on these virtualization platforms.

Preparing the Windows Server installations

Before you install Windows Server on intended domain controllers, perform these actions:

• Run the memory diagnostics from the Windows Server installation media: The Windows Server DVD allows administrators to check the RAM of physical and virtual machines to ensure that the memory used by the Windows Server installation is not faulty. Checking beforehand means you don't have to replace faulty memory after going live.
• Run sysprep.exe on cloned disks: When the Windows Server installation is the result of the cloning of a disk with a Windows Server installation on it, ensure that the Windows Server installation is sysprepped. You wouldn't want the Security Identifier (SID) on the cloned disk to become the SID for the new Active Directory forest or domain you might be creating.

Preconfiguring the Windows servers

After Windows Server is installed, configure these items on the Windows Server instance, either through Server Manager on Windows Server installations with the Desktop Experience feature or by using sconfig.cmd on Server Core installations:

• Change the hostname for the Windows Server installation. Leverage the server naming convention and/or policy within the organization.
• Check for proper Windows activation of the Windows Server operating system.
• Update the Windows Server installation with the latest updates.
• Configure the server with at least one static IPv4 address and/or a static IPv6 address. Leverage the networking plan and zone assignment policies within the organization. Avoid multi-homing domain controllers.

  Tip

  When the intended domain controller is to run as a virtual machine within a cloud environment, such as Amazon's AWS or Microsoft's Azure, let the cloud provider assign the IPv4 and/or IPv6 addresses, because manually setting these addresses might break the connectivity of the Windows Server installation. Instead, use IP address reservations to ensure the intended domain controllers remain reachable over the same addresses.

• Check for at least one connected LAN connection: Without a connected LAN connection, the promotion of a domain controller will fail. This is by design.
• Configure a proper naming resolution: As the DNS plays a vital role in locating Active Directory, ensure the DNS is properly configured. Plan for an Active Directory-integrated DNS. Don't forget the DNS stub zones and/or conditional forwarders when creating a new Active Directory domain and/or forest. Deploy Windows Internet Name Service (WINS) or DNS GlobalNames zones in legacy environments.
• Configure the page file correctly.
• Implement information security measures: Deploy agents for anti-malware, uninterruptible power supplies, backup and restore, Security Incident and Event Management (SIEM), Technology State and Compliance Monitoring (TSCM), advanced threat analytics, and other information security measures your organization's policies might require.

Documenting the passwords

In large organizations, you can't get anything done without the proper changes being filed through change management. Even if your organization doesn't require these steps, it's still a recommended practice to document at least these items:

• Document the password for the built-in administrator account: When deploying a new Active Directory forest or domain, deploy using a pre-configured password for the built-in administrator account. After successful promotion, change the password to one that you intend to assign to this account for a longer period. Document the latter password in a password vault.

  Tip

  As domain controllers are promoted using scripts, there is a chance the password for the built-in account will linger around unintentionally. Also, the password initially set for this account is stored with a weaker hashing algorithm than changed passwords.

• Document the Directory Services Restore Mode (DSRM) password: In dire situations, when the Active Directory-related services are no longer able to start, an administrator can sign in to the server using a fallback account with the DSRM password. Intend to use different DSRM passwords for each domain controller and document these properly in a password vault.

See also

See the Creating conditional forwarders recipe in Chapter 9, Managing DNS, to create conditional forwarders.