Home / Windows 7

---

Implementing Active Directory Domain Services

The process of implementing Active Directory Domain Services (AD DS) is similar whether you are installing Active Directory for the first time or extending your existing Active Directory infrastructure. In either case, you need to take the following steps:

1. Install the necessary domain controllers, and assign any other needed roles to these servers.
2. Create the necessary organizational units (OUs), and delegate administrative control over these OUs as necessary.
3. Create any necessary user, group, and computer accounts as well as the resources that are required for use in a domain.
4. Use group policy and local security policy to set default settings for user and computer environments in any domains and OUs you created.
5. Create the necessary sites, and configure those sites for use and replication.

In this tutorial, the steps for installing domain controllers, creating OUs, and delegating administrative control.

Preinstallation considerations for Active Directory

Whenever you work with a server role as complex as Active Directory Domain Services, you should take time to carefully consider the physical implementation. As with the installation of Microsoft SQL Server, Microsoft Exchange Server, or Microsoft Internet Information Services (IIS), you should evaluate hardware requirements, plan for the system's backup needs, and consider how the system will be used.

Hardware and configuration considerations for domain controllers

Every domain controller is essentially a database server with a complex replication system, and as such, when you select hardware for and configure domain controllers, you should use all the care and attention that you'd give to one of your mainstay database servers. The hardware you choose for the domain controllers should be correctly sized.

The following guidelines should be taken into consideration:

• Processor:
  The CPU for a domain controller needs to be relatively fast. As soon as you install the second domain controller in a forest, a process called the knowledge consistency checker (KCC) begins running on every domain controller. The KCC is responsible for generating the replication topology and dynamically handling changes and failures within the replication topology. By default, the KCC on every domain controller recalculates the replication topology every 15 minutes. The more complex the replication topology, the more processing power it takes to perform this task. In many cases, even in small domain environments, the calculations performed by the KCC considerably increase CPU utilization. This is acceptable for short durations. However, if the domain controller doesn't have a fast enough CPU, generating the replication topology in a complex environment could take several minutes rather than several seconds, which could severely affect the performance of all other processes running on the server.
• Multiprocessing:
  Some installations might benefit from having domain controllers with multiple CPUs. With multiple processors, you might see significant performance improvements. However, rather than having a single beefy domain controller, it is better to have multiple domain controllers placed appropriately.
• Memory:
  Domain controllers might use more memory than other servers. In addition to running standard processes, domain controllers must run special processes, such as storage engine processes, knowledge consistency checking, replication, and garbage collection. Therefore, most domain controllers should have at least 4 gigabytes (GBs) of RAM as a recommended starting point for full server installations and 2 GBs of RAM for core server installations. Be sure to monitor memory usage and upgrade as necessary.
• Disks:
  The data storage capacity you need depends entirely on the number of objects related to users, computers, groups, and resources that are stored in the Active Directory database. The initial installation of Active Directory requires a small amount of available space. By default, the database is stored in the Ntdis.dit database file on the system volume, as are related log files. When the database and log files are stored together, the storage volume should have free disk space of at least 20 percent of the combined size of the database and log files. When the database and log files are stored separately, each storage volume should have free disk space of at least 20 percent of either the database or the log files, as appropriate.
• Data protection:
  Domain controllers should use fault-tolerant drives to protect against hardware failure of the system volume and any other volumes used by Active Directory. I recommend using a redundant array of independent disks (RAID), either RAID 1 or RAID 5. Hardware RAID is preferable to software RAID.

When configuring the hardware, you should consider where you will install the files used by Active Directory. Active Directory database and log files are stored by default in the %SystemRoot%\NTDS folder, although the Active Directory system volume (Sysvol)-which is created as a shared folder and contains policy, scripts, and other related files-is stored by default in the %SystemRoot%\SYSVOL folder. These locations are completely configurable during installation; you should consider whether you want to accept the defaults or store the files elsewhere. You'll get much better scalability and performance if you put the database and log files on different volumes, each on a separate drive. The Active Directory Sysvol can remain in the default location in most cases.

Note:
If you decide to move the Sysvol, you must move it to an NTFS volume. For security reasons, the database and log folders should be on NTFS volumes as well, but this isn't a requirement.

Active Directory is dependent on network connectivity and the Domain Name System (DNS). You should configure domain controllers to use static Internet Protocol (IP) addresses and have the appropriate primary and secondary DNS servers set in their Transmission Control Protocol/Internet Protocol (TCP/IP) configuration. If DNS isn't available on the network, you have the opportunity to make DNS available during the installation of Active Directory.

