Interoperability and Migration Strategies

As mentioned earlier, collapsing a domain structure into a single domain is a desire of many organizations when they are looking to move to Active Directory. Windows NT 4 domains are not the most efficient when it comes to organizing and supporting many users. Novell NetWare, although it is a very efficient directory service, does not have the application support that has been the key to Microsoft s growth over the past few years . Most organizations desire to reduce their TCO has led them to make a decision of which of the directory service infrastructures they want to support.

Those that have made the decision to move to Active Directory are faced with the challenge of deciding the best course of action for migration. Many realize that challenge also entails an interoperability plan. Not everyone has the luxury of performing a single cutover migration; they need to support two directory services as a phased migration occurs. And for those who have applications they need to support that will not function on a Windows Server 2003 system, they may be faced with trying to design a long- term interoperability plan.

The following sections detail the upgrade considerations that you will need to address when you are designing the domain structure. You will need to take into account how the upgrade will be planned plus some of the concerns you will have when upgrading from Windows NT 4 or Windows 2000. Because the forest root is the most important domain within the forest ”it contains the administrative accounts that control the entire forest and by default holds the Active Directory schema ”you will need to make sure you have identified exactly how you want to design this domain. And every domain will need to be named appropriately. Although Windows Server 2003 allows the domain name to be changed at a later time, it is not an option you should take lightly.

Understanding Upgrade Considerations

Upgrading the current domain has some definite benefits. The accounts within the current domains will retain all of their properties when the upgrade is complete. Every account s SID will remain the same, and the group memberships will remain , as will the account properties. If the current domain design meets the requirements of the organization, an upgrade can be a relatively painless process. However, if the domain structure does not meet the design criteria, upgrading the domain may be a futile option. You may be better served to create a new domain and migrate the accounts from the existing domain to the new domain.

Understanding Restructuring Considerations

If the current domain model was put into place due to limitations of the directory service, such as those Windows NT 4 has, or the designer of the current domain structure did not implement an effective design, domain restructuring will allow you to rework the design to meet your current needs. For example, Windows NT 4 has a limit on the number of accounts that could exist within a domain and still function efficiently . Depending on the hardware that was used for the domain controllers within a Windows NT 4 domain, and taking into account replication considerations, the company may only have tens of thousands of accounts in a single domain. Due to these limitations, many administrators designed the NT 4 domain structure so that accounts and resources were divided into their own domains and trust relationships allowed users to access the resources.

Many Windows 2000 Active Directory forests were built before network architects understood many of the directory service features. In doing so, they created infrastructures that cost too much to maintain. Because Active Directory is not very forgiving , redesigning the forest was not usually an option, so the organization lived with the inefficient design. Now that Active Directory has existed for several years, network architects have gained an understanding of how it should be implemented. Creating a new directory services infrastructure and moving the accounts into it may be the best option for some organizations. You could reconfigure the forest to support the organization s needs as you move the infrastructure to Windows Server 2003 s Active Directory.

Migrating the users from their existing domain to the new domain will require the use of programs, such as the Active Directory Migration Tool (ADMT), that will move all of the information correctly and allow the accounts to still have access to the resources for which they have been assigned permissions. One major complication occurs when an account is moved to another domain: when the account is created in the new domain, it is assigned a new SID. Because the resources the user had access to still identify the account s original SID as the security descriptor for permissions, the user will no longer have access to the resources. Unless you want to manually reassign permissions to all of the resources, you must make sure you follow some specific guidelines:

• The new domain must be at least at the Windows 2000 Native Mode functional level.

• The account must be migrated using the ADMT.

• You must use the ADMT that was written for use with Windows Server 2003.

  Note  

  Although Microsoft identifies the ADMT as the migration tool to be used, third-party utilities will provide the same functionality as the ADMT and will provide additional functionality to make the migration easier.

