Domain Controller Sizing and Specification

We have examined how the Domain and Application Directory partitions influence the size of the Active Directory database and how to estimate the size of domain partitions based on number of users within each domain. In this section, we focus on the DCs housing this database and how they should be best configured, promoted, and placed for optimum performance and service.

We begin by looking at best practices for DC hardware configuration, focusing on components such as disk, memory, and CPU. Next, we examine any specific placement considerations, and then we discuss the promotion phase, the options available, and how the process can be automated and controlled.

Choosing a Specification

Estimating the requirements of a DC's hardware configuration is as difficult as estimating the size of the Active Directory database before deployment. The demands of one environment will be different from any other. It is difficult to predict the load and therefore the ideal hardware configuration of a DC.

Microsoft has set out some basic recommendations for DC CPU and memory requirements, and some suggested best practices for disk configurations.These recommendations can be found in the Windows Server 2003 Resource Kit Deployment Guide, available at recommendations and best practices are explored further in this section, beginning with disk configurations and disk space requirements. We then move on to CPU and memory recommendations.

Minimum Requirements

In addition to DC specific requirements, the minimum system requirements for Windows Server 2003 as set out by Microsoft must be adhered to. These requirements are detailed in Table 7.11.

Table 7.11 Windows Server 2GG3 Minimum System Requirements


Standard Edition

Enterprise Edition

Datacenter Edition

Minimum CPU

133 MHz

133 MHz for

400 MHz for x86-based




computers; 733

733 MHz for Itanium-

MHz for Itanium-

based computers

based computers


55G MHz

733 MHz

733 MHz

CPU speed

Minimum RAM








minimum RAM

Disk space for


1.5GB for x86-based

1.5GB for x86-based


computers; 2.0GB


for Itanium-based

2.0GB for Itanium-


based computers

Disk Configuration

Each DC houses a local copy of the Active Directory database. The DCs can, therefore, be thought of as "database servers" and thus configured and optimized in much the same way as a database server. In addition to the Active Directory database, each DC stores transaction log files relating to the database and a local operating system. These different components each has its own requirements from a disk configuration standpoint, since some are read intensive while others are write intensive. The trick to configuring disks in a DC is to meet the needs of all (or as many as possible) of these components.

Microsoft makes several recommendations concerning both disk configuration and disk space requirements.These are summarized in Table 7.12 and extracted from the Windows Server 2003 Deployment Guide available at

Table 7.12 Recommended Domain Controller Disk Configurations

Operations Performed Disk Configuration


Operating system

Active Directory log files

Active Directory database and SYSVOL files

Read and write operations Mostly write operations Mostly read operations


RAID 5 or RAID 0+1

Other relevant statements made in the same MICROSOFT paper include the following:

■ For DCs accessed by fewer than 1000 users, all four (database, logs, operating system, SYSVOL) can be collocated on the same RAID 1 array.

■ For DCs accessed by more than 1000 users, do the following:

1. Place logs and database on separate RAID arrays.

2. Place SYSVOL and the database on the same RAID array.

Disk Space Requirements

Microsoft suggests the following minimum requirements for the four DC components:

■ General Assume a GC server stores 100 percent of all object data for its local domain partition and 50 percent for all other domain partitions.This is covered in further detail in the section Global Catalog Server Sizing and Specification.

■ Database Allow for 0.4Gb per 1000 users.This was already discussed in the previous section Disk Configuration.

■ Logs Allow at least 500MB free space

■ SYSVOL Allow at least 500MB free space

■ Operating System Allow at least 1.5GB free space

Memory and CPU

Microsoft has published some best practices for DC memory and CPU requirements that depend on the number of users being supported in the site where the DC is located. Table 7.13 summarizes the suggested minimum specifications, as found in the Windows Server 2003 Deployment Guide available at reskit/deploykit.mspx.

Table 7.13 Recommended Domain Controller CPU and Memory Requirements

User Per No. of Domain CPUs Required Per Memory Required Per

Domain in Site Controllers Required Domain Controller Domain Controller



1 x 850 MHz





2 x 850 MHz





2 x 850 MHz





4 x 850 MHz



> 10000

One per 5000 users

4 x 850 MHz



Experience shows that while fast processors are important when configuring DCs, the more essential component is physical memory. DCs host several critical processes and services, including the Kerberos Key Distribution Center, the Active Directory database, and (optionally) DNS, each of which has its own memory demands on the DC.

