• Sidebar: Active Directory Primer
• Illustration: Active Directory Cross-Forest Trust
• Illustration: Universal Group Caching

Windows .NET Server will contain many features aimed at making the design, configuration, and maintenance of Active Directory (AD) easier, and these improvements will especially benefit large, geographically dispersed organizations and those that have been reluctant to upgrade to AD because they fear irreversible design mistakes. AD, introduced in Windows 2000, is a distributed database of objects, such as users, groups, computers, and policies, used primarily to control security (authentication and access to resources) and centralize administration of computer settings. Although the enhancements in Windows .NET Server will make AD more flexible, more efficient, and easier to manage, migrate, and deploy, some come at the cost of increased complexity and require substantial administrator effort and expertise.

What’s Slowing Conversion to AD?

Even though Windows 2000 has been shipping for over two years, organizations have been slow to adopt AD. Estimates vary, but still only about half of the organizations using Windows NT 4.0 have migrated completely to Windows 2000 and AD. For example, a recent TechTarget survey of 950 Windows IT professionals indicated that only 40% of respondents said they have installed AD, and another 13% plan to do so within six months.

A substantial improvement over the NT 4.0 directory, the Windows 2000 AD provides many new benefits, such as the following:

• The ability for "directory enabled" applications, in particular Exchange 2000, to use AD as a shared centralized directory, rather than forcing each application to maintain its own entries, such as users and groups, in separate databases that must be kept synchronized with a master list
• The ability to tailor AD to nearly all organizational sizes, structures, and network topologies, without being encumbered by NT 4.0’s directory size limitations and inability to support more than a two-tier directory structure
• Group Policy, a new feature that enables centralized control and maintenance of computer and user settings and software deployment.

Despite these advantages, adoption remains slow for several reasons. Migration requires companywide agreement on difficult political issues, such as who controls security for whom, how desktops will be controlled, and naming conventions. (For background, see "Domains in Windows NT 4.0 and Windows 2000" on page 6 of the Feb. 2000 Update.) Moreover, Windows 2000 AD designs are difficult to modify (e.g., to correct mistakes or accommodate mergers or acquisitions) once critical choices are made, and poor AD designs can slow response times or generate unsupportable network traffic volumes.

Except for small or medium-size organizations that used a single NT 4.0 domain, migration to AD is also tricky. Instead of performing in-place upgrades, organizations must usually build a new domain structure and then migrate users and computers into the new directory. This process is complex, disruptive to user productivity, and can open temporary security holes.

Given these obstacles, many NT 4.0-based organizations are either waiting on the sidelines or have taken a slow, deliberative approach to migration. AD improvements in Windows .NET Server may give those who have held off a reason to take another look.

What’s New in Windows .NET Server’s AD?

Many of the new AD features can be lumped into three categories based on the benefits they're designed to convey: greater flexibility, better network utilization, and easier migration and deployment. The new AD also contains improvements targeted at developers and at organizations that want to use AD as an Internet-facing directory, but these features are not covered in this article—see the "Resources" section for links to sources with more information on these features.

(Readers unfamiliar with AD terms and concepts should see the sidebar "Active Directory Primer".)

Flexibility Enhancements

The new AD makes it easier for organizations to accommodate changing business needs. Outlined below are the four most important changes that make AD more flexible.

Domain renaming and restructuring. Windows .NET Server supports renaming domains and restructuring the links between domains.

Under Windows 2000, it was difficult to make name changes, recover from design mistakes, or to make structural changes later in response to new business conditions such as the completion of a merger. Sometimes making such changes required starting over from scratch.

With the new AD, organizations can change their naming schemes or forest structures to match changes in organizational structure. For example, when a company changes its name, it can change the AD namespace to reflect the new name. It can also move any domain (except the root domain) around in the forest—for example, following a reorganization an organization may want to change its AD domain structure to map to the changes so that system administrators for each unit control only those resources owned by it. However, organizations cannot move domains from one forest to another—in that case they must use the included migration tool (discussed later).

