You might still be wrestling with your Windows 2000 deployment. You don't have the time or inclination to consider a migration to Windows .NET Server (Win.NET Server). But you might want to take a moment to see what Win.NET Server has to offer: Although Win.NET Server isn't a momentous release, as Win2K was, it offers some serious new features and significant improvements that smooth out some of Win2K's rough edges. The complete list of Win.NET Server's new and improved features is long, but the product's key infrastructure improvements—such as Active Directory (AD) modifications—can present compelling business reasons to consider the new platform.
What's New
Let's start with the features that are new to Win.NET Server. Few of Win.NET Server's new features are radical departures from the Win2K feature set; rather, they're logical extensions of existing functionality.
64-bit Windows. Windows .NET Enterprise Server, Windows XP Professional Edition, and Win2K Datacenter Server are the first Microsoft OSs to fully support 64-bit computing. The new 64-bit architecture shines most brightly in its ability to support and speed up large, memory-intensive applications. Whereas 32-bit Windows can address as much as 3GB of user address space in virtual memory, 64-bit Windows can address as much as 16TB—a 5000 percent improvement. Therefore, the system can run much larger data sets in physical memory (and avoid paging to the much slower disk subsystem) than 32-bit Windows can.
Domain Rename. In Win.NET Server, Microsoft has redressed the near impossibility in Win2K of renaming AD domains. (Even so, renaming AD domains is a dangerous prospect and isn't something you should consider lightly.) Microsoft has prepared a 28-page document about the Domain Rename tool at http://www.microsoft.com/windows2000/downloads/tools/domainrename/default.asp. The article walks you through the process of renaming a Win.NET Server domain. If you need to rename domains in your environment, this new functionality offers a powerful incentive to upgrade to Win.NET Server.
Install Replica from Media. A common complaint among administrators of companies with branch offices is that installing a domain controller (DC) at a small office that has a slow network connection is difficult. In Win2K, when you promote a server to a DC, the new DC copies the AD database from another DC in the site. If no other DCs reside in the same site—a common occurrence in branch offices—the data must be replicated from a DC across a WAN circuit that likely has limited bandwidth. This replication can deal a severe blow to the network performance of Microsoft client machines.
Win.NET Server's Dcpromo utility lets you load the AD database into the new DC from a system-state backup, as Figure 1 shows. You can burn a zipped system-state backup to CD-ROM—a 2GB system-state backup compresses down to as little as 400MB—and express-mail it to the branch office that's installing the new DC. The branch office unzips the backup to a temporary location, uses Ntbackup to restore it to an alternative location, and uses the Dcpromo /adv command to import the AD data into the new DC. AD then replicates the data from another DC to incorporate any changes that have occurred since the creation of the system-state backup.
Functional levels. Functional levels are descendants of Win2K's native mode. In Win2K, native mode is a versioning mechanism that enables full AD functionality across the domain—as long as you don't have any downlevel (e.g., Windows NT 4.0) DCs in the domain. Functional levels take this concept beyond the domain to the forest.
Win.NET Server offers two functional levels: domain functional level and forest functional level. Domain functional level is the Win.NET Server equivalent of Win2K's native mode. When you raise the domain functional level from Win2K to Win.NET Server, you can't have any downlevel (i.e., Win2K or earlier) DCs in the domain. The primary benefit of elevating your domains to Win.NET Server domain functional level is that doing so prepares your forest for an eventual elevation to forest functional level.
After you raise the domain functional level on every domain in your forest to Win.NET Server native mode, you can raise the forest functional level to Win.NET Server. When you achieve this functional level for the forest, you can't promote any of the forests' non-Win.NET Server machines to DCs.
Advancing AD to forest functional level makes improvements to many forestwide operations (e.g., AD synchronization improvements), which I describe later. To change functional levels, go to the Microsoft Management Console (MMC) Active Directory Domains and Trusts snap-in, right-click Active Directory Domains and Trusts above the domain container, and click Raise Forest Functionality to access the dialog box that Figure 2 shows.
Forest trust. Win2K uses Kerberos as its authentication protocol—a significant improvement over NT 4.0's NT LAN Manager (NTLM) protocol. But in Win2K, Kerberos authentication for Windows is only forest wide. If two or more forests need to share resources—for example, if you have production and development forests, or if you're undergoing an acquisition—you must set up NTLM trusts between every domain in each forest. If you have more than two forests, the web of trusts quickly gets out of hand and isn't as functional as the Kerberos trusts within a forest.
Win.NET Server forests that you elevate to forest functional level can use a new feature—forest trust. Forest trust is a one-way or two-way Kerberos transitive trust between two forests' root domains. Because the trust is fully transitive, authorization and authentication occur transparently between the linked forests. If you need to integrate separate forests into a federation of forests (an organization of two or more independent forests), or if you need to use one forest as an account forest (a scaled-up version of an NT 4.0 account domain) to support single sign-on (SSO) functionality throughout your company, this feature is an especially attractive Win.NET Server enhancement.
Netlogon Group Policy. Microsoft has added many new policies to Win.NET Server's implementation of Group Policy. One set of policies that the infrastructure administrator will find particularly interesting resides in the Administrative Templates\System\Net Logon folder. These policies replace some Netlogon-related settings that Win2K requires you to configure in every DC's registry. For example, Figure 3 shows a new policy that lets you force site coverage for a distant site—functionality that's particularly useful if you need to configure DC failover for a site that has only one DC.
Another helpful new Win.NET Server feature is the thorough Help information, which you can access directly from the snap-in's focus pane, in the Administrative Templates policies. Unfortunately, this new Help information is available only in the Administrative Templates—not in other Group Policy locations where it might be equally useful.
Site coverage typically occurs when a DC starts up and discovers that a nearby site has no DCs. The discovering DC registers its SRV records in DNS for its own site and also for the DC-less site. As a result, the clients in the DC-less site think the discovering DC is in their site rather than simply covering for them. Clients in the DC-less site then have a relatively close DC with which to authenticate. Default site coverage applies only for sites that have no DC—not when a site's only DC crashes.
To set up DC failover in a disaster scenario, an administrator must add a registry key to force a potentially covering DC in a nearby site to register itself in the single-DC site. If you have many DCs across your enterprise, however, such manual configuration can be time-consuming. Using this policy in conjunction with a site-based Group Policy Object (GPO) can reduce the amount of individual DC registry modifications that you need to perform.
What's Improved
Now let's focus on Win2K features that Win.NET Server has improved. Improvements are the core of Win.NET Server's appeal. Many of these improvements address scalability, whereas others provide ease of management.
Universal Group Membership Caching. To understand the importance of this improvement, you must consider the difficulties of Win2K branch-office design. In NT 4.0, branch offices benefit from an onsite DC because users log on locally instead of over a typically narrow-bandwidth WAN circuit. This situation remains in Win2K, but the Global Catalog (GC) adds a new wrinkle. The GC contains all the objects in the AD forest but only some of the objects' attributes. Also, because universal groups can reside in any domain in the forest (and can contain users from any domain in the forest), GC servers are the only servers that contain a list of all the universal groups (including their memberships) in the forest. When users log on, their friendly neighborhood authenticating DC can't know every universal group a user's account belongs to because non-GC DCs have information about only their individual domain. Therefore, the Win2K authentication process requires users to contact a GC server to obtain a list of the universal groups to which they belong.
In a branch office, users must either contact a GC server over the WAN or make their local DC a GC server. If users must contact a GC server over the WAN, successful logons are totally dependent on WAN availability. If users contact a local GC server, the WAN link gets hit with the significantly higher replication overhead that a GC experiences. To make matters worse, replication traffic across the forest increases with the number of branch offices that contain GC servers.
Universal Group Membership Caching lets you configure a site so that all the site's DCs cache their authenticating users' universal group memberships. Therefore, branch-office DCs needn't contain a GC and can be largely tolerant of WAN failures. Users in the site must contact a GC server the first time they log on. Then, the site's authenticating DC caches the users' universal group information, so they don't need to contact a GC for subsequent logons. For security, the system refreshes the cache (from a site that you select) at regular intervals. Figure 4 shows Universal Group Membership Caching enabled for a field sales office in Frisco, Texas. The site refreshes its cache from the main office in Austin.
The Intersite Topology Generator. The ISTG, an important but fairly obscure feature of AD replication, is a component of the Knowledge Consistency Checker (KCC)—an AD process that determines the replication topology between DCs. The KCC on every DC in a site computes the best replication topology within a site. In Win.NET Server's scaled-up version of the same process, one DC (called the ISTG server) in each site works with ISTG servers from other sites to compute the best replication topology between sites.
Why should you care about improved ISTG functionality? If you have many sites in your AD forest, the Win2K KCC begins to tie up the ISTG server's processors as they try to compute a replication topology for the sites. For example, if you have one domain and more than 1000 sites, ISTG processing can take more than 15 minutes—the interval for recomputing the topology—and so can never catch up. Win.NET Server's improved ISTG functionality uses an algorithm that's about 200 times as fast as the Win2K version and quickly resolves even the most complex site topologies. (For further information about ISTG servers, see the Microsoft article "How to Optimize Active Directory Replication in a Large Network" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q244368.)
AD synchronization improvements. If you're planning Microsoft Exchange 2000 Server or other AD-aware application rollouts, Win.NET Server's AD-synchronization improvements will appeal to you. But first, you need to understand a key problem of AD synchronization in Win2K.
Because of a GC's contents (all objects and some attributes), the GC's footprint typically makes up a significant percentage of the AD data file (i.e., \%systemroot%\ntds\ntds.dit). If all this extra bulk replicates across the forest, you can see why a full synchronization of the GC has a large AD-traffic impact on your network.
If you use the MMC AD Schema snap-in to access an attribute's properties sheet, you'll notice a Replicate this attribute to the Global Catalog check box. This check box determines the GC's contents. The collection of all attributes for which this check box is selected is called the Partial Attribute Set (PAS). In Win2K, if you change the contents of the PAS by selecting or clearing this check box for any attribute, the entire contents of the GC synchronize across the forest. This big network event is likely to occur whenever you bring an AD-aware application into your forest because such applications often add objects to AD that need to have forestwide accessibility. Win.NET Server improves this functionality in one simple way: When you change the contents of the Win.NET Server PAS, a full GC synchronization doesn't occur—only the change replicates across the forest.
Terminal Services. In Win.NET Server, Microsoft makes its impressive Terminal Services product even better. One improvement is the ability to scale up to Terminal Services farms, in which a Session Directory server remembers user sessions on one of many terminal servers in the farm. A second improvement is a small command-line option (i.e., /console) that you can execute on the Terminal Services client. This option lets you attach to the server's console session, as a local operator would, to perform such administrative tasks as remotely installing software (e.g., some virus scanners) that require a console installation. You can also access pop-up dialog boxes that appear only in the console. In these respects, Terminal Services can finally stand as a fully functional remote console manager.
The Group Policy Management Console. The GPMC, which Figure 5 shows, is a new MMC snap-in that enables unified Group Policy management across an enterprise. The tool encompasses a set of scriptable interfaces that let you manage all aspects of Group Policy from one location. To address several difficulties of working with Group Policy in Win2K, the GPMC provides the following:
- One snap-in instead of at least four separate tools in Win2K. (The native tools are still present in Win.NET Server.)
- A UI that's based on how administrators use and manage Group Policy rather than on Microsoft's architecture for the technology.
- The ability to back up and restore, import and export, and copy and paste GPOs.
- Reporting on GPO and Resultant Set of Policies (RSoP) data. In Win.NET Server (unlike Win2K), users with read access can use the GPMC to view GPOs.
- Scripting of GPO operations for the GPMC tool (although you can't use scripts to change the GPO settings).
The integration of features in this tool's UI is impressive. With just a few clicks, you can obtain information for which Win2K requires you to grind through several tools while collating data on a scratch pad.
Because the GPMC doesn't require a .NET infrastructure, this tool doesn't play into your decision to upgrade to Win.NET Server. Microsoft will release the free GPMC tool as part of a separate product cycle shortly after releasing Win.NET Server. The utility will work in both Win2K and .NET infrastructures; however, the client must run XP Service Pack 1 (SP1) or Win.NET Server
And There's More...
Win.NET Server offers many improvements beyond this article's focus. Features such as RSoP, new command-line tools, deactivation of object classes and attributes in the schema, universal group replication changes, and application partitions all deserve further examination. Although Win.NET Server is considered a "point" release, its ease of upgrade and number of significant updates justify its presence in your organization. For more information about Win.NET Server, see "Related Articles in Previous Issues."
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows & .NET Magazine's Web site at http://www.winnetmag.com. JAN DE CLERCQ "Security in a Windows .NET Server Network," October 2001, InstantDoc ID 22248 "Building a Secure .NET Infrastructure," June 15, 2001, InstantDoc ID 20933 DARREN MAR-ELIA "Understanding the "Net" in .NET," November 15, 2001, InstantDoc ID 22759 MICHAEL OTEY "Microsoft .NET Enterprise Servers," June 15, 2001, InstantDoc ID 20932 "Whistler Comes Together," March 15, 2001, InstantDoc ID 19875 |
