This white paper provides an overview of the migration process to move from Linux and Apache HTTP Server to Microsoft Windows 2000 and Internet Information Services. Internet Information Services (IIS) is built into each version of Windows 2000 Server and is an ideal platform for Web site hosting. This white paper is specifically designed as a planning and migration guide for IT professionals who are moving a Web site from Linux and Apache HTTP Server to Microsoft Windows 2000 and Internet Information Services.

On This Page

Introduction
Microsoft IIS 5.0 Overview
Using the Microsoft Solutions Framework
MSF Envisioning Phase
MSF Planning Phase
MSF Developing Phase
MSF Deploying Phase
Planning a Web Services Migration Project
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
Migration Steps
Migrating from Apache HTTP Server
Summary
Appendix A - Company.com
Appendix B - Additional Resources

Introduction

As the Internet becomes more woven into mainstream businesses, so grows the need to have Web services interwoven with mainstream business computing. To address that need, Microsoft® Windows® 2000 Server includes an updated version of Internet Information Services (IIS), called IIS 5.0. Internet Information Services runs as an enterprise service within Windows 2000. It uses other services provided by Windows 2000, such as security and the Active Directory™ directory service.

This version improves the Web server's reliability, performance, management, security, and application services. Many of these improvements result from the way IIS 5.0 incorporates new operating system features provided in Windows 2000.

With IIS 4.0, Microsoft focused on security, administration, programmability, and support for Internet standards. IIS 5.0 builds on the features and capabilities needed to deliver Web sites required in an increasingly Internet-centric business environment. And it makes it even easier to use the technologies delivered in prior versions. In particular, IIS 5.0 features improvements in the following four major areas:

Reliability and performance. A number of features make IIS more reliable and improve performance. To make it faster and easier to restart IIS, the reliable restart feature of IIS 5.0 allows an administrator to restart Web services without rebooting the computer. To improve reliability, Application Protection provides the ability to run applications in an isolated pool, separate from the Web services. The new CPU Throttling and Socket Pooling features in IIS 5.0 can also improve reliability. For application developers, Web site performance can be improved through new features such as scriptless Microsoft Active Server Pages (ASP) processing, ASP self-tuning, and performance-enhanced ASP objects.

Management. IIS 5.0 is easier to install and maintain. A number of features support this increased ease of maintenance, including a simplified installation process, new security task wizards, the ability to account for time used by processes, more flexible remote administration, and the ability to create custom error messages.

Security. IIS 5.0 adds support for important industry-standard security protocols, including Digest Authentication, Server Gated Cryptography, Kerberos v5 authentication protocol, Transport Layer Security, and Fortezza. In addition, three new task wizards make it easier for administrators to manage a site's security settings.

Application environment. Developers will find that IIS 5.0 expands the Web server's application development environment by building on new technologies included in Windows 2000 Server. These include Active Directory and the expanded Component Object Model (COM+). In addition, enhancements to IIS Active Server Pages, such as scriptless ASP processing, as well as improved flow control and error handling, let developers write more efficient Web-centric applications.

This paper provides a technical overview of the key features and capabilities in IIS 5.0 to allow information technology and business professionals to assess the ways IIS 5.0 can fit into their business computing environments.

These features are the reasons that more and more companies are migrating from Linux or other UNIX-like operating systems to Microsoft Windows 2000 as their Web hosting platform. The purpose of this paper is to provide a detailed description of the steps necessary to migrate from Linux and the Apache HTTP Server to Microsoft Windows 2000 and Internet Information Services. Because there are few, if any, relevant differences between Linux and other UNIX-like operating systems (such as FreeBSD or Solaris), you can also use this paper to guide your migration from those systems.

In Appendix A of this paper you will find a detailed discussion of Company.com (fictitious name to conceal the identity of the online company). Much of the information contained within this white paper was gained during their site migration from Linux and the Apache HTTP Server to Microsoft Windows 2000 and IIS 5.0.

Microsoft IIS 5.0 Overview

