Chapter 2 - Managing the Migration Process

Internet Information Services (IIS) 5.0 simplifies the setup and administration of Web services and provides many advantages over competing Web servers and previous versions of IIS. With IIS 5.0, Microsoft has emphasized a few key areas, notably security and manageability. New methods of publishing are implemented in this version, as well as updates and modifications to the Active Server Pages (ASP) model that help to improve application processing capacity and efficiency. These new and enhanced features give you compelling reasons to migrate or upgrade a Web server to IIS 5.0.

This is the first of two chapters about migrating to IIS 5.0. This chapter provides general, conceptual information about planning and managing the migration process when it involves multiple servers on an enterprise network. The next chapter, "Migrating a Web Server to IIS 5.0," provides specific "how-to" information about migrating an individual Web server.

This first section of this chapter gives an overview of the migration process, using the Microsoft® Solutions Framework (MSF) approach to deploying successful and cost­effective business solutions. It divides a Web server migration project into four phases: Envisioning, Planning, Developing, and Deploying. Subsequent sections provide details on key activities and milestones for each phase. The "Additional Resources" section provides references to more in-depth information about Web server migration and other useful tools. Forms and templates to use in planning a migration project are included on the Microsoft® Windows® 2000 Server Resource Kit companion CD.

On This Page

Migration Process Overview 1. Envisioning 2. Planning 3. Developing 4. Deploying Additional Resources

Migration Process Overview

The approach to migration used in this chapter is based on the Microsoft Solutions Framework (MSF) process model for Infrastructure Deployment, developed by Microsoft to assist customers in deploying business solutions. MSF is a flexible, interrelated series of models that can guide an organization through assembling the resources, people, and techniques needed to bring technology infrastructure in line with business objectives. You can use MSF together with your own tools and techniques to plan and manage a migration project. For more information about MSF, see https://www.microsoft.com/msf/.

The following graphic depicts the MSF process model, consisting of envisioning, planning, developing, and deploying, along with related milestones. The remainder of this chapter describes the migration process within the context of this model.

Figure 2.1 The MSF Process Model for Infrastructure Deployment

Table 2.1 describes how IIS 5.0 migration activities fit into the MSF process model, as depicted in the preceding figure. Although listed sequentially, many of the activities are performed concurrently, particularly within a phase.

Table 2.1 The MSF Process Model and Migration Activities

MSF Phase	Milestone	Migration Activity
1. Envisioning: defining the goals and limits of the project	Vision and Scope Document Approved	A. Define the project by identifying goals, scope, constraints, and assumptions. B. Create a requirements definition that describes what the new Web services must do. C. Develop a conceptual design for services. D. Assess high-level project risks. E. Define the structure of the project team.
2. Planning: writing the Functional Specification and Project Plan	Project Plan Approved	A. Gather information about current Web services. B. Define and design the new service offering in a functional specification. C. Assess resource needs to complete the project. D. Build a master project plan. E. Draft a project schedule.
3. Developing: developing, testing, and building out the system	Release	A. Validate the physical design by simulating the server environment and performing unit, integration, and application testing. B. Build out the system, configuring and locating the production Web servers that will be used on your network. C. Begin training administrators and key users. D. Conduct pilot testing and introduce the new services to a defined set of users on a small- and medium-scale basis.
4. Deploying: making the new services available to end users	Deployment Complete	A. Finish training administrators and all users. B. Roll out the new system, evaluate performance, and correct any problems. C. Monitor the system, and plan improvements and enhancements.

Every migration project varies in size, scope, and objectives. While this chapter provides an overview of the basic tasks involved, you may require additional assistance, especially when planning and managing a large-scale migration involving multiple geographic locations and numerous servers and users. If so, you might want to consider contacting a Microsoft Solution Provider or a Microsoft Consultant. For more information about obtaining this help, see https://www.microsoft.com/msf/.

For help with planning and deploying Microsoft® Windows® 2000 Server solutions, see https://www.microsoft.com/windows2000/default.asp.

1. Envisioning

During the Envisioning phase, the project team creates a Vision and Scope document to define the following:

• Project vision, scope (given the schedule and constraints), and assumptions

• Project requirements

• Conceptual design for services

• High-level project risks

• Structure of the project team

The Envisioning phase focuses the team on creating solid business value. It keeps your organization from investing significant effort on minor needs or from improving bad processes rather than creating good ones. The best results are based on open thinking about how the proposed solution may address not only the most visible current need, but also the underlying causes of that need. It is also important to consider similar issues in other departments, as well as issues that your business might face in the future.

