Export (0) Print
Expand All
Expand Minimize
3 out of 18 rated this helpful - Rate this topic

Migrating Linux and Apache Server to Windows 2000 and Internet Information Services

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.

lapa02

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.

      lapa03

    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.

    Bb742434.lapa04(en-us,TechNet.10).gif

  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.

Bb742434.lapa05(en-us,TechNet.10).gif

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 is not recommended, unless you can afford to have your Web server offline for an indeterminate length of time.

Preparing the Destination Server

Once you've acquired and set up the necessary hardware, you need to prepare the destination server for migration by installing Windows 2000 Server and IIS 5.0, configuring directories, and installing tools and utilities. Because it's my preference, these steps assume that you've decided to migrate to a clean installation of Windows 2000 and IIS 5.0.

Note: The destinationserver (sometimes called the target server) is running Windows 2000 Server with IIS 5.0, and the sourceserver is running the Web server software you plan to migrate. While source and destination servers could exist on the same physical computer, I do not recommend conducting a migration on a single computer. (The issues involved are described in the previous section, Assessing Hardware Requirements.) Therefore, in this discussion, source and destination servers are assumed to exist on separate computers.

  1. Back up the source server. Before you begin, create a backup file of all source server configuration settings, as well as files, applications, utilities, and other software used by your Web and FTP sites. Keep this file on a computer that's not involved in the migration.

  2. Identify items to migrate. Decide which items to migrate from the source server. Note any applications and scripts you need to modify in order for them to run on IIS 5.0. To migrate these items, you need to transfer them to a development computer for modification, then to a test server for testing, and finally to the production Web server for deployment.

  3. Estimate disk space and partition requirements. Estimate the total disk space needed for data, files, applications, and server software on the destination computer. For each item, make a note of the disk partition on which it will reside (some considerations are discussed next). Make sure the destination computer has sufficient hard disk space for your requirements.

  4. Install Windows 2000 Server and IIS 5.0. Install Windows 2000 Server and IIS 5.0 on the destination computer. When installing to a new computer, choose the clean install option. By default, Windows 2000 installs as a file server. If you are using this server primarily as a Web server, you should install it as an application server.

During setup you create disk partitions and specify the file format for the primary, or system, partition onto which Windows 2000 Server will be installed. Be sure to allocate sufficient space in each partition for the content or system files it will hold. The following are some other issues to consider when creating disk partitions and specifying file format:

  • Security To implement the highest level of security, format the partition onto which you install Windows 2000 Server as NTFS file system (NTFS).

    For security reasons, it's also a good idea to install the Windows 2000 Server and IIS 5.0 system software on a separate partition from the Web and FTP site content and applications. The following configuration should be fine in most cases:

    Drive C: Allocate 1.5 to 2 GB of disk space for Windows 2000 Server and IIS 5.0 executables.

    Drive D: Allocate 1 to 2 GB of disk space for the IIS root and Web site directories.

    Drive E: Allocate sufficient disk space to contain remaining software and content for your server.

  • Access from UNIX-based computers Keep in mind that only Windows NT– or Windows 2000–based computers can natively access data and files stored on NTFS partitions. Therefore, when using NTFS in a mixed environment, you might need to take additional steps to make sure files are available to UNIX-based computers. There are a couple of ways to do this. You can use Microsoft® Network File Sharing (NFS) client and server components that run on Windows 2000 and that support cross-platform file sharing. These and other useful tools and utilities are available as part of Windows NT Services for UNIX.

    Likewise the SAMBA shareware application suite allows UNIX clients to access Windows-based file systems. It also allows Windows-based clients to access files and printers on UNIX, NetWare, OS/2, or VMS servers that support the Server Message Block (SMB) protocol.

