MSDN Magazine > Issues and Downloads > 2000 > August >  Migrating Your ASP Apps from Windows NT 4.0 to ...
This article may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. To maintain the flow of the article, we've left these URLs in the text, but disabled the links.
MSDN Magazine

Migrating Your ASP Apps from Windows NT 4.0 to Windows 2000

Shelley Powers
This article assumes you�re familiar with IIS, MTS, and ASP
Level of Difficulty    1   2   3 
Code for this article: Powers0800.exe(32KB)
In order to take advantage of new features in Windows 2000 and IIS 5.0, you must first migrate your Windows NT 4.0-based ASP applications to Windows 2000. This article provides a multi-step migration plan. It discusses how to install and configure IIS 5.0, set up security, migrate MTS packages to COM+ applications, and handle differences in the ASP object models. Also included are guidelines for setting up Visual Basic and Visual C++ for development in Windows 2000 and information on what to expect when moving ASP components to the new OS.
N
ow that Windows® 2000 has been released, you're probably taking a close look at your ASP applications, thinking about migrating them from Windows NT® 4.0. Of course you'll want to know if your current ASP applications work in Windows 2000 without changes. After all, migrating applications is not a trivial exercise. What exactly does it take to make your ASP applications move smoothly from Windows NT to Windows 2000?
      Before migrating your ASP applications, you'll want to know which functionalities can move to Windows 2000 with little or no impact, and which functionalities require minimal intervention to achieve optimal performance. You'll also want to know what changes in Windows 2000 and Microsoft® Internet Information Services (IIS) 5.0 could cause potential problems for your ASP applications if you aren't aware of them, or if you don't deal with them proactively before making the move. In other words, you're going to need a migration plan.
      To help jump-start your plan, I've created a multi-step migration process. Although I'll discuss them in more detail throughout this article, here are the basic steps you'll need to take:
  1. Install and configure Windows 2000 and IIS 5.0 on development, test, and production machines.
  2. Recreate your existing Web sites and virtual directories on all of the machines.
  3. Set up security in your test and production environments.
  4. Copy ASP application pages, along with supporting graphics and script, to the development environment. Additionally, copy any ASP components that exist outside of Microsoft Transaction Server (MTS) packages to the development environment.
  5. Migrate MTS packages to COM+ applications in the development environment.
  6. Install Microsoft Visual Studio® (or other development tools) in the development environment.
  7. Unit test the ASP applications (ASP pages and supporting components) in the development environment. Make any necessary modifications to ensure the applications behave the same in Windows 2000 as they did in Windows NT.
  8. Move tested and modified ASP applications and associated COM+ applications and components to the test machine and conduct compatibility testing. Additionally, try out different IIS 5.0 settings and use testing tools to stress test the applications in order to determine which settings work best for them.
  9. Move tested and performance-tuned ASP applications and associated COM+ applications and components to the production environment, one application at a time. Enable CPU tracking on each newly migrated ASP application to make sure the application doesn't take more than its fair share of CPU time. If necessary, apply CPU and bandwidth throttling on the newly migrated ASP application.
  10. Monitor the applications in production, as you do now in Windows NT, but using the new monitoring features provided with Windows 2000 (such as CPU tracking).
  11. Sit back and relax knowing you've done a great job of migrating your Windows NT-based ASP applications to Windows 2000.
      These steps might seem like a lot of work, but by the time you're done, your ASP applications should be up and runningâ€"without major redevelopment effort, and without any unexpected surprises after the applications have gone to production. Then you can begin checking out the new functionality provided by Windows 2000 and deciding how you want to take advantage of this new functionality in your ASP applications.

Installation and Configuration

      If you install Windows 2000 to a clean machine or to dual-boot with Windows NT, you can choose to install IIS as part of the operating system installation, or you can install the Web server later. When you upgrade an existing installation of Windows NT to Windows 2000, IIS 5.0 is installed automatically if the installer for Windows 2000 detects a previous version of IIS on your machine. The installation program also migrates the current IIS settings to the new environment wherever there are compatible settings between the two Web server versions.
      When you're migrating a production ASP environment, I recommend that you install Windows 2000 on a clean (newly formatted) hard drive and avoid dual-boot configurationsâ€"except perhaps on development machines.

