Microsoft released Windows 2000 Server, and with it, Active Directory (AD), on February 21, 2000. So by the time you read this commentary, AD will have celebrated its fourth birthday. So how's AD doing at 4? Some good, some bad.
Let's begin by looking at the bad. For starters, AD hasn't lived up to adoption expectations. In 1999, Bill Gates' minions expected 60 percent of the Windows NT 4.0 domains to convert to AD by the time AD was 6 months old. But AD never experienced that growth spurt to become "the toddler that bestrode the world." Instead, AD is probably just now reaching that 60 percent mark. That 60 percent guess is based on the fact that I've spent a lot of time talking to thousands of users over the past 4 years, rarely seeing percentages of AD users greater than 60 to 65 percent.
So why haven't all environments migrated to AD? I suspect the migration was slowed for several reasons. Any product that arrived in February 2000 was doomed to slow adoption. The IT world had just finished dealing with Y2K and wasn't jumping into any major network changes. And AD's competition--NT 4.0 domains--was still quite good. Although I'd be cranky if I had to use NT 4.0 domains instead of AD domains, I can see why the proprietor of a butcher store or a dentist's office might not want to drop a few thousand bucks on a new-and-improved version of a product that was already working. Another reason for slow adoption is AD's massive planning requirements. Unlike NT 4, you can't just shove a CD-ROM into a drive and start clicking to end up with a working domain. AD absolutely requires careful thought and planning because the only answer to some AD planning failures is FDISK.
On the good side, AD is a quality product, and as long as you plan your AD infrastructure carefully, you'll experience few problems. Planning means first building a well-designed split-brain DNS infrastructure and sticking with that design--in my experience, DNS is the most common cause of AD problems. Decide where to place domain controllers (DCs), Global Catalog (GC) servers, and operations masters, then document that placement. Next, install AD DCs or upgrade old NT 4.0 DCs; however, if you intend to use Win2K, upgrade from a copy of Win2K Server that's had Service Pack 4 (SP4) slipstreamed onto it, because DCPROMO has grown a lot in 4 years. Do all that, and you should have a good AD experience.
As AD grows, I hope it will mature in flexibility. Planning a forest for a large organization is scary because of AD's inflexible nature. (Think of AD as a pencil without an eraser.) A Windows Server 2003-based AD is a bit more flexible because you can reshape an existing forest or link two forests with a single trust. But those improvements are baby steps toward what AD really needs. As companies merge and acquire new businesses, forests need to be able to merge and acquire to keep pace. Specifically, Microsoft needs to find a way to let two forests merge their respective schemas and GCs: We need the "forest shmooosh wizard." We need the ability to remove single domains or trees and make them into standalone forests, as in a divestiture scenario. And given AD's pervasive need for testing, we need to be able to quickly and easily duplicate an essential subset of a forest into virtual systems on VMWare or Microsoft Virtual PC platforms.
Let's say the boss asks you to try out the Microsoft Exchange Server 2007 beta, but inasmuch as Exchange 2007 (which doesn't exist, by the way, so don 't go looking for the beta) modifies the schema, you can't test the beta on your real network. But how do you create a test network that reflects your actual forest? With the "Virtualize Your Forest" wizard, part of Virtual PC 2004's Service Pack 1 (SP1). Unfortunately, Virtual PC 2004 SP1 also doesn't exist. But perhaps as AD grows up, its family will mature as well.