Active Directory was introduced in Windows 2000, and for its second major implementation, it is a pretty decent directory service. In Windows Server 2003, you will find a number of welcome improvements. Before discussing them, however, I should mention that Active Directory is improved but not perfected. It still has its quirks and shortcomings, and it is still fairly inflexible, which will frustrate some users, to be certain. For example, there is no easy way to rearrange the structure of existing forests, merge one forest with another to form a single forest, or split domains off a forest to form a new forest. These are all tasks that most large enterprises—probably even your organization, regardless of its size—will want to perform at some point in time. So, what's changed in Active Directory? Well, a lot actually, as you'll see in the sections that follow.
Note
If you are new to Active Directory and Windows Server 2003, it's okay if you are not familiar with all the terms and technologies discussed in the following introductory sections. Detailed discussions of these terms and technologies are discussed in Part 7.
You can now rename domains, which wasn't possible in Windows 2000. For example, if your company name changes from Adventure Works to Wide World Importers, you could change your domain name from adventure-works.com to wideworldimporters.com, and the domain-renaming process changes the organization's NetBIOS name as well.
As you might imagine, changing an organization's domain name has far-reaching consequences. It affects not only DNS and Active Directory, but all other network services, as well as domain trusts. It also affects every domain controller, server, and member computer in the domain. For these reasons, many prerequisites exist, as follows:
All the domain controllers in the forest must be running Windows Server 2003.
The forest must be operating in Windows Server 2003 functional mode.
You must complete fairly extensive research and implementation readiness plans prior to changing the domain name.
When you are ready to continue, you use the Microsoft-provided tool, Rendom, to change the domain name. The tool automates the change process in DNS and Active Directory. When it is finished, you must use another tool, Netdom, to rename domain controllers, and finally, you must fix the GPOs using Gpfixup. One or more reboots of domain controllers and member computers are required to complete the renaming process.
Note
For more information about renaming domains, see the section entitled "Changing Domain Design".
In Windows 2000, administrators can create primary DNS zones that are integrated with Active Directory (not surprisingly, these are called Active Directory–integrated primary zones). The major benefits of integrated zones are that all DNS information is stored in Active Directory and DNS information is automatically replicated with other Active Directory information to domain controllers throughout the domain. These benefits can also be detriments, however, in cases involving large numbers of domain controllers in which only a few of them are DNS servers. DNS information is replicated to each and every domain controller (as part of normal Active Directory replication), yet only a few of the domain controllers require the information. This causes a waste of network bandwidth and system resources.
Fortunately, the Active Directory implementation in Windows Server 2003 incorporates a real solution to this problem—a solution that can be applied to other types of data that you want to store in Active Directory as well—called an application partition. Essentially, an application partition allows you to create subsets of Active Directory data that can be replicated selectively throughout the domain. With Active Directory–integrated zones, application partitions are used to ensure that DNS information is replicated only to domain controllers that are also configured as DNS servers.
The really good news is that this feature doesn't require any preparation. Any domain controller running Windows Server 2003 uses this feature automatically. For other types of data that you want to store in Active Directory, you create the application partition and specify the domain controllers to which the data should be replicated.
Now you might be wondering how to fix the "split-brain" syndrome that can occur when you have multiple internal domains integrated with DNS. Am I correct? If I'm not, you probably haven't encountered this problem yet, but you might in the future.
Split-brain syndrome occurs when you have separate DNS servers set up to handle inside and outside domain name addressing. The DNS server that users inside your network see handles your internal networking needs. The DNS server that users outside your network see handles address information for the company's external Web or FTP sites and mail. This configuration works fine unless you have multiple internal domains. Because each Active Directory installation requires DNS, and if you integrate DNS zones with Active Directory, you must separate DNS servers for each domain, which causes problems.
In a normal DNS configuration, when your DNS server can't resolve a request, such as when you are trying to access a Web site on the public Internet, it simply forwards the request to your company's public DNS servers for resolution. This allows domain A to obtain internal DNS information and public DNS information. It doesn't, however, allow domain A to obtain internal DNS information on domain B, which is also part of your organization. Because of this, a request sent through the DNS server for domain A about domain B is forwarded to the public DNS server for resolution, and this public DNS server has no way to resolve the request. As far as the public DNS server is concerned, the private domain doesn't exist. See what I mean about split-brain syndrome?
By using conditional forwarding, you can tell your DNS servers that when they receive a request for such and such domain, they should not forward it to the public DNS servers for resolution. Instead, they should forward the request directly to X server—where X is the DNS server for the domain being looked up. This DNS server will then be able to answer the request, and the DNS lookup will be resolved.
In Windows 2000 Active Directory, you could extend the schema and make changes to the directory. However, as ironic as it sounds, you could not delete objects you created in the schema. In Windows Server 2003, however, now you can deactivate schema objects in Active Directory. Because deactivated objects are considered defunct and are unavailable, this allows you to correct any changes that shouldn't have been made and make new changes without fear of being able to undo them.
For many organizations, the issue of whether to install domain controllers at remote branch offices often arises. Should you install a domain controller at each site? Should you then also install the essential services the branch office requires, such as DNS, DHCP, and WINS? These are not easy decisions to make.
One of the key factors you always must consider is the type of connection between a branch office and the central office. Although some offices have persistent T1, digital subscriber line (DSL), or cable modem connections between them, others have only Integrated Services Digital Network (ISDN) or dial-up connections. Either way, usually only one connection between sites exists, and that connection can sometimes be iffy. For example, one branch site I encountered had a DSL connection that went from good to bad to worse, depending on the day (and sometimes on the time of day). Another site had a misconfigured T1 that was even worse—if you can imagine that.
With unreliable connections, organizations might be tempted to load up the branch office with everything it is going to need. You know, give it a domain controller, and install the works—DNS, DHCP, WINS, and so forth—to ensure users in the branch office can log on and remain productive if the link goes down. But even with reliable links, putting a domain controller and all those services at the branch office location could saturate the network so that there is little network bandwidth for anything else. And imagine what would happen with a poor connection.
When you decide to install a domain controller at a branch location, you might be in for some surprises before you even complete the installation. When you install a domain controller in Windows 2000, you use a tool called Dcpromo to promote an existing member server of the domain to the role of domain controller. To complete the promotion process, Dcpromo must obtain a full copy of Active Directory, which must be transferred over the network connection. When that completes, Active Directory and the configured services at the branch office must communicate and synchronize with Active Directory and the services at the main office.
With Active Directory running in Windows 2000, typically you also must install a global catalog on the domain controller to ensure users can access the global catalog during logon (which is mandatory) and can view global Active Directory data, such as distribution lists and their membership. However, if you did that, any changes you made to Active Directory could trigger a full synchronization of the global catalog (which happens any time you add attributes to a partial attribute set, such as when you add a user to a distribution list). Just imagine how that would work over an unreliable connection—or maybe you don't need to imagine it because you've already experienced it?
In Windows Server 2003, many of the issues branch offices face go away because of improvements in Active Directory and global catalog optimization. This means Windows Server 2003 really can come to the rescue.
By using Windows Server 2003, you can back up Active Directory to a file that can be burned to a CD-ROM. You can then mail copies of the CD-ROM to branch offices, and they can start the upgrade of a member server to a domain controller by installing from media using the backup, rather than forcing a complete initial replication over the interoffice link. Afterward, all the domain controller must do is synchronize with the changes that were made since the backup occurred, which usually aren't many; hence, very little replication should occur.
Windows Server 2003 also takes care of many issues related to the global catalog. First, you might not even need to use a global catalog at a branch office because Windows Server 2003 introduces universal group membership caching, which allows the branch office domain controller to cache the universal group membership information so that it is available to users. This feature effectively solves the problem of users not being able to log on when the interoffice link is down because no local global catalog exists (otherwise, access to the global catalog is required for logon).
By using caching, the information is replicated only when it is initially requested and not each time a change is made to the directory. This means less replication traffic is transmitted over the network. In addition, Active Directory has been optimized so that when you add attributes to a partial attribute set, only the changes are replicated. This means that instead of requiring a full synchronization after a change is made, Active Directory can now replicate only the change. Active Directory in Windows Server 2003 has also been optimized to enhance the ways in which transmission of replicated data occurs.
Note
Good news! These features do not require you to upgrade every domain controller in all the domains of your forest. You can, in fact, take advantage of these features at a branch office simply by installing a domain controller that runs Windows Server 2003 at the branch office. However, to take advantage of other features of Active Directory, as discussed previously, you are better off upgrading all domain controllers in your forest.
In Windows 2000, Microsoft attempted to decrease the impact of data replication on the network by compressing data so that it uses less bandwidth for transmission and using a leastcost method of routing data from a domain controller in one office to a domain controller in another office. Unfortunately, both implementations had unintended side effects. The processes of compressing and uncompressing data require processing time and resources. The routing algorithm chosen wasn't necessarily the best one, and as a result Active Directory bogged down when replicating data to more than a few hundred sites.
The fixes in Windows Server 2003 are relatively straightforward. You can now specify whether Active Directory should use compression. You do this by disabling compression and allowing Active Directory to replicate data natively. Although this means data is raw and uncompressed and will use additional network bandwidth, it also means the domain controllers won't waste processing power compressing and uncompressing Active Directory data. If you have plenty of bandwidth but CPU power is at a premium, you might consider this option.
To resolve the routing algorithm issue, Microsoft started using industry-standard algorithms that were highly optimized rather than the routing algorithms developed in-house. The result is that Active Directory can now handle replication to thousands of sites rather than hundreds.
I've already mentioned Active Directory forests, and I've also mentioned that in Windows 2000 forests were fairly inflexible. This might have got you wondering whether Windows Server 2003 improves the way forests work at all. The good news is that it does. You might also have wondered what the point of a forest is. In brief, you combine Active Directory domains into a forest to gain the advantages of transitive trusts and universal group caching. For automatic transitive trusts in Active Directory, all the domains in a forest automatically trust each other. For universal group caching, the designated global catalog servers in each domain cache directory data not just about that domain but about all domains in the forest. This makes it easier for users to access resources throughout the forest and to manage permissions on an enterprise-wide basis.
A problem enters the picture, however, when you want to share resources between forests. In Windows 2000, no easy way to share resource between forests exists. Sure, if the organization acquires several forests after a merger or similar consolidation, you could migrate all the accounts for users, groups, computers, and other objects from all forests to one forest, and then you'd have only one forest. But migration is a lot of work and it might not accomplish everything you hope it would.
Fortunately, Windows Server 2003 extends the concept of trusts to the forest level. In Windows Server 2003–based forests, you can use a cross-forest trust to establish a trust relationship between forests. Once you do this, all the domains in the first forest trust all the domains in the second forest, and vice versa. Problem solved, right? Well, mostly, because the forests still separate the global catalog servers, so that the first forest has a separate global catalog from the second forest and applications that are dependent on the global catalog, such as Microsoft Exchange Server 2003, won't recognize your organization as a single forest with one directory but as two separate forests with two directories.
Windows 2000 shipped with version 1 of the Active Directory Migration Tool (ADMT). The tool has since been revised and enhanced, and now version 2 is available as a download for Windows Server 2003 (http://www.microsoft.com/windowsserver2003/downloads/tools/). This latest version of the migration tool allows you to migrate user accounts, computer accounts, access control lists, and trusts from Windows NT 4 or Windows 2000 domains to Windows Server 2003 domains. Unlike previous versions of the tool, which migrated user accounts but not passwords, the new version migrates passwords as well.
You can also migrate objects between Active Directory forests. This allows you to set up an entirely new forest and migrate objects to the new forest. For example, if your company merges with another company or the company name changes, you could create a new forest to accommodate the changes. Or, if a branch office sets up its network in a separate forest, you could migrate it to the main forest of your organization. In the case of a merger, you could migrate the objects in company A's forest to company B's forest.