Schema deactivation. The new AD allows organizations to deactivate or redefine modifications to the default AD schema.

The AD schema has always been extensible to support the needs of new directory-enabled applications. For example, Exchange 2000 extends the user class in AD with new attributes that store information such as users’ e-mail addresses and mailbox servers. This extensibility was one of the qualities that made AD more attractive than NT 4.0's directory.

However, in Windows 2000, schema changes were one-way and permanent for the entire forest, which could create problems if mistakes were made or if needs changed. A custom schema extension could also conflict with a newer version of AD, preventing AD from being upgraded.

Windows .NET Server offers the ability to back out of schema changes, thereby allowing organizations to more confidently exploit AD's extensibility features.

Cross-forest trusts. Windows .NET Server’s AD supports one- and two-way "transitive" trusts between entire AD forests.

Although Windows 2000 AD supported external trusts between individual domains in one forest with individual domains in the other, the trust was not "transitive" and it only supported NTLM authentication, not Kerberos. This made it difficult to configure multidomain forests so that all accounts in the domains of one forest could access any resource in any domain of the other.

The new cross-forest trusts provide a way to quickly link acquired or merged organizations that already have one or more Windows .NET Server AD forests. A two-way trust between the roots of two forests can provide Kerberos-based single sign-on access to resources on any domain in either forest. Cross-forest trusts are also useful to organizations that have completely independent divisions or subsidiaries with autonomous IT groups, and do not want any administrators in one forest to have authority in other forests. (For more details on cross-forest trusts, see the illustration "Active Directory Cross-Forest Trust".)

Console enhancements. The new AD contains management interface improvements, such as multi-item editing, drag-and-drop, and saved queries.

With Windows 2000, making widespread changes to AD objects usually required scripting, which was difficult for most administrators and took excessively long when the changes were ad-hoc or one-time. For instance, simultaneously changing an attribute, such as the department name, for a group of users could not be done through the administrative interface. Hand-editing multiple objects one-at-a-time was impractical and prone to error.

With the new AD administration interfaces, administrators can perform routine tasks more quickly and easily. In particular, the new AD restores multi-item editing, a feature that was available in NT 4.0. This means that administrators can once again select multiple objects from a class (such as multiple users), open up a single property page, and simultaneously change one or more attributes on all selected objects. In addition, administrators can drag-and-drop objects from one container to another and can save object queries so that performing repeat operations on those same objects is faster.

Better Network Utilization

The new AD includes changes that allow organizations to unburden their WAN links. Outlined below are the two most important changes that improve network utilization.

Universal group caching. Windows .NET Server domain controllers (DCs) not configured as Global Catalog (GC) servers can now cache universal groups and service log-on requests for repeat users.

In Windows 2000, DCs had to contact GC servers to expand users’ universal group memberships when processing log-ons. This requirement compelled some organizations to deploy GC servers in remote offices to avoid log-on failures if the network link connecting the remote site to the rest of the organization failed. However, GC servers need to perform substantial replication in large environments, which burdens the WAN links servicing the remote site.

The new universal group caching feature allows organizations to avoid the replication overhead of placing GC servers in remote offices, yet lets them retain the ability for repeat users to log on if the WAN link goes down between them and the nearest GC server. Log-on response times are also better when local DCs can resolve universal group memberships.

(For a graphical overview of this feature, see "Universal Group Caching".)

Group replication improvements. Windows .NET Server’s AD allows group membership changes to use delta replication (i.e., replicating changes only, not the whole group membership) to mirror the changes to other DCs.

In Windows 2000, any change to the membership of a group required the entire group object to be replicated to the other DCs in its domain and to GC servers, which took longer than necessary and added to network traffic. The time lag could create additional problems—if the membership of a group was updated simultaneously on two or more DCs, then some of the membership updates could potentially be lost during replication. Microsoft recommended allowing no more than 5,000 members in a group for this reason.

