Planning a Web Server Migration Project

By Megan Davis, IIS Documentation Team

This article is the second in a series about the steps you can begin taking now to get ready for Internet Information Services (IIS) 5.0 when it becomes available later this year. If you're going to migrate enterprise Web services to IIS 5.0, this article will help you to plan the project. It assumes that you'll be migrating from a different type of Web server, such as Apache HTTP Server or Netscape Enterprise Server; however, if you're simply upgrading to the latest version of IIS, much of this information might be helpful to you as well.

On This Page

Completing the Tasks of the Envisioning Phase
Entering the Planning Phase
Writing the Functional Specification
Testing a Solution Prototype
Assessing Resource Needs
Building the Master Project Plan
Drafting the Project Schedule
Checking Your Assumptions
More Web Server Migration Resources


The TechNet article, Understanding the Migration Process, gives you an overview of the steps involved in an enterprise Web server migration project, from creating a vision statement that defines the desired outcome of the project, to troubleshooting any problems that arise following deployment. In this article, I take a topical approach to migration project planning. And to help you get started with your own planning, I provide a number of forms and checklists, as well as sample documents and templates that you can download from this Web site and use. While I hope to cover the most salient aspects of migration planning, it is outside the scope of this article to provide a comprehensive discussion of project planning. If you need more information on this subject, the Microsoft Solutions Framework Web site would be a good place to start.

I am devoting an entire article to planning because it is perhaps the most important phase in any project that affects enterprise computer systems. Without sufficient planning, you're more likely to overlook important steps or fail to prevent situations that you would have foreseen during the planning process. As a result, vital systems can become unavailable and day-to-day business operations can be disrupted and revenues lost. With careful planning, however, the new system can meet or even exceed your expectations with minimal disruptions, and greatly enhance your business.

Many people put off planning until the last minute. But keep in mind that the earlier you start, the more thorough and solid can be your plans, which can save both time and money in the long run. It's best to get started as soon as possible.

Completing the Tasks of the Envisioning Phase

As discussed in last month's article, "Understanding the Migration Process," the Envisioning phase is the first step in the migration process. This is when the project team defines the desired outcome for the project in the form of a vision statement and requirements definition, and identifies its scope in terms of time and resource constraints. Before starting the formal process of project planning, you need to complete the activities of this phase, culminating in the creation of a Vision and Scope document. To help you write a Vision and Scope document, you can use the "Vision and Scope Template” available to download from this Web site.

Last month's article provided an outline of the information to include in your document. The following are some examples of how you might address these topics.

Vision Statement

Your team should have a clearly defined vision statement, such as the following statement for a fictitious company, Contoso Pharmaceuticals:

Contoso Pharmaceuticals will replace its current UNIX Apache Web server environment with Microsoft Windows 2000 Server and IIS 5.0, a more efficient and flexible solution that will maximize competitiveness in our industry while reducing operational and administrative costs. The company will implement a global Windows 2000 Server domain model and will begin a scheduled deployment program by the third quarter of 1999. It will start an enterprise-wide rollout within three months and will be user-complete within 18 months, or the first quarter of 2001.

Implementation will require a conversion and coexistence infrastructure in order to seamlessly egrate the new platform. To accomplish this, the company will use Windows 2000 Server integration tools and third-party UNIX conversion tools.

Project Requirements

The project team should clearly define project requirements in the Vision and Scope document, prior to beginning formal planning. The following table lists some typical requirements for a Web services migration project.

Migration Project Requirements and Deliverables



Improve information sharing

Integrate the corporate intranet with Microsoft tools and technologies. IIS 5.0 fully integrates with other Microsoft business products, such as Microsoft® Word, Microsoft® Excel, and Microsoft® SQL Server. In addition, IIS 5.0 is fully ODBC- and OLE DB–compliant and can connect to more than 55 different databases. Use this built-in functionality to access, link, or exchange data with these products without the need for additional software.

Provide advanced online business services

Use IIS 5.0 in combination with other Microsoft products, such as Microsoft® Site Server, to conduct transaction-based services, central management, content indexing, and many other advanced services. You're ensured all system components have been designed, tested, and optimized to interoperate. For large Commercial Solution Providers, Microsoft® Commercial Internet System (MCIS) provides a fully integrated solution.

