microsoft exchange 2000 and novell groupwise coexistence...

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration

Published: January 2002

Table of Contents

Introduction ............................................................................................................ 1 Who Should Read This Paper .................................................................................. 1 Deploying Windows 2000 Server and Active Directory ................................................ 2 Fabrikam Case Study Overview............................................................................... 2

Chapter 1 – Planning .......................................................................................... 3 Chapter 2 – Developing....................................................................................... 3 Chapter 3 – Deploying ........................................................................................ 4 Appendixes ....................................................................................................... 4

Chapter 1 Planning ................................................................................................. 5 Migration Team .................................................................................................... 6 Time Line ............................................................................................................ 6 Risk Management Plan........................................................................................... 7 Fabrikam Existing Environment............................................................................... 8

User Distribution .............................................................................................. 10 Fabrikam Messaging Architecture........................................................................ 10 Web Mail......................................................................................................... 13 Mailbox Usage ................................................................................................. 13 Mail Flow ........................................................................................................ 14

Design Goals and Requirements............................................................................ 16 SMTP Mail Delivery ........................................................................................... 16 New E-Mail Naming Standard ............................................................................. 16 Exchange 2000 Requirements ............................................................................ 17 End User and Client Requirements ...................................................................... 20

Planning Phase Wrap-Up...................................................................................... 21 Planning Phase Questionnaire: Determine Your Migration Goals ................................. 22

Chapter 2 Developing............................................................................................ 25 Fabrikam Active Directory Design.......................................................................... 26 Components of the Developing Phase .................................................................... 29 Exchange Architecture......................................................................................... 29

GroupWise−to−Exchange Component Mapping ...................................................... 29 Key Messaging Parameters ................................................................................ 30 Local Archives.................................................................................................. 33 Centralized Administration................................................................................. 34 Internet Access to E-Mail................................................................................... 34 External Entities............................................................................................... 34 Distribution Lists and Personal Distribution Lists ................................................... 35

Exchange 2000 Setup.......................................................................................... 35 Naming Conventions......................................................................................... 35 Exchange 2000 Operation Mode ......................................................................... 42 Exchange 2000 Schema Extensions .................................................................... 42 Exchange 2000 Administrative Group Design........................................................ 43 Exchange Administration Delegation Wizard ......................................................... 45 Exchange 2000 Server Placement ....................................................................... 45

Exchange 2000 Routing Group Design ................................................................. 46 Routing Group Costs......................................................................................... 51 Exchange Server Remote Administration.............................................................. 52 Exchange Storage Group and Storage Design ....................................................... 52 Storage Design ................................................................................................ 55 Exchange Server Hardware Planning ................................................................... 57 Exchange 2000 System Policies .......................................................................... 59 Fabrikam’s Policy Design ................................................................................... 61 Recipient Update Service Design......................................................................... 64 Public Folder Hierarchy Design ........................................................................... 66 Outlook Web Access ......................................................................................... 68 Backup and Recovery........................................................................................ 71 Monitoring....................................................................................................... 71 Management Tools ........................................................................................... 71 Client Access Strategy ...................................................................................... 72 GroupWise-to-Outlook Client Functionality Issues ................................................. 74

GroupWise−to−Exchange 2000 Interoperability Architecture ...................................... 74 GroupWise-to-Exchange Directory Synchronization ............................................... 75 Foreign Domain in the GroupWise System............................................................ 76 GroupWise Connector Operations (Users, Resources, and Distribution Lists Synchronization) .............................................................................................. 76 Distribution Lists Synchronization and Operation................................................... 76 Directory Synchronization Design ....................................................................... 76 Mail Transport.................................................................................................. 77 Web Mail Coexistence Strategy........................................................................... 80 Calendar Transport........................................................................................... 81

GroupWise−to−Exchange 2000 Migration Architecture............................................... 83 Migration Considerations ................................................................................... 85 Migration Logical Overviews............................................................................... 89

Chapter 3 Deploying ............................................................................................. 93 Migration Process Summary ................................................................................. 94 Preparing Active Directory and Installing Exchange 2000 .......................................... 95

Active Directory ............................................................................................... 96 Checklist: Pre-Exchange 2000 Setup ................................................................... 98 Installing Exchange .........................................................................................101 Checklist: Installing Exchange...........................................................................103 Checklist: Configuring the First Exchange Server .................................................106

Preparing Novell Directory Services and GroupWise ................................................107 Novell Directory Services and GroupWise Requirements ........................................108 Install GroupWise API Gateway .........................................................................108 Install Gateway Patch 1 and Patch 2 ..................................................................108 Activate Distribution List Expansion....................................................................108 Create the API Gateway ...................................................................................109 Create an External Foreign Domain....................................................................110 Creating and Configuring Migration Accounts.......................................................111 Create an NTGateway Group in NetWare.............................................................111 Setting the GroupWise Access Mode to Direct Access............................................112 Configuring the GroupWise System: Best Practices...............................................113

Setting Up the GroupWise Connector ....................................................................114