The main milestone for the Envisioning phase is the project team's approval of the Vision and Scope document. Once this is completed, you'll be ready to move to the next phase, Planning.

To help you write a Vision and Scope document, you can use the "Vision and Scope Template" found in the VisScope.doc file included with IIS Tools. To install IIS Tools, run Setup from the Resource Kit companion CD and choose the IIS Tools option.

Define the Project

The first section of the Vision and Scope document should provide clear direction to the team by defining project vision, scope (given the schedule and constraints), and assumptions. Asking questions such as the following will help you in this effort:

• Vision At a high level, what final outcome or result do we envision for the project? For example, a vision statement might be, "To leverage information technology through fast and cost-effective development and deployment of crucial line-of-business applications." The following is an example of a vision statement for a Web server migration project, using a fictitious company, Contoso Pharmaceuticals:

  Contoso Pharmaceuticals will replace its current UNIX Apache Web server environment with 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 to 20,000 worldwide users at 100 locations 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 move users to the new platform. To accomplish this, the company will use Windows 2000 Server integration tools and third-party UNIX conversion tools.

  A vision statement can also include a conceptual design drawing, as described in "Develop a Conceptual Design" later in this chapter.

• Scope What functionality can we reasonably implement during this project, and what should be postponed to a later date? Project variables-resources (people and money), schedule (time), and features (the solution)-exist in a triangular relationship, as depicted in Figure 2.2. Setting project scope requires balancing these variables. This could be accomplished by trading desired, but inessential, features for a shortened project schedule or reduced resource requirements.

  

  Figure 2.2 Balancing Project Variables

• Assumptions What assumptions are implicit in the project plan? Some assumptions might include that a valid Windows 2000 Server domain design has been implemented, or that qualified staff is available.

Create a Requirements Definition

It's important to clearly define the requirements for the new Web service in your Vision and Scope document. Your primary reason for migrating to IIS 5.0 could be as simple as adding Web services to your corporate network, or as far-reaching as automating workflow processes or providing online transaction processing (OLTP). You might also have a number of secondary goals. Although you might not have the resources to realize every goal at this time, it is worthwhile to list the more important ones to include in longer-range planning. Table 2.2 lists some typical requirements for a migration project.

Table 2.2 Project Requirements and Deliverables

Requirement	Deliverable
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 compliant with Microsoft® ODBC and Microsoft® OLE DB, 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 Microsoft® 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 ASP-based applications and ISAPI extensions. This allows for more efficient use of resources than is possible on most other Web servers.

Develop a Conceptual Design

From the requirements definition, you can develop a conceptual design that reflects your goals and requirements and that takes into account the current network and server environment. This is usually a high-level drawing, included in your Vision and Scope document, that depicts an optimal solution.

Figure 2.3 is an example of a conceptual design.

Figure 2.3 Example of Conceptual Design

This figure shows a corporate system that includes an intranet and a corporate Internet Web site. It supports internal and Internet e-mail through Microsoft® Exchange Server. A firewall protects sensitive company information and the company intranet against outside intrusion.

Assess Risk

Migrating a Web server can involve some risk. Analyzing risks before you begin a project, and implementing methods to mitigate them, can reduce any undesirable impact on your business. Table 2.3 lists some high-level project risks and mitigation strategies. You should include this type of assessment in your Vision and Scope document. Your list will probably include some risks that are more specific to the parameters of your project.

Table 2.3 Project Risks and Mitigation Strategies

Risk	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 that is 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.

To evaluate risks for your project, you can use the "Risk Assessment Form" found in the RiskAsmt.doc file on the Resource Kit companion CD.

Define the Project Team

In the MSF model, a team of peers plans and implements a project. Each member is responsible for a functional area of the project, but overall project responsibility rests with the team as a whole. The project team definition of the Vision and Scope document identifies functional areas to be addressed by team members and assigns individual roles and responsibilities. For a small project, a single team member can be responsible for one or more functional areas. On larger projects, a separate team might be assigned to each functional area. Table 2.4 provides a description of the roles and responsibilities typically necessary in a migration project.

Table 2.4 Migration Project Roles and Responsibilities

