In a recent survey of Window & .NET Magazine readers, 51 percent of respondents said they had implemented Active Directory (AD) on at least some servers in their organization and 15 percent said they had an active AD migration project. However, even in shops with AD deployments, readers still had some Windows NT servers, which means they hadn't fully deployed AD in those organizations.
AD has been available since February 2000. So why are IT administrators taking so long to adopt AD, and why have 34 percent of respondents to the Windows & .NET Magazine survey not even started on an AD migration project?
First, managing AD is complicated. Windows & .NET Magazine and its related publications have published thousands of articles about AD. We know managing AD isn't easy, but we also know how important it is. Many of the administration improvements of Windows Server 2003 and Windows 2000 require a successful AD deployment.
Does Microsoft make it easy to migrate from NT to Win2K AD? Not really. An NT 4.0 administrator has many options to choose among and some technology to learn when implementing AD. Fortunately, good migration tools are available from companies such as Aelita Software and Quest Software.
The Cost and Benefits of AD
AD is expensive. If you need only file services, you can get a Windows Powered Network Attached Storage (NAS) system from any major storage vendor and avoid paying any Client Access Licenses (CALs). However, as soon as you authenticate to an AD domain server, you must pay for a CAL. AD isn't cheap, especially if you want to use it only for authentication.
One way to justify AD is to think of it as a platform for directory applications. Think of all the places that you store user information: human resources (HR) systems, phone systems, email systems, file systems, applications, and more. You can extend the AD database to add the fields necessary to help you build a unified directory system—a central user repository for all your applications. In an ideal environment, you would add a user to AD and put the user into the appropriate group. That user would automatically be configured in the voicemail system and authenticated in the appropriate applications. Likewise, when a user is removed from the system, all the appropriate references would be removed and any files that user "owned" would be reassigned to a new owner.
Some of these AD-enabled applications might include corporate white pages—basically the Global Address List (GAL) with a pretty face. Many enterprises spend big money on Lightweight Directory Access Protocol (LDAP)enabled white-pages applications such as those from Oblix and other vendors. These applications add a Web interface and workflow improvements (e.g., self-help attribute changes). AD has a fairly complete feature set for corporate identity, so why not leverage those features?
Another example of an AD-enabled application is a single-source application authentication repository. This type of application isn't really a metadirectory, but serving as a metadirectory could be part of its function. Again, because AD is ubiquitous, it's a perfect source of identity and authorization for internal applications. For example, you could use AD to authenticate users to internal Web applications and authorize access to those applications according to group membership. This approach is easy, cheap, and—because it's based on LDAP—cross-platform.
You can also use AD as a single source for business-process rules and policies. Yes, this approach encompasses Group Policy Objects (GPOs—which independent developers can extend), but the fact that AD is extensible also means that you can encapsulate other business rules in the directory. You can put most kinds of business rules in AD. For example, AD stores data about reporting structure (as the reports to attribute), so you could use AD for simple workflow.
And you can use AD as an integration point with other corporate directories. Because it functions as LDAP, AD can easily participate in or even act as a metadirectory.
Unfortunately, most companies that have implemented AD haven't achieved anywhere near the level of functionality that these examples describe. So they view AD as an updated authentication method that doesn't seem worth the cost of the CAL fee.
First Comes AD
In a way, AD is like a huge dam holding back the waves of technology that are coming at IT administrators from Microsoft. Without AD, you can't take advantage of Group Policies and other administrative features. In fact, you can't upgrade to the latest version of Microsoft Exchange Server. Many features of Windows 2003 are unavailable to you if you can't migrate to AD. Win2K's greatest feature, AD, seems to be its biggest stumbling block to adoption.
So, how do we get important IT administration technology working for everyone? I have one suggestion for administrators and one suggestion for Microsoft.
First, if you're stuck trying to justify the AD migration as a standalone project, try marrying the AD migration project to a server-consolidation project. You can buy migration and server-consolidation tools that work together. Server consolidation lets you reduce administration costs, reduce complexity, and significantly improve performance if you migrate your data from older, less reliable machines to new, high-end servers with high-performance NAS and Storage Area Network (SAN) storage infrastructure. According to documented server-consolidation case studies, many companies are seeing significant reductions in the numbers of required file servers—as much as 7-to-1 reductions—and realizing huge gains in performance and reliability. At the same time, they're migrating their old machines from NT to Win2K, which lets them use the AD-based tools in the process.
Second, Microsoft should consider eliminating the need to buy a CAL for AD authentication. Typical Linux environments don't charge for a CAL for authentication. Granted, LDAP is not as sophisticated as AD, but it gets the job done. Microsoft needs to compete with the rapid Linux server adoption, and eliminating CALs for AD authentication is one way to do it.
When Microsoft released Win2K, the marketing folks assured me that our readers would upgrade. However, for many reasons, our readers have held back, costing Microsoft billions of dollars in delayed licensing fees. Perhaps Microsoft should consider subsidizing the cost of expert migration consultants to help organizations that are still on Win2K or NT make the move. The faster everyone gets to Windows 2003, the faster we can all put this new technology to work.