Coexistence Components..................................................................................114 Windows 2000 Coexistence Preparation ..............................................................114 Configuring the GroupWise Connector ................................................................116

Setting Up Exchange 2000 Calendar Connector ......................................................117 Installing Calendar Connector ...........................................................................118 Recipient Policies and Calendar Connector...........................................................118 Replicating Free and Busy Folder to Other Servers ...............................................118 Configuring Calendar Connector ........................................................................119

Configuring the Migration Servers ........................................................................120 Client and Server Software Versions ..................................................................120 Software Installed on Migration Servers..............................................................121 Setting Up the Migration Server.........................................................................121

Nightly Migration Process ....................................................................................122 Lessons Learned .............................................................................................123 Migration Preparation Review ............................................................................124 Checklist: Day of Migration ...............................................................................126 Microsoft Exchange Migration Wizard..................................................................127 Check list: Desktop and Client Migration Tasks ....................................................129 Check list: Post Migration Tasks ........................................................................129

Appendix A Procedures.........................................................................................130 Administrative Groups and Routing Groups Visibility ...............................................130 Exchange Administration Delegation Wizard...........................................................130 Mailbox Size Limits ............................................................................................131 Message Size Limits ...........................................................................................132

Internal Message Size Limits.............................................................................132 External Message Size Limits ............................................................................132

Deleted Items Recovery......................................................................................133 Deleted Items Recovery Period..........................................................................133 Recover a Deleted Mailbox................................................................................133 Recover Deleted Items.....................................................................................133

Message Filtering...............................................................................................134 Set Message Filtering.......................................................................................134 Enable Message Filtering on a Virtual Server .......................................................135

Distribution Lists................................................................................................135 Replies to the Internet........................................................................................136 System Policies .................................................................................................136

Create a System Policy Container ......................................................................137 Create a Server Policy......................................................................................137 Create a Public Store Policy ..............................................................................138 Create a Mailbox Store Policy ............................................................................139

Recipient Policies ...............................................................................................140 How Fabrikam Created and Configured Its E-Mail Address Recipient Policies.............141 Create a Mailbox Recipient Policy (Mailbox Manager) ............................................143

Recipient Update Service ....................................................................................144 Routing Groups .................................................................................................145 Routing Group Connectors ..................................................................................146 SMTP Connectors...............................................................................................147

SMTP Connector for Executive Group..................................................................148

Public Folders....................................................................................................148 Configure Public Folder Permissions ...................................................................149 Configure Public Folder Replication.....................................................................149

Transaction Logs ...............................................................................................150 Databases ........................................................................................................150 Log Buffers .......................................................................................................151 Outlook Web Access...........................................................................................151

Configure the Server As a Front-End Server ........................................................151 Set the Default Domain Name...........................................................................152 Reroute Users to a Secure Connection ................................................................153 Install Digital Certificates for SSL Security ..........................................................153 Multimedia Outlook Web Access ........................................................................154

Appendix B Exchange Installation Checklists............................................................155 Medium Office Mailbox Server..............................................................................155 Small Office Mailbox Server.................................................................................157 Bridgehead Server .............................................................................................160 Outlook Web Access Server.................................................................................163

Appendix C Migration Flowchart.............................................................................166

Appendix D Additional Resources ...........................................................................168 Microsoft Knowledge Base Articles........................................................................168 Technical Papers and Other Web Sites ..................................................................169

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration

Published: January 2002

For the latest information, please see http://www.microsoft.com/exchange/.

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 Q296614, “XADM: Differences Between Exchange 2000 Standard and Enterprise,” at http://go.microsoft.com/fwlink/?LinkId=3052&ID=296614.

http://go.microsoft.com/fwlink/?LinkId=3052&ID=296614

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 2

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 http://go.microsoft.com/fwlink/?LinkId=3913

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

Release Vision/Scope Approved

Deployment Complete

Project Plan Approved

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


http://go.microsoft.com/fwlink/?LinkId=3913


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



January February March April May

Envisioning and Planning

Developing

Testing

Production setup

Pilot rollout

Deployment

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

Number of external entities1 per server

Number of distribution lists

Richmond (Willoughby, Drago, and Fisk2)

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:

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


Gateway usage Number of sent messages per day

Number of received messages per day


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 441,616 8238.8 381 21.6

Location Number of client-to-server

connection attempts per day

Number of messages per

day

Number of users Number of daily messages per

user


(Drago)

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 [email protected]. The company wants to change this format to first name.last [email protected] (for example, [email protected]). If two people have the same name, the standard will be first name.middle initial.last [email protected].

However, when Exchange is implemented, e-mail addressed to the current e-mail address ([email protected]) must be correctly routed to the correct Exchange mailbox, which will be using the new e-mail address ([email protected]).

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?

Question Response


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?

Question Response


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 Q197132, “Windows 2000 Active Directory FSMO Roles,” in the Microsoft Knowledge Base at http://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.

http://go.microsoft.com/fwlink/?LinkId=3052&ID=197132

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

Feature Existing component New component


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

microsoft exchange 2000 and novell groupwise coexistence...

Documents