Lesson 1: A Roadmap for Deploying Exchange 2000 Server | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

Infrastructure deployment projects, by nature, are highly visible in the organization. If you follow the rules and approach them with a clear understanding of the tasks and responsibilities that they entail, you will be able to deliver outstanding results. The MSF can help you. It divides infrastructure projects into the four specific phases of envisioning, planning, developing, and deploying (Figure 2.1). Don’t let the names puzzle you. Microsoft created MSF to streamline the management of software development projects, and that’s where these names come from. Envisioning is synonymous with project preparation. Planning stands for developing the functional specifications and deployment concepts, which are verified and approved during the development phase. You may also consider this part the verification phase. Deployment, of course, concludes the project. MSF has proven successful in large-scale projects, but its models work well on a small scale, too.

Figure 2.1 - The life cycle of a deployment project

This lesson describes in general terms how to manage Exchange 2000 deployment projects based on the principles of the MSF process model. You will read about the purpose of the various project phases, the tasks that are accomplished, and the documentation that is produced in each of them.

After this lesson, you will be able to

Organize an infrastructure project and plan the necessary tasks to accomplish it in a logical order
Identify important objectives that must be achieved before you can proceed to the next logical phase

Estimated time to complete this lesson: 45 minutes

Overview of the Envisioning Phase

During the envisioning or project preparation phase, you define the overall direction for a project. Whether you are managing a project for your own organization or for an external customer, you need to complete three important tasks. You must assemble the project team, define business objectives to win a project sponsor, and identify high-level risks that might adversely affect your undertaking.

The preparation of a deployment project requires you to clarify the following particulars:

Project team structure
Vision and scope of the project
Risk management plan

Roles and Responsibilities in the Project Team

Infrastructure deployment projects are best accomplished in teams. Team members can help each other, and it always is advantageous to have someone available for a discussion of deployment plans and assumptions. Jointly responsible for the entire project, the team members can work in parallel rather than in sequence, which can help to keep the project schedule tight. Depending on the extent of your deployment, your team may consist of executives and department managers, internal administrators, support specialists, and external consultants.

You should define several specific key roles and responsibilities within the team to distribute the various project tasks to individual persons or subteams. This allows each individual to focus on a specific mission and feel personally responsible for his or her part of the project. Ideally, the team is assembled as early in the preparation process as possible to jointly create the documentation.

The MSF team model suggests the following team roles with project responsibilities:

Project sponsor Responsible for final decisions and for emphasizing the importance of the project within the company. The project sponsor ensures the commitment of management and employees but does not assume an active role in the team.
Product manager Responsible for the entire project, including timely delivery within budget constraints and reporting to the project sponsor. It is the task of the product manager to satisfy the organization’s management.
Program manager Responsible for the technical specifications that define the features, functionality, network design, and infrastructure of the Exchange 2000 organization. It is the task of the product manager to satisfy the users.
Operations development Responsible for the development of the deployment strategies according to the technical specifications and the project schedule.
Test and quality assurance Responsible for the verification of the deployment strategies to ensure that the deployment of Exchange 2000 Server complies with the technical specifications.
User education and documentation Responsible for development and publishing of system documentation, manuals, and training material. User education and documentation is also actively involved in determining user-related business objectives during the project preparation phase.
Logistics and implementation management Responsible for transition from project development to daily operations and administration.

You may find the definition of additional roles useful. For example, you may want to appoint a financial officer, who tracks actual versus budgeted expenses (Figure 2.2). Staying within the budget is often an important criterion in

Figure 2.2 - A project team with standard and additional team roles

determining the success or failure of a project. A technical consultant or support resource may likewise be helpful, especially if technical knowledge or project experience is limited among the project team. A technical consultant could assist the program manager in defining the desired features and functionality, for instance. You can read more about forming a project team in Lesson 2.

Note

It is not necessary to involve the entire team in every part of the project, but the responsible person or subteam, as well as team members with other functions, should work together on each task. Working in cross-functional teams helps members gain wide-ranging expertise and reduces the risk of biased approaches.

Defining Strategic Project Goals

