Microsoft is hard at work on Windows Server (formerly code-named Whistler), the next version of Windows. Before you sigh and say, "Oh, no. I haven't even figured out Windows 2000 yet," relax—Windows Server isn't nearly as big a change as Win2K Server was. Think of Windows Server as Win2K 1.1, and you'll have reasonable expectations for the upcoming product.
However, Windows Server will be more than Win2K with bug fixes and driver updates. Although Windows Server won't be a revolution, it will be a significant evolution, as I discovered by talking with some of the Active Directory (AD) folks in Redmond. In Windows Server, AD will have some nice new features.
Group Limits Disappear
You might know that under Win2K's AD, you can't have a group that contains more than about 5000 members, under typical circumstances. (I say "under typical circumstances" because I've heard—but can't substantiate—that you can stretch that Win2K limit considerably if your domain controllers—DCs—have a prodigious amount of RAM and very fast CPUs.) However, Windows Server will apparently have no practical limit to the number of members in a group.
Partitionable Replication
AD's multimaster replication is much more flexible than Windows NT's single-master replication is. Because any DC can receive a new piece of information such as a new user account or a changed password, Win2K needs to somehow create a pathway for the updated information so that no matter which DC gets the new piece of data, every other DC will receive a copy of that data.Win2K contains a fair amount of machinery that enables AD replication, and other services besides AD could benefit from using that replication engine.
For example, you can make your DNS zones into what Microsoft calls AD-integrated zones. The importance of such zones is that DNS updates, which are single-master in most standard DNS server implementations (meaning that only one DNS server on the planet can accept changes to a given DNS zone's information), are now multimaster, so more than one DNS server can receive zone updates. DNS servers in AD-integrated zones solve the problem of using single-master DNS products to manage multimaster zone replication by piggybacking on the AD replication engine. This solution essentially gives AD the responsibility of moving the data around while keeping it consistent.
But this solution also has a cost. Clearly, adding DNS information to AD increases the amount of data that AD needs to shuffle around the network. In addition, as AD replicates its domain data to every DC in the domain, every DC—even if it isn't a DNS server—receives a copy of the domain's DNS zone information, provided that the zone is an AD-integrated zone. So, if you had 1000 DCs and only 150 of them were DNS servers, you'd like to be able to tell AD to replicate the DNS zone information only to the 150 DCs that are DNS servers. In other words, you'd like to be able to partition how AD replicates data.
Windows Server can partition replication. A developer can create a piece of data on a DC, then use AD's replication system to replicate that data to other DCs while telling AD, "When you replicate this data, don't send it to every DC—send it to only the DCs on this list." In AD geek-speak, you'd say that the developer will be able to create a custom naming context.
Now, don't get too excited: Although I use DNS zone data to explain how AD will be able to partition replication, apparently Windows Server isn't slated to give DNS its own naming context. However, I did infer that Microsoft eventually would like DNS to have its own naming context.
Create DCs from AD Backups
NT has always had trouble with rollout tools. For example, you're not supposed to simply copy one Win2K Professional or NT Workstation image to thousands of other systems, because doing so duplicates SIDs—and duplicate SIDs can cause big problems. But tools such as Win2K's Sysprep utility came to the rescue, and now many Win2K and NT administrators happily use Symantec's Ghost, PowerQuest's Drive Image Pro, or similar tools to crank out images. Nor does imaging work only for workstations—you can create images of servers, too—unless the servers happen to be DCs.
Mass-producing BDCs has always been a pain in the neck. (I know that in Win2K we don't call the second or subsequent DCs in a domain "backup" DCs; we simply call them DCs. For a while during the Win2K beta process, Microsoft called such a DC a replica DC because theoretically every Win2K DC is equal. But the first DC in a domain usually is special because it contains several jobs called Operations Master roles. If you lose that DC without moving those roles, you'll have trouble. So, the term replica DC disappeared by the time Win2K became commercially available. We still need a short term that means "DCs that don't hold an Operations Master role"; until we get one, I'll continue to use the term BDC.) Like NT 4.0 and NT 3.x, Win2K requires that to create a BDC, you be connected live on the network to another DC.
That requirement can make your job much more difficult. For example, let's say that you're the administrator who needs to go to your company's Toadstool Canyon branch office to set up the local DC and that connectivity between Toadstool Canyon and the home office is no better than a 56Kbps modem. While you're in the process of running Dcpromo to create the new DC, Dcpromo will insist on talking live to another DC and replicating the entire AD database from that DC over the 56Kbps link. Although that situation might be great for racking up overtime, it's no fun.
One answer is to set up the new secondary DC in the home office and let the new DC do its initial replication over a LAN. Then, you can ship the DC to Toadstool Canyon, plug it in, and have it occasionally dial up to the mother ship to replicate only the changes to AD rather than the entire domain database. But sometimes you just can't use that approach—the branch office paid for the computer and won't ship it to Corporate for some obscure political reason. So, you're stuck playing FreeCell while you wait for the 56Kbps replication to finish.
With Windows Server, when a new BDC needs to connect to another DC to replicate AD, you can simply give the new DC a backup of AD. I haven't seen this feature's UI, so I don't know exactly how Windows Server accomplishes the task. But the Microsoft folks tell me that you'll be able to load an AD backup from a CD-ROM, Zip disk, tape, or whatever you have. The new DC's copy of AD probably will be a bit out of date. But a slightly outdated AD doesn't cause a problem: After the new DC is running, it can establish a WAN link to an up-to-date DC and replicate only the AD changes to bring the copy of AD up-to-date.
Smarter Global Catalog
The Global Catalog (GC) is a subset of all the domains in an AD forest and contains a few pieces of information about every user. One of the GC's main benefits is that it simplifies the logon process in a multidomain forest. In fact, if you have a forest with two or more domains, under Win2K you can't log on to a machine if that machine can't locate a GC server. Working in a branch office that doesn't have a GC server might mean that you can't even log on to your Win2K Pro workstation if your branch office temporarily loses its connection to another office's GC server.
If you were in that situation under Windows Server, however, you'd probably be able to log on without difficulty. DCs that run Windows Server will cache information that they receive from a GC server.
In addition, Windows Server's GC replicates differently. As I said, the GC is a subset of the AD domain databases in a forest's various domains. You can choose to change that subset and tell the GC not to include some items or to add some others. (You might think you'd never want to add items to the GC, but the installation program for an application such as Microsoft Exchange 2000 Server that extends AD might add some of its new schema fields to the GC.) What you might not know—as I didn't—is that as soon as you add a new item to the GC, the GC rebuilds itself from scratch, sparking an awful lot of network (and potentially WAN) traffic.
For example, let's suppose that each AD domain contains 100 pieces of information about each user, but the GC needs only 10 of those items for replication. Then, let's say that you—or more likely some setup program—add another item to the GC. Under Win2K, a GC server will contact DCs all over the forest and request that they replicate all 11 items to that GC server. The GC essentially forgets what it knows about the 10 items it already has.
Under Windows Server, a GC server would request information about only the new item. However, you must first use a registry switch to put your forest in Whistler Forest Mode, which indicates that you've upgraded all the forest's DCs to Windows Server. You can think of Whistler Forest Mode as being like native mode in Win2K.
The Redmondites wouldn't say when Windows Server will ship, and I'm not about to pressure them, as a later and more bug-free product is always preferable to an earlier and buggier one. But based on what I've learned about Windows Server, I would say that the new OS will be good news for AD users.