Increase security

Use IIS 5.0 security, which integrates Windows 2000 Server security policies and user databases to reduce the number of security holes created by Web servers running on top of nonintegrated or incompatible security systems.

Reduce system support costs

Reduce support costs and risks associated with use of noncommercial software. IIS 5.0 provides enhanced local and remote Web administration at a significantly lower cost than comparable UNIX solutions. Also, take advantage of the lower average cost of hardware for Windows-based systems.

Reduce application development costs

Use ASP technology, with its many features that make application development quick and easy, including IIS 5.0 built-in script debugging.

Improve application and server performance

Take advantage of the efficient performance of ASP-based applications and Internet Server Application Programming Interface (ISAPI) extensions. You'll notice improved server performance because IIS 5.0 can run scripts in ASP pages and ISAPI extensions in the same memory space as the server, or can group them in a single process. This allows for more efficient use of resources than is possible on most other Web servers.

Project Risks

The team should perform a high-level risk assessment and develop some mitigation strategies to include in project plans. Following are some typical risks. Your team might come up with a different list, depending on your situation.

Project Risks and Mitigation Strategies


Mitigation Strategy

Service downtime

Upgrade or migrate to a different physical server, make sure servers pass all tests prior to full deployment, and test and debug all applications prior to full deployment.

Applications not functioning correctly after migration

Make sure skilled resources are available to perform migration work, especially for mission-critical applications. Also, test and debug all applications on a computer running Windows 2000 Server and IIS 5.0. Prior to deployment, perform stress testing that simulates the actual usage of the applications in order to uncover any performance problems.

Project not completed on schedule

During the planning process, be generous with estimates of time necessary for the expected work, and then allocate backup resources in the event that a task takes longer than anticipated. A 20 to 30 percent buffer is recommended.

Expenditures exceed budget

Estimate costs liberally, and allow for unexpected expenses; for example, hardware might malfunction and need to be replaced or software might need to be upgraded. Adding 20 to 30 percent to your base cost estimate will give you a reasonable cushion.

Applications or tools don't run on Windows 2000 Server or IIS 5.0

Make a careful inventory of applications and tools currently in use and, prior to system implementation, replace any that are incompatible. For more information about this inventory, see "Tools and Utilities in Use" later in this article.

Resistance to change by system users

Try to give individuals who will be using the new system a sense of ownership by involving them in its development. For example, provide information about the project in advance, and request input during the planning process. Give regular progress reports, and make sure users receive adequate training and support on the new technologies.

A Risk Assessment Form, which you can use for evaluating risks for your project, is available to download from this Web site.

Entering the Planning Phase

Once you and your team are satisfied with the Vision and Scope document, you're ready to move into the Planning phase. The first step is to define team roles for this phase. Then you begin gathering information that will be incorporated into the functional specification, project plan, and project schedule.

Define Team Roles

During the Envisioning phase, Product Management had a focal role. Now in the Planning phase, team focus shifts to Program Management, where it will remain throughout the Developing phase, as well. The following table shows team roles and responsibilities:

Team Roles during the Planning Phase



Product Management

Conceptual design, business and user needs analysis, budget

Program Management

Functional specification, project plan and schedule


Technology evaluation, physical design, development plan and schedule


Design evaluation, test plan and schedule

User Education

User education, communications, usability test plan, and schedule


Design evaluation, technical education plan and schedule, as well as logistics plan and schedule

Gather Information

In developing a plan for new services, it's important to have a complete picture of the current environment for Web services, both in terms of the technical resources in use, their locations, and the users that draw upon them. This will help you decide how to make the best use of resources and minimize disruption of important services.

Server and Network Environment

Drawing from a survey of your current Web servers, along with their functions, utilization level, and relationships with other servers on the network, you can determine which services to migrate to IIS 5.0 and how to integrate them in the service environment. In addition, a network environment survey can help you characterize the current network and its resources. It will tell you, for example, the names and locations of Web servers, proxies, and gateways, numbers of local and remote users, and access points. Sample forms you can use for conducting this survey, "Organization Environment Survey" and "Technical Environment Survey," are available to download from this Web site.

Tools and Utilities in Use