The Windows .NET Server AD group replication enhancement removes the membership limit, lowers network bandwidth consumption, and greatly speeds up replication so that collisions from simultaneous group changes become much less likely.

Migration and Deployment Enhancements

The new AD expedites deployment and migration from the NT 4.0 directory. Outlined below are the two most important enhancements to migration and deployment.

Improved object migration tool. Windows .NET Server includes an enhanced Active Directory Migration Tool (ADMT) that now preserves account passwords and is scriptable.

The Windows 2000 ADMT was a graphical tool that let administrators move users from one domain to another, but it lost the passwords in the process, leaving behind a security vulnerability or support headache until new passwords were issued or created. It was also not scriptable, preventing organizations from using scripts to perform repetitive migration operations.

The new ADMT tool makes migrating users during forest or domain consolidation operations less disruptive and allows organizations to build scripts to automate the process. ADMT in Windows .NET Server can be driven from any language that supports COM interfaces, such as Visual Basic Script, Visual Basic, and Visual C++. Also, all scriptable tasks can be executed from a command line or batch files.

Install replica from media. Administrators can use the new "Install Replica from Media" feature to build replica DCs in remote sites.

When an administrator needed to build the first Windows 2000 replica DC in a remote site, the entire AD database had to be replicated across the WAN from an existing DC. This could take a long time and generate a large amount of network traffic, particularly for large ADs. If the remote DC was also a GC server, the problem was exacerbated.

An administrator can now perform initial DC replication by backing up an existing DC or Global Catalog server to removable media. The backup files, generated by any AD-aware backup utility (such as the included NTBackup utility), can then be transported to the candidate DC using media such as tape, CD, or DVD. This means the network is used to replicate only those changes made since the backup was performed.

The Price of Increased Flexibility

Although most administrators will welcome the new Windows .NET Server AD capabilities, two of the new features have important caveats.

Domain rename and restructuring is not easy. Even though Microsoft provides tools and guidelines to help administrators rename a domain or change its position, it involves 34 pages of procedures and many potential pitfalls if the administrator does not fully understand the process and rehearse it on a test environment. Even when done properly, these tasks will involve many machine reboots and periods of AD and user downtime.

Microsoft acknowledges that it is still better to avoid this process through advanced planning whenever possible.

Cross-forest trusts don’t provide synchronization. Although cross-forest trusts allow users in the trusted forest to use their normal user accounts to access resources in the trusting forest, in some cases this is not enough. For example, if an organization with multiple forests is using Exchange 2000, it may want its global address book to have entries for all of the organization’s employees. However, the address book is based on entries in the Global Catalog of the forest to which the Exchange Server belongs, and will normally not have the e-mail names and distribution lists for users and groups in the other forests.

This problem can be rectified by using a synchronization tool, such as the Microsoft Metadirectory Services (MMS) product, to create corresponding Exchange "contacts" in each forest that represent user accounts in the other forests. (See "Metadirectory Services Tackle Identity Management" on page 8 of the Dec. 2000 Update.)

Although the current MMS 2.0 product would introduce a whole new level of cost, complexity, and potential for problems, a simpler solution is imminent. According to Jackson Shaw, technical product manager for Windows .NET Server, Microsoft will be introducing a simpler, limited version of MMS specifically geared to synchronizing multiple AD forests only. Named MMS Standard Edition, the new product will come with a graphical interface that guides administrators through this scenario.

Resources

For more information on the Windows .NET Server AD (including information on developer-oriented AD features and other new Windows .NET Server features), see www.microsoft.com/windows.netserver.

For more information on the Domain Rename Tool, see www.microsoft.com/windows2000/downloads/tools/domainrename/default.asp.

More information on MMS can be found at www.microsoft.com/windows2000/technologies/directory/MMS.