The process LSASS.EXE, for example, uses more memory as the Active Directory database grows. It is highly recommended, therefore, that DCs deployed into forests where a large number of objects and hence a large Active Directory database exist have 2GB or more of RAM installed, since excessive paging might be experienced if less RAM is installed. Monitor the memory used by the LSASS.EXE process as well as paging activity on DCs and add more RAM to DCs if deemed necessary.

Naturally, it is difficult to predict the precise requirements for CPU and memory. It is therefore of paramount importance that these components be monitored over a period of time such that bottlenecks and potentials issues can be predicted and addressed before any detrimental effects are seen in the Active Directory environment. Solutions such as the Microsoft Operations Manager (MOM) or NetIQ's Application Manager can be used to monitor DC components and perform trend analysis. This can help predict whether changes are required to DC components.

Placement Considerations

Traditionally, Microsoft has never published hard rules for deciding where to locate Active Directory infrastructure components. Recently, however, they have provided some detail and recommendations via the Windows Server 2003 Deployment Resource Kit.This covers DC, GC, FSMO, and DNS service placement and suggested algorithms for each. DC and GC placement discussions follow.

Microsoft has never published a definitive algorithm for deciding which locations should have DCs installed and which should be able to cope without local DCs.The flow diagram in Figure 7.3 offers a basic algorithm, found in the Windows Server 2003 Deployment Resource Kit. It focuses on remote administration, physical security, and WAN availability and performance. While it only asks the most basic questions about the location and WAN links, it can be seen that if a location has poor WAN availability and requires 24x7 authentication, then a DC will always be required, according to the algorithm. The stated example is often the case in a large, distributed, financial organization's network; thus, most or all locations will qualify for a DC.

Figure 7.3 A Suggested Algorithm for Determining Domain Controller Placement

Will the DCs be physically secure?

Will the DCs be physically secure?

Do not place a DC at the location

An algorithm has already been described in the section The Implementation Plan that helps identify locations that should receive Active Directory infrastructure components, in the form of a DC and/or GC server. Microsoft also has documented its own suggestions regarding DC placement.Table 7.14 shows Microsoft's suggestions regarding the number of DCs that should be deployed to a location, based on user population at that location. Up to a population of 1000 users, one DC is believed to suffice, while populations between 1000 and 10,000 should receive two DCs. Beyond 10,000, one DC should be deployed for each 50,000 users in the location.

Table 7.14 Microsoft Recommended Number of Domain Controllers Per Site

User Per Domain in Site

No. of Domain Controllers Required









> 10,000

One per 5000 users

The Promotion Strategy

Now that we have decided where DCs are to be placed and their specifications, we need to agree on the methodology that will be used for the promotion of a Windows Server 2003 member server into a DC.The promotion phase is split into two stages—the first deals with a review of the server's configuration, ensuring that it is ready to be promoted to a DC. The second stage, started once stage one has been completed successfully, is the actual promotion. This stage can be performed manually, automatically after stage one checks complete, or even automatically as a separate process, after the completion of the operating system installation onto the member server, without having performed any checks. In this section, we examine all of these options in turn, as well as post-promotion checks.

Pre-Promotion Checks

Before commencing with the promotion of a member server into a DC, several checks and best practices should be performed to ascertain whether the server is ready and able to be promoted.These checks are described in the Table 7.15.

Table 7.15 Pre-Promotion Check List

Pre-Promotion Check Explanation and Benefit

Check event logs for boot- Before promoting a member server, it is of related issues paramount importance that the server boots without errors or issues. Check the event logs for any installation- or boot-related issues and resolve them before continuing.

Configure event logs The number of events logged by a DC is likely to be greater than the number logged on a member server. Consequently, the event log sizes and wrapping properties should be altered appropriately. A group policy should implemented at the DC's OU to facilitate these settings.


Table 7.15 continued Pre-Promotion Check List

Pre-Promotion Check Explanation and Benefit

Configure services Certain services configured to start automatically might not be required within your organization, or might be viewed as potential areas of vulnerability. Review all services and disable those that are not required or deemed vulnerable to attack. Consider using a group policy at the DC's OU level to implement such changes so they are standardized and enforced across all DCs.

Check IP configuration Ensure that IP configuration is correct. Execute ipconfig /all from a command prompt and check that DNS and WINS settings are correct as well as subnet mask and default gateway(s). Correct any misconfigurations found.

Check network connectivity Once IP configurations are checked, network connectivity should be checked. Execute netdiag /v from a command prompt and ensure that connectivity to DNS and WINS occurs without issue. Correct any issues found.