The Windows 2000 Server operating system integrates Internet technologies across all services, from File and Print to advanced line-of-business application services. This helps ensure organizations can more effectively exchange information with customers, partners, and employees worldwide.

Windows 2000 Server meets the needs of a broad spectrum of users, from corporate intranets to Internet Service Providers hosting Web sites receiving millions of hits per day. Because Internet Information Services 5.0 (IIS) is fully integrated at the operating system level, Windows 2000 Server lets organizations add Internet capabilities that weave directly into the rest of their computing infrastructure.

Specifically, Windows 2000 Server lets organizations:

• Share information more efficiently using the Web.

  In the past, performing standard file operations on a network file share was much easier than performing similar operations on a remote Web site. Now, Windows 2000 Server technologies such as Web Distributed Authoring and Versioning (WebDAV) make it as easy to carry out standard file operations on a Web share.

• Create Web-based business applications.

  Creating Web-based applications that integrate well into traditional business applications can be difficult. Windows 2000 Server overcomes this burden by sharing Internet-aware application development tools with IIS, an efficiency that extends applications to the Web and eliminates awkward bridges between internal and external processes.

• Bring server operating system functionality to the Web.

  In addition to allowing organizations to extend basic file and print services to the Web, Windows 2000 Server supports applications, media, and communications and networking services from a common server platform. This convergence means that everything a company can do with Windows 2000 Server is automatically supported in a fully integrated Web environment.

What follows is a series of charts that detail the specific features and functionality of IIS 5.0 as they relate to the above themes. This information is intended to give you a good overview of the features and functionality contained within IIS 5.0 so that you may better plan how to utilize these features in your migration from Linux and the Apache HTTP Server to Microsoft Windows 2000 and IIS 5.0.Sharing Information

Feature	Description
Support for Web Distributed Authoring and Versioning (WebDAV)	WebDAV is an Internet standard that lets multiple people collaborate on a document using an Internet-based shared file system. It addresses issues such as file access permissions, offline editing, file integrity, and conflict resolution when competing changes are made to a document. WebDAV expands an organization's infrastructure by using the Internet as the central location for storing shared files.
Web Folders	Support for Web Folders lets users navigate to a WebDAV-compliant server and view the content as if it were part of the same namespace as the local system. Users can drag and drop files, retrieve or modify file property information, and perform other file system-related tasks. Web Folders let users maintain a consistent look and feel between navigating the local file system, a networked drive, and an Internet Web site.
Support for FrontPage Server Extensions	Windows 2000 Server lets administrators use Microsoft FrontPage® Web authoring and management features to deploy and manage Web sites. With FrontPage Server Extensions, administrators can view and manage a Web site in a graphical interface, so creating Web sites with the FrontPage Web site creation and management tool is as easy as clicking a check box on a property page for the Web site. In addition, authors can create, edit, and post Web pages to IIS remotely.
Support for Latest Internet Standards	Using the integrated Web services in Windows 2000 Server, organizations can take advantage of the latest Internet standards to publish and share information over the Web. Microsoft Internet Information Services (IIS) 5.0 complies with the HTTP 1.1 standard, including features such as PUT and DELETE, the ability to customize HTTP error messages, and support for custom HTTP headers. Support for the latest protocols provides optimum performance for Web server connections.
Support for Multiple Sites with One IP Address	With support for host headers, an organization can host multiple Web sites on a single computer running Microsoft Windows 2000 Server with only one Internet Protocol (IP) address. This lets Internet service providers (ISPs) and corporate intranets host multiple Web sites on a single server while offering separate user domains for each site.
News and Mail	Administrators can use Simple Mail Transfer Protocol (SMTP) and Network News Transport Protocol (NNTP) Services to set up intranet mail and news services that work in conjunction with IIS. SMTP is a commonly used protocol for sending e-mail messages between servers; NNTP is the protocol used to post, distribute, and retrieve USENET messages.
PICS Ratings	Administrators can apply Platform for Internet Content Selection (PICS) ratings to sites that contain content for mature audiences. This lets them host a variety of sites and provide information about suitability for particular audiences.
HTTP Compression	HTTP compression allows faster transmission of pages between the Web server and compression-enabled clients. This is useful in situations where bandwidth is limited.
File Transfer Protocol (FTP) and FTP Restart	The File Transfer Protocol (FTP) service, used to publish information to a Web server, is integrated into Windows 2000 Server. FTP Restart provides a faster, smoother way to download information from the Internet. Now, if an interruption occurs during data transfer from an FTP site, a download can be resumed without having to download the entire file over again.