New Properties in IIS 5.0 and ADSI

      Once IIS 5.0 is installed, you'll find that the Internet Services Manager (ISM) Management Console for IIS 5.0 differs somewhat from the one used with IIS 4.0. For instance, in the Virtual Directory tab or the Home Directory tab for a Web site (see Figure 1) the access and content control permissions are no longer grouped separately, and one new item has been added, "Script source access." Checking this new option allows Web access of script resources. To ensure that your script is not accessible, make sure this option is unchecked (the default setting).
Figure 1 IIS Management Console
Figure 1 IIS Management Console

      Another significant difference relates to controlling the ASP application settings. Instead of the checkbox option to run the application in a separate process, the choices are in a dropdown listbox labeled Application Protection, which contains three options: Low (IIS Process), Medium (Pooled), and High (Isolated). In Figure 1, the Medium option is selected.
      You'll find that running the application with the Low option in IIS 5.0 is similar to running the ASP application in IIS 4.0 when the separate process option is not checked. With this setting, the application runs in the same process as the Web services. If you choose the High option, the application runs in an environment similar to that in IIS 4.0 when the separate process option is checked. So the ASP application runs in a process isolated from other ASP applications and the Web server.
      The third option, Medium, is new with IIS 5.0. It allows the ASP application to run in a process isolated from the Web services, but shared with other, pooled ASP applications. This provides the advantage of a single process running all of the pooled applications rather than separate processes being created for each, which can negatively impact scalability. It also avoids security risks to the Web services (IIS), which remain isolated from this pooled process. For your production and test environments, consider accepting the default setting for Application Protection and run your trusted ASP applications within the Medium setting. You can then have fewer ASP application processes without risk to the core Web services.
      If you're creating an ASP component development environment, you'll want to run your ASP applications as separate processes so you can unload the application and recompile components during development. You should isolate the processes by choosing the High environment setting. Then you can unload your application by clicking the Unload button (as in IIS 4.0) to recompile your ASP component without impacting the other applications in a medium (pooled) environment, and without moving to shut down the Web server.
      Application isolation and downloading scripting source, in addition to other new options not covered here, aren't the only changes you'll find in IIS 5.0. There are also changes in the Active Directory™ Services Interface (ADSI) properties that are used to administer the site programmatically.
      One ADSI property, AspMemFreeFactor, is gone. This property specified a ratio of free memory blocks to used blocks, and IIS employed it to cache memory for ASP execution. If you've used ADSI to administer your site programmatically, check your existing code to make sure that this property is removed.
      Some of the other ADSI properties have different behaviors or different values. For instance, the ScriptMaps property is changed, as is the associated Application Mappings property sheet. In IIS 5.0, you now list all verbs that are included for an application mapping rather than listing only verbs that are excluded. However, unless you've added new application extensions to your IIS environment, you'll leave the current application/script mappings as is, so this metaproperty change should have little impact on your existing ASP apps.
      There are also several new ADSI properties, including a group that can be used to enable a new feature in IIS 5.0: CPU throttling. IIS 4.0 provided the concept of bandwidth throttling to prevent any one Web site from taking more than its fair share of the available Web server bandwidth. Starting with IIS 5.0, you can also prevent a site from taking more than its share of the CPU by enabling throttling either programmatically or using the ISM.
      Additionally, if your ASP applications use a lot of out-of-process functionality, you might want to consider enabling CPU tracking as you migrate your individual Web sites to Windows 2000. CPU tracking writes information about out-of-process CPU usage to the standard Web site log file. Though a new feature with IIS 5.0 and therefore not essential to the migration effort, this functionality can help pinpoint problem areas as soon as you port the sites, rather than after the sites have caused some havoc or slowed down other, better-behaving sites and ASP applications.
      Both CPU throttling and tracking can be easily turned on for a specific Web site using the ISM. Change the CPU tracking by accessing Log Properties and then select the Extended Properties tab, as shown in Figure 2. You can enable and modify the CPU (and bandwidth) throttling through the Performance property sheet for the site.

Figure 2 Log Properties
Figure 2 Log Properties

      If you prefer, you can create your own administrative ASP script to modify both CPU tracking and throttling. The ASP page shown in Figure 3 enables CPU throttling (using the default throttling of 10 percent) and also modifies the existing CPU tracking by turning on specific fields to print (matching those settings shown in Figure 2). This ASP page will then run within a restricted, administrative environment.
      As I stated earlier, using the new properties of IIS 5.0 and becoming familiar with the new ADSI properties aren't essential to the migration of your ASP applicationsâ€"but it wouldn't be a bad idea to know what they are before putting your Windows 2000-based ASP applications into production.
      Once IIS 5.0 is configured, recreate the Web sites and virtual directories of your existing ASP applications in the new Web server, setting the application protections according to whether the machine is in the development, test, or production environment. Once these ASP applications have been created, the next step is to make sure the right folks can access the right pages.

