Active Directory Domain Services (AD DS) is the foundation for many network services in Windows-based networks including authentication, authorization, and configuration management. While subsequent chapters discuss implementing and managing these and other features available in Active Directory this chapter focuses on managing the service itself. For example, its important to understand the basic components used to build a hierarchy of domains, how to configure replication, and how to manage the various operations masters roles used by AD DS domains and forests. In this chapter you will learn about the following:
Domains are the basic building blocks of AD DS. At the risk of confusing you, AD DS domains are discrete from and yet related to Domain Name Services (DNS) domains. They are distinct in that they perform many functions that are entirely separate from DNS domains such as user authentication and group policy. AD DS evolved from LAN Manager and Windows NT domains where the term was used with no correlation to DNS domains. They are related to DNS in that AD DS integrates with DNS for name resolution. Although it is possible to create an AD DS design that does not resemble the DNS namespace I recommend against doing so to avoid confusing users.
In AD DS a domain is a logical group of computers that share a directory database. A tree is one or more AD DS domains that have trust relationships with one another. Forests are one or more trees grouped together. Organizations can use domains, trees, and forests to organize their directory services according to the design of their business units, or their geographic distribution, or whatever combination works best for their situation. Figure 1 presents a notional architecture, the rectangles represent the two forests, and ovals represent the domains. In this example kurtdillard.com is the root domain for the entire organization, within the same tree are two additional layers of domains, americas.kurtdillard.com is the second layer, the other three form the third. All of the domains in the kurtdillard.com forest are located in the same tree. The other tree, europe.kurtdillard.com, consists of only two layers. This logical architecture also reflects the DNS namespace for the organization.
Figure 1: Hierarchy of Active Directory Forests and Domains
Production architecture could be as complex as the example, or even more complex, or it could be a simple as a single domain within a single forest. What is suitable will vary from one organization to another, however designing an optimum domain and forest structure is beyond the scope of this book, review the references section at the end of the chapter. for resources on exploring this topic. Each domain has at least one domain controller (DC) that hosts the AD DS database, best practices dictate that each domain have at least two DCs to provide redundancy in case one of them fails. There are several additional roles assigned to DCs, these are discussed later in this chapter. The objects and containers within an AD DS database are discussed in Creating and Maintaining Active Directory Objects.
Installing new AD DS forests is straight-forward, as you saw in the first exercise in Configuring DNS for Active Directory. Installing new domains and trees within an existing forest, and installing new DCs within existing domains is even easier, to prepare for the exam you should familiarize yourself with each of the options available in the Active Directory Domain Services Installation Wizard as it is likely you will encounter at least a couple of questions relating to it. It is also important to understand the options available for automating the installation using an answer file and manually installing from a command prompt, especially with the advent of Server Core in Windows Server 2008.
You automate AD DS installations using an answer file. If you are familiar with the graphical installation wizard answer files are easy to understand because you all you are doing is providing the same information in a text file. You can create and modify answer files in any text editor including Notepad, you specify parameter names and values on separate lines with an equal sign between, for example, including InstallDNS=Yes will force the installation of the DNS Server role. The following list shows the parameters available, which parameters are required depends upon what task you are accomplishing. For example certain parameters needed when creating a new forest but others are needed when installing a new DC in an existing domain. The parameter name appears first in bold; followed by the possible values; then the default value, if any, in italics, and then a brief description
· DomainLevel; 0|2|3; The domain functional level cannot be lower than the forest functional level. Default is set to the existing forest functional level or the value set for /ForestLevel – Determines the domain functional level when creating a new domain as follows:
o 0 = Windows 2000.
o 2 =Windows Server 2003.
o 3 = Windows Server 2008.
· DomainNetBiosName; "domain_NetBIOS_name" – Assigns a network basic input/output system (NetBIOS) name to the new domain.
· ForestLevel; 0|2|3; The default forest functional level when creating a new forest is Windows 2000 (0) – Do not use this parameter when adding a DC to an existing forest. It determines the forest functional level when creating a new forest as follows:
o 0 = Windows 2000.
o 2 =Windows Server 2003.
o 3 = Windows Server 2008.
· InstallDNS; Yes, No; Default is determined based on the environment; – Use to specify whether or not DNS will be installed (replaces CreateDNSDelegation in previous versions of DCPromo.exe).
· LogPath; "path_to_log_files"; %SYSTEMROOT%\NTDS – Specifies a local directory on that contains the domain log files; e.g. C:\Windows\NTDS.
· NewDomain; Tree, Child, Forest; Forest – Specifies whether to create a new forest, a new domain tree in an existing forest, or a child of an existing domain.
· NewDomainDNSName; "DNS_name_of_domain" – Specifies the FQDN for the new domain.
· ParentDomainDNSName; "DNS_name_of_domain" – Specifies the FQDN of the parent domain when creating a child domain.
· Password; "password", * – Specifies the password corresponding to the credentials used for the operation; use * to prompt for credentials.
· PasswordReplicationAllowed; "security_principal", None – Use only when installing a read only DC (RODC), it determines which accounts will have their passwords replicated to the new RODC. Specify "None" if you want to keep the value empty.
· PasswordReplicationDenied; "security_principal", None – Use only when installing an RODC, it determines which accounts will blocked from having their passwords replicated to the new RODC. Specify "None" if you want to keep the value empty. Members of the following groups are denied by default: Account Operators, Administrators, Backup Operators, Server Operators, and the Denied RODC Password Replication Group (which includes Cert Publishers, Domain Admins, Enterprise Admins, Enterprise Domain Controllers, Enterprise Read-Only Domain Controllers, Group Policy Creator Owners, the krbtgt account, and Schema Admins).
· RebootOnCompletion; Yes, No; Yes – Use to force the computer to reboot at the end of the installation process whether or not it was successful.
· RebootOnSuccess; Yes, No, NoAndNoPromptEither; Yes – Use to force the computer to reboot if installation is successful.
· ReplicaDomainDNSName; "DNS_name_of_domain" – Determines the FQDN of the domain in which you want to promote the new DC.
· ReplicaOrNewDomain; Replica, ReadOnlyReplica, Domain; Replica – Specifies whether to install an additional DC, an RODC, or to create a new domain.
· ReplicationSourceDC; "DNS_name_of_DC" – Specifies the FQDN of the DC to use for replication during the installation.
· ReplicationSourcePath; "replication_source_path" – Specifies the path of the data file to use for the installation of a new DC.
· SafeModeAdminPassword; "password"; Default is empty password (it is required that you do not leave this value blank) – Used to provide the password for the administrator account when starting the computer in safe mode.
· SiteName; "site_name"; The default depends on the type of installation; in a new forest it will be Default-First-Site-Name; in all other cases it is the site that is assigned to the subnet that includes the IP address of the DC. – Determines the site for the new DC.
· SkipAutoConfigDns – Use to skip automatic configuration of DNS.
· Syskey; none, system key; none – Indicates the system key for the media which contains the replication data.
· SysVolPath; "path_to_database_file"; %SYSTEMROOT%\sysvol – Determines the local path for to the sysvol folder, e.g., C:\Windows\SYSVOL.
· TransferIMRoleIfNecessary; Yes, No; No – Use to determine whether to transfer the infrastructure master role to the new DC. Enter “Yes” to transfer the role if needed (you also need to specify "/ConfirmGC:No"); Enter “No” if you do not want to transfer the role.
· UserDomain; “domain_name" – Determines the domain name for the credentials used for the operation. If no value is provided the domain of the computer is used.
· UserName; "user_name" – Specifies the credentials used for the operation. If no value is provided the credentials of the current user are used for the operation.
To perform the installation enter the following at a command prompt with administrative privileges:
Where %path% is the path for the answer file you created. It is also possible to type out all of the parameters and values in the command itself in this format:
The command will be very long and complex though, I recommend that you use answer files instead. You can also review the options for unattended installations by entering dcpromo /?:Promotion at a command prompt. The list of options for unattended installations is long, however I do not believe that you need to memorize it in order to prepare for the exam, instead just be sure that you understand what is possible and what might go awry with unattended installations.
Note: Read only domain controllers (RODC) are a new capability in Windows Server 2008 intended to help protect networks when one or more domain controllers has to be placed in a location that cannot be physically secured such as a branch office. They are discussed in Configuring Additional Active Directory Server Roles.
Upgrading from and interoperating with previous versions of Active Directory require planning and familiarity with the adprep tool. Upgrading from Windows NT 4.0 Directory Services is a unique process and will be covered in the next section.
Windows Server 2008 AD DS includes changes to the AD schema, therefore you must update the forest schema before installing and Windows Server 2008 domain controllers. Before running the AD DS installation wizard or performing an unattended installation of AD DS log into the forest’s schema master with an account that is a member of the Enterprise Admins, Schema Admins, and Domain Admins groups. Then insert the Windows Server 2008 installation DVD, open a command prompt with administrator privileges, navigate to the Adprep folder (for example, e:\sources\adprep), and enter the following:
Wait for the process to complete and allow the changes to replicate across the entire forest before preparing any domains for a Windows Server 2008 domain controller.
After preparing the forest you need to prepare each domain where you will install Windows Server 2008 domain controllers. First, log into the domain’s infrastructure operations master with an account that is a member of the Domain Admins group. Then insert the Windows Server 2008 installation DVD, open a command prompt with administrator privileges, navigate to the Adprep folder, and enter the following:
Wait for the process to complete and allow the changes to replicate across the forest before installing any Windows Server 2008 domain controllers.
Tip: AD DS includes several special roles that can only be held by single domain controllers in the domain, these are called flexible single master operations (FSMO) roles. Finding the infrastructure FSMO holder is easy in Windows Server 2008 domains, open Active Directory Users and Computers, right-click on the domain, select Operations Masters… and click on the Infrastructure tab. There can only be one schema FSMO holder for each forest, and identifying it is a little more complex because you use the schema editing tool to do so and Microsoft discourages modifying the schema directly. First you need to register the Microsoft Management Console (MMC) snap-in by entering the regsvr32 schmmgmt.dll from a command prompt. Then you need to open an empty MMC console by clicking Start, then clicking Run, and then entering mmc. Open the File menu, click Add/Remove Snap-in, select Active Directory Schema, click Add, and then click OK. Right-click on Active Directory Schema [%domainname%] and select Operations Masters… from the menu as shown in figure 2, to identify the current schema master for the forest. The user interface is slightly different for the MMC in Windows 2000 and Windows Server 2003, but adding the snap-in is still straightforward.
Figure 2: Active Directory Schema MMC Snap-In.
To prepare a Windows 2000 or Windows Server 2003 forest for RDOCs log into any computer in the forest with an account that is a member of the Domain Admins group. Then insert the Windows Server 2008 installation DVD, open a command prompt with administrator privileges, and enter the following:
Wait for the process to complete and allow the changes to replicate across the entire forest before preparing any domains for a Windows Server 2008 domain controller.
When you upgrade a domain controller running Windows 2000 or Windows Server 2003 you do not need to run the AD DS installation wizard or dcpromo because the server will automatically assume the role of DC after the final restart of the upgrade process. Windows Server 2008 DCs have more restrictive default security policies, to interoperate with clients running Windows NT 4.0 and certain 3rd party operating systems you may need to reduce security by changing the several settings in the Default Domain Controllers Policy group policy.
Figure 3: Editing the Default Domain Controller Policy.
You can learn more about these settings and why you may need to adjust them by reading “Modify Default Security Policies on Windows Server 2008-Based Domain Controllers.”
Caution: I do not recommend that you reduce your environment’s security by adjusting the settings as described above. It would be much better in the long run to upgrade the clients to operating systems that support the more restrictive values for these settings.
Another change you may wish to make when migrating from Windows 2000 AD is to update the permissions on all of the group policies in the domain to ensure that the Group Policy Modeling feature works. Microsoft has prepared a collection of scripts that you can download, see Group Policy Management Console Sample Scripts. By default the scripts will be installed in %programfiles%\Microsoft Group Policy\GPMC Sample Scripts. Execute the following from a command prompt to update the permissions:
Windows Server 2008 AD DS supports three functional levels: Windows 2000, Windows Server 2003, and Windows Server 2008. The newer versions support additional features, however, once raising the functional level for a forest or domain you cannot revert. Ensure that all of the domain controllers are running a version of Windows that supports the functional level you intend to use. To raise the domain function level do the following:
Click Start, select Administrative Tools, and then click Active Directory Users and Computers.
Right-click on the domain, then select Raise domain functional level...
Select the desired functional level and click Raise.
Click OK to confirm your choice.
To raise the forest function level and the functional levels of all domains in the forest do the following:
1. Click Start, select Administrative Tools, and then click Active Directory Domains and Trusts.
2. Right-click on Active Directory Domains and Trusts, then select Raise Forest Functional Level.
3. Select the desired functional level and click Raise.
4. Click OK to confirm your choice, click OK again.
Raising the functional level from Windows Server 2003 to Windows Server 2008 enables several new features including Kerberos support for Advanced Encryption Services (AES 128 and 256), detailed recording of last interactive logon information, fine-grained password policies, and Distributed File System (DFS) replication of the contents of SYSVOL.
You cannot migrate directly from Windows NT 4.0 to Windows Server 2008. Microsoft recommends a two process to upgrade domains from Windows NT 4.0, upgrade to Windows Server 2003 and then upgrade to Windows Server 2008. I do not think it is likely that you will encounter questions that require you to know all of the details of every step in the process but rather that you understand the limitations and how to overcome them. If you are faced with this challenge in a production environment here are links to useful resources from Microsoft:
There are three basic scenarios involving the decommissioning of DCs: removing one from a domain; removing the last one from a domain; and removing the last one from a forest. You can initiate the process using the graphical interface by launching dcpromo on the domain controller, you can do it from a command prompt by entering dcpromo from a command prompt with the appropriate parameters. Enter dcpromo /?:demotion to see a full list of parameters available for answer files and the command prompt. When you use the AD DS Installation Wizard you are asked to make a series of decisions about the demotion such as whether or not to delete any application directory partitions stored on the DC, whether to remove any DNS delegations pointing to the server. If you are deleting the last DC in a domain be sure to perform the instructions that appear on the Delete the Domain page of the wizard such as backing up cryptographic keys, you will need to enable the checkbox on this page. You will be prompted to provide credentials for an account that is a member of the Enterprise Admins group if you are not logged on with an account that belongs to it. Removing the last DC in a forest is essentially the same, however you must start the process while logged in with an account that belongs to the Enterprise Admins group for the forest or the Domain Admins group in the forest’s root domain.
A trust is a relationship between domains that make it possible for a user in one domain to be authenticated by a domain controller in the other. Trusts make it easier to grant access to shared resources to users in other domains. A one-way trust is a single trust relationship, if domain A trusts domain B then users from domain B can be granted permissions on objects in domain A. A two-way trust means that both domains trust the other and therefore users from either domain can be granted permissions on objects in the other.
Transitive means that if one domain trusts another, and that second trusts a third one then the first will also trust the third one. For example, in figure 4, Washington trusts Paris, and Paris trusts Moscow, therefore Washington also trusts Moscow. Trusts were one-way and not transitive by default in Windows NT 4.0 and earlier versions, since Windows 2000 they have been two-way and transitive by default.
Figure 4: Transitive Trusts
While most of the time two-way transitive trusts are sufficient, there are situations where a one-way non-transitive trust would be better. A hypothetical example may help, pretend that Company A has just acquired Firm B. Company A instructs Firm B to configure their Windows domains to trust the Company A domains, however Company A does not reciprocate. Until Company A management has determined which Firm B employees will be laid off and which will be retained this arrangement will minimize the risk of a disgruntled one at Firm B doing something unpleasant to Company A resources.
Trusts are established between domains as they are added to a forest, there are a number of things you might want to do to manage these types of trusts. Its also possible that you will need to manually establish trusts to improve authentication times in large trees or to connect to Kerberos realms running on other platforms.
The primary tools for managing trust relationships in AD DS are the Active Directory Domains and Trusts console and the netdom command prompt utility. There are a few other management tasks involving these tools that are covered at the end of this section.
There are four kinds of trusts available, all of which can be either unidirectional or bidirectional. Forest trusts are transitive trusts between two AD DS-based forests that facilitate the sharing of network resources. Shortcut trusts transitive trusts between two AD DS domains within the same forest that are manually created to improve logon times. External trusts are nontransitive trusts between AD DS domains and either NT 4.0 domains or AD-based domains located in separate, untrusted forests. Realm trusts are transitive or nontransitive trusts between AD DS domains and non-Windows Kerberos realms. In a one-way trust the trusting domain allows users in the other domain to access shared resources. In a two-way trust both domains trust the other and users in either can be granted access to resources in the other. To create a trust using Active Directory Domains and Trusts do the following:
1. Right-click on the desired domain and click Properties.
2. Select the Trusts tab and click New Trust, then click Next.
3. Provide the DNS or NetBIOS name of the other domain or realm, then click Next
4. Specify whether the trust will be with a Windows domain or Kerberos realm on the Trust Type page, then click Next. Figure 5 shows this page of the wizard with Active Directory Domains and Trust console and the domain properties dialog box.
5. Depending upon the type of trust selected you may be able to specify the type of transitivity for the trust on the Transitivity of Trust page.
6. Specify the direction of the trust on the Direction of Trust page. Note that an incoming one-way trust means users in the other domain will not have access to resources in this domain while in an outgoing one-way trust users in this domain will not have access to resources in the other.
7. If it’s a realm trust you will also be prompted to provide a password for the trust relationship.
Figure 5: The Trust Type Page of the New Trust Wizard.
To create an external or shortcut trust from a command prompt enter the following command, table 1 briefly explains each parameter:
The second parameter tells netdom what action to take, in this case managing a trust relationship.
Specifies the name (DNS or NetBIOS) of the trusting domain in the trust to create.
Indicates that the other domain will be trusted.
Specifies the name (DNS or NetBIOS) of the other domain in the trust to create.
Instructs netdom to establish a new trust.
Table 1: Netdom parameters for establishing trusts.
To create a realm trust from a command prompt enter the following command. Establishing a real trust requires a few more parameters as described in table 2:
Specifies that the trust is to be created to a Kerberos realm.
Parameter that precedes the password for the new trust.
The actual password for the new trust, it must match the password used in the Kerberos realm.
Table 2: Additional netdom parameters for realm trusts.
An alternate user principal name (UPN) suffix can simplify the logon process by allowing all users within the forest to use the same UPN suffix. The suffix does not have to be a valid DNS domain name. To add one open Active Directory Domains and Trusts, right-click on Active Directory Domains and Trusts, select Properties, then select the UPN Suffixes tab and click Add.
The default scope for authentication across trusts is broad in order to simply management. Users in the trusted domain have the same level of access to resources as users in the local domain. Only external and forest trusts support selective authentication, which allows you to more tightly control access to resources from those domains. If selective authentication is enabled you have to manually assign permissions to each resource you want users in the other domain to be able to access. To define the authentication scope across external and forest trusts open Active Directory Domains and Trusts, right-click on Active Directory Domains and Trusts, select Properties, then select the Trusts tab. Select the desired trust relationship, click Properties, then select the Authentication tab and specify the authentication scope.
AD DS accounts have an attribute called the SID history. Administrators can add users’ old security identifiers (SIDs) to simplify managing access to shared resources during migrations. Unfortunately, this feature might be abused by an attacker who has compromised a DC as they could add SIDs to new accounts granting those accounts unauthorized privileges. By default Windows Server 2008 enables SID filtering on all new external trusts. SID filtering reduces the risk of a malicious user or rogue administrator in the trusted domain from granting themselves elevated privileges in the trusting domain. You manage SID filtering using netdom, from a command prompt enter the following, table 3 briefly explains the parameters:
The second parameter tells netdom what action to take, in this case managing a trust relationship.
Specifies the name (DNS or NetBIOS) of the trusting domain.
Indicates that the other domain will be trusted.
Specifies the name (DNS or NetBIOS) of the other domain in the trust.
Instructs netdom to manage the state of SID filtering.
<yes | no>
Turns SID filtering on or off
Tip: restartable AD DS rather than having to reboot
While forests, trees, and domains represent the logical architecture of AD DS, sites represent the physical network architecture upon which it is deployed. A sound site design and DC placement is necessary to ensure performance and reasonable bandwidth consumption. Typically, a site hosts at least one DC and includes one or more Internet Protocol (IP) subnets that share a high-speed network and are connected to other sites via slower links. When you install the first DC in a new forest a site called Default-First-Site-Name is created, all computers are assigned to this site until additional ones are created. When sites have been defined computers will automatically be assigned to the appropriate one based on their IP address, if their address does not belong to any of the subnets defined for the sites it will be assigned to the Default-First-Site-Name site.
You manage sites and their components using the Active Directory Sites and Services console. Although you can create the objects in any order you wish and easily modify existing ones there is a logical progression that might save you time and effort. First create the site; then define the AD subnets for the site; then create site links between the new site and one or more sites that already exist; finally, assign one or more domain controllers to the site.
To add a site using Active Directory Sites and Services do the following:
1. Right-click on Sites in the console tree and select New Site
2. Type a name for the site in the Name text box.
3. Select a site link object from the list below Link Name and click OK.
To add a server to a site using Active Directory Sites and Services do the following:
1. Navigate to the desired site in the console tree and expand the view by clicking on the plus sign.
2. Right-click on Servers, select New, and then click Server.
3. Specify the name of the server and click OK.
To add a subnet using Active Directory Sites and Services do the following:
1. Right-click on Subnets in the console tree and select New Subnet…
2. Enter the prefix for the subnet address using network prefix notation, e.g. if the 192.168.2.0 subnet had a subnet mask of 255.255.255.0 its prefix would be 192.168.2.0/24 while a subnet of 10.2.0.0 with a subnet mask of 255.255.0.0 would have a prefix of 10.2.0.0/16.
3. Assign the subnet to a site by selecting the site from the Site Name list, then click OK.
To manage a site link using Active Directory Sites and Services do the following:
1. Expand the Inter-Site Transports folder.
2. Right-click the desired transport protocol, either IP or SMTP, the former refers to the protocol native to AD DS, RPC over IP, while SMTP is the Simple Mail Transport Protocol.
3. Select New Site Link.
4. Type a name for the site in the Name text box.
5. Select a site to add to the link from the Sites not in this site link: list and click Add. Repeat this procedure to place more sites in the link, as shown in figure 6.
Figure 6: Adding Sites to a Link.
Creating a site link as described above creates a transitive link between sites, for most situations this is ideal, however if you want to create a link that is not transitive select New Site Link Bridge instead of New Site Link in step 3 above.
You can manage other settings for these objects by right-clicking on them in the console tree and selecting properties, as shown in figure 7. By default replication occurs every 3 hours across a link and each link is available 24 hours per day, 7 days per week. You may want to adjust the cost of your links the replication frequency, and the schedule in order to more closely control bandwidth usage. While RPC over IP is a robust replication protocol for most situations, SMTP is ideal for replication across unreliable network connections. SMTP only supports replication of the schema, configuration, and global catalog and it requires and enterprise certification authority (CA). Note that the AD Knowledge Consistency Checker (KCC) builds the intersite replication topology automatically based on the sites, subnets, and links that you define. Replication will automatically follow the lowest cost routes between sites. The KCC updates the topology every 15 minutes, you can force it to update at any time by navigating to a server object under the site container in Active Directory Sites and Services, right-clicking NTDS Settings for the server, selecting All Tasks, and then clicking Check Replication Topology.
Figure 7: Site Properties Dialog Box.
The KCC automatically assigns the role of bridgehead server to one DC in each site. Replication between sites occurs between these bridgehead servers. Normally there is no need to alter them, if you do and the manually assigned server goes offline replication will be disrupted. To want to manually assign a preferred bridgehead server to a site in Active Directory Sites and Services, navigate to the desired domain controller in the console tree, right-click on it and click Properties. You can select one or more transports and click Add on the General tab to make that DC the preferred bridgehead server, as shown in figure 8.
Figure 8: Manually Configuring a Preferred Bridgehead Server.
This is a quick exercise that will help you practice the tasks discussed in the next part of this section. Previously you added AD DS server role to your practice computer, which resulted in the installation of the first domain controller in your lab. By default, choosing this server role adds two more: the DNS Server and File Services roles. DFS is an optional role service for the File Services role.
1. Open Server Manager.
2. Scroll down to the Roles Summary section and click Go to Roles.
3. Scroll down to the File Services section and click Add Role Services.
4. Select Distributed File System, verify that both of its subcomponents are also selected, DFS Namespaces and DFS Replication.
5. Click Install and complete the Add Role Services wizard.
The Distributed File System (DFS) is a multi-master replication technology for synchronizing folders across two or more servers. It includes two role services: DFS Namespaces and DFS Replication. You can manage these using the DFS Management Console or using several command prompt tools: DfsUtil, DfsCmd, DfsrAdmin, and DfsrDiag. To manage DFS Replication do the following:
1. Open the DFS Management Console.
2. Right-click the Replication node in the console tree and select New Replication Group…
3. Select Multipurpose replication group and click Next.
4. Enter a name, and if desired a description for the replication group, then click Next. You could assign the group to a different domain on this page too, but you probably only have a one domain in your practice lab right now.
5. Add all of the desired servers on the next page and click Next. Click OK if the Start Service dialog box appears.
6. On the Topology Selection page, select Full Mesh if the group has two servers and skip to step 9, otherwise select Hub and Spoke. Note the recommendations described on this page of the wizard, then click Next.
7. Select the master server from the Spoke Members list, click Add, then click Next.
8. Use the default selections on the Hub and Spoke Connections page, click Next.
9. The default bandwidth and schedule are fine for practice, however you should understand how to modify these settings, click Next.
10. Select the master server from the Primary member drop-down list and click Next.
11. Specify the folders to replicate by clicking Add… and entering the details in the Add Folder to Replicate dialog box. When you are done click Next.
12. Select a mirror server and click Edit, then select Enabled, specify a path on the mirror server and click OK. Repeat this for each mirror, when finished click Next.
13. Click Create and complete the wizard.
You can view the status of the replication group by selecting it in the console tree. You can modify its configuration by right-clicking on the group and selecting the desired command.
Note: It may seem strange to discuss DFS in a section focused on Active Directory replication, it certainly does to me and I am the author! While DFS Replication drives replication of the AD DS SYSVOL folder there are no configurable settings visible until after you have installed the DFS role service as described in exercise 1. I am including it here because Microsoft’s preparation guide for exam 70-640 includes it as one of the items under this topic. I suppose this illustrates that while the exam questions may be created and reviewed by technical experts who understand how the technology is used in the real world the people organizing and marketing things at a higher level may notJ.
The global catalog (GC) is the set of all objects that exist anywhere within an AD DS forest. A GC server is a DC that stores a full copy of all of the objects in the directory for its own domain as well as a read-only copy of all objects located in other domains within the forest. These copies only include the attributes marked for inclusion in the global catalog, these are known as the partial attribute set (PAS). An attribute is marked as part of its schema definition.
You use the Active Directory Sites and Services console to add or remove the global catalog from a DC. Navigate to the NTDS Settings of the desired server, right click on it, and select Properties. Clear or check the Global Catalog box to add or remove it from the server.
Normally the only time you would alter the schema is if you were installing an AD-integrated application like Exchange 2007. These sorts of products would normally include a tool to automate the necessary changes. Its unlikely that you will need to manually edit the schema directly, nevertheless, for the exam you should be familiar with the process and the caveats. Be very careful when editing the schema, especially when modifying built-in classes and attributes. Mistakes could cause all sorts of problems including completely fouling up your domain or even your forest. In addition, be careful when adding attributes to the Global Catalog because doing so will increase the amount of data that must be replicated, which could impact performance. The Active Directory Schema MMC snap-in is used to modify the schema, there is no shortcut to it on the Start menu by default so first you must create a new console and add the snap-in to it. Once you have done so navigate to Attributes in the console tree. To add an attribute to the global catalog right-click on it in the details pane and select the Replicate this attribute to the Global Catalog check box. Schema objects that define an attribute are called attributeSchema objects, the mark for GC replication adds an attribute called isMemberOfPartialAttributeSet to it. The default set of attributes that are marked for GC replication are those that Microsoft believes are most likely to be used in searches.
For sites with no global catalog server you may want to enable Universal Group Membership Caching (UGMC) on the DCs so that they do not need to contact the GC server in a different site. When enabled, each user’s universal group membership is cached. To enable UGMC from the Active Directory Sites and Services console navigate to the NTDS Settings of the desired site, right click on it, and select Properties. Check the Enable Universal Group Membership Caching box. You can specify the site where the cache refreshes should be pulled or accept the default. Click OK when finished.
Flexible Single Master Operations (FSMO) roles held by domain controllers were discussed briefly earlier in this chapter. There are five of these roles, each forest has one schema master and one domain naming master; each domain has one infrastructure master, one primary DC (PDC) emulator, and one relative identification (RID) master. The purpose served by FSMO role holder is as follows:
· Schema master – The only DC in the forest that has write permissions to the AD DS schema, to edit the schema you must log into the schema master. By default the first DC installed in a new forest assumes this role.
· Domain Naming master – This is the DC that manages the adding and deleting of directory partitions in the forest. It must be online in order to add or remove domains, application directory partitions, and cross-reference objects and in order to rename domains. By default the first DC installed in a new forest assumes this role.
· Infrastructure master – This DC manages changes to object names are updated for groups located in other domains. By default the first DC installed in a new domain assumes this role.
· PDC emulator – This DC simulates the domain’s PDC for older versions of Windows, its required to process password updates initiated from those clients. Even if there are no older clients all password changes made on any DC in the domain are first replicated to the PDC emulator, failed logons on other DCs are attempted once again on the PDC emulator before the attempt is rejected. By default the first DC installed in a new domain assumes this role.
· RID master – This DC ensures that each security principle created in the domain are assigned a unique relative identifier (RID). The RID master issues blocks of RIDs to the other DCs in the domain so that even if the RID master is offline new security principals can continue to be created. However, when the other DCs exhaust the RIDs they have been assigned no more security principals can be created until the RID master is online. By default the first DC installed in a new domain assumes this role.
Transferring the FSMO roles is straightforward. Open the appropriate tool and reassign the role to a different DC, however both DCs must be online. If you have not done so already create a new MMC console with the Active Directory Schema snap-in as described in the reader tip at the end of the “Preparing a Windows 2000 or Windows Server 2003 domain for Windows Server 2008”section earlier in this chapter. To transfer the schema master role right-click on Active Directory Schema in the console tree, then select Change Active Directory Domain Controller…, select the desired DC and click OK. Right-click on Active Directory Schema in the console tree again, then select Operations Manager, and click Change. Transferring the other FSMO roles requires similar procedures, however they are done using different tools. Use the Active Directory Users and Computers console to transfer the RID master, PDC emulator, and infrastructure master roles. Use the Active Directory Domains and Trusts console to transfer the domain naming master role.
If the current FSMO role owner is unavailable then you cannot perform a normal transfer, instead you must seize the role and assign it to a new DC. Attempt this procedure with caution though, only seize the role master if you are certain that the failed DC cannot be recovered in a timely manner. Seizing must be done at a command prompt using the Ntdsutil tool, to do so perform the following steps:
1. Type ntdsutil at the command prompt and press ENTER.
2. The ntdsutil prompt appears, enter roles.
3. The fsmo maintenance prompt appears, enter connections.
4. The server connections prompt appears, enter connect to server servername, where servername is the name of the target DC.
5. Enter quit.
6. Enter seize role, where role is the role to seize: schema master, naming master, infrastructure master, RID master, or PDC.
7. Accept the warning and the server will first attempt a normal transfer of the FSMO role, if that fails the role will be seized.
8. Enter quit twice to close the utility.
You can perform a normal transfer by replacing the word seize with transfer in step 6. Note that if you seize the schema master, domain naming master, or RID master you should never bring the original role holder online again. If you bring the original PDC emulator or infrastructure master online they will recognize the change and give up their role.
The new version of AD DS includes a very useful tool to ease the burden of disaster recovery, the database mounting tool (dsamain.exe). It allows you to compare offline data in snapshots or backups, you can use this information to determine which set of data you should restore. Previously, when data was lost, administrators had to restart a DC in Directory Services Restore Mode, then restore data from various backups until they found the best one. For example, if someone accidentally deleted or hopelessly misconfigured an organizational unit (OU) the database mounting tool can help you to figure out which backup set has the best copy of the OU to use for restoration. You run this tool from a command prompt, and it has many options which you can examine by entering dsamain /? at a command prompt.
When install the first DC in a new domain it automatically becomes the default time source for all other computers that join domains within the forest. After you configure the data and time on that first DC you may not need to perform any more management tasks relating to that function for a long time. There are two events that may force you to reconfigure the time service: if you change the PDC emulator for a domain or if change the time source for the PDC emulator. Enter the following command on the PDC emulator to change its list of time sources:
Replace the word peers with a space-delimited list of DNS hostnames or IP addresses enclosed in quotes (quotes are not necessary if you specify a single peer). After make changes to the peer list you should stop and restart the Time Service to ensure the changes take effect, either from the Services console or from a command prompt by entering two commands:
If you transfer the PDC emulator role you should configure the original server to use the new one as its time source using the following from a command prompt:
You can configure the PDC emulator to synchronize with its own internal clock rather than another server by entering the following from a command prompt:
If, before joining a domain, a client computer has been configured to synchronize with a manual time source it will not automatically use the PDC emulator. You should reconfigure such clients to use the PDC emulator otherwise Kerberos authentication may fail on that computer. You can do this by entering the following from a command prompt on the client:
You can verify that the time service is working the way you want by entering the following from a command prompt, this command displays a summary of the time service’s activity:
This chapter presented you with information about managing various elements of the AD DS infrastructure. You were shown how to automate the installation of AD DS using answer files and dcpromo from a command prompt, you were also shown how to use adprep to prepare AD domains running Windows 2000 and Windows Server 2003 DCs to add DCs running Windows Server 2008. You learned how to identify the current holder of each FSMO roles, how to transfer the roles to another DC, and how to forcibly seize the role should the DC holding it fail. Other topics covered included raising the forest and domain functional levels, configuring trusts, managing replication, and configuring the Windows Time Service.
This section presents a list of review questions designed to help reinforce the knowledge presented earlier in the chapter. To persuade you to explore the management tools more deeply a few questions may require you to examine those tools further rather than rereading the chapter.
Figure 9: Changing the RID Master.
Figure 10: The Topology Selection Page of the New Replication Group Wizard.
Figure 11: Creating a New Subnet.
Microsoft Windows Server 2008 Active Directory Domain Services page on Microsoft TechNet.
Microsoft Windows Server 2003 Active Directory page on Microsoft TechNet.