As mentioned earlier, it is important to define long-term objectives for the project to give your team an overall direction for their work. Your strategic goals should be business related. To identify relevant objectives, interview management and employees, even though most users will not be able to give direct answers right away. Issues and concerns raised by executives and other people in discussions about Exchange 2000 Server, however, can help to clarify the most important factors in the success of the project. Documents about management and IT policies as well as documentation from previous projects are another valuable source of information. It would be very interesting, for instance, to learn how the previous messaging system was implemented and why. A comparison of any existing messaging systems with Exchange 2000 Server is always useful and can help to show two or three compelling business benefits quickly. You can read more about the comparison of messaging systems in Chapter 1, "Introduction to Microsoft Exchange 2000 Server."

Project objectives must be measurable and achievable. You need to measure the progress of the work regularly to report the status to the team and the project sponsor. Microsoft recommends defining project objectives in two steps. First, develop a project vision; then define the scope in which the vision can be achieved. In other words, the vision is an unrestrained description of the intended undertaking. The scope defines which portions of the vision can actually be accomplished within existing constraints, such as limited budget or manpower. For instance, you may have to separate essential from nonessential features to exclude the latter from the project to complete the project successfully. The document in which you outline your strategic goals is often called a vision and scope document. You can read more about creating a vision and scope document in Lesson 2.

The vision and scope document should include the following information:

A vision statement
A description of business objectives, strategic goals, and scope
A preliminary outline of the future environment to give a first impression of the proposed Exchange 2000 organization
A date for the project start or an estimated schedule
The names of the product manager and the project sponsor, who assume full responsibility for the project

Understanding Risk Management

During any infrastructure deployment project, you face a variety of critical factors or risks that may cause delays, increase costs, or jeopardize the achievability of your strategic goals. For instance, technical skills are necessary to successfully accomplish the deployment of Exchange 2000 Server in your environment. If the technical know-how is missing and training is not provided, the project team may be unable to accomplish the work satisfactorily. Hence, it is vital to assess the skills of your team members and develop an appropriate training plan to avoid unpleasant surprises and frustration. It is important to assess the risks involved in the project and then take appropriate actions in advance to reduce their possible impact or likelihood. In short, you need to develop a risk management plan.

Your risk management plan should address the most critical risks. It should provide a clear description of each individual issue together with an assessment of the risk’s probability and its potential impact on the project. For each risk, you need to recommend a mitigation strategy (Table 2.1). It is often too late to think about mitigation strategies when problems occur. Likewise, it is advisable to create an emergency plan for risks with a high or critical priority, just to prepare your project team for the worst-case scenarios (Table 2.2). You can read more about risk management in Lesson 2.

Your risk management plan should include the following information:

Description of the risk
Rating of the risk for impact, probability, and priority
Name of the risk owner
Recommended mitigation strategies
Due date for risk mitigation activities
An emergency plan for high-priority risks

Note

Risk management is generally a team effort, but each individual risk should be assigned an owner to clarify risk management responsibilities. The risk owner needs to take appropriate actions to mitigate the risk or recover from its effects if things go wrong.

Table 2.1 Documenting Risks and Mitigation Strategies

Impact	Probability	Priority	Risk Description	Owner	Due Date	Mitigation
High	High	Critical	Insufficient knowledge of Windows 2000, Active Directory directory service, and Exchange 2000 Server will cause setbacks during rollout.	Product manager	March 2002	Develop training plan to ensure all team members receive appropriate training on Windows 2000 and and Exchange 2000 Server.

Table 2.2 An Emergency Plan for High-Priority Risks

Priority	Risk Description	Mitigation Strategy	Metrics	Trigger	Emergency Plan
Critical	Insufficient knowledge of Windows 2000, the Active Directory service, and Exchange 2000 Server will cause setbacks during rollout.	Develop training plan to ensure all team members receive appropriate training on Windows 2000 and Exchange 2000 Server. Due: Mar-02.	The team members are unable to develop structured action plans within project schedule.	The project slips more than two weeks behind schedule due to incomplete project plans.	Involve an external consultancy with working knowledge in deploying Exchange 2000 Server.

Approving the Deployment Project

Your preparations must conclude in the formal approval of the project through the project sponsor; without the sponsor’s signature on the front page of your vision and scope document, you cannot advance the project. A kickoff meeting is useful to discuss approval-related questions and concerns. It is important to select a project sponsor who is high enough in your organization’s hierarchy to promote and support the implementation of Exchange 2000 Server in your environment.

Processes in the Planning Phase