If you are using a DNS server that does not use Microsoft DNS, you can verify that the DNS server will work properly with Active Directory by using the Domain Controller Diagnostic Utility (Dcdiag.exe). You can run Dcdiag and test the DNS configuration by typing the following command at the command prompt:

dcdiag /test:dcpromo /dnsdomain:DomainName /newforest

Here, DomainName is the name of the DNS domain in which the domain controller is located. Consider the following example:

dcdiag /test:dcpromo /dnsdomain:cpandl.com /newforest

Here, you run a test of the Active Directory Domain Services Configuration Wizard (Dcpromo.exe) to see if the DNS domain cpandl.com is compatible with creating a new forest. Any errors in the output of the test would need to be examined closely and resolved.

Configuring Active Directory for fast recovery with storage area networks

Domain controllers are backed up differently than other servers are. To back up Active Directory, you must back up the System State. On Windows Server 2012, there are approximately 50,000 system state files, which use approximately 4 GBs of disc space in the default installation. These files must be backed up as a set and cannot be divided. To keep the System State intact when you place the volumes related to Active Directory on a storage area network (SAN), you must also place the operating system (system and boot volume) on the SAN. This means that you must then boot from the SAN.

Booting from a SAN and configuring Active Directory so that the related volumes are on a SAN enables several fast recovery scenarios-most of which make use of the Volume Shadow Copy Service (VSS). For instance, suppose that a domain controller is using the C, D, and E volumes: C for the operating system and Sysvol, D for the Active Directory database, and E for the Active Directory logs. Using a third-party backup utility that makes use of the Volume Shadow Copy Service, you might be able to use that backup software to create shadow copies of the System State on separate logical unit numbers (LUNs) on the SAN.

On the SAN, let's say that volumes C, D, and E correspond to LUNs 1, 2, and 3 and that the current shadow copy of those volumes is on LUNs 7, 8, and 9. If Active Directory failed at this point, you could recover by performing the following steps:

1. Use the DiskRAID utility to mask the failed LUNs (1, 2, and 3) so that they are no longer accessible.
2. Use the DiskRAID utility to unmask the shadow-copied LUNs (7, 8, and 9) so that they are usable.
   
   NOTE:
   The DiskRaid utility is a command-line tool for configuring and managing RAID storage subsystems, such as those associated with network-attached storage (NAS) and SANs. Windows 8 and Windows Server 2012 might be the last versions of Windows to support DiskRaid. Storage technologies are in transition from traditional approaches to standards- based approaches. As a result, several popular tools and favored features are being phased out, including DiskRAID.
   
   
3. You then boot the domain controller to firmware, set the boot device to LUN 6, and then reboot.
4. You've now recovered Active Directory. When the domain controller starts, it will recover the Active Directory database and synchronize with the rest of the domain controllers in the organization through regular replication.

SECURE COMMUNICATIONS FOR DOMAIN CONTROLLERS:
One reason for configuring secure communications by default is to prevent certain types of security attacks. Secure communications specifically thwart man-in-the-middle attacks, among others. In this attack, a third machine gets between the client and the server and pretends to be the other machine to each. This allows the man-in-the- middle machine to intercept and modify data that is transmitted between the client and the server. With that said, if you must disable secure communications, you can do so.

To disable the secure communications requirement, follow these steps:

1. Open the related Group Policy Object (GPO) for editing in the Group Policy Management Editor.
2. Expand Computer Configuration, Windows Settings, Security Settings, Local Policies, and then select Security Options.
3. Under Security Options, press and hold or right-click Domain Member: Digitally Encrypt Or Sign Secure Channel Data (Always), and then select Properties.
4. In the Properties dialog box, select Disabled and then tap or click OK.

Connecting clients to Active Directory

Network clients connect to Active Directory for logon and authentication and to perform Lightweight Directory Access Protocol (LDAP) lookups. In a standard configuration of Active Directory, communications between clients and servers are secure and use either Server Message Block (SMB) signing or secure channel encryption and signing. Secure communications are used by default because the default security policy for Windows Server 2008 and later has higher security settings than the security policies for previous versions of Windows. All current Windows clients natively support SMB signing, secure channel encryption and signing, or both.

The converted disk will now show as dynamic in Disk Management.