Exchange 2000 and Novell GroupWise Coexistence and Migration

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: January 1, 2002 | Updated : March 4, 2002

Authors:

Dean Suzuki, Microsoft Consulting Services

David Maguire, Exchange User Education
For the latest information, please see https://www.microsoft.com/exchange/.

On This Page

Introduction
Chapter 1 Planning
Chapter 2 Developing
Chapter 3 Deploying
Appendix A Procedures
Appendix B Exchange Installation Checklists
Appendix C Migration Flowchart
Appendix D Additional Resources

Introduction

This paper presents the detailed process Fabrikam Worldwide, Inc., a fictitious consulting firm based in Richmond, VA, followed in migrating its messaging system from Novell GroupWise to Microsoft® Exchange 2000 Server. Fabrikam has approximately 1,000 employees in the United States and Germany. This case study is based on GroupWise-to-Exchange 2000 migrations performed by Microsoft Consulting Services (MCS), and all data comes from MCS Exchange 2000 deployments.

Use Fabrikam's methods and strategies as guidelines for your Exchange 2000 deployments. Your organization will likely differ from Fabrikam in certain areas (topology, number of seats, and so on), but you can still follow these guidelines and precautions. Be aware that not every process performed by the Fabrikam migration team will be applicable to your organization. Nonetheless, the migration goals and, more important, lessons learned by Fabrikam can benefit anyone migrating from GroupWise to Exchange. In addition, checklists, questionnaires, and best practices have been identified to assist in your migration.

Who Should Read This Paper

This paper assumes you have a fundamental understanding of Microsoft Active Directory® directory service, security groups, and domain architecture, as well as basic knowledge of Exchange 2000. Your migration team must include at least one experienced GroupWise administrator.

The Fabrikam case study discussed here focuses primarily on the technical aspects of a GroupWise-to-Exchange 2000 migration, specifically migrating from GroupWise 5.5 to Exchange 2000 Enterprise Server. Although this case study is based on GroupWise version 5.5, most procedures, checklists, and conceptual planning information is relevant to all versions of GroupWise.

Note: Fabrikam installed Exchange 2000 Enterprise Server, which has greater storage capacity than the Standard Edition of Exchange 2000 Server. If your organization is migrating to Exchange 2000 Server, much of this white paper is still applicable.

For more information about the differences between Exchange 2000 Server and Exchange 2000 Enterprise Server, see the Microsoft Knowledge Base article 296614, "XADM: Differences Between Exchange 2000 Standard and Enterprise," at.

Deploying Windows 2000 Server and Active Directory

A separate Microsoft Windows® 2000 Server team designed Fabrikam's Active Directory. After designing Fabrikam's Active Directory, the Windows 2000 team performed the following steps.

1. Deployed Windows 2000 Server and Active Directory infrastructure in a test environment in a Fabrikam lab.

2. Deployed Windows 2000 Server and Active Directory infrastructure in a production environment.

3. Consulted with the Exchange 2000 migration team in charge of the Fabrikam GroupWise migration during the migration planning and implementation stages.

This case study assumes you have already deployed Windows 2000 Server, or will deploy it soon. In either case, this paper does not discuss organizational units and other structural elements of Windows 2000 in detail, but the importance of a sound operating system cannot be over-emphasized.

Exchange 2000 requires a stable Windows 2000 foundation, particularly a stable and well-planned Active Directory. MCS recommends that you set up your Windows 2000 architecture and run it in your production environment for a period of time before you deploy Exchange. Only after you determine that your Active Directory is functioning properly should you consider installing Exchange.

The following key components of your Windows 2000 organization affect Exchange:

• Global catalog servers Exchange 2000 uses global catalog servers extensively for directory lookups, group expansion, and client referrals. This information includes how many global catalog servers you need and where to locate them.

• DNS Exchange relies heavily on Domain Name System (DNS).

• Sites and subnets Exchange uses the Windows 2000 site and subnet structure, particularly in the placement of domain controllers and global catalog servers.

• Domain design Exchange 2000 uses Windows 2000 groups for distribution lists. In a multiple domain design, the Exchange 2000 design needs to accommodate distribution lists to ensure that all distribution lists work in every domain.

Fabrikam Case Study Overview

The purpose of this paper is to provide a comprehensive look at a real-world migration from GroupWise to Exchange 2000. The structure of the information provided here is based on Microsoft Solution Framework (MSF), an industry-proven project management framework used by MCS. For an efficient and successful GroupWise migration, model your migration after Fabrikam's Exchange deployment.

Any company attempting to migrate its enterprise messaging system from GroupWise should follow a proven project management framework. Even if your implementation methodology is different from MSF, the enterprise designs in Chapter 2 and the procedures and processes in Chapter 3 (as well as the lessons learned by MCS) are still valuable tools.

Any organization without a proprietary migration plan, however, should take advantage of MSF provided in this paper. Microsoft developed MSF after years of deploying Microsoft products at wide-ranging customer sites around the world. In this case study, Fabrikam adheres to the MSF phases of envisioning, planning, developing, and deploying. For more information about the MSF process, including training information, see the Microsoft Solution Framework Web site at https://go.microsoft.com/fwlink/?LinkId=3913

In brief, MSF breaks any project into four phases: envisioning, planning, developing, and deploying (Figure I.1).

Figure I: .1 Phases of Microsoft Solution Framework

For the purposes of this case study, envisioning is included with planning in Phase 1.

Each part of this case study discusses the specific tasks the migration team must perform during the planning, developing, and deploying phases. In addition, each chapter describes what each phase of MSF accomplishes as a result of the complete tasks.

Chapter 1 – Planning

In the planning phase, the key business requirements of the new Exchange messaging system are discussed, as well as the premigration networking and messaging environments of Fabrikam. The migration team's design mandate is to retain current messaging functionality and, when possible, exceed current functionality with Exchange 2000 features. Careful planning is the key to avoiding complications after migration begins.

Chapter 2 – Developing

The developing phase of the MSF process is where the requirements defined during planning are used to design the future Exchange 2000 system. In this phase, the migration team creates a complete, logical design of the future Exchange system. This section describes how Exchange features can meet Fabrikam's business requirements and the design of the new Exchange organization. The concept of interoperability ("coexistence") and the Exchange 2000 GroupWise Connector are also introduced.

Chapter 3 – Deploying

In the deploying phase, the various components of the Exchange design (such as routing group topologies and Microsoft Outlook® Web Access deployment) are implemented, first in a test and then in the production environment. A pilot group of users are migrated. This section:

• Describes the actual deployment of the Exchange system.

• Describes the setup and configuration of the Exchange system.

• Describes the setup of the GroupWise-to-Exchange interoperability architecture.

• Describes the use of Migration Wizard.

• Discusses the nightly migration process.

• Discusses types of data that can be migrated.

• Discusses how the data was migrated.

Chapter 3 also contains the checklists used by MCS and Fabrikam administrators to accomplish the tasks listed above. Use these checklists as guidelines for administrators in your organization during your own migration.

Appendixes

The appendixes contain procedures for accomplishing specific tasks, from configuring an Exchange 2000 Simple Mail Transfer Protocol (SMTP) connector to delegating administrative permissions. Some of the procedures are from the Exchange 2000 online documentation, and others were tailored by MCS specifically for Fabrikam and similar companies. All organizations can use these procedures for their own migrations, as the appendixes also include checklists for installing Exchange 2000 Enterprise Server in small, medium, and large office environments, and for deploying a dedicated Outlook Web Access server.

Chapter 1 Planning

This chapter describes Fabrikam's messaging topology prior to migration, as well as the needs Microsoft Exchange 2000 will have to address. The decisions of the migration team, based on these factors, are also discussed.

Table 1.1 provides an overview of the planning phase.

Table 1.1 Planning phase overview

Resources	Tasks	Key deliverables
· Project vision · Requirements · Existing documentation (network, GroupWise, Novell Directory Services, Microsoft® Windows NT®)	· Conduct discovery sessions on business and technical requirements. · Analyze existing network usage. · Analyze existing e-mail usage on servers and across the entire network. · Form the migration team. · Capture Fabrikam's vision and requirements in a functional specification document. · Perform risk assessment. · Create high-level project plan.	· Functional specification document prepared. · Migration team with team leads briefed on requirements. · High-level risk assessment plan prepared. · Project plan prepared. · Fabrikam management gives approval to proceed to developing phase (Chapter 2).

During the planning phase, the Fabrikam migration team performed the following tasks:

• Assembled the team members and resources. Microsoft Solution Framework (MSF) provides a model consisting of key lead roles to ensure a successful implementation. For more information about these roles, see the MSF white paper Team Model for Application Development available at https://go.microsoft.com/fwlink/?LinkId=5923.

• Your company should model this team structure as closely as possible. During the planning phase, the necessary resources need to be identified and made available for the project. In addition to people, the team identified and allocated the computer resources and the project work room.

  Important: MCS found that many projects fail because team members are assigned to the project but must still perform the day-to-day duties of their regular job. If at all possible, it is highly recommended that the duties of the six key lead personnel be shifted to other resources during the project.

• Identified and communicated the Fabrikam vision for the project. For more information about this vision, see the "Design Goals and Requirements" section later in this chapter.

• Developed a time line for the entire project.

• Developed a risk management plan. The risk management plan identifies any potential risks and corresponding mitigation actions. MSF contains an extensive description of the risk management strategy. For more information, see the white paper Risk Management Process available at https://go.microsoft.com/fwlink/?LinkId=5929.

Proactively managing risks, real or anticipated, is crucial for any project, and a migration from GroupWise project is no exception.

• Understood and documented Fabrikam's existing environment (for example, locations, number of users at each location, and the networking and messaging architecture). This information is covered in the "Fabrikam Existing Environment" section later in this chapter.

• Understood any future networking architecture changes that may be made. For example, for its corporate network, Fabrikam is considering increasing the capacity of some of its frame relay links as well as adding redundant links. (Figure 3 illustrates the Fabrikam frame relay network.)

• Understood Fabrikam business and technical requirements for its messaging system, as described in the "Design Goals and Requirements" section later in this chapter.

Use the questionnaire checklist provided at the end of this section to help with your planning effort.

Migration Team

Fabrikam identified individuals to lead six key areas (Table 1.2). Some of the teams (for example, development) had many members supporting the migration effort.

Table 1.2 Migration team leads

Team role	Person
Product management	Alan Steiner, Director of IS
Program management	Kim Ralls, Manager of IS
Development	Suzan Fine, Mail Administrator
Testing	Adam Barr, Network Administrator
User advocate	Raymond K. Sam, Manager of User Training
Logistics	Florian Voss, Administrative Assistant

Time Line

After the Fabrikam migration team was assembled, one of the first things the team did was create a time line for the project. Given the size of Fabrikam's messaging system, the team produced the time line shown in Figure 1.1.

Figure 1.1: GroupWise migration time line

To verify the plan, the migration team conducted a test of the Microsoft Windows® 2000 and Exchange 2000 system prior to deploying into the production network. This test was performed in a lab, separate from the production messaging system, to protect users until a solid and proven plan was in place.

Note that the time line allowed the Fabrikam migration team a full month each for preparatory work:

• Envisioning and planning the migration (including plans for the post-migration Exchange messaging system).

• Developing the environment to accommodate those plans (setting up Exchange servers, determining placement and naming conventions, and populating Active Directory® directory service with Exchange objects).

• Testing to see if the plan up to that point produces a topology that functions in a controlled environment.

Establishing a time line emphasizes the importance of careful planning. Each phase of the MSF method must be accomplished successfully before moving to the next.

Risk Management Plan

A key component of Microsoft Solution Framework is risk management. Use risk management to proactively identify potential problems and take preventive actions before the issues become major problems.

The risk management plan includes a list of all the risks. After the migration team lists all the risks in the migration, the team performs the following steps.

1. Assesses the risk impact, rating each of the risks from 1=Low Impact to 5=High Impact.

2. Assesses the probability that the risk will occur, rating it from 0 percent (no chance of occurring) to 100 percent (will definitely occur).

3. Assigns each risk a score by multiplying the risk impact and the risk probability.

4. Ranks the risks by risk score.

5. Identifies a risk mitigation action for each risk.

Table 1.3 illustrates a portion of Fabrikam's risk management plan.

Table 1.3 The Fabrikam risk management assessment

Risk	Risk impact (1-5)	Risk probability (0-100%)	Risk score (risk impact * risk probability)	Risk mitigation
Team members are not trained on Exchange 2000.	3	80%	2.4	Send team members to training.
Network links are heavily used.	3	80%	2.4	Monitor the network use of links. Evaluate costs of adding to link capacity.

Two key risks identified early were the lack of experience with Exchange 2000 by the Fabrikam personnel and the current level of use of the network links.The team identified mitigation actions that Fabrikam can take to reduce these risks.

The Fabrikam migration team met weekly to review the risk management plan.Any new risks were added to the table.If the team felt that the mitigation actions reduced the impact or probability of the risk, the risk score was adjusted.The team's goal was to reduce the total risk score (sum of the all the risk scores) each week.

For more information about devising a complete MSF Risk Management Plan, see the white paper Risk Management Process available at https://go.microsoft.com/fwlink/?LinkId=5929.

Fabrikam Existing Environment

Fabrikam has several branch offices connected by a number of WAN links. The company's headquarters are in Richmond, VA, with offices in Alexandria, VA; Braintree, MA; Chicago, IL; and Munich, Germany. Fifteen additional users are based in Chapel Hill, NC, with ten of those users serviced by Post Office Protocol version 3 (POP3) mail accounts and five users using the corporate GroupWise system.

Figure 1.2 illustrates the frame relay network that connects these offices.

Figure 1.2: Fabrikam Worldwide, Inc. frame relay network

Fabrikam uses three frame relay carriers. As shown in Figure 1.2, Fabrikam has two major frame relay networks so that there are redundant paths between each major location. A different telecommunications company manages each frame relay network. Thus, if a frame carrier's network has problems, the packets can flow over the other frame relay carrier.

Fabrikam employed a third frame relay company to provide the frame relay connection to Europe. The other two companies did not have affordable rates outside the United States

The numbers on the diagram indicate:

• The local loop speed (the link speed from the location to the frame relay network). This speed is the connection speed that Fabrikam has been given to the frame relay network.

• The permanent virtual circuit (PVC) speed (the link speed inside a frame relay network). This speed is the guaranteed speed provided by the frame relay carrier. However, Fabrikam can send bursts of speed up to the local loop connection speed across the PVC if bandwidth is available inside the frame relay network.

Because the Chapel Hill location is so small, Fabrikam is considering removing the frame relay connection to that office and replacing it with a DSL connection to the Internet. Administrators could then set up a virtual private network (VPN) connection from Chapel Hill to the corporate headquarters using Windows 2000 Server.

User Distribution

Table 1.4 shows the premigration server distribution throughout the entire Fabrikam organization and displays the user mailboxes and distribution lists by location.

Table 1.4 User distribution at Fabrikam

Location (server name)	Number of active users (does not include external entities(1))	Number of external entities 1 per server	Number of distribution lists
Richmond (Willoughby, Drago, and Fisk(2))	845	Willoughby: 95 + Drago: 49 = Total: 144	125
Alexandria (Wise)	77	10	12
Braintree (Evans)	119	15	25
Chicago (Lynn)	15	5	7
Munich (Carbo)	26	4	5
Chapel Hill (Doyle)	5	1	2
Total	1,087	179	176

(1) In GroupWise, an external entity is a mail-enabled GroupWise object that does not have a security principal associated with it (it is not part of Novell Directory Services [NDS]). Two examples of external entities are:

• The mail account that receives feedback from the Fabrikam Web site; this account is monitored by a group of administrators.

• Group calendars.

External entities cannot be migrated in the same manner as GroupWise mailboxes; therefore, these entities are considered separately during the planning phase. Best practices for migrating external entities are discussed later in this chapter.

(2) Fisk is Fabrikam's Internet mail gateway and does not house any mailboxes. Fisk also holds a GroupWise API gateway that interfaces to the company's fax system and Novell's pager interface.

External entities can be supported in Active Directory as mailbox-enabled objects that administrators disable. If your GroupWise organization has external entities that are accessed by means of the proxy, evaluate these proxy access methods because Exchange handles proxy access differently from GroupWise. In Exchange, the equivalent of proxy access is delegate access — when a user gives another user permission to some or all of their mailbox folders.

Fabrikam Messaging Architecture

This section looks at the current (premigration) GroupWise infrastructure at Fabrikam, including how Fabrikam communicates with external domains outside its firewall and the amount of average daily use of each GroupWise server.

Outbound Messages

Fabrikam employees send outbound messages to recipients in external domains by using Simple Mail Transfer Protocol (SMTP) to route messages outside the company through the Internet. All mail leaving Fabrikam bound for the Internet goes through the server Fisk, the company's GroupWise Internet gateway server. Fisk is configured to deliver all non-local mail (not bound for the Fabrikam domain) to one of two mail relay servers, which are located outside the first Fabrikam firewall but inside the second (see Figure 1.3). This firewall configuration is called a perimeter network (also known as DMZ, demilitarized zone, and screened subnet). In Fabrikam's firewalls, TCP port 25, the default SMTP port, is open. This port allows communication from Fisk to the mail relay servers in the perimeter network and then from the mail relay servers out to the Internet. For optimum performance, the mail relay servers run Windows 2000 Network Load Balancing, which means all the servers share all inbound and outbound traffic equally.

Figure 1.3 illustrates this configuration.

Figure 1.3: Fabrikam messaging architecture and SMTP mail configuration

When Fabrikam migrates to Exchange 2000, administrators must open a similar port in the Fabrikam firewall (TCP port 25). Opening this port allows SMTP traffic from the Exchange 2000 SMTP connector acting as gateway to communicate with the Fabrikam mail relay servers.

MX Records

Every Internet mail domain has one or more Mail Exchange (MX) records listed in DNS. When a mail router has a message to deliver to a particular domain, it looks up the MX records for that domain and sends it to the server (or host) with the lowest preference. If the host with the lowest preference is unavailable, the router attempts to send the message to the host with the next lowest preference, and so on.

Fabrikam Worldwide, Inc. has the following MX records defined in DNS:

Fabrikamworldwide.com   IN MX 10       fisk.fabrikam.com
Fabrikamworldwide.com   IN MX 20       willoughby.fabrikam.com

The Fisk server has a lower preference (10) than the Willoughby server (20). Therefore, Willoughby only receives mail addressed to Fabrikam.com if Fisk is busy.

Web Mail

Fabrikam uses the GroupWise Web Mail feature, which allows employees outside the firewall to have access to their e-mail by using a Web browser. Fabrikam employees access their mail by going to:

https://webmail.fabrikamworldwide.com

The system automatically redirects the user to a secure connection at:

https://webmail.fabrikamworldwide.com

This connection is a 128-bit Secure Sockets Layer (SSL) encrypted channel.

The average number of daily connection attempts to Fabrikam's Web server is 1,420.

Mailbox Usage

Figure 1.4 shows the current sizes of the GroupWise mailboxes on each Fabrikam server. This information helps determine the storage space needed on each Exchange server.

Figure 1.4: Mailbox usage

Mail Flow

The migration team monitored the existing GroupWise mail system for average daily usage in a number of key areas. The following sections discuss these key areas.

Gateway

Fabrikam used three gateways for communication outside its intranet:

• The GroupWise API gateway

• The GroupWise Pager gateway

• The GroupWise Internet Agent (GWIA)

Fabrikam used the API gateway to communicate with a third-party faxing product and used the pager gateway primarily to send pages out to Fabrikam's system administrators, informing them of system status messages.

Table 1.5 illustrates average daily usage for Fabrikam's Internet gateway.

Table 1.5 Internet gateway usage

Gateway usage	Number of sent messages per day	Number of received messages per day
API (for faxes)	0	50
Pager (third-party pager product)	33.2	0
GWIA (messages)	3282	8976.4

GroupWise MTA Usage

The most fundamental elements of a GroupWise domain are the post office, the message transfer agent (MTA), and the gateway. The post office is a logical grouping of users and other GroupWise objects that are mail-enabled. The gateway moves messages between a GroupWise system and other mail systems. The MTA delivers messages between GroupWise post offices within a domain, between post offices and gateways within a domain, and between domains within a GroupWise organization. One MTA is required for every domain.

Each Fabrikam office location has its own GroupWise domain with its own MTA. Table 1.6 shows the average number of messages processed by each MTA on a daily basis.

Table 1.6 Daily MTA traffic

Location of MTA	Number of messages sent through MTA	Number of users	Number of messages routed per user
Richmond	15200	845	17.99
Braintree	2789.2	119	23.44
Alexandria	1478.8	77	19.20
Chicago	667	15	44.46
Chapel Hill	40.6	2	20.3
Munich	55.8	26	2.15

The migration team looked at these numbers and considered MTA usage at each remote site combined with the bandwidth usage of each link (see Figure 1.2). Weighing these factors against the desired business direction of the company, the migration team defined three key questions about the architecture of the new messaging system:

• Should the team use a centralized approach or a decentralized approach?

• Should the team increase the link speeds?

• Should the team reduce the number of mail servers and centralize them?

Post Office Usage

Fabrikam has two GroupWise post offices in its Richmond headquarters and one post office at each of its other locations. Daily messaging traffic through each post office was analyzed, and the results are shown in Table 1.7.

Table 1.7 GroupWise post offices by location

Location	Number of client-to-server connection attempts per day	Number of messages per day	Number of users	Number of daily messages per user
Richmond (Willoughby)	0	0	464	0
Richmond (Drago)	441,616	8238.8	381	21.6
Braintree	122,954	3311.6	119	28.8
Alexandria	102838	1633.3	77	21.2
Chicago	1318	658.4	15	43.9
Chapel Hill	985	27.6	2	13.8
Munich	23706	639.2	26	24.6

Design Goals and Requirements

In addition to the overall design mandate to retain current messaging functionality after migration, the Fabrikam migration team was also instructed to set high standards in system reliability and fault tolerance.

• Users at branch offices can still perform their business functions if the WAN or central Richmond location become unavailable. The migration team will design each branch office to function independently.

• The e-mail system design will maximize fault tolerance. The migration team will implement technologies such as redundant array of independent disks (RAID) and separate disk controllers to increase the system fault tolerance.

The following sections describe the post-migration goals Fabrikam has for its messaging architecture. The goals include message routing and SMTP mail delivery standards, requirements for their servers running Exchange 2000 and for their client computers, and monitoring and maintenance needs.

SMTP Mail Delivery

Fabrikam currently has one point of SMTP connectivity to the Internet, the GroupWise Internet Agent (GWIA) on the Richmond server Fisk (see Figure 1.3). The team will replace the GWIA will with an Exchange 2000 SMTP connector, described in Chapter 2. All of Fabrikam's Internet-bound mail will go through this connector.

New E-Mail Naming Standard

Currently, Fabrikam uses the last name plus first initial of each employee as the company's e-mail naming standard. For example, Alan Steiner's e-mail address is asteiner@fabrikamworldwide.com. The company wants to change this format to first name.last name@fabrikam.com (for example, Alan.Steiner@fabrikam.com). If two people have the same name, the standard will be first name.middle initial.last name@fabrikam.com.

However, when Exchange is implemented, e-mail addressed to the current e-mail address (asteiner@fabrikamworldwide.com) must be correctly routed to the correct Exchange mailbox, which will be using the new e-mail address (alan.steiner@fabrikam.com).

Fabrikam management wanted to change the domain name of its e-mail from fabrikamworldwide.com to fabrikam.com. Whether you want to keep your existing domain name or change it significantly affects how you set up mail routing during the GroupWise and Exchange coexistence period. Fabrikam's domain name change, particularly related to its Outlook® Web Access deployment, is discussed in more detail in Chapter 2.

Exchange 2000 Requirements

The Fabrikam migration team will realize its design goals through the Exchange 2000 performance and architectural capabilities described in this section.

Mailbox Size Limits

Based on current e-mail usage (see Figure 1.4), the migration team decided on 125 MB as the maximum mailbox size for all users. Users will receive a warning message when their mailbox size reaches 100 MB, and they will receive that message once a day until the size is decreased to fewer than 100 MB. At 125 MB, users will be unable to send e-mail until they reduce the size of their mailbox.

Mailbox size limits are a particularly important planning consideration for three reasons:

• The amount of existing GroupWise mail to be migrated greatly affects total migration time.

• Any local archives cannot be migrated directly to Exchange.

• GroupWise, like Exchange, uses single-instance storage. Single-instance storage means that a message sent to 50 people is saved only once, but during migration this message is migrated 50 times.

Chapter 2 discusses all three of these considerations in full detail.

Mail Retention Policies

Fabrikam corporate policy is to delete all e-mail messages older than 45 days. The Exchange 2000 messaging system must continue this policy.

Deleted Items Recovery

Fabrikam noticed on several occasions that some executives accidentally deleted some critical e-mail items and emptied their e-mail trash can. To recover these items, the e-mail administrators restored the GroupWise database in a lab environment and recovered the message. Overall, this process was very arduous. After Fabrikam completes its Exchange 2000 rollout, the company plans to use set the Outlook and Exchange deleted items retention period for three days.

Deleted Mailbox Recovery

One of Fabrikam's requirements is the ability to reconnect the mailbox to a new user after the previous employee leaves the company. For example, when an employee leaves the company, Fabrikam's regulatory requirements require that the e-mail administrator delete the account of the employee. However, if a new employee replaces this employee, many times Fabrikam wants to link the previous user's mailbox to the new user's account so that a history of the prior work is retained.

Exchange provides the capability to link the mailbox of a user account to a new account. This linking can be done as long as the mailbox is linked within a specified interval called the deleted mailbox recovery period.

Fabrikam wants the ability to recover a deleted mailbox up to 30 days after it has been removed from Exchange.

Message Size Limits

Fabrikam imposes a message size limit of 5 MB for all messages sent through its SMTP gateway, the GWIA in Richmond. Certain "power users," such as company executives, are allowed to send messages up to 10 MB in size through the SMTP gateway. Currently, messages sent internally (from one Fabrikam employee to another) do not have size limits.

In Exchange, Fabrikam wants to optimize network performance and impose more granular size restrictions:

• Internal messages sent between sites cannot exceed 25 MB. Additionally, all messages larger than 10 MB should be delivered during non-working hours (between 5:00 P.M. and 9:00 A.M.).

• External messages—messages that are sent and received through the Exchange SMTP connector—cannot exceed 5 MB.

• The same group of users who had a larger message size limit through the GWIA must be able to send messages up to 10 MB through the SMTP connector.

Auto-Forwarding

One of Fabrikam's requirements was to limit users' ability to auto-forward messages outside to an Internet e-mail account. The company was concerned that proprietary information may be inadvertently sent out to an insecure e-mail account.

Client Rules

Users can create rules for incoming e-mail messages to manage those messages more efficiently. A rule is an action taken on e-mail under certain user-defined conditions, including exceptions to those conditions. An example rule a Fabrikam user might have is:

Copy all messages from Alan Steiner in which I am on the To or Cc lines to my "Alan S" folder, unless the message is marked low priority.

Fabrikam wants users to retain their rules in Outlook, which is the client Fabrikam will use after migrating to Exchange 2000.

Local Archives

Fabrikam employees archive older GroupWise items, such as messages they want to save. These archives are enormous, because Fabrikam configured its GroupWise system to automatically archive messages older than 30 days into these local archives. Employees want to migrate these archives to Outlook and Exchange 2000.

Centralized Messaging Administration

Fabrikam currently manages its GroupWise system from its main Richmond office. The network administrator in Braintree can create accounts in NDS, but she does not have permissions to manage e-mail. In every office, there are personnel to perform tape rotations (installing and maintaining system backups to tape), but these people will not be involved in Exchange management.

When Exchange 2000 is deployed, administrators in Richmond will manage all computers running Exchange across the entire company.

Internet Access to E-Mail

Fabrikam employees use GroupWise WebAccess to view their mailboxes over the Internet with a Web browser. This remote access functionality must be maintained after migration.

Chapter 2 covers designing your Outlook Web Access deployment in more detail, and Chapter 3 covers deploying and configuring Outlook Web Access.

External Entities

As discussed earlier in the "User Distribution" section, external entities are objects in the GroupWise system that do not have a security principal associated with them. An example of an external entity is the Information Services mail account that receives feedback mail from customers and sends mail on behalf of the IS department. This account is not associated with a particular user in NDS, but it can be accessed by a number of users (and mail is sent as coming from that user).

Group Calendars

In GroupWise, Fabrikam can support group calendars, where a department or team can schedule activities on a calendar that is viewable by everyone. Employees will need this functionality in Exchange 2000, along with the ability to delegate management of a group calendar to one or more people. Also teams need security in their group calendars so that only designated users can access, read, update, or delete meetings.

Distribution Lists

Distribution lists are lists of users who receive e-mail as a group. Messaging administrators create and maintain these lists. After migrating to Exchange 2000, Fabrikam wants to continue using nested distribution lists so administrators can re-create their current distribution list design (as shown in Figure 1.5).

Figure 1.5: Distribution lists in the Fabrikam GroupWise system

Besides re-creating this nested structure, the new Exchange 2000 system must provide administrators the ability to restrict who can send e-mail to particular distribution lists, for example, to prevent inappropriate mail being sent to company-wide distribution. This restriction would also prevent "mail storms," or a great deal of unnecessary mail traffic, caused by users replying to company-wide distribution lists.

Finally, the Exchange 2000 system has to be able to hide distribution lists from the directory so that unauthorized users cannot view distribution lists membership in their global address list (GAL).

Fabrikam users also have created personal distribution lists in their mailboxes.

End User and Client Requirements

The following sections describe the needs Fabrikam end users (employees) will have in their new Exchange 2000 system. The migration team plans to install Windows 2000 Professional (with the latest service packs) and Outlook 2000 on all workstations.

Offline Synchronization

Portable computer (for example, a laptop computer or a notebook computer) users must be supported following migration. When connected to the network, client computers must be able to synchronize e-mail, calendar items, and address books with the computers running Exchange. When portable computers are offline, Fabrikam employees still need to be able to read, create, and manage e-mail, and they need to be able to look up people in the global address list (GAL).

Personal Digital Assistant (PDA)

Approximately one-quarter of Fabrikam's employees use Pocket PCs and Palm connected organizers (also known as Palm PCs). These employees want to continue accessing their mailboxes with their PDAs after Exchange 2000 is deployed.

Resources

The dining room staff managed the Fabrikam conference rooms. Fabrikam wants its employees to be able to schedule the conference rooms using Exchange. The company wants to provide the ability for users to search for conference rooms, check the availability of the conference rooms, and schedule the rooms without having to involve the dining room staff.

Antivirus

Fabrikam currently has no antivirus software installed on its GroupWise servers. When Fabrikam's Exchange migration is complete, however, Fabrikam wants to scan both incoming and outgoing messages for viruses. The company also wants to clean out its Exchange e-mail databases if the databases become infected.

Pager

Network administrators currently receive pages about system conditions through the Novell Pager gateway. Custom scripts monitor Fabrikam servers and send automatically generated messages to the SMTP gateway with specific keywords in the subject line. In their GroupWise clients, administrators set up rules so that when messages arrive with these keywords, the messages are sent to the pager gateway. The pager gateway has an analog modem interface that relays the messages to the administrators' pagers.

The SMTP-to-pager interface of this system also allows users to send a page directly from a client computer.

While Exchange does not provide this paging capability, the Fabrikam migration team installed a third-party application to provide this feature.

Backup

Fabrikam currently uses SuperDuperBackup by A. Datum Corporation. This company is releasing a new version of its product that is able to back up Exchange 2000.

This product needs to be tested in the lab.

Planning Phase Wrap-Up

After capturing all of the information about Fabrikam's requirements and existing infrastructure, the migration team created a document called the Functional Specification. This document was reviewed by all migration team members as well as Fabrikam management. After reviewing the document, Fabrikam management approved the document and gave the authorization to proceed to the developing phase of the project.

By the end of the planning phase, the following deliverables were produced:

• Migration team assembled.

• Project work area established (computers allocated, network established).

• Functional specification document completed and signed off containing:

  • Fabrikam's vision for the new architecture.

  • Fabrikam's business and technical requirements for the new system.

  • Fabrikam's existing technical architecture including any planned changes.

  • Fabrikam's project plan and schedule.

• Risk management process started.

Planning Phase Questionnaire: Determine Your Migration Goals

Use the questions in Table 1.8 to aid your analysis of your own business needs and migration requirements. It is recommended that you fill this questionnaire out before moving on to the next phase, which covers developing the solutions for all business and infrastructure requirements developed in the planning phase.

Table 1.8 Planning phase questionnaire

	Question	Response
1	How many physical locations does your company have? How many users are at each location? Of these users, how many use e-mail?
2	What is the network topology of your network? What are the network link speeds between the physical locations? What is the current usage (peak and average) of each of the links? Where are the Internet access points located? For Web traffic? For SMTP traffic?
3	What is your messaging topology? Where are your mail servers located? How heavily used are they? How much mail is stored on each? How many users does each server service? Do your users have access to e-mail through the Internet? Do you want this capability with Exchange?
4	What is the average daily usage of the Web-based e-mail access? What should the URL of the new Web-based e-mail system be?
5	What DNS MX entries are entered for your company?
6	What are the mail gateways used by your company?
7	How many of the following you do have: · User accounts · External entities · Group calendars · Distribution lists
8	What is your current e-mail addressing standard? What is the planned future e-mail addressing standard? Is it possible that the company will choose a new domain name for the new Exchange system?
9	What are the current mailbox size limits? What are the planned future mailbox size limits?
10	Are there current automatically archive or automatically delete mail policies in place that remove old mail items in the user's e-mail? What are the requirements of the Exchange system regarding automatically archiving or automatically deleting e-mail?
11	What is the configuration of your current e-mail servers (CPU, memory, disk space, and so on)?
12	What, if any, should be the deleted item recovery period?
13	What, if any, should be the deleted mailbox recovery period?
14	What are the message size limits allowed through your Internet mail gateway? · For inbound messages? · For outbound messages? · Between remote locations?
15	Do you have portable computer users who access e-mail through dial-up connections? · Do they use the "Hit The Road" GroupWise feature and will they want the similar capability in Outlook?
16	Do you have PDAs in use at your company? · What type of PDA is used? · What software package is used to synchronize the PDA with GroupWise? · Does this software package work with Exchange?
17	Are conference rooms scheduled through GroupWise?
18	Do you have any antivirus requirements?
19	Are you using the GroupWise Pager gateway?
20	What backup tool are you currently using? · Does it have an Exchange backup agent?

Chapter 2 Developing

In the developing phase, the migration team used the information they gathered during the planning phase about Fabrikam Worldwide, Inc.'s existing Novell GroupWise environment. Solutions were scoped out for each of the messaging requirements defined during the planning phase (see the "Design Goals and Requirements" section in Chapter 1). After the team identified these Exchange solutions, the team completely designed every aspect of its Microsoft® Exchange 2000 Server organization. The migration team concluded the developing phase with the completion of the Microsoft Exchange System Design plan and approval from Fabrikam management to proceed.

This chapter describes the Exchange solutions for Fabrikam's messaging requirements and the methodology behind all of Fabrikam's Exchange-related decision making. These decisions include:

• Naming standards

• Hardware requirements

