microsoft exchange 2000 and novell groupwise coexistence and migration

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration

Published: January 2002

Table of ContentsIntroduction ............................................................................................................ 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 ......................................................................................... GroupWisetoExchange Component Mapping ...................................................... Key Messaging Parameters ................................................................................ Local Archives.................................................................................................. Centralized Administration ................................................................................. Internet Access to E-Mail ................................................................................... External Entities............................................................................................... Distribution Lists and Personal Distribution Lists ................................................... Exchange 2000 Setup.......................................................................................... Naming Conventions......................................................................................... Exchange 2000 Operation Mode ......................................................................... Exchange 2000 Schema Extensions .................................................................... Exchange 2000 Administrative Group Design........................................................ Exchange Administration Delegation Wizard ......................................................... Exchange 2000 Server Placement ....................................................................... 29 29 30 33 34 34 34 35 35 35 42 42 43 45 45

Exchange 2000 Routing Group Design ................................................................. Routing Group Costs ......................................................................................... Exchange Server Remote Administration.............................................................. Exchange Storage Group and Storage Design ....................................................... Storage Design ................................................................................................ Exchange Server Hardware Planning ................................................................... Exchange 2000 System Policies .......................................................................... Fabrikams Policy Design ................................................................................... Recipient Update Service Design......................................................................... Public Folder Hierarchy Design ........................................................................... Outlook Web Access ......................................................................................... Backup and Recovery........................................................................................ Monitoring....................................................................................................... Management Tools ........................................................................................... Client Access Strategy ...................................................................................... GroupWise-to-Outlook Client Functionality Issues ................................................. GroupWisetoExchange 2000 Interoperability Architecture ...................................... GroupWise-to-Exchange Directory Synchronization ............................................... Foreign Domain in the GroupWise System............................................................ GroupWise Connector Operations (Users, Resources, and Distribution Lists Synchronization) .............................................................................................. Distribution Lists Synchronization and Operation................................................... Directory Synchronization Design ....................................................................... Mail Transport.................................................................................................. Web Mail Coexistence Strategy........................................................................... Calendar Transport ........................................................................................... GroupWisetoExchange 2000 Migration Architecture............................................... Migration Considerations ................................................................................... Migration Logical Overviews ............................................................................... Chapter 3

46 51 52 52 55 57 59 61 64 66 68 71 71 71 72 74 74 75 76 76 76 76 77 80 81 83 85 89

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 Appendix D Migration Flowchart .............................................................................166 Additional Resources ...........................................................................168

Microsoft Knowledge Base Articles........................................................................168 Technical Papers and Other Web Sites ..................................................................169

Microsoft Exchange 2000 and Novell GroupWise Coexistence and MigrationPublished: January 2002For the latest information, please see http://www.microsoft.com/exchange/.

IntroductionThis 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 GroupWisetoExchange 2000 migrations performed by Microsoft Consulting Services (MCS), and all data comes from MCS Exchange 2000 deployments. Use Fabrikams 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 PaperThis 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 GroupWisetoExchange 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.

Deploying Windows 2000 Server and Active DirectoryA separate Microsoft Windows 2000 Server team designed Fabrikams Active Directory. After designing Fabrikams 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 OverviewThe 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 Fabrikams 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


2

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).Deployment Complete

Release

Vision/Scope Approved

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 teams 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 Fabrikams business


3

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


4

Chapter 1

Planning

This chapter describes Fabrikams 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 overviewTasks 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. Key deliverables 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).

Resources Project vision Requirements Existing documentation (network, GroupWise, Novell Directory Services, Microsoft Windows NT)

Capture Fabrikams vision and requirements in a functional specification document. Perform risk assessment. Create high-level project plan.

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


5

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 Fabrikams 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 TeamFabrikam 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 leadsPerson Alan Steiner, Director of IS Kim Ralls, Manager of IS Suzan Fine, Mail Administrator Adam Barr, Network Administrator Raymond K. Sam, Manager of User Training Florian Voss, Administrative Assistant

Team role Product management Program management Development Testing User advocate Logistics

Time LineAfter 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 Fabrikams messaging system, the team produced the time line shown in Figure 1.1.


6

January Envisioning and Planning Developing Testing Production setup Pilot rollout Deployment

February

March

April

May

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 PlanA 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 Fabrikams risk management plan.


7

Table 1.3Risk

The Fabrikam risk management assessmentRisk impact (1-5) 3 Risk probability (0-100%) 80% Risk score (risk impact risk probability) 2.4 Risk mitigation

Team members are not trained on Exchange 2000. Network links are heavily used.

Send team members to training. Monitor the network use of links. Evaluate costs of adding to link capacity.

3

80%

2.4

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 teams 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 EnvironmentFabrikam has several branch offices connected by a number of WAN links. The companys 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.


8

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


9

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 FabrikamNumber of active users (does not include external entities1) 845 Number of external entities1 per server Number of distribution lists

Location (server name)

Richmond (Willoughby, Drago, and Fisk2) Alexandria (Wise) Braintree (Evans) Chicago (Lynn) Munich (Carbo) Chapel Hill (Doyle) Total1

Willoughby: 95 + Drago: 49 = Total: 144 10 15 5 4 1 179

125

77 119 15 26 5 1,087

12 25 7 5 2 176

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 Fabrikams Internet mail gateway and does not house any mailboxes. Fisk also holds a GroupWise API gateway that interfaces to the companys fax system and Novells 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.


10

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


11

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.


12

Fabrikam Worldwide, Inc. has the following MX records defined in DNS: Fabrikamworldwide.com Fabrikamworldwide.com IN MX 10 IN MX 20 fisk.fabrikam.com 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 Fabrikams 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.


13

Figure 1.4 Mail Flow