For more information about creating and configuring Windows 2000 operating system partitions and directories, see the Windows 2000 Server online product documentation.

  1. Configure Windows 2000 Server. After installation, the next step is to configure Windows 2000 Server networking and security, and any additional services. For references on setup and administration, see the Windows 2000 Server online product documentation.

  2. Structure Web and FTP site directories. When you install IIS 5.0 for the first time, the Windows 2000 Server setup program creates a Web server directory structure in Windows Explorer at c:\Inetpub\wwwroot\. This is where actual Web site content and application files are stored. IIS 5.0 also creates a Default Web Site in the IIS snap-in of the Microsoft Management Console (MMC). It points to the content stored in the root directory and provides configuration settings (properties) for the Web site and its associated files. IIS 5.0 gives the Default Web Site the same name as the computer running IIS 5.0, unless the computer Internet Protocol (IP) address is registered with a different name on the Internet or your corporate network.

    The Wwwroot Directory in Windows Explorer and the Default Web Site in the IIS Snap-in

    You might be able to use the default directory structure as it is, or you might want to make some modifications to preserve paths (also called pathnames) within your content and application files. As much as possible, try to replicate the directory structure and names used on the source server. This minimizes broken links and the need to update URLs and pathnames within files following migration.

    Note: The Default Web Site in the IIS snap-in points to the IIS 5.0 online product documentation, supporting code, and application samples (accessible from the IIS snap-in Help menu, or by typing http://localhost/ in the address bar of your browser). If you delete the Default Web Site, you will no longer be able to open these items. Also, be aware that the Default Web Site is assigned port 80 by default. When you create a new Web site in the IIS snap-in, it also will be assigned port 80 by default. In order to continue accessing the documentation, you must change the port number of any new Web site you create to something besides 80 so that it doesn't conflict with the Default Web Site. To avoid these problems, it is best to use the Default Web Site to manage your Web site, rather than creating a new one. For more information, see the "Adding Sites" topic in the IIS 5.0 online product documentation.

    Storing Content outside the Web Server Root Directory

    The Virtual Directory feature of the IIS 5.0 snap-in allows you to publish content to your Web and FTP sites that is stored outside of the Web server root directory tree (c:\Inetpub\wwwroot) in Windows Explorer. Content—HTML files, scripts, images, and other files—can be stored in any Microsoft Windows directory on the local computer or another computer on your network. The only restriction is that the network drive containing the directory must be in the same Windows 2000 Server Domain as the computer running IIS 5.0. For more information about virtual directories, see the "Creating Virtual Directories" topic in the IIS 5.0 online product documentation.

  3. Install tools and utilities. Next, install tools and utilities on the destination server. These include all of the items you listed during the planning phase that must reside on the new server. If you're migrating from UNIX, you'll want to obtain and install the Windows 2000 Server counterparts of UNIX tools and utilities. Many of these are available on the Microsoft Windows 2000 Resource Kit companion CD. Others are available with Microsoft Windows Services for UNIX.

    You'll also want to obtain and install the appropriate script interpreters (also called scripting engines) to run applications written as scripts. IIS supports any scripting language for which you have installed a script interpreter that follows the Active Scripting standard. For ASP applications, IIS natively supports Microsoft Visual Basic Scripting Edition (VBScript) and Microsoft JScript, so you don't need to install their interpreters. Active Scripting interpreters for Perl 5.0 and Regina REXX are available through third-party developers. TCL/Tk, Python, and REXX script interpreters that are compatible with Microsoft Win32® are available from third-party sources. In most cases, you should install the script interpreter in the Web server root directory (c:\Inetpub\wwwroot) and set appropriate NTFS and IIS 5.0 permissions.

Migrating Web and FTP Sites

Next you migrate Web and FTP sites. This section describes the steps involved in doing this, including replicating content, creating virtual directories, correcting file formatting problems, repairing broken hyperlinks, and implementing special features, such as content expiration, footers, and server-side includes.

Replicating Windows-Based Files

You can copy files and directories between two Windows-based computers by using FTP, a serial connection, or the rcp utility that comes with the Windows 2000 operating system, or by creating a shared directory and copying the files across your local area network (LAN).

Keep in mind that a simple file copy and paste operation does not preserve some file data, such as security configuration, hyperlinks, and share information. The following paragraphs discuss some methods of preserving file data.

Preserving Permissions and Audit Settings

To copy files while retaining current Windows permissions and audit settings, you can use the XCopy utility that comes with Windows 2000 Server, by typing the following at the command prompt:

XCopy <current>:\<dir> <new>:\<dir> /o /a /s

For more information about using this tool, see the Windows 2000 Server online product documentation.

Preserving Hyperlinks and Web Structure

Both Microsoft FrontPage® and Microsoft Visual InterDev® Web development systems can replicate Web sites from one Windows-based computer to another, while preserving site directory structure and hyperlinks. However, you will need to recreate virtual paths, as these tools don't import this information.

Preserving Share Information

Copying files and directories is simple enough; however, share information isn't maintained in Windows directories, but rather in the registry, under LanmanServer. To preserve share information, you must also replicate this registry information from the source server currently hosting the shared files and directories, to the destination computer, as follows:

Note: The action described next will destroy any existing shares on the destination computer. Be sure to back up the registry before you begin.

Using the following registry key, save the source computer registry settings for shares to a file. Use Regedt32.exe, and not Regedit.exe, to edit the registry.

HKEY_LOCAL_MACHINE
\System
\CurrentControlSet
\Services
\LanmanServer
\Shares

Copy the resulting settings file to the destination computer and then use the following registry key to restore the share settings to the destination server from this file. The settings will take effect after you restart the computer.

HKEY_LOCAL_MACHINE
\System
\CurrentControlSet
\Services
\LanmanServer
\Shares

Caution: Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Replicating UNIX-Based Files

You can copy files and directories from a UNIX-based computer onto disks or tape media, or move them across a network connection by using FTP. To transfer an entire Web directory tree in one file, you can use tar for concatenating files and directories, compress them with one of several available utilities, and then use recursive FTP to transfer them to Windows 2000 Server. SAMBA is also useful for transferring files between computers running UNIX and Windows operating systems.

You can also copy files across a network by using the Windows 2000 rcp client to access a UNIX computer that's running the rcp daemon called rshd (Remote Shell Daemon). With rcp you can specify security parameters, as well as recursively copy files and directories between source and destination computers. In this case, the name of the Windows 2000 Server computer must appear in the .rmhosts file on the UNIX computer. For more information, see the "rcp" topic in the Windows 2000 Server online product documentation.

Note: MS-DOS® and Windows files use a carriage return and line feed character to mark the end of each line, while UNIX files use only a line feed character. The Windows 2000 rcp client and standard ftp clients automatically make this conversion for you when run in ASCII transfer mode (the default). However, inmost instances, Windows 2000 software and IIS will work as desired if the lline feed characters are included.

Once the files are copied to Windows 2000 Server, you can separate any concatenated directories and files by using Tar.exe for Win32, or you can use WinZip to separate and uncompress them. WinZip provides built-in support for TAR, gzip, UNIX compress, UUencode, BinHex, and Multipurpose Internet Mail Extensions (MIME). Then you can move the files into the appropriate Web server directory, which is c:\Inetpub\wwwroot by default. For applications, it's particularly important to retain the original directory structure.

To obtain a public domain copy of Tar.exe for Win32, go to http://www.acs.oakland.edu/ and use the search term "nttar.zip."

Ws_ftp, a tool that performs recursive FTP, is available at http://www.shareware.com/.

To download an evaluation version of WinZip, see http://www.winzip.com/.

Items to Note about Windows File Systems

Here are a few items you might want to note about Windows file systems if you've been accustomed to working in a UNIX environment.

  • On a Windows File Allocation Table (FAT) file system, Write access to a file is equivalent to full access. To protect data shared on a FAT file system, share it as a read-only resource. NTFS provides more security options for protecting data and is generally recommended over FAT. For more information about NTFS security, see the Windows 2000 Server online product documentation.

  • Because Windows FAT file systems were designed around single-user computers, they don't support the concept of a file owner or file group. However, the NTFS file system allows you to specify a file owner, which can be either an individual or a group.

  • Windows file systems do not support file links (either hard or symbolic links), but rather use a single-name/single-file concept with no support for multiple directory entries referring to the same file.

    Note: This only applies to local machine file systems where the Distributed File System (DFS) feature has not been enabled. When DFS is implemented across a single or multiple servers, these features are accessible.

Converting UNIX File Names and Pathnames

When you migrate files and directories from a UNIX-based Web server, you need to edit file names and pathnames (called paths in Windows) so that they adhere to Windows conventions. You also need to edit any file names and pathnames within UNIX application files in order to run them on Windows 2000 Server. If you don't make these corrections, file and hyperlink references might malfunction, and in some cases files could be overwritten.

Conventions are slightly different between the Windows FAT and NTFS file systems. While for security reasons you will want to use NTFS as much as possible, there are cases where you might need to use FAT for cross-platform file sharing. The issues involved with both systems are described below.

  • File Name and Extension Length UNIX systems support long file names and file extensions of any length. Depending on the method you use, when you copy a UNIX file or directory to a Windows file system, Windows might truncate a long file name or extension using the Microsoft MS-DOS 8.3 convention.

  • Case Sensitivity UNIX file names are case sensitive. Windows FAT file names are not case sensitive, and Windows NTFS file names are "case aware." In other words, NTFS preserves case, but doesn't use it in some functions, such as indexing. Also, in UNIX you can have two different files in the same directory with names distinguished only by case. For example, in any given directory you could have two different files, one named MyFile and the other named myfile.

  • Illegal Characters The following characters are supported in UNIX-style file names, but are not permitted in Windows file or directory names:

    \ : * ? " < > |

  • Directory Separators UNIX pathnames use the forward slash (/) as a directory separator, and Windows paths use the backslash (\).

  • Directory Hierarchy The UNIX file system appears to be a single directory hierarchy whereas Windows storage is divided into one or more physical or virtual disk drives with a directory hierarchy on each.

    Note: This only applies to local machine file systems where the Distributed File System (DFS) feature has not been enabled. When DFS is implemented across a single or multiple servers, these features are accessible.

Completing Web Site Migration

This section describes some additional steps you might need to take when migrating Web sites in order to restore hyperlinks, set up user Web sites, and replicate (or add) special features such as server-side includes, redirects, and directory indexes.

Repairing Hyperlinks

When you migrate Web pages, you need to find and repair any hyperlinks within them that were broken due to changes you might have made in the original Web site directory structure. You can use FrontPage features for testing and repairing hyperlinks, not only for internal URLs, but for those referring to external sites on the Internet as well.

Note: It is not recommended that you install the FrontPage client on the same computer as IIS 5.0. Instead, use FrontPage on a development computer to check and repair hyperlinks. Then publish the files to the computer running IIS 5.0, using the Web publishing features of FrontPage.

Setting Up User Web Sites

IIS 5.0 provides the following options for implementing user Web sites, which are common in most Internet service provider (ISP) and volume hosting environments:

  • Host Headers Implementing the HTTP 1.1 host header standard, you can create multiple Web sites on a single IIS server that share the same IP address. For browsers that do not support the HTTP 1.1 standard, IIS displays the home page for the Default Web Site and can be configured to send a cookie that automatically redirects users to the selected site on their next visit. For this reason, it is recommended that ISPs use the Default Web Site for their Web site, rather than for a customer Web site. This Web site can then display links to customer Web sites.

  • IP Addressing You can create multiple Web sites by assigning each one a unique IP address.

  • Unique Port Numbers You can create multiple Web sites by assigning each one a unique port number. For sites using something other than port 80, which is the default, users must append the port number to the URL to access the site. For example, http://www.microsoft.com/IIS:82 would access a Web site named IIS that uses port 82.

For more information about implementing these methods, see the "Web and FTP Sites" and "Name Resolution" topics in the IIS 5.0 online product documentation.

Implementing Special Web Features

IIS 5.0 supports many popular Web site features, such as directory browsing and indexing, document footers, and server-side includes. The following paragraphs describe some features you might want to implement on your Web sites.

  • Directory Browsing and Indexing You can enable directory browsing and indexing on the Home Directory tab of Web Site Properties. (Note: This configuration could represent a potential security loophole.)

  • Document Footers You can specify a document footer on the Enable Document Footer tab of Web Site Properties. For more information about document footers, see the "Adding a Footer to Web Pages" topic in the IIS 5.0 online product documentation.

  • Dynamically Updated Content For content that must be frequently updated, you can generate dynamic Web pages by using ASP and HTML templates. IIS 5.0 builds pages on-the-fly from content that is dynamically extracted from a database.

  • Personalized Content By using Dynamic HTML (DHTML) on the client or the Browser Capabilities Component you can detect user browser capabilities to provide personalized content based on the user environment. For more information, see the "Client Capabilities" topic in the IIS 5.0 section of the SDK documentation on MSDN.

  • Redirection (HTTP redirect) You can specify redirection from a Web site to another URL on the Home Directory tab of Web Site Properties.

  • Server-Side Includes IIS 5.0 supports server-side includes. A Web page that has included information can have the .stm or shtml file name extension. The virtual directory containing the .stm files must have either script or execute permissions enabled. This is a nice feature in that it allows the use of Server-Side Includes where others may use Active Server Pages. This greatly eases the conversion process.

  • Time-Sensitive Content To direct the user's browser to expire cached content at a specific date and time, you can enable content expiration on the HTTP Headers tab of Web Site Properties.

Completing FTP Site Migration

Here are a few steps you can take to reproduce (or add) special FTP site features.

  • Creating User Directories To have a user automatically placed in their own FTP directory when logging on, create a virtual FTP directory with the same name as the user.

  • Creating Welcome Messages On the Messages tab of FTP Site Properties, you can create a welcome message that will be displayed to users when they enter the FTP site.

Replicating and Configuring Applications

Application files are a special case. Rather than copying them directly to the new IIS 5.0 server, application files should be transferred to a development computer for any necessary editing or rewriting, and then to a test computer for testing and debugging. When you're ready to deploy the application on the new IIS 5.0 server, follow the instructions given in the "Configuring Applications" topic of the IIS 5.0 online product documentation.

The TechNet article, "Migrating Web Applications to IIS 5.0: Choosing an Approach," describes your options for migrating a CGI application to IIS 5.0. You can leave it as a CGI and make relatively minor changes so it runs on IIS 5.0. Or you can rewrite it as an ISAPI extension or an ASP application. The pros and cons of each approach are discussed in terms of development costs and server resources.

When porting their sites from Red Hat Linux to Microsoft Windows® 2000, Company.com made the decision to continue running their Perl/CGI scripts, and make the necessary modifications to them to ensure identical functionality under IIS 5.0 as opposed to achieving to converting everything to Active Server Pages. This helped increase the speed at which the migration could be completed as all Company.com scripts did not need to be rewritten as Active Server Pages.

After installing ActiveState's Perl and its required modules, several changes needed to be made to the scripts before they would operate in the same manner under Microsoft Windows 2000 and IIS 5.0 as they did under Red Hat Linux and Apache HTTP Server.

  1. Any use, include, require, or open commands needed the full path of the file being read or written to. This is due to the fact that \ is an escape character in Perl, so file paths must either be "C:\\Directory\\file.txt" escaped or within 'D:\directory\file.txt' single quotes (non-interpreted string).

  2. All print "Content-type…" statements had to be removed from scripts executed by server-side include calls. IIS 5.0 assumes that the server-side includes results are browser displayable. The Content-type header must stay in all cgi's called directly by the browser.

  3. All system and exec calls must be located. If making the call from the command line produces a printed response, the same call made incorrectly from within a script will print the result to the browser. The call may need to be modified so that no undesirable text is displayed in the browser.

Migrating Log Files

IIS 5.0 supports the W3C Extended Logging Format, and you can migrate any compliant log file to IIS 5.0. IIS 5.0 logs are stored in ASCII (text) files. If you want to preserve logging information from the source server, you can copy ASCII data from your log files to the IIS 5.0 log files.

IIS 5.0 provides several features you can use to customize logged information, and you can either log to a text file or to an Open Database Connectivity (ODBC) Data Source Name (DSN) for dynamic evaluation. For more information about logging, see the "Logging Site Activity" topic in the IIS 5.0 online product documentation.

Migrating Configuration Settings

Web servers—whether they are IIS 5.0, Netscape, Apache, or some other type—perform many of the same basic functions, and therefore offer many similar configuration options. However, the way in which you configure a server and the way settings are named can vary a great deal from one server to the next. This section describes the IIS user interface. Along with this, there is specific information comparing IIS configuration settings with settings on Apache HTTP Server.

IIS 5.0 uses property sheets to provide a GUI for server configuration. You open property sheets from the IIS 5.0 snap-in of the MMC by right-clicking the item you want to configure, and then clicking Properties. For information about IIS 5.0 configuration options, see the "Server Administration" topic in the IIS 5.0 online product documentation. As mentioned below, the administrator also has the option of using a command-line utility, or even writing custom scripts that use the Windows Script Host, to configure IIS 5.0.

Using the IIS 5.0 metabase, you can configure the server with greater granularity at the computer, Web site, virtual directory, directory, and file level. For more information, see the "Introduction to the IIS Metabase" topic in the IIS 5.0 online product documentation.

If you're new to Windows or IIS, here are a few tips:

  • When in doubt, right-click. When you're running Windows, right-clicking a window or an object reveals a menu of useful operations. For example, in the IIS snap-in, right-click an object such as the Administration Web Site or Default Web Site, and then click Properties. Then at the top of the dialog box, click the tab that corresponds to the configuration options you want to set.

  • If you get stuck, click the Help button. Click the Help button that appears in most dialog boxes to open a topic specific to that dialog box. You can also open the in-depth IIS 5.0 online product documentation as follows: In the left pane of the IIS snap-in window, click the Default Web Site and verify that it's running. Then at the top of the IIS snap-in window, click Help, and then click Help on Internet Information Services. From Windows 2000 Server Help, you can open IIS Help from within the "Internet Information Services" topic.

    Remember that the IIS snap-in isn't Windows Explorer. Although the IIS snap-in and Windows Explorer look very similar, you use them for different purposes. You configure Web site, FTP site, and Web administration properties in the IIS snap-in. You can also create virtual directories for a Web or FTP site in the IIS snap-in, but only in Windows Explorer can you actually manage files and directories, performing operations such as:

    • Copying files and directories (or folders) to your Web and FTP site directories

    • Creating, moving, and deleting files and directories

    • Setting NTFS permissions for files and directories

    • Defining network file sharing for files and directories

Configure IIS 5.0 to recognize both Windows and UNIX-style home page names. To make migrating UNIX Web sites easier, specify the following five home page names in IIS Web Site Properties:

  • Index.htm

  • Index.html

  • Default.htm

  • Default.html

  • Default.asp

This will cover nearly all cases for both UNIX and Windows Web sites.

Note: IIS 5.0 does not support the index.shtml as a default home page. However, this can be easily overcome by having a recognized home page type redirect to the index.shtml home page.

Securing the Server

Once you've migrated Web content and applications to IIS 5.0, you need to configure security. This section discusses the basics of securing your Web server: migrating user and group accounts, migrating certificates, setting NTFS file and directory permissions, and setting IIS 5.0 permissions. For more in-depth information, see the security topics in the IIS 5.0 and Windows 2000 Server online product documentation. For additional details on security, see http://www.microsoft.com/technet/security/default.mspx and http://msdn.microsoft.com/nhp/Default.asp?contentid=28001191.

Migrating Users and Groups

An important component of migration is transferring the identities and passwords of system users and groups to the new server. To make this easier, you can use Addusers.exe, a utility for adding user accounts to Windows 2000 Server, included on the Microsoft Windows 2000 Resource Kit companion CD.

You also need to configure security on the user and group accounts, and you might want to create new group identities to enhance security. For information about doing this, see the Windows 2000 Server online product documentation.

Setting NTFS Permissions

To protect your Web server from unwanted intrusions, you can set access permissions by user and group account for each file or directory stored in the Windows NTFS file system. Permissions set on a directory apply to each file within the directory. However, if a file within the directory has more restrictive settings, the more restrictive settings apply. For information about setting NTFS permissions, see the "Setting NTFS Permissions for a Directory or File" topic in the IIS 5.0 online product documentation. Note that you cannot set these access permissions for files and directories stored in a FAT file system.

The following are a few guidelines for configuring NTFS permissions for user and group accounts used by IIS 5.0:

  • Anonymous User During installation, the IIS 5.0 Web and FTP services are assigned a default user account, called IUSR_computername, for anonymous users. Do not make this account a member of any privileged group.

  • IIS Admin Service Do not give the IIS Admin Service the right to log on as the LocalSystem account.

  • Test It's a good idea to create a Test group account to which you can give enlarged access permissions, such as Write or Execute, needed by application developers and testers.

  • Full Control Only two accounts should be always given NTFS Full Control permissions: LocalSystem and Administrator. On selected files, you might want to also give full control to Owner/Creator.

Setting IIS 5.0 Permissions

You set additional access permissions for Web users in the IIS snap-in. On way to set up basic IIS 5.0 security is using the Permissions Wizard. To start the wizard, in the IIS snap-in select the Web site or directory for which you want to set permissions, click Action on the toolbar, point to All Tasks, and then click Permissions Wizard.

You can also configure security on Web Site property sheets. The following are some rules of thumb for setting IIS 5.0 permissions based on the type of access you want to provide. You might need to implement security differently than described here, depending on the requirements of your particular system. For more information about setting access permissions, see the "Access Control" topic in the IIS 5.0 online product documentation.

Note: If NTFS file and directory access permissions do not match the access permissions set in the IIS snap-in, the more restrictive settings take effect.

  • Web and FTP Site Anonymous Access To protect the information on your computer, restrict access by anonymous users. To do this, in the IIS snap-in deny all access to the anonymous user account, which is IUSR_computername by default. Next, select the specific files and directories under the root to which you want to allow anonymous access and enable the appropriate permissions for the anonymous user account. To override the access restrictions you set at the root level for these files and directories, clear the Allow inheritable permissions from parent to propagate to this object check box.

  • Web and FTP Site Authenticated Access To require users to provide a valid user name and password in order to access a Web or FTP site, in the IIS snap-in disable anonymous access on the Directory Security tab of Web Site Properties or FTP Site Properties. For Web sites, you can then select the type of authentication: Basic, Digest, or integrated Windows authentication. For more information, see the "Authentication" topic in the IIS 5.0 online product documentation.

    By default IIS 5.0 attempts to authenticate Web and FTP users from the local user database. For a Web site, you can change authentication to the domain user database from within the IIS snap-in. For an FTP site, you must modify the DefaultLogonDomain metabase property for the FTP service. To do this, you can use the IIS Administration Script Utility (Adsutil.exe), installed with IIS 5.0, as follows:

    At the command prompt, type:

    adsutil.exe set msftpsvc/DefaultLogonDomain " Name of Your Domain "

    Note: To set up an FTP site where users can upload files, but not see files already uploaded to the site by other users, use virtual directories. Enable Write, but not Read, permission for the user accounts. Give Read permission to the Administrator account only.

Setting Permissions Based on Content

The following table provides guidelines for setting NTFS and IIS 5.0 security on a directory, based on its type of content.

Basic Web Security Settings

Content

Directory Name/Type

NTFS Account

NTFS Directory Permissions

IIS 5.0 Virtual Directory Permissions

Static (.htm, .gif, .jpg, and so on.)

Content

Authenticated Users

Read

Allow Anonymous Access. Allow Read permissions. Directory Browsing okay.

ASP pages

ASP pages

Authenticated Users

Execute

Allow Anonymous Access. Allow Read permissions.
For Execute Permissions, choose Scripts only.
Directory Browsing okay.

ASP-page includes

Includes

Authenticated Users

Execute

Allow Read permissions.

Server-side includes

Content

Authenticated Users

Execute

Disable Anonymous Access.
For Execute Permissions, choose Script or Execute permissions.

CGI scripts

Scripts

Authenticated Users

Execute

Disable Anonymous Access.
For Execute Permissions, choose Scripts only.
Disable Read, Write, and Directory browsing.

ISAPI server extensions

ISAPI Extensions

Authenticated Users

Execute

Disable Anonymous Access.
For Execute Permissions, choose Execute.
Disable Read, Write, and Directory browsing.

ISAPI filters

ISAPI Filters

Authenticated Users

Execute

Disable Anonymous Access.
For Execute Permissions, select Execute.
Disable Read, Write, and Directory browsing.

Executable CGI applications

CGI bin

Authenticated Users

Execute

Disable Anonymous Access.
For Execute Permissions, choose Execute.
Disable Read, Write, and Directory browsing.

Databases

Databases

For remote databases, share out the directory and enable the Guest account for the IIS 5.0 Web service that accesses the share.

Security depends on the database..

Security depends on the database.

Microsoft Component Object Model (COM) and Microsoft Distributed Component Object Model (DCOM) components

Components

 

See note that follows.

Disable Anonymous Access. Enable Execute permissions only.
Disable Read, Write, and Directory browsing.

Downloadable executable files

Downloads

Authenticated Users

Read

Enable Read permissions only. Disable Execute permissions or the file will execute rather than download.

Note: In general, you should place COM and DCOM components in a directory with Execute permissions only. Place COM and DCOM components that need to write to data files in the same directory with the data files and enable both Execute and Write permissions. Be aware that setting Write permissions on a component directory creates the potential for intruders to upload and run an executable file on your server.

To help prevent unauthorized access to a directory

  1. In the IIS snap-in, disable Directory Browsing for that directory and its parent directory.

  2. Set up auditing on the directory so you can monitor any suspicious activity.

Migrating Security Certificates

One approach to migrating security certificates is using the Web Server Certificate Wizard. You can start the wizard in the IIS 5.0 snap-in from the Directory Security tab of Web Site Properties. For information about using the wizard, see the "Using the New Security Task Wizards" topic in the IIS 5.0 online product documentation.

Another approach to migrating a certificate is saving it as a .cer file and copying it to the new Windows 2000 Server. You can install the certificate by double-clicking the .cer file and then using the Web Server Certificate Wizard to bind the certificate to the appropriate Web site. Remember to create a backup copy of server and client certificates and keys in case they become corrupted during the transfer.

Integrating UNIX and Windows 2000 Server Security

Windows 2000 Server and UNIX handle their respective user accounts very differently, complicating security implementation in a mixed environment. If you plan a multi-step approach to migrating from UNIX to the more secure Windows 2000 Server environment, you might find it necessary to use a mixed authentication scheme during the early stages.

Windows 2000 Server implements the Kerberos v5 authentication protocol, a mature Internet security standard, as the default protocol for network authentication. This provides a foundation for authentication interoperability with other platforms, such as UNIX. For more information, see the security topics in the Windows 2000 Server online product documentation.

Migrating from Apache HTTP Server

This section provides additional details about migrating from Apache HTTP Server. It briefly compares Apache with IIS 5.0 and provides tables that match Apache directives to their corresponding IIS 5.0 properties. In this section you will find information about:

  • Comparing Apache and IIS 5.0 Terminology

  • Migrating Apache Directives

  • Migrating Custom Modules

Comparing Apache and IIS 5.0 Terminology

The following are some Apache features that have different names and implementations on IIS 5.0.

Administration Interface

IIS 5.0 properties, which correspond with Apache directives, are contained in the metabase. The most significant difference you'll find between administering Apache and IIS 5.0 is the fact that IIS 5.0 provides graphical tools, the IIS snap-in and the Internet Services Manager (HTML), for configuring the metabase, whereas Apache provides plaintext configuration files, usually httpd.conf, srm.conf, and access.conf, in which you configure directives. It should be noted, however, that IIS 5.0 does include adsutil.vbs to allow command line and scripting administration.

Apache administrators who prefer to work from the command line and to script routine tasks will be happy to know that IIS 5.0 also provides a set of tools for programmatic administration. These tools are described in the "Administering IIS Programmatically" topic in the IIS 5.0 online product documentation.

Apache administrators will also find that Windows 2000 Server commands are similar to familiar UNIX commands. Additional utilities for command-line administration are included with the Windows NT Services for UNIX, a suite of interoperability tools and utilities provided by Microsoft for Windows NT Server and UNIX. At the time of this writing, a version of these tools is under development for Windows 2000.

Security

If you're accustomed to Apache security, be aware that Allow and Deny access permissions are processed in a different order by Windows 2000 Server, producing results you might not expect. Windows 2000 Server always honors a Deny. If you deny permission to a group, and then try to allow permission to an individual member of the group, the member still will not be able to access the resource. These results could change should you change the order of implementation of the deny and allow access permissions. Also note that, unlike in Apache, CGI scripts are contained within the IIS 5.0 Web space. This is because NTFS and IIS 5.0 security sufficiently protects it from attack.

User Directory

You set up individual user Web sites differently on IIS 5.0 than on Apache HTTP Server. With Apache, you add a user to the machine, and then create a <~username> directory for the user's Web pages. The server then responds to the following request by displaying the user's Web pages:

http://www.server.com/<~username>

IIS 5.0 does not automatically create virtual directories for users. Instead, to add a user Web site you create a <username> directory for their files in Windows Explorer, create a virtual directory named <~username> in the IIS 5.0 snap-in, and then point it to the <username> directory.

Virtual Host

The IIS 5.0 counterpart to the Apache Virtual Host is a virtual server. As with Apache virtual hosts, each virtual server in IIS 5.0 has its own domain name and IP address. Apache also includes "name-based" virtual hosts in this category. IIS 5.0 supports this feature in the same manner as Apache, through host header names, but doesn't have a specific term for it.

Alias/Directory Alias

In IIS 5.0 an alias or directory alias is called a virtual directory. In Apache, you use the RedirectMatch/AliasMatch command to map a directory alias to a real directory located on the hard disk, as shown in the following example:

ReditrectMatch /usr/apache/htdocs/newfolder/.

To do the same thing in IIS 5.0, in the IIS snap-in, create a virtual directory and point it to the real directory in Windows Explorer. Using the previous example, the virtual directory would be named "folder," and you would point it to c:\apache\htdocs\newfolder\. Note the change from using forward slashes (/) in the UNIX pathname to backslashes (\) in the Windows path.

Custom Error Messages

In Apache, you provide custom error messages by editing the Error Document and referring to it by using the command:

ErrorDocument 404 http://www.domain.com/404.html

To customize error messages in IIS 5.0, in the IIS snap-in open Properties for the Web site. On the Custom Errors tab, you'll see the location of the error message files. From here, you can map custom error messages to a file or to a URL on the local server.

Redirects

In Apache you use the following .htaccess command to redirect a user to another file:

Redirect /oldfile.html http://www.domain.com/path/to/new/file

There are two ways to implement a redirection in IIS 5.0:

  1. In the IIS snap-in open Properties for the Web site. On the Home Directory tab, select A redirection to a URL, and choose the appropriate options.

  2. Or, put a Default.asp file, containing the following code, in the same directory as the old file:

    Response.Redirect /oldfile.html http://www.domain.com/path/to/new/file

Migrating Apache Directives

This section lists the core Apache HTTP Server 1.3 directives and lists corresponding IIS 5.0 metabase properties, as well as how to configure each property in the IIS snap-in. There is not a one-to-one correspondence between Apache and the IIS 5.0 configuration options: not all IIS 5.0 settings exist on Apache and vice versa. This section does not cover IIS 5.0 properties that have no counterpart in Apache. For in-depth information about IIS 5.0 configuration parameters and metabase properties, see the "Administrator's Reference" topic in the IIS 5.0 online product documentation.

Server Directives

Apache httpd.conf Directives and Corresponding IIS 5.0 Properties

Apache Directive

IIS Metabase Property

IIS Snap-in Configuration

AccessConfig

Not applicable

In IIS 5.0 there is no separate access configuration file.

BindAddress

ServerBindings

For multihoming, IIS 5.0 allows you to specify Virtual Hosts, or virtual servers. To configure a virtual server, right-click a Web site, choose Properties, and then select the Web Site tab. Click the Advanced button on the Web Site tab, and add the correct IP address and Transmission Control Protocol (TCP) port.

CacheNegotiatedDocs

Not applicable

You can specify an expiration date for content in a browser or proxy cache. To configure this setting, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Select the Enable Content Expiration check box and enter expiration dates.

ErrorLog

Not applicable

All errors for the Inetinfo process are logged to the Windows Event Log and do not need to be specified in the Web server configuration.

ExpiresActive

HttpExpires

In IIS 5.0 content expiration is disabled by default. To enable content expiration, right-click a Web site, choose Properties, select the HTTP Headers tab, and then check the Enable Content Expiration check box.

ExpiresDefault

HttpExpires

In IIS 5.0 content expiration is disabled by default. To enable content expiration, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Select the Enable Content Expiration check box, and then set the parameters.

Header

HttpCustomHeaders

To create a custom header, right-click a Web site, choose Properties, and then select the HTTP Headers tab. In the Custom HTTP Headers box, click Add, and then type a name and a value for the header.

HostnameLookups

EnableReverseDNS

IIS 5.0 log files capture the IP addresses of Web site visitors. To look up the host name of a given IP address, enable the metabase property EnableReverseDns. To set IP address restrictions, right-click a Web site, click Properties, click the Directory Security tab, and then click the Edit button in the IP Address and Domain Name Restrictions box.
Note: Enabling this feature may impact system performance.

IdentityCheck

LogExtFileUserName

To log the identity of each Web site visitor, right-click a Web site, click Properties, and then click the Web Site tab. Select the Enable Logging check box, and then click Properties. Click the Extended Properties tab, and then select the User Name check box.

<IfDefine>

Not applicable

 

Include

Not applicable

This directive is not needed in IIS 5.0.

KeepAlive

AllowKeepAlive, MaxConnections

In IIS 5.0, HTTP Keep-Alives are enabled by default. To disable Keep-Alives, right-click a Web site, and choose Properties. On the Web Site property sheet, clear the HTTP Keep-Alives Enabled check box. You set the maximum number of connections and the connection time-out in this location as well.

KeepAliveTimeout

Connection Timeout

To set the Keep-Alive time-out, right-click a Web site and then choose Properties. In the Connections box on the Web Site property sheet, select the Limited To radio button and, in the Connection Timeout box, specify the number of seconds you want before an idle connection times out.

Listen

ServerBindings

IIS 5.0 allows you to specify a port for name-based virtual hosts. To configure this setting, right-click a Web site and then choose Properties. On the Web Site property sheet, click the Advanced button, and then enter the TCP port number.

ListenBacklog

ServerListenBacklog

This is a service-level property, and it cannot be configured from the MMC. However, it can be administered at the service level instead of at the site level.

MaxClients

MaxConnections

To configure this property, right-click a Web site, choose Properties, and then select the Web Site tab. Select the Unlimited or the Limited To radio button. For limited connections, in the Connection Timeout box specify the number of seconds before a connection should time out.

MaxKeepAliveRequests

Not applicable

There is no equivalent in IIS 5.0.

MaxRequestsPerChild

Not applicable

IIS 5.0 uses a limited number of processes, and there is no need to set the maximum number of requests per child process as there is with Apache.

Min/MaxSpareServers

Not applicable

IIS 5.0 uses a limited number of processes, and there is no need to account for this number.

NameVirtualHost

ServerBindings

An Apache virtual host corresponds to an IIS 5.0 Web site. In IIS 5.0 you can create virtual hosts either by using multiple IP addresses or by using a single IP address and HTTP 1.1 Host Header Names. To create a virtual host with a unique IP address, right-click a Web site, choose Properties, and then select the Web Site tab. Click the Advanced button and specify the IP address. To specify a host header name for a name-based virtual host, right-click a Web site, and then choose Properties. On the Web Site property sheet, click the Advanced button and enter the host header name for the IP address you want to use.

PidFile

Not applicable

IIS 5.0 does not offer the option to log its process ID to a file.

Port

ServerBindings

To set the port to which your Web server should listen, right-click a Web site, choose Properties, and then select the Web Site tab. Enter a port number in the TCP Port box.

Proxy Cache Parameters

Not applicable

IIS 5.0 cannot function as a proxy server on its own. Microsoft ISA Server is recommended for use with Windows 2000 Server.

ProxyRequests

Not applicable

See the previous note for Proxy Cache Parameters.

RlimitCPU

CpuLimit

IIS 5.0 has a number of properties that specify CPU throttling parameters. To specify performance parameters in the IIS snap-in, right-click a Web site, choose Properties, click the Performance tab, and then choose the settings you want.

ScoreBoardFile

Not applicable

IIS 5.0 does not have a Scoreboard file.

ServerAdmin

Not applicable

IIS 5.0 does not have a configuration setting for displaying the administrator's name and contact information. You can add this information to your pages by using ASP.

ServerAlias

ServerBindings

IIS 5.0 allows you to specify a host header name for a name-based virtual host. To configure this setting, right-click a Web site, and then choose Properties. On the Web Site property sheet, click the Advanced button and enter the host header name for the IP address you want to use.

ServerName

Not applicable

The host name for your Web server is stored in your Domain Name System (DNS) server and is not required in IIS 5.0 configuration properties. However, you must specify an IP address and HTTP port in order for IIS 5.0 to serve content.

ServerPath

Path

This directive is migrated to the Path property of the IIS Virtual Directory object. This property defines the path from a virtual directory to its corresponding physical directory. You configure this property in the IIS snap-in when you create a new virtual directory, by specifying from which directory the content is to be served.

ServerRoot

Not applicable

IIS 5.0 does not have the same concept of server root and does not have a corresponding property.

ServerType

Not applicable

IIS 5.0 always runs in stand-alone mode. Once IIS 5.0 is started, its process remains in memory and listens to the specified HTTP port. You can't configure IIS 5.0 to dynamically load as with an inetd server on Apache.

StartServers

Not applicable

See the previous note for Min/MaxSpareServers.

Timeout

ConnectionTimeout

You can specify the maximum amount of idle time to elapse before your server drops a connection. To configure this setting, right-click a Web site, choose Properties, and then select the Web Site tab. Enter the maximum timeout value in the Connection Timeout box.

TransferLog

Not applicable

IIS 5.0 does not use a transfer log.

User/Group

Not applicable

When IIS 5.0 is installed, by default it creates the IWAM user account under which the server runs. You must be logged on as an administrator or operator in order to start and stop the IIS 5.0 service, but the process does not retain your permissions.

<VirtualHost>

Not applicable

For each Apache virtual host, you should create a new IIS Web site and apply the directives contained between the <VirtualHost> tags, including server bindings, to the Web site. You might need to correct the IP address of the new Web site, as well.

Resource Configuration

Apache srm.conf Directives and Corresponding IIS 5.0 Properties

Apache Directive

IIS Metabase Property

IIS Snap-in Configuration

AccessFileName

Not applicable

You can refer to these parameters for mapping access configuration information. However, in IIS 5.0 there is no separate access configuration file. IIS 5.0 security is integrated with Windows 2000 security. To limit access to a site or directory by user, you must configure a new user account in the Windows 2000 Server User Manager. You can also classify individuals or groups as "Web site Operators" with limited authority to administer a Web site. They do not have to be Windows 2000 Administrators. To define Web site Operators, in the IIS snap-in right-click a Web site, click Properties, and then click the Operators tab.

AddDescription

Not applicable

There is no corresponding property in IIS 5.0.

AddEncoding

MimeMap

To map a file extension to a MIME type, right-click a Web site, choose Properties, and then select the HTTP Headers tab. In the Mime Map box, click File Types, and then click New Type. Or, to edit an existing MIME type, select a file type in the list, and then click Edit. Type the file extension and associated MIME type in the appropriate boxes.

AddIcon

Not applicable

IIS 5.0 uses the standard Windows 2000 icons when displaying a directory. You cannot specify a substitute icon.

AddLanguage

Not applicable

There is no corresponding property in IIS 5.0.

AddType

MimeMap

To add MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. In the Mime Map box, click File Types, and then click New Type. Type the file extension and the associated MIME type in the appropriate boxes.

Alias

Not applicable

To create a virtual directory, right-click the FTP or Web site, click New, and select Virtual Directory. Use the New Virtual Directory Wizard to complete this task.

AliasMatch

Not applicable

There is no direct equivalent in IIS 5.0 because there is no concept of regular expressions. See the previous note for Alias.

DefaultIcon

Not applicable

Windows 2000 Server offers a standard default icon for file types that do not have a preset icon in the file system.

DefaultType

MimeMap

IIS 5.0 contains a comprehensive list of MIME types. You can add new MIME types to the list should you need to serve a new MIME type. To view default MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Click the File Types button in the MIME Map section of the tab.

DirectoryIndex

EnableDirBrowsing

To allow directory browsing, right-click a Web site, choose Properties, select the Home Directory tab, and then select the Directory Browsing check box. IIS 5.0 does not allow you to specify a prewritten HTML document as a directory index.
Note: This can be accomplished by editing the default page (default.htm, default.aps, etc.) to contain an annotated list of all files in the directory.

DocumentRoot

Path

The Path property of the IIS Root object defines the path from a Web site home directory to its corresponding physical directory. To configure this property in the IIS snap-in, right-click a Web site, choose Properties, and select the Home Directory tab. Then specify the location of the home directory (document root).

ErrorDocument

HttpErrors

To enable custom error messages, right-click a Web site, choose Properties, and then select the Custom Errors tab. In cases where the custom error page is a standard HTML page, you need only copy the file to the IIS 5.0 system in order to complete the migration. In the case of CGI custom errors, you need to test the CGI scripts after moving them to IIS 5.0.

FancyIndexing

Not applicable

IIS 5.0 offers default indexing only.

HeaderName

Not applicable

There is no corresponding property in IIS 5.0.

IndexIgnore

Not applicable

There is no corresponding property in IIS 5.0.

LanguagePriority

Not applicable

There is no corresponding property in IIS 5.0.

MetaDir

Not applicable

You do not need to specify a Meta Directory to serve HTTP header information. To specify custom HTTP headers, right-click a Web site, choose Properties, select the HTTP Headers tab, and then click Add. Specify a header name and value in the appropriate boxes.

MetaSuffix

Not applicable

See the previous note for MetaDir.

ReadmeName

Not applicable

IIS 5.0 does not specify a default name for ReadMe files.

Redirect

HttpRedirect

To redirect a request to another resource, right-click a Web site, choose Properties, select the Home Directory tab, and then select A redirection to a URL. Type the URL in the Redirect to box.

RedirectTemp

HttpRedirect

In IIS 5.0, redirections are temporary by default.

RedirectPermanent

HttpRedirect

To make a redirection permanent, follow the steps previously given for Redirect. In addition, select the A permanent redirection for this resource check box after typing the URL.

ResourceConfig

Not applicable

This information does not directly translate to an IIS 5.0 property.

ScriptAlias

Not applicable

To replicate this information, create a Virtual Directory object using the Apache path information and set the IIS AccessExecute property to TRUE. Any virtual directory can execute scripts when the "Allow Scripts" permission is enabled in the IIS snap-in. To configure this property, right-click a Web site, choose Properties, select the Home Directory tab, and then select the Scripts only or the Scripts and Executables option in the Execute Permissions box.

TypesConfig

MimeMap

To view or configure MIME types, right-click a Web site, choose Properties, and then select the HTTP Headers tab. Click the File Types button in the MIME Map section of the tab.

UserDir

Not applicable

IIS 5.0 does not offer a default directory for ISP user httpd directories. You must create a virtual directory for each user in the IIS snap-in, and then point it to the user directory in Windows Explorer.

Access Configuration

Apache access.conf Directives and Corresponding IIS 5.0 Properties

Apache Directive

IIS 5.0 Metabase Property

IIS Snap-in Configuration

AllowOverride

Not applicable

IIS 5.0 utilizes Windows 2000 security in order to restrict access to a site, so htaccess files are not necessary to control access. Note that in IIS 5.0 you can classify individuals or groups as "Web site Operators" with limited authority to administer a Web site. They do not have to be Windows 2000 Administrators. To define Web site Operators, in the IIS snap-in right-click a Web site, click Properties, and then click the Operators tab.

AuthDBGroupFile

Not applicable

Following migration, you must reconfigure all security on IIS 5.0, including users and groups.

AuthDBUserFile

Not applicable

See previous note for AuthDBGroupFile.

AuthDBMGroupFile

Not applicable

See previous note for AuthDBGroupFile.

AuthDBMUserFile

Not applicable

See previous note for AuthDBGroupFile.

AuthName

Realm

See previous note for AuthDBGroupFile.

AuthType

AuthBasic

In Apache, AuthType is usually set to Basic. The corresponding IIS 5.0 metabase property is AuthBasic. To configure authentication, right-click the virtual directory for which you want to set authentication, click Properties, and then click Directory Security. In the Enable anonymous access and edit the authentication methods for this resource box, click Edit, and then choose an authentication method.

<Directory>

Not applicable

You'll need to migrate defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.

<DirectoryMatch>

Not applicable

You'll need to migrate defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.

<Files>

Not applicable

You'll need to migrate defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.

<FilesMatch>

Not applicable

You'll need to migrate defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.

<Limit>

Not applicable

There is no equivalent in IIS 5.0.

<LimitExcept>

Not applicable

There is no equivalent in IIS 5.0.

<Location>

Not applicable

You'll need to migrate defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.

<LocationMatch>

Not applicable

You'll need to migrate defined directives enclosed in this tag to the corresponding IIS 5.0 virtual directory.

Options, ExecCGI

AccessExecute

You can set most of the IIS 5.0 equivalents of the Options parameter by enabling execution or script permissions for any virtual directory. To do this, in the IIS snap-in right-click the directory for which you want to set permissions, and then click Properties. Click the Home Directory tab, and then set permissions in the Execute Permissions box.

Options Indexes

EnableDirBrowsing

To enable users to view directory contents, in the IIS snap-in right-click the directory for which you want to enable browsing, and then click Properties. Click the Home Directory tab, and then select the Directory browsing check box.

Server status reports

Not applicable

IIS 5.0 does not provide server status reports.

Migrating Custom Modules

In Apache, custom modules extend the capabilities of the Web server. With IIS 5.0, there are a number of options for extending server capabilities. There is no direct way to migrate a custom module, so it must be recreated in IIS 5.0 using one of the following approaches:

  • ASP with COM components or ISAPI DLLs can be written to duplicate most of the desired functionality, such as database or file system access. There are a number of built-in ASP objects to speed this task, such as FileSystemObject, which provides the methods, properties, and collections you use to access the file system.

  • ISAPI filters allow you to implement custom authentication and logging, as well as URL rewriting, or "munging."

For more information about using these technologies, see the IIS 5.0 section of the SDK documentation on MSDN.

Summary

Microsoft Windows 2000 Server and Internet Information Services have been designed with the following things in mind:

  • Reliability and 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 a pool, separate from the Web services. The 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.

These features are the reasons that more and more companies are migrating from Linux and other UNIX-like operating systems to Microsoft Windows 2000 as their Web hosting platform. After reading this white paper, you should have all the information you need to successfully migrate from Linux and Apache HTTP Server to Microsoft Windows 2000 and Internet Information Services 5.0. You should have a good understanding of Microsoft Internet Information Services 5.0 and its features and functionality. You should also be knowledgable about the planning process for a Web site migration using the Microsoft Solutions Framework resulting in the execution of various steps and the creation of planning documents that come out of this framework. You should also have a good understanding of how to migrate the various Apache-specific functionalities to Microsoft Internet Information Services 5.0.

For More Information

For the latest information about Windows 2000 Server and Internet Information Services, visit the Windows 2000 Server Web site. Also refer to the Windows 2000 Server Resource Kit and Deployment Guide.

Appendix A - Company.com

Company.com Environment

Overview

Much of this paper is based on information gained during the migration process of Company.com (fictitious name to conceal the identity of the online company) from Linux and Apache HTTP Server to Microsoft Windows 2000 and IIS 5.0. This Appendix serves to provide more detailed information about the specific configuration of Company.com. It also serves to provide information about a specific migration process and the steps that were taken at Company.com.

Company Profile:

Company.com is a comprehensive investment research Web site that provides free access to professional-level investment and financial tools including advanced charting, research, quotes, news, and technical analysis. Company.com also provides private label financial content and interactive investment tools to Web portals, online brokers, banks, and other financial institutions.

Initial Platform and Tool Configuration:

Initially, the Company.com Web site and the all the data content client Web sites were running on a 500 MHz Single Processor (Pentium III) Dell PowerEdge 4300 server.

The Web Server was Apache 1.2 residing on Red Hat's Linux Operating System.

The CGI scripts were written in Perl (standard UNIX build 5.004) and retrieved data from either flat files or a mySQL database.

Bb742434.lapa01(en-us,TechNet.10).gif

The Business Problem:

Providing a 24*7, STABLE, ROBUST, and EASILY Managed/Administered Web Server Environment

Company.com's online clients include banks, brokerage firms, and Web portals. They expect uninterrupted 24*7 service regardless of the volume of Web traffic at any particular point in time. As Company.com grew and the number of data content clients increased, the job of the Web Server administrator became more complicated and particularly challenging.

The Company.com development team was therefore looking for a solution that would provide:

  • A more stable and robust Web Server platform

  • A load balancing solution integrated with the Web server and the operating system

  • Ease of administration whether done locally or remotely from a browser

  • Lower total cost of ownership and maintenance of its bank of Web servers

The Windows 2000 Solution

Although the Apache Web server on a Linux operating system provided the initial rapid deployment environment for the Company.com Web site and its data content clients, the rapidly growing number of clients proved to be a daunting administration and management task for the development team.

Installing Apache is not an intuitive process. Most other Web servers have installation routines designed to help you set up the server quickly, but Apache requires a tremendous amount of manipulation before it will run. There is no management interface; all of Apache's power is accessed directly through the text-based UNIX shell.

Apache provides rudimentary site management capabilities; no utilities are included to handle content creation or management.

The Apache/Linux combination did not come with any load balancing or failover capabilities, which made adding more servers to the Web farm difficult and time-consuming.

Finally, hosting an Apache/Linux server on the back-end and Windows NT on the desktops at Company.com called for administration, management, and troubleshooting skills for two different operating systems with the corresponding increase in IT staffing needs and skills.

There are currently many Web servers on the market, but given the requirements at Company.com mentioned above, the development team decided to standardize on the Windows 2000 platform. The Windows 2000 Server comes bundled with IIS 5.0 with a number of significant enhancements.

The Migration Steps In Detail:

  • Migration of the hardware environment

Moved from Single Pentium III Dell PowerEdge 4300 to Dual Processor Pentium III Dell PowerEdge 4300

  • Migration of the software environment

Moved from Red Hat Linux to Microsoft Windows 2000 Advanced Server

Moved from Apache Web Server 1.2 to Microsoft IIS 5.0

Moved from standard UNIX build 5.004 to PerlEx (Version 1.1.6) provided by ActiveState

Perl is a natural choice for CGI programming. Unfortunately, in a Web server environment, where a copy of perl.exe needs to be started for each Perl script that is executed, there can be a very significant performance penalty associated with Perl. Like mod_perl on Apache Web servers, PerlEx keeps Perl in memory between invocations of Perl scripts, thus avoiding the need to create expensive perl.exe processes to run your Perl CGI scripts. PerlEx also compiles and stores in memory any Perl scripts that are run by interpreters, so that subsequent requests to the same Perl scripts are instantly fulfilled. A Perl CGI program running under PerlEx also can take advantage of persistent data. For example, a single database connection can be made when a script is first executed, and the resulting database handle can be used in subsequent invocations of the script, thus avoiding having to make further expensive database connections.

Company.com was also using an old version of the GD.pm library, used by Perl for image manipulation. Older versions supported .gif images directly, the newest version of the library does not due to patent issues related to the .gif file format. Changes were made to the scripts using GD::image to manipulate .png images as opposed to .gif. A file conversion is done at the end of the script from .png to .jpg and .gif using the ImageMagick Perl library.

  • Migration of Web site content

An FTP program was used to move the files directly over from the Linux box to the test server. Allaire's HomeSite was used for extended search and replace, and the few hand modifications that had to be made to the .shtml files and .cgi scripts themselves (see below). Microsoft's nmake.exe (shipped with Visual Studio) was used in the place of UNIX OS make utility for compiling Perl libraries and extensions.

  • Things that mapped one to one:

    All static HTML files. The directory structure (from public_html to Inetpub/wwwroot/sites).

  • Things that exist in Linux but not on Windows 2000 and their workarounds:

    The Linux system command, cal, which outputs a preformatted string representing monthly calendars is not available in the Microsoft Windows 2000 operating system without writing a custom PERL script.

    The following is an example output of the cal command:

    Linux_box> % cal

    March 2000

    S M Tu W Th F S

    1 2 3 4

    5 6 7 8 9 10 11

    12 13 14 15 16 17 18

    19 20 21 22 23 24 25

    26 27 28 29 30 31

    We saved two years of output from the Linux box to a text file that can be read in place of an operating system command.

  • Things that needed to be changed:

    The home directories on Apache/Linux which were of the form http://www.Company.com/~homedir. They were changed to the form http://homedir.Company.com on IIS 5.0. This required some changes to the configuration of the individual Web sites and pointers from within Web pages.

  • Specific Perl changes in going from Linux to Microsoft Windows 2000:

When porting their sites from Linux to Microsoft Windows 2000, Company.com made the decision to continue running their Perl/CGI scripts, making the necessary modifications to them as opposed to achieving the same functionality through ASPs.

After installing and configuring Perl and its required modules (Company.com chose to use ActiveState's version of Perl), several changes needed to be made to the scripts themselves, before being functional under IIS 5.0 and Microsoft Windows 2000.

  • Any use, include, require, or open commands require the full path of the file to be read/written. (Note: \ is an escape character in Perl, so file paths must either be "C:\\Directory\\file.txt" escaped or within 'D:\directory\file.txt' single quotes (non-interpreted string)).

  • Remove all print "Content-type…" statements from scripts executed by server-side include calls. IIS assumes that the SSI results are browser displayable. (Note: The Content-type header must stay in all cgi's called directly by the browser.)

  • Locate all system and exec calls. If making the call from the command line produces a printed response, the same call made incorrectly from within a script will print the result to the browser. The call may need to be modified so that no undesirable text is displayed in the browser.

The Final Platform and Configuration:

Total Web Pages Count:

Static HTML pages = 250

CGI Perl scripts = 350

The total number of Web pages that migrated directly = 250 static pages

The total number of Perl Scripts that needed conversion = 350 scripts

Total person-hours to complete conversion = 25 hours

Company.com's current configuration:

Bb742434.lapa06(en-us,TechNet.10).gif

Conclusion:

Company.com is currently running a mirrored load-balanced Web Server configuration that is highly scalable and easily manageable from local or remote stations. Microsoft's Network Load Balancing Services technology included in Windows 2000 Advanced Server provides a much improved configuration and setup environment allowing multiple machines to share the load and deliver more reliable Web services. Company.com has been able to easily add and configure more servers for their Web Server farm as the number of Data & Content customers has steadily increased. The clustering capabilities of Windows 2000 Advanced Server allows smaller companies to provide fault-tolerant, high-availability, mission-critical Web Server farms without the need to immediately purchase high-end load-balancing/switching systems such as Cisco's Local Director or Alteon's Web OS.

The improvements made to IIS 5.0 were also very welcome. There are a number of significant enhancements to indexing, performance, and security. The ease of configuring the servers and the well-integrated server administration tools fulfilled one of the highest requirements of the Company.com development team; the ability to monitor and administer the Web Servers at anytime and from anywhere.

The ease and speed at which the migration from a Linux/Apache platform to Windows 2000 Advanced Server/IIS 5.0 platform took place, underscored the feasibility and practicality of the solution that the Company.com development team chose and implemented.

In fact, Company.com was one of the first companies to migrate completely to Windows 2000 Professional on its desktop and Windows 2000 Advanced Server for its server configuration before the Windows 2000 launch on February 17th, 2000. This was enabled by their participation in the Rapid Deployment Program. Overall, this project was undertaken as part of Company.com's continued commitment to bring the best of breed technologies to the Financial Internet and to the financial industry as a whole.

Appendix B - Additional Resources

Additional Web Server Migration Resources

General IIS and Migration Information

http://www.microsoft.com/technet/iis

The Microsoft IIS TechNet site is a clearinghouse of information, best practices, and resources to help you deploy, maintain, and support IIS.

Migration Tools

IIS Migration Wizard

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

Microsoft Services For UNIX 2.0

Microsoft Windows Services for UNIX 2.0 provides a subset of UNIX utilities and a Korn Shell to give UNIX users and administrators their familiar set of tools and shell environment.

http://www.datafocus.com/products/tk/ds_tkedev.asp

The MKS Toolkit for Developers 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.

http://www.shareware.com/

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

Books on Migration and Integration

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

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

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

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

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

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

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

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

Planning and Testing Information

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

http://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

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

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

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

The following test tools are included on the Microsoft Windows 2000 Resource Kit companion CD.

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

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

  • HTTP Monitoring Tool monitors HTTP activity on the server.

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

General Server Administration Books and Training

Inside Windows 2000, Third Edition, by David A. Solomon and Mark E. Russinovich, 2000, Redmond: Microsoft Press.

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

http://www.microsoft.com/technet/itsolutions/msf/default.mspx

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

http://www.microsoft.com/trainingandservices/default.asp?PageID=training&name=course

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

Application Migration Tools

http://msdn.microsoft.com/developer/sdk/

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

http://msdn.microsoft.com/scripting/

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

http://www.activestate.com/

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

http://www.microsoft.com/windows/sfu/productinfo/overview/default.asp

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

http://www.datafocus.com/

This Porting Guide by DataFocus Inc. describes how to use Nutcracker to migrate UNIX and X/Motif applications to Windows 2000, Windows NT, and Microsoft Windows 95 as native Win32 applications. Datafocus also owns the MKS Toolkit, which provides many utilities, such as htdiff, htsplit, URL, and Web, to help you automate Web development and maintenance tasks. The Toolkit includes a version of Perl, as well as Pscript, an Active Scripting interpreter that allows you to use PerlScript code in an ASP page.

http://www.python.org/windows/

Provides Python language products for the Windows operating system.

http://www.python.org/windows/

Provides Tcl scripting language products for the Windows operating system.

http://cgi-lib.berkeley.edu/

Provides information about the Cgi-lib.pl library.

Server Administration and Interoperation Tools

http://www.microsoft.com/ntserver/techresources/interop/unix/sfu.asp

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

http://www.microsoft.com/ntserver/techresources/interop/unix/WindowsNTUNIX.asp

This white paper lists Microsoft interoperation initiatives and partners.

http://www.netmanage.com/

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

http://virtunix.itribe.net/

Windows versions of popular UNIX tools.

http://www.shareware.com/

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

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.