Role	Responsibility
Product Management	Product Management articulates a vision for the service and compiles requirements. This person or team is part of the project team and represents (or defends) end-user interests throughout the project. This role is not necessarily technical.
Program Management	Program Management drives the critical decisions necessary to release the right service at the right time, and coordinates the decision-making process in order to deliver the service in a manner consistent with organizational standards and interoperability goals. This person or team takes a technical role in the products and also coordinates the day-to-day activities of the rollout, providing technical guidance to the team and reporting progress to the Executive Sponsor, a high-level manager who might not necessarily be part of the team. The individual or team comprising Program Management is typically involved full-time and should have project management experience.
Development	Development builds or implements a system that is fully compliant with the Functional Specification, as described in "Define the New Service Offering" later in this chapter. This person or team has several responsibilities in a Web server migration project: Developing and designing the system services and base configuration of the system Creating profiles, system policies, and the overall system user interface Designing, testing, implementing, and supporting the system Selecting, evaluating, migrating, implementing, and supporting Web applications
Test	Test exercises the user interface, applications, and integration of new software into existing systems, ensuring that all issues are known before the release of the service. The test person or team is responsible for developing procedures and guidelines for testing and evaluating all applications in conjunction with new hardware and software systems. This role is responsible for writing the test suites and ensuring project goals have been met.
User Education	User Education improves the user experience through training and support systems. This person or team is responsible for ensuring that the user education process and documents are completed, including all documentation relative to this installation. This role also creates a knowledge base for support and evaluates the various options, before selecting the best ones for training and education programs.
Logistics	Logistics ensures a smooth rollout, installation, and migration of the system to the operations and support groups. This person or role is responsible for planning the deployment of technology.
Executive Sponsor	This is a high-level management official (at the Director, Vice President, or Corporate Information Officer level) who has a great deal of authority and who can support your efforts by providing assistance throughout the project. This individual will not be involved full-time. The Executive Sponsor is not necessarily a team member, but serves as an "external influence" on the team.

2. Planning

Planning, the second phase of the MSF process model, is perhaps the most important activity in a migration project. Careful planning can make the difference between a smooth transition to IIS 5.0 and a rocky one. During this phase, the project team defines:

• What solution the project team will deliver. The solution is defined in the form of a functional specification document.

• How the solution will be developed, tested, and deployed, in the form of a master project plan.

• When development of the solution will begin and when its deployment will be completed, in the form of a project schedule.

As part of this process, you will gather information about current services, define the new service offering, as well as assess resource needs and time requirements for carrying out the project. These activities will yield the information you need to build a functional specification, as well as a master project plan, and a project schedule. The project team's acceptance of the project plan is the milestone signifying completion of the Planning phase.

Team Roles during the Planning Phase

During the previous phase-Envisioning-Product Management had a focal role. Now team focus shifts to Program Management, where it will remain during the Planning and Developing phases. Table 2.5 shows team roles and responsibilities during the Planning phase:

Table 2.5 Team Roles During the Planning Phase

Role	Responsibility
Product Management	Conceptual design, business and user needs analysis, budget
Program Management	The Functional Specification, project plan, and schedule
Development	Technology evaluation, physical design, development plan, and schedule
Test	Design evaluation, test plan, and schedule
User Education	User education, communications, usability test plan, and schedule
Logistics	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, 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. You can find sample forms to use for conducting this survey, titled "Organization Environment Survey" (OrgEnvir.doc) and "Technical Environment Survey" (TechEnvi.doc), on the Resource Kit companion CD.

You might also want to perform a traffic analysis for estimating capacity requirements. For more information about doing this, see "Capacity Planning" in this book.

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 might 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 https://www.microsoft.com/frontpage/.

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 the resources listed at the end of "Migrating a Web Server to IIS 5.0" in this book.

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 might be on your list:

• IIS Migration Wizard, if migrating from Netscape or Apache

• Web content migration tools, such as FrontPage

• UNIX-to-Microsoft® 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, Common Gateway Interface (CGI), Perl, C++, and Java. Next, decide if you will continue supporting them. Otherwise, make the transition to ISAPI or ASP, as described in "Migrating a Web Server to IIS 5.0" in this book. To help you with this list, you can use the "Tools Checklist" located in the ToolsChk.doc file on the Resource Kit companion CD.

Users

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. Figure 2.4 shows the information flow as external and internal users access the services and facilities of a commercial ISP.

Figure 2.4 System Users of an ISP

Standards

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 Form" found in the Standard.doc file on the Resource Kit companion CD.

Table 2.6 shows some issues to consider when reviewing standards and policies:

Table 2.6 Policy and Procedure Review