You'll also need to develop a list of the tools and utilities currently in use and, with the vendor or creator, verify their compatibility with Windows 2000 Server and IIS 5.0. These tools might include administrative, programming, Web publishing, and client-side applications, such as Internet browsers.

Some of these tools may no longer be required after a migration; for example, if you use Microsoft® FrontPage® Web site creation and management tools, you can eliminate many other publishing tools, even if you're running other Web servers in addition to IIS 5.0. To use all the features of FrontPage, you also need to install the appropriate Microsoft® FrontPage® Server Extensions, which are available for most popular Web servers, including those servers running on UNIX. For more information about FrontPage Server Extensions, see

Chances are that users will want to continue using at least some of their existing tools. If you're migrating from a UNIX-based server, this could mean obtaining the Windows 2000 Server counterparts to UNIX tools. For more information about acquiring these, see "More Web Server Migration Resources" at the end of this article.

You can use a checklist to help generate a list of the Windows versions of UNIX tools and utilities that you'll need to obtain when migrating from a UNIX-based Web server to IIS 5.0. Some are available from third-party sources and from public FTP sites. You will need to port or rewrite any custom tools. Here are some items that may be on your list:

  • For migrating from Netscape or Apache, the IIS Migration Wizard, included on the Microsoft Windows 2000 Resource Kit, IIS Resource Guide companion CD (the Resource Kit will be available through Microsoft Press later this year)

  • Web content migration tools, such as FrontPage

  • UNIX-to-MS-DOS-based file copy and conversion tools, such as Mtool

  • Test scripts

  • Test tools, such as Web Capacity Analysis Tool (WCAT), the Web Application Stress Tool, and the IIS 5.0 debugger

  • Shell scripts used by applications during development or execution

  • Counterparts to UNIX daemons as well as other utilities that perform application functions

  • Script interpreters, such as Perl, REXX, and TCL

In addition, you will need to generate a list of application programming tools in use, such as NSAPI, CGI, Perl, C++, and Java. Next, decide if you would like to continue supporting them, or if it makes more sense to migrate to Internet Server Application Programming Interface (ISAPI) or Active Server Pages (ASP) technologies, as described in my previous TechNet article, Migrating Applications to IIS: Choosing an Approach. To help you create this list, you can use the "Tools " available to download from this Web site.

System Users

The information about system users that you gathered for the Vision and Scope document will be important in your project planning. It's also helpful to make a diagram that depicts all system users, their locations, and the services they access. If your system serves a business or nonprofit group, you might find it useful to have both an organizational chart and an information flowchart to characterize where and how users currently access Web services. If you offer services as an Internet service provider (ISP), you need information about Web developers and general users accessing your system. To this diagram, you can add any additional capabilities that will result from the migration to IIS 5.0 as well as indicate any changes to these services. The following figure shows the information flow as external and internal users access the services and facilities of a commercial ISP.


System Users of an ISP


Another area to assess is system operations standards, which usually take the form of policies and procedures. You might want to review and update your existing standards with reference to IIS 5.0. To help conduct a standards review, you can use the "Standards Review " available to download from this Web site.

Here are some issues to consider when reviewing standards and policies:

Standards Review



Content Publishing

General guidelines on issues such as consistency in page formatting and style.
Instructions on how to publish a Web page served by IIS 5.0, and directory access policies for Web Distributed Authoring and Versioning (WebDAV).

Disaster Recovery

Recovery plans.
Off-site or on-site spare server location.
Spare server availability.
Rehearsal provisions.

Internet Services

The person to contact for each service.
Access control.


Preventative maintenance procedures.
System monitoring policy and tools.


Guidelines for appropriate network and e-mail use.


Escalation procedures for downed links.
Contacts for network services.

Redundant Servers

Fault-tolerant servers.
Load-balancing servers.


Password length and expiration period.
Logon policies and auditing.
Intruder prevention processes.
Ownership/responsibility for user accounts.
Methods for key encryption.

Writing the Functional Specification

After gathering the necessary information about the network, tools in use, system users, and standards, you can define the new service offering in more detail. This involves translating the requirements of the migration and conceptual design into a functional specification.

The functional specification provides a detailed description of the IIS 5.0 solution. The team describes all system functionality at a high level and then works out details during the design process to complete the document. The immediate goal is to give the functional specification enough detail for the project team members to begin laying out project plans for their individual portions of the work. To help you begin this process, you can use the "Functional Specification Template" available to download from this Web site.

