Migrating Your ASP Apps from Windows NT 4.0 to Windows 2000

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.
    

Installation and Configuration

New Properties in IIS 5.0 and ADSI

Figure 1IIS 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 2Log 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

Figure 4IIS 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+

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 5Component Services

6. Repeat steps 2 through 5 for each package.
   

Changes to ASP Components in Windows 2000

Figure 6Configuration 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

Figure 7References

      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

Figure 9Configured 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:

      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