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.
Active Directory and Global Catalog Are Optimized
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 Ser- vices Digital Network (ISDN) or dial-up connections. Either way, usually only one connec- tion 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 misconfig- ured 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 con- troller 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 cat- alog 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
Chapter 1
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 improve- ments 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 dis- cussed previously, you are better off upgrading all domain controllers in your forest.
Active Directory Can Compress and Route Selectively
In Windows 2000, Microsoft attempted to decrease the impact of data replication on the net- work by compressing data so that it uses less bandwidth for transmission and using a least- cost 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 pro- cesses 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
Chapter 1
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.
Note To get these benefits, however, you must upgrade all the domain controllers in all the domains of your forest to Windows Server 2003.
Forest-to-Forest Trusts
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 per- missions 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.
Chapter 1
Note To use forest trusts, you must upgrade all the domain controllers in all the domains of both forests to Windows Server 2003.
Active Directory Migration Made Easier
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.
Group Policy Improvements
Some of the changes that have occurred in Group Policy include the new Group Policy Man- agement Console, the new Software Restriction Policies feature in Group Policies, and new policies for user profiles.
Group Policy Management Console
Navigating Group Policy can be a nightmare. Heck, just trying to figure out where things are can be a challenge, not to mention trying to figure out why so and so’s computer doesn’t have a policy applied when everyone else’s does. Often you have to work with several different tools to try to figure things out. All in all, it can be a very frustrating experience.
Enter Group Policy Management Console (GPMC), Microsoft’s solution for making Group Policy management easier. GPMC does for Group Policy what the Computer Man- agement console did for system, storage, and service management; namely, it gives you a central interface for working with Group Policy. The really good news is that GPMC can be used to manage Windows Server 2003–based as well as Windows 2000–based Group Policy implementations. This means you can use it even if you haven’t fully upgraded to Windows Server 2003.
For more information about Group Policy management and the GPMC, see Chapter 38, “Managing Group Policy.” You can download GPMC from the Windows Server 2003 Feature Packs page on the Microsoft Web site (http://www.microsoft.com/windowsserver2003/downloads/featurepacks/). GPMC