Policy/Procedure	More Information	Issues
Content Publishing	IIS 5.0 online product documentation	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	"Capacity Planning" in this book	Recovery plans. Off-site or on-site spare server location. Spare server availability. Rehearsal provisions.
Internet Services	"Security" in this book	The person to contact for each service. Access control.
Maintenance	"Monitoring and Tuning Your Server" in this book	Preventative maintenance procedures. System monitoring policy and tools.
Netiquette		Guidelines for appropriate network and e-mail use.
Network	Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide	Escalation procedures for downed links. Contacts for network services.
Redundant Servers	"Administering an ISP Installation" in this book	Fault-tolerant servers. Load-balancing servers.
Security	"Security" in this book	Password length and expiration period. Logon policies and auditing. Intruder prevention processes. Ownership/responsibility for user accounts. Methods for key encryption.

Define the New Service Offering

After gathering the necessary information about the network, tools in use, system users, and standards, the next step is to define the new service offering in more detail. This involves translating the requirements of the migration and conceptual design into the Functional Specification, which describes one or more solutions.

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 Development, Testing, User Education, and Logistics Management to begin laying out project plans for their portion of the work. To help you begin this process, you can use the "Functional Specification Template" found in the FuncSpec.doc file on the Resource Kit companion CD.

The Solution

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. For more information about database applications, see "Developing Web Applications" in this book.

You might plan to migrate to IIS 5.0 because of a specific requirement supported by a particular capability IIS 5.0 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. Earlier in this chapter, Table 2.2, "Project Requirements and Deliverables" provided 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 https://www.microsoft.com/ntserver/.

Interoperation Plan

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. This entails considering the best way 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 "Migrating a Web Server to IIS 5.0" in this book.

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 needs can be affected by growth in overall system usage as well as by user demand for increasingly rich content. For more information about this subject, see "Capacity Planning" in this book. In that chapter, the detailed design for services at https://www.microsoft.com is illustrated in Figure 4.9, "The microsoft.com Web Site." For developing the detailed design, you can use the "Design Template" found in the Design.doc file on the Resource Kit companion CD.

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 adequately defines the required capabilities of the system. Prototyping allows predevelopment testing from many perspectives, especially usability, and helps create a better understanding of user interaction. The information gained from prototyping will also help you improve the Functional Specification.

Assess Resource Needs

