When Windows 2003 Server (formerly Windows .NET Server) was first announced, Microsoft made clear that a primary goal of this platform would be security. To implement a security model more resistant to hackers and crackers, Microsoft paid considerable attention to its Web server component, IIS 6.0, adding new features and modifying old ones. This article discusses the principal changes with special attention to running existing active server pages (ASPs) on the new platform.

The Big Lockdown
Microsoft has responded forcefully to the longstanding contention by the IT community that IIS turned every installation of a Windows server into a magnet for malicious attacks. The company's primary step is locking down IIS. When Windows Server 2003 is installed, IIS 6.0 is no longer installed by default. It has to be installed separately by the administrator. (In fact, domain admins can use a new group policy to prevent users from installing IIS on their own systems.)

And when IIS 6.0 is installed, it defaults to a secure "locked" mode, meaning it can serve up only static content. ASP, ASP.NET, and FrontPage Server Extensions are all disabled and have to be intentionally and separately enabled. If you forget to do so, IIS will return a 404 error to all requests for dynamic content.

The system is not quite as tight when upgrading from IIS 5.0. The upgrade wizard expects that your existing configuration of IIS is set up as you want it, and so it converts existing settings to the new version of 6.0. To avoid simply inheriting your existing security holes, Microsoft recommends running its IIS Lockdown Wizard before upgrading. The wizard helps identify, disable, and remove unused services on Windows 2000 Server that represent security weaknesses. In this way, these holes are not carried over to the upgraded installation. (Readers interested in running the Lockdown Wizard on existing systems—even without an upgrade in mind—can download it.)

Microsoft has made numerous other changes to IIS 6.0 in the name of security. Some of the most compelling are:

• Functions run in a low-privilege user space, which greatly limits the range of actions a user can take. To run executables in the system folder (such as the command-line window, cmd.exe), the user must be a member of the Administrators group. Essentially, anonymous users cannot launch executables on the host system.
• Anonymous users are by default denied write access to Web content.
• Access to the source code of ASP and other scripts is disabled by default. Access can be reset to read or write by the administrator.
• IIS 6.0 will serve up requests only to files with know name extensions. If the filename extension is not mapped to an established extension, the request is refused.

By these changes, which set defaults to their more secure rather than their more open options, it's clear that IIS 6.0 aims to cut off many of the traditional tools used by crackers to get in and damage systems. We can hope that Microsoft's choice of defaults that disable vulnerable features will encourage this practice in products from other software vendors.

Dual Operating Modes
When installing IIS 6.0, administrators can choose one of two operating modes: the new worker-process isolation mode, or the backwardly compatible IIS 5.0 isolation mode. The latter mode simply duplicates the functionality of existing programs and scripts. Like IIS 5.0, in-process applications run inside inetinfo.exe, and out-of-process applications run in separate DLL hosts.

In worker-process isolation mode, however, all application code runs on IIS 6.0 in one or more isolated environments. In this mode, the administrator is capable of isolating everything—from applications to entire sites—in self-contained worker processes. The aim is to block an application in one process from crashing another.

But the isolation has other benefits: It facilitates several management tasks—such as restarts, changing the components used by a specific application, monitoring counters and resources, and debugging. Says Microsoft: "Unloading components becomes easier because with isolated application processes, the process can, if necessary, be terminated to unload all resources, with no effect on other content or applications being served from other processes."

In addition to these operating modes, IIS 6.0 supports two different processor architectures. Windows Server 2003 runs on 32-bit and 64-bit platforms, the latter running on Intel's Itanium family of processors. Likewise, IIS 6.0 is available for both platforms. However, on the 64-bit version of Windows 2003 Server, IIS runs as a 64-bit application. This means it cannot call 32-bit applications, such as using ADO to interact with an Access database. (However, ADO can be used to access 64-bit applications such as SQL Server.)

ASPs
Microsoft's .NET initiative places a high value on having developers migrate apps to ASP.NET and its ASPx pages. But developers who have considered this transition know all too well how correct is the contention of Destination .NET instructor, Ted Pattison, when he says "The use of the letters 'ASP' in ASP.NET is a ruse. Porting from ASP to ASP.NET is like porting code from one language to another." As a result, developers enticed by .NET's siren song might want to consider a provisional arrangement in which they continue to run ASPs on IIS 6.0 and then transition to ASP.NET as time permits and needs dictate.

Developers who opt for this approach need to know several things about IIS 6.0. For starters, a reminder of what was mentioned previously: In the pursuit of tighter security, ASPs do not run on IIS 6.0 out of the box. They have to be specifically enabled. So do ASPx pages. Both kinds of pages can run at the same time on IIS 6.0-a useful transitional feature.

ASP pages will find that using COM+ components is considerably easier. Previously, developers had to write their own COM component to call services from ASPs. On IIS 6.0, however, ASP applications can use some COM+ services without using a COM go-between. One important such service is the COM+ transaction service. Direct access here is expected to significantly improve performance.

IIS 6.0 also introduces the idea of COM+ partitions. Using these partitions, each application has its own private space in which the COM+ objects reside, as does configuration data and private data. This feature is particularly useful if a site is used by two customers or departments that must keep their data and their applications separate from each other. This arrangement also enables older versions of COM+ objects to run without interfering with other applications that need later versions.

A neat utility to help debug these scenarios is a new tool called COM+ Tracker. When tracker is enabled, it measures when ASPs are loaded, when COM components are loaded, and when threads leave a page. Like all similar debugging tools, COM+ Tracker, takes a toll on performance, and so should not be used as a general monitoring tool.

Overall
It is clear that Microsoft intends to use IIS 6.0 as a magnet to encourage shops to migrate to Windows 2003 Server. And on the basis of the improved security and the greater reliability of ASPs, there is no doubt sites that rely on ASPs will find these features compelling. Once the server product ships, sites will be in a position to ascertain the effectiveness of these new features and what their hidden cost might be. For developers and administrators considering such a migration, I have attached a list of technical resources that should be useful.

Resources