Mailbox usage

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 Fabrikams system administrators, informing them of system status messages. Table 1.5 illustrates average daily usage for Fabrikams Internet gateway. Table 1.5 Internet gateway usageNumber of sent messages per day 0 Number of received messages per day 50

Gateway usage API (for faxes)


14

Gateway usage Pager (third-party pager product) GWIA (messages)

Number of sent messages per day 33.2 3282

Number of received messages per day 0 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 trafficNumber of messages sent through MTA 15200 2789.2 1478.8 667 40.6 55.8 Number of users 845 119 77 15 2 26 Number of messages routed per user 17.99 23.44 19.20 44.46 20.3 2.15

Location of MTA Richmond Braintree Alexandria Chicago Chapel Hill Munich

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

GroupWise post offices by locationNumber of client-to-server connection attempts per day 0 441,616 0 8238.8 Number of messages per day Number of users Number of daily messages per user 0 21.6

Richmond (Willoughby) Richmond

464 381


15

Location

Number of client-to-server connection attempts per day 122,954 102838 1318 985 23706

Number of messages per day

Number of users

Number of daily messages per user

(Drago) Braintree Alexandria Chicago Chapel Hill Munich 3311.6 1633.3 658.4 27.6 639.2 119 77 15 2 26 28.8 21.2 43.9 13.8 24.6

Design Goals and RequirementsIn 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 Fabrikams 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 companys e-mail naming standard. For example, Alan Steiners 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


16

the GroupWise and Exchange coexistence period. Fabrikams 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 Fabrikams 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, Fabrikams 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 users mailbox to the new users 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.


17

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 messagesmessages that are sent and received through the Exchange SMTP connectorcannot 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 Fabrikams 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.


18

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 recreate their current distribution list design (as shown in Figure 1.5).


19

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


20

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 Fabrikams 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 Fabrikams 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-UpAfter capturing all of the information about Fabrikams 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


21

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: Fabrikams vision for the new architecture. Fabrikams business and technical requirements for the new system. Fabrikams existing technical architecture including any planned changes. Fabrikams project plan and schedule.

Risk management process started.

Planning Phase Questionnaire: Determine Your Migration GoalsUse 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.81

Planning phase questionnaireQuestion Response

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?


22

Question 4 What is the average daily usage of the Web-based e-mail access? What should the URL of the new Webbased e-mail system be? 5 6 7 What DNS MX entries are entered for your company? What are the mail gateways used by your company? How many of the following you do have: 8 User accounts External entities Group calendars Distribution lists

Response

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 users email? 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)? What, if any, should be the deleted item recovery period? What, if any, should be the deleted mailbox recovery period? What are the message size limits allowed through your Internet mail gateway? For inbound messages? For outbound messages? Between remote locations?

12 13 14

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?


23

Question 16 Do you have PDAs in use at your company? 17 18 19 20 What type of PDA is used? What software package is used to synchronize the PDA with GroupWise? Does this software package work with Exchange?

Response

Are conference rooms scheduled through GroupWise? Do you have any antivirus requirements? Are you using the GroupWise Pager gateway? What backup tool are you currently using? Does it have an Exchange backup agent?


24

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 Fabrikams messaging requirements and the methodology behind all of Fabrikams 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 ExchangetoGroupWise 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.


25

Table 2.1

Developing phase overviewTasks Translate vision, business, and technical requirements into system design. Design Exchange architecture to meet technical requirements. Design GroupWisetoExchange coexistence architecture. Design GroupWisetoExchange migration architecture. Order production hardware. Develop test plan. Develop test lab to mimic production environment. Test Exchange architecture, ExchangetoGroupWise coexistence architecture, and ExchangetoGroupWise 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. Key deliverables 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).

Resources Functional specification document Migration team Risk management plan Project plan

Fabrikam Active Directory DesignAlthough this paper focuses on Fabrikams 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.


26

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


27

Figure 2.1

Logical design of Fabrikams 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 Fabrikams 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


28

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

Components of the Developing PhaseThe 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. GroupWisetoExchange 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. GroupWisetoExchange 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 ArchitectureFabrikam 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. GroupWisetoExchange 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.2Mailbox server Web access to e-mail Fax gateway Pager gateway SMTP gateway Mail client

Component overviewExisting component GroupWise 5.5 Server GroupWise WebAccess Third-party program Novell Pager Gateway GroupWise Internet Agent (GWIA) GroupWise client New component Exchange 2000 Server Microsoft Outlook Web Access Exchange 2000 certified third-party program Exchange 2000 certified third-party program Exchange 2000 SMTP connector Outlook 2000

Feature


29

Feature Mail antivirus None

Existing component

New component Exchange 2000 certified third-party virus protection program Exchange 2000 certified third-party program

Backup and restore

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 Fabrikams 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 users mailbox size limitthe 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.


30

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 Fabrikams deleted items recovery periodsDuration of recovery period and action when period expires 45 days, after which time, move mailbox items to clients Deleted Items folder. 7 days, after which time, remove the items from the Deleted Items folder. 3 days, after which time, the user cannot recover the item. At this point, administrators must recover these items for users from backup tape. 55 days

Type of recovery period Server: Mail retention Server: Deleted Items folder cleanup Client: Deleted Items recovery

Total

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


31

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


32

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 companys 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 nonworking 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 Fabrikams message size limitsLimit 25 MB, with messages larger than 10 MB delivered during nonworking hours

Type of size limit Messages sent internally

Messages sent externally (outside 5 MB the firewall) Executive teams 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 thirdparty 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.


33

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: http://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 Fabrikams case, one of the companys 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.


34

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 companywide 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 Fabrikams 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 SetupThe 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 administrat

microsoft exchange 2000 and novell groupwise coexistence and migration

Documents