In addition to basic IIS 5.0 functionality, the solution you define might use related products that provide advanced services, such as SQL Server and Site Server. Fortunately, Microsoft applications were built to work together, making it easy to implement solutions. For example, you can use FrontPage wizards to insert a data call in a Web page so it interacts with SQL Server and an existing database.

You might plan to migrate to IIS 5.0 because of a specific requirement supported by a particular capability it provides. However, the Planning phase is also an ideal time to assess any additional features of IIS 5.0 that could enhance your existing services. Rather than exactly replicating your current services, and substituting IIS 5.0 features in place of existing ones, you might want to consider adding new capabilities. In addition, you may need to consider retiring gopher services, which aren't supported by IIS 5.0, or making provisions to continue providing them through another server. The table "Project Requirements and Deliverables" earlier in this article included some examples of the deliverables that an IIS 5.0 migration project could encompass.

To compare IIS 5.0 features with those of other Web servers, follow the links to the Web server comparison page from the Windows 2000 Server Web site, located at

Develop an Interoperation Strategy

For various reasons, you might decide to make the transition to IIS 5.0 in phases, migrating only one Web server or group of servers at a time. This process can result in a mixture of platforms and Web servers operating on the same network for a period of time. If your planned server environment will be mixed, you need to develop a strategy that allows the different servers to interoperate, or coexist, on your network; the servers must also work in concert to provide Web services. You must decide upon an effective approach to integrate the different components of the IIS 5.0 solution into your existing service environment, which is the combination of physical servers, network connections, software, and services or functions.

This strategy can be incorporated in an interoperation plan. Depending on your particular environment and needs, your plan might address the following issues:

  • Enabling file sharing between UNIX- and Windows-based platforms

  • Establishing common methods and policies for administering multiple Web server technologies

  • Implementing common security methods and password synchronization

This chapter provides references to helpful information in these areas. In addition, Microsoft as well as third-party vendors offer a variety of tools and solutions for implementing a mixed server environment. For more information about tools, and for URLs to interoperation resources, see "More Web Server Migration Resources" at the end of this article.

Create the Detailed Design

Another key component of the functional specification is a detailed solution design. For the detailed design, you apply real-world technology constraints to the conceptual model, including implementation and performance considerations. This is a good time to reevaluate and refine your preliminary resource, cost, and schedule estimates.

The detailed design should include interfaces to the existing system, as well as provisions for meeting projected future needs in terms of physical servers and network bandwidth. Future capacity requirements can be affected by growth in overall system usage as well as by user demand for increasingly rich content. For developing the detailed design, you can use the "Design " available to download from this Web site.

Testing a Solution Prototype

At this point it's wise to perform proof-of-concept testing, in order to validate the technical features of your proposed solution. You don't need to test the complete solution, but you should set up a prototype of the production environment to demonstrate that your design can achieve the required capabilities of the system. Prototyping allows predevelopment testing from many perspectives, especially usability, and helps create a better understanding of user interaction. It will also improve the functional specification.

Assessing Resource Needs

Another important step during the planning phase is to identify the material and staff resources needed for the project. You must consider any software and hardware that you need to purchase, and whether you want to train current employees or hire consultants to fill gaps in expertise. From this assessment you can develop a resource plan, cost estimate, and budget. There are several areas to consider when assessing resource needs, such as staff, tools, software, and hardware.

Skilled Staff

To implement a migration to IIS 5.0, the project staff needs to have the following skills:

  • Knowledge of Windows 2000 Server networking and administration, including domain design, Web services, and security setup.

  • Understanding of general internetworking concepts and TCP/IP technologies.

  • Familiarity with Microsoft Internet technologies, including ASP.

  • For migrations involving interoperation between UNIX and Windows 2000 Server, a firm grasp of the relevant concepts, and awareness of the available tools.

  • For migrations from UNIX Web services, application developers should have the ability to port applications and utilities from UNIX to Windows 2000 Server.

These skills could already exist within your company, or you might decide to hire a consulting firm to round out your capabilities or even to handle the entire migration effort. If your project is small, you might find all the talent you need in one or two experienced members of your staff.

Migration Tools