Creating Web-Based Applications

Feature	Description
Active Server Pages	Microsoft Active Server Pages (ASP) lets developers create dynamic content by using server-side scripting and components to create browser-independent dynamic content. ASP provides an easy-to-use alternative to Common Gateway Interface (CGI) and Internet Server Application Program Interface (ISAPI) by letting content developers embed any scripting language or server component into their HTML pages. ASP pages provide standards-based database connectivity and the ability to customize content for different browsers. ASP also provides error-handling capabilities for Web-based applications.
Performance-Enhanced Objects	ASP provides performance-enhanced versions of its popular installable components. These objects scale reliably in a wide range of Web application environments.
XML Integration	Just as HTML lets developers describe the format of a Web document, Extensible Markup Language (XML) lets them describe complex data structures. Developers can share this information across a variety of applications, clients, and servers. Using the new Microsoft XML Parser, developers can create applications that enable their Web server to exchange XML-formatted data with both Microsoft Internet Explorer and any server capable of parsing XML.
Windows Script Components	ASP supports the new scripting technology, Windows Script Components. This lets developers turn business logic script procedures into reusable COM components for Web applications and other COM-compliant programs.
ASP Self-Tuning	ASP now senses when executing requests are blocked by external resources and automatically provides more threads to simultaneously execute additional requests while continuing processing. If the CPU becomes overburdened, ASP curtails the number of threads in order to reduce the context switching that occurs when too many non-blocking requests are executing simultaneously.
Encoded ASP Scripts	Traditionally, Web developers have been unable to prevent others from reading their scripting code. ASP now supports a new script encoding utility provided with Microsoft Visual Basic® Scripting Edition (VBScript) and Microsoft JScript® 5.0. Web developers can apply an encoding scheme to both client and server-side scripts that makes the programmatic logic unreadable. When unencoded, the logic appears in standard ASCII characters. Encoded scripts are decoded at run time by the script engine, so there's no need for a separate utility. Although this feature is not intended as a secure, encrypted solution, it can prevent most casual users from browsing or copying scripts.
Application Protection	IIS 5.0 offers improved protection and increased reliability for Web applications. By default, IIS runs all applications in a common or pooled process that is separate from core IIS processes. In addition, administrators can still isolate mission-critical applications that should be run outside of both core IIS and pooled processes.
ADSI 2.0	Administrators and application developers can add custom objects, properties, and methods to the existing Active Directory Service Interfaces (ADSI) provider, giving administrators more flexibility in configuring sites. ADSI is a COM-based directory service model that lets ADSI-compliant client applications access a wide variety of distinct directory protocols, including Windows Directory Services and Lightweight Directory Access Protocol (LDAP), while using a single, standard set of interfaces. ADSI shields the client application from the implementation and operational details of the underlying data store or protocol.

Bringing Server Operating System Functionality To The Web