With the formal approval of the project, both team and sponsor have matched their ideas about the future Exchange 2000 organization. Now, the project team needs to turn these ideas into concrete plans. This includes the development of functional specifications, which define the services and features of the future messaging organization. It also includes the creation of a master project plan, which is a blueprint that describes the tasks of each individual team member in the context of an overall project schedule. The master project plan describes the activities of the project team in designing, testing, and implementing Exchange 2000 Server. The planning phase is also an important opportunity to reassess project risks and finalize budget estimates.

The project team must accomplish the following activities during the planning phase:

Document the current infrastructure and identify required changes to support Exchange 2000 Server.
Develop functional specifications for the future environment.
Design the physical and logical architecture of the Exchange 2000 organization.
Update the risk assessment document.
Create the master project plan.

Assessing

It is impossible to deploy Exchange 2000 Server without taking the existing environment into consideration. The future is best built on the present infrastructure, whether you are still running Microsoft Windows NT version 4.0 or already have upgraded to Microsoft Windows 2000 Server. You need to take into account the technical dependencies as well as organizational and business requirements.

When assessing the existing environment, document the following information:

The nature of your company’s business, the structure of the organization, the relationships of departments and divisions affected by the deployment, and management and user requirements
The existing computer and network environment, including server and workstation hardware; naming conventions; local area network (LAN) and wide area network (WAN) links; Active Directory and other directory topologies; and network services, such as Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), firewalls, and virtual private network (VPN) configurations
The current messaging infrastructure, including the individual e-mail systems that it contains, the connections between them, directory synchronization services, and workgroup applications

You can read more about the assessment of an existing environment in Chapter 3, "Assessing the Current Network Environment," and Chapter 4, "Assessing the Current Messaging Infrastructure."

Creating Functional Specifications

The development of technical specifications is primarily the responsibility of the program manager, who will need to work closely with operations development and other team members to address the technical issues. The functional specifications, based on the strategic project goals, provide detailed information about the characteristics, features, and services of the future Exchange 2000 organization. Team members as well as persons not directly involved in the project, such as the project sponsor, will be interested in this information.

Although the project team should develop functional specifications as early as possible in the planning process (to ensure that the entire team has the same ideas and expectations for the future environment), they should not be finalized until the production rollout begins. Project planning is an iterative process. Difficulties and unexpected results encountered during testing may require you to switch back and change the specifications to find better approaches, so functional specifications are updated regularly until the production rollout begins. You can read more about the development of functional specifications in Chapter 5, "Designing a Basic Messaging Infrastructure with Microsoft Exchange 2000 Server."

The functional specifications should contain the following information:

The vision/scope document
A description of deployment issues and potential problems
Design information about the future Exchange 2000 organization, such as standards for server hardware, locations and roles of servers, and so on

Creating the Physical and Logical Design

An important part of the functional specifications, as already discussed, is information about the logical and physical architecture of the Exchange 2000 organization. The logical design details the individual functions and services of Exchange 2000 Server and their relation to other system services, such as DNS and Active Directory. Administrative groups and management policies are important logical design elements. The physical design, on the other hand, maps the logical design onto the physical network to achieve optimal system performance within the restrictions of the existing environment. The configuration of server hardware and the topology of routing groups within the organization are part of the physical design (Table 2.3). You can read more about the logical and physical design of Exchange 2000 in Chapter 5, "Designing a Basic Meeting Infrastructure with Microsoft Exchange 2000 Server."

Table 2.3 Logical and Physical Design Elements

Logical Design
Active Directory and Global Catalog (GC) topology Advanced security and encryption key management Configuration of client applications, such as Microsoft Outlook 2000 Outlook Web Access, Network News Transfer Protocol (NNTP), Internet Messaging Access Protocol 4 (IMAP 4), and Post Office Protocol 3 (POP3) clients External connectivity and migration strategies Management of electronic and Web-based forms Management of mailboxes, contacts, and distribution groups Naming conventions and standards Server management policies Structure of public folder hierarchies Topology of administrative groups
Physical Design
Network infrastructure, including LAN and WAN links, Internet access points, firewalls and perimeter networks, VPN connections, and so on Remote access to Exchange 2000 resources Routing group topology and server placement Server sizing, including configuration of server hardware and Windows 2000 clusters Topology of external messaging paths and directory synchronization Topology of public folder replication

Reassessing Project Risks