Migration tools are an important resource for expediting migration tasks. Listed here are a few you might want to have on hand.

IIS Migration Wizard

The IIS Migration Wizard migrates server configuration settings to IIS 5.0 from Netscape Enterprise Server, Apache HTTP Server, and IIS 4.0, and it replicates settings from one IIS 5.0 server to another. This IIS Migration Wizard is included on the Microsoft Windows 2000 Resource Kit, IIS Resource Guide companion CD, which will be available through Microsoft Press later this year.

Content Replication

For moving content to the new IIS 5.0 server from another Windows computer, you might want to use a replication tool such as Microsoft® Content Deployment, which is included with Site Server.

You might also consider acquiring FrontPage for migrating Web sites to IIS 5.0. By using the Microsoft® FrontPage Import Web Wizard, you can convert a Web site to a full-featured FrontPage web. When doing this, the wizard imports your pages, images, and files, while preserving the web's structure and hyperlinks. For more information about FrontPage, see

Cross-Platform Administration

Microsoft has developed a set of utilities for configuring and administering servers in an environment that encompasses both UNIX-based and Windows-based computers. You can find more information about these and other tools in "More Web Server Migration Resources" at the end of this article.

Other Tools

Other tools for converting CGI applications, debugging script, transferring data, testing, and more are listed in "More Web Server Migration Resources" at the end of this article.

Server Software

To migrate to IIS 5.0, the only server software you need is Windows 2000 Server, which includes integrated Web (HTTP), File Transfer Protocol (FTP), Internet mail, and local newsgroup (NNTP) services. For large installations, you might also want to consider obtaining Site Server or, for very large applications, Microsoft Commercial Internet System (MCIS). Information about these products is available at


The complexity of the migration and the number of servers involved dictates the hardware needed to create a development environment and test lab, as well as to deploy the new system. The following paragraphs discuss some considerations involved in planning hardware resources.

Development and Test Resources

A working development environment allows for proper development and testing of the solution so that it has no negative impact on production systems. You'll need to have sufficient development computers available for migrating and porting applications and for performing application-specific testing.

In addition, if your organization does not already have a suitable test lab in place, the team must build one. The test lab should contain servers that are representative of the new user environment. For example, if the new environment will be mixed, including computers running UNIX or Macintosh® operating systems along with computers running Windows 2000 Server, the test lab should reflect this.

The test lab consists of a unit lab and an integration lab. The unit lab is used for the initial preliminary evaluation and review of features, functions, and application software behavior. After applications are ported or developed, and then are evaluated on the development computer, they are then tested in the unit lab.

Once applications are tested and approved at the unit lab, they are staged in the integration lab, so that users and other assigned teams can begin the evaluation process.

The integration lab should be made available for other project teams and users at different times during deployment. This gives design and testing teams an opportunity to review and address any immediate problems or issues found, without taking much time away from their overall project responsibilities.

The unit and integration lab environments should be identical in order to support evaluation of cross-router and cross-bridge connectivity. Two routers can divide the labs to simulate a wide area network (WAN). This way, design and testing teams can reproduce production environments throughout the enterprise and eliminate potential problems during the testing process.

Depending on your user environment, each lab might be a pure Windows 2000 environment, or it might include both Windows 2000 and another network operating system. Desktop operating systems could include Microsoft® Windows® 95, Microsoft® Windows NT® 3.51 or Microsoft® Windows NT® 4.0, Windows 2000, Macintosh, and even some UNIX-based computers. Be sure to make each environment identical to the desktop configuration when Windows 2000 Server is deployed.

The following figure shows a unit and integration lab with a WAN link simulated by using two routers.


Example of a Test Lab Setup

Deployment Resources

It's a very good idea to set up a dedicated physical server for deployment, leaving your production Web server running until the new server is fully tested and debugged. This is especially true if you're migrating both your Web server and your operating system, such as when moving to Windows 2000 Server with IIS 5.0 from a UNIX computer running Apache; however, your job will be easier if you do this in all cases. This way you can set up users, groups, and permissions, and transfer all of your files, applications, and configuration settings without running the risk of losing your data in the event of a mishap. In addition, by doing this you can also thoroughly test the server and applications prior to deployment, which is highly recommended for mission-critical servers and applications.