Feature	Description
Multisite Hosting	Often Web sites for several departments can run on a single server, freeing a company from spending the time and money to set up and manage multiple servers. Windows 2000 Server offers a comprehensive platform for hosting multiple Web sites on a single server. In addition, the multisite hosting capability in Windows 2000 Server lets ISPs host Web sites that can scale from hosting thousands of small sites on a single server to hosting a great number of sites across multiple servers.
Multiple User Domains	The integration between the Web servers and directory services (the Active Directory) in Windows 2000 Server lets organizations host multiple Web sites with independent user domains—that is, each Web site on a single server has its own user database.
User Management Delegation	This lets an IT or ISP administrator who hosts multiple Web sites on a single server delegate the day-to-day management of the Web site.
Process Throttling	This lets administrators limit the amount of CPU time a Web application or site can use during a predetermined period of time to ensure that processor time is available to other Web sites or to non-Web applications.
Per-Web-Site Bandwidth Throttling	This lets administrators regulate the amount of server bandwidth each site uses. This lets an ISP, for example, guarantee a predetermined amount of bandwidth to each site.
Integrated Setup and Upgrade	Internet Information Services (IIS) 5.0 installs as a networking service of Windows 2000 Server. Customers with any existing version of Windows NT® Server 3.51 or 4.0 will automatically be upgraded to the new Web services in Windows 2000 Server and can take advantage of the new features and services of Windows 2000 Server and IIS.
Microsoft Management Console (MMC) Task Pad	The MMC task pad considerably simplifies the administration of an IIS server. For example, if a user selects a server under the IIS MMC snap-in, the task pad will display wizards for creating new Web and FTP sites. Administrators simply select the task they want to complete, and a wizard walks them through the steps.
DFS as Filing System for IIS	You can use Microsoft DFS as the filing system for IIS by selecting the root for the Web site as a DFS root. Doing so lets you move resources within the DFS tree without affecting any HTML links. (Windows Media Services content can also be stored in the DFS tree.)
Improved Command-Line Administration Scripts	IIS ships with scripts that can be executed from the command line to automate the management of common Web server tasks. Administrators can create custom scripts that automate the management of IIS.
Reliable IIS Restart	Users can stop and restart all Internet services from within the IIS MMC snap-in, which makes it unnecessary to restart the computer when applications become unavailable.
Backing Up and Restoring IIS	Administrators can back up and save metabase settings to make it easy to return to a safe, known state. (A metabase is the structure for storing IIS configuration settings; the metabase performs some of the same functions as the system registry, but is more versatile.)
Process Accounting	Process Accounting, which is enabled and customized on a per-site basis, lets administrators monitor and log how Web sites use CPU resources on the server. Both system administrators and application developers can use this feature to determine CPU utilization. Internet service providers (ISPs) can use this information to determine which sites are using disproportionately high CPU resources or that may have malfunctioning scripts or Common Gateway Interface (CGI) processes. IT managers can use this information to charge back the cost of hosting a Web site and/or application to the appropriate division within a company.
Improved Custom Error Messages	Administrators can now send informative messages to clients when HTTP or ASP errors occur on their Web sites. They can use the custom errors that IIS 5.0 provides or create their own.
Configuration Options	Administrators can set permissions for read, write, execute, script, and FrontPage Web operations at the site, directory, or file level.
Remote Administration	IIS 5.0 has Web-based administration tools that allow remote management of a server from almost any browser on any platform. With IIS 5.0, administrators can set up administration accounts called Operators with limited administration privileges on Web sites, to help distribute administrative tasks.
Terminal Services	The Terminal Services support in Windows 2000 Server lets administrators remotely administer IIS by using the Microsoft Management Console (MMC) over a dial-up or PPTP connection. To do this, the Terminal Services client must be installed on client computers.
Centralized Administration	Administrators can use the MMC snap-in for IIS from a computer running Windows 2000 Professional to administer a computer on their intranet running Internet Information Services on Windows 2000 Server.

Securing Web Services