Set up Security

      You'll want to set up application security that's comparable to or better than what you had in your Windows NT-based installation. I have some good news for you; there are more security options, more granularity of security, and more consistent application of security for your Web applications within Windows 2000. And there are also some handy new security wizards in IIS to help walk you through the security settings.
      Your first line of defense in Windows 2000 is the same as it was in Windows NT: setting the file and folder access permissions with NTFS. Web security lacks the granularity you get with NTFS, and if you want to fine-tune which users can read or write to a file or folder or execute a particular application, set the access permissions with NTFS. While you are setting the permissions, note that the anonymous Web user is still IUSR_machinename, as it was with Windows NT.
      Two wizards are used to set up certificates and assign certificate trust lists (CTL). You can run the Web Server Certificate Wizard by accessing the Directory Security property sheet for the Web site and then clicking on the Server Certificate button in the page. The Certificate Wizard will pop open and ask you for information about the certificate to be set up for the site, such as the name of the certificate and locale information for the Web server. The wizard then generates a certificate request file that you can send to the certificate authority, as shown in Figure 4.
Figure 4 IIS Certificate Wizard
Figure 4 IIS Certificate Wizard

      Once a certificate is installed, you can assign a CTL to it by accessing the IIS Directory Security property sheet for the site and choosing the Edit button to edit an existing certificate. This runs the CTL wizard.
      The Permission Wizard works on a scenario basis, and sets permissions for the virtual directory or the Web site based on whether the site is publicly accessible or it is a secure site accessible only by folks with a Windows 2000 user account. You can run this wizard by clicking on the Web or virtual directory you want to set permissions for, selecting the All Tasks option from the Action menu, then selecting the Permission Wizard from the list that opens.
      For the public site, everyone is given read access and administrators have complete control; these permissions can be further refined to override existing permissions or can be used in conjunction with existing file and folder permissions. The secure site has the same options, with the understanding that an anonymous user can't access the pagesâ€"only people with valid Windows 2000 user accounts can access it.
      You might want to use the Permission Wizard to set up your Web sites. Just make sure your NTFS permissions and those set by the wizard are compatible with each other, and always choose NTFS permissions over those provided by the wizard. Remember, you have more control with NTFS.
      If your ASP applications require authenticated access, you have a new authentication protocol that you can use in IIS 5.0. This protocol, Digest authentication, creates a hash of the user's login information before transmitting it over the wire. Since a hash is used, decryption methods don't work on the data transmitted, and the information should be secure. A limitation with this approach, though, is that it only works with Microsoft Internet Explorer 5.x and higher. However, it is a feasible approach to use for Internet pages accessed only by company personnel and clients who are guaranteed to be using the correct browser.
      Other security changes in the IIS 5.0 and Windows 2000 environments can also affect your ASP applications in an unexpected manner. In Windows NT, if you initiated a COM process from your ASP pages (through the use of ASP components), the process would run as SYSTEM if the component is an in-process component or as IWAM_machinename if the component is defined as an out-of-process component. Because of this, in Windows NT the components have greater access to the machine and its resources than the Web page user might have.
      In Windows 2000, both in-process and out-of-process components run within the security context of the user who is accessing the ASP application through a process known as cloaking. Because of this, if you access an ASP page that instantiates a component that performs certain operations such as accessing a file or a system resource and you're accessing the ASP page as the anonymous user, you might find that the component process is prohibited due to security restrictions.
      This is a much more secure process than existed in Windows NT, but if you aren't aware of which ASP applications are using external processes and don't test your applications with a variety of users (each with different permissions), you might have unexpected results with your ASP applications once they're moved to the new production environment. The bottom line is that you must test your ASP applications thoroughly to make sure the new security features meet your expectations.
      Once your IIS 5.0 environment has been secured, it's time to copy your ASP application pages, script, images, and other material to your development environment. This includes any components used in the ASP application, and also includes migrating your MTS packages to COM+ applications.
      If you use third-party ASP components, you might want to hold off on porting the ASP applications that use them until the vendor provides versions of the components for Windows 2000 or verifies that the existing components will run without any problems in Windows 2000.

