With Microsoft about to issue a second release candidate of its upcoming Windows .NET Server 2003, many companies have begun evaluating the new platform in earnest. The new Internet Information Server 6.0 has a redesigned architecture that offers better performance and the ability to deploy more secure and reliable applications. For companies that want to build an n-tier application design, Microsoft will even offer a lightweight “Web server” version of .NET Server designed to be deployed as the presentation-layer machines for a data center.

.NET Server will also be the first Microsoft OS system to ship with the .NET runtime (version 1.1) fully integrated. This integration includes new management tools and integration with other key features of the OS, like Active Directory (AD). The packaging of the .NET runtime and application services (IIS, transaction management, etc.) with the core network OS means that buying .NET Server is now the functional equivalent of purchasing a UNIX OS and a third-party application server to manage application objects.

In fact, the Microsoft solution will be more powerful due to the integration between the core user authentications provided by the OS. The authentication required by the application services will be more tightly managed by AD than any combination of a UNIX version and an application server provided by a third party.

But therein lies the rub. Although implementations of AD have been increasing in recent months, the slow adoption of AD has been a frustration for Microsoft. For enterprises to take advantage of the vision of an integrated services platform, it’s critical that they embrace the core authentication and authorization store on which the platform is based.

What’s taking so long?
In talking with CIOs who’ve adopted AD, I’ve found that their decisions are based on one of two key reasons. First, they’ve chosen to upgrade to Exchange 2000, which won’t work without an installed AD implementation.

The second reason is their fear of continuing to live on Windows NT 4.0, given its scheduled “retirement” at the end of the year. Without the ability to get ongoing support for NT 4.0, prudent CIOs have already begun the move toward implementing a Windows 2000 infrastructure, including AD. Their hope is that with the release of the .NET application platform and its ability to tightly integrate with AD, the trickle of AD-enabled applications will turn into a torrent.

But why haven’t organizations migrated to Windows 2000 and AD naturally? One simple reason—the current AD implementation allows little margin for error. If you design AD poorly, re-architecting it with the current set of management tools is difficult or, in some cases, impossible. Even if you do everything right, an acquisition or merger with another company running AD will require the same re-architecture exercise.

Another key problem is AD’s global storage of application attributes. In the current implementation, if a development team in Division A adds a User Shoe Size attribute to the directory, that attribute is replicated globally to all other divisions. This means that not only can those divisions not add a similarly named attribute, they pay the replication and AD bloat cost without getting any benefits from usage of the attribute.

Solving these two problems to encourage adoption and development of AD were two key design points for .NET Server 2003.

Better manageability features
Microsoft has provided new management and administration features in .NET Server that allow administrators to rename domains and manage cross-domain and cross-forest. There are also new tools that allow grafting of domain trees to allow administrators to change the structure of the domain without having to re-install or migrate to a new domain.

New tools like the Group Policy Management Console (GPMC) allow administrators to delegate management and more easily apply directory attributes to users and other resources. Surprisingly, one of the most requested features from engineers was the ability to use command-line tools. In this release, Microsoft allows most administration tasks to be driven from the command line, allowing utility or maintenance jobs to be scheduled and executed by a process rather than accomplished manually.

Recognizing that many companies will still have the business need to support multiple directories, Microsoft has integrated its Metadirectory Services (MMS) into the OS. This feature was previously a Windows 2000 add-on. MMS allows companies to integrate identity information from multiple directories, databases, and files with AD. Using MMS, administrators can get a unified view of user identity information and synchronize the information across different directory systems in an organization.

The beauty of application mode
Another issue now solved by .NET Server relates to software development. Developers who wanted to use AD to store application attributes were consistently rejected by AD administrators who didn’t want the AD cluttered with divisional or application-level information.

Microsoft solves this problem in .NET Server by allowing a subset of AD to run in what’s called Application Mode (AD/AM). When running in Application Mode, the AD/AM instance provides an application with access to attributes and authorization information but the enterprise AD provides the application with authentication and service publication information.

Organizations can also run multiple instances of AD/AM on the same box to centralize management or on different boxes to distribute management. For instance, a company could have each division run its own instance of AD/AM locally to manage application attributes but still reference the enterprise AD for their authentication. The addition of AD/AM makes .NET Server much more flexible in the way its services can be deployed and managed.

No better time to evaluate
Better management tools and more flexible deployment clearly make .NET Server worth evaluation, especially for enterprises that have been holding off from deploying AD. If you’re in the middle of an AD deployment, there’s no reason to wait for .NET Server to be released. You should finish the current deployment, but add a task to your project plan to evaluate how to take advantage of .NET Server’s new management and deployment capabilities once it is released.