Feature	Description
Integrated Web Security	The Windows 2000 Server Web services are fully integrated with the Kerberos security infrastructure. The Kerberos Version 5 authentication protocol, which provides fast, single logon to Windows 2000 Server, replaces NTLM as the primary security protocol for access to resources within or across Windows 2000 domains. Users can securely authenticate themselves to a Windows 2000 Server Web site and will not have to undergo a separate authentication (logon) to use other resources. In addition, Windows 2000 Server now also supports the following standard authentication protocols, which are applicable to Web-based users and ordinary network users alike: · Digest Authentication: the latest authentication standard of the World Wide Web Consortium (W3C), the organization that sets standards for the Web and HTML. · Server-Gated Cryptography (SGC): used by financial institutions to transmit private documents via the Internet. · Fortezza: The United States government security standard.
Secure Communications	Secure Sockets Layer (SSL) 3.0 and Transport Layer Security (TLS) provide a secure way to exchange information between clients and servers. In addition, SSL 3.0 and TLS provide a way for the server to verify who the client is before the user logs on to the server. In IIS 5.0 programmers can track users through their sites. Also, IIS 5.0 lets administrators control access to system resources based on the client certificate.
Digest Authentication	Digest Authentication enables secure authentication of users across proxy servers and firewalls. It offers the same features as basic authentication, but improves on it by "hashing" the password traveling over the Internet, instead of transmitting it as clear text. For those who choose not to use Digest Authentication, Anonymous, HTTP Basic, and integrated Windows authentication (formerly called Windows NT Challenge/Response authentication) and NT LAN Manager (NTLM) authentication are still available.
Server-Gated Cryptography	SGC, an extension of Secure Sockets Layer (SSL), lets financial institutions with export versions of IIS use strong 128-bit encryption. Although SGC capabilities are built into IIS 5.0, a special SGC certificate is required to use SGC.
Security Wizards	These security wizards simplify server administration tasks: · Certificate Wizard simplifies certificate administration tasks, such as creating certificate requests and managing the certificate life cycle. Secure Sockets Layer (SSL) security is an increasingly common requirement for Web sites that provide e-commerce and access to sensitive business information. The new wizard makes it easy to set up SSL-enabled Web sites on Windows 2000 Server - administrators can easily establish and maintain SSL encryption and client certificate authentication. (A client certificate contains detailed identification information about the user and organization that issued the certificate.) · Permission Wizard walks administrators through the tasks of setting up permissions and authenticated access on an IIS Web site, making it much easier to set up and manage a Web site that requires authenticated access to its content. · Certificate Trust Lists (CTL) Wizard lets administrators configure certificate trust lists (CTLs). A CTL is a list of trusted certification authorities (CAs) for a particular directory. CTLs are especially useful for Internet service providers (ISPs) who have several Web sites on their server and who need to have a different list of approved certification authorities for each site.
IP and Internet Domain Restrictions	Administrators can grant or deny Web access to individual computers, groups of computers, or entire domains.
Kerberos Version 5 Authentication Protocol Compliance	IIS is fully integrated with the Kerberos v5 authentication protocol implemented in Microsoft Windows 2000. This means administrators can pass authentication credentials among connected computers running Windows.
Certificate Storage	IIS certificate storage is now integrated with the Windows CryptoAPI storage. The Windows Certificate Manager provides a single point of entry that lets administrators store, back up, and configure server certificates.
Fortezza	IIS 5.0 supports the United States government security standard, commonly called Fortezza. This standard satisfies the Defense Message System security architecture with a cryptographic mechanism that provides message confidentiality, integrity, authentication, and access control to messages, components, and systems. These features can be implemented both with server and browser software and with PCMCIA card hardware.

Using the Microsoft Solutions Framework

The best way to think about the migration process is in terms of the Microsoft Solutions Framework (MSF) 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: http://www.microsoft.com/technet/itsolutions/msf/default.mspx

The following graphic depicts the MSF process model, consisting of envisioning, planning, developing, and deploying, along with related milestones.

The MSF Model for Infrastructure Deployment

The following table lists the activities that are involved in each phase of a migration project in terms of the MSF phases and milestones:

MSF Phase	Main Milestone	Main Migration Tasks
1. Envisioning: the definition of goals and limits for 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 risks at a high level for the project. 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 the master project plan. E. Draft the project schedule.
3. Developing: developing, testing, and building 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 controlled introduction to 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.

MSF Envisioning Phase

Main Task: Creating the Vision and Scope Document

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

• Project goals, scope, 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.

