In this Chapter
Even though many organizations can benefit from features present in Windows Server 2003 as member servers in an existing directory structure, the true defining characteristic of a Windows Server 2003 network is Active Directory. Active Directory is Microsoft’s directory service that also provides a platform for the integration of many Microsoft and third-party technologies.
Active Directory is a familiar technology for those administrators who have worked in a Windows 2000 environment. The Windows Server 2003 implementation of Active Directory is an improvement on the Windows 2000 model through added and enhanced features. This chapter focuses on leveraging these enhancements and provides best practices for implementing a Windows Server 2003 Active Directory.
Many of the items discussed in this chapter are new Windows Server 2003 features that are only available when domain controllers are operating in Windows Server 2003 functional modes. In essence, to get some of the new features available to Active Directory, all domain controllers must be running Windows Server 2003.
The functional levels of Windows Server 2003 are similar to the mixed and native modes of Windows 2000 Active Directory. They provide for backward-compatibility to earlier operating systems and a migration path to the newest operating system. This section will explain the various domain and forest functional levels and point out which new features are available at each level.
The Windows 2000 Mixed Domain Functional level provides for backwards-compatibility with a Windows 2000 Active Directory running in Mixed mode. Installed at this level, Windows Server 2003 domain controllers will be able to communicate with both Windows NT 4.0 and Windows 2000 domain controllers throughout the forest. At this level, Windows Server 2003 shares the same limitations present in the Windows 2000 Mixed mode domain.
Windows Server 2003 servers in the Mixed mode domain and forest levels can take advantage of installing Active Directory from Media. This feature will be discussed in the next section.
The Windows 2000 Native Functional Level is the initial operating level of Windows Server 2003 domain controllers installed into a Windows 2000 Native mode domain. At this level there are no NT 4.0 domain controllers. All authentication is performed by Windows 2000 and Windows Server 2003 domain controllers.
At this level, Active Directory can use Universal Groups and Windows Server 2003 domain controllers can cache Universal Groups. These features are discussed in following sections.
The Windows Server 2003 Interim Functional Level is the initial operating level of Windows Server 2003 domain controllers installed into a Windows NT 4.0 domain. This level is provided primarily as a stepping stone during a migration from Windows NT 4.0 to Windows Server 2003. The Interim Functional level comes into play for those companies that have not upgraded to Windows 2000, but instead migrate directly to Windows Server 2003 Active Directory.
To gain the full functionality of a Windows Server 2003 Active Directory, the Windows Server 2003 Functional Level is the final goal for domain and forest functional levels. Functionality at this level enables many of the new features available to Windows Server 2003, such as renaming domains and domain controllers, schema deactivation, and cross-forest trusts. In order for you to promote your Active Directory to the full Windows Server 2003 Functional level, all domain controllers must be upgraded to Windows Server 2003. Individual domains can be promoted to the Windows Server 2003 functional level, but the forest can only be promoted to this functional level after all the domains in the forest are operating at this highest level.
At this level, Active Directory can benefit from all the new Windows Server 2003 features, including domain rename, cross-forest trusts, schema deletes, partial global catalog synchronization, and linked-value replication. All these new Active Directory features are discussed in the following sections.
Those who have installed Active Directory in a Windows 2000 environment realize that the process by which Active Directory is implemented is unique from the installation of the server operating system. A member server becomes a domain controller in an Active Directory domain through the use of the DCPromo utility, or the Active Directory Installation Wizard, after the operating system is installed. A domain controller provides network users and computers with the Active Directory directory service, which stores and replicates directory data and manages user interactions with the domain, including user logon processes, authentication, and directory searches. Every domain must contain at least one domain controller. This section provides information on how to use the DCPromo utility to build Windows Server 2003 domain controllers in new and existing directory service environments.
When executed, the DCPromo utility enables you to promote a Windows Server 2003 member server to a domain controller. It also allows a domain controller to be demoted back to a member server.
The common tasks you can perform in promoting a member server to a domain controller are as follows:
Creating a new forest (also creating a new domain). In this scenario, the server will be the first domain controller created for Active Directory.
Creating a new tree in an existing forest. This scenario comes into play when creating a peer root Active Directory forest.
Creating a child domain. A child domain creates a domain boundary within a forest while maintaining a contiguous namespace.
Creating an additional domain controller in an existing domain. This is a common strategy for fault tolerance and load balancing.
Each of these domain controller roles has unique installation considerations depending on the overall Active Directory design for the organization(s). For design tips, see Chapter 10, “Advanced Active Directory Design.” For any of these installation paths, though, keep the following in mind:
The partition on which the server operating system is installed must be formatted with the NTFS file system.
If DNS is not present or available, DCPromo will prompt the user with the option to have it configured automatically. Verify that DNS is installed and configured correctly before promoting the server.
In any Active Directory installation that involves a domain controller that is not the first domain controller in the forest, there must be some method by which the server being promoted can transfer Active Directory information. In addition to transferring this information over the network, Windows Server 2003 allows Active Directory to be transferred from a backup copied to media. This feature is detailed later in this chapter.
Verify that the installer has the proper level of administrative access to perform the operation. Creating a new domain in a new forest, the administrator need only have the local administrator level permission on the server. To create a new tree in an existing forest, the installer must be a member of the Enterprise Admins group or the Domain Admins group of the root domain. To create a child domain, the installer must be a member of the Enterprise Admins group or the Domain Admins group of the parent domain. To create an additional domain controller in an existing domain, the installer needs to be a member of the Domain Admins group of the existing domain.
The ability to demote a domain controller to a member server was first made available with Windows 2000. This useful feature can still be leveraged in a Windows Server 2003 environment by using the DCPromo utility. Performing a domain controller demotion is a simple task, but it can have some far-reaching consequences if particular considerations are not taken into account.
To demote a domain controller, follow these steps:
Before Performing a Domain Controller Demotion...
Before performing a domain controller demotion, make sure that the server is not the last global catalog server in the domain, and also that it does not contain any operation master roles.
It is important to verify that there will still be a global catalog server available for users before the demotion of a domain controller is completed. If you choose to demote a global catalog server, the DCPromo process will prompt the user with a warning.
FSMO Roles Can be Transferred by Using NTDSUtil.exe
Flexible Single-Master Operations (FSMO) roles can be transferred by using the NTDSUtil.exe command line utility.
Also, if the server to be demoted holds any operation master roles, those roles should be transferred to another domain controller before a demotion takes place.
If the domain controller being demoted is the last domain controller in a domain, that Active Directory domain will be completely removed from the forest. Further, if this is the last domain controller in the forest, the demotion will also delete the forest. To delete a domain or forest using DCPromo, click the check box indicating this is the last domain controller in the domain as shown in Figure 12.1.
Traditionally when a domain controller is added to an existing forest or domain, the Active Directory information that gets installed during the process is transferred over the network from an existing domain controller. This transfer presents a potential bottleneck, especially for building new domain controllers in remote sites connected by a slow WAN connection. One option for avoiding the bottleneck is to build the new domain controller locally, and then ship it to the remote location where only updates will be transferred over the WAN. Windows Server 2003 provides a new method to alleviate the bottleneck by enabling you to install Active Directory (and a global catalog server) from a backup copied to removable media.
Any Encrypted Files in a Domain Should Be Decrypted Before Deleting a Domain
Deleting a domain deletes all user accounts. Computers will no longer be able to log in and access domain resources. Also, any encrypted files in a domain should be decrypted before deleting a domain.
The process of creating a domain controller from backup is fairly simple. By using the NTBackup utility provided with the operating system, a system-state backup can be performed on an existing domain controller. The backup is then copied to removable media such as a CD or tape. The media is then shipped to the remote location where the new domain controller is being built.
On the remote system, you run DCPromo with an /adv switch, which will activate the option to install the Active Directory database from media, as shown in Figure 12.2.
After the DCPromo process completes on the remote system, only incremental changes to the Active Directory database are transferred over the WAN.
A global catalog server is a domain controller that contains a copy of every Active Directory object in a forest. By default, the first domain controller installed in a forest is a global catalog server. The global catalog contains a full copy of every Active Directory object in its host domain, and a partial copy of every object in other domains in the forest. The partial copies include the most commonly queried attributes of objects. The attribute set that global catalogs will store is defined in the Active Directory schema, which can be modified if needed.
The role of the global catalog server is to perform the following primary tasks:
Find objects anywhere in the forest. When users search for people or printers from the Start menu, the queries are sent directly to a global catalog.
Authenticate User Principle Names (UPNs). When an authenticating domain controller does not have information about a user that is logging on with a UPN, (for example, user1@companyabc
.com), it sends a request to a global catalog to complete the logon request.Contain Universal Group membership. Unlike global group memberships, which are stored in each domain, universal group memberships are only stored in global catalogs.
Windows Server 2003 has new features on how global catalog information is stored that will affect decisions on where to place a global catalog server in a distributed organization. The next section provides best practices for group catalog placement and customization based on the new features in Windows Server 2003.
Conceivably, every domain controller can contain a copy of the global catalog. Because global catalog information must be replicated to every global catalog server in the forest, making every domain controller a global catalog server can significantly affect network performance. On the other hand, having too few GCs available to users can affect user logons and access tokens.
Uses More Network Resources
Network traffic related to global catalog queries generally uses more network resources than normal directory replication traffic.
For a single site environment, a single global catalog is sufficient. It is a best practice to have at least a second GC in a single site for fault tolerance.
It is also a best practice to place a GC in a remote site connected by an unreliable or slow connection. In this scenario, fault tolerance for user authentication is achieved at the price of a network performance hit.
If users at the remote site are members of a Windows 2000 native mode domain, they get their universal group membership information from a global catalog server. If the GC is not located in the same site, logon requests will have to be routed over the WAN to find a GC. Windows Server 2003 domain controllers can alleviate this problem with Universal Group Caching.
Due to the network performance issues related to locating GCs at remote sites, Microsoft has added a feature in Windows Server 2003 that enables domain controllers to cache and store Universal Group membership without containing (and replicating) a global catalog.
When enabled, the domain controller will query a global catalog for universal group membership when a user logs on once, and then cache that information indefinitely. The next time that user logs on, the domain controller will refer to its local cache instead of querying the global catalog server. The universal group membership information that is cached is periodically refreshed (by default, every eight hours).
The benefits of universal group caching can be summarized as follows:
Faster logon times. The domain controller can use its cached copy of universal group memberships instead of querying a global catalog server.
Greater bandwidth utilization. Fewer domain controllers will be replicating the entire global catalog of Active Directory objects.
Better hardware utilization. Potentially, fewer servers would be required to support Active Directory. At the very least, existing domain controllers could perform additional roles in the organization if they are not tasked with global catalog storage and replication.
Enabling universal group caching on a domain controller is accomplished by using Active Directory Sites and Services. To enable universal group caching, perform the following steps:
Open Active Directory Sites and Services.
In the console tree, click the site in which you want to enable universal group membership caching.
In the details pane, right-click NTDS Site Settings, and then click Properties.
Select the Enable Universal Group Membership Caching check box, as shown in Figure 12.3.
In Refresh Cache From, click a site from which this site will refresh its cache, or accept <Default> to refresh the cache from the nearest site that has a global catalog.
As was indicated earlier, the global catalog contains only a partial list of attributes about objects not present in the host domain. Although the attributes that are included represent those items queried for most of the time (for example, a user’s first name, last name, and e-mail address), there might be occasions for adding attributes to be replicated and available for users or applications to query against.
Adding attributes to the global catalog can improve query performance. When considering whether to add attributes to the global catalog, keep the following in mind:
Added attributes can affect network bandwidth utilization. The more data there is to replicate, the more bandwidth will be used.
Consider both the size of the attribute and the frequency with which it is updated. A small attribute will not take that much network traffic to replicate, but if it is an attribute that is updated often, it can potentially create more network traffic than a large attribute that rarely changes.
Consider that global catalog information consumes disk space as well as network bandwidth.
When a new attribute is added to the global catalog for Windows 2000 domain controllers, a forestwide synchronization occurs that will replicate the entire global catalog to all DCs. If the GC/DCs are Windows Server 2003 servers, only the added attribute is replicated.
To add attributes to the global catalog, you must use the Active Directory Schema snap-in.
To add an attribute to the global catalog, for example to add the primary mobile phone attribute, perform the following steps:
Open the Active Directory Schema snap-in.
In the console tree, click Attributes.
In the Details pane, scroll down the list and right-click on Mobile, and then click Properties.
Select the Replicate This Attribute to the Global Catalog check box shown in Figure 12.4.
Modifying the Schema Is an Advanced Operation
The Active Directory Schema snap-in must be installed before it can be used. Only members of the Schema Admins group have the capability to modify the schema. Modifying the schema is an advanced operation best performed by experienced programmers and system administrators.
In Windows Server 2003, as with Windows 2000, domain controllers support multimaster replication. In essence, all domain controllers in these environments are peers distributing Active Directory access throughout an organization. This distribution also provides redundancy by eliminating the single point of failure present in the single master domain model of Windows NT.
Although domain controllers distribute most of the functionality available in managing an Active Directory forest, there are five unique functions that require the use of a single server to support because these particular functions are impractical to distribute. For each of these functions, there is only one domain controller that is the operation master.
There are two forestwide Flexible Single Master Operation (FSMO) roles that must appear in any forest. Also, there are three domainwide roles that must appear in any domain. The FSMO roles are outlined as follows:
Schema Master—. The server that contains this forestwide role contains the only writable copy of the schema in the forest.
Domain Naming Master—. This forestwide role is responsible for the addition or removal of domains within the forest.
PDC Emulator—. This domain FSMO role is responsible for authenticating pre-Windows 2000 client computers within the domain. It is also responsible for synchronizing the time on all domain controllers in the domain.
RID Master—. The server supporting this domain wide role allocates sequences of relative IDs (RIDs) to each of the various domain controllers in its domain. Whenever a domain controller creates a user, group, or computer object, it assigns the object a unique security ID (SID). The SID consists of a domain SID, which is the same for all SIDs created in the domain, and a RID, which is unique for each SID created in the domain. The RID Master is also responsible for moving Active Directory objects between domains.
Infrastructure Master—. The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. The infrastructure master compares its data with that of a global catalog. It then requests updates from the global catalog and replicates that information to other domain controllers in its domain.
Because each Operation Master role can only reside on a single domain controller, it is important to understand the ramifications of each role in order to determine its proper placement with a forest or domain. Changes in Windows Server 2003 also affect some placement restrictions present in Windows 2000 forests. This section provides some best practices for FSMO role assignments.
Firstly, the Infrastructure Master role should be assigned to a domain controller that is not a global catalog server. This is true even in single domain models because there is always the possibility that new domains will be added to the forest. In a multidomain model, if the Infrastructure Master has a local copy of the global catalog, it will never find data that is out of date, and therefore never replicate new information about other domains to the other domain controllers in its own domain.
Placement of the PDC Emulator domain controller might affect logon times in some organizations. Even for companies that no longer support pre-Windows 2000 clients on the network, the PDC Emulator gets preferential treatment with regards to password change replication. If a password was recently changed, that change takes time to replicate to every domain controller in the domain. If a logon authentication fails at another domain controller due to a bad password, that domain controller will forward the authentication request to the PDC emulator before rejecting the logon attempt.
Also, the PDC Emulator should get special consideration when setting up time synchronization. This FSMO role is responsible for the synchronization of time for all domain controllers in its domain. The PDC Emulator in the parent domain in a forest should be synchronized with an external time source.
Finally, there is a limitation of Windows 2000 functional level forests that requires the Domain Naming master role resides on a domain controller that is also a global catalog server. In a Windows Server 2003 functional level, this limitation is removed, so this forestwide role can exist on a DC that is not a GC.
There might be occasion to move particular FSMO roles between servers after Active Directory is installed and distributed across several domain controllers. Also, in cases of disaster recovery or demotion of domain controllers serving these roles, it might become necessary to move FSMO roles. This section explains how to transfer the roles.
In cases where the FSMO role merely needs to be transferred between two functioning domain controllers, a GUI interface or the NTDSUtil command-line tool can be used. In disaster recovery situations where the operation master is lost, the FSMO roles must be seized using the NTDSUtil command line tool.
Transfer of the Schema Master role is performed by using the Active Directory Schema snap-in. This snap-in must be installed and executed by a member of the Schema Admins group in the forest. See the section “Using the Active Directory Schema Snap-in” for instructions on how to install the snap-in. To transfer the Schema Master role, perform the following steps:
Open the Active Directory Schema snap-in.
In the console tree, right-click Active Directory Schema and then click Change Domain Controller.
Click Specify Name and type the name of the domain controller that you want to hold the schema master role.
In the console tree, right-click Active Directory Schema, and then click Operations Master.
Click Change.
Transferring the Domain Naming master role is a similar procedure performed using Active Directory Domains and Trusts. Transferring the PDC Emulator, RID Master, or Infrastructure Master roles can all be performed using Active Directory Users and Computers.
Change the Focus of Active Directory Users and Computers
To transfer a role to another domain controller, change the focus of Active Directory Users and Computers to the target domain controller. To do this, right-click Active Directory Users and Computers, click Connect to Domain Controller, and then click the target domain controller.
In cases where the operation master is lost and cannot be recovered, the NTDSUtil command line tool can be used to seize the role from a functioning domain controller.
To seize the RID master role, for example, follow these steps:
Open a command prompt.
Type ntdsutil and press Enter.
At the
ntdsutilcommand prompt, type roles and press Enter.At the fsmo maintenance command prompt, type connections and press Enter.
At the server connections command prompt, type connect to server servername and press Enter.
At the server connections prompt, type quit and press Enter.
At the fsmo maintenance command prompt, type seize RID master, and after seizing the role, type quit (or just q) and press Enter until you’ve exited the ntdsutil tool.
The concept of a domain trust is familiar to system administrators in Windows NT and Windows 2000 environments. Windows Server 2003 introduces the concept of a forest trust. Domain trusts—and now forest-level trusts—provide a useful path through which autonomous organizations can share data and resources. Some scenarios that demonstrate the usefulness of establishing trusts are as follows:
Companies undergoing a merger. When two companies are in the process of a merger, they might require a method by which to share network resources while maintaining their individual administrative models.
Companies with different Active Directory schema requirements. A company could have different forests within their organization linked by a trust yet operate under different schemas and replication topologies.
Isolating a DMZ. For increased security, a DMZ might be placed in a forest independent yet linked to the production forest by a trust relationship.
Separate companies requiring collaboration and sharing of resources. Trust relationship can be set up for links to suppliers, customers, and other partner businesses.
In a Windows 2000 forest, if users in one forest need access to resources in another forest, you can create an external trust relationship between individual domains within each forest. External trusts can be one-way or two-way and are nontransitive, and therefore, limit the ability for trust paths to extend to other domains.
For Windows Server 2003 functional forests, disjoined forests can be joined together to form a one-way or two-way, transitive trust relationship. A two-way forest trust is used to form a transitive trust relationship between every domain in both forests.
Forest trusts benefit a company by reducing the number of external trusts that might be required to share resources cross-forest. They provide the ability to authenticate user principle names (UPNs) cross-forest. And they still enable companies to maintain autonomous administrative models in each forest.
A forest trust can only be created between the forest root domain of one Windows Server 2003 forest and the forest root domain of another Windows Server 2003 forest. Both forests need to be operating in Windows Server 2003 functional level. Creating a forest trust between two Windows Server 2003 forests provides a one-way or two-way transitive trust relationship between every domain residing within each forest.
A one-way forest trust between two forests enables members of the trusted forest to use resources located in the trusting forest. The trust, therefore, only functions in one direction. For example, when a one-way forest trust is created between forest A (the trusted forest) and forest B (the trusting forest), members of forest A can access resources located in forest B, but members of forest B cannot access resources located in forest A using the same trust.
A two-way forest trust, on the other hand, enables members from either forest to use resources located in the other forest. Domains in each respective forest trust domains in the other forest implicitly. For example, when a two-way forest trust is established between forest A and forest B, members of forest A can access resources located in forest B, and members of forest B can access resources in forest A, using the same trust.
When creating a forest trust, be sure that DNS is configured properly. If there is a root DNS server that can be made the root DNS server for both of the forest DNS namespaces, make it the root server by ensuring that the root zone contains delegations for each of the DNS namespaces. Because this will probably not be the case, configure DNS secondary zones in each DNS namespace to route queries for names in the other namespace. Another alternative, if the DNS servers are both Windows Server 2003, is to configure conditional forwarders in each DNS namespace to route queries for names in the other namespace. For more information on Windows Server 2003 DNS, see Chapter 13, “Infrastructure Integration.”
If Forest Trust Is Not an Available Option
If, at this point, forest trust is not an available option, it is likely that the forest functional level has not yet been raised to Windows Server 2003.
To create a two-way forest trust, open Active Directory Domains and Trusts and follow these steps:
In the console tree, right-click the domain node for the forest root domain, and then click Properties.
On the Trust tab, click New Trust, and then click Next.
On the Trust Name page, type the DNS name of another forest, and then click Next.
On the Trust Type page, click Forest Trust, and then click Next.
On the Direction of Trust page, click Two-way as shown in Figure 12.5
On the Sides of Trust page, select This Side Only, and click Next.
On the Outgoing Trust Authentication Level, choose Forest-wide. (Authentication levels will be discussed in the Authentication Firewall section of this chapter).
Provide a password for the Trust, and click Next.
After a forest trust has been established, it is an easy process for you to grant rights and permissions to resources on one side of the trust to users on the other side. The object picker is updated, enabling you to see objects in the root domain of the trusted forest.
You Cannot Browse the Entire Trusted Forest
For security, performance, and privacy reasons, you cannot browse the entire trusted forest. You will need to know the names of the security principles in order to grant rights and permissions.
To assign permissions to a particular folder to the Domain Admins group in a domain in another forest, perform the following steps:
Right-click on the folder, choose Properties, and go to the Security Tab.
Click Add, and then in the Object Picker, click Locations.
Select the forest root domain of the trusted forest.
Type Domain Admins, and click Check Names.
Select the appropriate Domain Admins group and click OK to complete the configuration.
When a forest trust is created, you have the option to allow full authentication between every domain in each of the forests. This might be appropriate if both forests belong to the same company. If the trusting forests belong to two independent companies, it is likely that a selective authentication will be configured for the trust. The concept of selective authentication is also referred to as authentication firewall.
Authentication firewall is automatically set up during trust creation if Selective Authentication is chosen on the Authentication Level page of the wizard. To impose an authentication firewall after a trust is established, simply go the Authentication tab of the Properties sheet of the existing trust, as shown in Figure 12.6.
After Authentication firewall is configured, only users or groups from cross-forest that are assigned the extended right Allow to Authenticate will be able to authenticate.
To specify that only members of the domain admins group from a trusted forest domain can authenticate in a particular domain in the home forest, perform the following steps:
In Active Directory Users and Computers, right-click on the domain controller in the domain that will be the authenticating DC, choose Properties, and go to the Security tab.
Click on the Add button, and then click Location.
Select the trusted forest and click OK.
Type Domain Admins, and click Check Names.
Set permissions and set the Allowed to Authenticate permission; then click OK to complete the configuration.
Another new feature with Windows Server 2003 Active Directory is the ability to rename domains or move domains to different locations within an existing forest. Domain rename supports the ability to change the NetBIOS domain name, or the Active Directory namespace (companyabc.com for example).
The procedure to rename a domain is not a simple switch, and depending on the size of the organization, can require considerable downtime to complete. For these reasons, renaming domains should be planned out accordingly.
The best practices surrounding domain renames really boils down to understanding the limitations, meeting a list of prerequisites, following a six-step process, and providing the downtime necessary to complete the procedure. This section will help you to plan and navigate this process.
The domain rename process will not work in every scenario. It is important to know what cannot be done before planning a big rename weekend. The following is a list of restrictions for domain rename:
Identity of the forest root domain cannot be changed. Although the forest root domain can be renamed, it cannot be moved to another location in the forest as other domains can. The forest root remains the forest root.
Domains cannot be dropped or added during the process. There are other methods to accomplish this task, so this is not a big limitation. The key point here is that after the domain rename process is completed there should be the same number of domains in the forest as there were at the outset.
Two domains in the forest cannot swap names in a single process. Essentially, one domain cannot give up its name to another production domain in the forest in a single restructuring process.
A forest-prepped domain cannot be renamed. If the schema has been updated with an Exchange 2000 installation, it cannot be modified by the domain rename process.
After the constraints of the domain rename process are understood, you can begin to establish these prerequisites for carrying out the procedure:
The forest must be in Windows Server 2003 functional mode. The process does not work with Windows 2000 domain controllers. All DCs in the forest must be running Windows Server 2003, and the forest must be elevated to Windows Server 2003 functional mode.
DNS must be prepared. If the domain rename process involves renaming the DNS namespace, a DNS zone must be created to include the new namespace. This is not necessary for renaming the NETBIOS domain.
The process cannot run on a DC. A member Windows Server 2003 server must be used as the “console” for the operation. Because domain controllers will be reconfigured and rebooted during the process, a DC cannot perform the actual operation.
Temporary trusts might need to be created. If domain rename is being used as a reorganization tool with which domains will be moved around within the forest, temporary trusts must be created for any domain and its future parent domain.
After the limitations are understood and the prerequisites have been met, the actual domain rename process is fairly simple. It is important to keep in mind, though, that depending on the size of the organization this process might require a great deal of network downtime.
Steps for the Domain Rename Process
Remember that all steps for the Domain Rename process must be performed from a single member Windows Server 2003 server.
The tool used to perform the domain rename process is rendom.exe, which can be found in the ValueaddMsftMgmtDomren folder of the installation CD. The first step is to run rendom with the /list switch, which generates an XML file that lists the domain-naming information for a domain. A sample domainlist.xml file is shown in Figure 12.7.
In this step, open the XML file generated from step 1 in a text editor, and modify domain-naming information. For example if companyabc.com is being changed to organizationA.org, a simple find and replace operation can be used to change all references from one domain name to the other. Further, any changes to DNS and NetBIOS names should be changed as well.
After the XML file is updated, run the rendom command with the /upload switch. This uploads the new information to every domain controller in the forest.
Because every domain controller must participate in the update process, it is important to verify that each DC has received the update file and is ready for the migration. Run the rendom command with the /prepare switch. The prepare function will fail if it cannot contact every DC in the forest, in which case this process must be restarted. This step will ensure a successful migration to the new structure.
After step 4 completes successfully, run rendom with the /execute switch. No changes to the production environment take place until this command is run. When executed, all domain controllers execute the change and automatically reboot. After the DCs reboot, every workstation and member server in the forest must also be rebooted to get the change. It might be necessary to reboot workstations and member servers twice to ensure all services receive the domain name changes.
The final step in the domain rename process is to run rendom with the /clean switch which removes temporary files from the domain controllers and returns the domain to a normal operating state.
Also, each domain controller will need to have its primary DNS suffix changed via the netdom command-line utility. To perform this procedure, execute the following commands on each domain controller:
Open a command prompt window.
Type netdom computername oldservername /add:Newservername.
Type netdom computername oldservername /makeprimary:Newservername.
Restart the server.
Type netdom computername Newsservername /remove:oldservername.
Replace oldservername and newservername with the full DNS name of the old and new server, for example srv1.companyabc and srv1.organizationA.com.
The schema is to the Active Directory what the Registry is to the Windows operating system. The schema is a database of definitions for all object types within the directory structure, which determines how all Active Directory objects can and are configured. Just as care is extended to managing and modifying the Windows Registry, extreme care should be extended to the administration of the schema. Changes to the schema affect the entire Active Directory environment. As such, the schema is not a database that should be modified casually. If modifications will be made, either for troubleshooting or development purposes, it is important to test these modifications in a test lab environment before implementing them in production.
The next section discusses the tools used to manage the schema and a new feature in Windows Server 2003 that allows for schema attribute deletes.
One method for viewing and modifying the Active Directory schema is by using the Active Directory Service Interfaces (ADSI) Edit utility. The ADSIEdit utility provides a GUI interface similar to Active Directory Users and Computers, but with a much lower level view of Active Directory objects.
ADSI Edit is installed with the Support Tools available on the installation media in the Tools/Support folder. Once installed, ADSI Edit can be accessed through the MMC snap-in, or by executing adsiedit.msc from the run line.
Although ADSI Edit provides a method for modifying Active Directory objects, the tool is best used as a method for troubleshooting or gaining detailed configuration information about a particular Active Directory implementation. When changes to Active Directory fail to work through the normal administration tools, such as Active Directory Users and Computers and Active Directory Sites and Services, ADSI Edit can be used as a last resort to repair the AD database.
For example, as was discussed in an earlier section of this chapter, DCPromo can be used to promote a member server to a domain controller and demote a domain controller to a member server. If a DCPromo demotion process fails, it might become necessary to delete the specific domain controller object from Active Directory by using the ADSI Edit utility.
The easiest way to view and modify the Active Directory schema is by using the Active Directory schema snap-in. Unlike other Active Directory snap-ins that are installed by default with the Windows Server 2003 Administration Tools, the Schema snap-in must be activated by running the following command at a command prompt: regsvr32 schmmgmt.dll. After the program is registered on the computer, the snap-in can be access by adding it to an MMC session.
When executed, the Schema snap-in provides a GUI interface that lists both Active Directory classes and attributes, as shown in Figure 12.8
In the schema, an object class represents a category of directory objects, such as users, printers, or application programs, that share a set of common characteristics. The definition for each object class contains a list of the schema attributes that can be used to describe instances of the class. For example, the Computer class has attributes such as Network Address, Operating System, and Machine Role.
The Schema snap-in provides a low-level view of the classes and associated attributes in Active Directory providing schema administrators to view and modify individual characteristics of Active Directory objects.
In Windows 2000, as with Windows Server 2003, it is possible to extend the schema with new classes and attributes. Installing Exchange 2000, for example, extends to the schema to almost double its original size. But after classes and attributes were added to the schema, it was not possible to remove them. Although it is still the case that added classes and attributes cannot be deleted, with Windows Server 2003, schema administrators now have the capability to deactivate and redefine classes and attributes.
Classes, Attributes, and the Forest Functional Level
Classes and attributes added to the base schema can be deactivated without raising the forest functional level. However, they can be redefined only in forests with the forest functional level set to Windows Server 2003.
To deactivate an attribute, for example to deactivate an attribute called BuildingName, perform the following steps:
Open the Active Directory Schema snap-in.
In the console tree, click Active Directory Schema.
In the console tree, double-click Attributes.
In the Details pane, right-click the BuildingName attribute, and then click Properties.
On the General tab, clear the Attribute Is Active check box, as shown in Figure 12.9.
Click Yes at the warning dialog.
Another new feature available in Windows Server 2003 is the concept of Application Partitions. This feature provides the ability to store data in Active Directory, taking advantage of Active Directory replication, without replicating that data to every domain controller in the forest.
Active Directory allows the creation of a new type of naming context (NC), or partition, called application partitions. This NC can contain a hierarchy of any type of objects except security principals (users, groups, and computers), and can be configured to replicate to any set of domain controllers in the forest, not necessarily all in the same domain.
This means that dynamic data from network services such as Remote Access Service (RAS), RADIUS, and Dynamic Host Configuration Protocol (DHCP) can reside in a directory so that applications can access them uniformly with one access methodology. Developers will be able to use this feature to write application data to dedicated application directory partitions rather than to a domain partition.
Most importantly, Windows Server 2003 uses application partitions to hold Active Directory Integrated DNS zones. For every domain in a forest, a separate application partition is created and is used to store all records that exist in each AD-integrated zone. Because the application partition is not included as part of the global catalog, DNS entries are no longer included as part of global catalog replication.
Application partitions can be created using either the ADSIedit GUI interface, or by using the NTDSUtil command-line interface.
To create an application directory partition named “test” on a domain controller named DC1 in the companyabc.com domain, perform the following steps:
Open a command prompt.
Type ntdsutil, and press Enter.
At the ntdsutil command prompt, type domain management, and press Enter.
At the domain management command prompt, type connection, and press Enter.
At the connection command prompt, type connect to server DC1, and press Enter.
At the connection command prompt, type quit, and press Enter.
At the domain management command prompt, type create nc dc=test,dc=companyabc,dc=com DC1, and press Enter.
After an application partition has been established, it is possible to add replicas of that partition to other domain controllers. Adding a replica initiates the replication process so that the application partition is available, for redundancy or data access, on any domain controller that is configured with a replica.
To add a replica, use the same NTDSUtil procedure used to create the application partition in the previous example. This time, add the replica to a domain controller named DC2 with the following command:
add nc replica dc=test,dc=companyabc,dc=com DC2
When changes are made in a particular application partition on a particular domain controller, those changes are replicated to other domain controllers containing a replica of that partition. The domain controller on which the change is made notifies its replication partners, and the replication is initiated. Windows Server 2003 enables you to control this replication process by setting the amount of time a domain controller will wait to send out the change notification to its first and subsequent replication partners.
Continuing with the previous examples, to configure DC1 to wait 10 minutes before notifying DC2 of a change to the test application partition, use the NTDSUtil command line interface, and type the following command at the domain management prompt:
set nc replicate notification delay dc=test,dc=companyabc,dc=com 600.
As this chapter illustrates, there are several new features available to Active Directory with Windows Server 2003. Although many of the new features rely on a certain functional level of the Windows Server 2003 network, some features can be realized with only a single Windows Server 2003 domain controller running in a Windows 2000 functional mode (for example universal group caching). After the functional level of the forest is elevated to Windows Server 2003 mode, many of the barriers that once existed in Windows 2000 networks are broken, allowing administrators greater management and design flexibility than was ever possible before.