Details on setting up a dedicated physical server for deployment will be provided in the third article of this series, "Basic Steps to Migrate a Web Server to IIS 5.0," which will be published by TechNet next month.

Building the Master Project Plan

The Master Project Plan, which is basically a blueprint to follow throughout the project, includes all of the detailed plans contributed by each functional area of the project: Product Management, Program Management, Development, Test, User Education, and Logistics. Developing this plan prompts the team to consider all of the resources that must be assembled in advance, and alerts the team to potential pitfalls to avoid. A good plan steers the migration process, helping keep staff on schedule and on task, and the project within budget.

For developing a test plan, you can refer to the "Sample Test Plan ," and for your project plan, you can use the "Project Plan," both available to download from this Web site.

Drafting the Project Schedule

Your project schedule should include all of the team project schedules, and should include the release date. The team determines the release date after reviewing the draft functional specification draft and the draft master project plan. It might be necessary for the team to modify the specifications and plans to meet a required release date. Although features, resources, and release date can vary, a fixed release date will help the team prioritize features, assess risks, and plan adequately. The key to project success is finding the right balance between resources, deployment date, and features.

You can use the "Sample Project Schedule," available to download from this Web site, to give you ideas about items to include in your own schedule.

Checking Your Assumptions

Before you begin putting your plans into action, develop a list of any assumptions, constraints, and dependencies on which the plans rely. Then check your assumptions to avoid costly delays later on. Examples of assumptions you'd want to verify are as follows:

  • A valid Windows 2000 Server network is in place.

  • The project team knows how to install and configure Windows 2000 Server and IIS 5.0.

  • Computer hardware meets the requirements listed at

  • Required Windows 2000 Server counterparts to UNIX software are available.

More Web Server Migration Resources

Migration Tools

IIS Migration Wizard

The IIS Migration Wizard migrates server configuration settings to IIS 5.0 from Netscape Enterprise Server, Apache HTTP Server, and IIS 4.0, and it replicates settings from one IIS 5.0 server to another. The wizard is included on the Microsoft Windows 2000 Resource Kit companion CD. The Resource Kit will be available through Microsoft Press later this year.

The MKS Toolkit provides Windows scripting and migration tools. This set of more than 210 UNIX and Windows utilities allows you to create scripts and use familiar UNIX commands on your PC. It also automates tasks like updating pages on a Web site, manipulating files and text, querying a database, and accessing and updating the Windows registry.

At this site you can obtain a tool called Ws_ftp that performs recursive FTP for Windows.

Books on Migration and Integration

Migrating to Windows NT by Steve Heath, 1997, Houston: Digital Press.

A handbook to ease the transition from another operating system to Windows NT. Discusses the user interface, accessories, networking abilities, and other aspects of Windows NT. Includes chapters dealing with transitioning from UNIX, Macintosh, MS-DOS, and Windows 3.x.

Windows NT & UNIX, Administration, Coexistence, Integration, & Migration by G. Robert Williams et al, 1998, Reading: Addison Wesley Longman, Inc.

(See my book review.) Topics covered include porting applications, TCP/IP, Common Object Request Broker (CORBA) and Distributed Component Object Model (DCOM) interoperability. Also discusses various e-mail systems, user interface emulators, Portable Operating System Interface UNIX (POSIX) commands and utilities, and clustering technologies. Includes a quick reference guide to common Windows NT and UNIX commands and utilities.

Windows NT, UNIX, NetWare Migration and Coexistence, A Professional's Guide by Raj Rajagopal, 1998, Perth: CRC Press LLC.

Identifies and classifies the solutions and products that support migration and coexistence between UNIX, Windows, and NetWare. It discusses porting applications as well as developing new applications by using cross-platform development techniques, and also provides guidelines for selecting a solution.

Windows NT & UNIX Integration Guide by David Gunter et al, 1997, Maidenhead: Osborne McGraw-Hill.

The CD-ROM contains freeware, shareware, and demonstrations of commercial products designed to assist Windows NT and UNIX integration efforts. It also contains a selection of FAQs for easy reference.

Planning and Testing Information

Software Project Survival Guide by Steve McConnell, 1998, Redmond: Microsoft Press. This book provides a complete set of guidelines for a successful development project.