1. Define the Project

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

   1. Vision What final outcome or result do we envision for the project, at a high level? 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." A vision statement can also include a conceptual design drawing, as described later.

   2. 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 the following diagram. Setting project scope requires balancing these variables. This is accomplished by trading desired, but inessential, features for a shortened project schedule or reduced resource requirements, for example.

      

   3. 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.

2. 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. 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.

3. Develop a Conceptual Design

   From the requirements definition you can develop a conceptual design that reflects your goals and requirements and 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. The following figure is an example of a 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. Sensitive company information and the company intranet is secured from outside intrusion by a firewall.

   

4. 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. The following table 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.

5. Define the Project Team

   In the MSF model, a project is planned and implemented by a team of peers. 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.

Main Milestone: Vision and Scope Approved

The main milestone for this phase is approval by the project team of the Vision and Scope document.

Migration Project Roles and Responsibilities

This table describes team roles and responsibilities during a Web server migration project.

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 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. This individual or team 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 later in "Functional Specification." 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 signing off on the final document when the 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 (Director, Vice President, or Corporate Information Officer level) who has a great deal of authority and 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.

MSF Planning Phase

Main Task: Creating the Master Project Plan and Schedule

Planning, the second phase of the MSF process model, is one of the most important activities 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 the following:

• What solution the project team will deliver. The solution is defined in 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, and assess resource needs and time requirements for carrying out the project. These activities will yield the information you need to build the functional specification, the master project plan, and the schedule.

These activities will be discussed in detail in the next article in this series, "Planning a Migration Project." Downloadable templates and forms to assist you in the process of gathering information and compiling it into plans will be provided.

Main Milestone: Project Plan Approved

The milestone for this phase is approval by the project team of the Master Project Plan and Project Schedule.

Team Roles During the Planning Phase

During the previous phase, Envisioning, product management had a focal role. Now team focus shifts to the program management, where it will remain during the Planning and Developing phases.

Role	Responsibility
Product Management	Conceptual design, business and user needs analysis, budget
Program Management	Functional specification, master 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, logistics plan and schedule

MSF Developing Phase

Main Task: Developing, Testing, and Building Out the System

An approved functional specification and associated project plan provides 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, training of administrators and key users begins, and, finally, pilot testing is conducted.

Validate the Design

During the planning phase, the team created a detailed system design. When 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, which will be described in greater detail in the next article in this series, "Planning a Migration Project."

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 may discover a problem during an integration test, correct it and 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.

Build Out the System

Once the detailed design has been tested and validated, you're ready to build 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 later.

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 as well. In addition, Web developers will benefit from training on subjects such as creating ASP-based applications and using Microsoft FrontPage to publish Web pages.

For more information about available Microsoft training, see: http://www.microsoft.com/learning/default.asp

For information about other books and training materials on Microsoft products, see: http://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 a good idea 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.

Main Milestone: Release

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.

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

MSF Deploying Phase

Main Task: Making the New Services Available to End Users

The final phase of the migration process, in the MSF 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 making the new services available to the target audience and users. This requires completing user and administrator training, rolling out and monitoring the system, and bug fixing.

Finish Training

Prior to rolling out the new system, you need to ensure 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

You're ready to make the new system available to all prospective users, when you've completed the following set of tasks. At this point, 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.

Rollout Checklist

Checked	Task
	Migrate server configuration settings.
	Migrate Web and FTP site content.
	Migrate Web applications.
	Prepare the network including implementation of a valid Windows 2000 Server domain and network topology.
	Install administrative tools and utilities.
	Implement required policies and procedures.
	Install tools, utilities, and applications needed by Web developers and end users.
	Thoroughly test components, system, pages, and applications.
	Provide training on the new system for all administrators, developers, and end users.
	Make technical support available for all users.