Configure the page file If the prospective DC has multiple physical disks, or multiple disk arrays, consider placing page files on all of these disks so the paging load is spread across multiple disks.

Check FSMO availability In order for a member server to be promoted, con nectivity to one or more FSMO roles is required. If you are creating a new domain in an existing forest, for example, the DNM must be available. If a new DC is being created in an existing domain, then the RID Master must be available. Ensure that these roles are available, and that the prospective DC can resolve their names and connect to the DCs hosting these roles.

Back up the server Before promoting a member server to a DC, it is a best practice to back up the server including the system state and any other services and applications it hosts. The backup may then be used to restore the server to its original state if the promotion phase fails.


Table 7.15 continued Pre-Promotion Check List

Pre-Promotion Check Explanation and Benefit

Check DNS connectivity Use nslookup and/or ping to ensure that a DNS

server hosting the appropriate Windows Server 2003 DNS zone(s) can be located. If a new domain is being created via the promotion phase, then ensure that the corresponding DNS zone is available and that DDNS updates are permitted in that zone.

Manual Promotion

The most popular approach to promoting servers to become DCs is the manual approach. This approach offers the administrator complete control over the promotion phase and is the suggested approach of the author that should be adopted, at least until the promotion of servers is fully understood by the administrators of Active Directory. Once this process is fully understood and administrators are comfortable with automating the process, then this can be done using an answer file. This automated approach is covered in the section Automated Promotion.

The manual approach involves the installation of a Windows Server 2003 member server followed by promotion using the utility dcpromo, which can be launched via Start | Run dcpromo <Enter>. The various options available during the promotion phase are described in Table 7.16.

Table 7.16 Manual Promotion Options




Additional DC or Member Server

DC Type

Select whether the server is to become a new member server or a new DC


Additional domain controller for an existing domain or

Domain controller for a new domain

If creating a new DC in an existing domain, choose Additional Domain Controller. If demoting a DC to a member server, choose Additional Member Server.

If adding a DC to an existing domain, choose Additional domain controller for an existing domain and go to option Domain Name. Otherwise. choose Domain controller for a new domain and go to option Create New Domain.


Table 7.16 continued Manual Promotion Options




Create New Domain

New Domain Name

NetBIOS Domain Name

Domain Name

Database and Log Folders

Shared System Volume


Directory Services Restore Mode Administrator Password


Domain in a new forest or

Child domain in an existing domain tree or

Domain tree in an existing forest

Type the DNS name of the new domain

Type the NetBIOS name of the domain

Type the existing DNS domain name

Specify the locations for the database and log files

Specify the location for the SYSVOL folder


Permissions compatible with pre-Windows 2000 server operating systems

Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems

Type the password to be When booting into DSRM, a local used when booting the logon must be performed since DC into Directory Active Directory is not available. Type

Services Restore mode the password to be assigned to the (DSRM) local administrator account.

If establishing a new domain and a new forest, choose Domain in a new forest.

If creating a new domain in an existing domain tree, choose Child domain in an existing domain tree. If creating a new domain and new tree in an existing forest, choose Domain tree in an existing forest.

Type, for example.

Type mycompany, for example

Type, for example

Place database folders in d:\database and log files in e:\logs, for example

Place SYSVOL folder in c:\windows\sysvol, for example

If users from older, legacy clients need to query Active Directory, choose Permissions compatible with pre-Windows 2000 server operating systems. Otherwise, select Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems.

Once all the information required has been given, a summary window appears that details all the information provided. This summary should be reviewed, and if found to be correct, then the promotion can be started.

Automated Promotion

Rather than directly provide answers to various questions and thus promote a member server to a DC manually, the process can be automated using a dcpromo answer file, which contains all required answers to questions posed by the promotion phase. Dcpromo can be executed in the following way:

dcpromo /answer: answeriile.txt

.. .where answerfile.txt is the name of a text file that contains all the required responses to all dcpromo questions. Naturally, the answers provided in the text file will vary depending on whether the DC is establishing a new domain, new domain tree, or new forest, or simply being added to an existing domain. The various options available and their application are listed in Table 7.17.This is followed by several example answer files, covering some of the promotion options available.

AllowAnonymousAccess Yes/No. No default. Used to determine whether anonymous access is permitted to user and group information.

Table 7.17 Automated Promotion Options


Possible Values

(Defaults in Bold) How and When Used

AdministratorPassword No default.