Risk management is an important chore in all project phases. With every step toward the strategic project goals, you will encounter further risks, which you need to mitigate in addition to those discovered during the preparation phase. For instance, during the assessment of the existing environment, you may find that there is a high risk for Exchange 2000 Server to monopolize the Active Directory environment. In this case, as a possible mitigation strategy, you may want to recommend a complete redesign of Active Directory with Exchange 2000 in mind. The project team should then incorporate this mitigation strategy into their functional specifications. In other words, risk management and mitigation strategies from the risk management plan should influence how you approach the rollout of Exchange 2000 Server. You can read more about risk management, in the context of the project preparation, in Lesson 2.

Creating the Master Project Plan and Project Schedule

Whereas the functional specifications outline what you intend to build, the master project plan details the individual steps and the sequence of activities for performing the deployment. The program manager is the owner of the master project plan and coordinates the required resources, assigns tasks to individual team members, and ensures that the project stays on schedule. The individual team members, in turn, develop the planning documents according to their responsibilities and estimate the required time to complete their jobs. The planning phase is complete when all team members agree on the master project plan.

Table 2.4 lists typical planning documents that are part of the master project plan for a deployment of Exchange 2000 Server.

Table 2.4 Planning Documents Included in a Typical Master Project Plan for a Deployment of Exchange 2000 Server

Planning Documents	Description	Owner
Budgetary plan	Documents the required resources for a successful completion of the project, including costs for the evaluation of deployment issues, hardware and software upgrades, the purchase of lab equipment, and administrator and end user training.	The product manager controls the budget and ensures that the deployment does not exceed the allotted financial resources.
Deployment plans	Detail when, where, and how the project team intends to deploy Exchange 2000 Server. To ensure a smooth deployment with minimum problems, you need to test and verify the deployment plans before the production rollout begins. The creation of deployment plans is the subject of Chapters 5 through 9.	The program manager owns the deployment plans and coordinates their creation with operations development.
Design verification and pilot plans	Outline the configuration of test labs and usage scenarios and document the required steps to check the implementation procedures. To reliably verify the system design, consider a pilot rollout of Exchange 2000 at a small scale in the real environment in addition to the test lab. You can read more about testing and piloting later in this lesson.	Testing and quality assurance is responsible for testing the functional specifications and deployment plans.
Disaster recovery plan	Covers all aspects of system backup and restore procedures, including scheduling of backup cycles and maintenance of backup tapes. You can read more about disaster recovery planning in Chapter 11, "Designing a Disaster Recovery Plan for Microsoft Exchange 2000 Server."	The operations development team is responsible for creating the disaster recovery plan.
Logistics plan	Defines a strategy for the actual deployment of Exchange 2000 Server in the production environment.	Logistics management creates and owns the logistics plan.
Project team and communication plans	Describe the relationships, roles, responsibilities, and communication paths within the project team. You can find more information about the formation of the project team in Lesson 2.	The product manager assembles the project team and clarifies the team hierarchy and communication paths.
Risk management plans	Identify critical risks in the project and outline possible mitigation and emergency strategies. You can read more about risk management in Lesson 2.	The product manager is responsible for risk management, but the entire project team updates the risk management plan during all project phases.
Security plan	Defines which users can per- form specific activities, such as system administration tasks, and access sensitive data in the Exchange 2000 organization. This plan also describes how to prevent unauthorized access to the system. Security planning is further discussed in Chapter 9, "Implementing Security for Hosted Services."	The program manager is responsible for the development of the security plan.
Training plan	Documents how to familiarize administrators, users, and help desk personnel with the new environment (such as via instructor-led, self-paced, and computer-based training). If you decide to develop your own training material, do not forget to test it during the pilot phase.	User training and documentation is responsible for developing the training plan and any customized training material.

Stages in the Development Phase

It is not advisable to take functional specifications and project plans for granted without careful testing, which you should accomplish in two stages to obtain the most reliable results. First, you need to verify the functional specifications in a test lab, and then you should deploy Exchange 2000 Server on a small scale in the real world, often called a pilot rollout. During these verification stages, the project team verifies the practicability of the deployment plans, identifies and eliminates performance bottlenecks, determines user acceptance criteria for the new system, and gathers valuable practical experiences for the full-scale production rollout.

The following activities are part of the development phase:

Validation of project plans and system designs in a test lab
Deployment of Exchange 2000 Server in a pilot environment with a limited number of technically skilled users
Finalization of the functional specifications on completion of the pilot phase

Validating the Deployment Plans