There are several technical approaches to taking a production server out of service and bringing the new server on 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, turn off the existing production server and simultaneously start the new IIS 5.0 server using the IP address and network settings of the existing production 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 Time-To-Live(TTL) units in the domain name system (DNS) records to expire in 24 hours. Set up round-robin DNS so requests are sent sequentially to the production server and 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 server, and wait for propagation to occur again. When you're sure the new IP has been propagated, turn off the production server. However, use 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 Microsoft® Windows® Load Balancing Service, all you need do is assign the new server the appropriate IP address and bring it onto the network, then take the old production 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. Use Microsoft Windows 2000 Server Performance Monitor or HTTPMon, which will be included on the Windows 2000 Resource Kit companion CD, to track server performance. Performance degradation can alert you to a serious problem. Some suggested items to monitor are processor use, memory use, disk use, and network availability.

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 you can get troubleshooting information from other IIS 5.0 users, such as the newsgroup sponsored by 15seconds.com. In addition, Microsoft provides searchable reference information that may be of help at: http://support.microsoft.com/support/

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

Main Milestone: Deployment Complete

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, users receive the appropriate training, and the operations and support systems are activated.

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

Planning a Web Services Migration Project

Now that you are familiar with the MSF, this section will help you to plan your migration project. It assumes that you'll be migrating from Apache HTTP Server. However, if you're migrating from another Web server or simply upgrading to the latest version of IIS, much of this information might be helpful to you as well.

In the previous sections you have been given 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 section, a topical approach to migration project planning is taken to help you get started with your own planning.

Planning 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 can be, 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 previously, 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. Provided previously was 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 that Company.com used:

Company.com will replace its current UNIX Apache HTTP 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 an enterprise Windows 2000 Server domain model and will begin a scheduled deployment program by the end of January 2000.

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 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 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 Commerce Server 2000 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 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 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.

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.

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

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 http://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 "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 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).

• Web content authoring tools, such as FrontPage.

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

• Test scripts.

• Automated testing tools, which may need to be re-evaluated, especially if the testing team will be changing to different client hardware as part of the migration.

• Test tools, such as Web Capacity Analysis Tool (WCAT), the Web Application Stress Tool, and the IIS 5.0 script 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. This will be one of the most critical decisions made during the entire migration process. Therefore, a thorough examination must be conducted.

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.

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.

Standards Review Policy/Procedure	Issues
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
Maintenance	Preventative maintenance procedures System monitoring policy and tools
Internet etiquette	Guidelines for appropriate network and e-mail use
Network	Escalation procedures for downed links Contacts for network services
Redundant servers	Fault-tolerant servers Load-balancing servers
Security	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

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 Commerce Server 2000. 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

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.

• Consistency of functional specification between the original and new implementations. Consider the end-user experience if pages are served by a randomized alternation of Web servers.

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 Appendix A at the end of this white paper.

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.

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.

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 http://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 Appendix B at the end of this white paper.

Other Tools

Other tools for converting CGI applications, debugging script, transferring data, testing, and more are listed in Appendix B at the end of this white paper.

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 http://www.microsoft.com/catalog/navigation.asp?nv=2&subid=22

.

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 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.

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.

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.

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 http://www.microsoft.com/catalog/default.asp?subid=22.

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

Migration Steps

Once you've completed the planning and preparatory steps you're ready to begin migrating your Web servers to IIS 5.0. This section describes the following steps:

• Assessing hardware requirements and acquiring any new hardware needed for deployment

• Preparing the destination computer by creating partitions, installing Windows 2000 Server with IIS 5.0, and structuring directories

• Migrating Web and File Transfer Protocol (FTP) sites by replicating their content to the destination computer, correcting any problems with the files, and implementing special features

• Replicating Web application files to the destination server, additional steps that might be required to migrate applications to IIS 5.0

• Migrating log files

• Migrating Web server configuration settings

• Securing the new Web server by importing user and group information, setting permissions, installing security certificates, and configuring other security parameters

We will also specifically address the unique issues of migrating to IIS 5.0 from Apache HTTP Server.

Assessing Hardware Requirements

Your first step is to decide what type of hardware to use for the migration, and then obtain it and set it up. There are four different approaches to migration, and each one has a different implication for deployment hardware. This section describes the pros and cons of each approach and the hardware required. Later sections tell you how to perform the migration steps mentioned here.