When using the ADMT to migrate the accounts to a Windows 2000 Native Mode functional level domain, the SIDHistory attribute for the new object will be populated with the account s original SID. The account will now have the new SID from the new domain, and the original SID from the previous domain. This allows the account to access all of the resources for which it was originally assigned and have access to new objects.

Migrating from Windows NT 4

Windows NT 4 s directory service was not very efficient. The model used did not scale well for large environments, and as such, multiple domains were usually created to organize resources. Master User Domains (MUDs) were created to host the user accounts for the domain. MUDs were created in a Windows NT 4 environment so that the user accounts for the organization could be organized neatly. Administrators responsible for account control were made administrators of these domains so that they could modify the account requirements. In very large environments with thousands to hundreds of thousands of users, several domains would be created. Resource domains would be created to hold the resources, such as member servers. Collapsing these domains into one Active Directory domain so that the resources are arranged logically within the simplest domain model possible will help reduce the administrative overhead.

The following sections present the options available for migrating the accounts from the MUDs and resource domains into the new design.

Incorporating the Master User Domains

When updating the MUD to Active Directory, you want to retain the account SIDs. Performing an in-place upgrade of the MUDs keeps all of the properties for the accounts intact. In fact, the account is still the exact same account as it had been under Windows NT, but it has been enhanced with additional functionality due to the new features available with Active Directory.

There is a major drawback to the in-place upgrade, however. The domain structure remains the same as the NT 4 domain structure. If you had a single MUD and three resource domains, you will end up with the same domains in Active Directory. Figure 4.10 shows the original NT 4 domain structure and the Active Directory structure after the upgrade.

Figure 4.10: Comparison of the Windows NT 4.0 domains and the upgraded Active Directory structure

Upgrading a Windows NT 4 domain structure that uses multiple MUDs poses another problem. The first domain that you upgrade becomes the forest root. As the remainder of the domains are upgraded, they usually take on the role of child domains in the first tree of the forest. However, in the case of multiple MUDs, the administrators of the MUDs usually have autonomy over the accounts for which they are responsible. If one of the MUDs becomes the forest root, they will have the ability to affect the accounts from the other MUDs. Because this is usually not acceptable when you are trying to retain the same level of control, the best design option is to create an empty forest root and then upgrade the domains to be child domains within the tree.

Figure 4.11 shows an example of a tree with an empty forest root and upgraded MUDs. Because the domains are controlled by different administrative groups that should not be administering objects from the other s domains, the empty forest root was created and the MUDs were upgraded as separate domains beneath the root.

Figure 4.11: Empty forest root and upgraded MUDs

The forest root will contain the service administrator accounts for the forest, but only the forest-owner will have the ability modify the membership of these accounts. The domain owners of the upgraded MUDs will still retain their autonomy over their accounts and will be able to control and maintain those accounts as they were able to under Windows NT 4.

To avoid having the same domain structure, the domains can be consolidated within a single domain structure, or a simpler multiple domain structure if necessary. Tools such as the ADMT exist to make the migration of accounts to Active Directory an easy proposition.

Note  

For more information about these account migration tools, see the MCSE: Windows Server 2003 Active Directory Planning, Implementation, and Maintenance Study Guide by Anil Desai with James Chellis, (Sybex, 2003).

Because many companies were tied to the account restrictions within Windows NT 4, they had created multiple MUDs, but the same administrative staff supported all of them. Collapsing the MUDs into a single domain makes administration far easier than before and reduces administrative overhead. No longer will accounts have to be added to groups in multiple domains so that they will have the proper rights to perform their duties .

The trust relationships that are automatically created within an Active Directory forest are transitive and will allow the accounts to have access to the same resources as they had before. Due to the transitive nature of the trusts, far fewer trust relationships are required, and access to the resources is more efficient. Once the resource domains are upgraded, the users will have the same resource access as before.

Incorporating the Resource Domains