The team members responsible for testing and quality assurance are in charge of the verification processes. They need to validate the implementation plans and system designs in a dedicated laboratory to identify performance issues and other problems that could lead to critical deployment situations. Without approval from testing and quality assurance, you should not begin the production rollout.

The tests are best approached in a systematic way, beginning with design checks to ensure that the hardware and all server components fulfill their functional specifications, and ending with interoperability tests to guarantee proper system operation and performance in a multiserver environment possibly integrated with foreign messaging systems. It is good practice to document the configuration of the laboratory and the actual test procedures to describe how the test results were achieved. Careful incident tracking is particularly important should it become necessary to change deployment procedures or implementation strategies. The project team must update the planning documents so that you can reproduce the changes in the production environment.

When building the test lab, consider the following issues:

Consider the installation of separate test labs for each deployment scenario It is advantageous, for instance, to test upgrading from Microsoft Exchange Server 5.5 separately from migrating from a foreign messaging system because the deployment procedures differ significantly in these situations.
Create a separate Active Directory forest and DNS environment It is important to keep the test systems strictly separate from the production environment, including Active Directory domain controllers and DNS servers, to minimize the risk of conflicts with production systems.
Create a separate network You should duplicate the network configuration in a logically separate network to avoid connecting the test systems to production systems, which may lead to problems with message routing or other issues that may cause a disruption of business processes.
Simulate the production environment as best as possible Use hardware with the same configuration as the servers and workstations in the production environment and install typical applications on the test systems to uncover possible interoperability issues.

Note

You should keep the test lab intact after completion of the full-scale Exchange 2000 Server deployment. Having an isolated test environment allows you to test new software and service packs before applying them to the production systems. The test environment also enables system administrators to practice disaster recovery procedures periodically. In addition, it can serve as an emergency hardware supply if defective production equipment must be replaced.

Piloting Exchange 2000 Server

It is impossible to examine user interaction with Exchange 2000 Server in a test lab. For this reason, you need to plan a pilot project to find out how the deployment of Exchange 2000 Server affects and satisfies the users in the production environment. The pilot project is a means to optimize the architecture of the future Exchange 2000 organization, and it also provides a great opportunity to fine-tune training material and user manuals.

You should plan the Exchange 2000 pilot as a separate, small-scale deployment project, just to test the readiness of your project team for the production rollout. An important consideration is which users you should select for the pilot. The ideal group consists of a small number of technically skilled users who are willing to cope with the initial challenges of a new and unfamiliar messaging system. The pilot users must be willing to report any problems and how to reproduce them. Another important consideration is how much of your production system you want to involve. The less the better, but the pilot must remain representative of the full-scale rollout. For instance, if you intend to connect the future Exchange 2000 organization to the Internet, then you need to connect the pilot organization to examine issues related to Internet connectivity.

Take the following tasks into account when creating the pilot implementation plan:

Create a communication plan Efficient communication between the pilot group and the project team is vital for the success of the pilot project. The pilot group requires a convenient communication channel to report technical problems, and the project team needs to provide technical help and frequent status updates.
Determine measurable objectives for the pilot project You do not need to address all business requirements, but you need to determine appropriate success factors for the pilot project according to the strategic goals outlined for the production rollout in the vision and scope document and functional specifications.
Determine the functions that should be tested Ideally, the pilot project tackles all significant deployment scenarios. If you are planning to utilize advanced server configurations for fault tolerance and resilience, such as clustered servers, install at least one Windows 2000 server cluster in your pilot environment. If you need to establish an organization with multiple routing groups, implement two routing groups to test at least one routing group connector. If you intend to migrate from a foreign messaging system, establish one messaging connection, perform directory synchronization, and migrate the pilot users.
Determine the pilot users The pilot group should consist of technically skilled users who are willing to work with new technology and tolerate technical problems. Because the chance of technical problems is high, you should avoid choosing a group engaged in mission-critical work. It is likewise not advisable to choose a very specialized group of users because such a group does not allow you to determine typical user requirements. For example, if your end user community works primarily with workstations running Microsoft Windows 98, but the IT department is using Windows 2000 Professional, do not appoint the IT department as the pilot group.
Document the pilot processes and actions taken to resolve problems The documentation created during the pilot phase will help you finalize the deployment plans. You may also want to provide a summary of the pilot project to the project sponsor to report that the deployment plans and the project team are both ready for the production rollout.