Specifies the local admin password assigned to a server after demotion.

Determines whether DNS should be automatically installed and configured on the DC.

Name of the new child domain being created (for example,

Create = create new forest. Join = create a new domain tree and join to existing forest.




No default.



CriticalReplicationOnly No values. No default. Specifies that only critical replica-

tion should occur during dcpromo, and that the remaining replication should occur after the new DC is rebooted.


Table 7.17 continued Automated Promotion Options


Possible Values (Defaults in Bold)

How and When Used


DomainNetBIOSName DNSOnNetwork


No default. Yes/No



LogPath %systemroot%\NTDS

NewDomainDNSName No default.


No default.

ParentDomainDNSName No default.



ReplicaDomainDNSName No default.



ReplicaOrNewDomain Domain/Replica

The path to the Active Directory database file (NTDS.DIT).

The NetBIOS name of the domain.

Yes = DNS client is left configured "as is."

No = DNS client is auto-configured to use the new DC as its preferred DNS server.

Indicates that this is the last DC in the domain (used during a demotion).

The path to the Active Directory log files.

The fully qualified DNS name of the new domain.

The password to be used (along with "username") during the promotion phase.

The DNS name of the parent domain.

Yes = reboot when dcpromo completes.

No = do not reboot when dcpromo completes.

The existing DNS name into which the DC is to be promoted.

Replica = promote the server to a DC in an existing domain. Member = demote a DC to a member server in the domain.

Domain = promote the server as the first DC in a new domain. Replica = promote the server to a DC in an existing domain.


Table 7.17 continued Automated Promotion Options


Possible Values (Defaults in Bold)

How and When Used


No default.

The name of the DC from which Active Directory objects are to be replicated, during the promotion.

SafeModeAdminPassword No default.

The DC local admin password used in Restore mode.



The site into which the DC is to be placed.


%systemroot%\ SYSVOL

The path to the SYSVOL share.



Tree = establish a new domain tree in an existing forest. Child = create a new child domain in an existing domain tree.


No default.

The domain in which the "username" exists, used during the promotion phase.


No default.

The username used during the promotion.

Example Answer File

A new domain tree in a new forest can be established as follows:

[DCINSTALL] ReplicaOrNewDomain=Domain TreeOrChild=Tree CreateOrJoin=Create

NewDomainDNSName=<fully qualified DNS domain name > DNSOnNetwork=yes

DomainNetbiosName=<Netbios domain name> AutoConfigDNS=yes

SiteName=[active directory site name (optional)]





SafeModeAdminPassword=<admin defined offline admin account password>



Post-Promotion Checks

Once a DC has been deployed, several checks and amendments should be performed before the DC is "production-ready."These are described in Table 7.18.

Table 7.18 Post Promotion Checks



Default Containers

Domain Controllers OU

Site Membership

Active Directory Database


Remote Desktop

When creating a new domain, ensure that after the first DC has been promoted, the default containers (such as Users, Computers, and ForeignSecurityPrincipals) exist

When creating a new domain, ensure that the Domain Controllers OU exists.

When a DC has been promoted, ensure that it exists in the correct Active Directory site.

Ensure that the database file NTDS.DIT exists in the correct location.

If the DC is to act as a GC server, enable that role using the Active Directory Sites and Services MMC snap-in as follows:

1. Navigate to Sites | <SiteName> | Servers | <DCname> | NTDS Settings

2. Right-click Properties

3. Select Global Catalog

If the DC is the first one in a new forest, it should be assigned the GC role automatically, as part of the promotion phase. Use the preceding steps to verify that this is the case.

Use the command net share to verify that SYSVOL has been shared and is available.

Ensure that all DC (and GC) DNS resource records are registered correctly. Look for resource records of type -kerberos and _ldap in locations: _msdcs.dc._sites.siteName._tcp _msdcs.dc._tcp.

The remote desktop feature is installed but not enabled by default. It is suggested (although not a requirement) that this option be enabled so that the DC can be managed remotely.


Table 7.18 continued Post Promotion Checks

Task Explanation

This can be done via:

Start | Control Panel | System | Remote tab | Allow users to remotely connect to this computer

Event Logs Check all event logs, in particular System and

Directory Services, and ensure that the DC is functioning correctly. Search for errors occurring at boot (in the System log) or that relate to replication issues (found in the Directory Services log).

Was this article helpful?

0 0


  • Sophia Herzog
    How to spec domain controller?
    8 months ago

Post a comment