Resource domains under the Windows NT 4 model were created to delegate control to data administrators or they were required due to the account limitations of the Windows NT 4 directory service. Most organizations will want to collapse the domain structure so that the accounts and resources reside within the same domain. Unless the resources must be isolated, the domain consolidation can incorporate them into OUs that will mimic the resource domain structure. If the resources must be isolated, a resource domain can remain, giving the administrators of the resource domain autonomous control over the resource. If true isolation is required, the design requirements may dictate that a resource forest be created. For more information about resource forests, check out the section titled Designing the Forest Structure in Chapter 3.

Upgrading the resource domain retains the domain structure. Performing an upgrade of the domain does not allow you to restructure or collapse the domains into a smaller, more manageable design. This is the easiest of the upgrade methods , but you do not gain any administrative benefits. The domains have to be controlled separately as they were under Windows NT 4.

When looking at this migration approach, review the reasons for maintaining the same design as was previously used. One of the primary reasons for moving to Active Directory is the reduced TCO. Without reducing the administrative overhead associated with multiple domains, you will not achieve the maximum TCO savings. Figure 4.12 shows an example of a Windows NT 4 domain structure upgraded to Windows 2003 Active Directory. Note that all of the existing domains are retained within the new design. The MUD, Corp, has been upgraded to become the forest root. Each of the resource domains are upgraded as child domains so that the current administrative staff can still manage the resources. Also note that the administrative staff from Corp.com will now be able to control the objects within the resource domains.

Figure 4.12: Upgrading Windows NT 4 to Windows 2003 Active Directory

Restructuring the domains allows you to take advantage of the new features of Active Directory. If data administrators decide that they need autonomy over the resources they control, an OU can be identified in which the resources can be migrated. Delegating the appropriate rights to the OU allows the administrators to control their resources without having to worry about other administrators having rights over the resources. This does not include the service administrators, however. Remember, service administrators within the forest or domain can still access resources anywhere in the container where they have service rights. Figure 4.13 shows an example of a Windows NT 4 domain restructure under Windows Server 2003 Active Directory.

Figure 4.13: Windows NT 4.0 restructure

Migrating from Windows 2000

Windows 2000 Server Active Directory migration to Windows Server 2003 Active Directory can be a straightforward process. Because Windows Server 2003 Active Directory is based on the same technology as Windows 2000 Server Active Directory, the upgrade process is very straightforward. Prior to promoting a Windows Server 2003 member server to a domain controller, you need to extend the schema to support the new object classes and attributes. From the command prompt, the utility you need to run is ADPREP /forestprep, followed by ADPREP /domainprep. Once you run these and implement the new attributes and object classes, you can bring Windows Server 2003 domain controllers online and start interoperating with the domain.

Note  

ADPrep is the utility that prepares the forest and all domains within the forest for the first Windows Server 2003 domain controller. If the schema for your organization has been modified, you may need to perform some additional steps. Plus, you will need to verify that the utility functioned as it should have. For more information on the steps required to prepare your domain for Windows Server 2003 Active Directory, see Microsoft Knowledgebase article 325379.

Of course, you do not have to perform an upgrade of the Windows 2000 Active Directory infrastructure. If the current design is no longer efficient enough or the design does not support the organization needs due to reorganizations, acquisitions, or mergers, you can restructure the forest to meet the needs of the organization.

Defining Domain Names

In Chapter 10, Analyzing Name Resolution, we will discuss the name resolution requirements for the Active Directory and network infrastructure design. During this design phase, we need to identify what the domain name will be for each domain in the forest. The Active Directory namespace will follow the DNS namespace. Although Active Directory and the Windows DNS allow for the full Unicode character set, if you require interoperability with other DNS servers, you should make sure you follow the DNS naming standards, which only allow the following characters :

• A “Z

• a “z

• 0 “9

• hyphen (-)

If the name that is going to be used will be used for an Internet presence, the name will have to be registered. Registering the name with a registrar, such as Network Solutions or any other registrar, guarantees that the name is reserved for the organization; no one else can use the name on the Internet. If the name is going to be a local-only name, meaning that it will be used internally within your organization and not on the Internet, then registration is not required.