This Web site provides helpful information and tools on software project planning, much of which is relevant to a migration project.

Software Testing in the Real World, Improving the Process by Edward Kit, 1995, New York: ACM Press.

This is a general guide to software testing with many useful appendices that include sample development, test plan outlines, and reports.

Software Verification and Validation, A Practitioner's Guide by Steven R. Rakitin, 1997, Norwood: Artech House, Inc.

This is a general guide to software testing that includes many useful references to additional resources, information about test tools, and sample verification exercises.

Test Tools

The following test tools will be included with Windows 2000 Server and IIS 5.0:

  • The IIS 5.0 debugger component, which is built into IIS 5.0, can be used for debugging applications.

  • The Component Object Model (COM) application debugger is a component of Windows 2000 Server.

The following test tools will be included on the Microsoft Windows 2000 Resource Kit companion CD. The Resource Kit will be available from Microsoft Press later this year:

  • Web Capacity Analysis Tool (WCAT), allows you to stress test the Web server by sending multiple client requests to simulate load on the servers.

  • The Web Application Stress Tool is designed to realistically simulate multiple browsers requesting pages from a Web application. It covers the features most needed for stress testing three-tier personalized Active Server Page Web sites running on Microsoft® Windows NT® Server 4.0 and Windows 2000 Server.

  • HTTP Monitoring Tool monitors HTTP activity on the server.

For more information about testing tools, see

General Server Administration Books and Training

Inside Windows NT, Second Edition by David A. Solomon, 1998, Redmond: Microsoft Press.

Essential Windows NT System Administration by AEleen Frisch, 1998, Sebastopol: O'Reilly & Associates, Inc.

This Web site provides information about training on the Microsoft Solutions Framework.

To find online training resources for Windows 2000 Server, select Windows 2000 Server as the product category.

Application Migration Tools

The Microsoft Platform Software Development Kit (SDK)—January 1998 Edition: Current and emerging Microsoft technologies including tools, headers, libraries, and sample code, as well as information about developing ISAPI extensions. This is the successor to the Win32 SDK, and includes components that have been distributed separately in the Microsoft® Win32 SDK, the Microsoft® BackOffice® SDK, the Microsoft® ActiveX/Internet Client SDK, and the Microsoft® DirectX SDK.

Information about Microsoft Windows script technologies, including JScript, VBScript, and Microsoft® Windows® Script Host (WSH).

ActiveState provides three Perl interpreters of interest to IIS developers: Perl for Win32, Perl for ISAPI, and PerlScript, an Active Scripting interpreter that runs PerlScript in ASP pages. In addition, it provides PerlEX, a plug-in you can use with IIS 5.0 that dramatically improves the performance of Perl CGI scripts and allows you to embed Perl code within HTML.

To Windows 2000 Server and IIS 5.0, Interix adds the ability to host complete Internet applications developed for UNIX systems. It provides full support for sendmail, Perl and TCL/TK, UNIX commands and shells, including rcommands, and remote access with telnetd and rlogind.

This Porting Guide by DataFocus Inc. describes how to use Nutcracker to migrate UNIX and X/Motif applications to Windows 2000, Windows NT, and Microsoft® Windows® 95 as native Win32 applications.

Mortice Kern Systems makes the MKS Toolkit, which provides many utilities, such as htdiff, htsplit, URL, and Web, to help you automate Web development and maintenance tasks. The Toolkit includes a version of Perl, as well as Pscript, an Active Scripting interpreter that allows you to use PerlScript code in an ASP page.

Provides Python language products for the Windows operating system.

Provides Tcl scripting language products for the Windows operating system.

Server Administration and Interoperation Tools

Windows NT Services for UNIX, a suite of interoperability tools and utilities for Windows NT Server and UNIX. At the time of this writing, a version of this tool suite is under development for Windows 2000.

This white paper lists Microsoft interoperation initiatives and partners.

NetManage, Inc. provides PC connectivity solutions, such as Chameleon UNIX Link 97, version 8.0, with significant enhancements to X Windows and NFS applications, extended browser access to UNIX, AS/400, and mainframe systems, as well as SupportNow technology. Chameleon UNIX Link 97 supports Windows 3.x, 9x, and Windows NT.

Offers a tool called Ws_ftp to perform recursive FTP for the Windows operating system.