When I first started playing with early directory services products almost 10 years ago, vendors described their products as "X.500-like" to appeal to purists for whom the X.500 protocol was the epitome of a directory service. The impossibility of writing a directory service that conformed strictly and completely to the X.500 specification was one of the factors that led to the creation of Lightweight Directory Access Protocol (LDAP). LDAP was intended to give directory vendors a common, simple-to-use protocol that would let applications and directories talk to one another.
The journey from LDAP to Active Directory (AD) has been an interesting one. LDAP was the point from which most of the IT world began to implement directory services. What lessons can Microsoft glean from the evolution of directory services that will help the company contend with the less-than-warm reception AD has received to date?
A Short History of Directory Services
A good common communications and access protocol isn't everything that's necessary to make directory services a success with users, although such a protocol plays a large part. What prevented the early directory services from being successful was that no clear picture existed in users' minds of what to expect from a directory service. Vendors told users that a directory service was like a comprehensive phone book for their networks. Information about every user and every system would be available to users and administrators at the click of a button and to any application through simple programming. Administrators of Banyan VINES networks sat back and chuckled at the situation, because Banyan had already made such capability available. Unfortunately, few applications were available on the Banyan platform.
Novell and Microsoft narrowed the focus and managed users' expectations of a directory service. With Novell Directory Services (NDS), Novell could provide a good single sign-on (SSO) system to a broad variety of network resources. Microsoft realized that Novell had found the hook that would bring the majority of users around to the concept of directory services and "added" a directory service to Windows NT 4.0. (Microsoft didn't actually add anything to NT 4.0. Instead, Microsoft simply changed the description of the NT domain system in a supplement to the Microsoft Windows NT 4.0 Resource Kit to document the existing limited SSO capabilities as a directory service.) But if it did nothing else, the lip service Microsoft paid to the directory service idea went a long way toward legitimizing it, moving the idea from the world of the network engineer into the consciousness of the network administrator.
The Exchange Factor
Microsoft Exchange Server's success made the average network administrator aware of additional directory service capabilities. Exchange's ability to create information about a new Exchange user account and propagate that information directly to the user accounts in an NT domain simplified the creation of user and account information. Network administrators started to ask for functionality that comes naturally to directory serviceenabled applications. Administrators wanted the directory service's ease of use and, more important, deployment and manageability to become standard across all their network applications.
A problem existed in that the Exchange directory didn't play any part in Microsoft's plans for a directory service. With the benefit of hindsight, Microsoft will say it planned the difference between Exchange's directory and AD, but I believe that the company was as surprised by the success of Exchange as everyone else was. That success has made acceptance of AD that much more difficult, if only because the capabilities in Exchange would have been a perfect introduction to and deployment choice for AD, had Microsoft included AD as the backbone of Exchange.
A Tall Order for Redmond
You've probably read the news stories about Windows 2000's slow adoption rate and the analyses that explain it. What's lacking from most of the analysis is the recognition that even the sites that have begun to move to Win2K (and are now worrying about adopting Windows 2002—formerly code-named Whistler) are configuring Win2K Server as member servers in existing NT 4.0 domains. The release of the .NET Enterprise Servers, some of which have been very successful, has forced users to deploy Win2K Server to host most of those applications. These same sites have been staying away from AD in droves.
Many reasons exist for avoiding AD, but a few concerns stand out. First, of course, is the uncertainty users have felt about moving from NT 4.0 to Win2K. The widespread belief that doing so isn't a good idea has been reinforced by Microsoft's and the media's early and heavy coverage and promotion of the Windows XP (formerly code-named Whistler) platform. This extensive campaign has tended to keep folks from jumping on the server-side Win2K bandwagon. (For one expert's perspective about migrating to Win2K, see Paul Thurrott, Editorial, "Stay on Target," page 7.) Second, deploying AD (or any directory service, for that matter) isn't easy. You need corporate buy-in, because deploying AD is much simpler if you can deploy from the top down throughout the organization. Last, Microsoft didn't learn enough from Novell's experience with the first generation of NDS, which suffered from the same lackadaisical attitude toward adoption by the existing Novell NetWare user base that AD faces from the existing NT user base. NDS didn't include easy-to-use graphical tools that let users modify existing directory trees. After users realized that making major changes in existing trees was exceedingly difficult, any enthusiasm they might have had for the application took a hike.
Building tools for managing AD isn't easy. The Movetree command-line utility provides a glimpse of helpful functionality but is frustrating to use. If Microsoft knew that such a tool was necessary, why doesn't a GUI version exist? Users today are knowledgeable. They know what a good directory service can mean for improved management and maintaining a business advantage. But they're wary of getting involved in such an all-encompassing project as AD until they know that the tools exist to help them succeed. The tools don't have to come from Microsoft, but users have to believe that AD will be sufficiently robust to let them build on top of it without worrying that the AD structure won't support their business model. And they need to know that the AD structure is sufficiently malleable to let them change the way they do business as quickly as is necessary.
Resolving these concerns is a challenge to Microsoft, especially in light of .NET plans that concentrate on providing Internet services. A strong, flexible directory service is the key to making .NET work. AD still needs to prove that it can be that service.