However, if you think you might eventually need the name for use on the Internet, register it before it is too late.

If you require an Internet presence, you need to choose how you will implement the domain names for internal and external use. Three options exist:

• A domain name that is used for internal and external resources and those resources reside in the same infrastructure

• A domain name that is used for internal resources that is the same as the external resources in different infrastructures

• A domain name that is used for internal resources that is different than the name used for external resources

Of the three, the last option is the easiest to administer. Separating the domain names from the internal and external resources allows you to have internal users accessing resources in both infrastructures without having to perform additional administration. It also allows you to protect internal resources from external users. If the first option is employed, there is a risk that the internal resources could become compromised because they are part of the same domain infrastructure as the external resources. With the second option, additional administrative overhead will occur because the replication of data between the two infrastructures will be necessary for users to access all resources.

The root domain provides the initial Active Directory domain name. This is also the root of the first tree within the forest. Most companies want this tree to define the corporate presence. All of the child domains within this tree off the root share the same namespace as the root domain. With this in mind, you will want to make sure that the name reflects the corporate image. Names should be easy for users to understand and type. Long names are not accepted very easily. Short names are easier to work with and allow you to add additional domains without making an unwieldy namespace.

Identifying the Forest Root Domain

The forest root domain is the most important domain within the Active Directory design. Several critical services exist within the forest root. By default, only two forest-wide single master operations exist in this domain: the Schema Master and the Domain Naming Master. Only two high-level groups reside here as well: Enterprise Admins and Schema Admins. You must carefully plan the membership of the root domain administrative accounts. Any account that becomes a member of the Domain Admins account in the forest root domain can add other accounts into the Enterprise Admins or Schema Admins groups, thereby giving them ultimate control over the forest.

Real World Scenario ”Building the Domain Names

Montgomery Printing had chosen to create the domain structure based on an empty root and separate domains for each of the operations centers. To keep the Active Directory structure secure, they chose to implement a local name that would not be accessible from the Internet. Their Internet presence was registered as montgomeryprinting.com. The internal namespace was chosen to be mp.local to make sure that the domain name would not be too long when additional domains were added to the domain hierarchy. Each of the domains was then based upon the location of the operations center so that the users would have a simple namespace for their domain.

 

If a single domain is used for the design, the domain will be the forest root. All of the resources will be organized within this domain and a single domain name is all that is required. It is still imperative that the name is a meaningful name and that the domain be registered in case an Internet presence may be required using that domain name. Internal namespaces that are not seen on the Internet do not have to be registered, however, so you can create a different internal namespace to increase security. When an organization takes advantage of the single domain forest design, the forest owners are the service administrators. In this situation, monitoring of the administrative groups will be a necessity because any domain administrator can modify the membership of the forest-wide service group, Enterprise Admins.

It is possible to build a forest to allow for isolation or autonomy of services or data between organizations or divisions within an organization within the single forest design. Creating domains for each of the units of the organization allows the administrators from each business unit to control their own resources and access to those resources. The forest still needs to have a forest root, and that root contains the service accounts that have control throughout the forest. The decision then becomes, Who has control over the forest root? Many companies will create a headless forest root, or a dedicated forest root that does not contain any resources or accounts for any of the business units.

This dedicated forest root domain contains only the high-level service accounts and the forest-wide master operations. Using this scenario, the Enterprise Admins and Schema Admins groups will not fall under the control of any organizational domain administrators. Of course, trusted administration staff still need to have access to the forest root, and those administrators have control over the entire forest. Carefully plan who you will allow to have control over the dedicated forest root domain.

Another benefit to this design is that by its nature, the forest will be immune to organizational changes. Acquisitions and mergers will not drastically alter the forest design. New organizational domains can be added to the forest and will not affect the existing domains. Because all of the domains can interoperate , resource access can be allowed to any account within the forest where necessary.