Note

The pilot phase is complete when the project team has resolved all critical problems and has achieved end user satisfaction according to the feedback from the pilot users. To obtain final authorization for the production rollout, you should present a status report, documenting the success of the pilot, to the project sponsor.

Activities in the Deployment Phase

With the completion of planning and testing, you are ready for the final project phase—the production rollout. This is the moment of truth that will show how carefully your team prepared for the implementation of Exchange 2000 Server. However, the deployment of Exchange 2000 does not only entail the installation of server systems and migration of end users. It also includes the preparation of external teams, such as messaging administrators and a user help desk, as well as the end users. Administrators require technical training on Exchange 2000 Server for ongoing system maintenance. The user help desk requires training on Exchange 2000 Server and Outlook 2000 to support the end users. End users, finally, should also receive technical training on Outlook 2000 and other relevant client software before you migrate them to the new platform. In short, training everyone affected is a key aspect of the production rollout.

The following are important activities that you need to accomplish during the deployment phase:

Train administrators, user help desk staff, and end users on the new environment.
Deploy Exchange 2000 Server and Outlook 2000 throughout the organization.
Assess the progress and success of the production rollout.
Transfer the new infrastructure to daily operations for system administration, maintenance, and support.

Deploying Exchange 2000 Server

The rollout of Exchange 2000 Server is primarily the task of the logistics management squad, but other team members will need to support this group. For example, operations development may have to solve critical problems that arise during the deployment despite careful testing and the pilot project. Testing and quality assurance may also be involved to verify the practicability of the problem-resolution strategies.

Assessing Deployment Progress and Completion

Often you will have to update the project sponsor and other executives in the company on the progress of the production rollout, so it is desirable to achieve reportable results quickly. To deploy Exchange 2000 Server efficiently, implement the company-wide messaging backbone first and then configure routing group connectors and connections to foreign messaging systems, such as Internet connections.

As soon as you have established the backbone, your team can implement the mailbox servers that actually hold the user data. It is a good idea to monitor newly installed servers for several days before placing mailboxes and public folders on them. It is advantageous to migrate your users according to the teams and departments of your organization because this facilitates measurement of the project’s progress. However, keep in mind that the transfer of end users will take a significant amount of time because of the required user training. It is not advisable to accelerate the rollout by cutting training short. Insufficiently trained users are unable to work with the new environment and will turn quickly into frustrated users. Administrators and user help desk staff would have to pay the price and would likewise become frustrated. More often than not, it is better to extend the project schedule than to shorten the training lessons.

Transferring the Project to Daily Operations

The rollout is complete when the project team has migrated all users to Exchange 2000 Server. You then need to hand off the system to the daily operations groups for routine administration and maintenance. You also need to close up the project formally. It is important to establish an agreement with the project sponsor that the project has been accomplished successfully according to the project plan and business objectives. In this context, you may want to conduct a project review to identify possible improvements or additional functionality that may be implemented in a follow-up project. Documenting these findings helps future project teams to begin their preparations efficiently.

Lesson Summary

Proper project planning is essential to the overall success of the deployment of Exchange 2000 Server. It is best approached by using reliable management methods that help keep the project on schedule and the project team focused on relevant objectives. For this reason, Microsoft has developed a comprehensive management framework for software development and infrastructure deploy-ment projects. The MSF divides infrastructure deployments into the phases of envisioning, planning, developing, and deployment.

During the envisioning phase, the project team is assembled, the project’s vision and scope are determined, and a first risk assessment is performed. This phase is followed by the planning phase, in which you develop the functional specifications according to the vision and scope document and information from an assessment of the existing environment. Furthermore, you create the physical and logical design of the Exchange 2000 organization and establish the master project plan.

It is vital to verify the functional specifications and planning documents because only proven procedures should be applied in the production environment. The necessary tests are accomplished during the development phase, which follows after the planning phase and entails primarily two processes: the verification of the deployment concepts in a test lab and the rollout of Exchange 2000 Server in a pilot environment. With the completion of these two processes, the work on the functional specifications and implementation plans is finished. The deployment phase begins when you take Exchange 2000 Server into production. Users and administrators must receive appropriate training. You will need to report project progress, completion, and success to the project sponsor. At completion of the rollout, the environment can be handed over to daily operations, and the established environment should be reviewed for possible improvements that may be the objectives of future infrastructure projects.