Migrate MTS Packages to COM+

      If you use ASP components and transactions within your existing ASP applications, then you've created MTS packages to group your components. In Windows 2000, MTS has been integrated into COM+ so component packaging is now handled through Component Services, and MTS packages have been replaced by COM+ applications. However, you can easily migrate your MTS packages to COM+ applications using one of two techniques, depending on whether you've chosen to upgrade or do a new install of the operating system.
      If you upgrade, your MTS packages are upgraded to COM+ applications automatically via the installer utility MTSTOCOM. Any errors in the conversion process are reported during the installation, and the results of this automated conversion are written to a file, Mtstocom.log, created in the Windows directory.
      If you've done a new install of Windows 2000, you can export your MTS packages into MTS Package Files (with a .pak extension) to move to the new environment. Then create a new COM+ application for each MTS package by following these steps:
  1. Open Component Services from Administrative Tools.
  2. Expand the directory tree, and then right-click on COM+ Applications.
  3. From the context menu, choose the New Application option, which starts the COM Application Install Wizard.
  4. When asked by the wizard whether the application is new or prebuilt, select the prebuilt option.
  5. When asked to choose an application object, select your MTS package. You might have to change the file type to MTS Package Files (*.pak) to find it, as shown in Figure 5.
Figure 5 Component Services
Figure 5 Component Services
  1. Repeat steps 2 through 5 for each package.
      During the import, a new COM+ application is created and any MTS package components and roles are added to the app. In addition, Component Services also creates any users (and permissions) associated with the roles if the users are exported in the MTS package and you choose to import them.
      MTS components in the packages are migrated to the new COM Services environment with all of the behavior that the component possessed within Windows NT. If the component supported transactions originally, it still supports transactions in the new environment. If the component participated in just-in-time (JIT) activation in Windows NT, it continues to participate in JIT activation in Windows 2000. However, your component won't automatically be updated to use new COM+ options such as object pooling and queuing. The reason for this is discussed in the next section.

Changes to ASP Components in Windows 2000

      If there is one ASP application area where you would expect to see an impact based on differences between Windows NT 4.0 and Windows 2000 it is within your ASP components. After all, most ASP components are also MTS components, and MTS has been integrated into COM+ in the new environment. In addition, there are significant changes in how components are managed in COM+, such as object pooling, queuing, and other new options. Considering all the differences, you might be surprised at the ease of migrating your components to Windows 2000. To demonstrate, I'll take a look at migrating components created using Visual Basic® 6.0 and Visual C++® 6.0. First, though, I'll have to set up the development environment within Windows 2000.
      The first step in setting up the development machine is to install Visual Studio 6.0, as well as the Visual Studio Service Pack 3. Once Visual Studio is installed, open Visual C++, and then close the applicationâ€"you'll see the reason in a moment.
      If you're developing ASP components using Visual Studio, and particularly if you're using Visual C++, you're also going to want to install the January 2000 (or later) edition of the Platform SDK. You can access the Platform SDK from the MSDN Online SDK area (http://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/msdn-files/028/000/123/topic.xml); if you have a Universal or Professional MSDN subscription, you'll find it on the CDs.
      When you install the Platform SDK, you can select which components you want in your own environment. At a minimum you'll want to select the Configuration Options, which includes Integrate with Visual C++, and the Build Environment option (see Figure 6). If you have room, I strongly recommend installing the documentation as well. Selecting the Build option installs the libraries and header files for working with COM+, and the integration option actually integrates these into Visual C++ by adding the Platform SDK libraries and header files as the first entries in the include and source file directories.
Figure 6 Configuration Options
Figure 6 Configuration Options

      An interesting thing happens when you select the Integrate with Microsoft Visual C++ option. Visual C++ has to be opened first for this process to happen correctly. If you don't open it first, the directories are added after all other directories installed with Visual Studio, rather than first in the list. You'll then have to manually adjust the listing location to move the directories to the first positions in the include and library paths. As you'll see a little later, the Platform SDK libraries and include files must be first in the list to work with Visual C++ in Windows 2000.
      Once the Platform SDK has been installed, you're all set to work with your existing and new ASP components. Now let's see what happens to your existing Visual Basic-based components once they are moved into Windows 2000.