Another important step 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.

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 Transmission Control Protocol/Internet Protocol (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. On the other hand, 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, included on the Resource Kit companion CD, migrates server configuration settings to IIS 5.0 from Netscape Enterprise Server, Apache HTTP Server, and IIS 4.0, and replicates settings from one IIS 5.0 server to another. The wizard is described in "Migrating a Web Server to IIS 5.0" in this book.

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 you do this, the wizard imports your pages, images, and files, while preserving the web's structure and hyperlinks. For more information about FrontPage, see https://www.microsoft.com/frontpage/.

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 "Migrating a Web Server to IIS 5.0" in this book.

Other Tools

Other tools for converting CGI applications, debugging script, transferring data, testing, and more are listed in the "Additional Resources" section in this chapter and in "Migrating a Web Server to IIS 5.0" in this book.

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 https://www.microsoft.com/products/os.htm.

Hardware

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 Environment

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 that are running UNIX or Macintosh® operating systems along with computers that are 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 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 replicate 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.

Figure 2.5 shows a unit and integration lab with a WAN link simulated by using two routers.

Figure 2.5 Example of a Test Lab Setup

Deployment Environment

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.

For details on setting up a dedicated physical server for deployment, and for more information about assessing your deployment hardware needs, see "Migrating a Web Server to IIS 5.0" in this book.

Build 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 your project plan, you can use the "Project Plan Template" in the ProjPlan.doc file on the Resource Kit companion CD.

Draft the Project Schedule

Your project schedule should include all of the detailed project schedules, including the release date. The team determines the release date after negotiating the Functional Specification draft and reviewing the Master Project Plan draft. It might be necessary for the team to modify some of the Functional Specification or Master Project Plan 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.

Figure 2.6 shows a sample schedule. You can use the "Sample Project Schedule," in the ProjSche.mpp file on the Resource Kit companion CD, as a template for developing your schedule.

Figure 2.6 Sample Project Schedule

Check 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:

• 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 https://www.microsoft.com/products/.

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

3. Developing

An approved functional specification and associated project plan provide the baseline for focused development to begin. During the Developing phase, the Development team creates and validates the detailed design through testing and debugging. The system is built out, training of administrators and key users begins, and, finally, pilot testing is conducted.

The main milestone for the Developing phase is Release. At the Release milestone, the team assesses product functionality and verifies that rollout and support plans are in place. All new development is complete, and deferred functionality is documented for the next release.

Team Roles During the Developing Phase

During this phase, Program Management continues to take the lead. Table 2.7 shows the responsibilities of the project team during this phase:

Table 2.7 Team Roles During the Developing Phase

Role	Responsibility
Product Management	Developing and delivering communications to the user community outside the project team
Program Management	Functional specification management, project tracking, updated plans
Development	Solution and documentation
Test	Solution test, issue identification, documentation testing, updated test plans
User Education	Training, updated training plan, user communications
Logistics	Rollout checklists, updated rollout and pilot plans, site preparation checklists

Validate the Design

When the detailed design is complete, you're ready to validate it. Validating the design consists of performing unit, integration, and application testing to ensure the proposed system functions as expected and required. This testing is usually conducted in a lab environment similar to the one depicted in "Assess Resource Needs" earlier in this chapter.

Testing can be divided into four basic categories:

• Unit Testing Performed in the unit test lab, unit testing validates functionality of the Web server independent of other computers and systems.

• Integration Testing Performed in the integration test lab, integration testing ensures functionality, performance, and security of the Web server in the context of a network, and the platforms and servers with which the server will operate.

• Application Testing To verify Web application functionality and performance, application testing progresses from a development computer for basic functionality testing, to the unit lab, and finally to the integration lab to test its functionality in context.

• Pilot Testing Conducted by typical system users, usually on their own workstations, pilot testing demonstrates the usability of the Web services.

The testing process is iterative rather than linear. For example, you might discover a problem during an integration test, correct it, test the solution, and then go back to unit testing to find out if the correction has changed your results. In addition, it's frequently possible to conduct two or more procedures concurrently in order to complete testing at an earlier date.

For more information about testing and debugging applications, see "Developing Web Applications" in this book. In addition, see test planning information at https://www.microsoft.com/msf/.

For more information about improving server performance, see "Monitoring and Tuning Your Server" in this book. To develop your own test plans, you can use the "Sample Test Plan" found in the Testplan.doc file on the Resource Kit companion CD.

Testing at microsoft.com

The microsoft.com Web site provides a good example of the testing process for new servers and applications. Prior to adding a new IIS 5.0 production Web server, the microsoft.com team monitors and tunes a replica of the new server in a lab environment for a period of three months. Team members use a software and hardware configuration exactly replicating the production Web server that will exist on the microsoft.com Web site. Next, they move the server to the Microsoft intranet for a two-week period of further evaluation and tuning. After the tuning period, they replicate it to a nonmission-critical server on microsoft.com, running it in debug mode for one or two days to resolve any new problems that arise. Finally, they replicate the server to the actual production hardware, and then make it available site-wide. During the entire test process, the team monitors server performance continuously by using the HTTP Monitoring Tool, and uses the optimization techniques described in a white paper you can read at https://www.microsoft.com/ms.htm.

Another important concern for the microsoft.com team is ASP performance. To ensure good user experiences, the test team inspects all new ASP pages before they're published on the Microsoft Web site, noting the number of elements within each ASP page that have the potential to block performance, including objects such as Microsoft® ActiveX® Data Objects (ADO) and the ASP FileSystemObject. The test team then uses WCAT to test all pages that contain more than a certain threshold number of potentially troublesome elements. The team scores each page on Requests per Second, Maximum Response Time, and Average Response Time. If a page receives a poor score, the test team requires the owner to make improvements that will enhance performance.

Unit Testing

Unit testing involves the individual server outside the context of the network as well as other servers and operating systems with which it may coexist. If your migration involves multiple servers, you should migrate and test one server initially and ensure that it functions properly before proceeding to the others. This learning process will help you improve your approach for migrating subsequent servers. Table 2.8 describes some of the more important items to check during unit testing. You might want to include additional items in your own test process.

Table 2.8 Unit Tests

Unit Test	Description
User and Administrator accounts	Verify that user and group authentication information is accurate and complete. Verify that the correct user database is referenced by IIS 5.0 (local or domain).
Permissions	Verify file and directory permissions. Check access to files using different user accounts. Run ported applications and server extensions, such as CGI scripts and executables or ISAPI dynamic-link libraries (DLLs), to exercise Component Services settings and Execute/Script permissions.
File names and paths	Check for file-name conflicts and verify that file names and paths are correct. Verify that Windows conventions are used within migrated files, including referenced file names and paths, as discussed in "Migrating a Web Server to IIS 5.0" in this book.
Hyperlinks and page formatting	Run as https://localhost/ and verify hyperlinks. Also check for corrupt HTML that results in improper page formatting. Be sure to include ASP in this testing, if you are using it.
Applications	Verify that pooled, out-of-process, and in-process applications run correctly, as well as any applications that rely on a third-party script interpreter, such as Perl. Test any ported CGI or server-extending applications (EXE and DLL) to exercise Component Services settings and Execute/Script permissions.

Integration Testing

Once the server has passed unit testing, you're ready to evaluate it in a larger context of a network or server group during integration testing. Table 2.9 describes some common integration tests. You might want to include additional items in your own test process.

Table 2.9 Integration Tests

Integration Test	Description
Network identification	Verify that the server is correctly identified on the network.
Application integration	Test ASP applications that access backend databases or other remote objects, to verify that they function as expected and that permissions and script settings (such as time-out) are set correctly.
Stress, or load testing	Measure Web site performance, working with a replica of the site in a lab environment with multiple clients to simulate load on the servers. WCAT, a useful tool for this simulation, is provided on the Resource Kit companion CD. You can also check how individual Web sites are using the CPU by using IIS 5.0 process accounting, as described in the IIS 5.0 online product documentation.
Server availability	Measure availability of the server on the network by using the HTTP Monitoring Tool, which is included on the Resource Kit companion CD. It is described in a white paper you can read at https://msdn.microsoft.com/workshop/server/.
Performance monitoring and tuning	Monitor server performance by using the HTTP Monitoring Tool, as described in a white paper you can read at https://msdn.microsoft.com/workshop/server/. See also "Monitoring and Tuning Your Server" in this book and the "Calculating Connection Performance" topic in the IIS 5.0 online product documentation.
Security functionality	Test the various possible iterations of the system to verify that security performs as expected in each scenario. You can generate tests to exercise these system variations from a matrix that includes: Each secured system component, such as Microsoft® Internet Explorer 5, IIS 5.0, and SQL Server. Variants in the security implementation of each component; for example, browser Secure Sockets Layer (SSL) security (48 bit, 128 bit, or Server­Gated Cryptography [SGC]), IIS 5.0 authentication (none, Basic, or integrated Windows authentication), and so forth. Communication protocols between system components, such as named pipes and TCP/IP sockets.
Security against penetration	Test security against intrusion, as described in "Security" in this book.

Application Testing

Prior to deployment, each application you migrate or port to IIS 5.0 should be tested on a server that's running Windows 2000 Server with IIS 5.0. It's best to begin this process well in advance of the final deadline for completion since Web applications can present unexpected problems.

In addition to testing for basic functionality, it's also important to test an application for performance. A poorly coded Web page can increase server response time and decrease the number of users served. Table 2.10 includes a few examples of application tests. Usually, code review is conducted on a development computer, then stress and performance testing move to the test lab. For more information about testing and debugging applications, see "Developing Web Applications" in this book.

Table 2.10 Application Tests

Application Test	Description
Code review	Check hyperlink references, keywords, and programming style. Make sure that any UNIX conventions are changed to Windows conventions, as described in "Migrating a Web Server to IIS 5.0" in this book. For ASP optimization tips, see "ASP Best Practices." For tips on reviewing ASP code, see https://msdn.microsoft.com/workshop/server/.
Load, or stress testing	Test the number of concurrent users the application can support. Verify that CPU and memory usage is acceptable under high loads. You can use the Web Application Stress Tool, included on the Resource Kit companion CD, for stress testing multitier ASP applications.
Performance testing	Test application performance under a variety of conditions. Test overall performance impact of the application on the server.
Application logic	Run as https://localhost/ and check for proper operation of application logic.

Build out the System

Once the detailed design has been tested and validated, you're ready to build out the system, configuring and locating the production Web servers that will be used on your network. When the Release milestone for the Developing phase has been achieved, you will be ready to deploy the new servers, as described in "Deploying" later in this chapter.

Begin Training

As soon as possible, begin training administrative staff, support personnel, and key users. Any staff members who will be working with IIS 5.0 during or after the migration will benefit from taking a Microsoft-certified course in IIS 5.0. In addition to training the individuals who will be performing the migration and administering servers, you'll probably want to provide end-user training and support. Web developers will also benefit from training on subjects such as creating ASP-based applications and using FrontPage to publish Web pages.

For more information about available Microsoft training, see https://www.microsoft.com/train_cert/.

For information about other books and for training materials on Microsoft products, see https://www.microsoft.com/mspress/.

Conduct Pilot Testing

Pilot testing involves having a group of end users try the system prior to its full deployment in order to give feedback on IIS 5.0 features and functions. The level of pilot testing you want to perform depends on the size and scope of your migration project. For larger projects, a formal, carefully planned pilot is essential. For any size project, it's good to have selected end users test the system prior to full deployment.

During the initial, pre-pilot phase you can select a small group of technically savvy users to try out the technology. You probably won't want to provide support during this phase, because it can draw resources away from system development and burden your schedule.

After making adjustments based on input from the pre-pilot users, you can begin the actual pilot. During this phase, a larger group of users should review and fully use system features. These users should be at about the same technical level as your system users in general. During this phase, you should plan to provide support for all issues, errors, or problems that users report. When you make any corrections, be sure to thoroughly retest the system.

The following are items to include in planning a pilot test:

• Adequate training for participants

• A rollout plan for deploying the servers and preparing systems for the pilot

• Documentation of the installation process so you can improve it as more is learned

• A mechanism, such as a Web site or e-mail alias, for users to provide constant feedback to the design and testing teams

• Evaluation criteria for the pilot, including information about the number of users who were dissatisfied, the number of problems reported, the number of support calls and requests, and the resolution rate for problems

4. Deploying

The final phase of the migration process, in the MSF process model, is Deploying. During this phase, the team must transition from creating elegant development solutions to complying with the rigid operational requirements of thorough and complete testing. The goal of this phase is to make the new services available to the target audience and users. This requires completing user and administrator training, rolling out and monitoring the system, and fixing bugs.

The milestone for this phase is Deployment Complete, when the system can be formally turned over to Operations and Support, for maintenance.

Team Roles During the Deploying Phase

During this phase, a subtle shift occurs in the dynamics of the project team. Here, the Logistics Manager will step to center stage. The Logistics Manager will often share the focus of the project with User Education as the systems are actively deployed, as users receive the appropriate training, and as the operations and support systems are activated. Table 2.11 shows the responsibilities of the project team during this phase:

Table 2.11 Team Roles During the Deploying Phase

Role	Responsibility
Product Management	Promotion, feedback, assessment, sign-off
Program Management	Solution/scope comparison, stabilization management
Development	Problem resolution, escalation support
Test	Performance testing, problem identification
User Education	Training, training schedule management
Logistics	Site deployment management, change approval

Finish Training

Prior to rolling out the new system, you need to be sure that all system administrators, support staff, and users have completed training. In addition, user support systems should be in place.

Roll out the New System

Before making the new system available to all prospective users, you can use the checklist in Table 2.12 to verify that you've completed the minimum set of tasks required for a successful rollout.

Table 2.12 Rollout Checklist

	Task	Reference
	Migrate server configuration settings.	"Migrating a Web Server to IIS 5.0" in this book.
	Migrate Web and FTP site content.	"Migrating a Web Server to IIS 5.0" in this book.
	Migrate Web applications.	"Migrating a Web Server to IIS 5.0" in this book.
	Prepare the network including implementation of a valid Windows 2000 Server domain and network topology.	Windows 2000 Server online product documentation.
	Install administrative tools and utilities.	"Migrating a Web Server to IIS 5.0" in this book.
	Implement required policies and procedures.	"Standards" earlier in this chapter.
	Install tools, utilities, and applications needed by Web developers and end users.	"Migrating a Web Server to IIS 5.0" in this book.
	Thoroughly test components, system, pages, and applications.	"Validate the Design" earlier in this chapter.
	Provide training on the new system for all administrators, developers, and end users.	"Staff" earlier in this chapter.
	Make technical support available for all users.	"Staff" earlier in this chapter.

Once you've completed the rollout checklist, you're ready to make the new IIS 5.0 server available to users on the network. For a large-scale migration, or one involving mission-critical applications, you might deploy the server in steps, making its services available to progressively larger groups of users over time. For an example of how to do this, see the sidebar "Testing at microsoft.com" earlier in this chapter.

There are several technical approaches to taking a production Web server out of service and bringing the new server onto your network to begin hosting. The method you choose should be based on your network policies, amount of acceptable downtime, and your technical knowledge. Here are two possible methods:

• If some downtime is acceptable, power down the existing production Web server and simultaneously start up the new IIS 5.0 server using the IP address and network settings of the existing production Web server. You might experience several minutes of server downtime; however, problems should be minimized if you perform the switch during off-peak hours and inform users several days in advance.

• If no downtime is acceptable, assign the new IIS 5.0 server a new IP address, and set the transistor-transistor logic (TTL) units in the Domain Name System (DNS) records so that they will expire in 24 hours. Set up round-robin DNS so requests will be sent sequentially to the production Web server and to the new IIS 5.0 server. Wait for the DNS to propagate. After the first propagation, turn off the round-robin setting on the production Web server, and wait for propagation to occur again. When you're sure the new IP has been propagated, turn off the production Web server. However, exercise caution if you're using tracking or dynamic capabilities on your site, as problems could occur.

  Of course, if you're using a server clustering tool such as Network Load Balancing, all you need to do is assign the new server the appropriate IP address and bring it onto the network, and then take the old production Web server offline.

Monitor the System

It's important to monitor the performance of the new IIS 5.0 server, especially in the first few days after deployment, to ensure your users are not encountering problems when visiting your Web sites. During this time, you'll also want to fine-tune server performance. To track server performance, use either the System Monitor in Microsoft® Windows® 2000 Server, or the HTTP Monitoring Tool, the latter of which is included on the Resource Kit companion CD. Performance degradation can alert you to a serious problem. Some suggested items to monitor are processor use, memory use, disk use, and network availability. For more information about monitoring, see "Monitoring and Tuning Your Server" in this book.

No matter how carefully you've planned and carried out the migration, you're bound to run into a glitch or two following system deployment. There are a number of resources to help you troubleshoot problems that occur with the new IIS 5.0 server. For example, by participating in a related newsgroup, such as the newsgroup sponsored by 15seconds.com, you can get troubleshooting information from other IIS 5.0 users. In addition, Microsoft provides searchable reference information that may be of help at https://support.microsoft.com/support/.

For finding information about debugging applications, try using the search string "application debugging."

Additional Resources

Described below are additional resources that can help you perform a migration. Also listed are Web sites and books that provide additional information about IIS 5.0 and about other features of Windows 2000 Server.

Support Documents

The following support files, which were referred to in this chapter, can be found on the Resource Kit companion CD. They are available in .rtf format as well.

·Design.doc	Design Template
·FuncSpec.doc	Functional Specification Template
·OrgEnvir.doc	Organization Environment Survey
·ProjPlan.doc	Project Plan Template
·ProjSche.mpp	Sample Project Schedule
·RiskAsmt.doc	Risk Assessment Form
·Standard.doc	Standards Review Form
·TechEnvi.doc	Technical Environment Survey
·TestPlan.doc	Sample Test Plan
·ToolsChk.doc	Tools Checklist
·VisScope.doc	Vision and Scope Template

IIS 5.0 Migration Tools

IIS Migration Wizard

Included on the Resource Kit companion CD, the IIS Migration Wizard automatically migrates most configuration settings, as well as user and group information, to IIS 5.0 from the following Web servers:

• Netscape Enterprise Server 3.5

• Apache HTTP Server 1.3

• IIS 4.0

• IIS 5.0 (from one computer to another)

For more information about the IIS Migration Wizard and for tables of migrated configuration settings, see "Migrating a Web Server to IIS 5.0" in this book.

Note: The IIS Migration Wizard is provided for instructional purposes only and is not supported by Microsoft.

Other Migration Tools

https://www.datafocus.com/products/tk/

Mortice Kern Systems makes the MKS Toolkit, which 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.

https://www.shareware.com/

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

Migration and Integration Resources

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.

Topics covered include porting applications, TCP/IP, Common Object Request Broker (CORBA) and Microsoft® 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 Resources

Software Project Survival Guide by Steve McConnell, 1998, Redmond: Microsoft Press.

This book provides a complete set of guidelines for a successful development project.

https://www.construx.com/survivalguide/

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

Here are various tools that you can use for testing:

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

• The Web Application Stress Tool, found on the Resource Kit companion CD, 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.

• The HTTP Monitoring Tool, found on the Resource Kit companion CD, monitors HTTP activity on the server.

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

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

For more information about testing tools, see https://www.microsoft.com/windows2000/default.asp.

General Administration Books and Training

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

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

https://www.microsoft.com/msf/

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