1. Migrate to a clean installation of Windows 2000 Server and IIS 5.0. The ideal approach to migration is to perform a clean installation of Windows 2000 Server and IIS 5.0 on a computer other than the production Web server. Migrate settings, content, and applications from the production Web server to the new IIS 5.0 server. Test and debug the new server before deploying it and taking the old production Web server offline.

   Hardware needed: A second computer is required, in addition to the existing production Web server.

   Pros: You can put new, updated hardware in place at the same time you perform the migration. You also avoid taking your production Web server offline until the new server is tested and deployed. Following deployment you can use the original server as a backup, in case problems arise with the new server that didn't appear during testing.

   Cons: You'll need to purchase the second computer, if you don't have a spare to use. However, the cost can be offset by the time saved conducting the migration and fixing problems.

   Recommendation: This is the ideal approach because it is the least likely to result in unforeseen problems, such DLL conflicts. Because of the difficulty in conducting a cross-platform migration on a single computer, this is the best approach recommend for migrating a UNIX-based Web server to IIS 5.0.

2. Migrate a duplicate of a Windows NT–based Web server. Some people prefer this approach when they have a spare Web server already running Microsoft Windows NT: On the second computer (the "spare"), install the same software as exists on the production Web server, and then use the Windows 2000 Server Setup Wizard in order to upgrade to Windows 2000 Server and IIS 5.0. Migrate configuration settings, content, and applications to the new Web server. Test and debug the new server before deploying it and taking the old production Web server offline.

   Hardware needed: A second computer is required, in addition to the existing production Web server.

   Pros: You can opt to put new, updated hardware in place at the same time you perform the migration. You also avoid taking your production Web server offline until the new server is tested and deployed. Following deployment you can use the original server as a backup, in case problems arise with the new server that didn't appear during testing.

   Cons: You might need new hardware if you don't have a spare server. But if you're buying new hardware, you'd be better off to install Windows 2000 and IIS 5.0 on it, as in the first approach.

   Recommendation: For migrating from another Windows NT–based Web server, this approach is perfectly fine, and all of the testing we've done so far has not revealed any problems with it. However, my preference is to reformat the hard drive and migrate to a clean installation of Windows 2000 and IIS 5.0.

3. Migrate a mirror of a Windows NT–based Web server. This is another approach many people use when migrating from a computer running Windows NT: Create a mirror image of the current production Web server (operating system, software, configuration settings, and content) on a second computer. Then use the Windows 2000 Server Setup Wizard to upgrade it to Windows 2000 Server and IIS 5.0. Migrate Web configuration settings, content, and applications to the new Web server. Test and debug the new server before deploying it and taking the old production Web server offline.

   Hardware needed: For this approach to work, the new hardware must exactly duplicate the existing server.

   Pros: You avoid taking your production Web server offline until the new server is deployed. Following deployment, if problems arise with the new server that didn't appear during testing, you can use the original server as a backup.

   Cons: Because the hardware on the new system must exactly duplicate the original server, you can't upgrade your hardware at the same time you migrate or upgrade the Web server.

   Recommendation: This method is more efficient than the last one because you don't have the extra step of separately migrating configuration and content. It's fine if you don't need to upgrade your hardware, and is far less risky than the next approach.

4. Migrate the production Web server. Here's an approach some people use for migrating non-mission-critical Web servers when they have a limited (or nonexistent) hardware budget: Take the production Web server offline. Back up everything! If it's already running Windows NT Server, use the Windows 2000 Server Setup Wizard to upgrade the server to Windows 2000 Server with IIS 5.0. For a new installation, install Windows 2000 Server on a primary disk partition. This might require reformatting and repartitioning the hard disk. Migrate Web configuration settings, content, and applications to IIS 'in place' on the production Web server. Test and debug the server before deploying it.

   Hardware needed: No new hardware is required.

   Pros: There is no hardware cost.

   Cons: Migrating a production Web server is extremely risky. You must take the server offline, and it will not be available to users until you complete all migration tasks, testing, and debugging.

   Recommendation: This method i