Components from Visual Basic

      After copying one or more of your Visual Basic component projects to the new operating system, open any project that previously used the MTS type library (mts.dll). Checking the references for the project, you're going to find that the reference to the MTS type library no longer appears. Instead, the COM+ Services Type Library, comsvcs.dll, is now listed, as shown in Figure 7. How did this happen? Through the magic of COM, of course.
Figure 7 References
Figure 7 References

      When Microsoft created the new COM Services component, it provided all of the existing functionality of MTS, and more. To make sure that this new functionality was automatically accessible to components moving to Windows 2000, Microsoft gave the COM Services component the exact same CLSID that was used by the older MTS component.
      Your existing Visual Basic-based component accessed the MTS functionality externally through the type library description, but internally by its CLSID. In Windows 2000, your Visual Basic-based ASP component accesses that same functionality, but through the new COM Services component.
      As a test of how well your component has moved to the new environment, compile it without any changes and you'll find that the component not only compiles without a problem, it should work the same when accessed by any of your existing ASP pages in Windows 2000â€"depending on what the component is doing and what external processing it is accessing, of course. For instance, a component that implements ObjectControl to take advantage of JIT activation and then uses the built-in ASP Response object to write a message out to the client can have code similar to the example shown in Figure 8.
      Registering a component in Component Services and accessing it from an ASP page in IIS 5.0 results in the same behavior that would occur if the component was registered in MTS and accessed in Windows NT 4.0. More specifically, the ASP page calls the testResponse method, which triggers JIT activation to invoke the ObjectControl Activate method, which in turn creates the Response object used to output the "Hello World" message.
      One difference between the two environments in accessing the component is that a component is deactivated earlier in Windows 2000. In Windows NT 4.0, the components are released when the page goes out of scope; in Windows 2000, the components are released as soon as the last reference is released on the component. So as soon as you set the component instance to Nothing in your ASP page (if you're using VBScript), the Visual Basic-based component is deactivated.
      Of course, this isn't the only behavior within ASP components that can differ between Windows NT 4.0 and Windows 2000. If your component is accessing Windows NT-specific services or performing other operations such as input/output that might differ in implementation between Windows NT 4.0 and Windows 2000, you'll need to modify the component code for the new environment. However, if your ASP components are primarily used to access a database using something such as ActiveX® Data Objects (ADO), you'll find that the component should migrate to Windows 2000 with minimal effort.
      There is a difference in developing components in Windows 2000 that you should know about. In Windows NT 4.0, when working on a component that was registered in MTS in Visual Basic (or Visual C++), you had to refresh the component every time you recompiled it. The reason was that Visual Basic (and Visual C++) automatically registered any COM project when the component DLL was generated. However, the registration entry that Visual Basic made conflicted with the one that MTS created for the component when it's registered within an MTS package. By refreshing the component in MTS after you recompile it, you gave MTS a chance to fix the registry entry for the component.
      Within Windows 2000, there is no separation between COM+ and MTS, and the registration made by Visual Basic (or by running REGSVR32.EXE) is the one that COM+ supports when the component is accessed. The refresh operation is still available in COM Services for backward compatibility, but you don't need to use it when you are recompiling your component.
      Speaking of registration, you don't have to recompile your components or add them to COM+ applications to use them within ASP pages. You can continue to use REGSVR32.EXE to register the components. The only difference between using REGSVR32.EXE and adding the component to a COM+ application is that the latter is considered a configured component, while the former is considered an unconfigured component. However, as long as the component doesn't use transactions or JIT activation, it will still work regardless of how it is registered.

Visual C++ Components in Windows 2000

      If you use Visual C++ to create your ASP components, the Platform SDK installation should add the SDK libraries and header files to your build environment, as shown in Figure 9. As with the Visual Basic environment, you should be able to recompile your ASP components in Visual C++ with little or no intervention. This includes any ASP or MTS components you created using the ATL component wizards.
Figure 9 Configured Build Environment
Figure 9 Configured Build Environment

      When creating a new ASP component, the Visual C++ 6.0 ATL wizard used the ScriptingContext object, along with the OnStartPage and OnEndPage event handlers, to instantiate the ScriptingContext object, create instances of the ASP built-in objects, and to perform any cleanup. These components will work within the Windows 2000 and IIS 5.0 environment, as Microsoft is maintaining a reference to the ScriptingContext object within IIS 5.0 for backward compatibility.
      Although ScriptingContext still exists, don't use it with any new development. Instead, create your ASP components using other ATL Object Wizard options or by creating the component class directly. You should also seriously consider removing references to the ScriptingContext object before you move your ASP components to Windows 2000â€"the object is supported now, but this support is not going to last forever.
      The ATL Object Wizard adds the MTS library to the project, and adds the MTS header file when creating the MTS component. For instance, the following line is automatically added to your component's header file:



#include <mtx.h>
MTS doesn't exist within the Windows 2000 environment. It has been replaced by COM+. Also, the MTS library is no longer supported; it has been replaced by the COM Services library. So, how can MTS components successfully compile or work?
      The answer is apparent when you open the mtx.h header file that comes with the Platform SDK:


  //  Copyright (C) 1995-1999 Microsoft 
  //  Corporation.  All rights reserved.
  #define __MTxSpm_LIBRARY_DEFINED__
  #include "comsvcs.h"
The mtx.h file included in the new Platform SDK is nothing more than a wrapper for the new COM Services header file. Checking the external dependencies for a project built with Visual C++, you'll find that comsvcs.h, rather than mtx.h, is included in this list. This file is one of the reasons why it is essential that the Platform SDK library and include files are placed before those installed with Visual Studioâ€"to ensure that you pick up the correct version of the header files used in your components, such as mtx.h.
      You can actually change the include file directly in your component using the following, instead of using a reference to mtx.h:


#include <comsvcs.h>
However, this doesn't really affect the end resultâ€"an ASP component that can be registered in a COM+ application and accessed from ASP pages in Windows 2000.
      As stated earlier, your migrated components have the same component services in Windows 2000 that they had in Windows NT 4.0. However, there are new services available with COM+ that you won't necessarily be able to use without more serious consideration and more extensive modification of the ASP components.

Object Pooling

      One new COM+ feature you'll be interested in is object pooling, which allows components to be created within a pool of reusable objects, decreasing the amount of time necessary to instantiate the objects. Object pooling was not implemented in Windows NT 4.0; it's new in Windows 2000. You might be tempted to add the object pooling option (see Figure 10) when you add your existing Visual Basic and Visual C++-based components to COM+ applications through Component Services. However, you will find that none of your Visual Basic-based components can be pooled, and it is unlikely that any of your Visual C++-based components can be.
Figure 10 Object Pooling
Figure 10 Object Pooling

      Visual Basic components can't be pooled because they're apartment threaded, and a requirement of object pooling is that the component be able to run in either the neutral-threaded or the multithreaded apartment (MTA).
      Components built with Visual C++ can be marked both-threaded, meaning they run within the MTA, so they meet the threading requirement of object pooling. However, if the components were created as MTS components, they won't support object pooling. Object pooling requires that the component supports aggregation, but MTS required that the component not support aggregation. In fact, when creating the MTS component using ATL, a macro that prevents the component from being aggregated is added to the component's header file:



DECLARE_NOT_AGGREGATABLE(CComponent)
      An additional requirement of object pooling is that any resources allocated within the component must be handled by the component (and that the component doesn't maintain client state), which means additional work to make sure the component is poolable as defined by Windows 2000. So you're going to have to do some work before you can use object pooling with your MTS components in Visual C++, and you're not going to be able to use object pooling with your Visual Basic-based components at all, at least for now.
      However, your components still have access to the functionality they had in Windows NT 4.0, and that's really what you care about when migrating them and their associated ASP applications to Windows 2000.
      Once you've set up your ASP development environment and migrated your ASP components and MTS packages, it's time to unit test the applications. Now let's take a closer look at what has changed in ASP itself in Windows 2000.

Differences in the ASP Object Model

      The ASP object model is different in IIS 5.0, with the addition of new methods as well as changed behavior for some existing methods and properties. One of the most significant changes is that buffering is now enabled by default for an ASP application, where previously buffering was disabled by default. With this change, all ASP script in the page is processed before any page contents are returned. Default buffering could impact your existing ASP applications that perform longer database queries or other time-consuming operations.
      For example, I created a simple little ASP page containing a loop that is executed two million times, with code setting a single variable to zero within the loop. The code is nonsensical, but its purpose is to generate a process within the ASP page that takes enough time to be humanly noticeable. I then added a Response.Write statement before and after the loop:


<HTML>
<HEAD>
<BODY>
<%
Response.Write "<h3>About to perform long loop</h3>"

Dim i, j
For i = 1 To 2000000
   j = 0
Next
Response.Write "<h3>Long loop is finished</h3>"
%>
</BODY>
</HTML>
      I temporarily turned off the buffering for the ASP application that contains this page. You can disable buffering for an entire application by accessing the Configuration properties for the application and unchecking the Enable Buffering option in the App Options property sheet. You can access the Configuration properties by clicking the button labeled Configuration in the Virtual Directory property sheet for a virtual directory or in the Home Directory property sheet for a Web site.
      The first header is written out and returned to the client before the loop finishes. The second header is then printed out after the loop is finished (this takes a few seconds). However, when I turn buffering back on, as shown in Figure 11, no content is displayed in the page until all of the processing is finished.
Figure 11 Enable Buffering
Figure 11 Enable Buffering

      If your ASP applications have longer database queries or other processes, and you have been using output to tell the client that processing is occurring, you might want to turn buffering off for the affected ASP application. Or you might want to modify your affected ASP pages and turn buffering off through the Response object, or flush the buffer before executing any long process.
      If you have ASP applications that have been working with buffered content, you don't have to change the code before migrating the application. The redundant setting of the buffering property doesn't impact the application, other than the time it takes to process the script:



<% Response.Buffer = True %>
      Another change that should have little impact when migrating your existing ASP applications is that the IsConnected property now responds correctly regardless of whether the ASP page is returning content. Previously, this property would not work correctly if the ASP page didn't return content. Chances are, though, if you've used this property in your existing application, you've already coded around the property's previous limitationsâ€"and the existing code should work just fine in IIS 5.0, as it did in IIS 4.0.
      There are new methods with ASP in IIS 5.0, such as the new Server Execute and Transfer methods, the Remove and RemoveAll methods for the Contents collections of the Session and Application objects, and a new object called ASPError. As interesting as these new features are, they have little impact on migrating your ASP applications to Windows 2000. But once you have successfully migrated your applications, do check out these enhancements, in particular the Server Transfer method. This method will transfer the client to a new ASP page without having to return to the browser. It also transfers all existing request object information, as well as any pending transactions. This is one of the more exciting enhancements provided by the new ASP object model in IIS.
      After you've unit tested your ASP applications and made any modifications required to ensure they work correctly and as originally planned, you can then move the applications to test for compatibility and to do stress testing.
      After they've run the gauntlet in the test environment, the next and final step is to move the ASP applications to their new permanent home in the production environment. Hopefully, you shouldn't need any additional modifications to the ASP applications themselves at this time, and your migration effort will be complete. Enable CPU tracking on each newly migrated ASP application to ensure the application doesn't take more than its fair share of the CPU. If necessary, apply CPU and bandwidth throttling on the newly migrated ASP application.
      All that's left to do is monitor your ported applications as you do now in Windows NT 4.0. You can use the monitoring features of Windows 2000, such as CPU tracking. Now congratulate yourself on a job well done!

Conclusion

      In this article, I've provided a multi-step process you can use to create a plan for migrating your existing ASP applications to Windows 2000. Additionally, I hope I've provided enough detail about this planâ€"setting up IIS 5.0, Web security, creating the ASP development environment for both Visual Basic and Visual C++-based component development, migrating your MTS packages to COM+ applications, and handling ASP differencesâ€"to give you a clear idea of what you're facing with each migration step.
      You're going to find that migrating your ASP applications to Window 2000 doesn't have to be an overwhelming task, and that you can take advantage of some of the Windows 2000 functionality with little or no effort, and with little or no impact to your existing applications.

For related articles see:
http://msdn.microsoft.com/workshop/server/asp/server02282000.asp
http://www.microsoft.com/mind/0499/iis5/iis5.htm
For background information see:
http://www.microsoft.com/msj/0599/complusprog/complusprog.htm
http://www.microsoft.com/msj/0999/com/com0999.htm
http://msdn.microsoft.com/msdnmag/issues/0300/com/com.asp
http://msdn.microsoft.com/msdnmag/issues/0300/basics/basics.asp
http://msdn.microsoft.com/downloads/default.asp?URL=/code/topic.asp?URL=/msdn-files/028/000/123/topic.xml
Shelley Powers, otherwise known as YASD (http://www.yasd.com), is an independent consultant in Boston, Massachusetts, and author of Developing ASP Components (O'Reilly & Associates, 1999). She can be reached at shelleyp@yasd.com.

From the August 2000 issue of MSDN Magazine.

Page view tracker