• Routing and administrative group designs

• Storage group designs

• System policies

• Public folders

This chapter also introduces the concept of Exchange-to-GroupWise interoperability (also known as "coexistence") and discusses the closely related concept of migrating objects permanently to Exchange.

The migration team went through many design iterations in creating the various Exchange organizational components, including extensive testing in its dedicated test lab. After extensive planning and testing, the team finalized the design and submitted it to Fabrikam management. After everyone agreed to and approved the design, the team proceeded to the next phase: deploying (covered in Chapter 3).

Table 2.1 provides an overview of the developing phase.

Table 2.1 Developing phase overview

Resources	Tasks	Key deliverables
· Functional specification document · Migration team · Risk management plan · Project plan	· Translate vision, business, and technical requirements into system design. · Design Exchange architecture to meet technical requirements. · Design GroupWise-to-Exchange coexistence architecture. · Design GroupWise-to-Exchange migration architecture. · Order production hardware. · Develop test plan. · Develop test lab to mimic production environment. · Test Exchange architecture, Exchange-to-GroupWise coexistence architecture, and Exchange-to-GroupWise migration architecture. Develop working prototype system. · Update and manage risk assessment. · Update project plan. · Develop end-user training plan. Identify resources (classrooms, computers, and so on). · Develop administrator training. Train administrators, including help desk support team. · Develop deployment plan indicating which users migrate and when the migrate. · Create checklists to build production environment. · Develop and implement communication plan to users to inform them of new system, address concerns, and so on.	· Logical design specification document and detailed design specification document. · Test plan completed. · Test lab containing all system components built. · Risk assessment updated. · End-user training plan and materials prepared. · Deployment plan and migration checklists prepared. · Help desk support team trained to support Microsoft Outlook® users. · Administrators trained to support Exchange. · Production hardware acquired. · Communication plan sent to end-users. · Fabrikam management gives approval to proceed to deploying phase (Chapter 3).

Fabrikam Active Directory Design

Although this paper focuses on Fabrikam's Exchange organization, the design of your Active Directory® directory service is crucial to the success of your Exchange deployment. By experience, Microsoft Consulting Services (MCS) learned that a lot of Exchange deployment problems originate from either an improperly designed Active Directory and Domain Name System (DNS) design, or a domain controller and global catalog server architecture. Therefore, it is very important to give equal diligence to both your Active Directory design and your Exchange design.

While designing the Exchange organization, the Fabrikam migration team was in constant communication with the Active Directory team. The migration team was involved in many key Active Directory design decisions. In the logical design, Exchange dictated the DNS structure and the global catalog server and domain controller placement. In the physical design of Active Directory, Exchange influenced the Microsoft Windows® 2000 site design.

Another key example of how Exchange influenced the Active Directory design decision was when the Fabrikam Active Directory team developed a multiple domain design for Fabrikam within a single forest; they made this decision because an Exchange organization cannot go beyond a single Active Directory forest.

The domain design the Active Directory and Exchange migration teams developed consisted of a root domain and a child domain. The designated root domain named fabrikam.com was specified as a placeholder domain, which meant it would not contain any end-user accounts. The root domain contained only the accounts of a few key administrators. With a limited number of administrators in the root domain, the number of people who could make changes to the Active Directory schema was kept to a minimum. In this design, a broader set of administrators could exist in the child domain, none of whom has the permissions to affect the schema.

Below the fabrikam.com root domain, the team created a child domain called corp.fabrikam.com. This child domain contained all the user accounts and the Exchange servers. In each of these domains, the Active Directory team installed two domain controllers, which also acted as global catalog servers. Then the Flexible Single Master Operations (FSMO) roles were split across the domain controllers and global catalog servers, based on best practices for Active Directory design as found in the Windows 2000 Server Deployment Planning Guide, in the Microsoft Windows 2000 Server Resource Kit.

Note: For more information about operations master roles, see 197132, "Windows 2000 Active Directory FSMO Roles," in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=3052&ID=197132.

Figure 2.1 displays the logical design of Fabrikam's Active Directory deployment, with emphasis on the aspects that will affect Exchange 2000. These aspects include domain controllers, global catalog servers, FSMO role placement, as well as Windows Internet Name Service (WINS), DNS, and Dynamic Host Configuration Protocol (DHCP) server placement.

Figure 2.1: Logical design of Fabrikam's Active Directory

Because Fabrikam decided to use Windows 2000 global security groups for its distribution lists, it was critical that, to expand a distribution list, each Exchange server used a global catalog server located in the same domain as the distribution list being expanded. The design illustrated in Figure 2.1 ensures sufficient global catalog server availability.

For more information about global catalog issues related to Exchange, see Chapter 9, "Preparing a New Environment," as well as Part 5, "Advanced Deployment Planning," in Microsoft Exchange 2000 Server Resource Kit.

The domain controller and global catalog servers in the root domain were placed in a separate Windows 2000 subnet from the domain controllers and global catalog servers in the child domain (see Figure 2.2). For distribution list expansion, Exchange uses global catalog servers in the local site first. The designs in Figure 2.1 and Figure 2.2 ensure that Fabrikam's Exchange 2000 servers are always able to expand the membership of Windows 2000 global security groups.

Figure 2.2: Setting up domain controllers and global catalog servers in the Windows 2000 environment

Note: Soon after Exchange implementation, administrators will switch both Windows 2000 domains to native mode because Fabrikam's Windows 2000 forest contains no Microsoft Windows NT® or earlier domain controllers.

Components of the Developing Phase

The developing phase of the Exchange migration consisted of three major components, described in Chapter 2. Those components are as follows:

• Exchange architecture The design and setup of the Exchange organization. The Exchange architecture must meet the design requirements identified during the planning phase (Chapter 1). After completion, the Exchange messaging system is operational in the production environment.

• GroupWise-to-Exchange 2000 interoperability architecture The coexistence of GroupWise and Exchange. The interoperability architecture enables directory synchronization, mail transfer, and calendar communication between the GroupWise and Exchange systems. After interoperability is established, Fabrikam GroupWise users can be migrated to Exchange with minimal business interruption. Also, users on either system can send mail to each other and schedule meetings as if they were on the same system.

• GroupWise-to-Exchange 2000 migration architecture The setup of the migration architecture. The migration architecture provides the tools to perform the migration of mail, calendar, and personal address data from GroupWise to Exchange.

Exchange Architecture

Fabrikam had many requirements for its Exchange messaging system, as described in the "Design Goals and Requirements" section in Chapter 1. In the developing phase, the migration team first delineated the Exchange feature or features that would meet these requirements.

GroupWise-to-Exchange Component Mapping

The migration team matched up its GroupWise software components with their corresponding Exchange components. Table 2.2 provides an overview of the Exchange component solutions for the Fabrikam messaging system.

Table 2.2 Component overview

Feature	Existing component	New component
Mailbox server	GroupWise 5.5 Server	Exchange 2000 Server
Web access to e-mail	GroupWise WebAccess	Microsoft Outlook® Web Access
Fax gateway	Third-party program	Exchange 2000 certified third-party program
Pager gateway	Novell Pager Gateway	Exchange 2000 certified third-party program
SMTP gateway	GroupWise Internet Agent (GWIA)	Exchange 2000 SMTP connector
Mail client	GroupWise client	Outlook 2000
Mail antivirus	None	Exchange 2000 certified third-party virus protection program
Backup and restore	Third-party program	Exchange 2000 certified third-party program

Note: For more information about third-party programs that are compatible with Exchange 2000, see the "Exchange 2000 Third-Party Solutions" Web page at https://go.microsoft.com/fwlink/?LinkId=5225.

Key Messaging Parameters

The migration team identified a number of messaging parameters that required decisions from the Fabrikam management. These parameters include:

• Mailbox size limits

• Client and server recovery periods

• Message size limits

• Local archives

• Centralized administration

• Internet access to e-mail

• External entities

• Distribution lists and personal distribution lists

The following sections contain Exchange solutions for each of Fabrikam's messaging requirements, and how management wanted to apply each of the solutions. For more information about these messaging requirements, see "Exchange 2000 Requirements" in Chapter 1.

Mailbox Size Limits

By using the Exchange System Manager snap-in in Microsoft Management Console (MMC), administrators can set a variety of mailbox properties. For more information about the procedure for setting mailbox size limits, see "Mailbox Size Limits" in Appendix A.

A key component of the Exchange design comes from determining each user's mailbox size limit—the amount of mail data each Fabrikam user would be allowed to store on the server running Exchange. Much of the Exchange design comes from setting this limit appropriately. Fabrikam based the design according to the current mailbox usage before the migration.

The migration team examined the current GroupWise mailbox usage and examined each GroupWise server to determine the mail database size for each user. Based on this analysis, Fabrikam determined that 90 percent of its users had less than 125 MB of mail data (see Figure 1.4) and, therefore, set the Exchange mailbox limit for most users at 125 MB. For more information about important mail migration issues, see "Migration Considerations" later in this chapter.

Client and Server Recovery Periods

This section covers the recovery periods Fabrikam requested for both the client and server sides of its Exchange organization. Table 2.3 summarizes the recovery periods for deleted items.

Table 2.3 Summary of Fabrikam's deleted items recovery periods

Type of recovery period	Duration of recovery period and action when period expires
Server: Mail retention	45 days, after which time, move mailbox items to client's Deleted Items folder.
Server: Deleted Items folder cleanup	7 days, after which time, remove the items from the Deleted Items folder.
Client: Deleted Items recovery	3 days, after which time, the user cannot recover the item. At this point, administrators must recover these items for users from backup tape.
Total	55 days

Mail Retention Period

Exchange Mailbox Manager, available in Exchange 2000 Service Pack 1 (SP1) and later, can dictate mail retention policies across all mailboxes on computers running Exchange, and can be run manually or at regular intervals.

Fabrikam did not want to retain mail older than 45 days on the server running Exchange, and requested that Exchange automatically move mail older than 45 days into users' Deleted Item folders. This requirement can be handled by Mailbox Manager. For more information, see "Create a Mailbox Recipient Policy (Mailbox Manager)" in Appendix A.

Administrators can use Mailbox Manager to make sure Fabrikam users stay within their 125 MB mailbox size limit by automatically deleting messages that exceed a predetermined size limit. By deleting old or oversized mailbox items, administrators can ensure that disk space dedicated to mailbox databases is used more efficiently. For complete information about Mailbox Manager, see the Exchange 2000 online documentation.

Deleted Items Folder Cleanup Period

Mailbox Manager can delete items in any folder in a user's mailbox, including the Deleted Items folder. Administrators can apply the same message age and message size limits to the Deleted Items folder as to other mailbox folders, or they can apply unique limits to the Delete Items folder. These settings determine how long users can store mail in their Deleted Items folder before those items are permanently deleted.

At Fabrikam, after Mailbox Manager ran and placed items older than 45 days into each users' Deleted Items folder, users still had time during which they could recover deleted items. Fabrikam management specified that it wanted to keep only 7 days of mail in the users' Deleted Items folders. After 7 days, the messages would be deleted from the Deleted Items folders.

For more information on how Fabrikam configured Mailbox Manager to meet these needs, see "Create a Mailbox Recipient Policy (Mailbox Manager)" in Appendix A.

Deleted Items Recovery Period

Fabrikam requested items be permanently removed from the server running Exchange after 3 days. This additional 72 hours allows users to recover deleted items. In Outlook, when the deleted items folder cleanup period expires, the item is still not permanently deleted. Even after the user either deletes an item from the Deleted Items folder or empties the Deleted Items folder, the item is still not permanently deleted. Instead, the item is temporarily stored on the server running Exchange, even though it's hidden from the user. If the user needs to recover an item they deleted from the Deleted Items folder, they can recover it through Outlook without involving Fabrikam's e-mail administrators.

Outlook 2000, when used with Exchange 2000, allows users to recover items they deleted (either automatically or manually) from the Deleted Items folder without the need of administrator assistance.

Deleted messages are retained on the Exchange server for a recovery period that you can set with the Keep deleted items for setting, on the Limits tab of the Mailbox Store Properties dialog box. Fabrikam configured this recovery period to 3 days.

In Exchange 2000 SP 2 or later, Outlook Web Access also provides the ability to recover deleted items. As with Outlook clients, the Keep deleted items for setting on the Exchange server dictates the amount of time users have to recover an item. To recover a deleted item, in the Deleted Items folder, Outlook Web Access users can click the Recover Deleted Items button on their Outlook Web Access tool bar. Users can also go to the Outlook Web Access Options page and, under Recover Deleted Items, click View Items.

Figure 2.3: Recover Deleted Items button on the Deleted Items folder toolbar in Outlook Web Access

For more information about recovering deleted items in Outlook or Outlook Web Access, or about setting the deleted items recovery period, see "Deleted Items Recovery" in Appendix A.

Deleted Mailbox Recovery

In Exchange 2000, it is possible to recover a deleted mailbox for a specified period of time, provided the following two conditions are both true:

• The Windows 2000 user account associated with the mailbox was deleted through the Windows 2000 Active Directory Users and Computers snap-in console.

• The Exchange mailbox was not deleted through Exchange System Manager.

If both conditions are true, the mailbox is marked as unowned. You can re-create the user account in Active Directory Users and Computers, and then link the unowned mailbox to the account. For more information about recovering a mailbox, see "Recover a Deleted Mailbox" in Appendix A.

If System Manager was used to delete the mailbox, you need to recover the mailbox from a backup tape. For more information about how to recover a single mailbox, see the Exchange Up-to-Date article Mailbox Recovery for Microsoft Exchange 2000 Server on the Web at https://go.microsoft.com/fwlink/?LinkId=5216.

Fabrikam decided to set the mailbox recovery period to 30 days.

Message Size Limits

Fabrikam wanted to impose message size limits on both internal messages and messages addressed to external domains. The migration team next determined the message size limits on both internal messages and messages addressed to external domains. After consulting with the network administrators to review the company's current network bandwidth usage, the team decided to set the following limits:

• Maximum message size sent internally: 25 MB.

  Additionally, all messages larger than 10 MB should be delivered during non-working hours (between 5 P.M. and 9 A.M.).

• Maximum message size sent externally: 5 MB.

  Additionally, Fabrikam wanted to grant a certain set of users the ability to send messages larger than 5 MB (and up to 10 MB) outside the company. Table 2.4 summarizes these message size limits.

Table 2.4 Fabrikam's message size limits

Type of size limit	Limit
Messages sent internally	25 MB, with messages larger than 10 MB delivered during non-working hours
Messages sent externally (outside the firewall)	5 MB
Executive team's external messages	10 MB

For internal messages, Fabrikam can use Global Settings in System Manager to set the preferred maximum message size of 25 MB and to set the schedule for delivering messages larger than 10 MB. Global Settings affect all SMTP virtual servers across the organization. For more information about setting the internal message size limits, see "Message Size Limits" in Appendix A.

For external messages, Fabrikam administrators can set the 5 MB message size limit on their SMTP connector. For more information about setting the external message size limits, see "SMTP Connectors" in Appendix A.

To set a larger size limit (10 MB) for a select group of users (mostly Fabrikam executives), administrators installed a second SMTP connector and configured it to allow sending of 10 MB messages. However, only the executive group is allowed to transmit through this connector. For more information about SMTP connectors, see "SMTP Connectors" in Appendix A.

Local Archives

Although it is possible to migrate archives from GroupWise to Exchange using third-party tools, MCS has not tested this method.

As another option, users could convert their archives back to standard mail data, and then have that data migrated along with the rest of their mailbox items. However, given the possible volume of archived items across the entire company, this option could seriously impede network performance and greatly increase the total migration time. For these reasons, Fabrikam decided not to migrate GroupWise archives.

However, company executives were the exception. Management requested that it be allowed to migrate mail in local archives. To allow this migration to occur, the Fabrikam migration team turned off the automatic archiving rule so that executives could converts their local archives back to standard mail data and migrate it along with their normal mail. To make this process as efficient as possible, the Fabrikam migration team required that the executives delete any unneeded messages prior to migration.

Centralized Administration

Fabrikam wanted a centralized group to be able to manage their entire Exchange organization. For more information about how the Exchange 2000 Administrative Groups will provide centralized administration, see "Exchange 2000 Setup" later in this chapter.

Internet Access to E-Mail

Outlook Web Access is installed by default with Exchange 2000. Outlook Web Access allows employees to manage e-mail, calendar, contacts, and other Outlook items through their Web browsers. Additionally, the migration team plans to configure Outlook Web Access to use secure sockets layer (SSL) encryption, which protects passwords and other information from being exposed on the Internet.

Fabrikam employees will access their e-mail by typing the following URL in their browsers:

https://webmail.fabrikam.com

The system will automatically redirect the user to a secure, 128-bit encrypted connection at:

https://webmail.fabrikam.com

To allow both Exchange and GroupWise users Web access to their e-mail, you must use a different domain name for your Exchange environment than you have been using for GroupWise. In Fabrikam's case, one of the company's migration goals was to change its corporate identity from Fabrikam Worldwide (with the domain name fabrikamworldwide.com) to Fabrikam (fabrikam.com), so this change to accommodate Outlook Web Access was easy.

External Entities

The GroupWise directory is separate from the Novell Directory Services (NDS) directory (similar to how the Exchange 5.x directory was separate from the Windows NT directory). Because of this duality, there could potentially be two objects for each user (the Novell NDS object and the GroupWise object) and, therefore, two user IDs and two passwords. When you run both Windows 2000 and Exchange 2000, there is only one object per user. For each GroupWise external entity, a Window account will be created and given an Exchange 2000 mailbox. This account will be given minimal network access rights, but one or more users will have full access rights to each accounts' Exchange 2000 mailbox.

The other function of external entities is group calendars. Group calendars will be supported in Exchange in a similar manner. Multiple users will be given permissions to a mailbox-enabled Windows 2000 account.

Because external entities, after migration, are represented as user accounts in Active Directory, the process for migrating mail data for external entities is the same as for GroupWise users. When migration is finished, the migration team must grant proxy access rights to the external entities to all appropriate users.

Distribution Lists and Personal Distribution Lists

The new Exchange 2000 system must provide administrators the ability to restrict who can send e-mail to particular distribution lists. For example, restricting who could send e-mail would prevent inappropriate e-mail from being sent to company-wide distribution list. Restricting who could send e-mail would also prevent "mail storms" (when the network is flooded by unnecessary e-mail) caused by users replying to company-wide distribution lists. For more information about restricting who can send e-mail to a distribution list, see "Distribution Lists" in Appendix A.

At the time of Fabrikam's migration, no tools existed that directly migrated personal distribution lists. Instead, Fabrikam employees recorded their personal distribution lists, and then re-create them in Outlook.

Exchange 2000 Setup

The following sections describe each step the Fabrikam migration team took to design and implement its Exchange 2000 organization. This section provides guidelines for naming conventions (a logical and intuitive system for naming every major Exchange object in your Active Directory), as well as a template for organizational, administrative, and routing group designs. Also covered are storage group design, hardware requirements, Exchange 2000 system policies, and setting up public folder hierarchies.

Naming Conventions

Microsoft Consulting Services recommends using predefined naming conventions to name everything in your Exchange organization, from your organization (for example, Fabrikam or Microsoft) all the way down to routing groups and e-mail addresses. Standards make a messaging system easier to manage, maintain, operate, and troubleshoot, especially in larger organizations. For example, in a multiple-server environment with no server naming standards, an administrator may find it difficult to immediately identify the Exchange servers. Similarly, if a randomly named server had problems, an administrator would not be able to tell which applications were affected, or possibly even where the server was located.

Restricted Characters

Exchange does not accept certain characters in the display names of some objects. When you name your Exchange objects, these restricted characters should be one of your first considerations. Table 2.5 lists the restricted characters you cannot use in the name of an Exchange organization and its administrative groups.

Note: This information is also available in the Exchange 2000 release notes. Microsoft recommends reading the release notes for Exchange 2000 and all subsequent service packs to ensure that these standards have not changed.

Table 2.5 Exchange 2000 restricted characters

Symbol	Description
#	Number sign
;	Semicolon
,	Comma
" "	Quotation marks
/	Forward slash
\	Backward slash
< >	Angle brackets
+	Plus sign
*	Asterisk
•	Bullet
|	Vertical bar, pipe
[sect]	Section
[para]	Paragraph
$	Dollar sign
^	Circumflex, carat
{ }	Braces
~	Tilde
`	Grave accent
!	Exclamation point
@	At sign
%	Percent
&	Ampersand
( )	Parentheses
_	Underscore
=	Equal sign
[ ]	Brackets
'	Single quotation mark
?	Question mark

Unicode and double-byte character set (DBCS) strings are acceptable, as are embedded spaces (" ") and hyphens ("-"). During an Exchange 2000 installation, the Exchange System Administrator enforces these naming rules for new installations of Exchange 2000, as well as for upgrades from Microsoft Exchange Server version 5.5.

If you are upgrading to Exchange 2000 and have an organization name or Exchange 5.5 site name that contains any of the characters in Table 2.5, you must change the display name of the affected object before you run Exchange 2000 Setup.

Do not use the restricted characters in the following Exchange objects:

• Policies

• Address lists

• Offline address lists

• Routing groups

• Storage groups

• Mailbox stores

• Public folder stores

• SMTP and X.400 connectors

• Public folder hierarchies

Although the characters in Table 2.5 are not prohibited in other Exchange object names, avoid the use of such special characters whenever possible.

Organization Naming Standard

The organization name is the top-level Exchange object in Active Directory. Microsoft Consulting Services recommends using names that are as short as possible, but also intuitively descriptive of the organization that is installing Exchange. Keep the following two rules in mind when you name your organization:

• You cannot change the organization name after it is set.

• You can install only one Exchange organization per Active Directory forest.

• The organization name is case-sensitive.

For Fabrikam Worldwide, Inc., the migration team recommended the organization name Fabrikam.

Administrative Group Naming Standard

In Exchange 2000, an administrative group is a collection of Active Directory objects (such as servers, routing groups, public folder hierarchies, and policies) that are grouped together for the purpose of permissions management. You can use a maximum of 64 characters for administrative group names (excluding the characters in Table 2.5). It is important to note that, when recovering from any kind of data or hardware failure, the organization name and administrative group names on the backup tape must match those names in the data you attempt to recover.

Because the Fabrikam migration team decided to use only one administrative group (discussed later in this chapter in "Exchange 2000 Administrative Group Design"), the team went with the default name of First Administrative Group.

Routing Group Naming Standard

Routing group names should be unique and named by geographic or physical location, or by function. You can use a maximum of 64 characters for routing group names (avoid the characters in Table 2.5). Based on the routing group architecture ultimately determined by the migration team (discussed later in this chapter in "Exchange 2000 Routing Group Design"), the team recommend a standard of Location RG, where Location is a two-letter abbreviation for the location of the routing group, followed by a space before "RG". For example, the routing group in the main office in Richmond was named RI RG. In Alexandria, AL RG.

Routing Group Connector Naming Standard

To communicate with one another, Exchange routing groups must be connected by one of several types of routing group connectors. You can use a maximum of 64 characters for routing group connector names (avoid the characters in Table 2.5). Fabrikam decided the name of each routing group connector will consist of the starting and ending locations of the routing group connector. The resulting standard was Location-Location RGC. For example, the routing group connector between Richmond and Alexandria was named RI-AL RGC.

Server Naming Standard

While server names can be changed when necessary, it is not an easy thing to do (you must completely reinstall Exchange). For this reason, Microsoft Consulting Services recommends that you consider server names with the same carefulness that you use to plan and designate your Exchange organization name. Network administrators must be able to readily identify Exchange servers in their enterprise. This ability to readily identify Exchange servers is why a server-naming scheme is particularly important. In addition, server names must be unique.

Note: Exchange Setup automatically uses the Windows 2000 server name for the Exchange server name. Although you can change the name of the computer running Windows 2000 Server through Network and Dial-up Connections in Control Panel, doing so prevents the server running Exchange from starting and functioning correctly. If the Exchange server name was changed through the Network Control Panel, you can restore server functionality by resetting the server name to the original name. Therefore, it is important to plan the names of your computers running Exchange before installation.

Important: Windows 2000 and Exchange 2000 primarily use DNS for name resolution, but network operations that use NetBIOS names are still common. Because NetBIOS names cannot be longer than 15 characters, make sure your Exchange server names do not exceed 15 characters.

The Fabrikam migration team developed the following naming standard to provide network and system administrators easy identification of the function, location, and number of servers located throughout the company:

Function-LocationSeqStatus

• Function Designates the function of the server. The most common uses at Fabrikam are:

  • MSG = Exchange mailbox servers

  • MSGBRDG = Exchange bridgehead servers

  • MSGWEB = Exchange front-end server (at Fabrikam, used primarily for Outlook Web Access)

  • DC = domain controller

• Location Uses the same two-letter abbreviations for each Fabrikam office location. This portion of the name designates the physical location of the server.

• Seq Numbers the servers sequentially for when there are multiple computers performing the same function in one location.

• Status Defines the current status of the server, as described in Table 2.6.

Table 2.6 Server naming standard-server status

Status	Meaning
P	Production A server used in an organization's production environment.
D	Development These servers are on a separate network from the production network. Development servers are used to develop and test changes to the network or messaging architecture before those changes are deployed in the production environment.
R	Recovery A server used in backing up and restoring data if any kind of data or hardware failure should occur on a production computer.

After the migration team decided on the naming convention, they proceeded to name the servers. Richmond, which is Fabrikam's main office, has two Exchange servers, a front-end server for Outlook Web Access, a bridgehead server, and two domain controllers. The team named these servers:

• MSG-RI01P

• MSG-RI02P

• MSGOWA-RI01P

• MSGBRDG-RI01P

• DC-RI01P

• DC-RI02P

Fabrikam's Alexandria office has one server running Exchange. The team named this server:

• MSG-AL01P

By using this naming convention, a Fabrikam network administrator who has little knowledge of the Exchange messaging system can identify each server in any context, know what the function is of each server, and know where the location is of each server in the enterprise.

User Account

Each user account needs to have the following fields defined:

• First name

• Initials

• Last name

• Full name (by default, Windows 2000 generates Full name from the first name, middle initial, and last name)

• User logon name

Figure 2.4 illustrates a new user record in Windows 2000. For each Fabrikam employee, the user logon name will be the same as his or her NDS logon name.

Figure 2.4: User naming conventions

User Internet E-Mail Standards

Internet e-mail addresses are in SMTP format and allow users to receive e-mail messages when connected to the Internet (from outside the firewall). All Fabrikam employees who have a valid GroupWise or Exchange 2000 mailbox will have a unique Internet (SMTP) e-mail address.

The Fabrikam standard for e-mail addresses in the GroupWise messaging system was user-alias@fabrikamworldwide.com. Management requested changing this e-mail naming standard to firstname.lastname@fabrikam.com.

The Fabrikam migration team used the following steps when it generated Internet e-mail addresses.

1. Try to create the Internet alias using firstname.lastname@fabrikam.com.

2. If this alias is already in use, try to create the Internet alias using firstname.middleinitial.lastname@fabrikam.com.

3. If this alias is already in use, try to create the Internet alias using firstname.middlename.lastname@fabrikam.com.

4. If all of these aliases are already in use, the administrator creating the account must contact the user and decide on an Internet alias that conforms to Fabrikam's naming standards.

Exchange 2000 Conference Room Naming Convention

Each Fabrikam conference room has an account in Active Directory; this account will be mailbox-enabled with an Exchange 2000 mailbox. The conference rooms will serve as a place or object that users can schedule.

All Fabrikam conference rooms will be created and entered in Active Directory according to the following naming convention: CRLocationnnnn. Conference room names will begin with CR so that they are readily identifiable in the directory. Location indicates the Fabrikam office where the conference room is located, and nnnn represents the room number of the conference room.

For example, a conference room named CRRI2143 is located in room 2143 in Richmond. In Active Directory, administrators created a new user and filled in the fields as follows:

• First name Piedmont

• Last name Conference Room Richmond

• User logon name CRRI2143

Distribution Group Naming Convention

In Exchange 2000, distribution groups are objects in Active Directory that are mailbox-enabled with an SMTP address. Distribution groups contain members and do not have security rights. For Fabrikam's purposes, distribution groups are the equivalent of a GroupWise or Exchange 5.x distribution list.

All Fabrikam distribution lists will be re-created in Exchange according to the following naming convention:

• Dashes will be used instead of spaces when connecting multiple words together in the alias and display name.

• Names will be limited to 50 characters.

• For simplicity sake, the naming convention matches the current GroupWise distribution list naming convention. To deter unsolicited and unwanted e-mail (also known as junk or spam e-mail) and for other security reasons, Internet users will not be able to send e-mail to Fabrikam distribution lists.

Even though the best practice in a multiple domain environment is to use universal groups for distribution lists, Fabrikam wanted to use global groups. The membership of universal security groups is stored on all global catalog servers throughout the forest, which is why universal security groups are recommended for distribution lists. Fabrikam was concerned that, if it acquired another company and set up a separate domain for that company, administrators and users in the other domain could see the membership of Fabrikam distribution lists by looking at the global catalog in their own domain. In contrast, the membership of a global group is not stored in the global catalog. Therefore, the acquired company could not view the membership of Fabrikam distribution lists.

By choosing to use global groups, however, Fabrikam had to take extra care to ensure that Exchange would use the correct global catalog servers for distribution list expansion. If Exchange uses an incorrect global catalog server for distribution list expansion, the distribution list may not expand, and users on the distribution list would not receive the message. Because of this concern, the migration team decided to place the Exchange servers in a Windows 2000 subnet separate from the forest root domain and any other future domains.

Additional Naming Standards

Table 2.7 lists the remaining naming standards adopted by Fabrikam.

Table 2.7 Additional naming standards

Area	Naming standard	Example
Storage Group	<Ordinal> Storage Group	First Storage Group
Address Lists	<Grouping> Address List	NetworkAdmin Address List
Mailbox Store	Mailbox Store nn	Mailbox Store 01
VIP Mailbox Store	VIP Mailbox Store	VIP Mailbox Store
Public Folder Store	Public Folder Store nn	Public Folder Store 01

Exchange Server Drive Letter

For the purposes of clarity and consistency, Microsoft Consulting Services recommends that the drives on all computers running Exchange in your organization be labeled the same.

For more information about drive letters, see "Exchange Server Hardware Planning" later in this chapter.

Exchange 2000 Operation Mode

Exchange 2000 operates in two modes: mixed mode and native mode. Mixed mode provides compatibility with Exchange 5.5 and earlier, and native mode offers full Exchange 2000 functionality. By default, Exchange 2000 installs itself in mixed mode because native mode requires that all servers running Exchange be running Exchange 2000 Server. To switch to native mode, right-click the organization object in System Manager, and then click Change Mode. Remember, when you switch to native mode, you cannot go back to mixed mode.

Because no Exchange 5.5 servers exist at Fabrikam, the migration team recommended that the servers running Exchange 2000 be switched to native mode as soon as possible during the migration.

Exchange 2000 Schema Extensions

Before you install Exchange, you must prepare the Active Directory schema for Exchange, and you must also prepare each domain into which you plan to install Exchange. To prepare your organization, you must use two command-line utilities: ForestPrep and DomainPrep. You run ForestPrep once on each forest to extend the Active Directory schema. You run DomainPrep once on each domain to identify the address list server and to set permissions within the domain. You do not need to run DomainPrep in a domain until you are ready to install Exchange.

Exchange 2000, through the ForestPrep utility, makes approximately 1,000 schema changes to the Active Directory schema. The person who runs the ForestPrep utility must:

• Be a member of the Windows 2000 Schema Admins group and Enterprise Admins group. Only Schema Admins members have the necessary permissions to be able to modify the Active Directory.

• Run the ForestPrep utility in the same domain where the schema master resides. The schema master, by default, resides on the first Windows 2000 domain controller installed in the forest.

Warning: ForestPrep causes a lot of replication traffic and may take some time to run, depending on the size and topology of your organization. Because the schema is stored on every global catalog server, running ForestPrep causes the schema extension changes to be replicated to every global catalog server. If your global catalog servers are located across the WAN, this replication may cause large amounts of WAN traffic. Therefore, Microsoft Consulting Services recommends that you run ForestPrep as early as possible, so you can be sure the schema is prepared for Exchange, even in remote locations.

For more information about ForestPrep and DomainPrep, see the Exchange Up-to-Date article ForestPrep and DomainPrep on the Web at https://go.microsoft.com/fwlink/?LinkId=5224.

Exchange 2000 Domain Preparation

The DomainPrep utility makes the modifications Exchange 2000 requires in each Windows 2000 domain that contains a server running Exchange. A member of the local domain's Domain Admins group must run this utility. The DomainPrep utility performs the following operations:

• Prompts for the address list server responsible for this domain.

• Creates the Exchange Domain Servers global security group.

• Creates the Exchange Enterprise Servers domain local security group.,

• Adds the Exchange Domain Servers group to the Exchange Enterprise Servers group.

• Grants appropriate rights to the address list server.

For more information about ForestPrep and DomainPrep, see the Exchange Up-to-Date article ForestPrep and DomainPrep on the Web at https://go.microsoft.com/fwlink/?LinkId=5224.

Exchange 2000 Administrative Group Design

In Exchange Server version 5.5 and earlier, the concept of a site defined the administrative and routing topologies for an organization. In Exchange 2000 Server, the site is split into administrative groups and routing groups*.* An administrative group is a collection of Exchange objects that are grouped together to simplify management of permissions. After you create an administrative group and set permissions for it, you can add objects to the group and the objects inherit the permissions you have set for the group. For example, if you have 10 servers running Exchange, it is simpler to define a set of permissions for an administrative group and add a Servers object containing the ten servers than it is to define the same set of permissions separately for each server.

On reason you may have multiple administrative groups would be if your organization has multiple sets of mail administrators, each of whom manage a certain set of mail servers. In this scenario, a group of administrators do not want other groups to be able to manage the first group's servers. You can solve this problem by creating an administrative group for each set of mail administrators.

Important: Unlike routing groups, you cannot move Exchange servers between administrative groups.

Fabrikam decided on the following goals for its Exchange administrative model:

• Policy management to be centralized The Richmond administrative group will be responsible for policies that enforce standard configuration for Exchange servers across the entire organization.

• Secondary administrators to be located in Braintree There are administrators in Braintree who will be able to perform some basic day-to-day administrative tasks.

• No mail administrators located at other sites No mail administrators will be located at the other Fabrikam locations, and there are no plans to hire mail administrators at any of the other offices.

• Richmond administrators to provide limited on-site support The mail administrators in Richmond will provide some on-site support to the servers in nearby Alexandria.

Because of these goals, the Fabrikam migration team recommended a single Exchange administrative group. The name of the administrative group will be the default name, First Administrative Group. Figure 2.5 represents the centralized administrative design for Fabrikam.

Figure 2.5: Fabrikam's administrative group design

Figure 2.6 shows the administrative group design as displayed in System Manager, the primary Exchange management tool.

Figure 2.6: Fabrikam's administrative group design in Exchange System Manager

Exchange Administration Delegation Wizard

Exchange Administration Delegation Wizard simplifies delegating permissions to Exchange administrators. When you start Exchange Administration Delegation Wizard in System Manager, the wizard prompts for users and groups to which you want to apply the administrative permissions. You can delegate administrative permissions at the organization level in System Manager, or at an administrative group level. The scope of permissions you set is determined by the place from which you launch the wizard. For example, if you run the wizard from the organization level, the groups or users that you specify will have administrative permissions at the organizational level.

So that network administrators at the branch offices can perform basic administrative messaging tasks, Fabrikam will delegate permissions to certain users within the administrative group. Fabrikam chose to configure these permissions by using Exchange Administration Delegation Wizard . For more information about using this wizard, see "Exchange Administration Delegation Wizard" in Appendix A.

Exchange 2000 Server Placement

The Fabrikam migration team considered several options both how many servers running Exchange to use and where to place the servers in the Fabrikam organization. Fabrikam wanted to place servers running Exchange 2000 in each of its major branch offices because of the need for each location to continue operating even if the WAN links connecting the offices became unavailable. To meet this need, a distributed Exchange server design is necessary.

To ensure access to Active Directory is always available to Exchange and its clients, at least one global catalog server must be located in the same location as the servers running Exchange. In Fabrikam's case, at least one global catalog server must be installed in each of the following locations:

• Richmond

• Alexandria

• Chicago

• Braintree

• Munich

Note: Because the Chapel Hill office contained only five users, Fabrikam decided Chapel Hill would not have an Exchange server at its location.

Exchange 2000 Routing Group Design

An Exchange 2000 routing group is a group of servers that are constantly communicating information to each other using reliable LAN connectivity. Information from one server to another server in the same routing group flows directly and immediately by using SMTP protocol (native in Exchange), not through a connector or on a schedule.

This section describes the different routing group designs the Fabrikam migration team considered for its Exchange messaging system. In addition to routing groups, all Exchange organizations need to set up routing group connectors to allow communication between routing groups. The team also considered the placement and frequency of routing group connectors when it designed the Fabrikam routing groups.

Note: In all of the following diagrams, proposed routing group connectors are named according to standards discussed in the "Naming Conventions" section earlier in this chapter.

Routing Group Design 1

After the migration team analyzed Fabrikam's network, the team suggested the routing group design shown in Figure 2.7.

Figure 2.7: Proposed routing group design 1

Proposed routing group 1 contains:

• 5 routing groups

• 4 routing group connectors

Although this design is simple and straightforward, it does not allow for redundancy, should any of Fabrikam's WAN links become unavailable.

Routing Group Design 2

If bandwidth usage between Richmond and Alexandria is sufficient, both locations could be placed in the same routing group, creating the routing group design shown in Figure 2.8.

Figure 2.8: Proposed routing group design 2

Proposed routing group design 2 contains:

• 4 routing groups

• 3 routing group connectors

Although routing group design 2 did not include a redundant link, this proposal did require the fewest number of routing groups and connectors, which offers the simplest administration.

Routing Group Design 3

Because Fabrikam chose a design that requires added redundancy, the migration team made Braintree a hub site, as shown in Figure 2.9.

Figure 2.9: Proposed routing group design 3

Proposed routing group design 3 contains:

• 5 routing groups

• 6 routing group connectors

Routing Group Design 4

The design shown in Figure 2.10 builds on routing group design 3 and adds a redundant path for the Alexandria office.

Figure 2.10: Proposed routing group design 4

Proposed routing group design 4 contains:

• 5 routing groups

• 7 routing group connectors

Routing Group Design 5

Fabrikam management ultimately decided that only one of its WAN links had sufficient capacity to be used as a redundant path. Management decided that the redundant link would be placed between Richmond and Braintree. Fabrikam implemented proposed routing group design 5 (shown in Figure 2.11).

Figure 2.11: Proposed routing group design 5 (design chosen by Fabrikam)

Proposed routing group design 5 contains:

• 5 routing groups

• 5 routing group connectors

Routing Group Costs

• Because Exchange uses routing group costs to prioritize the paths an e-mail message can take from its source to its destination, each routing group connector must have a cost assigned to it. Exchange uses the lowest available aggregate cost route (the total cost of all routing groups) over a higher cost route. Routing group costs range from 1 to 100. Table 2.8 shows the routing group costs that the migration team associated with each Fabrikam routing group connector.

Table 2.8 Fabrikam routing group connector costs

Routing group connector	Cost
RI-AL RGC (Richmond-Alexandria)	10
RI-BR RGC (Richmond-Braintree)	10
RI-CH RGC (Richmond-Chicago)	10
RI-MU RGC (Richmond-Munich)	10
AL-BR RGC (Alexandria-Braintree)	30

Given the costs shown in Table 2.8 as an example, a message sent from Chicago to Richmond would cost 10 because it travels over the RI-CH RGC connector. A message sent from Chicago to Braintree would cost 20 (RI-CH RGC + RI-BR RGC).

Similarly, a message sent from Alexandria to Braintree travels through Richmond rather than going directly over the AL-BR RGC connector because the Richmond route costs only 20 (RI-AL RGC + RI-BR RGC) but the route over AL-BR RGC costs 30. This cost difference is because the low-speed AL-BR RGC link is only meant to be used as a redundant path if another link becomes unavailable. At the time of migration, Fabrikam considered upgrading the network link speed between Alexandria and Braintree. If an upgrade occurs, Fabrikam may reduce the routing cost on AL-BR RGC from 30 to 10. Mail would then be routed on this link directly between Alexandria and Braintree before it was routed through Richmond.

Exchange Server Remote Administration

As stated earlier, Fabrikam wants to manage all Exchange servers from the Richmond location. To provide this capability, the migration team prepared the following tools:

• Windows 2000 Terminal Services Terminal services will be loaded on each server running Exchange. Using Terminal Services allows administrators to log on and remotely administer the server running Exchange.

• Exchange System Manager Microsoft Management Console (MMC) System Manager can be installed on any computer running Windows 2000. Using System Manager allows administrators to administer any server running Exchange on which the administrator has been given necessary permissions.

• Active Directory Users and Computers MMC Active Directory Users and Computers can also be installed on any computer running Windows 2000. Using Active Directory Users and Computers allows administrators to administer the domain's user accounts and mailboxes.

Exchange Storage Group and Storage Design

Exchange 2000 provides many new features to support more users on each server. One new feature is the Exchange store and its use of multiple databases. In previous versions of Exchange, the information store supported only one private messaging database (Priv.edb) and one public messaging database (Pub.edb) on each server. If either of the two databases grows too large, much time can be spent backing up or restoring the databases.

Exchange 2000 allows administrators to create multiple databases on each server. When you divide your mailbox store and public folder store databases into smaller, multiple databases, you can manipulate, back up, and restore the databases more efficiently.

Exchange 2000 allows you to divide the messaging database from one large messaging database to as many as 24 messaging databases on each server. The database is divided into units called storage groups. Each server can support up to four storage groups per server, and each storage group can contain up to five databases. Within a storage group, every database shares the same transaction log and writes to a single transaction log.

Note: In designing your storage groups, remember that every storage group requires additional CPU processing power and memory. In addition, it is recommended that a dedicated set of drives be allocated for each storage group for the storage group's transaction log files.

Microsoft Consulting Services recommends reserving one database for troubleshooting operations. Fabrikam used a maximum of five databases in each storage group for messaging and data storage.

The Extensible Storage Engine (ESE) is the basis of Exchange 2000 database technology. As shown in Figure 2.12, An ESE consists of a database and uncommitted entries in transaction log files (.log files). Each Exchange database contains two components: a streaming database (.stm) and the property database (.edb) files.

Figure 2.12: Exchange 2000 Server storage architecture

The .stm file stores messages submitted by Internet clients in the messages' native format. The .edb file contains message-header information in Rich Text Format (RTF) and stores the messages and message bodies. Outlook 2000 accesses messages from the .edb database.

Multiple databases have many advantages over a single, giant database. For example, you can group your users based on similar requirements, such as message retention, mailbox size, or policy. You can also mount and dismount individual databases without interrupting any of the other databases, which makes recovery more efficient.

Storage Group Design

The flexible architecture of the Exchange store creates additional complexity when developing a storage group design. Use the following best practices to develop a sound storage group design:

• Store Policies

• Usage factors

• Physical disk configuration

• Backup and Restore Service Level Agreements

• Virtual memory usage

• Clustering

• Parallel backup and restore

Store Policies

You can assign mailbox policies (such as mailbox size quotas, deleted item retention time, deleted mailbox retention time, and single instance storage ratio) on each database. Because you can assign these policies on each database, if you want different mailbox size limits for different users, you can group users in separate databases and apply different mailbox policies.

Usage Factors

Usage factors (such as full-content indexing) can create the need to separate users into separate databases. For example, full-text indexing is a very processor-intensive task and should not be enabled on every server and database if it is not required. If only one group of users requires full-text indexing, you can put this group into a separate database (you can enable full-text indexing at the database level).

Physical Disk Configuration

Because each storage group has its own set of transaction log files, and Exchange best practices recommend that transaction log files have their own dedicated hard disk, each storage group should have a redundant array of independent drives (RAID) 1 mirror set dedicated to it.

Note: Be aware that the number of physical disks required in your server, should you configure your disks in this method, could prove costly. This costliness is especially true as you add more storage groups to the server because each storage group should have its own RAID 1 mirror set.

Backup and Restore Service Level Requirements

The service level requirement for backing up and restoring databases on a server must be considered when you design the Exchange storage group architecture. When you perform a backup, storage groups can be backed up in parallel. However, within a single storage group, Microsoft does not support parallel backup of databases. When you restore a storage group, the granularity of what you can restore reaches the individual database level.

Administrators need to know the backup and restore speeds of their backup solution. Currently, a good guideline for how long it should take to back up storage groups to digital linear tape is 20 GB to 30 GB per hour for a locally attached hard drive and 10 GB to 20 GB per hour for network backup over a dedicated 100 Mbps switched LAN connection. Typically, it takes twice as long to restore a backup as it takes to create the backup.

For example, if you have a restore service level agreement of 2 hours to restore Exchange and a tape restore speed of 10 GB per hour, the maximum Exchange store size is 20 GB. Databases must be designed so that the maximum database size does not exceed 20 GB.

Virtual memory usage

Each storage group requires approximately 100 MB of virtual memory, and each database requires approximately 10 MB of virtual memory. Therefore, you need the following amount of virtual memory for each server running Exchange 2000:

(number of storage groups * 100 MB) + (number of databases * 10 MB)

Although virtual memory usage is not usually a major factor in storage group design, allocating too much virtual memory to the Exchange store can affect overall system performance by taking memory away from other services.

Clustering

When you cluster Exchange and a failover occurs, the entire storage group fails over. Because the entire storage group fails over, it is imperative when you design your cluster failover strategy that no single node runs more than four storage groups in either a before or after failover configuration. In other words, upon failure in a cluster, there must be an equivalent number of unallocated storage groups on the other server to host the storage groups from the failed node. For example, if you have a two-node cluster, each node can host a maximum of two storage groups because the other node can pick up the storage groups from the failed node without exceeding its maximum allowed number of storage groups.

In general, the load on the cluster nodes should not exceed

100% - (100% / n)

where n is the number of nodes in the cluster.

Parallel backup and restore

It is possible to back up individual storage groups in parallel, but the backup software and tape configuration must support parallel backup. Individual databases can be restored in parallel but, again, the backup software and tape configuration must support parallel restoring of databases. It is not recommended to parallel restore two databases in the same storage group as contention for the shared transaction log files can affect performance and database integrity.

Storage Design

Exchange 2000, like GroupWise, supports a feature called single-instance storage. Single-instance storage means that, if a message is sent to multiple users in the same Exchange mailbox store, only 1 copy of the message is kept in the database. Thus, if you send a 10 MB message to 100 users in the same database, only 1 copy of the 10 MB message is kept in the messaging database.

To maximize the use of this feature, during initial Exchange deployment, Fabrikam plans to keep the users who frequently communicate with each other in the same mailbox store. Such practices take advantage of single-instance storage and are arguments against segmenting storage groups into too many databases.

The Fabrikam migration team made the following assumptions to determine the design of its Exchange databases:

• Do not implement clustering initially, but may implement it in the future.

• Do not implement parallel backup and restore of files.

• Maximize single-instance storage space savings.

• Put only one storage group on each server.

• Minimize the number of users in each Exchange database, but use more databases.

• Put a public folder store on every mailbox server.

• Set the mailbox size limit to 125 MB for each user.

• Set the deleted item retention to 7 days.

• Set the deleted mailbox retention to 30 days.

• Recover any single database in four hours or less.

• Assume that the average backup speed is at least 15 GB per hour.

• Assume that the average restore speed is at least 6 GB per hour.

Exchange 2000 Public Folder Store

To support group collaboration applications, Exchange users can use public folders. Public folder data is stored separately from messaging or other data in dedicated public folder stores.

Storage Design Principals

Fabrikam determined that each storage group would contain one public folder store and up to four mailbox stores. The Fabrikam migration team applied the following method to the data it had assembled to determine Fabrikam's storage requirements:

• Maximum downtime equals 2 hours. (Administrators have 4 hours to restore an Exchange database, but it takes 2 of those hours to locate a tape, find server software, and load the tape).

• The 2 hours maximum downtime (calculated above) multiplied by the 10 GB per hour restore speed (2 x 10) means 20 GB maximum can be restored.

• 20 GB / 125 MB maximum mailbox size = 160 mailboxes (or users) maximum in each mailbox store.

Design Results

Table 2.9 illustrates how the storage requirements and design solutions described in this section were implemented at each Fabrikam office location.

Table 2.9 Exchange store implementation across the Fabrikam organization

Location	Number of users	Planned number of e-mail servers	Number of users on each server	Planned number of storage groups	Planned number of mailbox stores	Planned number of users in each mailbox store	Maximum disk space (125 MB for each user)
Richmond	800	2	400	1	4	100	12.5 GB
Braintree	100	1	100	1	1	100	12.5 GB
Alexandria	60	1	60	1	1	60	7.5 GB
Chicago	15	1	15	1	1	15	1.8 GB
Munich	30	1	30	1	1	30	3.75 GB

Notes: At each location, one of the five databases is dedicated for public folders. In Richmond, one mailbox store will be dedicated to the Fabrikam executive team.

Exchange Server Hardware Planning

Early in the planning phase, the migration team conducted an analysis of the Exchange 2000 hardware requirements. The team combined this analysis with usage information of the existing GroupWise system from Chapter 1, as well as the storage needs discussed above. Based upon this analysis, the migration team created the following categories of Exchange servers:

• Mailbox server for large offices A server that holds over 100 mailboxes.

• Mailbox server for medium offices A server that holds 40 to 100 mailboxes.

• Mailbox server for small offices A server that holds up to 40 mailboxes.

• Outlook Web Access server A front-end server dedicated to receiving HTTP requests from Outlook Web Access clients.

• Gateway or bridgehead server A server that handles all outgoing and incoming messages from the Internet to users behind the Fabrikam firewall. Bridgehead servers contain all Exchange connectors: SMTP connector, routing group connector, GroupWise connector, and Exchange 2000 Calendar Connector.

The following sections describe the minimum hardware requirements for each server type. Note that the hardware specification in your organization may vary from Fabrikam's specifications.

Mailbox Server for Large Offices (over 100 Mailboxes)

• Server class computer with redundant power and cooling

• Dual processor, Pentium III 1 Ghz with 256 KB L2 cache

• 2 GB RAM

• Two 18-GB drives; RAID 1 (creates 18 GB total storage); formatted NTFS; System

• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; Exchange logs

• Five 18-GB drives; RAID 5 (creates 72 GB total storage); formatted NTFS; Exchange database

Mailbox Server for Medium Offices (40 to 100 Mailboxes)

• Server class computer with redundant power and cooling

• Dual processor, Pentium III 1 Ghz with 256 KB L2 cache

• 2 GB RAM

• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; System

• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; Exchange logs

• Three 18-GB drives; RAID 5 (creates 36 GB total storage); formatted NTFS; Exchange database

Mailbox Server for Small Offices (up to 40 mailboxes)

• Server class computer with redundant power and cooling

• Dual processor, Pentium III 1 Ghz with 256KB L2 cache

• 1 GB RAM

• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; System

• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; Exchange logs

• Two 18-GB drives; RAID 5 (creates 18 GB total storage); formatted NTFS; Exchange database

Outlook Web Access Server

• Server class computer with redundant power and cooling

• Dual processor, Pentium III 1 Ghz with 256 KB L2 cache

• 1 GB RAM

• Four 9-GB drives; RAID 5 (creates 27 GB total storage); formatted NTFS; System; Outlook Web Access

Gateway/Bridgehead Server

• Server class computer with redundant power and cooling

• Dual processor, Pentium III 1 Ghz with 256 KB L2 cache

• 1 GB RAM

• Four 9-GB drives; RAID 5 (creates 27 GB total storage); formatted NTFS; System; Exchange connectors

Important: Exchange 2000 requires modification if installed on a server that has more than 1 GB of physical RAM. For more information, see Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," available at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.

SMTP Queue Directory and Message Tracking Logs

When you install Exchange, the SMTP queue directory and the message tracking log directory are created beneath the Exchsrvr directory. Microsoft Consulting Services recommends that you create the Exchsrvr directory on a high-capacity volume (preferably a RAID array) that can handle the disk throughput of the SMTP queue and the Message Tracking log (during Exchange Setup, you are prompted to accept the default locations or enter new locations). After Exchange Setup finishes, you cannot move these directories automatically.

Exchange Server Drive Letters

For the purposes of clarity and consistency, the Fabrikam team developed a standard drive configuration and attempted to follow it across all of the Exchange server types. Table 2.10 shows the functions, labels, and physical configurations of each drive.

Table 2.10 Using drives consistently

Logical drive configuration	Physical drive configuration
Drive C: System partition, about 2.8 GB Drive D: System recovery partition, about 1.6 GB Drive F: Application installation (contains Exchange binaries); size varies based on server function. Drive Z: Paging file, about 2 GB	RAID 1
Drive N: Exchange database; size varies based upon server function.	RAID 5 or RAID 0+1
Drive L: Exchange transaction log files; size varies based on server function	RAID 1

For information about RAID and mirrored disk configurations, see your Windows 2000 Server documentation.

Exchange 2000 Server Placement

After the migration team identified the hardware requirements and the types of servers Fabrikam required for an Exchange messaging system, the team obtained the following servers for each office location.

Table 2.11 Server placement at Fabrikam

Location	Server type
Richmond	2 mailbox servers for large offices 2 gateway or bridgehead servers 1 Outlook Web Access (front-end) server
Alexandria	1 mailbox server for medium offices
Braintree	1 mailbox server for medium offices
Chicago	1 mailbox server for small offices
Munich	1 mailbox server for small offices

Exchange 2000 System Policies

A policy is a collection of configuration settings that is applied to one or more Exchange objects of the same class; for example, an administrator can define a policy that controls configuration settings across multiple servers. After these policies are defined and implemented, you can change the configuration of all of the servers by editing the policies and applying the changes.

Exchange 2000 includes two kinds of policies: system and recipient. System policies are policies that you create and apply to a server, mailbox store, or public folder store. Recipient policies are policies that you apply to mail-enabled Exchange 2000 objects (any object with at least one e-mail address) to generate e-mail addresses.

An administrator creates a policy, defines the settings that policy implements, associates that policy with one or more objects of the same class, and then applies the policy. When an object, such as a server, is associated with a policy, any changes to settings must be made through the policy; you will not be able to make configuration changes directly at the object. (Settings that are not affected by the policy can still be made at the object.) This policy-lockout feature enables administrators to prevent further changes.

For the purposes of migration, Microsoft Consulting Services recommends setting server, public folder, and mailbox policies to every administrative group in your Exchange organization. Setting these policies ensures configuration consistency across similar objects, and prevents changes being made that could affect migration.

The following sections provide an overview of the policy settings used by Fabrikam in its new Exchange organization. For more information about policies, see your Exchange 2000 online documentation. For more information about how to create a policy, see "System Policies" and "Recipient Policies" in Appendix A.

Policy Types and Tab Descriptions

Each type of system policy is defined by setting properties on one or more tabs. The smallest possible policy is the set of properties on a single tab. Table 2.12 lists the tabs available with each policy type.

Table 2.12 Tabs available with policy types

Policy type	Tabs
Server	General
Public folder store	General, Database, Replication, Full-Text Indexing, Limits
Mailbox store	General, Database, Full-Text Indexing, Limits

Table 2.13 lists the configuration settings that can be made on each tab.

Table 2.13 Tab descriptions

Tab	Description
General	Settings for the specific policy type.
Database	Settings for storage group membership and database maintenance.
Full-Text Indexing	If you deploy full-text indexing, settings for scheduling how often to update the index.
Replication	Settings for how often public folders replicate and to size limits for replicated items.
Limits	Settings for deleted item retention, storage limit, and folder age limit.

Note: Full-text indexing indexes every word in a public or private store, making faster search and retrieval possible without requiring special mail clients. However, because of the amount of data that can be involved and the updating required, full-text indexing can also be taxing on your system resources. For more information about best practices in deploying full-text indexing in your organization, see the Exchange Up-to-Date article Best Practices for Deploying Full-Text Indexing on the Web at https://go.microsoft.com/fwlink/?LinkId=5223.

Fabrikam's Policy Design

As Fabrikam deployed Exchange in its organization, the company created one policy of each type in its administrative group (First Administrative Group). For simplicity, the default policy names were kept: Default Server Policy, Default Public Folder Policy, and Default Mailbox Policy. Tables 2.14 through 2.16 show how Fabrikam configured these policies.

Note: All of the default settings in these tables use the Service Pack 1 (SP1) default settings when no policy is applied to an object.

Table 2.14 Default server policy settings

Tab	Property	Default setting	Fabrikam setting
General	Enable subject logging and display	Disabled	Enabled
General	Enable message tracking	Disabled	Enabled
General	Remove log files	Enabled	Enabled
General	Remove files older than (days)	7	14

Message tracking is enabled during migration to help administrators monitor message flow for the purposes of troubleshooting. Fabrikam wanted to keep log files for two weeks for a sufficient history of server transactions during migration. Your organization may require a different log storage period.

Table 2.15 Default public store policy settings

Tab	Property	Default setting	Fabrikam setting
General	Clients support S/MIME signatures	Enabled	Enabled
General	Display plain text messages in a fixed-sized font	Disabled	Disabled
Database	Maintenance interval	Daily: 1:00 to 5:00 A.M.	Daily: 6:00 to 10:00 P.M.
Replication	Replication interval	Always run	Always run
Replication	Limits: Replication interval for always (minutes)	Disabled	Disabled
Replication	Limits: Replication message size limit (KB)	Disabled	Disabled
Limits	Storage limits: Issue warning at (KB)	Disabled	Disabled
Limits	Storage limits: Prohibit post at (KB)	Disabled	Disabled
Limits	Storage limits: Maximum item size (KB)	Disabled	Disabled
Limits	Warning message interval	Run daily at Midnight	Run daily at Midnight
Limits	Keep deleted item for (days)	0	7
Limits	Do not permanently delete items until the store has been backed up	Disabled	Enabled
Limits	Age limit for all folders in this store (days)	Disabled	Enabled; set to 60 days
Full-Text Indexing	Update interval	Never run	Never run
Full-Text Indexing	Rebuild interval	Never run	Never run

After the Fabrikam management approves and implements a definitive public folder design in the organization, public store policy settings may be changed. The above settings were sufficient during the migration. The next project for the migration team would be implementation of a complete public folder architecture.

Administrators changed the deleted items default setting because one of Fabrikam's Exchange requirements was to retain deleted items for 7 days. It also good practice to make sure nothing is deleted until the information has been secured on backup tape. Finally, for storage space and performance concerns, Fabrikam did not want to keep public folders longer than 60 days.

Table 2.16 Default mailbox store policy settings

Tab	Property	Default Setting	Fabrikam Setting
Database	Maintenance interval	Daily: 1:00 to 5:00 A.M.	Daily: 6:00 to 10:00 P.M.
Limits	Storage limits: Issue warning at (KB)	Disabled	100000 (100 MB)
Limits	Storage limits: Prohibit send at (KB)	Disabled	125000 (125 MB)
Limits	Storage limits: Prohibit send and receive at (KB)	Disabled	Disabled
Limits	Warning message interval	Run daily at Midnight	Run daily at Midnight
Limits	Keep deleted items for (days)	0	7
Limits	Keep deleted mailboxes for (days)	30	30
Limits	Do not permanently delete items until the store has been backed up	Disabled	Enabled
Full-Text Indexing	Update interval	Never run	Never run
Full-Text Indexing	Rebuild interval	Never run	Never run

In keeping with Fabrikam's 125 MB size limit on all mailboxes, two of the storage limits were enabled on mailboxes. As with public folder stores, administrators want to retain deleted mail items for 7 days to allow a comfortable recovery period. Administrators also want to make sure everything is backed up before it is permanently deleted.

Recipient Policies

In Exchange 2000, recipient policies perform two primary functions:

• Assign the default e-mail address assigned to users

• Establish the mailbox manager policies.

At Fabrikam, the migration team developed three recipient policies to generate e-mail addresses for the various Exchange objects. Table 2.17 summarizes these recipient policy settings.

Table 2.17 Fabrikam recipient policy settings

Policy name	Objects affected	E-mail address
Fabrikam Recipient Policy	Exchange mailboxes, mail-enabled groups	SMTP <primary>: %g.%s@fabrikam.com SMTP <secondary>: %m@fabrikam.com|mailto:%m@fabrikam.com X.400: <default> GWISE: FirstAdminGroup.Exchange.%M
Contact Policy	Exchange contacts for GroupWise users	SMTP: %m@fabrikamgw.com
Default Recipient Policy	All recipients	GWISE: Exchange.FirstAdminGroup.Exchange.%M SMTP: %m@fabrikam.com <primary> X.400: <default>

E-mail Address Recipient Policies

E-mail address recipient policies create the appropriate e-mail addresses for users in your Exchange organization. E-mail addresses identify recipients to the gateways and connectors that connect Exchange with other messaging systems, including GroupWise.

The Fabrikam Recipient Policy used the following guidelines to set the e-mail addresses of all employees:

Note: This section discusses why you need recipient policies and what these policies do. The procedures for creating the recipient policies described in this section are included in Chapter 3, Deploying.

• Firstname.lastname @fabrikam.com (for example, alan.steiner@fabrikam.com) This e-mail format is established by %g.%s@fabrikam.com. Administrators set this address as the primary SMTP address.

• loginid @fabrikam.com (for example, alans@fabrikam.com) In Exchange, you can have multiple SMTP addresses assigned to one user object, and mail sent to any of these e-mail addresses is delivered to that user's mailbox. Fabrikam employees will be able to receive mail sent to their loginid@fabrikam address, which is similar to their GroupWise e-mail addresses.

• GroupWise (GWISE) address (for example, Exchange.First Administrative Group.alans) Exchange only creates SMTP and X.400 addresses by default. When you install the GroupWise connector, the connector adds a GroupWise (GWISE) e-mail address to your recipient policies. To generate GroupWise addresses for recipients, you must select the GWISE check box on the policy object to have Recipient Update Service generate a GroupWise address for each applicable object. The GroupWise connector replicates this object to the GroupWise system. During the period of interoperability between the two messaging system that exists shortly before migration, this address is the one that users on the GroupWise side will use to send mail to Exchange users.

Fabrikam Contact Recipient Policy

As part of the migration process, the Fabrikam contact policy was created to assign an SMTP address to the Exchange contacts that are created for all migrating GroupWise users. When you configure the GroupWise connector to perform directory synchronization between GroupWise and Exchange, the connector creates Exchange contacts for each user in GroupWise (it can also create user accounts). The contact recipient policy assigns these contacts an SMTP address of %m@fabrikamgw.com.

Without the Fabrikam contact policy, the default recipient policy would operate on these contacts and assign each an SMTP address of %m@fabrikam.com. Then, after you migrate the account to Windows 2000, you would be unable to create an SMTP address for the user because the same SMTP address already existed for the contact.

Chapter 3, Deploying, describes Exchange Migration Wizard and how it moves contact information to the new Active Directory object and then deletes the contact objects. Note, however, that Migration Wizard requires a user object already to exist before e-mail information can be imported from the contact object. At Fabrikam, the Active Directory team created all organizational units (such as Marketing, Sales, Support, and so on) and user accounts in advance. All accounts were originally disabled, and then, as users were migrated to Exchange, their accounts were enabled. Microsoft Consulting Services recommends creating Active Directory accounts manually as Fabrikam did, rather than letting the GroupWise connector create the accounts. There are two reasons for this recommendation:

• First, the connector can only create Active Directory accounts in a single organizational unit.

• Second (and more important), if a GroupWise administrator were to move a GroupWise account from one post office to another, this move could result in the GroupWise connector creating multiple Active Directory accounts for the same GroupWise user.

For best results, Microsoft Consulting Services recommends that the GroupWise connector only be used to create contact objects for GroupWise users, and not used to create Active Directory accounts.

Default Recipient Policy

The default recipient policy is required. Although you cannot edit which objects the default recipient policy applies to, you can indicate what type of addresses it should generate. It is critical that the default recipient policy create a GWISE address, as the Exchange 2000 Calendar Connector uses the Exchange System Attendant to perform some of its free and busy operations. The Exchange System Attendant needs a valid GroupWise address and depends on the default recipient policy for this address.

Recipient Update Service Design

In Exchange 2000, Recipient Update Service performs two critical functions:

• Generates address lists (for example, the global address list [GAL], any custom address lists, any offline address lists, and so on).

• Applies the recipient policies.

By default, Recipient Update Service checks one domain controller for changes, such as when you create a new account. In the case of a new account, when Recipient Update Server detects a change, the service stamps the account with the new e-mail address based on the recipient policy. After this change is made, the domain controller waits for the next predetermined replication cycle (by default, 15 minutes) to replicate the change to the other domain controllers. A delay of 30 minutes or more may elapse between the creation of a new account and the addition of the address to the global address list.

1. An administrator connects to a domain controller in Alexandria (DC-AL01P) and creates an account (Kim Ralls). Recipient Update Service is configured to communicate with DC-RI01P (a domain controller in Richmond).

2. During the next replication period, Active Directory replicates the new account to DC-RI01P. (Depending on Recipient Update Service settings, it may take some time before Recipient Update Service detects the new account on the domain controller.)

3. Recipient Update Service stamps the new account on DC-RI01P with an e-mail address (Kim.Ralls@fabrikam.com).

4. After another replication period, Active Directory replicates the new account's e-mail address back to DC-RI01P, and to the rest of the Fabrikam organization.

Multiple Recipient Update Services

To avoid possible replication latency issues, the Fabrikam migration team implemented multiple Recipient Update Services, one for every domain controller in the child domain (corp.fabrikam.com). In such a scenario, if an administrator makes a change on any domain controller in the company, Recipient Update Service will be available to create the SMTP address almost immediately. All domain controllers in the Active Directory forest will receive the updated account and e-mail address during the next replication cycle, which eliminates one Active Directory replication cycle. In addition, the fault tolerance of Recipient Update Service is increased because multiple instances of the service are now running.

Warning: If your company has many recipient policies, implementing multiple Recipient Update Services must be tested closely. At one customer site, Microsoft Consulting Services needed to implement approximately 100 recipient policies in an environment in which multiple Recipient Update Services were already running. The result was an unintended cycle wherein many of the recipient policies never finished processing before another Recipient Update Service started the process over again.

Remote Site Recipient Update Service Design

Another method for reducing directory replication delays at remote sites is to install Recipient Update Service at every remote site with a domain controller or global catalog. Administrators can create user accounts for the remote sites by using the domain controller at those sites (rather than one in the main office). In this way, the new accounts are available immediately because Recipient Update Service at the remote location stamps the account right away with the e-mail address. Users at locations that are one directory replication hop away will have the new information after the next replication cycle.

Figure 2.13 shows how Fabrikam implemented multiple Recipient Update Services in several of its office locations. Note that the Chicago office is small enough that its domain controller was also the server running Exchange.

Figure 2.13: Multiple Recipient Update Services

Mailbox Manager Settings

Beginning with SP1, mailbox recipient policies use Exchange Mailbox Manager to enforce corporate e-mail retention policies on all mailboxes defined by policy membership. When Mailbox Manager finds messages in one or more folders that exceed policy limits, you can choose to delete the messages immediately or move them to users' Deleted Items folders.

The limits that trigger Mailbox Management action can also be configured to be uniform across all mailbox folders, or defined on a folder-by-folder basis. Limits can be based on age (the default is 30 days), size (the default is 1,024 KB), or both.

To maximize storage space, Fabrikam wants to automatically delete all messages older than 60 days. For more information about how to set Mailbox Manager to automatically delete all messages older than a specific age, see "Recipient Policies" in Appendix A.

Public Folder Hierarchy Design

Public folders store messages or information that can be shared among users in your organization. Public folders can contain different types of information, ranging from custom forms to Internet content stored in its native format.

In Exchange 2000, public folders are arranged in a hierarchy, and you can assign permissions such that only certain users are allowed to create folders or add, modify, or delete content from folders at any level of the hierarchy. Public folders can contain the following types of information:

• Discussion threads This function allows users to post messages to a group of users with a common interest, such as to a folder called "IT News."

• Group calendars This function enables departments to have a departmental calendar.

• Group contacts lists This function allows you to maintain lists of contact information for other companies that a group or department may be working with.

• Group task lists This function can be used to maintain group task lists and can be linked to Microsoft Project.

The owner of the public folder controls access to the folder so that certain users are allowed read, write, or delete access to items in the public folder. To host a public folder, the Exchange administrators need to allocate one of the databases in the storage group for the public folder.

By default, the public folder hierarchy replicates to all public folder servers in the Exchange organization. This replication allows users in every location with a public folder server to view the hierarchy.

The public folder contents are stored locally but can be replicated to multiple servers. If you replicate the contents of a public folder server to other servers, users will not need to transverse the network to access the contents. At Fabrikam, management decided to focus on designing and implementing the core Exchange 2000 architecture and the migration of GroupWise data to the new Exchange system. The migration team plans to concentrate on public folders after they complete the phase of the project covered in this white paper. For the time being, the migration team changed the permissions on the public folder hierarchy so that no users had permission to create any public folders.

For complete information about public folders, see your Exchange 2000 online documentation.

Free and Busy Information

Exchange 2000 Calendar Connector allows Exchange and GroupWise users to share schedule information. When synchronizing calendar information with other messaging systems, the schedules for all users in the Exchange organization are stored in a free and busy public folder located on the first Exchange server installed in the organization. At a minimum, the Fabrikam team needs to replicate the free and busy public folder to the Exchange bridgehead server that hosts Calendar Connector. An additional design consideration for the migration team was whether or not to replicate the free and busy public folder across the entire organization.

The decision that had to be made was whether or not to replicate the free and busy public folder in Richmond to the other Exchange servers. Ultimately, the migration team decided to replicate the free and busy public folder to the Exchange servers at the locations outside of Richmond to allow users in those offices to query the free and busy folder locally instead of across the WAN. Querying the folder locally provides speedier free and busy queries for all users. However, because of replication delays, there could be data inconsistencies in the free and busy information between remote offices. But the migration team decided that, because most users scheduled meetings only with users at the same location, the replication risk would not be sufficient enough to deter replicating the free and busy folder.

For more information about Calendar Connector, see the "GroupWise-to-Exchange 2000 Interoperability Architecture" section later in this chapter.

Outlook Web Access

Fabrikam employees will have Web-based access to their Exchange mailboxes through Outlook Web Access. The recommended method for deploying Outlook Web Access in any medium-to-large organization is by using a front-end/back-end server architecture.

In previous versions of Exchange, the Information Store managed the databases and client access protocols such as Internet Message Access Protocol version 4 (IMAP4), Post Office Protocol version 3 (POP3), Network News Transfer Protocol (NNTP), and MAPI. In Exchange 2000, the Internet access protocols have been removed from Information Store and are managed by IIS instead. Deploying a front-end/back-end architecture makes it possible to manage the Internet access protocols (including HTTP, the protocol used by Outlook Web Access) on a server that is separate from the one on which the Exchange store and the databases run. Essentially, a group of protocol servers (front-end servers) handles incoming client connections while back-end servers are dedicated to running the databases.

The following sections discuss the highlights of front-end/back-end architecture, and its advantages in deploying Outlook Web Access. For a complete overview and best practices examination of front-end/back-end deployment, see the white paper Exchange 2000 Front-end and Back-end Topology at https://go.microsoft.com/fwlink/?linkid=4721.

Front-end/back-end deployment offers the following advantages to both users and administrators:

• Single namespace The primary advantage of a front-end and back-end server architecture is the ability to define a single namespace for users to access their mailboxes (for example, https://webmail.fabrikam.com/ for Outlook Web Access). Without a front-end server, each user must know the name of the server that is storing his or her mailbox. With a front-end server, Administrators can move a mailbox to another server, and the Outlook Web Access user can continue using the same URL.

• Offload processing Exchange 2000 servers can be configured to support Secure Sockets Layer (SSL) traffic between the client and the server to protect the traffic from third-party interception. However, encrypting and decrypting message traffic uses processor time. Therefore, when SSL encryption is in use, front-end and back-end server architecture provides an additional advantage because the front-end servers can handle all encryption and decryption processing. Using front-end servers in this way improves performance by removing processing tasks from back-end servers, while still allowing the data to be encrypted between the client and the Exchange servers.

• Firewalls The front-end server can be positioned as the single point of access behind an Internet firewall (or in a perimeter network configuration [also known as DMZ, demilitarized zone, and screened subnet]). Figure 2.14 displays a typical firewall deployment in an Outlook Web Access enviornment. Because the front-end server has no user information on it, an additional layer of security is provided. In addition, because the front-end server can be configured to authenticate requests before proxying them, the back-end servers are protected from denial-of-service attacks.

Front-End Architecture

Figure 2.14 illustrates the planned configuration of the front end architecture.

Figure 2.14: Typical Outlook Web Access deployment with firewalls

The front-end server will be placed inside the Fabrikam firewall. TCP port 443 must be opened from the Internet to the front-end server.

Table A.1 in the "Outlook Web Access" section of Appendix A lists all the ports that must be opened in both the internal and external firewalls for this Outlook Web Access configuration to work.

Front-End Architecture Sizing

As a general rule, one front-end server is reasonable for every four back-end servers. Front-end servers need not have large or particularly fast disk storage but should have fast CPUs and a large amount of memory.

Front-End Server Configuration

When you plan your front-end servers to receive requests from clients using Outlook Web Access (HTTP), POP3, or IMAP4, keep the following considerations in mind:

• The front-end server must be part of the same Exchange 2000 organization as the back-end servers.

• A front-end server must not host any users or public folders. Before placing the server in production, dismount the mailbox and public stores on the front-end server. Otherwise, the public store will be inaccessible from the front-end server.

  Important: Deleting the databases makes it impossible to make configuration changes using the IIS administration tools (Internet Services Manager [ISM]). If there are configuration changes that must be done using ISM (for example, configuring SSL encryption), be sure to complete these steps before removing the databases.

• To set up a front-end server, install the Exchange 2000 server in the organization. Then, in Exchange System Manager, find the server object and open the server property page (right-click the server object, and select Properties). Select the This is a front-end server check box and close the page. Before the server can be used as a front-end server, you must restart it, or you must stop and then restart HTTP, POP3, and IMAP4 services.

• Stop the unused Exchange services on a front-end server. HTTP requires no Exchange-specific services. However, the Windows HTTP service (World Wide Web Publishing Service) must be running.

• To stop and disable services, use the Services Microsoft Management Console (MMC) snap-in.

• The front-end server's virtual directories and HTTP virtual servers must exactly match those of the back-end server. In a default setting, no additional configuration needs to be done on the front-end server—the "Exchange" and "public" virtual directories already match.

• The Windows 2000 License Logging Service must be running on the front-end server. IIS does not allow more than 10 simultaneous SSL connections unless this service is running.

• Enable SSL encryption on the front-end server.

Back-End Server Configuration

Back-end servers have to be in the same domain as their front-end servers. At Fabrikam (fabrikam.com), this point will not be an issue.

Web Browser Support

The ideal client for Outlook Web Access is Microsoft Internet Explorer 5 or later. Although any browser that supports HTTP version 3.2 will work, including Internet Explorer 4.x and Netscape Navigator 4.x, only Internet Explorer 5 or later takes full advantage of Outlook Web Access features. HTML text composition, drag-and-drop editing, and preview pane are examples of features only available with Internet Explorer 5 or later.

Accessing Mailbox Through Outlook Web Access

Clients direct specific requests to Outlook Web Access using named URLs. Often the URL, such as https://webmail.fabrikam.com/, directs the client to the user's mailbox. However, named URLs are not limited to addressing a mailbox. Users can address most functions and components of the client by defining a specific URL. For example, you can open a specific folder by typing the name of the folder after the mailbox name. For Fabrikam employee Alan Steiner to open his calendar, he would type the path to his mailbox followed by /calendar, for example, https://webmail.fabrikam.com/asteiner/calendar. Likewise, you can access contacts directly by typing the path to the mailbox followed by /contacts.

Backup and Recovery

To effectively and reliably recover a server running Exchange in the event of a hardware failure or a natural disaster, Microsoft recommends the following:

• Perform full, daily backups. Full backups are the simplest method for recovering a server running Exchange because you do not need multiple days of backup tapes to restore from. In addition, only full and incremental backups purge committed Exchange transaction log files. The committed transaction log files should be committed on a daily basis to ensure there is enough space on the Exchange transaction log file drive.

• Disable circular logging on the mailbox servers.

• Ensure you use an approved Exchange backup agent to back up the server running Exchange. For example, Windows 2000 provides the administrative tool Backup, which is enhanced when Exchange is installed so it can perform Exchange backups. In Backup, be sure to back up the following:

  • The Exchange store

  • Microsoft Site Replication Service (only available when you run Site Replication Service, which is used for Exchange 5.5-to-Exchange 2000 communication).

  • System state

• Do not lock files while backing up Exchange because locking files may corrupt your Exchange databases.

• Do not shut down the server running Exchange during backups. Exchange supports hot backups.

Monitoring

Monitoring tools are required to perform data collection and health monitoring of Exchange components, including the hardware, operating system, and Exchange processes and supporting software. Fabrikam developed some custom scripts to help with the monitoring of its servers. However, Fabrikam has not implemented a software-monitoring package. Based on the functionality requirements, the migration team plans to focus upon implementing the monitoring tools that are built into Exchange 2000.

In a later project, the migration team is considering implementing Microsoft Operations Manager (MOM) and its Exchange monitoring agents, or another third-party Exchange monitoring package.

Management Tools

This section discusses tools with which Fabrikam's messaging administrators had to familiarize themselves. These tools allow complete management of their Exchange organization.

• Windows 2000 Terminal Services Terminal services was installed on each server running Exchange. This tool allows administrators to log on and remotely administer the server running Exchange.

• Exchange System Manager Microsoft Management Console (MMC) System Manager can be installed on any computer running Windows 2000 and is used to administer any server running Exchange to which the administrator has been given necessary permissions.

• Active Directory Users and Computers MMC Users and Computers administers the domain's user accounts and mailboxes.

• Exchange Message Tracking Center Message Tracking Center tracks the flow of system messages, e-mail messages, and public folder messages, as well as the status of messages in the Exchange organization. Administrators can use Message Tracking Center as a troubleshooting tool and gather data for statistical reporting.

• MMC Performance console In addition to the above snap-ins, the MMC Performance console will be used on each server to ensure the Exchange services are functioning as expected.

• Event Viewer Event Viewer gathers informational, warning, and error events in the server's log files. Use Event Viewer to troubleshoot any problems with the Exchange 2000 server.

All of these tools and snap-ins are available with a typical Exchange installation or are available on the Exchange 2000 compact disc.

Client Access Strategy

The migration team had several considerations on the client side when planning its Exchange organization. Table 2.18 documents the supported client-access methods in Exchange.

Note: At the time of Fabrikam's migration, Outlook 2002 (available in Microsoft Office XP) had not yet been released.

Table 2.18 Clients for Exchange 2000

Platform	Mail client
Desktop computer	Outlook 2000.
Home systems, other	Outlook Web Access.
Portable computer	Outlook 2000 (when connected to Fabrikam network). Offline mode when working remotely.
PDA	Microsoft ActiveSync® software for Pocket PC users; Intellisync software for Palm connected organizer users.
POP3/IMAP4	Outlook Express, enabled in Exchange by Exchange administrators

Outlook 2000

Outlook 2000 or later is the preferred client for Exchange 2000 because it provides the most functionality and flexibility of any of the Exchange clients. Fabrikam deployed Outlook 2000 on the majority of its client workstations.

Outlook Profile Generation

Outlook requires the creation of a profile file for each user. This profile identifies the Outlook 2000 configuration, the Exchange server that the user should point to for mailbox data, the offline and online settings, and services available (for example, personal folder, personal address books). This profile must be created for every Outlook user.

A CNAME record called "Exchange" was added to Fabrikam's DNS entries for the corp.fabrikam.com domain. The migration team created and associated this record with the MSG-RI01P Exchange server. The CNAME record allowed the team responsible for setting up employees' client computers ("the desktop team") to build a standard desktop image for every client computer. When the desktop team set up Outlook 2000 on each workstation, the Exchange server was always specified as Exchange.corp.Fabrikam.com (see Figure 2.15), although user mailboxes were located on different Exchange servers.

Figure 2.15: Creating Outlook profiles with a CNAME record

The first time a user started Outlook, Outlook resolved the user's Exchange server by checking the Exchange server (MSG-RI01P) specified in the CNAME record. MSG-RI01P contacted the global catalog server and determined which Exchange server hosted the user's mailboxes. The appropriate server name was sent back to the user, and the user's Exchange server profile field was updated with the correct server.

Outlook 2000 (for offline use)

When you configure portable computers for offline use in the Outlook 2000 client configuration, select Enable Offline Folder (OST) Use. Select this option for portable computers, but do not select this option for desktop computers. This option creates a file on the local computer that mirrors the contents of the user's mailbox, including all of the items in the Exchange database. An .ost file can be very large, so this option should not be used unless necessary. On a portable computer, an offline file is useful because it allows the user to read and answer mail without being constantly connected to the network over a phone line. On a desktop computer, the server is assumed to be always available and using an offline file should not be necessary.

Outlook Web Access

Outlook Web Access has been improved greatly in Exchange 2000. It is more robust and offers much more functionality than its Exchange 5.5 predecessor. However, this Web-based client does not provide all of the functionality of Outlook 2000 (such as Journal, Notes, or proxy access).

PDA Interoperability Plan

Currently the Palm connected organizer is the standard for Personal Data Assistants (PDAs) at Fabrikam. All PDAs will be modified to synchronize with Outlook 2000 instead of GroupWise. Administrators may need to create a synchronization policy to standardize the configurations of all PDAs.

GroupWise-to-Outlook Client Functionality Issues

The section lists the GroupWise functionality that Exchange and Outlook will not be able to reproduce.

Outlook 2000

Outlook 2000 cannot match the following functionality that Fabrikam employees had in GroupWise:

• The ability to schedule a meeting by choosing a date

• The ability to view multiple user calendars on one screen. (Can be done in Outlook 2002.)

• The ability to view attachments inline, so that the application associated with the attachment does not have to be installed on the local computer.

The migration team discussed these issues with management and decided to proceed without this functionality. The team had identified third-party software vendors that provide these capabilities.

GroupWise-to-Exchange 2000 Interoperability Architecture

A phased migration, where users migrate slowly from the old system to the new system, is considerably safer than the alternative method, an all-at-once migration. The disadvantage of a phased migration is that administrators must support two systems for however long the phased migration lasts. In the all-at-once approach, users can be migrated from the old system to the new system in a single weekend. However, an all-in-one migration may not be technically feasible in a large company. For example, in a 10,000-user company located in multiple countries, the tasks to complete the migration of e-mail messages and other data and to install Outlook on every workstation, would be a time-intensive task.

When it comes time to migrate GroupWise data to your Exchange messaging system, the migration process can take the average organization several days to complete (depending on a variety of conditions, including network traffic and volume of data). For this reason, a temporary period of interoperability, or "coexistence," between the two messaging systems is necessary. Interoperability allowed Fabrikam to continue its business functions uninterrupted during the migration process because both systems can communicate with each other and provide users with all necessary information, regardless of which system stores the information.

This section describes the tools that make interoperability between GroupWise and Exchange 2000 possible. Also covered are the preparations the migration team went through on various components in its GroupWise and Exchange messaging systems.

Note: This section describes Fabrikam's coexistence plan. The configuration details are covered in the next phase of the migration, deploying (Chapter 3).

The following three components make up the GroupWise-to-Exchange coexistence architecture.

• Directory Synchronization of the user objects and distribution lists Exchange 2000 GroupWise Connector (the GroupWise connector) provides this function.

• Mail Transport and meeting requests between GroupWise and Exchange The GroupWise connector provides this function.

• Free and Busy schedule checking Exchange 2000 Calendar Connector provides this function. Calendar Connector allows users on either system to see the free and busy schedule of users when they schedule a meeting.

GroupWise-to-Exchange Directory Synchronization

The GroupWise-to-Exchange directory synchronization architecture requires you to set up the following components:

• Organizational unit An organizational unit in Active Directory holds contact objects for the users on GroupWise. These contact objects in this organizational unit allow Exchange users to send e-mail to users on GroupWise.

• Foreign domain A foreign domain in GroupWise holds mail-enabled Active Directory objects as foreign objects in GroupWise. The contact objects in this foreign domain allow GroupWise users to send e-mail to users on Exchange.

• GroupWise connector The GroupWise connector performs the actual directory synchronization.

• GroupWise API gateway GroupWise API gateway interfaces with the GroupWise connector.

As a first step in coexistence, administrators created an organizational unit called GroupWise Users in Active Directory. This organizational unit contained Active Directory contact objects that represented existing GroupWise users, distribution lists, and resource objects that had not yet been migrated.

During the interoperability phase, the GroupWise connector was used to perform directory synchronization between the existing GroupWise directory and Active Directory. Administrators configured each GroupWise connector to connect to a GroupWise API gateway. At Fabrikam, this GroupWise API gateway was in Richmond.

Note: If you have not installed the GroupWise API gateway in your GroupWise environment, you must install it for interoperability.

Foreign Domain in the GroupWise System

In the existing GroupWise system, administrators created a GroupWise foreign domain. This foreign domain contained external foreign objects from Exchange 2000 that were being replicated back to GroupWise, such as users who have already been migrated or new users on Exchange who were never part of the GroupWise system.

The migration team decided to name the foreign domain in the GroupWise system "Exchange."

GroupWise Connector Operations (Users, Resources, and Distribution Lists Synchronization)

The GroupWise Connector synchronizes all valid GroupWise users, resources, and distribution lists that have a GroupWise visibility setting of "system." These objects are synchronized into the Active Directory organizational unit as contacts. Items with a visibility other than system are not synchronized into Active Directory.

Distribution Lists Synchronization and Operation

All GroupWise distribution lists that had "system" visibility were synchronized with Active Directory. Users on Exchange see these distribution lists as contacts. The owner of each distribution list decided whether to synchronize these distribution lists into Active Directory or to leave them GroupWise-only.

Meanwhile, distribution lists on Exchange were replicated by the GroupWise connector back into the GroupWise foreign domain as a foreign object. In either case, users could send an e-mail to the distribution list. If the distribution list exists on the opposite system, the connector sends the message to the other system. The other system performs the distribution list expansion and sends the message to the appropriate users.

The GroupWise connector does not allow distribution lists that contains a forward slash (/) in its name or exceeds 50 characters in its name. These distribution lists are not be synchronized into Active Directory.

Note: GroupWise external foreign user accounts that are system-visible and belong to foreign domains and post offices should also be synchronized with Active Directory as contacts. (Fabrikam had no foreign users.)

Directory Synchronization Design

The GroupWise connector was installed on the Exchange 2000 bridgehead server in Richmond (BRG-RI01P) and communicated with the GroupWise API Gateway. Figure 2.16 illustrates how directory synchronization between Exchange and GroupWise functioned at Fabrikam.

Figure 2.16: Directory synchronization between GroupWise and Exchange 2000

GroupWise Directory Synchronization Schedule

Administrators scheduled the directory synchronization between GroupWise and Exchange 2000 to run all the time.

Mail Transport

This section describes how e-mail was sent between the two messaging systems, and how the new e-mail naming standard was phased in without disrupting e-mail availability.

As discussed earlier, one of Fabrikam's migration goals was to change its corporate identity from Fabrikam Worldwide to Fabrikam, Inc. This change included changing the company domain name from fabrikamworldwide.com to fabrikam.com. To accommodate the change, Internet (SMTP) e-mail addressed to, for example, asteiner@fabrikamworldwide.com was delivered to the GroupWise Internet Agent. Meanwhile, Internet e-mail addressed to alan.steiner@fabrikam.com was delivered to the Exchange 2000 SMTP connector.

The key to delivering mail to the appropriate system was the design of the DNS MX records for @fabrikamworldwide.com and @fabrikam.com.

DNS Modifications

Internally, Fabrikam had the following records defined in DNS for the mail exchanger (MX) records (as previously mentioned in Chapter 1, Planning).

fabrikamworldwide.com    IN    MX 10 fisk.fabrikamworldwide.com
fabrikamworldwide.com    IN    MX 20 willoughby.fabrikamworldwide.com

For e-mail coexistence, the following MX records needed to be added to account for MSGBRDG-RI01P and MSGBRDG-RI02P, the new Exchange 2000 bridgehead servers in Richmond:

fabrikam.com      IN     MX 10 E2kSmtp1
fabrikam.com      IN     MX 20 E2kSmtp2
E2kSMTP1    CNAME   MSGBRDG-RI01P.Fabrikam.com
E2kSMTP2    CNAME  MSGBRDG-RI02P.Fabrikam.com
MSGBRDG-RI01P.Fabrikam.com      A          172.19.75.7
MSGBRDG-RI02P.Fabrikam.com      A          172.19.75.8

The CNAME entry is a way of representing a server such that, if the server name were to change, the only configuration change you would need to make is the CNAME entry. Fabrikam requested that CNAME records be implemented to provide the company with the flexibility of changing servers to support its SMTP interface.

Note: Fabrikam's decision to change its e-mail domain name made this architecture possible. If your organization has decided to retain its existing e-mail domain when it migrates to Exchange, the architecture will need to be modified slightly. Because you can have only one authoritative system for an e-mail domain, this modified design would only have one MX record defined for it. If Fabrikam had kept its old domain name, the @fabrikamworldwide.com MX record would continue to point to the GroupWise Internet Agent. After all users or the majority of the users had been migrated to Exchange, the MX record could be modified to point to Exchange (for example, fabrikawmworldwide.com IN MX E2KSmtp).

After Migration Is Completed

After all GroupWise users are migrated to Exchange, the GroupWise address space (fabrikamworldwide.com) will be added to each Exchange user's account (through recipient policies). After all GroupWise users are migrated to Exchange, the GroupWise Internet Agent will be deactivated and the MX record will be modified to deliver mail bound for fabrikamworldwide.com to one of the Exchange bridgehead servers. This configuration allows the Exchange messaging system to continue receiving and delivering e-mail messages addressed to employees at their old e-mail address.

For example, the following DNS MX modification will be made:

fabrikamworldwide.com    IN    MX 10  E2KSmtp1
fabrikamworldwide.com    IN    MX 20  E2KSmtp2

Figure 2.17 shows how mail is received from the Internet and routed between the two messaging systems.

Figure 2.17: SMTP coexistence between GroupWise and Exchange 2000

Mail bound for @fabrikam.com enters through the Exchange bridgehead server (MSGBDG-RI01P) in Richmond. Then, Exchange routes the mail internally to the Exchange server that contains with the recipient's mailbox.

Mail bound for @fabrikamworldwide.com enters through the GroupWise Internet Agent server in Richmond. Then, GroupWise routes the mail internally.

It was inevitable that mail addressed to the GroupWise domain (@fabrikamworldwide.com) would be sent to a user who had already been migrated to Exchange. The migration team anticipated this situation by creating a forwarding rule in each user's GroupWise mailbox on the night the user was migrated. This rule forwarded mail to the user's Exchange mailbox (over the GroupWise connector) and also replied to the sender, informing the sender of the user's new e-mail address. After forwarding the mail, the rule deleted the message on the GroupWise server.

All mail sent to the Internet from an Exchange 2000 user has the return address of firstname.lastname@fabrikam.com, which represents the users primary SMTP proxy address. Thus, external users who reply to these messages will have their mail delivered directly to Exchange.

Fabrikam Users' E-mail Addresses

After the migration, Fabrikam users on Exchange will have multiple e-mail addresses associated with their account. They are as follows:

• SMTP (primary address): firstname.lastname@fabrikam.com

• SMTP (secondary address): loginid@fabrikamworldwide.com

• SMTP (secondary address): loginid@fabrikam.com

• GWISE: FirstAdministrativeGroup.Exchange.loginid

The primary SMTP address is used as the From address, or return address, for all mail sent to the Internet. The secondary SMTP address will be used after all users have migrated to Exchange and the MX record for @fabrikamworldwide.com is modified to point to the servers running Exchange.

An Exchange recipient policy will be used to create these addresses. For more information, see the "Recipient Policies" procedure in Appendix A.

Web Mail Coexistence Strategy

The Fabrikam migration team developed the following coexistence strategy for Fabrikam's web mail functionality. This strategy allows users of both GroupWise WebAccess and Exchange Outlook Web Access to access their mailboxes. In GroupWise, Fabrikam employees used the following URL:

https://webmail.fabrikamworldwide.com

The migration team set up a parallel Web site that allows Outlook Web Access users to access to their e-mail on Exchange. This Web site was accessed at the following URL:

https://webmail.fabrikam.com

Note: The only change required to support this change is the addition of the DNS host name record, webmail.fabrikam.com. For example:

Webmail     A    OWAMSG-RI01P.fabrikam.com

Figure 2.18 illustrates how both GroupWise and Exchange users at Fabrikam access their e-mail over the Internet.

Figure 2.18: Web mail coexistence strategy

Calendar Transport

Calendar Connector handles the transfer of free and busy requests between the GroupWise and Exchange 2000 systems. Calendar Connector was released with Exchange 2000 Service Pack 1 (SP1).

Without Calendar Connector, users on GroupWise or Exchange can send meeting requests to each other over the GroupWise Connector. However, users on either system are not able to look at the free and busy calendar of users on the other system, making it difficult to efficiently schedule meetings.

Calendar Connector allows users on GroupWise or Exchange to do a free and busy schedule query for users on the other system. At Fabrikam, Calendar Connector was installed on the Exchange 2000 bridgehead server in the Richmond location (MSGBDG-RI01P). The bridgehead server needs a replica of the free and busy public folder. By default, the free and busy public folder is created on the first server in the Exchange 2000 organization. If Calendar Connector is not installed on the first Exchange server, you must create a replica of the free and busy folder.

How Free and Busy Requests from GroupWise to Exchange 2000 Work

When a GroupWise user attempts to schedule a meeting, the GroupWise client searches the GroupWise domain database to find which system the target account is on. If the account is located in the GroupWise foreign domain called "Exchange" (created by Exchange 2000 directory synchronization), the request will be sent to the GroupWise API gateway. The request is reformatted, placed in a queue, and then routed to the Exchange 2000 server's connector queue by means of the GroupWise connector.

Figure 2.19 shows Fabrikam's calendar coexistence architecture.

Figure 2.19: Calendar Connector between GroupWise and Exchange 2000

Calendar Connector processes the request by checking the Exchange system's free and busy folder for the Exchange user's calendar information. When the information is found, Calendar Connector sends the request back to the GroupWise connector. The connector then routes the free and busy request to the appropriate GroupWise API gateway. The GroupWise server's message transfer agent (MTA) relays the information to the MTA of the domain where the original requestor was located, and then to the requestor's GroupWise client. The fundamentals of this process are shown in Figure 2.20.

Figure 2.20: Exchange 2000 Calendar Connector

How Free and Busy Requests from Exchange 2000 to GroupWise Work

When Outlook users attempt to schedule a meeting, the Outlook client searches Active Directory to find which system the target account is on. If the recipient is a GroupWise user, and the Exchange free and busy folder does not contain free and busy data for this user, the request is placed in the GroupWise connector's queue and then delivered to the GroupWise domain's API gateway. The API gateway reformats the request, and then the domain MTA routes the free and busy request to the appropriate domain and post office. The post office agent (POA) processes the free and busy request and then sends it back to the domain's MTA or API gateway. The API gateway reformats the message, places it in a queue, and waits for the GroupWise connector to process the request. The GroupWise connector routes the message back to Exchange, and Calendar Connector processes this information by updating the local free and busy folder and by updating the Outlook client's free and busy screen.

If another request was performed on the same GroupWise user within 15 minutes of the previous request (you can configure this time period), Exchange uses the cached free and busy information rather than querying GroupWise again. If 15 minutes has passed since the GroupWise user's calendaring information was requested, the system sends a message to GroupWise as to obtain updated calendaring information for the user.

GroupWise-to-Exchange 2000 Migration Architecture

After the two messaging systems are communicating with each other and the coexistence architecture has been established, you can begin the actual mail migration.

Microsoft provides a tool to help with the migration. This tool, Exchange Migration Wizard, uses the GroupWise client API to open a user's mailbox on GroupWise. It extracts the mail and calendar data to a file. Then the wizard converts it to Exchange formatting and imports it to Exchange.

Exchange Migration Wizard only migrates data stored on the GroupWise server. Data stored on client computers (for example, in local archives) is not migrated by the wizard.

Note: To migrate local archives, users must converts their local archives back to standard mail data and put it back on the GroupWise server. Fabrikam allowed only executives and employees with specific permission to migrate local archives.

Exchange Migration Wizard migrates accounts on an account-by-account basis, meaning that objects used globally and that are not associated with one particular user account such as distribution lists, are not migrated by Exchange Migration Wizard. Distribution lists need to be re-created on Exchange.

Table 2.19 lists the most common messaging data types and how Exchange Migration Wizard supports them. When an object cannot be migrated, the table lists alternative migration methods.

Table 2.19 Migration objects

Exchange 2000 feature	GroupWise feature	GroupWise to Exchange 2000	Exchange 2000 to GroupWise	Alternative migration method
E-mail messages	E-mail messages	Yes	Yes	Not applicable
E-mail Read receipt	E-mail Read receipt	Yes	Yes	Not applicable
E-mail Read receipt	E-mail Read receipt	Yes	Yes	Not applicable
Non-Delivery report	Non-Delivery report	Yes	Yes	Not applicable
Importance	Importance	Yes	Yes	Not applicable
Sensitivity	Sensitivity	Yes	Yes	Not applicable
Meeting Requests	Appointments	Yes	Yes	Not applicable
Meeting Accepted	Meeting Accepted	Yes	Yes	Not applicable
Meeting Declined	Meeting Declined	Yes	Yes	Not applicable
Meeting Tentatively Accepted	Meeting Accepted	Appear as "Accepted"	Appear as "Accepted"	Not applicable
Meeting Request Read	Meeting Request Read	Yes	Yes	Not applicable
Meeting Request delivery	Meeting Request delivery	Yes	Yes	Not applicable
Meeting Updates	Meeting Updates	Appear as new meeting requests containing the word "Updated" in the subject line	Appear as new meeting requests containing the word "Updated" in the subject line	Not applicable
Meeting Reminder times	Meeting Reminder times	No	No	Not applicable
Meeting Cancellation	Meeting Cancellation	No	Yes	Not applicable
Task Requests	Tasks	Task requests appear as e-mail messages	Tasks appear as e-mail messages	Not applicable
All Day Meeting Requests	Notes	All day meeting requests appear as notes	Notes appear as e-mail messages with date and subject in the message	Not applicable
Outlook does not have a phone messages data type	Phone Messages	Appear as e-mail messages	Not applicable	Not applicable
Other Messages	Other Messages	Default to e-mail messages	Default to e-mail messages	Not applicable
Outlook (.pst) files	GroupWise local archives	Not migrated by migration tool	Not migrated by migration tool	Need to be unarchived back to the server (see notes below).
Outlook Contact folders	User/Personal Address Books	Not migrated by migration tool	Not migrated by migration tool	User must export to a *.nab file. Fabrikam created a conversion script and imported the data into Outlook.
Global Address List	Novell GroupWise Address Book	Synchronized by GroupWise connector	Synchronized by GroupWise connector	Not applicable
Distribution lists in Outlook Contacts folder	Personal Groups (distribution lists)	Not migrated by migration tool	Not migrated by migration tool	User must re-create in Outlook.
Distribution lists on computer running Exchange	Public Groups (distribution lists)	Not migrated by migration tool	Not migrated by migration tool	Administrator must re-create after migration.
Granting other users permissions to Outlook folders	Shared Folders	Not migrated by migration tool	Not migrated by migration tool	User must re-create in Outlook.
Rules	Rules	Not migrated by migration tool	Not migrated by migration tool	User must re-create in Outlook.
Filters	Filters	Not migrated by migration tool	Not migrated by migration tool	User must re-create in Outlook.
Delegates	Proxies	Not Migrated by Migration Tool	Not Migrated by Migration Tool	Users must re-establish their proxies and delegates after migration.
Words added to personal dictionaries	Words added to personal dictionaries	Not migrated by migration tool	Not migrated by migration tool	User must re-create in Outlook.
Exchange mailbox	External entity	Migrated by migration wizard	Migrated by migration wizard	Not applicable

Migration Considerations

As you plan your migration, the following sections contain other data and process considerations for migration.

Migration Errors During Export

During the mailbox migration process, the Fabrikam team encountered certain accounts that had difficulty migrating to Exchange. If the issue was encountered during the GroupWise data export step, many of these migration issues were resolved by running the GroupWise messaging database repair utility, GroupWise Check (GWCheck), available from Novell. The Fabrikam migration team found it sometimes had to run this tool multiple times to repair a user messaging database. Repairing a user messaging database significantly slowed down the migration process. The team learned that, if a user account had a problem migrating, it was best to remove the account from that night's migration and set it aside to migrate later. Then, part of the team ran Exchange Migration Wizard with the remaining accounts while other administrators repaired the problem GroupWise account's messaging database.

Expansion of Migrated Mail

Although determining a mailbox size limit was an important Exchange design decision, equally important are mail migration issues. The following considerations were presented to the Fabrikam management team:

• The amount of existing GroupWise e-mail that users would be allowed to migrate was a critical consideration. The amount of GroupWise e-mail you allow users to move significantly affects the time it takes to migrate a mailbox. Equally important, migrating a large volume of mail increases the risk of migration complications. For example, when Exchange Migration Wizard encounters a corrupted message, migrations stops until an administrator decides what to do with the message, thereby increasing migration time. Increasing migration time, in turn, affects the number of users that can be migrated each night, and the number of resources that need to be involved during the migration. Management decided to only migrate messages from the past 30 days.

• Related to the question of how much GroupWise mail to migrate is the matter of how to handle GroupWise local archives. There is no Microsoft tool that can convert GroupWise local archives to Outlook local archives. Exchange Migration Wizard only migrates mail data stored on the GroupWise server. Therefore, mail data in users' local archives is not migrated. If management allows data stored in GroupWise local archives to be brought over to the new Exchange system, each user needs to unarchive his or her mail back to his or her GroupWise mailbox on the server and then have that mail migrated. Most users have a great volume of mail in their local archives, which means putting these items back into their GroupWise mailboxes will greatly increase the amount of GroupWise data to be migrated (leading to the risks described above). Further, putting local archive data back on the mail server can cause that computer to run out of disk space. For these reasons, Fabrikam management decided not to migrate local archives. However, management decided to allow certain Fabrikam executives to take stored messages out of their local archives, put them back into their mailboxes on the GroupWise computer, and then migrate all their mailbox items.

  Note: Although there are third-party applications that can directly migrate GroupWise local archives to Exchange, at the time of this case study, these applications had not been tested by MCS.

• GroupWise, like Exchange, uses the concept of single-instance message storage. Single-instance storage, discussed earlier in this chapter in "Exchange Storage Group and Storage Design," is also relevant to mailbox migration because of the likelihood of mail expansion. For example, if a user sends a message with a 5 MB attachment to 500 users on the same server, only one copy of the message is stored in the GroupWise database. However, Exchange Migration Wizard migrates users one at a time, and single-instance storage is lost during the migration. Because GroupWise users are likely to be migrated at different times—and possibly to different Exchange servers—Exchange Migration Wizard cannot maintain all of the pointers to a single message. In this example, mail expansion occurs after migration because there will be 500 messages in the new Exchange mailbox store, and each message will include its own copy of the 5 MB attachment, which causes a space usage increase from 5 MB to 2.5 GB (500 * 5 MB). The amount of overall mail expansion will vary by organization, based on the number and size of widely-distributed, or "broadcast," messages sent to all users. Prior to migration, organizations should do an assessment of the number of broadcast messages sent and the size of these messages. Then, using this information, you can calculate an expansion figure to estimate the required size of hard disks running Exchange.

• At Fabrikam, this method predicted a 30 percent increase in mail storage size due to mail expansion. Therefore, a 10 GB GroupWise mail database would require approximately 13 GB on Exchange (Exchange hardware requirements are also discussed earlier in this chapter in "Exchange 2000 Hardware Planning"). It is important to note that mail expansion only occurs during migration. Because Exchange also has single-instance storage capability, a post-migration broadcast message sent to users on the same Exchange database is stored as only a single instance of the message.

Personal Address Books Migration

Microsoft has no tools to directly migrate personal address books from GroupWise to Exchange. However, the Fabrikam team developed a migration script to perform the migration. Users who wanted to have their personal address books migrated needed to use their GroupWise clients to export them to .nab files. The users needed to export their personal address books prior to the migration date of their accounts and place the .nab files on their server.

In addition, Outlook provides the ability to import Contact objects from a .csv file. The Fabrikam team mapped the layout of the .nab file to the .csv file and wrote a custom migration script that read the .nab file, re-ordered the fields to match the layout required by Outlook, and wrote the result to a .csv file. This migration script was relatively easy to create.

During the nightly migration, the migration team ran this migration script on the users' .nab files. Then, they imported the resultant .csv files into the users' mailboxes. Thus, the users received their personal address books in Exchange.

Client Rules

Although Fabrikam wanted to migrate client rules from the GroupWise client to Outlook 2000, Microsoft has no tools to directly migrate rules. Fabrikam employees must use Outlook Rules Wizard to re-create their rules in Outlook. Users can access Rules Wizard from the Tools menu in Outlook.

Shared Folders

GroupWise users have the ability to share their mailbox folders with other users. Migration Wizard can migrate the shared folders and the data they contain to Exchange, but there are no Microsoft tools for directly migrating users' shared folders permissions. To share folders after the migration, users must re-create these permissions on the appropriate folders in Outlook.

Note: Exchange users can only share their folders with other Exchange users; they will not be able to give access to their folders to GroupWise users.

Proxy Access

Microsoft has no tools to directly migrate the proxy access permissions that a user has given to his or her account. Fabrikam users will have to set up their proxies again. In Outlook, this procedure is called granting delegate access.

Note: Exchange users can only grant delegate access to their accounts or folders to other Exchange users. They will not be able to give delegate access to their folders to GroupWise users.

The way Exchange handles the ability to send e-mail as another user is different from the way GroupWise handles this action. Users must be extensively trained on how to set up delegates and send on behalf of another user in Outlook.

At Fabrikam, users (particularly, executives) use the proxy feature extensively. In retrospect, the team learned that it should have spent more time analyzing these requirements and planning how to handle them early in the design process. In this project, it turned out that the Fabrikam team did not discover this requirement until midway through the migration process. Because of this late discovery, the team had to overcome the difficulties during the migration to develop procedures and processes to handle Fabrikam's proxy access requirements.

Personal Dictionaries

Microsoft has no tools to directly migrate personal dictionaries from GroupWise to Exchange. At Fabrikam, some executives had added their own words to their GroupWise spelling checker dictionary and they wanted these words added to their new spelling checker dictionaries in Outlook. Although GroupWise stores these added words in a separate, identifiable file, the file is encrypted and encoded, and the Fabrikam team could not identify or develop a method to migrate these personal dictionaries to Outlook.

Public Distribution Lists and Personal Distribution Lists

Microsoft has no tools to directly migrate distribution lists from GroupWise to Exchange. Fabrikam users must re-create their personal distribution lists in Outlook.

Fabrikam administrators must re-create their server-side distribution lists in Active Directory. For more information, see "Distribution Lists" in Appendix A.

The new Exchange 2000 system has to provide administrators the ability to restrict who can send mail to particular distribution lists. This restriction prevents inappropriate mail from being sent to company-wide distribution lists, for example. It would also prevent "mail storms" caused by users replying to company-wide distribution lists.

External Entities

The GroupWise directory is separate from Novell Directory Services (NDS). GroupWise allows objects to exist in the GroupWise directory without having an NDS linked object. This kind of object is called an external entity. In Exchange, these external entities are handled as normal mailbox-enabled accounts. As such, the data in the external entity will be migrated using Exchange Migration Wizard.

Migration Logical Overviews

The illustrations and procedures in this section provide a logical overview for migrating the following types of GroupWise data to your Exchange system:

• Mail and calendar information

• Local archives

• Personal address books

Note: The following processes are intended as overview information only. Configuration specifics are covered in Chapter 3, Deploying.

Mail and Calendar Migration Process

Figure 2.21 shows the logical migration architecture Fabrikam used to migrate mailbox and calendar information. Migration servers, covered in Chapter 3, are Windows 2000 computers that are installed with clients for NDS and GroupWise, as well as Exchange System Manager. This configuration allows them to communicate with both messaging systems during the migration process.

Fabrikam used the following process to migrate the mail migration.

1. A member of the migration team logs on to one of the migration servers and starts Exchange Migration Wizard.

2. Migration Wizard reads users' mail in their GroupWise mailboxes and then converts the mail to an Exchange format. After conversion, Migration Wizard puts the mail into the users' new Exchange mailboxes.

3. During the migration process, Migration Wizard creates a message in each user's Exchange mailbox with the subject line Calendar Information. This message contains an attachment that contains the user's GroupWise calendar information.

During the setup of the user's computer running Windows 2000 Professional, including Outlook 2000 (at Fabrikam this task was performed by a dedicated desktop team), an administrator uses the Outlook Import and Export Wizard to complete the migration of the calendar information.

Figure 2.21: User migration process

Archive Migration Process

Figure 2.22 shows the logical migration architecture Fabrikam used to migrate users' archives. Because the most reliable method of migrating archived data from GroupWise to Exchange consisted of converting the local archives back to standard mail data and then transferring the data to a server for migration, Fabrikam administrators were concerned this method would create too much data and impede the company's migration process. For this reason, Fabrikam decided only executives and select employees would be allowed to migrate local archives.

Fabrikam used the following process to migrate the local archives.

1. Users are allowed to request to have their local archives migrated.

2. Each request is approved or rejected by Fabrikam management.

3. If approved, during the nightly migration process, the migration team disables the automatic archive functionality in GroupWise. Then the team converts user's local archives back to standard mail data on his or her GroupWise client computer and places the data on the user's GroupWise mail server.

4. The migration team migrates the GroupWise mail data to Exchange.

5. After migration is complete, the migration team reactivates the automatic archive functionality on GroupWise.

6. In Outlook, the user creates a local .pst file.

7. The user copies the mail data that had been previously stored in the GroupWise local archive to his or her .pst file.

Figure 2.22: Local archive migration process

Personal Address Book Migration Process

Figure 2.23 shows the logical migration architecture Fabrikam used to migrate users' personal address books.

Fabrikam used the following process to migrate the personal address book.

1. Users who want to migrate their personal address books are instructed that they must use their GroupWise clients to export the address books as .nab files. Users are also instructed to name each .nab files after the name of the corresponding personal address book.

2. Users save the .nab files on file servers in their home directory.

3. During the nightly migration process, the desktop team checks each migrating users' home directory for .nab files. (This desktop team is responsible for setting up users' computers running Windows 2000 Professional.)

4. If .nab files are found for the user, a member of the desktop team runs a customized conversion script to convert each .nab file to a .csv file. As mentioned earlier in this chapter, the conversion script was easy to create. Without a conversion script, users will have to re-create their contacts in Outlook by hand.

5. On the user's workstation, in Outlook, a desktop team member creates folders for every .nab file. For each folder, in the Create New Folder dialog box, under Folder contains, the desktop team member selects Contact Items.

6. A desktop team member uses the Outlook Import and Export Wizard to import the .csv file into the appropriate, newly-created Outlook contact items folder.

   

   Figure 2.23: Personal address book migration process

Chapter 3 Deploying

After the Fabrikam, Inc. migration team assessed the current GroupWise messaging conditions and future Microsoft® Exchange 2000 Server needs at Fabrikam (Chapter 1) and designed the Exchange organization and Exchange and GroupWise interoperability architecture (Chapter 2), the migration team was ready to test its Exchange deployment. Chapter 3 covers the deploying phase of the Fabrikam GroupWise migration, in which the migration team introduces its Exchange organization in stages, beginning in an isolated test environment and culminating in Fabrikam's production environment.

This chapter also discusses the steps Fabrikam followed to configure its Exchange servers, as well as how Fabrikam configured its Exchange and GroupWise interoperability deployment, including the Microsoft Exchange Connector for Novell GroupWise (GroupWise connector) and Exchange 2000 Calendar Connector.

Note: As discussed in Chapter 2, a period of interoperability, or coexistence, is often necessary during migrations so that users can retain messaging capability during the period of time it takes to migrate everyone to the new messaging system (at Fabrikam, 25 to 35 users migrate each night).

Chapter 3 also describes how Fabrikam set up its migration architecture, including how to prepare the GroupWise messaging system. The chapter concludes with the process the migration team followed to migrate a group of users every night.

Table 3.1 summarizes the goals and requirements of the deploying phase.

Table 3.1 Deploying phase overview

Resources	Tasks	Key deliverables
· Logical design and detailed design (created after developing phase) · Test plan · Test lab containing all system components with all components tested. · Updated risk assessment plan · Updated project plan	· Deploy Microsoft Active Directory® directory service in production environment. · Install and set up Exchange in production environment. · Set up the Exchange and GroupWise interoperability architecture. · Set up and configure backup software. · Set up migration servers. · Conduct pilot migration with IS department. · Assess the pilot migration and modify Exchange configuration accordingly. · Perform end-user migration at one office location at a time. · Shut down GroupWise system.	· Exchange architecture is operational in production environment. · Exchange operations architecture in place, such as administration, technical support, backup, virus scanning, and monitoring. · Users are trained and running on Exchange mail system · Help desk team able to handle support issues and network administrators able to manage and maintain the Exchange system. · Project plan updated. · Fabrikam migration team approval of deploying phase.

Migration Process Summary

This section provides an overview of the entire migration process. Each of the following steps is discussed in depth later in this chapter.

At the outset of the deploying phase, the Fabrikam migration team knew that, before it could begin migrating users, it had to accomplish the following tasks:

1. Prepare Active Directory and install Exchange 2000.

2. Prepare Novell Directory Services (NDS) and GroupWise.

3. Set up the GroupWise connector.

4. Set up Exchange 2000 Calendar Connector.

5. Configure the migration servers.

After the migration team extensively mapped out its Exchange organization during the developing phase (Chapter 2), the team began the deploying phase by deploying Exchange in the Fabrikam production environment. After the architecture was stabilized in production, the team began the pilot migration with a small group of users, the members of the Fabrikam IT department. The team used the pilot group deployment to identify and correct any problems in Fabrikam's Exchange architecture and migration processes (problems in either the topology design or deployment of the Exchange components). Only after the pilot group was successfully migrated to Exchange was the end-user migration process begun.

Important: It is worth mentioning again that this white paper assumes your Active Directory deployment is stable and replicating all relevant information correctly before you install Exchange 2000. In the "Installing Exchange" section later in this chapter (and in "Fabrikam Active Directory Design" in Chapter 2), Active Directory elements that directly affect your deployment of Exchange 2000 are discussed. However, be sure to consult Microsoft Consulting Services (MCS), Microsoft® Windows® 2000 Server Resource Kit Deployment Planning Guide, Windows 2000 Help, or other resources when designing and deploying your Windows 2000 Active Directory. Exchange 2000 will not work correctly without a solid and reliable Active Directory.

While the new Exchange organization was being deployed in Fabrikam's production environment, other members of the migration team prepared the GroupWise system for coexistence with Exchange and for migration. This preparation involved creating accounts in NDS to be used during migration, setting up the GroupWise API gateway, and creating a GroupWise external foreign domain.

After Exchange was ready for operation and GroupWise was prepared for migration, the migration team configured two tools for coexistence: the GroupWise connector and the Exchange 2000 Calendar Connector. Although neither of these tools was necessary for migration, the coexistence they provide allowed employees to continue working and communicating during the migration process, regardless of which messaging system they were on.

The final step before migration was preparing the migration servers. Fabrikam used four high-end desktop computers running Windows 2000 Advanced Server. The migration team installed Exchange System Manager (the primary Exchange 2000 management tool) and both an NDS client and a GroupWise client on each server. This configuration allowed the migration servers to communicate with both messaging systems.

The migration team migrated the Fabrikam IT department first, starting with the personnel on the migration project. The entire process was monitored closely, and after the pilot migration was considered satisfactory, the team migrated the rest of the employees in the Richmond office. After the team migrated users in the Richmond headquarters, they sent one migration server to each of the branch offices in Alexandria, Braintree, Chicago, and Munich so that users in those offices could also migrate to Exchange. Because of replication time and other complications that might arise due to the physical distance between offices, it was recommended that migration at Fabrikam be performed within each office. By having a migration server present at every site, administrators were able to perform all migrations locally.

Architecture Summary

Figure 3.1 illustrates the migration architecture used by Fabrikam and summarizes what was discussed in this section.

Figure 3.1: Fabrikam's migration architecture

Preparing Active Directory and Installing Exchange 2000

Fabrikam used the information in the following sections to set up its new Exchange organization. This section includes configurations made to Active Directory, the first Exchange server installed in Fabrikam's Richmond headquarters, and all subsequent Fabrikam Exchange servers.

Active Directory

As discussed in Chapter 2, Exchange affected certain construction principles of Fabrikam's Active Directory. Before the migration team could install Exchange, it was necessary to perform the additional directory tasks described below.

Figure 3.2 illustrates the Windows 2000 domain architecture.

Figure 3.2: Fabrikam's Windows 2000 domain architecture

Both domains were in Windows 2000 native mode.

Note: The switch from mixed mode to native mode cannot be reversed, and it should be done only if there are no domain controllers running Microsoft Windows NT® version 4.0 or earlier.

Create Security Groups

Fabrikam used the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in to create the following groups:

• Exchange Admins (alias ExchAdmins) This universal security group in corp.fabrikam.com was populated with the Fabrikam employees selected to administer Exchange. Because this group is a universial security group, users from either Fabrikam domain (fabrikam.com or corp.fabrikam.com) can be added and, thereby, have Exchange administrative rights. (Note that, in a single-domain environment, this group could be a global security group.) During ForestPrep, ExchAdmins group members were granted permissions to administrate Exchange upon installation.

  Note: Another option is to use Exchange Delegation Wizard to grant permissions. After you install the first Exchange server, you can run Delegation Wizard to grant the ExchAdmins group the necessary permissions. If you use this option, grant the ExchAdmins group Full Administrator permissions at the organization level. For more information about Exchange Delegation Wizard, see the "Installing Exchange" section later in this chapter.

  Important: Always designate multiple accounts with Exchange Full Administrator permissions as soon as possible, in case one account is accidentally deleted. For this reason, Fabrikam administrators gave the ExchAdmins group Exchange administrative rights during ForestPrep, rather than giving those rights to a single account and then having that account run Exchange Delegation Wizard to give the ExchAdmins necessary permissions.

• Exchange View-Only Admins (alias ExchViewOnlyAdmins) This group, also a universal security group created in the corp.fabrikam.com domain, was populated with Fabrikam's network administrators who who were not selected to administer Exchange. Members of this group need to create users with Exchange mailboxes and, therefore, need some permissions inside Exchange.

Note: Network administrators need only view-only Exchange permissions to create Exchange mailboxes in Active Directory accounts. After you install the first server running Exchange, use Exchange Delegation Wizard to grant this group Exchange View Only Administrator permissions at the organization level.

Create Accounts

The Fabrikam migration team requested the following accounts be created in Active Directory. Table 3.2 describes these accounts.

Table 3.2 Active Directory accounts for Exchange installation and migration

Account name	Display name	Description	Member of	Purpose
ExchSrvc	Exchange Service	Exchange service account	Domain Administrator group, Exchange Administrator group	Administrators use this account to log on when they install Exchange.
Gw2Ex	Migration Account	Mail migration account	Domain Administrator group, Exchange Administrator group	The migration team uses this account to log on and perform the nightly migration.
End-user accounts	<Last name>, <First name>	Exchange user accounts	Domain Users group	User accounts (disabled after creation). Initially, no Exchange mailbox was created for these accounts.

The migration team also created accounts for each Fabrikam Exchange administrator and then added the account to the Exchange Admins group. Finally, the team created accounts for each Fabrikam network administrator and then added the account to the Exchange View-Only Admins group.

Run Forest Prep and Domain Prep

The migration team ran both ForestPrep and DomainPrep in the Fabrikam domain. From the team's experience, the following points are worth noting in Fabrikam's application of ForestPrep and DomainPrep:

• The administrator who ran ForestPrep belonged to the Domain Admins group for fabrikam.com, the Enterprise Admins group, and the Schema Admins group.

• The administrator ran ForestPrep in the root domain (fabrikam.com). ForestPrep must always be run in the same domain as the Active Directory schema master, which is the root domain by default.

• ForestPrep created the Exchange organization, already determined to be called "Fabrikam" in Active Directory.

• When prompted during ForestPrep, the administrator chose the ExchAdmins account as the account that would grant Exchange permissions to other accounts.

• The administrators who ran DomainPrep belonged to the Domain Admins group in the corp.fabrikam.com domain.

• The administrators ran DomainPrep in every domain that contained an Exchange server or Exchange users (corp.fabrikam.com).

• Though not necessary, the administrators also ran DomainPrep in the root fabrikam.com domain, in case, at some point in the future, Fabrikam puts Exchange accounts in that domain. In the root domain, a member of the local Domain Admins group ran DomainPrep.

For more information about ForestPrep and DomainPrep, see the "Exchange 2000 Schema Extensions" section in Chapter 2 and the Exchange Up-to-Date article ForestPrep and DomainPrep at https://go.microsoft.com/fwlink/?linkId=5224.

Create Organizational Units

Administrators used the Active Directory Users and Computers snap-in to create a new organizational unit called GroupWise Users. This organizational unit contains objects that represent users on the GroupWise system.

DNS

Chapter 2 "DNS Modifications" described the DNS records Fabrikam administrators added for MSGBRDG-RI01P and MSGBRDG-RI02P, the two new Exchange bridgehead servers. The DNS additions allowed Fabrikam employees to receive e-mail after they migrated to the Exchange system.

In addition, administrators added two CNAME records. The following CNAME record was added for Outlook® Web Access:

Webmail.fabrikam.com  IN  CNAME  MSGOWARI-01P

And the following CNAME record was added for Outlook clients, as discussed in "Outlook Profile Generation" in Chapter 2.

Exchange.corp.fabrikam.com  IN  CNAME  MSGRI-01P.corp.fabrikam.com

This second CNAME record allows any employee who installs Outlook on his or her workstation to simply enter "Exchange" when prompted for his or her Exchange server.

Checklist: Pre-Exchange 2000 Setup

The Fabrikam migration team and network administrators used the checklist in Table 3.3 to prepare their organization for the Exchange installation. Some of the actions in the checklist are based on discussions in this section. Other actions in the checklist are necessary preparation for the configurations described in the "Installing Exchange" section later in this chapter.

Use this checklist as a guideline for your own organization before you install your first Exchange server.

Table 3.3 Pre-Exchange 2000 setup checklist

Step	Action	ü
1	Confirm that domain controllers and global catalog servers are installed and configured correctly. In the root domain fabrikam.com, the domain controllers and global catalog servers were: · DC-RI01P (global catalog and schema master for the entire Active Directory forest) · DC-RI01P (domain controller) In corp.fabrikam.com, the domain controllers and global catalog servers were: · DC-RI03P (global catalog) · DC-RI04P (domain controller)
2	Confirm that Active Directory Flexible Single Master Operation (FSMO roles) is set up correctly on the four servers listed in Step 1. For more information about operations master roles, see your Windows 2000 Server Help and Microsoft Knowledge Base article 197132, "Windows 2000 Active Directory FSMO Roles," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=197132.
3	Confirm that Windows 2000 Service Pack 2 (SP2) is loaded on all domain controllers and global catalog servers: at a command prompt, type winver.
4	Confirm that Active Directory Integrated DNS is installed on all domain controllers.
5	Install the Windows 2000 Support tools from the support folder on the Windows 2000 Server CD-ROM.
6	From the Support tools, run the Netdiag.exe utility on all domain controllers. Make sure that no errors are detected. If errors are detected, resolve them before proceeding. For more information about these and other Support tools, see your Windows 2000 Server Help.
7	On every domain controller, run the Dcdiag.exe utility. Make sure that no errors are detected. If errors are detected, resolve them before proceeding.
8	Confirm that DNS is working properly: at a command prompt, type nslookup.
9	On one of the corp.fabrikam.com domain controllers, verify that the domain is operating in native mode. On the desktop, right-click My Computer, and then click Properties. The General tab displays the domain's mode.
10	In the corp.fabrikam.com domain, create the Exchange Administrator (alias: ExchSrvc) account, and then add the account to the Domain Administrator group.
11	In the corp.fabrikam.com domain, create the Exchange Admins (alias: ExchAdmins) universal security group. Note that you can only create universal security groups in native-mode domains.
12	Add the ExchSrvc account to the Exchange Administrator group.
13	In the corp.fabrikam.com domain, create the Exchange View Only Admins universal security group (alias: ExchViewOnlyAdmins).
14	On DC-RI01P, the schema master, insert the Exchange 2000 Enterprise Server CD-ROM. Run ForestPrep (at a command prompt, type: <drive>: setup\i386\setup /forestprep) When prompted, give the ExchAdmins group account Full Exchange Administrator permissions.
15	After you allow time for replication, verify that ForestPrep finished extending the schema and that all extensions were replicated. Run the Windows 2000 Support tool Ldp.exe (the Active Directory Administration tool) to make this verification. Perform the following steps in Ldp.exe: 1. On the Connection menu, click Bind, and then enter a valid user name and password. 2. On the Browse menu, click Search. In Search, enter the following information: Base DN: cn=schema,cn=configuration,dc=fabrikam,dc=com Filter: (adminDescription=*Exch-Schema-Version*) 3. Click Options. In Search Options, in Attributes, type the following: ldapDisplayName,rangeUpper 4. Click OK. In Search, click Run. 5. If object not found is returned, the schema extensions have not yet replicated. If you can bind to the object, look at the rangeupper attribute and see if it is set to 4397, which indicates the schema is fully replicated. For more information about using Ldp.exe, see the Microsoft Knowledge Base article 224543, "Using ldp.exe to Find Data in the Active Directory," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=224543.
16	On each global catalog server (DC-RI01P in fabrikam.com and DC-RI03P in corp.fabrikam.com), insert the Exchange 2000 Server Enterprise CD-ROM. Run DomainPrep (at a command prompt, type: <drive>: setup\i386\setup /domainprep) Again, running DomainPrep in the root domain (fabrikam.com) is not necessary, but the migration team ran it anyway to allow someone at a later time to install mailbox-enabled accounts in the root domain.
17	In the DNS MMC snap-in, create the CNAME record webmail.fabrikam.com and point the record to the front-end server to be used for Outlook Web Access. At Fabrikam, this server was MSGOWA-RI01P.
18	To verify DomainPrep security policy replication, in each domain, run Policytest.exe. This tool is available on the Exchange 2000 Server Enterprise CD-ROM. If replication completed, you will see: Right found: "SeSecurityPrivilege" For more information about this step, see the white paper Microsoft Exchange 2000 Internals: Installation and Setup at https://go.microsoft.com/fwlink/?LinkId=5906.
19	Confirm that all Windows 2000 subnets containing servers running Exchange are defined: in the Active Directory Sites and Services snap-in, click Subnets and verify that a subnet object is defined for each subnet in which you plan to install an Exchange server. Then make sure every subnet is associated with the appropriate site. Note It is important to ensure that the domain controllers for the fabrikam.com domain are in a separate Windows 2000 site from the domain controllers in corp.fabrikam.com. (Follow the logical and physical Active Directory designs displayed in Figures 2.1 and 2.2 to achieve this.) Make sure that your Exchange servers are part of the Windows 2000 site containing the domain controllers for the corp.fabrikam.com site. This configuration controls which global catalog servers the Exchange servers use for directory lookups. If the Exchange servers used the global catalog servers in the root domain, they would have problems performing distribution list expansion.
20	If the computers that will run Exchange have more than 1 GB of memory, modify the Boot.ini file with the /3gb switch. For more information about this switch, see the Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
21	Create a CNAME record called Exchange in the corp.fabrikam.com zone and map it to MSGRI-01P: Exchange.corp.fabrikam.com IN CNAME MSGRI-01P.corp.fabrikam.com

Installing Exchange

After the migration team completed the pre-Exchange 2000 setup checklist, the team installed the first Exchange server in its production environment. This section contains a summary and checklist for this process, followed by a checklist of configurations and settings Fabrikam made to its new Exchange servers.

Appendix B contains detailed procedures for installing Exchange on different types of servers, depending on their role in the Exchange organization (for more information about these roles, see "Exchange Server Hardware Planning" in Chapter 2). In both Appendix B and in this section, the following assumptions are made regarding the computers running Windows 2000 Server in your organization:

• Service Pack 2 is installed on all computers running Windows 2000 Server or Advanced Server.

• SMTP and NNTP are installed on all servers that Exchange will be installed on.

• All computers are named according to the naming standards discussed in Chapter 2.

• The team installing Exchange has all necessary Windows passwords and permissions.

• Date and time settings are accurate on all computers.

• TCP/IP is configured, including DNS and WINS.

Note: Successfully completing the pre-Exchange 2000 setup checklist ensures all of these conditions are met and provides a solid, stable, and reliable Active Directory in which to introduce Exchange.

For more information about using Exchange 2000 Installation Wizard, see Chapter 19, "Installing Exchange," in Exchange 2000 Server Planning and Installation Guide. This book comes with Exchange 2000.

Fabrikam needed three types of Exchange servers: bridgehead servers, standard messaging servers, and a front-end server for Outlook Web Access. Figure 3.3 illustrates the Component Selection page when you install a bridgehead server. This page will vary if you install a standard messaging server. All other pages are the same between the two types of servers. For more information about the procedures for configuring an Outlook Web Access server, see Appendix A.

Figure 3.3: Custom installation for Exchange 2000 bridgehead server

Note: To install the GroupWise connector, on the Action menu, you must select Custom, and then select Microsoft Exchange Connector for Novell GroupWise.

Figure 3.4 illustrates the Component Selection page that you see when you install standard messaging servers. Use the Typical settings for this type of server.

Figure 3.4: Typical installation for standard Exchange 2000 server

Note: During all Exchange server installations, click Change Folder and select the appropriate drive for the type of server you are installing. By default, Setup installs Exchange on the same drive as the Windows 2000. This default behavior does not match any of the recommended drive designs described earlier in this chapter or in Appendix B.

Checklist: Installing Exchange

The Fabrikam team used checklists extensively to ensure that a consistent process was used to build each server. In addition, the team saved checklists in a documentation folder on each server and used the checklists for troubleshooting and maintenance purposes.

Fabrikam administrators used the checklist in Table 3.4 to install Exchange on servers intended for large offices. For checklists used for small offices, medium offices, bridgehead servers, and Outlook Web Access servers, see Appendix B.

Table 3.4 Installing Exchange checklist

Step	Action	ü
1	Receive server from the Windows 2000 team.
2	Confirm that RAID configuration matches designed configuration: · Two 9 GB or Two 18 GB; RAID1; Disk 0 · C: (3.71 GB); formatted NTFS; System · E: (1.17 GB); formatted NTFS; OS recovery partition · F: (1.67 or 9.67 GB); formatted NTFS; Applications; Exchange binary files · Z: (2 GB); formatted NTFS; Paging (swap) file · Two 9 GB; RAID1; Disk 1 · L: (8.46 GB); formatted NTFS; Exchange transaction log files · Four 18 GB; RAID0+1 or RAID5; Disk 2 · N: (67.8 GB); formatted NTFS; Exchange databases Use the disk array management tool from your hardware vendor. Although Windows provides software-level RAID, Microsoft Consulting Services recommends using the hardware RAID provided by the SCSI controllers. Note The Exchange transaction log files must be on a dedicated RAID1 drive set. Do not allow any other applications to use the Exchange 2000 transaction log set.
3	Verify Windows 2000 Licensing Mode is set to per seat.
4	Check TCP/IP settings: 1. At a command prompt, type ipconfig /all 2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the predetermined design. Note DNS is critical for Exchange. If you install Exchange on a DNS server, do not configure the DNS setting on the Exchange network interface card (NIC) to the local server; instead, use another DNS server.
5	In My Network Places, verify that File and Printer Sharing for Microsoft Networks setting is set to Maximize Data Throughput For Network Applications.
6	Confirm that the computer name is set correctly, and then join the computer to the domain (corp.fabrikam.com).
7	In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8	Create the MMC Exchange 2000 console, and add the following MMC snap-ins: · Active Directory Users and Computers · Active Directory Domains and Trusts · Active Directory Sites and Services · Event Viewer · Disk Management · Services Save the MMC at Desktop Level for All Users. For information about creating MMC snap-ins, see your Windows 2000 Help.
9	On the desktop, rename the My Computer icon to <computer name>.
10	Perform the following steps: 1. Check Event Log properties. 2. Confirm that Maximum Log Size is set to 16384 for Application, System, and Security log files. 3. Confirm that Overwrite as needed is selected.
11	Confirm the paging file is set to: · Drive C: 5 MB · Drive Z: 1955 MB To confirm the paging file is set 1. On the desktop, right-click the < computer name> icon (formerly My Computer, which you renamed in Step 9), and then click Properties. 2. In System Properties, on the Advanced tab, click Performance Options. 3. In Performance Options, under Virtual memory, click Change. 4. In Virtual Memory, check the paging file settings. If they are not set properly, type the appropriate sizes, and then click Set. Note These settings were optimized for Fabrikam's networking environment. Your organization may require different paging file settings. For more information about paging files, see your Windows 2000 Help.
12	Confirm that Maximum Registry Size is set to 150 MB To confirm Maximum Registry Size is set 1. Follow the same procedure in Step 11. 2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB) setting is correct. For more information, see your Windows 2000 Help.
13	If you have not done so already, add the /3gb switch to the Boot.ini file for servers with more than 1 GB of memory, For more information about this switch, see the Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14	Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000 Server CD-ROM.) This test ensures correct Active Directory and DNS integration and verifies where the Exchange servers look to find domain controllers, global catalog servers, and other services. Run the following variations of Nltest.exe in the corp.Fabrikam.com domain: · nltest /dsgetdc:corp · nltest /dclist:corp · nltest /dsgetsite Note If you get an error, restart the Net Logon service. If restarting the service does not correct the error, you have a DNS problem, or your Windows 2000 sites are not defined correctly. You must work with Active Directory and network administrators to remedy the situation before you proceed.
15	Perform the following steps: 1. Start the Active Directory Sites and Services snap-in. 2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your first site), and then click Servers. 3. Confirm that the Exchange server is listed.
16	Insert the Exchange 2000 Server CD-ROM and run Setup.
17	Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at https://www.microsoft.com/exchange/downloads/2000/sp2/. Note After you install SP2, the help files for Outlook Web Access clients must be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the first screen you see when you start EX2KSP2_server.exe), you must select Outlook Web Access Help Files, and then double-click the appropriate .msi file for each client language you support.
18	Move the transaction log files to the transaction log drive (drive L). For more information about how to move the files, see "Transaction Logs" in Appendix A.
19	Move the Exchange databases to drive N. For more information about how to move databases, see "Exchange Databases" in Appendix A.
20	Create a mailbox recipient policy and start the mailbox management process. For more information, see "Create a Mailbox Recipient Policy (Mailbox Manager)" in Appendix A.
21	Increase the log buffers. For more information about how to increase the log buffers, see "Log Buffers" in Appendix A.

Checklist: Configuring the First Exchange Server

The Fabrikam migration team used the checklist in Table 3.5 to initialize the Exchange architecture after the team installed the first server running Exchange. This checklist includes all of the necessary configurations to meet the Fabrikam messaging needs defined in Chapter 1 and provides the solutions the migration team designed in Chapter 2.

Note: In each step, the name of the appropriate procedure in Appendix A is included.

Use this checklist as a guideline for your own organization when you configure the first Exchange server installed in your organization.

Table 3.5 Configuring the first Exchange server checklist

Step	Configuration	ü	Section in Appendix A
1	Display administrative groups and routing groups in System Manager.		Administrative Groups and Routing Groups Visibility
2	Delegate organization-level permissions to Exchange view only administrators.		Exchange Administration Delegation Wizard
3	Create and configure Fabrikam's recipient policy.		Fabrikam Recipient Policy
4	Create and configure Fabrikam's contact recipient policy		Fabrikam Contact Recipient Policy
5	Configure Mailbox Manager.		Create a Mailbox Recipient Policy (Mailbox Manager)
6	Create a system policy container in System Manager.		Create a System Policy Container
7	Create a mailbox store policy.		Create a Mailbox Store Policy
8	Apply the mailbox store policy to all mailbox stores.		How Fabrikam Configured Its Mailbox Store Policy
9	Create a server policy.		Create a Server Policy
10	Apply the server policy to all Exchange servers.		How Fabrikam Configured Its Server Policy
11	Create a public store policy.		Create a Public Store Policy
12	Apply the public store policy to all public stores.		How Fabrikam Configured Its Public Store Policy
13	Allow only a few people to create top-level public folders.		Configure Public Folder Permissions
14	Set a maximum message size for message delivery.		Message Size Limits
15	Restrict automatic replies to the Internet.		Replies to the Internet
16	Filter unsolicited commercial e-mail. Note: If you monitor Exchange, be aware that the monitoring agent could send error and warning messages with a blank sender. If you have activated message filtering, these monitoring messages could be filtered.		Set Message Filtering
17	Rename the first routing group to RI RG.		Routing Groups
18	Create and populate remaining routing groups.		Routing Groups
19	Create and configure routing group connectors. Note Routing groups only go one way. When Exchange Setup prompts you, make sure you configure connectors in the opposite direction.		Routing Group Connectors
20	Configure the enterprise Recipient Update Service by pointing the MSGRI-01P Recipient Update Service to DCRI-01P (in the root fabrikam.com domain). Have the domain Recipient Update Service point to DCRI-03P, a domain controller in corp.fabrikam.com. Create a second Recipient Update Service on MSGRI-02P and point it to the local domain controller DCRI-04P. Ideally, for maximum replication speed, create a domain Recipient Update Service on every domain controller.		Recipient Update Service
21	Create a domain Recipient Update Service in each remote office that has a local domain controller and an Exchange 2000 server. Point the domain Recipient Update Service from the remote office Exchange 2000 server to the remote office domain controller.		Recipient Update Service
22	Replicate the Free and Busy folder and offline address book from MSG-RI01P throughout the organization		Configure Public Folder Replication

After the migration team configured the first server running Exchange, the team installed Exchange on the remaining Fabrikam servers. The configuration on all subsequent Exchange servers included joining those servers to the server, public store, and mailbox store policies created and defined on the first Exchange server. For more information, see "Adding Servers to the Server Policy" in Appendix A.

After the migration team installed Exchange and configured all Exchange servers appropriately, the team was ready to configure the coexistence tools: the GroupWise connector and the Exchange 2000 Calendar Connector.

Preparing Novell Directory Services and GroupWise

While some of the migration team set up the Exchange system in Fabrikam's production environment, other members of the migration team prepared the GroupWise system. This section describes the GroupWise configurations that the migration team made to prepare the system for coexistence and migration.

Important: This section contains procedures for configuring your GroupWise system. Consult your GroupWise documentation or GroupWise administrators in your organization before making changes to your GroupWise system.

Novell Directory Services and GroupWise Requirements

You must install the following components on the Novell NetWare server that hosts the migrating GroupWise users.

• Novell NetWare version 3.x or later

• GroupWise 4.1 API Gateway NetWare Loadable Module (NLM)

• Novell NetWare Administrator

• Novell GroupWise, version 4.1 or later

  Note: This migration case study is based on Novell GroupWise version 5.5.

• GroupWise Patch 2 for API NLM/OS2

Install GroupWise API Gateway

Install GroupWise 4.1 API Gateway NLM on the GroupWise domain that you connect to with the GroupWise connector. For installation instructions and to download GroupWise 4.1 API Gateway NLM, see the Novell Support & Downloads Web site at see https://support.novell.com.

Install Gateway Patch 1 and Patch 2

Install the GroupWise Patch 1 and Patch 2 for API NLM/OS2 (Gw41api2.exe). The patches allow GroupWise to expand messages sent to GroupWise groups from Exchange. For more information about getting these patches, see the Novell Support & Downloads Web site at https://support.novell.com/.

Based on the information above, Fabrikam installed the following patches on its API gateway:

• API GW 4.10b (release date June 4, 1997)

• API GW SP1 4.10b (release date April 13, 1998)

• API GW SP2 4.10b (release date November 3, 1999)

Activate Distribution List Expansion

During coexistence, Exchange users can see GroupWise distribution lists in the Exchange global address list (GAL). When an Exchange user sends a message to a GroupWise distribution list, only one copy of the message is sent over the GroupWise connector. If distribution lists are activated on the GroupWise side, the API gateway receives the message and sends it to all members of the distribution list.

Note: For distribution list expansion to work, the /group line in the Ngwapi.prm API gateway configuration file must not be commented, and GroupWise Patch 2 for API NLM/OS2 (Gw41api.exe) must be installed.

To activate distribution lists in GroupWise

1. Find the Ngwapi.prm file, which was installed in the API gateway root directory.

2. Open this file with either Notepad (Windows) or Edit (NetWare).

3. Find the line that contains ;/group and remove the semi-colon (;).

4. Save the file.

For these changes to take effect, you must restart the API gateway.

Create the API Gateway

After you install the required software, use NetWare Administrator to create the API gateway in the GroupWise domain that will connect to Exchange through the GroupWise connector.

To create the API gateway

1. In NetWare Administrator, on the Tools menu, click NDS Browser.

2. Select the GroupWise domain that is connecting to Exchange. On the Object menu, click Create.

3. Click GroupWise Gateway Internet Agent.

4. In Create GroupWise Gateway/Internet Agent, click Gateway. Be sure the Internet Agent check box is not selected.

   Note: GroupWise versions 5.0 and 5.1 refer to this property page as Create GroupWise Gateway.

5. Type a Gateway Name that is unique within the GroupWise domain. Fabrikam used API.

To configure the API gateway

1. In Gateway Home Directory, type the name of the directory where gateway files are installed.

2. Verify that Time Zone is set to the same time zone used by the Exchange bridgehead server that will run the GroupWise connector.

3. In Database Version, click 4.x. This setting refers to the gateway version.

4. In Platform, click NetWare Loadable Module.

5. In Gateway Type, click API.

6. Click Define additional properties, and then click Create to open the GroupWise Gateway/Internet Agent property page.

7. Click Optional Gateway Settings.

8. In Directory Sync/Exchange, click Exchange. This means that GroupWise will wait until prompted to send a directory update to Exchange.

9. In Convert Status to Messages, click Yes. If you do not make this selection, Exchange will not receive status messages such as delivery receipts.

10. In Outbound Status Level, click Full.

11. Click Required Parameters.

12. Change the root directory paths in the Gateway File Paths section to absolute paths in the form Server name/Volume:\Path.

    Note: You can find the universal naming convention (UNC) path to the gateway on the Information property page. The default paths are drive paths that are relative to the GroupWise client, but for migration you must use a Server name/Volume format and not a drive letter.

13. In Addressing Format, click Component.

14. Click Gateway Time Settings.

15. In Idle Sleep Duration, select a value of 5 seconds or less (1 second is preferred). This setting reduces the time taken by free or busy queries and directory synchronization. Click OK.

Start the API Gateway

When you create the API gateway, the API.ncf batch file is installed on the NetWare server.

To start the API gateway, run the batch file. Type API on the NetWare Server Console, and then press Enter. The API gateway should be visible as its own screen on the NetWare server.

After the gateway starts, NetWare checks the API_IN directory for messages according to what is configured in the Idle Sleep Duration option of the gateway.

Create an External Foreign Domain

The Fabrikam migration team created an external domain in its GroupWise organization called Exchange. During the coexistence period, this domain contained objects from Exchange 2000, such as users who already migrated or new users on Exchange who were never part of the GroupWise system.

To create an external foreign domain for the Exchange organization and configure the link table

1. In NetWare Administrator, from the Tools menu, click GroupWise View, and then click the API gateway.

2. Right-click and select Create, and then click External Domain.

3. Type an external domain name that matches the default recipient policy name in Exchange and repeat for other policies if necessary. The name is the first part of the GroupWise (GWISE) proxy address on each Exchange organization. You can edit the name on the E-Mail Addressing tab of Recipient Policies. Fabrikam used the default name, which is Exchange.

4. In Domain Type, click External Foreign.

5. In Database Version, select 4.x (to match the API gateway).

6. Be sure that Time Zone is set to the same time zone used by the Exchange server that runs the GroupWise connector.

7. Click Create.

8. In NetWare Administrator, select the GroupWise domain that is performing directory synchronization with Exchange. This domain contains the API gateway.

9. On the Tools menu, click GroupWise Utilities, and then click Link Configuration.

10. In Link Configuration Tool, click the newly created external domain.

11. On the Edit menu, click Link.

12. In Link Type, select Gateway.

13. In Gateway Link, select the API gateway that connects to Exchange, and then click OK.

Creating and Configuring Migration Accounts

In Novell Directory Services (NDS), Fabrikam administrators created an account in each GroupWise post office called <PostOfficeName>2Ex, where <PostOfficeName> was the name of the GroupWise post office in that domain. The migration team logged on with this account to perform the nightly migrations.

Important: The migration account must be in the same GroupWise post office as the accounts that are being migrated. Because Fabrikam had multiple domains and post offices, the migration team created a migration account in each GroupWise post office.

After the migration team created the migration account, an administrator logged on to GroupWise at each Fabrikam office location and granted the migration account full access to the GroupWise domain and the post office in that domain. In each GroupWise domain, administrators also granted the migration account read and write permissions on the files in the post office and proxy permissions on the mailboxes.

Create an NTGateway Group in NetWare

In the NetWare Administrator program, the Fabrikam team created a group called NTGateway, whose membership had read and write permissions to the API gateway directories. The router service component of the GroupWise connector uses these NTGateway permissions to access API gateway directories.

To create the NTGateway group

1. In NetWare Administrator, on the Tools menu, click NDS Browser. Select a tree and a context.

2. In NDS Browser, right-click the tree.

3. Click Create, and then click Group.

4. Type NTGateway, and then click Create.

5. In NetWare Administrator, double-click the NTGateway group. On the Members tab, click Add.

6. Add an administrator with administrative rights to the Novell NetWare server that is hosting GroupWise. The account used here must be the same account used on the Exchange side to specify the connection to GroupWise.

After the migration team created the NTGateway group, the team performed the following tasks:

• Added all migration accounts to the NTGateway group.

• Gave the NTGateway group full rights to the API gateway directory.

• Gave the NTGateway group full rights to the post office directory for each post office.

Setting the GroupWise Access Mode to Direct Access

Access Mode in GroupWise determines how the client program connects to a post office. Access from client to post office can be direct or through the Post Office Agent (POA) (the Client/Server setting). For the purposes of migrating to Exchange, set the Access Mode option on every post office to Client/Server and Direct to allow either method. Direct access mode speeds up the time it takes Exchange Migration Wizard to access users' mailboxes and extract data.

Fabrikam administrators used the Netware Administrator tool in their GroupWise organization to open POA object properties on each GroupWise server. Figure 3.5 shows the property page in which administrators changed the Access Mode from Client/Server Only to Client/Server and Direct.

Note: For more information about access modes, POAs, and setting GroupWise post office properties, see your GroupWise documentation.

Figure 3.5: Change the Access Mode setting to Client/Server and Direct

After administrators applied this setting on each Fabrikam POA, the POAs were synchronized. Then administrators unloaded and reloaded each POA to make sure the changes took effect. They also checked the POA log files to verify that the access mode was changed. If log files indicated that access mode was not changed, the migration team would need to rebuild the GroupWise database.

Configuring the GroupWise System: Best Practices

Microsoft Consulting Services recommends the following best practices to ensure a successful migration.

Reduce the Amount of Data to Migrate

Reducing data simplifies migration and allows administrators to complete migration in a much shorter time frame. For this reason, administrators asked all Fabrikam employees to perform the following tasks:

• Delete unwanted or old e-mail.

• Delete old calendar data.

• Delete mail in the Deleted Items and Sent Items folders, as these messages are also migrated by default by Migration Wizard.

In addition to specifying which GroupWise accounts to migrate, Exchange Migration Wizard allows you to specify how many days' worth of e-mail to migrate. This is why you should know the amount of each users' mail you plan to migrate each evening. At Fabrikam, administrators and management decided to migrate only the past 30 days of e-mail.

Important: As you plan your migration, you must remember to include mail expansion in your migration calculations. For more information about mail expansion, see "Migration Considerations" in Chapter 2.

Set the Visibility of Objects

Only GroupWise objects with a visibility of system are migrated. Make sure all accounts and data have visibility set to system before migration. For information about configuring visibility, see your GroupWise documentation.

After the migration team migrated an account, the team changed the visibility of the account to None. Changing the visibility hides the migrated GroupWise account from the remaining GroupWise users.

Setting Up the GroupWise Connector

Fabrikam made some configurations changes to its Active Directory to prepare for coexistence with GroupWise. After making these changes, the migration team installed and configured the GroupWise connector. This section describes how the migration team performed these steps.

Coexistence Components

In an Exchange and GroupWise coexistence, the major Exchange component is an Exchange 2000 bridgehead server installed with the following:

• GroupWise connector

• Exchange 2000 Calendar Connector

• Gateway and Client Services for NetWare

The major GroupWise coexistence component is the GroupWise API gateway and the NTGateway group in NDS. For more information about the NTGateway group, see the "Create an NTGateway Group in NetWare" section earlier in this chapter.

In addition, you must have one migration account that appears in both Exchange and GroupWise, preferably with the same password in each directory.

Windows 2000 Coexistence Preparation

Use the procedures in the following sections to prepare Windows 2000 for the Exchange 2000 and GroupWise coexistence.

Install Gateway and Client Services for NetWare

On the Exchange bridgehead server with the GroupWise connector (at Fabrikam, this server was named MSGBRDGRI-01P), install Gateway and Client Services for NetWare. During coexistence, Windows resources need access to NDS resources, which Gateway and Client Services provides. Windows resources have the same permissions granted to the NTGateway group.

Note: As an alternative, you can install a Novell client on your Exchange bridgehead server. Fabrikam, however, had problems getting the Novell client to work on the computer running Exchange in the test environment, so the migration team used Gateway and Client Services instead.

When you install Gateway and Client Services, Windows adds the NWLink protocol to the network protocol stack. Therefore, you need to enable IPX between the Exchange bridgehead server and the Novell API gateway server. Microsoft Consulting Services noticed that some companies had disabled IPX routing on their network. If this is the case in your organization, you must re-enable IPX because, as of January 2002, Gateway and Client Services supports only IPX.

To install Gateway and Client Services for Netware

1. On the Exchange bridgehead server's desktop, right-click My Network Places, and then click Properties.

2. Right-click Local Area Connection, and then click Properties.

3. Click Install.

4. Select Client, and then click Add.

5. In Select Network Client, select Gateway (and Client) Services for NetWare, and then click OK.

6. When prompted, restart the computer. Perform the "To configure Gateway and Client Services for NetWare" procedure immediately after you restart your computer.

To configure Gateway and Client Services for NetWare

After the computer restarts, log on with a migration account. For more information about migration accounts, see the "Creating and Configuring Migration Accounts" section earlier in this chapter.

1. At the Select NetWare Logon screen, when asked to enter a Default Tree and Context, click Cancel.

2. A dialog box will ask you if you want to continue. If you click Yes, you can select a preferred server later in Control Panel. Click Yes.

3. Click Start, point to Settings, and then click Control Panel.

4. In Control Panel, double-click GSNW.

5. In Gateway Service for NetWare, select Default Tree and Context if it is not already selected.

6. In Tree, type the name of the NDS tree (this tree is roughly the equivalent of a forest in Active Directory). At Fabrikam, the NDS tree was called Fabrikamworldwide.

7. In Context, type the path to the GroupWise organization. At Fabrikam, this path was groupwise.Richmond.fabrikamworldwide.

8. Click Gateway.

9. In Configure Gateway, in Gateway Account, enter the migration account for the GroupWise domain that hosts the API gateway. Then enter the password. Click OK.

Configuring the GroupWise Connector

After the migration team completed these two Windows 2000 procedures, the team was ready to configure the GroupWise connector installed on one of the Richmond bridgehead servers (MSGBRDGRI-01P).

Note: For more conceptual information about how the GroupWise connector works and procedure information about configuring the connector, see your Exchange 2000 online documentation.

To configure the GroupWise connector

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Routing Groups, expand RI RG (the Richmond routing group), expand Connectors, right-click Connector for Novell GroupWise (MSGBRDGRI-01P), and then click Properties.

3. On the General tab, in API Gateway Path, enter the same UNC path entered in Step 12 of the "To configure the API gateway" procedure earlier in this chapter. At Fabrikam, the UNC was \\fisk\mail\gwdomain\wpgate\api41.

4. Set the NetWare account by typing the migration account name (the account common to both messaging systems created for the purpose of coexistence). Enter the entire path beginning with a period, such as .gwise2ex.groupwise.Richmond.fabrikamworldwide. Microsoft Consulting Services recommends using the period (.) before the account name to prevent errors during migration.

5. Under Message size, leave the default No limit.

6. Under Delivery Order, leave the default Priority.

   Important: For additional information about other setting options and how to determine which settings are best for your organization, see your Exchange 2000 online documentation.

7. On the Address Space tab, click Add, select GWISE, and then click OK. In Novell GroupWise Address Space Properties, in Address, type an asterisk (*). Leave the default cost of 1. Click OK. On the Address Space tab, leave Connector scope at the default Entire organization.

8. If you have not already created the GroupWise Users organizational unit in Active Directory, create the organizational unit now.

9. On the Import Container tab, in Container, select GroupWise Users. Leave the default option Create a Windows contact. This option allows GroupWise users to receive mail from Exchange at their GroupWise mailboxes, but does not allow them to access Windows 2000 resources. Under Filtering leave the default selection Import all directory entries.

   Note: The filtering option allows you to specify what GroupWise directory entries, such as domains, post offices, or individual recipients, you want to include or exclude from the import container. For more information filters and how to create and configure them, see your Exchange online documentation.

10. On the Export Containers tab, add all Active Directory organizational units that contain objects that you want exported to GroupWise through the connector when directory synchronization occurs. At Fabrikam, these organizational units were created for each office location (Richmond, Alexandria, Braintree, and so on). Leave the default Export groups selected.

11. On the Dirsync Schedule tab, set Exchange-GroupWise directory update schedule to run every 15 minutes.

Note: The greater the number of changes that need to be propagated between systems, the longer the directory synchronization cycle. Also, because directory updates are sent over the same connection used for messages, directory synchronization affects message throughput. When you choose a directory synchronization schedule, weigh the benefits of frequent updates against the impact that the cycle will have on system performance.

Fabrikam made no settings on the Delivery Restrictions tab.

Important: If you have not updated the default recipient policy, you must update it now in your Exchange system to include GroupWise (GWISE) addresses. For more information, see the "Fabrikam's Policy Design" section in Chapter 2. When you have GroupWise addresses in the default recipient policy, your Exchange users can receive mail from GroupWise users during coexistence.

Starting the Connector Services

After configuring the connector, verify that the two GroupWise connector services started.

To verify that services started

1. On the Start menu, point to Programs, point to Administrative Tools, and then click Services.

2. In the details pane, right-click Microsoft Exchange Connector for Novell GroupWise, and then click Start. Set the Startup Type to Automatic.

3. In the details pane, right-click Microsoft Exchange Router for Novell GroupWise, and then click Start. Set the Startup Type to Automatic.

Setting Up Exchange 2000 Calendar Connector

After the migration team installed the GroupWise connector, the team installed and configured Calendar Connector. Calendar Connector allows GroupWise and Exchange users to schedule meetings and share calendar information without having to worry about which messaging system the recipient is on.

Note: For conceptual information about how calendar connector works and procedural information about configuring calendar connector, see your Exchange online documentation.

Installing Calendar Connector

Calendar Connector is available in Exchange 2000 SP1 and later.

To install Calendar Connector

Note: To perform this installation you must be a member of the Domain Administrator group in the local domain, as well as a member of Enterprise Administrator and Schema Administrator. You must have these permissions because Calendar Connector makes changes to the Active Directory schema.

1. On the computer running Windows 2000 Server on which Exchange 2000 is installed, insert the Exchange SP1 compact disc into the CD-ROM drive.

2. Open Windows Explorer, click the CD-ROM drive, and then open the calcon directory.

3. In calcon, open the i386 directory.

4. To install Calendar Connector, double-click setup.exe, and then complete the installation wizard.

Recipient Policies and Calendar Connector

Calendar connector uses the System Attendant service to query GroupWise for GroupWise users' free and busy information. Any request from an Exchange user for GroupWise free and busy information is communicated by the System Attendant.

For free and busy information to be properly replicated between messaging systems, Exchange 2000 System Attendant must have a GroupWise e-mail address (GWISE). Therefore, System Attendant must be assigned a GWISE address.

At Fabrikam, during the testing phase, the migration team discovered the default recipient policy included only Exchange mailboxes and the policy did not create GWISE addresses. When the migration team installed Exchange in the production environment, the team modified the default recipient policy to create GWISE addresses.

Replicating Free and Busy Folder to Other Servers

Free and busy information for each administrative group (Fabrikam has only one administrative group) must replicate to the server on which Calendar Connector was installed. Free and busy information for all users in an administrative group is kept in the Schedule+ Free Busy Information folder located in the public folder store of the first Exchange server in that administrative group. By default, free and busy information is stored only on the first Exchange server in the organization. If you do not install Calendar Connector on the first Exchange server in the administrative group, you must replicate the Schedule+ Free Busy Information public folder to the Exchange server on which Calendar Connector is running.

At Fabrikam, the migration team installed Calendar Connector on BRDGMSGRI-01P, but MSGRI-01P was the first Exchange server installed and, therefore, the first server in First Administrative Group. Therefore, administrators performed the following procedure so that Exchange users' free and busy information would replicate to Calendar Connector. Fabrikam decided to replicate the Schedule+ Free Busy Information public folder to at least one server in each routing group.

To replicate free and busy information

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Click to expand Administrative Groups, expand First Administrative Group, expand Servers, expand MSGRI-01P, expand First Storage Group, expand Public Folder Store (MSGRI-01P), and then click Public Folders.

3. In the details pane, right-click Schedule+ Free Busy Information – First Administrative Group, and then click Properties.

4. On the Replication tab, click Add.

5. In Select a Public Store, select the public folder stores on all other Exchange servers, and then click OK.

6. On the Replication tab, change Public folder replication interval to Always run.

7. Change Replication message priority to Urgent.

Design Consideration

Because the migration team replicated the free and busy public folder across the Fabrikam organization to all routing groups, users outside of the Richmond routing group did not have to go over a routing group connector to obtain free and busy information. The disadvantage of this approach is that users outside of Richmond were dependant on public folder replication, which has a minimum latency of 15 minutes. However, as discussed in Chapter 2, the migration team reasoned that most users scheduled meetings with people in their own office location (which is also their own routing group), so the effect of organization-wide public folder updates would be minimal to Fabrikam.

Configuring Calendar Connector

The following procedure describes how Fabrikam configured its Calendar Connector. For complete information about configuration options for Calendar Connector, see your Exchange 2000 SP1 online documentation.

To configure Calendar Connector

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Click to expand Routing Groups, expand RI RGC (the Richmond routing group), expand Connectors, right-click Calendar Connector (BRDGMSGRI-01P), and then click Properties.

3. On the General tab, click Modify, and in Select Exchange Notes or Groupwise Connector, select Connector for Novell GroupWise (BRDGMSGRI-01P), and then click OK.

4. On the General tab, type the number of days you want GroupWise to return free and busy information. The maximum is 389 days. If you type a number larger than 389, GroupWise will not return any information. The more data that is requested (the larger the number of days' worth of data you enter), the longer it takes for the free and busy information to come across Calendar Connector.

5. On the General tab, enter the maximum age in minutes of GroupWise data that Exchange can use before querying the GroupWise system for more data. If you set this value to 0, every free and busy request from an Exchange user will result in a query to GroupWise.

6. On the General tab, enter the maximum number of seconds you want Exchange to wait for a response from GroupWise.

7. On the Calendar Connections tab, click New. In Calendar Type, select Novell Groupwise, and then click OK.

8. In GroupWise Calendar Connection, under GroupWise API Gateway, type the Novel API gateway (in this case, fabrikamworldwide_Richmond.api). Click OK.

9. On the Schedule tab, enter how often you want Exchange to check the GroupWise directory for new users to create free and busy records for those users in the Exchange free and busy folder. The default is Never. Always queries GroupWise for new users on the hour and every fifteen minutes thereafter. Selected times allows you to customize the times Exchange queries GroupWise for new users.

Note: The times and frequency entered on the Schedule tab do not determine when information is synchronized. This tab determines the frequency when Exchange makes sure there is a free and busy record created for each GroupWise user in the Exchange free and busy folder. The free and busy record for an external user is created when an Exchange user makes a query for that particular user. If a free and busy record is not created for a GroupWise user and an Exchange user looks for that GroupWise user's free and busy information, no information is returned.

Configuring the Migration Servers

During the migration process, migration servers extract e-mail data from GroupWise and transfer it to Exchange. This section describes how Fabrikam configured its migration servers.

Note: Migration servers can be desktop computers. You do not need the most powerful hardware available for your migration servers. Microsoft Consulting Services recommends that you scale out migration servers (increase the number of migration servers) rather than scale up (use a smaller number of computers with powerful hardware).

Client and Server Software Versions

At the time of the Fabrikam migration, the migration team tested a number of different software versions for the purpose of migration and found the following combination worked best. However, new tools may become available that work better.

• GroupWise client to be installed on migration server: GroupWise 5.2.5 This client recommendation is only for the migration server. GroupWise users can run the latest GroupWise client.

• Novell client to be installed on migration server: Novell NetWare 4.8 This client recommendation is only for the migration server. Users can run the latest Novell client.

• GroupWise server: GroupWise 5.5.3 server This server is the version Fabrikam was runnning at the time of migration, and it is the verison the migration team used to develop and test its procedures.

Software Installed on Migration Servers

The Fabrikam migration team installed the following programs on Fabrikam's migration servers.

• Windows 2000 Server (or Advanced Server)

  Note: Although you can use Windows 2000 Professional, Microsoft Consulting Service found that Migration Wizard runs faster and more reliably on Windows 2000 Server or Advanced Server and, therefore, does not recommend using Windows 2000 Professional on the migration server.

• Windows 2000 Service Pack 2

• GroupWise client version 5.2.5

• Novell client version 4.8

• Exchange System Manager

Setting Up the Migration Server

Fabrikam used the following procedure to configure its four migration servers in Richmond, the first Fabrikam office to be migrated. After the migration team migrated all Richmond employees, the team sent one migration server to each of the other office locations. By sending a migration server to each office, all migrations could occur locally and not depend upon WAN links that would greatly increase the process time.

Your Exchange organization must be installed and running before you can configure your migration servers.

To set up a migration sever

1. Install Windows 2000 Server or Advanced Server.

2. Make sure video drivers (provided by the hardware vendor), NNTP, SMTP, Terminal Services, and basic TCP/IP services are installed with the operating system.

3. Join the computer to the corp.fabrikam.com domain.

4. Install Windows 2000 SP2.

5. Install GroupWise client 5.2.5.

6. Install Novell client 4.8.

7. Insert the Exchange 2000 Enterprise CD into the CD-ROM drive and run Setup. On the Component Selection page, on the Action menu drop-down list next to Microsoft Exchange 2000 Server, select Custom.

8. On the Action menu drop-down list next to Microsoft Exchange System Management Tools, select Install. Leave all other component actions blank. This selection installs System Manager only.

With System Manager, a GroupWise client, and a Novell client installed, each migration server can communicate with the GroupWise and NDS system and with the Exchange 2000 and Active Directory system.

Important: The migration server must have a Windows Messaging profile installed. In Control Panel, double click Mail to verify if the profile exists. If no profile exists, create it. One way you can create the profile is by installing Outlook.

This profile could have Exchange services listed. If so, remove the Exchange services. If you do not remove the services, you will be prompted for Exchange logon credentials once for every user you migrate. To avoid this logon request, make sure the only services listed in the migration server's mail profile are Novell GroupWise Message Store, Novell GroupWise Address book, and Novell Personal Address Book.

Nightly Migration Process

Each night after normal working hours, the Fabrikam migration team migrated 30 to 40 users. Because Fabrikam has over 1,000 employees, the GroupWise Connector and Calendar Connector were instrumental in allowing employees to continue collaborating regardless of which system they were on at any given time.

Exchange Migration Wizard ran on four migration servers. Migration Wizard communicated with both messaging systems because, as discussed in the "Configuring the Migration Servers" section earlier in this chapter, the migration team installed a Novell client, a GroupWise client, and System Manager the migration server.

The migration team created a migration account for every GroupWise post office on the NDS and GroupWise system. GroupWise users gave their post office's migration account proxy access to their e-mail so that the migration account could read the user's e-mail and extract it. In Active Directory, you need only one migration account: the account administrators use to run Migration Wizard.

Migration Wizard extracted the mail data, converted it, and inserted the data into the Exchange system. During the insertion, Migration Wizard checked to see if an account existed in Active Directory that corresponded to the mail data. Fabrikam administrators could do either a two-step migration (where they specified the accounts to receive the mail data) or a one-step migration (where Migration Wizard is configured to create Active Directory accounts and load the data into these accounts). For more information about single-step and two-step migrations, see "Microsoft Exchange Migration Wizard" later in this chapter.

Before you migrate any users, Microsoft Consulting Services recommends you review the migration-related Microsoft Knowledge Base articles listed in Appendix D.

Lessons Learned

The following list itemizes many valuable lessons learned by MCS in the testing and pilot migration environments at Fabrikam. To avoid the issues listed here, review this list before you begin your actual migration. After each issue, the section that discusses the issue is referenced.

• When the migration team tested the GroupWise 5.5.3 client, Migration Wizard generated a Dr.Watson error. When the team tested the GroupWise 5.2.5 client, it worked. However, on the server, GroupWise 5.5 introduced database changes that are not available to the Groupwise 5.2.5 client. Because of these database changes, for migration purposes, installing the GroupWise 5.2.5 client on the migration servers was sufficient. For more information, see "Configuring the Migration Servers" earlier in this chapter.

• Migration Wizard asks for the GroupWise domain, user account, and password. The password that Migration Wizard wants is the migration account's GroupWise password, not NDS password. By default, the GroupWise password is blank, so you must set the GroupWise password to the same one you use in Migration Wizard. The GroupWise password and the NDS password are not linked to each other. It is recommended that you set the migration account's GroupWise password the same as its NDS password. For more information, see "Microsoft Exchange Migration Wizard" later in this chapter.

• The migration account must be in the same GroupWise post office as the accounts that you plan to migrate. At Fabrikam, each office location was its own GroupWise domain and post office. Some offices had multiple post offices within a single GroupWise domain. Therefore, multiple migration accounts had to created, one for every post office. For more information, see "Creating and Configuring Migration Accounts" earlier in this chapter.

• To migrate accounts, Migration Wizard must point to the GroupWise domain that contains the post offices with the users who need to migrate. Even if Migration Wizard points to the primary GroupWise domain, Migration Wizard cannot see the post offices in secondary GroupWise domains. For more information, see "Microsoft Exchange Migration Wizard" later in this chapter.

• When migrating mail data from Groupwise to Exchange 2000, you can migrate the data from a GroupWise mailbox into any Active Directory account. For more information, see "Microsoft Exchange Migration Wizard" later in this chapter.

• Exchange Migration Wizard is much faster when GroupWise is in direct access mode rather than client/server mode. Direct access mode requires configuration on both the client and server sides. For more information, see "Setting the GroupWise Access Mode to Direct Access" earlier in this chapter.

• If the GroupWise user has a nickname, you must remove it. Migration Wizard incorrectly grabs the nickname field instead of the user's alias. For more information, see "Microsoft Exchange Migration Wizard" later in this chapter.

• Microsoft Consulting Services found the Migration Wizard works much better with the Groupwise 5.2.5 client than with the GroupWise 5.5.1, GroupWise 5.5.2, or GroupWise 5.5.3 clients. For more information, see "Client and Server Software Versions" earlier in this chapter.

• Microsoft Consulting Services found that running Migration Wizard on a computer running Windows 2000 Server was much faster than running Migration Wizard on a computer running Windows 2000 Professional. For more information, see "Software Installed on Migration Servers" earlier in this chapter.

• During the testing phase, Fabrikam administrators discovered that, even though the migration account was granted Minimum User Access rights on every GroupWise account, some accounts were still unable to migrate. To simplify the migration, administrators decided to explicitly grant the migration account all proxy rights to the user's account. For more information, see "Creating and Configuring Migration Accounts" earlier in this chapter.

• During coexistence, the Gateway Service for NetWare tool (which is used by the GroupWise connector) runs only over IPX. If your organization has disabled IPX routing, you must enable it beween the Exchange bridgehead server running Gateway Service for NetWare and the GroupWise API gateway server. For more information about Gateway Service for NetWare and IPX, see the following Microsoft Knowledge Base articles:

  • 222059, "Windows 2000 GSNW and CSNW Do Not Support NetWare 5 IP," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=222059.

  • 235225, "GSNW and CSNW Do Not Support the IPX/SPX Protocol," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=235225.

Migration Preparation Review

This section provides an overview of all the steps Fabrikam took to prepare for its migration. Use this list to help you ensure you have adequately prepared your own organization for migration.

Note: The following items summarize the actions Fabrikam's migration team took as soon as the team successfully implemented Exchange 2000 in its production environment and established coexistence between Exchange and GroupWise. The Exchange installation includes all routing group connectors, the SMTP connector, Outlook Web Access, the GroupWise connector, and Exchange 2000 Calendar Connector.

After the migration team successfully implemented Active Directory and Exchange, the team:

• Created disabled user accounts in Active Directory for each GroupWise user who was to be migrated.

• Populated user accounts with relevant information (name, phone number, and so on).

• Created security and distribution groups in Active Directory (groups were not mail-enabled at this time).

• Created an organizational unit in Active Directory called GroupWise Users.

• Assigned appropriate permissions to the migration account in Active Directory (the account that administrators use to log on to the migration servers).

• Assigned appropriate NDS and GroupWise permissions to migration accounts on the GroupWise system (there were multiple accounts on the GroupWise system because one migration account was created for each GroupWise post office).

• Ran directory synchronization between GroupWise and Active Directory to create contact objects in Active Directory for GroupWise users and to create foreign objects in the GroupWise external foreign domain ("Exchange") for mail-enabled users in Active Directory.

• Set up the migration servers.

• Created a Microsoft Excel worksheet to use as a migration tracking database and included all Fabrikam employees and external entities (such as group calendars and shared mailboxes) to be migrated.

• Determined which GroupWise distribution lists to migrate and added them to the tracking database.

Four weeks before migration, the migration team:

• Identified the post offices from which users will migrate.

• Developed a user migration schedule and, whenever possible, scheduled users in the same work group to migrate together.

• Scheduled Outlook and Windows 2000 Professional training for users.

• Identified distribution lists to which users belonged, scheduled a separate migration for distribution lists, and added this migration to the tracking database.

• Identified external entities and scheduled external entities to migrate at the same time as the group that uses them (for example, migrate the legal group's calendar on the same night as the legal group).

• Identified the Exchange databases into which each user's mailbox will be located and added this informaiton to the tracking database.

• Identified any users who have nicknames on GroupWise and recorded the nicknames in the tracking database.

Two weeks before migration, the migration team:

• Gave users instructions on how to save their current configuration information, such as rules, and instructed users to clean up their GroupWise mailboxes.

• Trained users on Outlook and Windows 2000 Professional.

• Identified users with personal digital assistants (PDAs) and added this information to the tracking database.

• Identified users who were approved by management to have their GroupWise local archives migrated and added these users to the tracking database.

• Instructed users to identify any Novell Personal Address Books that they want to migrate. Instructed users to export their personal address books to .nab files, name each .nab file after the address book name, and save the files on the file server.

• Use the GWCheck utility (Gwchk32.exe), available from Novell, to run a structure and contents check on each account to be migrated. A successful check will return the results "No problems found."

The day before migration, the migration team:

• Converted the mail from approved users' mail archives back to standard mail data, and put this data on the users' GroupWise server.

Checklist: Day of Migration

Fabrikam administrators used the checklist in Table 3.6 on the evening a particular GroupWise post office was scheduled for migration. Use this checklist as a guideline to be sure your own organization is ready for migration.

Note: Some of these steps require configurations in your GroupWise system. For more information about how to perform these procedures, see your GroupWise documentation.

Table 3.6 Day of migration checklist

Step	Action	ü
1	Identify users to be migrated tonight.
2	Give the GroupWise post office's migration account proxy access to each GroupWise user account. Give the migration account read and write permissions for every option available.
3	In GroupWise, clear any nicknames on migrating users.
4	In Active Directory Users and Computers, right-click the Windows 2000 accounts for all users being migrated tonight and select Enable Account. After the accounts are enabled, right-click each account again and select Exchange Tasks. Use Exchange Task Wizard to mail-enable the Windows 2000 accounts. Place the accounts in the appropriate Exchange 2000 database.
5	Change the password on each GroupWise account so that the migration team can access the account.
6	Change the mailbox visibility of each migrating user's mailbox to System.
7	Log on to each user's GroupWise account and configure it to give the GroupWise migration account full proxy rights.
8	Create a forwarding rule in each migrating user's GroupWise mailbox so that any new mail is forwarded to the user's new Exchange mailbox. Also, have the rule delete the GroupWise copy of the message. Note: After you create this forwarding rule, the users will no longer receive mail on the GroupWise system, so make sure the users are ready to migrate.
9	Disable any remaining rules in the user's GroupWise mailbox, and disable any message receipts or message tracking that the user set up in his or her GroupWise mailbox.
10	On a migration server, run Microsoft Exchange Migration Wizard. When prompted, be sure to migrate the user into the correct Exchange 2000 mailbox store. For information about how to run Migration Wizard, see the "Microsoft Exchange Migration Wizard" section later in this chapter.
11	After you migrate users, check to see if any distribution lists are scheduled to be migrated tonight. If so, in GroupWise, change the visibility of the corresponding GroupWise public group to Hidden, and then mail-enable the security group in Active Directory, the same way you main-enabled users in Step 4.

Note: After you migrate user accounts, follow the same procedure for any external entities that may be scheduled for migration that evening. Migrating external entities includes running Migration Wizard, and then starting Outlook and performing the steps in the desktop and client migration tasks checklist (see Table 3.7), just as you would for users.

Microsoft Exchange Migration Wizard

The GroupWise to Exchange migration can be either a single-step or two-step process, and the primary migration tool, Exchange Migration Wizard, can be configured to perform either type of migration. In a two-step migration, the migration servers:

1. Read the GroupWise mail database, extract the data, and convert it to an Exchange format (.pst files).

2. Import this converted data into Exchange to locations pre-assigned by administrators.

In a single-step migration, the migration servers do both these steps without user intervention.

At Fabrikam, the migration team used the one-step approach. However, some accounts that had no errors during mail export produced errors during mail import. In these cases, the migration team reset the user's mailbox, used the temporary files created during the export process, and ran Migration Wizard in two-step mode. When administrators ran the wizard a second time, they ran only the import portion and the migration usually finished without additional errors.

Because the migration team used four migration servers, the team could migrate about 30 accounts per night. With each migration server migrating 6 to 8 users, the nightly migration process took 1 to 2 hours to complete, depending on the volume of data.

Important: If any problems occur during the migration, remove the problem account from the migration list and run Migration Wizard with the remaining accounts. Then run GWCheck.exe on the problem account while the remaining accounts migrate.

To run the Microsoft Exchange Migration Wizard

1. Log on to a migration server with the Active Directory migration account.

2. Start Migration Wizard. On the Start menu, point to Programs, point to Microsoft Exchange, and then click Migration Wizard.

3. On the Welcome page, click Next.

4. On the Migration page, select Migrate from Novell GroupWise 5.x. Click Next.

5. Click Next again.

6. On the Migration Procedure page, you can select One step migration (recommended) or Extract migration files only, which is the first step in a two-step migration. A one-step migration is simplest and is recommended. However, if you find you receive errors during migration, a two-step migration separates the process and allows you to troubleshoot the problem file. This procedure continues based on a one-step migration. Whichever option you select, on the Migration Procedure page, you must also specify a directory to store the extracted GroupWise mail data.

7. On the Migration Destination page, click Migrate to a computer running Exchange Server, and then select the Exchange server and the correct database (Mailbox Store is selected by default) to receive the GroupWise data. On this page, you can also decide to extract the GroupWise information to .pst files at a later time, which effectively turns a one-step migration into a two-step migration.

   Note: If the migration account is not a member of Domain Administrator for the local domain, you will not see any servers to choose from on this page.

8. On the GroupWise Domain page, in Path, type the path to the GroupWise domain database. This path is to the GroupWise domain that contains the post office with the users you want to migrate. You can enter the path as a UNC path or it can be a mapped drive path. In Account name, enter the name of the migration account. In Password, enter the migration account's GroupWise password (not the NDS password, unless you have configured these passwords to be the same).

   Important: Microsoft Consulting Services discovered over the course of several migrations at customer sites that when the GroupWise system has multiple domains and post offices, as Fabrikam did, the path you enter on this page must be the domain that contains the post offices you want to migrate. Entering a path to the GroupWise primary domain does not guarantee that all post offices will be displayed by Migration Wizard on the next page.

9. On the GroupWise Post Office page, select the post office that contains the accounts you want to migrate. As noted in Step 8, Migration Wizard lists only the post offices in the domain that you entered on the GroupWise Domain page.

10. On the Migration Information page, select the type and age of mail and calendar information you want to migrate.

11. On the Account Migration page, Migration Wizard displays a list of users from the post office you selected earlier. Select the users you want to migrate.

12. On the Container for New Windows Accounts page, select the migrated GroupWise users organizational unit that you created prior to running Migration Wizard. Migrated accounts will be placed in this organizational unit. Click Options to assign passwords for the newly created accounts.

13. On the Windows Account Creation and Association page, do one of the following:

    • Click to select one or more displayed accounts and choose whether you want Migration Wizard to create a new Windows account.

    • Click Find Existing Account to match an existing Active Directory account with the selected account.

    When done, click Next, and Migration Wizard begins extracting GroupWise mail, converting it, and inserting the converted GroupWise mail into Exchange.

14. If, on the Container for New Windows Accounts page, you clicked Options and chose to have a random password assigned to accounts created by Migration Wizard, the file containing those randomly assigned passwords is included in the application log file. When Migration Wizard finishes, check the application log file for these passwords.

Note: Log files will be in the folder you designated when you installed Exchange.

Check list: Desktop and Client Migration Tasks

When Migration Wizard finished extracting the GroupWise data, the Fabrikam migration team readied the workstations of migrating users. Table 3.7 lists the tasks performed on each newly migrated user's computer running Windows 2000 Professional.

Table 3.7 Desktop and client migration tasks checklist

Step	Action	ü
1	Install Outlook on each user's workstation. In addition, be sure to install the Import and Export tool. This step can be done while Migration Wizard runs.
2	Start Outlook. Import migrated calendar information from the .sc2 file in the user's Inbox by running Outlook Import and Export Wizard.
3	Verify that each user's mail and calendar information migrated. Verify that any folders created in GroupWise migrated.
4	If you your organization created a NAB customized conversion script, which is what Fabrikam did, convert Novell personal address books on the file server by running the script. On the workstation, create a contact folder in Outlook for each .nab file. Use Outlook Import and Export Wizard to import the converted .nab file into the appropriate Outlook contact folder. Without a conversion script, users must re-create their contacts in Outlook by hand.
5	Communicate to the user, in a sealed envelope, his or her new Active Directory password.

Check list: Post Migration Tasks

After Migration Wizard finished running and client migration tasks were completed, Fabrikam administrators performed the tasks listed in Table 3.8.

Table 3.8 Post-migration tasks checklist

Step	Action	ü
1	Manually synchronize GroupWise and Exchange by clicking Immediate Full Reload on the Dirsync Schedule tab of the GroupWise connector.
2	Verify that Step 1 synchronized newly migrated users to the GroupWise external domain.
3	In GroupWise, change the visibility setting of the accounts you just migrated to Hidden.
4	Reconfigure users' PDAs for synchronization with Outlook.
5	Notify users that they need to re-create proxies, rules, shared folders, and words added to their personal dictionaries.

For more information: https://www.microsoft.com/exchange/

Did this paper help you? Please give us your feedback. On a scale of 1 (poor) to 5 (excellent), how would you rate this paper?

exchdocs@microsoft.com

Appendix A Procedures

Use the procedures in this appendix to help you configure your Microsoft® Exchange 2000 organization. You can find most of these procedures in your Exchange 2000 online documentation; however, in some cases, the procedures were customized for Fabrikam.

The Fabrikam migration team used these procedures to set up its Exchange system; depending on your topology, you may need to change some configuration settings.

Administrative Groups and Routing Groups Visibility

By default, System Manager does not display routing groups or administrative groups. This section describes how to view one or both of these objects.

To view administrative groups and routing groups

1. Start System Manager. On the Start menu, click Programs, point to Microsoft Exchange, and then click System Manager.

2. Right-click the organization object [in this case, Fabrikam (Exchange)], and then click Properties.

3. On the General tab, under Administrative views, select the Display routing groups and Display administrative groups check boxes.

Exchange Administration Delegation Wizard

Exchange Administration Delegation Wizard is a tool that simplifies delegating permissions to Exchange administrators. When you start Exchange Administration Delegation Wizard, you are prompted to select users and groups for which you want to apply the administrative permissions. This tool is particularly useful immediately after you install Exchange, because the account that installed the first Exchange server (you designate this account during Forest Prep) can use Exchange Administration Delegation Wizard to grant administration permissions to all Exchange administrators in the organization.

To use Exchange Administration Delegation Wizard

1. Start Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Right-click the organization or administrative group for which you want to delegate administrative permissions, and then click Delegate control.

3. In Exchange Administration Delegation Wizard, click Next.

4. In Users or Groups, click Add to grant a new user or group administrative permissions.

5. In Delegate Control, click Browse, and then select a user or group from the list that appears. To display the list of users and groups from the Active Directory® directory service, or only the list for a particular domain, click Locations. You can also type the name or alias of the user or group under Enter the object name to select, and then click Check Names. You must type one name at a time.

6. After you have selected a user or group, in Delegate Control, in the Role list, select the one of the following types of administrative permissions for the group or user:

   • Exchange Full Administrator. This option can fully administer Exchange system information and modify permissions.

   • Exchange Administrator. This option can fully administer Exchange system information.

   • Exchange View Only Administrator. This option can view Exchange configuration information.

7. To change the role of an existing user or group, in Users and Groups, select the user or group, click Edit, and then select the new role.

8. To remove a user or group, in Users and Groups, select the user or group, and then click Remove.

9. To assign the permissions, click Next, and then click Finish.

Mailbox Size Limits

This section describes setting mailbox size limits. For procedures about setting mailbox recipient policies and configuring Mailbox Manager, see "Recipient Policies" later in this appendix.

To set mailbox size limits

1. Start System Manager. On the Start menu, click Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, expand the appropriate server, and then expand First Storage Group.

3. Right-click Mailbox Store (<server name>), and then click Properties.

4. Click the Limits tab. Select the Prohibit send and receive at (KB) check box, and then type 2500 in the corresponding text box. To warn users when they are approaching the organization's mailbox size limit, you can select the Issue warning at (KB) and Prohibit send at (KB) check boxes and type smaller numbers in the corresponding text boxes.

Mailbox Store Policies

Use the mailbox size limit procedure to impose size limits in a single mailbox store. Instead of performing this procedure multiple times on all of Fabrikam's mailbox stores, the migration team created a mailbox store policy and applied it to multiple mailbox stores in the organization. For more information about how to create a mailbox store policy, see "Create a Mailbox Store Policy" later in this appendix.

Message Size Limits

This section contains procedures for limiting the size of message that can be sent between users in your organization.

At Fabrikam, internal messages limits were configured using global settings in System Manager. Global settings apply to all SMTP virtual servers in an Exchange organization.

Note: Message size limits on a user's mailbox (set through the Active Directory Users and Computers snap-in) override SMTP virtual server settings, regardless of whether those settings are global across all virtual servers or unique to one particular virtual server.

Internal Message Size Limits

Setting internal message size limits determines the size limit for messages sent between users within an Exchange organization.

To configure internal message size limits

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Double-click Global Settings.

3. Right-click Message Delivery, and then click Properties.

4. On the Defaults tab, set the following options:

   • Under Sending message size, click Maximum (KB), and then type the maximum message size, in kilobytes, that can be sent by users. The default setting is No limit, which means users are allowed to send a message of any size.

   • Optionally, under Receiving message size, you can click Maximum (KB), and then type the maximum message size, in kilobytes, that can be received by users. The default setting is No limit, which means users are allowed to receive a message of any size.

Note: The SMTP virtual servers in your organization do not allow users to send or receive messages that exceed these limits (except for users who may have a different limit set on their individual mailboxes).

External Message Size Limits

The global settings described in the "Internal Message Size Limits" section apply to the SMTP virtual servers in the Exchange organization. Although each SMTP virtual server can be configured to relay all external messages through a designated smart host (by clicking Advanced on the Delivery tab), Fabrikam chose to channel all external (Internet-bound) e-mail through an SMTP connector on its bridgehead server (MSGBRDGRI-01P) in Richmond.

For more procedures about setting size limits on external messages, see "SMTP Connectors" later in this appendix.

Deleted Items Recovery

The following procedures describe how to set a deleted items recovery period, how to recover a deleted mailbox, and how users can recover deleted mailbox items from within Microsoft Outlook® 2000 or Outlook Web Access (in Exchange 2000 Server Service Pack 2 or later).

Deleted Items Recovery Period

A setting on the computer running Exchange determines the number of days administrators have to recover deleted mailboxes and the number of days users have to recover deleted mailbox items.

To set the deleted items recovery period for mailboxes and mailbox items

1. Start System Manager. On the Start menu, click Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, expand the appropriate server, and then expand First Storage Group.

3. Right-click Mailbox Store (<server name>), and then click Properties.

4. Click the Limits tab. Under Deletion settings, in the Keep deleted items for (days) and Keep deleted mailboxes for (days) boxes, type the number of days you want.

Repeat this procedure for every mailbox store in your organization.

Recover a Deleted Mailbox

The following procedure describes how to recover a mailbox after a user has been deleted from Active Directory, which makes the mailbox unowned. If the user is reinstated in Active Directory, or you want to give the mailbox to another user, use this procedure. To recover a mailbox that has been deleted from System Manager, you must use a backup tape.

To recover a mailbox after the mailbox owner is deleted from Active Directory

1. Start System Manager. On the Start menu, click Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, expand the appropriate server, expand First Storage Group, and then expand Mailbox Store (<server name>).

3. In the console tree, click Mailboxes.

4. In the details pane, right-click the mailbox you want, and then click Reconnect.

Recover Deleted Items

The following procedures describe how a user can recover a deleted item from their Deleted Items folder.

To recover deleted items in Outlook

1. From your Deleted Items folder, on the Tools menu, click Recover Deleted Items.

2. In the list, click the item or folder you want to retrieve, and then click Recover Selected Items.

To recover deleted items in Outlook Web Access

1. Click the Options icon on the Outlook Bar. Under Recover Deleted Items, click View Items. The Recover Deleted Items window opens.

   Note: Another way to open this window is to open your Deleted Items folder, and then click Recover Deleted Items on the toolbar.

2. In the Recover Deleted Items window, select the item you want to recover. To select multiple items, press the CTRL or SHIFT keys.

3. Click Recover to return the selected items to your Deleted Items folder.

Message Filtering

The message filtering feature of Exchange 2000 allows you to block predefined users or domains from sending e-mail to your users. Fabrikam used message filtering to block unsolicited commercial e-mail from its organization.

Setting up messaging filtering in your organization is a two-step process. First, you set message filtering in global settings, and then you enable message filtering on every IP address and TCP port combination ([All Unassigned] and 25 are the defaults) on every SMTP virtual server to which you want to apply the filter.

Set Message Filtering

This procedure describes how to create a message filtering list. Everyone included on this list, either individual users or entire domains, cannot send e-mail to your Exchange organization.

To set message filtering

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Global Settings.

3. Right-click Message Delivery, and then click Properties.

4. On the Filtering tab, click Add.

5. In Add Sender, type the name of the sender whose messages you want to filter, and then click OK.

   • To prevent a specific user in a specific domain from delivering messages to your site, type the user's alias and domain name in the following format: *username@*domain; for example, someone@microsoft.com.

   • To prevent all users in a specific domain, including all subdomains of that domain, from delivering messages to your site, type the domain name, including the at sign (@). For example, if you use the mask address @microsoft.com, the addresses someone@microsoft.com and someone@support.microsoft.com are both blocked.

   • To limit the domain blocking to a specific domain and exclude subdomains of that domain, precede the domain name with the number sign (#). For example, to block mail from all users at microsoft.com but allow mail from users in a subdomain of microsoft.com (for example, support.microsoft.com), use the mask #@microsoft.com. This setting blocks someone@microsoft.com, but allows someone@support.microsoft.com.

   Important: When entering names, you must use an SMTP address format (someone@microsoft.com) or type in a sender's display name in quotation marks.

6. Repeat Steps 4 and 5 for every sender you want to add to the message filter list.

7. Filtered messages are deleted unless you select the Archive filtered messages check box. Messages are kept in the <root>\Exchsrvr\Mailroot\<vsi #>\Filter directory, where <vsi #> is the SMTP virtual server.

Note: When the first message is filtered, the Filter directory is automatically created in the virtual server's directory.

Enable Message Filtering on a Virtual Server

After you create a message filter list, use the following procedure to apply the filter to each IP address/TCP port combination in every SMTP virtual server in your Exchange organization. This procedure allows for flexibility when applying your message filter to some or all users.

To apply message filtering

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, expand the appropriate server, expand Protocols, and then expand SMTP.

3. Right-click the appropriate SMTP virtual server, and then click Properties.

4. On the General tab, click Advanced.

5. In Advanced, select the IP address to which you want to apply the message filter, and then click Edit.

6. In Identification, select the Apply Filter check box, and then click OK. In Advanced, under Filter Enabled, Yes appears.

7. To disable filtering, clear the Apply Filter check box.

Distribution Lists

In Exchange 2000, distribution lists are mail-enabled groups. The following procedure describes how to restrict one or more users from sending mail to a particular group.

To restrict one or more users from sending messages to a distribution list

1. On the Start menu, point to Programs, point to Microsoft Exchange, and then click Active Directory Users and Computers.

2. In the console tree, click the organization unit that contains the mail-enabled group (Users by default).

3. In the details pane, right-click the group, and then click Properties.

4. Click the Exchange General tab.

5. Under Message restrictions, do one of the following:

   • Click From everyone to allow everyone in your organization to send e-mail to this group.

   • Click Add to create a list of users and groups. When you finish creating your list, select the Only from option to allow only the list you have created to send mail to this group.

   • Click Add to create a list of users and groups. When you finish creating your list, select the From everyone except option to exclude the list you created from sending e-mail to the group.

Replies to the Internet

The following procedure describes how to determine which automatic replies (such as "out of facility" [or OOF] messages) users can and cannot send outside your organization to the Internet.

To restrict replies to the Internet

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Global Settings.

3. Click Internet Message Formats.

4. In the details pane, right click Default, and then click Properties.

5. In Default Properties, click the Advanced tab.

6. Under Exchange rich-text format, click Determined by individual user settings. Do not click Always use unless you are certain your users only send messages to other Exchange organizations.

7. Depending on the needs and policies of your organization, select or clear the six check boxes at the bottom of the Advanced tab, which allow you to send or block certain types of messages.

System Policies

To enforce a common configuration across all office locations, the Fabrikam migration team established server policies, public store policies, and mailbox store policies. This section contains procedures for creating each of these system policy types, as well as for creating a system policy container.

Create a System Policy Container

Creating a system policy container is the first step in creating any system policy.

To create a system policy container

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups.

3. Right-click First Administrative Group, point to New, and then click System Policy Container.

Create a Server Policy

Server policies ensure configuration consistency in all Exchange servers.

To create a server policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative Group.

3. Right-click System Policies, point to New, and then click Server policy.

For complete information about server policy configuration options, see your Exchange 2000 online documentation.

The following section describes how Fabrikam configured its system policy; be aware that settings Fabrikam made may not be optimal for your organization.

How Fabrikam Configured Its Server Policy

Fabrikam administrators used the following procedure to configure their server policy.

1. Complete Steps 1 through 3 in the To create a server policy procedure.

2. In New Policy, select the General check box, and then click OK.

3. In Properties, on the General tab, type Fabrikam Exchange Server Policy as a name for the policy.

4. On the Details tab, use Administrative note to add additional information about the policy.

5. On the General (Policy) tab, set the following options:

   • Select the Enable subject logging and display check box to log all message subject fields.

   • Select the Enable message tracking check box to log all mail activity performed by all Exchange components.

   • Select the Remove log files check box to remove all log files older than the value set in the Remove files older than (days) box. Enter 7 for the number of days.

Adding Servers to the Server Policy

After the policy was created, administrators added all mailbox servers to the policy.

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and then expand System Policies.

3. Right-click Fabrikam Exchange Server Policy, and then click Add server.

4. In Select the items to place under the control of this policy, select all appropriate servers, click Add, and then click OK.

Create a Public Store Policy

With a public store policy, you can quickly apply general, database, replication, and message and folder limits properties to public folder stores.

To create a public store policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative Group.

3. Right-click System Policies, point to New, and then click Public store policy.

For complete information about public store policy configuration options, see your Exchange 2000 online documentation.

At the time of Fabrikam's migration, Fabrikam administrators concentrated on getting their Exchange organization running rather than configuring multiple public folder stores. Administrators planned to implement a complete public folder infrastructure at a later date, which is why the initial public store policy was a relatively simple policy. The following section describes how Fabrikam configured its public store policy; be aware that settings Fabrikam made may not be optimal for your organization.

How Fabrikam Configured Its Public Store Policy

Fabrikam administrators used the following procedure to configure their public store policy.

1. Complete Steps 1 through 3 of the To create a public store policy procedure.

2. In New Policy, select the Limits and Replication check boxes, and then click OK.

3. In Properties, on the General tab, type Fabrikam Exchange Public Folder Store Policy as a name for the policy.

4. On the Details tab, use Administrative note to add additional information about the policy.

5. On the Limits (Policy) tab, set the following options:

   • Select the Issue warning at (KB) check box to send a warning when the storage space used reaches the size you specify. In the corresponding text box, type 25000.

   • Select the Prohibit post at (KB) check box to prohibit messages over the size you specify from posting. In the corresponding text box, type 50000.

   • Select the Maximum item size (KB) check box to set a maximum limit for items in the policy. In the corresponding text box, type 5000.

   • In the Warning message interval list, leave the default warning message interval, Run daily at Midnight.

   • Under Deletion settings, in the Keep deleted items for (days) box, set the maximum number of days that items can remain in the store. Type 3.

   • Select the Do not permanently delete items until the store has been backed up check box to preserve items until the public store is backed up.

   • Select the Age limit for all folders in this store (days) check box, and then type 30 in the corresponding text box.

6. On the Replication (Policy) tab, click Restore Defaults.

Adding Public Folder Stores to the Public Folder Store Policy

After the policy was created, administrators added all public folder stores to the policy.

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and then expand System Policies.

3. Right-click Fabrikam Exchange Public Folder Store Policy, and then click Add Public Store.

4. In Select the items to place under the control of this policy, select all public folder stores, click Add, and then click OK.

Create a Mailbox Store Policy

With a mailbox store policy, you can quickly apply general, database, and message limit properties to mailbox stores.

To create a mailbox store policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative Group.

3. Right-click System Policies, point to New, and then click Mailbox store policy.

For complete information about mailbox policy configuration options, see your Exchange 2000 online documentation.

The following section describes how Fabrikam configured its mailbox store policy; be aware that settings Fabrikam made may not be optimal for your organization.

How Fabrikam Configured Its Mailbox Store Policy

Fabrikam administrators used the following procedure to configure their mailbox store policy.

1. Complete Steps 1 through 3 of the To create a mailbox store policy procedure.

2. In New Policy, select the Limits check box, and then click OK.

3. In Properties, on the General tab, type Fabrikam Exchange Mailbox Store Policy as a name for the policy.

4. On the Details tab, use Administrative note to add additional information about the policy.

5. On the Limits (Policy) tab, set the following options:

   • Select the Issue warning at (KB) check box to issue a warning when the storage space used reaches the size you specify. In the corresponding text box, type 100000, which is 100 MB.

   • Select the Prohibit send at (KB) check box to stop sending items when the storage space used reaches the size you specify. In the corresponding text box, type 125000, which is 125 MB.

   • Under Deletion settings, in the Keep deleted items for (days) box, set the maximum number of days to keep deleted items in the store. Type 7.

   • In the Keep deleted mailboxes for (days) box, set the maximum number of days to keep deleted mailboxes in the store. Type 30.

   • Select the Do not permanently delete mailboxes and items until the store has been backed up check box to preserve mailboxes and items until the mailbox store is backed up.

Adding Mailbox Stores to the Mailbox Store Policy

After the policy was created, administrators added all mailbox stores to the policy.

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and then expand System Policies.

3. Right-click Fabrikam Exchange Mailbox Store Policy, and then click Add Mailbox Store.

4. In Select the items to place under the control of this policy, select all mailbox stores, click Add, and then click OK.

Recipient Policies

E-mail address recipient policies generate e-mail addresses for users and contacts in your organization. Mailbox recipient policies use Mailbox Manager to enforce message size limits and age limits in one or more mailboxes in your organization.

For information about both kinds of recipient policies and their configuration options, see the Exchange 2000 online documentation.

How Fabrikam Created and Configured Its E-Mail Address Recipient Policies

For each e-mail address recipient policy you create, you can define the membership of the recipient policy and select the address types for policy members. The default recipient policy creates SMTP and X.400 e-mail addresses for all mail objects in Active Directory.

The Fabrikam migration team needed three e-mail recipient policies:

• A policy called Fabrikam Recipient Policy, which applied to Fabrikam employees with Exchange mailboxes (priority: 1)

• A policy called Fabrikam Contact Recipient Policy, which applied to the contact objects created by the GroupWise connector. (priority: 2)

• The default policy, called Default Policy, which applied to all mail-enabled objects in the Active Directory forest (priority: Lowest)

Default Policy

The default policy cannot be deleted, and its membership cannot be altered. The Fabrikam migration team discovered it had to add GroupWise to the types of addresses created by the default policy. This information was necessary for coexistence, as Exchange 2000 Calendar Connector does not work properly unless Exchange System Attendant has a GroupWise e-mail address. System Attendant, like all system services that have e-mail addresses, is assigned its e-mail address by the default policy. For this reason, ensure that the GWISE check box is selected in the default policy.

To add GroupWise addresses to the default policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Recipients, and then click Recipient Policies.

3. In the details pane, right-click Default Policy, and then click Properties.

4. In Default Policy Properties, on the E-Mail Addresses (Policy) tab, click New.

5. In New E-mail Address, click Novell GroupWise Address, and then click OK.

6. In Novell GroupWise Address Properties, in the Address box, type the GroupWise address format you want all mail-enabled objects in Active Directory to have, and then click OK. At Fabrikam, this format was Exchange.First Administrative Group.&m.

7. On the E-Mail Addresses (Policy) tab, ensure that GWISE is selected.

Fabrikam Recipient Policy

The Fabrikam Recipient Policy applied to all users with Exchange mailboxes, mail-enabled groups, and public folders. This recipient policy consisted of the default X.400 and SMTP addresses (for example, alan.steiner@fabrikam.com), as well as a GroupWise address like the one created in the Default Policy. The GroupWise address is generated so that, during coexistence, Exchange users can communicate with GroupWise users.

In addition, a secondary SMTP address was included in this policy. The secondary SMTP address used a logon ID (for example, asteiner@fabrikamworldwide.com), similar to each employee's GroupWise e-mail address. This address was included in the policy to ensure that users would continue receiving e-mail from the Internet, even if the mail was addressed to their old GroupWise e-mail address.

To create the recipient policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Recipients, right-click Recipient Policies, point to New, and then click Recipient Policy.

3. In New Policy, under Property pages, select the E-Mail Addresses check box, and then click OK.

4. In Properties, on the General tab, in the Name box, type Fabrikam Recipient Policy.

5. To define policy membership, click Modify.

6. In Find Exchange Recipients, under Show these recipients, select the Users with Exchange mailbox, Groups, and Public folders check boxes. Clear all other check boxes, and then click OK.

7. In Properties, on the E-Mail Addresses (Policy) tab, click New.

8. In New E-mail Address, click SMTP Address, and then click OK.

9. In SMTP Address Properties, under Address, type the secondary SMTP address, and then click OK. At Fabrikam, this address was %m@fabrikamworldwide.com.

10. On the E-Mail Addresses (Policy) tab, select the new SMTP address check box.

Fabrikam Contact Recipient Policy

The GroupWise connector creates contact objects in Active Directory for every migrating GroupWise user. The default policy assigns SMTP addresses to these contact objects. However, having the default policy assign SMTP address to these objects is not desirable because, when you migrate the users to Exchange and assign the users SMTP addresses, the SMTP address (for example, alan.steiner@fabrikam.com) is already taken by the contact object.

For this reason, the Fabrikam migration team created a contact recipient policy whose membership consisted of only contact objects. This policy created SMTP addresses in the format @fabrikamgw.com so that, when the user migrated, no conflict occurred when assigning the new Exchange user an SMTP address.

To create a contact recipient policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Recipients, right-click Recipient Policies, point to New, and then click Recipient Policy.

3. In New Policy, under Property pages, select E-Mail Addresses, and then click OK.

4. In Properties, on the General tab, in the Name box, type Fabrikam Contact Recipient Policy.

5. To define policy membership, click Modify.

6. In Find Exchange Recipients, under Show these recipients, select the Contacts check box. Clear all other check boxes, and then click OK.

7. In Properties, on the E-Mail Addresses (Policy) tab, click New.

8. In New E-mail Address, click SMTP Address, and then click OK.

9. In SMTP Address Properties, under Address, type the contact SMTP address. At Fabrikam, this address was @fabrikamgw.com. Click OK.

10. On the E-Mail Addresses (Policy) tab, select the new SMTP address check box.

Create a Mailbox Recipient Policy (Mailbox Manager)

Fabrikam created a mailbox recipient policy, which configures Mailbox Manager to maintain employees' mailboxes by deleting messages that exceed a time or age limit.

Note: Mailbox Manager is available in Exchange 2000 SP1 or later.

For complete information about mailbox recipient policies, see your Exchange 2000 online documentation.

Fabrikam administrators used the following procedure to create a mailbox recipient policy; be aware that not all of their configurations may apply to your organization.

To create a mailbox recipient policy

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Recipients, and then click Recipient Policies.

3. In the details pane, right-click Fabrikam Recipient Policy (created earlier when setting up e-mail address recipient policies), and then click Change property pages.

4. In New Policy, select Mailbox Manager Settings, and then click OK.

5. In the details pane, right-click Fabrikam Recipient Policy again, and then click Properties.

6. In Fabrikam Recipient Policy Properties, click the Mailbox Manager Settings (Policy) tab.

7. In the When processing a mailbox list, select Move to Deleted Items folder.

8. Under Folder, select the Inbox, Sent Items, Deleted Items, and System Cleanup Folders check boxes. Clear all other check boxes.

9. Click Inbox, and then click Edit.

10. In Folder Retention Settings, clear the Message Size (KB) check box and ensure that the Age Limit (days) check box is selected. In the Age Limit (days) text box, type 45, and then click OK. Fabrikam wants to delete all messages older than 45 days, regardless of the size of the messages.

11. Repeat Step 10 for every folder selected in Step 8, except Deleted Items.

12. Click Deleted Items, and then click Edit.

13. In Folder Retention Settings, clear the Message Size (KB) check box. In the Age Limit (days) text box, type 7, and then click OK.

Starting the Mailbox Management Process

After you create a mailbox recipient policy, Mailbox Manager does not run until you activate it on the server object.

To start the mailbox management process

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, right-click a server that contains Exchange mailboxes, and then click Start Mailbox Management Process.

3. Repeat Step 2 for every server.

Recipient Update Service

The Recipient Update Service ensures accurate address list memberships by updating address lists to reflect the modifications you make. The frequency and method you use to update address lists depends on your organization's needs, network topology, and resources. By default, Exchange creates a Recipient Update Service for the enterprise and for the domain in which it is installed.

For complete information about the Recipient Update Service, see your Exchange 2000 online documentation.

To expedite replication when administrators make changes to an address list or policy from any location, Fabrikam administrators installed a Recipient Update Service in every office location.

To create a Recipient Update Service

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Recipients.

3. Right-click Recipient Update Service, point to New, and then click Recipient Update Service.

4. In New Object – Recipient Update Service, click Browse.

5. In Browse for Domain, select corp.fabrikam.com, and then click OK.

After Recipient Update Services were created, Fabrikam administrators in each office location could update address lists with any changes or rebuild address lists on their local domain controllers. The local domain controllers then replicated the changes to the rest of the organization.

To update or rebuild address lists

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Recipients, and then click Recipient Update Services.

3. In the details pane, right-click the appropriate Recipient Update Service, and then click Update Now or Rebuild. The appropriate Recipient Update Service is Recipient Update Service (FABRIKAM) where, under Domain Controller, the local domain controller is listed.

Routing Groups

Figure 2.11 (in Chapter 2) displays the routing group design implemented by Fabrikam administrators. This section describes how to create routing groups. To begin, create a routing groups container in each administrative group.

To create a routing groups container

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups.

3. Right-click First Administrative Group, point to New, and then click Routing Groups Container.

The Fabrikam migration team named its routing groups container "Routing Groups."

To create a routing group

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative Group.

3. Right-click Routing Groups, point to New, and then click Routing Group.

4. In Properties, in the Name box, type a name for the routing group. The first routing group created by Fabrikam for its Richmond headquarters was called RI RG.

5. Repeat Steps 3 and 4 to create routing groups for Alexandria, Chicago, Braintree, and Munich.

To populate routing groups

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Routing Groups, and then expand the routing group you want to populate.

3. Select a server, and then drag it with your mouse into the Members folder in the routing group to which you want that server to belong.

Routing Group Connectors

Within the Fabrikam organization, routing group connectors were required so that all the routing groups could communicate with one another. Figure 2.11 (in Chapter 2) displays the routing group connector architecture designed by the Fabrikam migration team.

For complete information about configuring routing group connectors, see your Exchange 2000 online documentation.

Fabrikam used the following procedure to configure its routing group connectors; be aware that not all settings may apply to your organization.

To create a routing group connector

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Routing Groups, and then expand the routing group for which you want to create a connector.

3. Right-click Connectors, point to New, and then click Routing Group Connector.

4. In Properties, on the General tab, in the Name box, type the name of the routing group connector. For example, Fabrikam named its connector from the Richmond routing group (RI RG) to the Alexandria routing group (AL RG) RI-AL RGC.

5. In the Connects this routing group with list, select the target routing group.

6. On the Remote Bridgehead tab, click Add.

7. In Add Bridgehead, select the server and virtual server. At Fabrikam, this server was always the target server and the virtual server was Default SMTP Virtual Server.

8. On the Delivery Options tab, select the Use different delivery times for oversize messages check box.

9. In the Oversize messages are greater than (KB) box, type 10000, which is 10 MB.

10. Click Customize (the bottom button) and, in Schedule, select non-working hours. These hours will be the times that messages over 10 MB are delivered.

11. When you finish configuring the connector, a prompt appears asking Do you want to create the routing group connector in the remote routing group? Click Yes.

SMTP Connectors

Although computers running Exchange 2000 can communicate with the Internet directly, Fabrikam created SMTP connectors on a designated bridgehead server (MSGBRDGRI-01P). The SMTP connectors routed all of Fabrikam's outbound SMTP mail through the intranet firewall to one of two SMTP mail relay servers in Fabrikam's perimeter network. The SMTP mail relay servers then sent the messages through the Internet firewall to the Internet.

For complete information about creating and configuring SMTP connectors, see your Exchange 2000 online documentation.

Fabrikam administrators used the following procedure to set up their SMTP connectors; be aware that not every setting may apply to your organization.

To create an SMTP connector

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Routing Groups, and then expand RI RG (the Richmond routing group).

3. Right-click Connectors, point to New, and then click SMTP Connector.

4. In Properties, on the General tab, in the Name box, type Fabrikam SMTP Connector.

5. Click Forward all mail through this connector to the following smart hosts, and then, in the corresponding text box, type the IP addresses of the two SMTP mail relay servers in the perimeter network. Organizations that use an ISP can type the IP address of mail relay servers hosted at the ISP sites. Be sure to enclose each IP address in brackets ([ ]) and separate IP addresses with commas (,).

6. Under Local bridgeheads, click Add.

7. In Add Bridgehead, under Server, click MSGBRDGRI-01P (with Default Virtual Server), and then click OK.

8. Select the Do not allow public folder referrals check box.

9. On the Address Space tab, click Add.

10. In Add Address Space, click SMTP, and then click OK.

11. In Internet Address Space Properties, in the E-mail domain box, leave the default e-mail domain of *. In the Cost box, change the default cost to 10, and then click OK.

12. On the Address Space tab, under Connector scope, ensure that the Entire organization button is selected.

13. On the Content Restrictions tab, ensure that every check box under Allowed priorities and Allowed types is selected. Under Allowed sizes, select the Only messages less than (KB) check box, and then type 5000 in the corresponding text box. This option imposes a 5 MB limit on all messages sent by Fabrikam employees to the Internet.

SMTP Connector for Executive Group

Executives at Fabrikam wanted to send messages up to 10 MB in size to the Internet. Administrators created a group called Fabrikam Execs and used the following procedure to create an SMTP connector just for this group.

To create the executive SMTP connector

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Routing Groups, and then expand RI RG (the Richmond routing group).

3. Right-click Connectors, point to New, and then click SMTP Connector.

4. In Properties, on the General tab, in the Name box, type Fabrikam SMTP Connector.

5. Click Forward all mail through this connector to the following smart hosts, and then, in the corresponding check box, type the IP addresses of the two SMTP mail relay servers in the perimeter network. Organizations that use an ISP can type the IP address of mail relay servers hosted at the ISP sites. Be sure to enclose each IP address in brackets ([ ]) and separate IP addresses with commas (,).

6. Under Local bridgeheads, click Add.

7. In Add Bridgehead, under Server, click MSGBRDGRI-01P (with Default Virtual Server), and then click OK.

8. Select the Do not allow public folder referrals check box.

9. On the Address Space tab, click Add.

10. In Add Address Space, click SMTP, and then click OK.

11. In Internet Address Space Properties, in the E-mail domain box, leave the default e-mail domain of *. In the Cost box, change the default cost to 30, and then click OK.

12. On the Content Restrictions tab, under Allowed sizes, select the Only messages less than (KB) check box, and then, in the corresponding text box, type 10000. This option imposes a 10 MB limit on all messages sent through this connector.

13. On the Delivery Restrictions tab, under By default, messages from everyone are, click Rejected.

14. Under Accept messages from, click Add.

15. In Select Recipient, select Fabrikam Execs, click Add, and then click OK.

Public Folders

For complete information about public folders, how to use them, and how to configure them, see your Exchange 2000 online documentation. The following procedures describe the two most important public folder configuration performed by Fabrikam administrators.

Configure Public Folder Permissions

You can specify the users and groups who can change the replication, limits, and other settings for the public folder. The following procedure describes how to grant administration rights to a public folder. There are other permissions you can grant or deny to users in your organization, at different levels in your public folder hierarchy. For more information about these procedures, see your Exchange 2000 online documentation.

To grant administration rights to a public folder

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Folders, and then expand the folder tree containing the folder you want.

3. Right-click a folder you want to grant administration rights, and then click Properties.

4. In < folder name > Properties, on the Permissions tab, click Administrative rights.

5. In Permissions for < folder name >, to grant access to a specific user, click Add.

6. Select a user, and then click Add. Repeat this step for all users you want to add.

7. In Permissions for < folder name >, under Permissions for < user or group >, select the Allow or Deny check box to grant or deny the selected user or group access to the available options.

Configure Public Folder Replication

Public folders are created underneath top-level roots and belong to public folder hierarchies. Each hierarchy has its own public folder store, and all folders in a hierarchy are contained within the same public folder store. You are not required to replicate every public folder in a public folder store. You can replicate a specific public folder or subset of folders, or you can replicate all of them. You can configure a public folder to have replicas on multiple public folder servers within an organization.

For complete information about public folder replication, see your Exchange 2000 online documentation.

The following procedure describes how to replicate a public folder; be aware that there are many more options than the results of this procedure.

After you create a public folder store on an alternate server, you need to identify which folders to replicate in that public folder store. Although the storage location on the alternate server is associated with a specific folder hierarchy, the folders in the public folder store are not replicated to the alternate server by default. You must access the folder and specify that it should be replicated to the alternate server.

To add a replica (a copy of a public folder) to another public folder store

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Folders, and then expand the folder tree containing the folder you want to replicate.

3. Right-click a folder you want to replicate, and then click Properties.

4. On the Replication tab, click Add.

5. Select a public folder store on the alternate server.

Transaction Logs

After the Exchange installation, Fabrikam administrators moved the transaction logs to drive L on each computer running Exchange that contained user mailboxes. Before you perform the following procedure, be sure to create a folder called mdbdata on drive L.

To move the transaction logs

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, and then expand the appropriate server.

3. Right-click First Storage Group, and then click Properties.

4. In First Storage Group Properties, beside Transaction log location, click Browse.

5. In Transaction Log, select L:\mdbdata, and then click OK.

Databases

After the Exchange installation, Fabrikam administrators moved the databases to drive N on each computer running Exchange that contained user mailboxes. Before you perform the following procedure, be sure to create a folder called mdbdata on drive N.

To move the databases

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, and then expand the appropriate server.

3. Right-click First Storage Group, and then click Properties.

4. In First Storage Group Properties, beside System path location, click Browse.

5. In System Path, select N:\mdbdata, and then click OK.

6. In System Manager, expand First Storage Group, right-click Mailbox Store (< server name >), and then click Properties.

7. In Mailbox Store (< server name >) Properties, click the Database tab.

8. Beside Exchange database, click Browse.

9. In Exchange Database, save priv1.edb and pub1.edb to N:\mdbdata.

10. Repeat Steps 6 through 9 for Public Folder Store (< server name >).

Log Buffers

After the Exchange installation, Fabrikam administrators used the following procedure to increase the log buffers on all computers running Exchange. Fabrikam administrators found the default value of 84 was too low for the back-end servers in their organization.

To increase the size of the log buffers

1. Start the Microsoft Windows® 2000 Support Tool ADSI Edit. Support tools are available on your Windows 2000 Server CD-ROM.

2. Expand Configuration Container [corp.fabrikam.com], CN=Configuration,DC=corp,DC=Fabrikam,DC=com, CN=Services, CN=Microsoft Exchange, CN=Fabrikam, CN=Administrative Groups, CN=First Administrative Group, CN=Servers, and CN=< server name >.

3. Click First Storage Group, and then click Properties.

4. In First Storage Group Properties, on the Attributes tab, beside Select a property to view, select msExchESEParamLogBuffers.

5. In the Edit Attribute box, type 9000, and then click OK.

Outlook Web Access

Fabrikam used the procedures in this section to configure Outlook Web Access. Be aware that not every setting made by Fabrikam may be optimal for your organization.

Configure the Server As a Front-End Server

Fabrikam administrators installed Exchange 2000 on MSGOWARI-01P, their dedicated Outlook Web Access server. MSGOWARI-01P was placed in the perimeter network in Richmond and acted as an Exchange front-end server, which means it sends HTTP requests from Outlook Web Access users to their mailboxes behind the intranet firewall. Table A.1 summarizes the ports that Fabrikam had to open in both the Internet and intranet firewalls.

Important: You must configure the virtual directories and HTTP virtual server the same way on the Outlook Web Access server as they are on all back-end servers. Take note of any configurations on one so that you can do the same on the other. By default, the exchange and public virtual directories are identical.

To configure the server as a front-end server

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and then expand Servers.

3. Right-click MSGOWARI-01P, and then click Properties.

4. In MSGOWARI-01P Properties, on the General tab, select the This is a front-end server check box.

5. Click OK, and then restart the computer.

Table A.1 Firewall ports opened for Outlook Web Access

Connection from	Connection to	Firewall (Internet or intranet)	Protocol/ports used
Internet	Outlook Web Access server	Internet	HTTPS/TCP 443
Outlook Web Access server	Domain controllers (DCRI-03P and DCRI-04P)	Intranet	LDAP (to domain controller)/TCP 389 LDAP (to global catalog server)/TCP 3268 Kerberos/TCP 88 or Kerberos/UDP 88 DNS/TCP 53 or DNS/UDP 53
Outlook Web Access server	Back-end servers (MSGRI0-1P, MSGAL-01P, and so on)	Intranet	HTTP/TCP 80
Outlook Web Access server	Internet	Internet	HTTPS/TCP 443
Local Fabrikam users	Outlook Web Access server	Intranet	HTTP/TCP 80 or HTTPS/TCP 443

Set the Default Domain Name

Fabrikam administrators used the following procedure so that Outlook Web Access users did not have to specify a domain name during authentication. This configuration was possible because all Fabrikam users were in the same domain, corp.fabrikam.com.

To set the default domain name

1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand Servers, expand MSGOWARI-01P, expand Protocols, expand HTTP, and then expand Exchange Virtual Server.

3. Right-click Exchange, and then click Properties.

4. In Exchange Properties, on the Access tab, click Authentication.

5. In Authentication Methods, in the Default domain box, type the domain name, corp.fabrikam.com.

Users do not have to authenticate themselves with a <domain name>\<user name> format. Only a user name or logon ID is necessary.

Reroute Users to a Secure Connection

If users accidentally type https:// instead of https:// when connecting to Outlook Web Access, the following procedure automatically redirects them to a secure connection.

To redirect users to a secure connection

1. On the Start menu, point to Programs, point to Administrative Tools, and then click Internet Information Services .

2. In Internet Information Services, expand *msgowari-01p, expand Web Sites, right-click Default Web Site, and then click Properties.

3. In Default Web Site Properties, on the Directory Security tab, under Secure communications, click Edit.

4. In Secure Communications, verify that the Require secure channel (SSL) check box is not selected.

5. In < drive >:\inetpub\wwwroot, create an HTML file called default.htm. Make the contents of this file:

   <html>

   <head>
   <meta http-equiv="refresh"
   content="0;URL=https://webmail.fabrikam.com/exchange">
   </head>
   </html>

Install Digital Certificates for SSL Security

The IIS Web Server Certificate Wizard allows you to create and install a certificate that enables SSL communications between the Outlook Web Access server and your users.

To install a digital certificate

1. On the Start menu, point to Programs, point to Administrative Tools, and then click Internet Information Services.

2. In Internet Information Services, expand *msgowari-01p, expand Web Sites, right-click Default Web Site, and then click Properties.

3. In Default Web Site Properties, on the Directory Security tab, under Secure communications, click Server Certificate.

4. Use Web Server Certificate Wizard to create a new certificate, with a bit length of 1024.

5. On the Your Site's Common Name page, under Common name, type webmail.fabrikam.com. This entry is very important. It must match the URL you want users to type to access Outlook Web Access.

6. Provide the rest of the information, and then send your certificate request to a certificate authority, such as VeriSign. You may need to fill out an enrollment form on the certificate authority's Web site.

7. Upon approval, Fabrikam received its certificate in e-mail, as a cert.cer attachment. Save this file on the Outlook Web Access server.

8. On MSGOWARI-01P, repeat Steps 1 through 3 above.

9. Enter the path to cert.cer.

Multimedia Outlook Web Access

As of January 2002, if Outlook Web Access users install the Exchange Multimedia Control, but administrators did not install the HTML Source Edit component of Microsoft Office 2000, the first time users run Outlook Web Access, the Office 2000 installer prompts them to insert the Office 2000 compact disc. Inserting the CD is not necessary; users can click Cancel.

To fix this problem, install the HTML Source Editor.

Appendix B Exchange Installation Checklists

To ensure that a consistent process was used to build each server in the Fabrikam Worldwide organization, the Fabrikam migration team used checklists extensively. In addition, the team saved checklists in a documentation folder on each server and used the checklists for troubleshooting and maintenance purposes.

Fabrikam administrators used the first two checklists (Tables B.1 and B.2) to install Microsoft® Exchange 2000 on servers that were intended for medium and small offices. They used the last two checklists (Tables B.3 and B.4) to install a bridgehead server and to install a front-end server used to process HTTP requests by Outlook® Web Access users.

Use these checklists as a guideline for your own organization when you configure the first Exchange server installed in your organization. Before you use any of these checklists, remember to consult the installation prerequisites covered in "Installing Exchange" in Chapter 3.

For more information about server roles (medium office mailbox server, bridgehead server, and so on), see "Exchange Server Hardware Planning" in Chapter 2.

Note: The primary difference among the large, medium, and small office server configurations is the disk subsystem configuration.

Medium Office Mailbox Server

A computer running Exchange 2000 that is used to service a medium-sized office can hold 40 to 100 mailboxes.

Table B.1 Installing Exchange in a medium office

Step	Action	ü
1	Receive server from the Microsoft Windows® 2000 team.
2	Confirm that the RAID configuration matches designed configuration: · Two 9 GB or two 18 GB; RAID1; Disk 0 · Drive C: (3.71 GB); formatted NTFS; System · Drive E: (1.17 GB); formatted NTFS; Operating system recovery partition · Drive F: (1.59 GB); formatted NTFS; Application · Drive Z: (2 GB); formatted NTFS; Paging (swap) file · Two 9 GB; RAID1; Disk 1 · Drive L: (8.46 GB); formatted NTFS; Exchange transaction log files · Four 18 GB; RAID5; Disk 2 · Drive N: (36 GB); formatted NTFS; Exchange databases and Exchange binary files Use the disk array management tool from your hardware vendor. Although Windows provides software-level RAID, Microsoft Consulting Services recommends using the hardware RAID provided by the SCSI controllers. Note The Exchange transaction log files must be on a dedicated RAID1 drive set. Do not allow any other applications to use the Exchange 2000 transaction log set.
3	Verify Windows 2000 Licensing Mode is set to per seat.
4	Confirm TCP/IP settings: 1. At a command prompt, type ipconfig /all. 2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the predetermined design. Note DNS is critical for Exchange. If you install Exchange on a DNS server, do not configure the DNS setting on the Exchange network interface card (NIC) to the local server; instead, use another DNS server.
5	In My Network Places, verify that the File and Printer Sharing for Microsoft Networks setting is set to Maximize Data Throughput For Network Applications.
6	Confirm that the computer name is set correctly, and then join the computer to the domain (corp.fabrikam.com).
7	In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8	Create the MMC Exchange 2000 console, and add the following MMC snap-ins: · Active Directory Users and Computers · Active Directory Domains and Trusts · Active Directory Sites and Services · Event Viewer · Disk Management · Services Save the MMC at Desktop Level for All Users. For information about creating MMC snap-ins, see your Windows 2000 online documentation.
9	On the desktop, rename the My Computer icon to <computer name>.
10	Perform the following steps: 1. Check Event Log properties. 2. Confirm that Maximum Log Size is set to 16384 for Application, System, and Security log files. 3. Confirm that Overwrite as needed is selected.
11	Confirm the paging file is set to: · Drive C: 5 MB · Drive Z: 1955 MB To confirm the paging file is set 1. On the desktop, right-click the < computer name> icon (formerly My Computer, which you renamed in Step 9), and then click Properties. 2. In System Properties, on the Advanced tab, click Performance Options. 3. In Performance Options, under Virtual memory, click Change. 4. In Virtual Memory, check the paging file settings. If they are not set properly, type the appropriate sizes, and then click Set. Note These settings were optimized for Fabrikam's networking environment. Your organization may require different paging file settings. For more information about paging files, see your Windows 2000 online documentation.
12	Confirm that Maximum Registry Size set to 150 MB. To confirm Maximum Registry Size is set 1. Follow the same procedure in Step 11. 2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB) setting is correct. For more information, see your Windows 2000 online documentation.
13	If you have not done so already, add the /3gb switch to the Boot.ini file for servers with more than 1 GB of memory. For more information about this switch, see the Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14	Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000 Server CD-ROM.) This test ensures correct Active Directory® directory service and DNS integration and verifies where the Exchange servers look to find domain controllers, global catalog servers, and other services. Run the following variations of Nltest.exe in the corp.fabrikam.com domain: · nltest /dsgetdc:corp · nltest /dclist:corp · nltest /dsgetsite Note If you get an error, restart the Net Logon service. If restarting the service does not correct the error, you have a DNS problem, or your Windows 2000 sites are not defined correctly. You must work with Active Directory and network administrators to remedy the situation before proceeding.
15	Perform the following steps: 1. Start the Active Directory Sites and Services snap-in. 2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your first site), and then click Servers. 3. Confirm that the Exchange server is listed.
16	Insert the Exchange 2000 Enterprise CD-ROM and run Setup. When prompted, be sure to install Exchange files to drive F.
17	Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at https://go.microsoft.com/fwlink/?LinkId=5909. Note After installing SP2, the help files for Outlook Web Access clients must be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the first screen you see when you launch EX2KSP2_server.exe), you must select Outlook Web Access Help Files, and then double-click the appropriate .msi file for each client language you support.
18	Move the transaction log files to the transaction log drive (drive L). For more information about how to move the files, see "Transaction Logs" in Appendix A.
19	Move the Exchange databases to drive N. For more information about how to move the databases, see "Databases" in Appendix A.
20	Create a mailbox recipient policy and start the mailbox management process. For more information, see "Create a Mailbox Recipient Policy (Mailbox Manager)" in Appendix A.
21	Increase the log buffers. For more information about how to increase the log buffers, see "Log Buffers" in Appendix A.

Small Office Mailbox Server

A computer running Exchange 2000 that is used to service a small office can hold up to 40 mailboxes.

Table B.2 Installing Exchange in a small office

Step	Action	ü
1	Receive server from the Windows 2000 team.
2	Confirm that RAID configuration matches designed configuration: · Two 9 GB or two 18 GB; RAID1; Disk 0 · Drive C: (3.71 GB); formatted NTFS; System · Drive E: (1.17 GB); formatted NTFS; OS recovery partition · Drive F: (1.59 GB); formatted NTFS; Application · Drive Z: (2 GB); formatted NTFS; Paging (swap) file · Two 9 GB; RAID1; Disk 1 · Drive L: (8.46 GB); formatted NTFS; Exchange transaction log files · Two 18 GB; RAID1; Disk 2 · Drive N: (18 GB); formatted NTFS; Exchange databases and Exchange binary files Use the disk array management tool from your hardware vendor. Although Windows provides software-level RAID, Microsoft Consulting Services recommends using the hardware RAID provided by the SCSI controllers. Note The Exchange transaction log files must be on a dedicated RAID1 drive set. Do not allow any other applications to use the Exchange 2000 transaction log set.
3	Verify Windows 2000 Licensing Mode is set to per seat.
4	Check TCP/IP settings: 1. At a command prompt, type ipconfig /all. 2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the predetermined design. Note DNS is critical for Exchange. If you install Exchange on a DNS server, do not configure the DNS setting on the Exchange network interface card (NIC) to the local server; instead, use another DNS server.
5	In My Network Places, verify that File and Printer Sharing for Microsoft Networks setting is set to Maximize Data Throughput For Network Applications.
6	Confirm that the computer name is set correctly, and then join the computer to the domain (corp.fabrikam.com).
7	In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8	Create the MMC Exchange 2000 console, and add the following MMC snap-ins: · Active Directory Users and Computers · Active Directory Domains and Trusts · Active Directory Sites and Services · Event Viewer · Disk Management · Services Save the MMC at Desktop Level for All Users. For information about creating MMC snap-ins, see your Windows 2000 online documentation.
9	On the desktop, rename the My Computer icon to <computer name>.
10	Perform the following steps: 1. Check Event Log properties. 2. Confirm that Maximum Log Size is set to 16384 for Application, System, and Security log files. 3. Confirm that Overwrite as needed is selected.
11	Confirm the paging file is set to: · Drive C: 5 MB · Drive Z: 1955 MB To confirm the paging file is set 1. On the desktop, right-click the < computer name> icon (formerly My Computer, which you renamed in Step 9), and then click Properties. 2. In System Properties, on the Advanced tab, click Performance Options. 3. In Performance Options, under Virtual memory, click Change. 4. In Virtual Memory, check the paging file settings. If they are not set properly, type the appropriate sizes, and then click Set. Note These settings were optimized for Fabrikam's networking environment. Your organization may require different paging file settings. For more information about paging files, see your Windows 2000 online documentation.
12	Confirm that Maximum Registry Size set to 150 MB. To confirm Maximum Registry Size is set 1. Follow the same procedure in Step 11. 2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB) setting is correct. For more information, see your Windows 2000 online documentation.
13	If you have not done so already, add the /3gb switch to the Boot.ini file for servers with more than 1 GB of memory. For more information about this switch, see the Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14	Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000 Server CD-ROM.) This test ensures correct Active Directory and DNS integration and verifies where the Exchange servers look to find domain controllers, global catalog servers, and other services. Run the following variations of Nltest.exe in the corp.fabrikam.com domain: · nltest /dsgetdc:corp · nltest /dclist:corp · nltest /dsgetsite Note If you get an error, restart the Net Logon service. If restarting the service does not correct the error, you have a DNS problem, or your Windows 2000 sites are not defined correctly. You must work with Active Directory and network administrators to remedy the situation before you proceed.
15	Perform the following steps: 1. Start the Active Directory Sites and Services snap-in. 2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your first site), and then click Servers. 3. Confirm that the Exchange server is listed.
16	Insert the Exchange 2000 Enterprise CD-ROM and run Setup. When prompted, be sure to install Exchange files to drive F.
17	Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at https://go.microsoft.com/fwlink/?LinkId=5909. Note After installing SP2, the help files for Outlook Web Access clients must be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the first screen you see when you launch EX2KSP2_server.exe), you must select Outlook Web Access Help Files, and then double-click the appropriate .msi file for each client language you support.
18	Move the transaction log files to the transaction log drive (drive L). For more information about how to move the files, see "Transaction Logs" in Appendix A.
19	Move the Exchange databases to drive N. For more information about how to move the databases, see "Databases" in Appendix A.
20	Create a mailbox recipient policy and start the mailbox management process. For more information, see "Create a Mailbox Recipient Policy (Mailbox Manager)" in Appendix A.
21	Increase the log buffers. For more information about how to increase the log buffer, see "Log Buffers" in Appendix A.

Bridgehead Server

An Exchange 2000 bridgehead server contains one or more connectors, most notably the SMTP connector, GroupWise connector, and Exchange 2000 Calendar Connector. The bridgehead server handles all outgoing and incoming messages from the Internet to users behind your firewall.

At Fabrikam, SMTP connectors communicated with two SMTP mail relay servers outside the intranet firewall in Fabrikam's perimeter network. A second firewall protected the SMTP mail relay servers from the Internet, as illustrated in Figure 1.3 (in Chapter 1). In this scenario, no e-mail could reach a Fabrikam employee without first passing through the Internet firewall, an SMTP mail relay server, the intranet firewall, and finally an SMTP connector on a bridgehead server. For information about configuring SMTP connectors, see the "SMTP connectors" section in Appendix A.

The bridgehead server also contains the GroupWise connector and Exchange 2000 Calendar Connector, which allow the GroupWise and Exchange messaging systems to communicate during coexistence.

Table B.3 Installing Exchange on a bridgehead server

Step	Action	ü
1	Receive server from the Windows 2000 team.
2	Confirm that RAID configuration matches designed configuration: · Two 18 GB; RAID1; Disk 0 · Drive C: (3.71 GB); formatted NTFS; System · Drive E: (1.17 GB); formatted NTFS; OS recovery partition · Drive F: (10.59 GB); formatted NTFS; Application · Drive Z: (2 GB); formatted NTFS; Paging (swap) file
3	Verify Windows 2000 Licensing Mode is set to per seat.
4	Confirm TCP/IP settings: 1. At a command prompt, type ipconfig /all. 2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the predetermined design. Note DNS is critical for Exchange. If you install Exchange on a DNS server, do not configure the DNS setting on the Exchange network interface card (NIC) to the local server; instead, use another DNS server.
5	In My Network Places, verify that the File and Printer Sharing for Microsoft Networks setting is set to Maximize Data Throughput For Network Applications.
6	Confirm that the computer name is set correctly, and then join the computer to the domain (corp.fabrikam.com).
7	In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8	Create the MMC Exchange 2000 console, and add the following MMC snap-ins: · Active Directory Users and Computers · Active Directory Domains and Trusts · Active Directory Sites and Services · Event Viewer · Disk Management · Services Save the MMC at Desktop Level for All Users. For information about creating MMC snap-ins, see your Windows 2000 online documentation.
9	On the desktop, rename the My Computer icon to <computer name>.
10	Perform the following steps: 1. Check Event Log properties. 2. Confirm that Maximum Log Size is set to 16384 for Application, System, and Security log files. 3. Confirm that Overwrite as needed is selected.
11	Confirm the paging file is set to: · Drive C: 5 MB · Drive Z: 1955 MB To confirm the paging file is set 1. On the desktop, right-click the < computer name> icon (formerly My Computer, which you renamed in Step 9), and then click Properties. 2. In System Properties, on the Advanced tab, click Performance Options. 3. In Performance Options, under Virtual memory, click Change. 4. In Virtual Memory, check the paging file settings. If they are not set properly, type the appropriate sizes, and then click Set. Note These settings were optimized for Fabrikam's networking environment. Your organization may require different paging file settings. For more information about paging files, see your Windows 2000 online documentation.
12	Confirm that Maximum Registry Size set to 150 MB. To confirm Maximum Registry Size is set 1. Follow the same procedure in Step 11. 2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB) setting is correct. For more information, see your Windows 2000 online documentation.
13	If you have not done so already, add the /3gb switch to the Boot.ini file for servers with more than 1 GB of memory, For more information about this switch, see the Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14	Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000 Server CD-ROM.) This test ensures correct Active Directory and DNS integration and verifies where the Exchange servers look to find domain controllers, global catalog servers, and other services. Run the following variations of Nltest.exe in the corp.Fabrikam.com domain: · nltest /dsgetdc:corp · nltest /dclist:corp · nltest /dsgetsite Note If you get an error, restart the Net Logon service. If restarting the service does not correct the error, you have a DNS problem, or your Windows 2000 sites are not defined correctly. You must work with Active Directory and network administrators to remedy the situation before you proceed.
15	Perform the following steps: 1. Start the Active Directory Sites and Services snap-in. 2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your first site), and then click Servers. 3. Confirm that the Exchange server is listed.
16	Insert the Exchange 2000 Enterprise CD-ROM and run Setup. When prompted, be sure to install Exchange files to drive F. On the Component Selection page of Exchange 2000 Installation Wizard, select a custom installation, and then select Microsoft Exchange Connector for Novell GroupWise, as shown in Figure 3.3 (in Chapter 3).
17	Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at https://go.microsoft.com/fwlink/?LinkId=5909.
18	Install Exchange 2000 Calendar Connector (available in SP1 and later). For information about installing Calendar Connector, see the Exchange 2000 Server online documentation.
19	Enable circular logging. To enable circular logging 1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager. 2. Expand First Administrative Group, expand Servers, and then expand < bridgehead server name>. 3. Right-click First Storage Group, and then click Properties. 4. In First Storage Group Properties, on the General tab, select Enable circular logging.
20	Set up the SMTP connector and the "Executive Group" SMTP connector. For information about setting up the SMTP connectors, see "SMTP Connectors" in Appendix A.
21	Create a mailbox recipient policy and start the mailbox management process. For more information, see "Create a Mailbox Recipient Policy (Mailbox Manager)" in Appendix A.
22	Increase the log buffers. For more information about how to increase the log buffers, see "Log Buffers" in Appendix A.

Outlook Web Access Server

The Outlook Web Access server is an Exchange 2000 front-end server that handles HTTP requests. The requests come from users who access their Exchange mailbox data with a Web browser.

At Fabrikam, the Outlook Web Access server (MSGOWARI-01P) was placed in the perimeter network, as illustrated in Figure 2.14 (in Chapter 2). Objects in the perimeter network are inside the Internet firewall but outside the intranet firewall.

The following checklist details the basic procedures for installing and configuring an Outlook Web Access server. For more detailed information about installing Outlook Web Access, see "Outlook Web Access" in Appendix A. For more information about the basics of Outlook Web Access and Exchange 2000 front-end and back-end architecture, see "Outlook Web Access" in Chapter 2.

Table B.4 Installing Exchange on an Outlook Web Access server

Step	Action	ü
1	Receive server from the Windows 2000 team.
2	Confirm that RAID configuration matches designed configuration: · Two 18 GB; RAID1; Disk 0 · Drive C: (3.71 GB); formatted NTFS; System · Drive E: (1.17 GB); formatted NTFS; OS recovery partition · Drive F: (10.59 GB); formatted NTFS; Application · Drive Z: (2 GB); formatted NTFS; Paging (swap) file
3	Verify Windows 2000 Licensing Mode is set to per seat.
4	Confirm TCP/IP settings: 1. At a command prompt, type ipconfig /all. 2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the predetermined design. Note DNS is critical for Exchange. If you install Exchange on a DNS server, do not configure the DNS setting on the Exchange network interface card (NIC) to the local server; instead, use another DNS server.
5	In My Network Places, verify that File and Printer Sharing for Microsoft Networks setting is set to Maximize Data Throughput For Network Applications.
6	Confirm that the computer name is set correctly, and then join the computer to the domain (corp.fabrikam.com).
7	In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8	Create the MMC Exchange 2000 console, and add the following MMC snap-ins: · Active Directory Users and Computers · Active Directory Domains and Trusts · Active Directory Sites and Services · Event Viewer · Disk Management · Services Save the MMC at Desktop Level for All Users. For information about creating MMC snap-ins, see your Windows 2000 online documentation.
9	On the desktop, rename the My Computer icon to <computer name>.
10	Perform the following steps: 1. Check Event Log properties. 2. Confirm that Maximum Log Size is set to 16384 for Application, System, and Security log files. 3. Confirm that Overwrite as needed is selected.
11	Confirm the paging file is set to: · Drive C: 5 MB · Drive Z: 1955 MB To confirm the paging files is set 1. On the desktop, right-click the < computer name> icon (formerly My Computer, which you renamed in Step 9), and then click Properties. 2. In System Properties, on the Advanced tab, click Performance Options. 3. In Performance Options, under Virtual memory, click Change. 4. In Virtual Memory, check the paging file settings. If they are not set properly, type the appropriate sizes, and then click Set. Note These settings were optimized for Fabrikam's networking environment. Your organization may require different paging file settings. For more information about paging files, see your Windows 2000 online documentation.
12	Confirm that Maximum Registry Size set to 150 MB. To confirm Maximum Registry Size is set 1. Follow the same procedure in Step 11. 2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB) setting is correct. For more information, see your Windows 2000 online documentation.
13	If you have not done so already, add the /3gb switch to the Boot.ini file for servers with more than 1 GB of memory, For more information about this switch, see the Microsoft Knowledge Base article 266096, "XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM," at https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14	Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000 Server CD-ROM.) This test ensures correct Active Directory and DNS integration and verifies where the Exchange servers look to find domain controllers, global catalog servers, and other services. Run the following variations of Nltest.exe in the corp.Fabrikam.com domain: · nltest /dsgetdc:corp · nltest /dclist:corp · nltest /dsgetsite Note If you get an error, restart the Net Logon service. If restarting the service does not correct the error, you have a DNS problem, or your Windows 2000 sites are not defined correctly. You must work with Active Directory and network administrators to remedy the situation before you proceed.
15	Perform the following steps: 1. Start the Active Directory Sites & Services snap-in. 2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your first site), and then click Servers. 3. Confirm that the Outlook Web Access server is listed.
16	Insert the Exchange 2000 Enterprise CD-ROM and run Setup. When prompted, be sure to install Exchange files to drive F.
17	Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at https://go.microsoft.com/fwlink/?LinkId=5909. Note After installing SP2, the help files for Outlook Web Access clients must be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the first screen you see when you launch EX2KSP2_server.exe), you must select Outlook Web Access Help Files, and then double-click the appropriate .msi file for each client language you support.
18	Enable circular logging. To enable circular logging 1. Start System Manager. On the Start menu, point to Programs, point to Microsoft Exchange, and then click System Manager. 2. Expand First Administrative Group, expand Servers, and then expand < Outlook Web Access server>. Right-click First Storage Group, and then click Properties. 3. In First Storage Group Properties, on the General tab, select Enable circular logging.
19	To finish setting up the Outlook Web Access server, perform all the tasks in the "Outlook Web Access" section of Appendix A.

Appendix C Migration Flowchart

The following flowchart provides a logical view of the migration process at Fabrikam. The migration team was divided into three groups. The two main groups were the server migration team and the desktop migration team. The third, less formal group was the logistics team, who was responsible for tracking migration details such as which users migrate on a given night. The server migration team prepared the Novell GroupWise and Microsoft® Exchange 2000 messaging systems and used Exchange Migration Wizard to migrate users' data. The desktop migration team prepared employees' computers running Microsoft Windows® 2000 Professional, including setting up each user's Microsoft Outlook® 2000 profile. The desktop team also ensured that all employees had everything they needed after their mailbox data was migrated from Exchange.

Appendix D Additional Resources

This appendix contains migration-related articles from the Microsoft® Knowledge Base and other useful technical papers. Microsoft recommends that you read any of these articles that may apply to your organization before you migrate users.

Microsoft Knowledge Base Articles

These articles can be accessed on the Web at https://support.microsoft.com/. To search for a Microsoft Exchange 2000 article using a key word from the title or the article ID number, select Exchange 2000 Server from the product menu. You can also use the URL beside each article to access the information directly.

Article ID	Title	Summary	URL
268496	XFOR: Migration Wizard Generates Dr. Watson Events When Migrating from GroupWise 5.5	Use a GroupWise client older than version 5.5.3 on the migration server.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=268496
238285	XFOR: GroupWise Migration Fails with Event ID 4012	The GroupWise migration account must be in the same post office as the accounts you are trying to migrate.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=238285
273349	XFOR: GroupWise Migration Is Unsuccessful When Migration Account Is the Same as Mailbox Owner	Always give the migration account proxy access to any account that you are migrating, even for the mailbox belonging to the migration account.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=273349
258175	XFOR: Migrating from GroupWise 5.x to Exchange 2000 May Cause Event 4012: Insufficient Access Rights	You need to ensure that only the migration account has proxy permissions on a user's GroupWise account.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=258175
174254	XADM: GroupWise Users must Grant Access Rights to be Migrated	GroupWise users must grant read and write access to the migration account for certain items in their mailboxes, or those items will not be migrated.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=174254
198013	XFOR: GroupWise 5.x Migration Error	Discusses causes for and solutions to the error message: An error occurred logging on to the GroupWise 5 Admin API.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=198013
198014	XFOR: Troubleshooting GroupWise 5.x Migration Problems	Informative article addressing a permissions error MCS has encountered from the migration server.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=198014
266096	XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM	Explains how to install Exchange 2000 on a computer that has more than 3 GB of RAM.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=266096
197132	Windows 2000 Active Directory FSMO Roles	Provides a summary of Windows 2000 FSMO roles.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=197132
224543	Using Ldp.exe to Find Data in the Active Directory	Explains how to use an important Windows 2000 utility to query Active Directory.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=224543
222059	Windows 2000 GSNW and CSNW Do Not Support NetWare 5 IP	Valuable troubleshooting information.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=222059
235225	GSNW and CSNW Only Support the IPX/SPX Protocol	Valuable troubleshooting information.	https://go.microsoft.com/fwlink/?LinkId=3052&ID=235225

Technical Papers and Other Web Sites

• Microsoft Exchange Server, Novell GroupWise Web site:

  https://go.microsoft.com/fwlink/?LinkId=5908

• Coexistence and Migration Using Microsoft Exchange Connector for Novell GroupWise

  https://go.microsoft.com/fwlink/?LinkId=5907

• Team Model for Application Development

  https://go.microsoft.com/fwlink/?LinkId=5923

• Risk Management Process

  https://go.microsoft.com/fwlink/?LinkId=5929

• Mailbox Recovery for Microsoft Exchange 2000 Server

  https://go.microsoft.com/fwlink/?LinkId=5216

• ForestPrep and DomainPrep

  https://go.microsoft.com/fwlink/?LinkId=5224

• Best Practices for Deploying Full-Text Indexing

  https://go.microsoft.com/fwlink/?LinkId=5223

• Exchange 2000 Front-end and Back-end Topology

  https://go.microsoft.com/fwlink/?linkid=4721

• Microsoft Exchange 2000 Internals: Installation and Setup

  https://go.microsoft.com/fwlink/?LinkId=5906