You are on page 1of 174

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 4


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 • Conduct discovery sessions on • Functional specification
business and technical document prepared.
• Requirements
requirements.
• Migration team with
• Existing documentation
• Analyze existing network team leads briefed on
(network, GroupWise, Novell
usage. requirements.
Directory Services,
Microsoft® Windows NT®) • Analyze existing e-mail usage • High-level risk
on servers and across the assessment plan
entire network. prepared.
• Form the migration team. • Project plan prepared.
• Capture Fabrikam’s vision and • Fabrikam management
requirements in a functional gives approval to
specification document. proceed to developing
phase (Chapter 2).
• 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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 6


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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 7


Table 1.3 The Fabrikam risk management assessment
Risk Risk impact Risk probability Risk score Risk mitigation
(1-5) (0-100%) (risk impact ×
risk probability)
Team members 3 80% 2.4 Send team
are not trained members to
on training.
Exchange 2000.
Network links are 3 80% 2.4 Monitor the
heavily used. 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 Fabrikam


Location Number of active Number of external Number of
(server name) users entities1 per server distribution lists
(does not include
external entities1)
Richmond 845 Willoughby: 95 + 125
(Willoughby, Drago, Drago: 49 = Total: 144
and Fisk2)
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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 12


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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 13


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 Number of received messages
day per day
API (for faxes) 0 50

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 14


Gateway usage Number of sent messages per Number of received messages
day per day
Pager (third-party pager 33.2 0
product)
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 Number of users Number of messages
sent through MTA 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 Number of Number of users Number of daily
client-to-server messages per messages per
connection day user
attempts per day
Richmond 0 0 464 0
(Willoughby)
Richmond 441,616 8238.8 381 21.6

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 15


Location Number of Number of Number of users Number of daily
client-to-server messages per messages per
connection day user
attempts per day
(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
asteiner@fabrikamworldwide.com. The company wants to change this format to first
name.last name@fabrikam.com (for example, Alan.Steiner@fabrikam.com). If two
people have the same name, the standard will be first name.middle initial.last
name@fabrikam.com.

However, when Exchange is implemented, e-mail addressed to the current e-mail


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

Fabrikam management wanted to change the domain name of its e-mail from
fabrikamworldwide.com to fabrikam.com. Whether you want to keep your existing
domain name or change it significantly affects how you set up mail routing during

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 16


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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 re-
create their current distribution list design (as shown in Figure 1.5).

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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:


• 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?

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 22


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?

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 23


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?

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 25


Table 2.1 Developing phase overview
Resources Tasks Key deliverables
• Functional specification • Translate vision, business, and • Logical design
document technical requirements into specification document
system design. and detailed design
• Migration team
specification document.
• Design Exchange architecture
• Risk management plan
to meet technical • Test plan completed.
• Project plan requirements.
• Test lab containing all
• Design system components
GroupWise−to−Exchange built.
coexistence architecture. • Risk assessment
• Design updated.
GroupWise−to−Exchange • End-user training plan
migration architecture. and materials prepared.
• Order production hardware. • Deployment plan and
• Develop test plan. migration checklists
prepared.
• Develop test lab to mimic
production environment. • Help desk support team
trained to support
• Test Exchange architecture,
Microsoft Outlook®
Exchange−to−GroupWise
users.
coexistence architecture, and
Exchange−to−GroupWise • Administrators trained to
migration architecture. support Exchange.
Develop working prototype • Production hardware
system. acquired.
• Update and manage risk • Communication plan sent
assessment. to end-users.
• Update project plan. • Fabrikam management
• Develop end-user training gives approval to
plan. Identify resources proceed to deploying
(classrooms, computers, and phase (Chapter 3).
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.

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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 27


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 28


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 29


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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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 7 days, after which time, remove the items from the Deleted Items
cleanup 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 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 5 MB
the firewall)
Executive team’s external 10 MB
messages

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.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 Fabrikam’s case, one of the company’s migration goals was
to change its corporate identity from Fabrikam Worldwide (with the domain name
fabrikamworldwide.com) to Fabrikam (fabrikam.com), so this change to
accommodate Outlook Web Access was easy.

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 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 company-
wide distribution list. Restricting who could send e-mail would also prevent “mail
storms” (when the network is flooded by unnecessary e-mail) caused by users
replying to company-wide distribution lists. For more information about restricting
who can send e-mail to a distribution list, see “Distribution Lists” in Appendix A.

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

Exchange 2000 Setup

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

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

Restricted Characters

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

Note This information is also available in the Exchange 2000 release


notes. Microsoft recommends reading the release notes for Exchange 2000
and all subsequent service packs to ensure that these standards have not
changed.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 35


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

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

If you are upgrading to Exchange 2000 and have an organization name or


Exchange 5.5 site name that contains any of the characters in Table 2.5, you must
change the display name of the affected object before you run Exchange 2000
Setup.

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

• Policies

• Address lists

• Offline address lists

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 36


• Routing groups

• Storage groups

• Mailbox stores

• Public folder stores

• SMTP and X.400 connectors

• Public folder hierarchies

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

Organization Naming Standard

The organization name is the top-level Exchange object in Active Directory.


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

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

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

• The organization name is case-sensitive.

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

Administrative Group Naming Standard

In Exchange 2000, an administrative group is a collection of Active Directory objects


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

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

Routing Group Naming Standard

Routing group names should be unique and named by geographic or physical


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

Routing Group Connector Naming Standard

To communicate with one another, Exchange routing groups must be connected by


one of several types of routing group connectors. You can use a maximum of 64

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 37


characters for routing group connector names (avoid the characters in Table 2.5).
Fabrikam decided the name of each routing group connector will consist of the
starting and ending locations of the routing group connector. The resulting standard
was Location-Location RGC. For example, the routing group connector between
Richmond and Alexandria was named RI-AL RGC.

Server Naming Standard

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

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

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

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

Function-LocationSeqStatus

• Function Designates the function of the server. The most common uses at
Fabrikam are:
• MSG = Exchange mailbox servers
• MSGBRDG = Exchange bridgehead servers
• MSGWEB = Exchange front-end server (at Fabrikam, used primarily for
Outlook Web Access)
• DC = domain controller

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

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 38


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

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

• MSG-RI01P

• MSG-RI02P

• MSGOWA-RI01P

• MSGBRDG-RI01P

• DC-RI01P

• DC-RI02P

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

• MSG-AL01P

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

User Account

Each user account needs to have the following fields defined:

• First name

• Initials

• Last name

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

• User logon name

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 39


Figure 2.4 User naming conventions

User Internet E-Mail Standards

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

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

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

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

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

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 40


Exchange 2000 Conference Room Naming Convention

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

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

For example, a conference room named CRRI2143 is located in room 2143 in


Richmond. In Active Directory, administrators created a new user and filled in the
fields as follows:

• First name Piedmont

• Last name Conference Room Richmond

• User logon name CRRI2143

Distribution Group Naming Convention

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

All Fabrikam distribution lists will be re-created in Exchange according to the


following naming convention:

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

• Names will be limited to 50 characters.

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

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

By choosing to use global groups, however, Fabrikam had to take extra care to
ensure that Exchange would use the correct global catalog servers for distribution
list expansion. If Exchange uses an incorrect global catalog server for distribution
list expansion, the distribution list may not expand, and users on the distribution list
would not receive the message. Because of this concern, the migration team

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 41


decided to place the Exchange servers in a Windows 2000 subnet separate from the
forest root domain and any other future domains.

Additional Naming Standards

Table 2.7 lists the remaining naming standards adopted by Fabrikam.

Table 2.7 Additional naming standards


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

Exchange Server Drive Letter

For the purposes of clarity and consistency, Microsoft Consulting Services


recommends that the drives on all computers running Exchange in your organization
be labeled the same.

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

Exchange 2000 Operation Mode


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

Because no Exchange 5.5 servers exist at Fabrikam, the migration team


recommended that the servers running Exchange 2000 be switched to native mode
as soon as possible during the migration.

Exchange 2000 Schema Extensions


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

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

• Be a member of the Windows 2000 Schema Admins group and Enterprise


Admins group. Only Schema Admins members have the necessary permissions
to be able to modify the Active Directory.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 42


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

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

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

Exchange 2000 Domain Preparation

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

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

• Creates the Exchange Domain Servers global security group.

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

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

• Grants appropriate rights to the address list server.

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

Exchange 2000 Administrative Group Design


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

On reason you may have multiple administrative groups would be if your


organization has multiple sets of mail administrators, each of whom manage a
certain set of mail servers. In this scenario, a group of administrators do not want

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 43


other groups to be able to manage the first group’s servers. You can solve this
problem by creating an administrative group for each set of mail administrators.

Important Unlike routing groups, you cannot move Exchange servers


between administrative groups.

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

• Policy management to be centralized The Richmond administrative group


will be responsible for policies that enforce standard configuration for Exchange
servers across the entire organization.

• Secondary administrators to be located in Braintree There are


administrators in Braintree who will be able to perform some basic day-to-day
administrative tasks.

• No mail administrators located at other sites No mail administrators will


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

• Richmond administrators to provide limited on-site support The mail


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

Because of these goals, the Fabrikam migration team recommended a single


Exchange administrative group. The name of the administrative group will be the
default name, First Administrative Group. Figure 2.5 represents the centralized
administrative design for Fabrikam.

Figure 2.5 Fabrikam’s administrative group design

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 44


Figure 2.6 Fabrikam’s administrative group design in Exchange System Manager

Exchange Administration Delegation Wizard


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

So that network administrators at the branch offices can perform basic


administrative messaging tasks, Fabrikam will delegate permissions to certain users
within the administrative group. Fabrikam chose to configure these permissions by
using Exchange Administration Delegation Wizard . For more information about
using this wizard, see “Exchange Administration Delegation Wizard” in Appendix A.

Exchange 2000 Server Placement


The Fabrikam migration team considered several options both how many servers
running Exchange to use and where to place the servers in the Fabrikam
organization. Fabrikam wanted to place servers running Exchange 2000 in each of
its major branch offices because of the need for each location to continue operating

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 45


even if the WAN links connecting the offices became unavailable. To meet this need,
a distributed Exchange server design is necessary.

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

• Richmond

• Alexandria

• Chicago

• Braintree

• Munich

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

Exchange 2000 Routing Group Design


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

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

Note In all of the following diagrams, proposed routing group connectors


are named according to standards discussed in the “Naming Conventions”
section earlier in this chapter.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 46


Routing Group Design 1

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

Figure 2.7 Proposed routing group design 1

Proposed routing group 1 contains:

• 5 routing groups

• 4 routing group connectors

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 47


Routing Group Design 2

If bandwidth usage between Richmond and Alexandria is sufficient, both locations


could be placed in the same routing group, creating the routing group design shown
in Figure 2.8.

Figure 2.8 Proposed routing group design 2

Proposed routing group design 2 contains:

• 4 routing groups

• 3 routing group connectors

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 48


Routing Group Design 3

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

Figure 2.9 Proposed routing group design 3

Proposed routing group design 3 contains:

• 5 routing groups

• 6 routing group connectors

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 49


Routing Group Design 4

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

Figure 2.10 Proposed routing group design 4

Proposed routing group design 4 contains:

• 5 routing groups

• 7 routing group connectors

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 50


Routing Group Design 5

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

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

Proposed routing group design 5 contains:

• 5 routing groups

• 5 routing group connectors

Routing Group Costs


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

Table 2.8 Fabrikam routing group connector costs


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 51


Routing group connector Cost
AL-BR RGC (Alexandria-Braintree) 30

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

Similarly, a message sent from Alexandria to Braintree travels through Richmond


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

Exchange Server Remote Administration


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

• Windows 2000 Terminal Services Terminal services will be loaded on each


server running Exchange. Using Terminal Services allows administrators to log
on and remotely administer the server running Exchange.

• Exchange System Manager Microsoft Management Console


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

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

Exchange Storage Group and Storage Design


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

Exchange 2000 allows administrators to create multiple databases on each server.


When you divide your mailbox store and public folder store databases into smaller,
multiple databases, you can manipulate, back up, and restore the databases more
efficiently.

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 52


databases. Within a storage group, every database shares the same transaction log
and writes to a single transaction log.

Note In designing your storage groups, remember that every storage


group requires additional CPU processing power and memory. In addition,
it is recommended that a dedicated set of drives be allocated for each
storage group for the storage group’s transaction log files.

Microsoft Consulting Services recommends reserving one database for


troubleshooting operations. Fabrikam used a maximum of five databases in each
storage group for messaging and data storage.

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

Figure 2.12 Exchange 2000 Server storage architecture

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 53


Storage Group Design

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

• Store Policies

• Usage factors

• Physical disk configuration

• Backup and Restore Service Level Agreements

• Virtual memory usage

• Clustering

• Parallel backup and restore

Store Policies

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

Usage Factors

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

Physical Disk Configuration

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

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

Backup and Restore Service Level Requirements

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

Administrators need to know the backup and restore speeds of their backup
solution. Currently, a good guideline for how long it should take to back up storage

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 54


groups to digital linear tape is 20 GB to 30 GB per hour for a locally attached hard
drive and 10 GB to 20 GB per hour for network backup over a dedicated 100 Mbps
switched LAN connection. Typically, it takes twice as long to restore a backup as it
takes to create the backup.

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

Virtual memory usage

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

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

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

Clustering

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

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

100% - (100% ÷ n)

where n is the number of nodes in the cluster.

Parallel backup and restore

It is possible to back up individual storage groups in parallel, but the backup


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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 55


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

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

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

• Do not implement parallel backup and restore of files.

• Maximize single-instance storage space savings.

• Put only one storage group on each server.

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

• Put a public folder store on every mailbox server.

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

• Set the deleted item retention to 7 days.

• Set the deleted mailbox retention to 30 days.

• Recover any single database in four hours or less.

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

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

Exchange 2000 Public Folder Store

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

Storage Design Principals

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

• Maximum downtime equals 2 hours. (Administrators have 4 hours to restore an


Exchange database, but it takes 2 of those hours to locate a tape, find server
software, and load the tape).

• The 2 hours maximum downtime (calculated above) multiplied by the 10 GB per


hour restore speed (2 x 10) means 20 GB maximum can be restored.

• 20 GB ÷ 125 MB maximum mailbox size = 160 mailboxes (or users) maximum in


each mailbox store.

Design Results

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 56


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

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

Exchange Server Hardware Planning


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

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

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

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

• Outlook Web Access server A front-end server dedicated to receiving HTTP


requests from Outlook Web Access clients.

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

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

Mailbox Server for Large Offices (over 100 Mailboxes)

• Server class computer with redundant power and cooling

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

• 2 GB RAM

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


System

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


Exchange logs

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 57


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

Mailbox Server for Medium Offices (40 to 100 Mailboxes)

• Server class computer with redundant power and cooling

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

• 2 GB RAM

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

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


Exchange logs

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


Exchange database

Mailbox Server for Small Offices (up to 40 mailboxes)

• Server class computer with redundant power and cooling

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

• 1 GB RAM

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

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


Exchange logs

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


Exchange database

Outlook Web Access Server

• Server class computer with redundant power and cooling

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

• 1 GB RAM

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


System; Outlook Web Access

Gateway/Bridgehead Server

• Server class computer with redundant power and cooling

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

• 1 GB RAM

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


System; Exchange connectors

Important Exchange 2000 requires modification if installed on a server


that has more than 1 GB of physical RAM. For more information, see
Microsoft Knowledge Base article Q266096, “XGEN: Exchange 2000
Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM,”
available at http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 58


SMTP Queue Directory and Message Tracking Logs

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

Exchange Server Drive Letters

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

Table 2.10 Using drives consistently


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

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

Exchange 2000 Server Placement

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

Table 2.11 Server placement at Fabrikam


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

Exchange 2000 System Policies


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 59


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

An administrator creates a policy, defines the settings that policy implements,


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

For the purposes of migration, Microsoft Consulting Services recommends setting


server, public folder, and mailbox policies to every administrative group in your
Exchange organization. Setting these policies ensures configuration consistency
across similar objects, and prevents changes being made that could affect
migration.

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

Policy Types and Tab Descriptions

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

Table 2.12 Tabs available with policy types


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

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

Table 2.13 Tab descriptions


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

Note Full-text indexing indexes every word in a public or private store,


making faster search and retrieval possible without requiring special mail
clients. However, because of the amount of data that can be involved and
the updating required, full-text indexing can also be taxing on your system
resources. For more information about best practices in deploying full-text
indexing in your organization, see the Exchange Up-to-Date article Best

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 60


Practices for Deploying Full-Text Indexing on the Web at
http://go.microsoft.com/fwlink/?LinkId=5223.

Fabrikam’s Policy Design


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

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

Table 2.14 Default server policy settings


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

Message tracking is enabled during migration to help administrators monitor


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

Table 2.15 Default public store policy settings


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 61


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

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

Table 2.16 Default mailbox store policy settings


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

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

Recipient Policies

In Exchange 2000, recipient policies perform two primary functions:

• Assign the default e-mail address assigned to users

• Establish the mailbox manager policies.

At Fabrikam, the migration team developed three recipient policies to generate e-


mail addresses for the various Exchange objects. Table 2.17 summarizes these
recipient policy settings.

Table 2.17 Fabrikam recipient policy settings


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 62


Policy name Objects affected E-mail address
Default Recipient All recipients GWISE: Exchange.FirstAdminGroup.Exchange.%M
Policy SMTP: %m@fabrikam.com <primary>
X.400: <default>

E-mail Address Recipient Policies

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

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

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

• Firstname.lastname@fabrikam.com (for example,


alan.steiner@fabrikam.com) This e-mail format is established by
%g.%s@fabrikam.com. Administrators set this address as the primary SMTP
address.

• loginid@fabrikam.com (for example, alans@fabrikam.com) In Exchange,


you can have multiple SMTP addresses assigned to one user object, and mail
sent to any of these e-mail addresses is delivered to that user’s mailbox.
Fabrikam employees will be able to receive mail sent to their loginid@fabrikam
address, which is similar to their GroupWise e-mail addresses.

• GroupWise (GWISE) address (for example, Exchange.First


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

Fabrikam Contact Recipient Policy

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 63


address for the user because the same SMTP address already existed for the
contact.

Chapter 3, Deploying, describes Exchange Migration Wizard and how it moves


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

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

• Second (and more important), if a GroupWise administrator were to move a


GroupWise account from one post office to another, this move could result in the
GroupWise connector creating multiple Active Directory accounts for the same
GroupWise user.

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

Default Recipient Policy

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

Recipient Update Service Design


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

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

• Applies the recipient policies.

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

1. An administrator connects to a domain controller in Alexandria (DC-AL01P) and


creates an account (Kim Ralls). Recipient Update Service is configured to
communicate with DC-RI01P (a domain controller in Richmond).

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 64


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

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

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

Multiple Recipient Update Services

To avoid possible replication latency issues, the Fabrikam migration team


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

Warning If your company has many recipient policies, implementing


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

Remote Site Recipient Update Service Design

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 65


Figure 2.13 Multiple Recipient Update Services

Mailbox Manager Settings

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

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

To maximize storage space, Fabrikam wants to automatically delete all messages


older than 60 days. For more information about how to set Mailbox Manager to
automatically delete all messages older than a specific age, see “Recipient Policies”
in Appendix A.

Public Folder Hierarchy Design


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 66


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

• Discussion threads This function allows users to post messages to a group of


users with a common interest, such as to a folder called “IT News.”

• Group calendars This function enables departments to have a departmental


calendar.

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

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

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

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

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

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

Free and Busy Information

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

The decision that had to be made was whether or not to replicate the free and busy
public folder in Richmond to the other Exchange servers. Ultimately, the migration
team decided to replicate the free and busy public folder to the Exchange servers at
the locations outside of Richmond to allow users in those offices to query the free
and busy folder locally instead of across the WAN. Querying the folder locally
provides speedier free and busy queries for all users. However, because of

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 67


replication delays, there could be data inconsistencies in the free and busy
information between remote offices. But the migration team decided that, because
most users scheduled meetings only with users at the same location, the replication
risk would not be sufficient enough to deter replicating the free and busy folder.

For more information about Calendar Connector, see the


“GroupWise−to−Exchange 2000 Interoperability Architecture” section later in this
chapter.

Outlook Web Access


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

In previous versions of Exchange, the Information Store managed the databases


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

The following sections discuss the highlights of front-end/back-end architecture, and


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

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


administrators:

• Single namespace The primary advantage of a front-end and back-end server


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

• Offload processing Exchange 2000 servers can be configured to support


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

• Firewalls The front-end server can be positioned as the single point of access
behind an Internet firewall (or in a perimeter network configuration [also known

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 68


as DMZ, demilitarized zone, and screened subnet]). Figure 2.14 displays a
typical firewall deployment in an Outlook Web Access enviornment. Because the
front-end server has no user information on it, an additional layer of security is
provided. In addition, because the front-end server can be configured to
authenticate requests before proxying them, the back-end servers are protected
from denial-of-service attacks.

Front-End Architecture

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

Figure 2.14 Typical Outlook Web Access deployment with firewalls

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

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

Front-End Architecture Sizing

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

Front-End Server Configuration

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

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

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

Important Deleting the databases makes it impossible to make


configuration changes using the IIS administration tools (Internet Services
Manager [ISM]). If there are configuration changes that must be done

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 69


using ISM (for example, configuring SSL encryption), be sure to complete
these steps before removing the databases.

• To set up a front-end server, install the Exchange 2000 server in the


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

• Stop the unused Exchange services on a front-end server. HTTP requires no


Exchange-specific services. However, the Windows HTTP service (World Wide
Web Publishing Service) must be running.

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

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

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

• Enable SSL encryption on the front-end server.

Back-End Server Configuration

Back-end servers have to be in the same domain as their front-end servers. At


Fabrikam (fabrikam.com), this point will not be an issue.

Web Browser Support

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

Accessing Mailbox Through Outlook Web Access

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 70


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

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

• Disable circular logging on the mailbox servers.

• Ensure you use an approved Exchange backup agent to back up the server
running Exchange. For example, Windows 2000 provides the administrative tool
Backup, which is enhanced when Exchange is installed so it can perform
Exchange backups. In Backup, be sure to back up the following:
• The Exchange store
• Microsoft Site Replication Service (only available when you run Site
Replication Service, which is used for Exchange 5.5−to−Exchange 2000
communication).
• System state

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

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

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

In a later project, the migration team is considering implementing Microsoft


Operations Manager (MOM) and its Exchange monitoring agents, or another third-
party Exchange monitoring package.

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

• Windows 2000 Terminal Services Terminal services was installed on each


server running Exchange. This tool allows administrators to log on and remotely
administer the server running Exchange.

• Exchange System Manager Microsoft Management Console


(MMC) System Manager can be installed on any computer running

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 71


Windows 2000 and is used to administer any server running Exchange to which
the administrator has been given necessary permissions.

• Active Directory Users and Computers MMC Users and Computers


administers the domain’s user accounts and mailboxes.

• Exchange Message Tracking Center Message Tracking Center tracks the


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

• MMC Performance console In addition to the above snap-ins, the MMC


Performance console will be used on each server to ensure the Exchange
services are functioning as expected.

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

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

Client Access Strategy


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

Note At the time of Fabrikam’s migration, Outlook 2002 (available in


Microsoft Office XP) had not yet been released.

Table 2.18 Clients for Exchange 2000


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

Outlook 2000

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

Outlook Profile Generation

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 72


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

Figure 2.15 Creating Outlook profiles with a CNAME record

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

Outlook 2000 (for offline use)

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 73


Outlook Web Access

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

PDA Interoperability Plan

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

GroupWise-to-Outlook Client Functionality Issues


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

Outlook 2000

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

• The ability to schedule a meeting by choosing a date

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

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

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

GroupWise−to−Exchange 2000 Interoperability Architecture

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

When it comes time to migrate GroupWise data to your Exchange messaging


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 74


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

Note This section describes Fabrikam’s coexistence plan. The


configuration details are covered in the next phase of the migration,
deploying (Chapter 3).

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


architecture.

• Directory Synchronization of the user objects and distribution


lists Exchange 2000 GroupWise Connector (the GroupWise connector) provides
this function.

• Mail Transport and meeting requests between GroupWise and


Exchange The GroupWise connector provides this function.

• Free and Busy schedule checking Exchange 2000 Calendar Connector


provides this function. Calendar Connector allows users on either system to see
the free and busy schedule of users when they schedule a meeting.

GroupWise-to-Exchange Directory Synchronization


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

• Organizational unit An organizational unit in Active Directory holds contact


objects for the users on GroupWise. These contact objects in this organizational
unit allow Exchange users to send e-mail to users on GroupWise.

• Foreign domain A foreign domain in GroupWise holds mail-enabled Active


Directory objects as foreign objects in GroupWise. The contact objects in this
foreign domain allow GroupWise users to send e-mail to users on Exchange.

• GroupWise connector The GroupWise connector performs the actual


directory synchronization.

• GroupWise API gateway GroupWise API gateway interfaces with the


GroupWise connector.

As a first step in coexistence, administrators created an organizational unit called


GroupWise Users in Active Directory. This organizational unit contained Active
Directory contact objects that represented existing GroupWise users, distribution
lists, and resource objects that had not yet been migrated.

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 75


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

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

GroupWise Connector Operations (Users, Resources, and Distribution Lists


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

Distribution Lists Synchronization and Operation


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

Meanwhile, distribution lists on Exchange were replicated by the GroupWise


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

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

Note GroupWise external foreign user accounts that are system-visible


and belong to foreign domains and post offices should also be synchronized
with Active Directory as contacts. (Fabrikam had no foreign users.)

Directory Synchronization Design


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 76


Figure 2.16 Directory synchronization between GroupWise and Exchange 2000

GroupWise Directory Synchronization Schedule

Administrators scheduled the directory synchronization between GroupWise and


Exchange 2000 to run all the time.

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

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

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

DNS Modifications

Internally, Fabrikam had the following records defined in DNS for the mail
exchanger (MX) records (as previously mentioned in Chapter 1, Planning).
fabrikamworldwide.com IN MX 10 fisk.fabrikamworldwide.com
fabrikamworldwide.com IN MX 20 willoughby.fabrikamworldwide.com

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 77


For e-mail coexistence, the following MX records needed to be added to account for
MSGBRDG-RI01P and MSGBRDG-RI02P, the new Exchange 2000 bridgehead servers
in Richmond:
fabrikam.com IN MX 10 E2kSmtp1
fabrikam.com IN MX 20 E2kSmtp2
E2kSMTP1 CNAME MSGBRDG-RI01P.Fabrikam.com
E2kSMTP2 CNAME MSGBRDG-RI02P.Fabrikam.com
MSGBRDG-RI01P.Fabrikam.com A 172.19.75.7
MSGBRDG-RI02P.Fabrikam.com A 172.19.75.8

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

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

After Migration Is Completed

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

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


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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 78


Figure 2.17 SMTP coexistence between GroupWise and Exchange 2000

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

Mail bound for @fabrikamworldwide.com enters through the GroupWise Internet


Agent server in Richmond. Then, GroupWise routes the mail internally.

It was inevitable that mail addressed to the GroupWise domain


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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 79


Fabrikam Users’ E-mail Addresses

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

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

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

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

• GWISE: FirstAdministrativeGroup.Exchange.loginid

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

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

Web Mail Coexistence Strategy


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

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

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 80


Figure 2.18 Web mail coexistence strategy

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

Without Calendar Connector, users on GroupWise or Exchange can send meeting


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

Calendar Connector allows users on GroupWise or Exchange to do a free and busy


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 81


How Free and Busy Requests from GroupWise to Exchange 2000 Work

When a GroupWise user attempts to schedule a meeting, the GroupWise client


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

Figure 2.19 shows Fabrikam’s calendar coexistence architecture.

Figure 2.19 Calendar Connector between GroupWise and Exchange 2000

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 82


Figure 2.20 Exchange 2000 Calendar Connector

How Free and Busy Requests from Exchange 2000 to GroupWise Work

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

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

GroupWise−to−Exchange 2000 Migration Architecture

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

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

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

Note To migrate local archives, users must converts their local archives
back to standard mail data and put it back on the GroupWise server.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 83


Fabrikam allowed only executives and employees with specific permission
to migrate local archives.

Exchange Migration Wizard migrates accounts on an account-by-account basis,


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

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

Table 2.19 Migration objects


Exchange 2000 GroupWise feature GroupWise to Exchange 2000 Alternative
feature Exchange 2000 to GroupWise migration
method
E-mail messages E-mail messages Yes Yes Not applicable
E-mail Read receipt E-mail Read receipt Yes Yes Not applicable
E-mail Read receipt E-mail Read receipt Yes Yes Not applicable
Non-Delivery report Non-Delivery report Yes Yes Not applicable
Importance Importance Yes Yes Not applicable
Sensitivity Sensitivity Yes Yes Not applicable
Meeting Requests Appointments Yes Yes Not applicable
Meeting Accepted Meeting Accepted Yes Yes Not applicable
Meeting Declined Meeting Declined Yes Yes Not applicable
Meeting Tentatively Meeting Accepted Appear as Appear as Not applicable
Accepted “Accepted” “Accepted”
Meeting Request Read Meeting Request Read Yes Yes Not applicable
Meeting Request Meeting Request delivery Yes Yes Not applicable
delivery
Meeting Updates Meeting Updates Appear as new Appear as new Not applicable
meeting requests meeting requests
containing the containing the
word “Updated” word “Updated”
in the subject line in the subject line
Meeting Reminder Meeting Reminder times No No Not applicable
times
Meeting Cancellation Meeting Cancellation No Yes Not applicable
Task Requests Tasks Task requests Tasks appear as Not applicable
appear as e-mail e-mail messages
messages
All Day Meeting Notes All day meeting Notes appear as Not applicable
Requests requests appear e-mail messages
as notes with date and
subject in the
message
Outlook does not have Phone Messages Appear as e-mail Not applicable Not applicable
a phone messages messages
data type
Other Messages Other Messages Default to e-mail Default to e-mail Not applicable
messages messages

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 84


Exchange 2000 GroupWise feature GroupWise to Exchange 2000 Alternative
feature Exchange 2000 to GroupWise migration
method
Outlook (.pst) files GroupWise local archives Not migrated by Not migrated by Need to be
migration tool migration tool unarchived
back to the
server (see
notes below).
Outlook Contact User/Personal Address Not migrated by Not migrated by User must
folders Books migration tool migration tool export to a
*.nab file.
Fabrikam
created a
conversion
script and
imported the
data into
Outlook.
Global Address List Novell GroupWise Address Synchronized by Synchronized by Not applicable
Book GroupWise GroupWise
connector connector
Distribution lists in Personal Groups Not migrated by Not migrated by User must re-
Outlook Contacts (distribution lists) migration tool migration tool create in
folder Outlook.
Distribution lists on Public Groups (distribution Not migrated by Not migrated by Administrator
computer running lists) migration tool migration tool must re-create
Exchange after migration.
Granting other users Shared Folders Not migrated by Not migrated by User must re-
permissions to migration tool migration tool create in
Outlook folders Outlook.
Rules Rules Not migrated by Not migrated by User must re-
migration tool migration tool create in
Outlook.
Filters Filters Not migrated by Not migrated by User must re-
migration tool migration tool create in
Outlook.
Delegates Proxies Not Migrated by Not Migrated by Users must re-
Migration Tool Migration Tool establish their
proxies and
delegates after
migration.
Words added to Words added to personal Not migrated by Not migrated by User must re-
personal dictionaries dictionaries migration tool migration tool create in
Outlook.
Exchange mailbox External entity Migrated by Migrated by Not applicable
migration wizard migration wizard

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

Migration Errors During Export

During the mailbox migration process, the Fabrikam team encountered certain
accounts that had difficulty migrating to Exchange. If the issue was encountered
during the GroupWise data export step, many of these migration issues were
resolved by running the GroupWise messaging database repair utility, GroupWise
Check (GWCheck), available from Novell. The Fabrikam migration team found it
sometimes had to run this tool multiple times to repair a user messaging database.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 85


Repairing a user messaging database significantly slowed down the migration
process. The team learned that, if a user account had a problem migrating, it was
best to remove the account from that night’s migration and set it aside to migrate
later. Then, part of the team ran Exchange Migration Wizard with the remaining
accounts while other administrators repaired the problem GroupWise account’s
messaging database.

Expansion of Migrated Mail

Although determining a mailbox size limit was an important Exchange design


decision, equally important are mail migration issues. The following considerations
were presented to the Fabrikam management team:

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

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

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

• GroupWise, like Exchange, uses the concept of single-instance message storage.


Single-instance storage, discussed earlier in this chapter in “Exchange Storage
Group and Storage Design,” is also relevant to mailbox migration because of the
likelihood of mail expansion. For example, if a user sends a message with a 5 MB
attachment to 500 users on the same server, only one copy of the message is
stored in the GroupWise database. However, Exchange Migration Wizard
migrates users one at a time, and single-instance storage is lost during the
migration. Because GroupWise users are likely to be migrated at different
times—and possibly to different Exchange servers—Exchange Migration Wizard

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 86


cannot maintain all of the pointers to a single message. In this example, mail
expansion occurs after migration because there will be 500 messages in the new
Exchange mailbox store, and each message will include its own copy of the 5 MB
attachment, which causes a space usage increase from 5 MB to 2.5 GB
(500 × 5 MB). The amount of overall mail expansion will vary by organization,
based on the number and size of widely-distributed, or “broadcast,” messages
sent to all users. Prior to migration, organizations should do an assessment of
the number of broadcast messages sent and the size of these messages. Then,
using this information, you can calculate an expansion figure to estimate the
required size of hard disks running Exchange.

At Fabrikam, this method predicted a 30 percent increase in mail storage size


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

Personal Address Books Migration

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

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

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

Client Rules

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

Shared Folders

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 87


Proxy Access

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

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

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

At Fabrikam, users (particularly, executives) use the proxy feature extensively. In


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

Personal Dictionaries

Microsoft has no tools to directly migrate personal dictionaries from GroupWise to


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

Public Distribution Lists and Personal Distribution Lists

Microsoft has no tools to directly migrate distribution lists from GroupWise to


Exchange. Fabrikam users must re-create their personal distribution lists in Outlook.

Fabrikam administrators must re-create their server-side distribution lists in Active


Directory. For more information, see “Distribution Lists” in Appendix A.

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

External Entities

The GroupWise directory is separate from Novell Directory Services (NDS).


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 88


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

• Mail and calendar information

• Local archives

• Personal address books

Note The following processes are intended as overview information only.


Configuration specifics are covered in Chapter 3, Deploying.

Mail and Calendar Migration Process

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

Fabrikam used the following process to migrate the mail migration.

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

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

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 89


Figure 2.21 User migration process

Archive Migration Process

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

Fabrikam used the following process to migrate the local archives.

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

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

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

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

5. After migration is complete, the migration team reactivates the automatic


archive functionality on GroupWise.

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 90


Figure 2.22 Local archive migration process

Personal Address Book Migration Process

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

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

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

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

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

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

5. On the user’s workstation, in Outlook, a desktop team member creates folders


for every .nab file. For each folder, in the Create New Folder dialog box, under
Folder contains, the desktop team member selects Contact Items.

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 91


Figure 2.23 Personal address book migration process

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 92


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

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

Note As discussed in Chapter 2, a period of interoperability, or


coexistence, is often necessary during migrations so that users can retain
messaging capability during the period of time it takes to migrate everyone
to the new messaging system (at Fabrikam, 25 to 35 users migrate each
night).

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

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

Table 3.1 Deploying phase overview


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 93


Migration Process Summary

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

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

1. Prepare Active Directory and install Exchange 2000.

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

3. Set up the GroupWise connector.

4. Set up Exchange 2000 Calendar Connector.

5. Configure the migration servers.

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

Important It is worth mentioning again that this white paper assumes


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

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

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

The final step before migration was preparing the migration servers. Fabrikam used
four high-end desktop computers running Windows 2000 Advanced Server. The
migration team installed Exchange System Manager (the primary Exchange 2000

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 94


management tool) and both an NDS client and a GroupWise client on each server.
This configuration allowed the migration servers to communicate with both
messaging systems.

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

Architecture Summary

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

Figure 3.1 Fabrikam’s migration architecture

Preparing Active Directory and Installing Exchange 2000

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 95


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

Figure 3.2 illustrates the Windows 2000 domain architecture.

Figure 3.2 Fabrikam’s Windows 2000 domain architecture

Both domains were in Windows 2000 native mode.

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

Create Security Groups

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

• Exchange Admins (alias ExchAdmins) This universal security group in


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

Note Another option is to use Exchange Delegation Wizard to grant


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

Important Always designate multiple accounts with Exchange Full


Administrator permissions as soon as possible, in case one account is
accidentally deleted. For this reason, Fabrikam administrators gave the
ExchAdmins group Exchange administrative rights during ForestPrep,
rather than giving those rights to a single account and then having that

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 96


account run Exchange Delegation Wizard to give the ExchAdmins necessary
permissions.

• Exchange View-Only Admins (alias ExchViewOnlyAdmins) This group,


also a universal security group created in the corp.fabrikam.com domain, was
populated with Fabrikam’s network administrators who who were not selected to
administer Exchange. Members of this group need to create users with Exchange
mailboxes and, therefore, need some permissions inside Exchange.

Note Network administrators need only view-only Exchange permissions


to create Exchange mailboxes in Active Directory accounts. After you install
the first server running Exchange, use Exchange Delegation Wizard to
grant this group Exchange View Only Administrator permissions at the
organization level.

Create Accounts

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

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

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

Run Forest Prep and Domain Prep

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

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

• The administrator ran ForestPrep in the root domain (fabrikam.com). ForestPrep


must always be run in the same domain as the Active Directory schema master,
which is the root domain by default.

• ForestPrep created the Exchange organization, already determined to be called


“Fabrikam” in Active Directory.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 97


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

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

• The administrators ran DomainPrep in every domain that contained an Exchange


server or Exchange users (corp.fabrikam.com).

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

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

Create Organizational Units

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

DNS

Chapter 2 “DNS Modifications” described the DNS records Fabrikam administrators


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

In addition, administrators added two CNAME records. The following CNAME record
was added for Outlook® Web Access:
Webmail.fabrikam.com IN CNAME MSGOWARI-01P

And the following CNAME record was added for Outlook clients, as discussed in
“Outlook Profile Generation” in Chapter 2.
Exchange.corp.fabrikam.com IN CNAME MSGRI-01P.corp.fabrikam.com

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

Checklist: Pre-Exchange 2000 Setup


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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 98


Table 3.3 Pre-Exchange 2000 setup checklist
Step Action

1 Confirm that domain controllers and global catalog servers are installed and
configured correctly.
In the root domain fabrikam.com, the domain controllers and global catalog
servers were:
• DC-RI01P (global catalog and schema master for the entire Active Directory
forest)
• DC-RI01P (domain controller)
In corp.fabrikam.com, the domain controllers and global catalog servers were:
• DC-RI03P (global catalog)
• DC-RI04P (domain controller)
2 Confirm that Active Directory Flexible Single Master Operation (FSMO roles) is set
up correctly on the four servers listed in Step 1.
For more information about operations master roles, see your Windows 2000
Server Help and Microsoft Knowledge Base article Q197132, “Windows 2000
Active Directory FSMO Roles,” at
http://go.microsoft.com/fwlink/?LinkId=3052&ID=197132.
3 Confirm that Windows 2000 Service Pack 2 (SP2) is loaded on all domain
controllers and global catalog servers: at a command prompt, type winver.
4 Confirm that Active Directory Integrated DNS is installed on all domain
controllers.
5 Install the Windows 2000 Support tools from the support folder on the
Windows 2000 Server CD-ROM.
6 From the Support tools, run the Netdiag.exe utility on all domain controllers.
Make sure that no errors are detected. If errors are detected, resolve them
before proceeding.
For more information about these and other Support tools, see your
Windows 2000 Server Help.
7 On every domain controller, run the Dcdiag.exe utility. Make sure that no errors
are detected. If errors are detected, resolve them before proceeding.
8 Confirm that DNS is working properly: at a command prompt, type nslookup.
9 On one of the corp.fabrikam.com domain controllers, verify that the domain is
operating in native mode. On the desktop, right-click My Computer, and then
click Properties. The General tab displays the domain’s mode.
10 In the corp.fabrikam.com domain, create the Exchange Administrator (alias:
ExchSrvc) account, and then add the account to the Domain Administrator group.
11 In the corp.fabrikam.com domain, create the Exchange Admins (alias:
ExchAdmins) universal security group. Note that you can only create universal
security groups in native-mode domains.
12 Add the ExchSrvc account to the Exchange Administrator group.
13 In the corp.fabrikam.com domain, create the Exchange View Only Admins
universal security group (alias: ExchViewOnlyAdmins).
14 On DC-RI01P, the schema master, insert the Exchange 2000 Enterprise Server
CD-ROM. Run ForestPrep (at a command prompt, type:
<drive>: setup\i386\setup /forestprep)
When prompted, give the ExchAdmins group account Full Exchange Administrator
permissions.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 99


Step Action

15 After you allow time for replication, verify that ForestPrep finished extending the
schema and that all extensions were replicated. Run the Windows 2000 Support
tool Ldp.exe (the Active Directory Administration tool) to make this verification.
Perform the following steps in Ldp.exe:
1. On the Connection menu, click Bind, and then enter a valid user name and
password.

2. On the Browse menu, click Search. In Search, enter the following


information:
Base DN: cn=schema,cn=configuration,dc=fabrikam,dc=com
Filter: (adminDescription=*Exch-Schema-Version*)
3. Click Options. In Search Options, in Attributes, type the following:
ldapDisplayName,rangeUpper
4. Click OK. In Search, click Run.

5. If object not found is returned, the schema extensions have not yet
replicated. If you can bind to the object, look at the rangeupper attribute and
see if it is set to 4397, which indicates the schema is fully replicated.
For more information about using Ldp.exe, see the Microsoft Knowledge Base
article Q224543, “Using ldp.exe to Find Data in the Active Directory,” at
http://go.microsoft.com/fwlink/?LinkId=3052&ID=224543.
16 On each global catalog server (DC-RI01P in fabrikam.com and DC-RI03P in
corp.fabrikam.com), insert the Exchange 2000 Server Enterprise CD-ROM. Run
DomainPrep (at a command prompt, type:
<drive>: setup\i386\setup /domainprep)
Again, running DomainPrep in the root domain (fabrikam.com) is not necessary,
but the migration team ran it anyway to allow someone at a later time to install
mailbox-enabled accounts in the root domain.
17 In the DNS MMC snap-in, create the CNAME record webmail.fabrikam.com and
point the record to the front-end server to be used for Outlook Web Access. At
Fabrikam, this server was MSGOWA-RI01P.
18 To verify DomainPrep security policy replication, in each domain, run
Policytest.exe. This tool is available on the Exchange 2000 Server Enterprise CD-
ROM. If replication completed, you will see:
Right found: "SeSecurityPrivilege"

For more information about this step, see the white paper Microsoft Exchange
2000 Internals: Installation and Setup at
http://go.microsoft.com/fwlink/?LinkId=5906.
19 Confirm that all Windows 2000 subnets containing servers running Exchange are
defined: in the Active Directory Sites and Services snap-in, click Subnets and
verify that a subnet object is defined for each subnet in which you plan to install
an Exchange server. Then make sure every subnet is associated with the
appropriate site.
Note It is important to ensure that the domain controllers for the
fabrikam.com domain are in a separate Windows 2000 site from the
domain controllers in corp.fabrikam.com. (Follow the logical and
physical Active Directory designs displayed in Figures 2.1 and 2.2 to
achieve this.) Make sure that your Exchange servers are part of the
Windows 2000 site containing the domain controllers for the
corp.fabrikam.com site. This configuration controls which global
catalog servers the Exchange servers use for directory lookups. If the
Exchange servers used the global catalog servers in the root domain,
they would have problems performing distribution list expansion.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 100
Step Action

20 If the computers that will run Exchange have more than 1 GB of memory, modify
the Boot.ini file with the /3gb switch. For more information about this switch,
see the Microsoft Knowledge Base article Q266096, “XGEN: Exchange 2000
Requires /3GB Switch with More Than 1 Gigabyte of Physical RAM,” at
http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
21 Create a CNAME record called Exchange in the corp.fabrikam.com zone and map
it to MSGRI-01P:
Exchange.corp.fabrikam.com IN CNAME MSGRI-01P.corp.fabrikam.com

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

Appendix B contains detailed procedures for installing Exchange on different types


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

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


Advanced Server.

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

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


Chapter 2.

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

• Date and time settings are accurate on all computers.

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

Note Successfully completing the pre-Exchange 2000 setup checklist


ensures all of these conditions are met and provides a solid, stable, and
reliable Active Directory in which to introduce Exchange.

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

Fabrikam needed three types of Exchange servers: bridgehead servers, standard


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 101
Figure 3.3 Custom installation for Exchange 2000 bridgehead server

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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 102
Figure 3.4 Typical installation for standard Exchange 2000 server

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

Checklist: Installing Exchange


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

Fabrikam administrators used the checklist in Table 3.4 to install Exchange on


servers intended for large offices. For checklists used for small offices, medium
offices, bridgehead servers, and Outlook Web Access servers, see Appendix B.

Table 3.4 Installing Exchange checklist


Step Action

1 Receive server from the Windows 2000 team.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 103
Step Action

2 Confirm that RAID configuration matches designed configuration:


• Two 9 GB or Two 18 GB; RAID1; Disk 0
• C: (3.71 GB); formatted NTFS; System
• E: (1.17 GB); formatted NTFS; OS recovery partition
• F: (1.67 or 9.67 GB); formatted NTFS; Applications; Exchange binary files
• Z: (2 GB); formatted NTFS; Paging (swap) file
• Two 9 GB; RAID1; Disk 1
• L: (8.46 GB); formatted NTFS; Exchange transaction log files
• Four 18 GB; RAID0+1 or RAID5; Disk 2
• N: (67.8 GB); formatted NTFS; Exchange databases
Use the disk array management tool from your hardware vendor. Although Windows
provides software-level RAID, Microsoft Consulting Services recommends using the
hardware RAID provided by the SCSI controllers.
Note The Exchange transaction log files must be on a dedicated RAID1 drive
set. Do not allow any other applications to use the Exchange 2000 transaction
log set.

3 Verify Windows 2000 Licensing Mode is set to per seat.


4 Check TCP/IP settings:
1. At a command prompt, type ipconfig /all

2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the
predetermined design.

Note DNS is critical for Exchange. If you install Exchange on a DNS server,
do not configure the DNS setting on the Exchange network interface card
(NIC) to the local server; instead, use another DNS server.

5 In My Network Places, verify that File and Printer Sharing for Microsoft Networks setting
is set to Maximize Data Throughput For Network Applications.
6 Confirm that the computer name is set correctly, and then join the computer to the
domain (corp.fabrikam.com).
7 In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8 Create the MMC Exchange 2000 console, and add the following MMC snap-ins:
• Active Directory Users and Computers
• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Event Viewer
• Disk Management
• Services
Save the MMC at Desktop Level for All Users. For information about creating MMC
snap-ins, see your Windows 2000 Help.
9 On the desktop, rename the My Computer icon to <computer name>.
10 Perform the following steps:
1. Check Event Log properties.

2. Confirm that Maximum Log Size is set to 16384 for Application, System, and
Security log files.

3. Confirm that Overwrite as needed is selected.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 104
Step Action

11 Confirm the paging file is set to:


• Drive C: 5 MB
• Drive Z: 1955 MB
To confirm the paging file is set
1. On the desktop, right-click the <computer name> icon (formerly My Computer,
which you renamed in Step 9), and then click Properties.
2. In System Properties, on the Advanced tab, click Performance Options.
3. In Performance Options, under Virtual memory, click Change.
4. In Virtual Memory, check the paging file settings. If they are not set properly, type
the appropriate sizes, and then click Set.
Note These settings were optimized for Fabrikam’s networking environment.
Your organization may require different paging file settings. For more
information about paging files, see your Windows 2000 Help.

12 Confirm that Maximum Registry Size is set to 150 MB


To confirm Maximum Registry Size is set
1. Follow the same procedure in Step 11.
2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB)
setting is correct.
For more information, see your Windows 2000 Help.
13 If you have not done so already, add the /3gb switch to the Boot.ini file for servers with
more than 1 GB of memory,
For more information about this switch, see the Microsoft Knowledge Base article
Q266096, “XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of
Physical RAM,” at http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14 Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000
Server CD-ROM.) This test ensures correct Active Directory and DNS integration and
verifies where the Exchange servers look to find domain controllers, global catalog
servers, and other services.
Run the following variations of Nltest.exe in the corp.Fabrikam.com domain:
• nltest /dsgetdc:corp
• nltest /dclist:corp
• nltest /dsgetsite
Note If you get an error, restart the Net Logon service. If restarting the
service does not correct the error, you have a DNS problem, or your
Windows 2000 sites are not defined correctly. You must work with Active
Directory and network administrators to remedy the situation before you
proceed.

15 Perform the following steps:


1. Start the Active Directory Sites and Services snap-in.
2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your
first site), and then click Servers.
3. Confirm that the Exchange server is listed.
16 Insert the Exchange 2000 Server CD-ROM and run Setup.
17 Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at
http://www.microsoft.com/exchange/downloads/2000/sp2/.
Note After you install SP2, the help files for Outlook Web Access clients must
be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the
first screen you see when you start EX2KSP2_server.exe), you must select
Outlook Web Access Help Files, and then double-click the appropriate .msi
file for each client language you support.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 105
Step Action

18 Move the transaction log files to the transaction log drive (drive L). For more information
about how to move the files, see “Transaction Logs” in Appendix A.
19 Move the Exchange databases to drive N. For more information about how to move
databases, see “Exchange Databases” in Appendix A.
20 Create a mailbox recipient policy and start the mailbox management process. For more
information, see “Create a Mailbox Recipient Policy (Mailbox Manager)” in Appendix A.
21 Increase the log buffers. For more information about how to increase the log buffers, see
“Log Buffers” in Appendix A.

Checklist: Configuring the First Exchange Server


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

Note In each step, the name of the appropriate procedure in Appendix A


is included.

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

Table 3.5 Configuring the first Exchange server checklist


Step Configuration Section in Appendix A

1 Display administrative groups and routing Administrative Groups and


groups in System Manager. Routing Groups Visibility
2 Delegate organization-level permissions to Exchange Administration
Exchange view only administrators. Delegation Wizard
3 Create and configure Fabrikam’s recipient policy. Fabrikam Recipient Policy
4 Create and configure Fabrikam’s contact Fabrikam Contact Recipient
recipient policy Policy
5 Configure Mailbox Manager. Create a Mailbox Recipient Policy
(Mailbox Manager)
6 Create a system policy container in System Create a System Policy
Manager. Container
7 Create a mailbox store policy. Create a Mailbox Store Policy
8 Apply the mailbox store policy to all mailbox How Fabrikam Configured Its
stores. Mailbox Store Policy
9 Create a server policy. Create a Server Policy
10 Apply the server policy to all Exchange servers. How Fabrikam Configured Its
Server Policy
11 Create a public store policy. Create a Public Store Policy
12 Apply the public store policy to all public stores. How Fabrikam Configured Its
Public Store Policy
13 Allow only a few people to create top-level public Configure Public Folder
folders. Permissions
14 Set a maximum message size for message Message Size Limits
delivery.
15 Restrict automatic replies to the Internet. Replies to the Internet

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 106
Step Configuration Section in Appendix A

16 Filter unsolicited commercial e-mail. Set Message Filtering


Note If you monitor Exchange, be
aware that the monitoring agent
could send error and warning
messages with a blank sender. If you
have activated message filtering,
these monitoring messages could be
filtered.

17 Rename the first routing group to RI RG. Routing Groups


18 Create and populate remaining routing groups. Routing Groups
19 Create and configure routing group connectors. Routing Group Connectors
Note Routing groups only go
one way. When Exchange Setup
prompts you, make sure you
configure connectors in the opposite
direction.

20 Configure the enterprise Recipient Update Recipient Update Service


Service by pointing the MSGRI-01P Recipient
Update Service to DCRI-01P (in the root
fabrikam.com domain). Have the domain
Recipient Update Service point to DCRI-03P, a
domain controller in corp.fabrikam.com. Create
a second Recipient Update Service on MSGRI-
02P and point it to the local domain controller
DCRI-04P. Ideally, for maximum replication
speed, create a domain Recipient Update Service
on every domain controller.
21 Create a domain Recipient Update Service in Recipient Update Service
each remote office that has a local domain
controller and an Exchange 2000 server. Point
the domain Recipient Update Service from the
remote office Exchange 2000 server to the
remote office domain controller.
22 Replicate the Free and Busy folder and offline Configure Public Folder
address book from MSG-RI01P throughout the Replication
organization

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

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

Preparing Novell Directory Services and GroupWise

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

Important This section contains procedures for configuring your


GroupWise system. Consult your GroupWise documentation or GroupWise

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 107
administrators in your organization before making changes to your
GroupWise system.

Novell Directory Services and GroupWise Requirements


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

• Novell NetWare version 3.x or later

• GroupWise 4.1 API Gateway NetWare Loadable Module (NLM)

• Novell NetWare Administrator

• Novell GroupWise, version 4.1 or later

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

• GroupWise Patch 2 for API NLM/OS2

Install GroupWise API Gateway


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

Install Gateway Patch 1 and Patch 2


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

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

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

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

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

Activate Distribution List Expansion


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

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

To activate distribution lists in GroupWise

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 108
2. Open this file with either Notepad (Windows) or Edit (NetWare).

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

4. Save the file.

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

Create the API Gateway


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

To create the API gateway

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

2. Select the GroupWise domain that is connecting to Exchange. On the Object


menu, click Create.

3. Click GroupWise Gateway Internet Agent.

4. In Create GroupWise Gateway/Internet Agent, click Gateway. Be sure the


Internet Agent check box is not selected.

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

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

To configure the API gateway

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

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

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

4. In Platform, click NetWare Loadable Module.

5. In Gateway Type, click API.

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

7. Click Optional Gateway Settings.

8. In Directory Sync/Exchange, click Exchange. This means that GroupWise will


wait until prompted to send a directory update to Exchange.

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

10. In Outbound Status Level, click Full.

11. Click Required Parameters.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 109
12. Change the root directory paths in the Gateway File Paths section to absolute
paths in the form Server name/Volume:\Path.

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

13. In Addressing Format, click Component.

14. Click Gateway Time Settings.

15. In Idle Sleep Duration, select a value of 5 seconds or less (1 second is


preferred). This setting reduces the time taken by free or busy queries and
directory synchronization. Click OK.

Start the API Gateway

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

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

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

Create an External Foreign Domain


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

To create an external foreign domain for the Exchange organization and


configure the link table

1. In NetWare Administrator, from the Tools menu, click GroupWise View,


and then click the API gateway.

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

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

4. In Domain Type, click External Foreign.

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

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

7. Click Create.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 110
8. In NetWare Administrator, select the GroupWise domain that is performing
directory synchronization with Exchange. This domain contains the API gateway.

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

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

11. On the Edit menu, click Link.

12. In Link Type, select Gateway.

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

Creating and Configuring Migration Accounts


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

Important The migration account must be in the same GroupWise post


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

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

Create an NTGateway Group in NetWare


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

To create the NTGateway group

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


tree and a context.

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

3. Click Create, and then click Group.

4. Type NTGateway, and then click Create.

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


Members tab, click Add.

6. Add an administrator with administrative rights to the Novell NetWare server


that is hosting GroupWise. The account used here must be the same account
used on the Exchange side to specify the connection to GroupWise.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 111
After the migration team created the NTGateway group, the team performed the
following tasks:

• Added all migration accounts to the NTGateway group.

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

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

Setting the GroupWise Access Mode to Direct Access


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

Fabrikam administrators used the Netware Administrator tool in their GroupWise


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

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 112
Figure 3.5 Change the Access Mode setting to Client/Server and Direct

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

Configuring the GroupWise System: Best Practices


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

Reduce the Amount of Data to Migrate

Reducing data simplifies migration and allows administrators to complete migration


in a much shorter time frame. For this reason, administrators asked all Fabrikam
employees to perform the following tasks:

• Delete unwanted or old e-mail.

• Delete old calendar data.

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

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

Important As you plan your migration, you must remember to include


mail expansion in your migration calculations. For more information about
mail expansion, see “Migration Considerations” in Chapter 2.

Set the Visibility of Objects

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

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

Setting Up the GroupWise Connector

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

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

• GroupWise connector

• Exchange 2000 Calendar Connector

• Gateway and Client Services for NetWare

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

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

Windows 2000 Coexistence Preparation


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

Install Gateway and Client Services for NetWare

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

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

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

To install Gateway and Client Services for Netware

1. On the Exchange bridgehead server’s desktop, right-click My Network Places,


and then click Properties.

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

3. Click Install.

4. Select Client, and then click Add.

5. In Select Network Client, select Gateway (and Client) Services for


NetWare, and then click OK.

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

To configure Gateway and Client Services for NetWare

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

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

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

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

4. In Control Panel, double-click GSNW.

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


not already selected.

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

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

8. Click Gateway.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 115
9. In Configure Gateway, in Gateway Account, enter the migration account for
the GroupWise domain that hosts the API gateway. Then enter the password.
Click OK.

Configuring the GroupWise Connector


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

Note For more conceptual information about how the GroupWise


connector works and procedure information about configuring the
connector, see your Exchange 2000 online documentation.

To configure the GroupWise connector

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


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

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

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

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

6. Under Delivery Order, leave the default Priority.

Important For additional information about other setting options and


how to determine which settings are best for your organization, see your
Exchange 2000 online documentation.

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

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

9. On the Import Container tab, in Container, select GroupWise Users. Leave


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

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

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

11. On the Dirsync Schedule tab, set Exchange-GroupWise directory update


schedule to run every 15 minutes.

Note The greater the number of changes that need to be propagated


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

Fabrikam made no settings on the Delivery Restrictions tab.

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

Starting the Connector Services

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

To verify that services started

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


then click Services.

2. In the details pane, right-click Microsoft Exchange Connector for Novell


GroupWise, and then click Start. Set the Startup Type to Automatic.

3. In the details pane, right-click Microsoft Exchange Router for Novell


GroupWise, and then click Start. Set the Startup Type to Automatic.

Setting Up Exchange 2000 Calendar Connector

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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 117
Note For conceptual information about how calendar connector works
and procedural information about configuring calendar connector, see your
Exchange online documentation.

Installing Calendar Connector


Calendar Connector is available in Exchange 2000 SP1 and later.

To install Calendar Connector

Note To perform this installation you must be a member of the Domain


Administrator group in the local domain, as well as a member of Enterprise
Administrator and Schema Administrator. You must have these permissions
because Calendar Connector makes changes to the Active Directory
schema.

1. On the computer running Windows 2000 Server on which Exchange 2000 is


installed, insert the Exchange SP1 compact disc into the CD-ROM drive.

2. Open Windows Explorer, click the CD-ROM drive, and then open the calcon
directory.

3. In calcon, open the i386 directory.

4. To install Calendar Connector, double-click setup.exe, and then complete the


installation wizard.

Recipient Policies and Calendar Connector


Calendar connector uses the System Attendant service to query GroupWise for
GroupWise users’ free and busy information. Any request from an Exchange user for
GroupWise free and busy information is communicated by the System Attendant.

For free and busy information to be properly replicated between messaging


systems, Exchange 2000 System Attendant must have a GroupWise e-mail address
(GWISE). Therefore, System Attendant must be assigned a GWISE address.

At Fabrikam, during the testing phase, the migration team discovered the default
recipient policy included only Exchange mailboxes and the policy did not create
GWISE addresses. When the migration team installed Exchange in the production
environment, the team modified the default recipient policy to create GWISE
addresses.

Replicating Free and Busy Folder to Other Servers


Free and busy information for each administrative group (Fabrikam has only one
administrative group) must replicate to the server on which Calendar Connector was
installed. Free and busy information for all users in an administrative group is kept
in the Schedule+ Free Busy Information folder located in the public folder store
of the first Exchange server in that administrative group. By default, free and busy
information is stored only on the first Exchange server in the organization. If you do
not install Calendar Connector on the first Exchange server in the administrative
group, you must replicate the Schedule+ Free Busy Information public folder to
the Exchange server on which Calendar Connector is running.

At Fabrikam, the migration team installed Calendar Connector on BRDGMSGRI-01P,


but MSGRI-01P was the first Exchange server installed and, therefore, the first
server in First Administrative Group. Therefore, administrators performed the

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 118
following procedure so that Exchange users’ free and busy information would
replicate to Calendar Connector. Fabrikam decided to replicate the Schedule+ Free
Busy Information public folder to at least one server in each routing group.

To replicate free and busy information

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Click to expand Administrative Groups, expand First Administrative Group,


expand Servers, expand MSGRI-01P, expand First Storage Group, expand
Public Folder Store (MSGRI-01P), and then click Public Folders.

3. In the details pane, right-click Schedule+ Free Busy Information – First


Administrative Group, and then click Properties.

4. On the Replication tab, click Add.

5. In Select a Public Store, select the public folder stores on all other Exchange
servers, and then click OK.

6. On the Replication tab, change Public folder replication interval to Always


run.

7. Change Replication message priority to Urgent.

Design Consideration

Because the migration team replicated the free and busy public folder across the
Fabrikam organization to all routing groups, users outside of the Richmond routing
group did not have to go over a routing group connector to obtain free and busy
information. The disadvantage of this approach is that users outside of Richmond
were dependant on public folder replication, which has a minimum latency of 15
minutes. However, as discussed in Chapter 2, the migration team reasoned that
most users scheduled meetings with people in their own office location (which is
also their own routing group), so the effect of organization-wide public folder
updates would be minimal to Fabrikam.

Configuring Calendar Connector


The following procedure describes how Fabrikam configured its Calendar Connector.
For complete information about configuration options for Calendar Connector, see
your Exchange 2000 SP1 online documentation.

To configure Calendar Connector

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Click to expand Routing Groups, expand RI RGC (the Richmond routing


group), expand Connectors, right-click Calendar Connector (BRDGMSGRI-
01P), and then click Properties.

3. On the General tab, click Modify, and in Select Exchange Notes or


Groupwise Connector, select Connector for Novell GroupWise
(BRDGMSGRI-01P), and then click OK.

4. On the General tab, type the number of days you want GroupWise to return
free and busy information. The maximum is 389 days. If you type a number

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 119
larger than 389, GroupWise will not return any information. The more data that
is requested (the larger the number of days’ worth of data you enter), the longer
it takes for the free and busy information to come across Calendar Connector.

5. On the General tab, enter the maximum age in minutes of GroupWise data that
Exchange can use before querying the GroupWise system for more data. If you
set this value to 0, every free and busy request from an Exchange user will
result in a query to GroupWise.

6. On the General tab, enter the maximum number of seconds you want Exchange
to wait for a response from GroupWise.

7. On the Calendar Connections tab, click New. In Calendar Type, select


Novell Groupwise, and then click OK.

8. In GroupWise Calendar Connection, under GroupWise API Gateway, type


the Novel API gateway (in this case, fabrikamworldwide_Richmond.api).
Click OK.

9. On the Schedule tab, enter how often you want Exchange to check the
GroupWise directory for new users to create free and busy records for those
users in the Exchange free and busy folder. The default is Never. Always
queries GroupWise for new users on the hour and every fifteen minutes
thereafter. Selected times allows you to customize the times Exchange queries
GroupWise for new users.

Note The times and frequency entered on the Schedule tab do not
determine when information is synchronized. This tab determines the
frequency when Exchange makes sure there is a free and busy record
created for each GroupWise user in the Exchange free and busy folder. The
free and busy record for an external user is created when an Exchange
user makes a query for that particular user. If a free and busy record is not
created for a GroupWise user and an Exchange user looks for that
GroupWise user’s free and busy information, no information is returned.

Configuring the Migration Servers

During the migration process, migration servers extract e-mail data from GroupWise
and transfer it to Exchange. This section describes how Fabrikam configured its
migration servers.

Note Migration servers can be desktop computers. You do not need the
most powerful hardware available for your migration servers. Microsoft
Consulting Services recommends that you scale out migration servers
(increase the number of migration servers) rather than scale up (use a
smaller number of computers with powerful hardware).

Client and Server Software Versions


At the time of the Fabrikam migration, the migration team tested a number of
different software versions for the purpose of migration and found the following
combination worked best. However, new tools may become available that work
better.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 120
• GroupWise client to be installed on migration server: GroupWise
5.2.5 This client recommendation is only for the migration server. GroupWise
users can run the latest GroupWise client.

• Novell client to be installed on migration server: Novell NetWare


4.8 This client recommendation is only for the migration server. Users can run
the latest Novell client.

• GroupWise server: GroupWise 5.5.3 server This server is the version


Fabrikam was runnning at the time of migration, and it is the verison the
migration team used to develop and test its procedures.

Software Installed on Migration Servers


The Fabrikam migration team installed the following programs on Fabrikam’s
migration servers.

• Windows 2000 Server (or Advanced Server)

Note Although you can use Windows 2000 Professional, Microsoft


Consulting Service found that Migration Wizard runs faster and more
reliably on Windows 2000 Server or Advanced Server and, therefore, does
not recommend using Windows 2000 Professional on the migration server.

• Windows 2000 Service Pack 2

• GroupWise client version 5.2.5

• Novell client version 4.8

• Exchange System Manager

Setting Up the Migration Server


Fabrikam used the following procedure to configure its four migration servers in
Richmond, the first Fabrikam office to be migrated. After the migration team
migrated all Richmond employees, the team sent one migration server to each of
the other office locations. By sending a migration server to each office, all
migrations could occur locally and not depend upon WAN links that would greatly
increase the process time.

Your Exchange organization must be installed and running before you can configure
your migration servers.

To set up a migration sever

1. Install Windows 2000 Server or Advanced Server.

2. Make sure video drivers (provided by the hardware vendor), NNTP, SMTP,
Terminal Services, and basic TCP/IP services are installed with the operating
system.

3. Join the computer to the corp.fabrikam.com domain.

4. Install Windows 2000 SP2.

5. Install GroupWise client 5.2.5.

6. Install Novell client 4.8.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 121
7. Insert the Exchange 2000 Enterprise CD into the CD-ROM drive and run Setup.
On the Component Selection page, on the Action menu drop-down list next
to Microsoft Exchange 2000 Server, select Custom.

8. On the Action menu drop-down list next to Microsoft Exchange System


Management Tools, select Install. Leave all other component actions blank.
This selection installs System Manager only.

With System Manager, a GroupWise client, and a Novell client installed, each
migration server can communicate with the GroupWise and NDS system and with
the Exchange 2000 and Active Directory system.

Important The migration server must have a Windows Messaging profile


installed. In Control Panel, double click Mail to verify if the profile exists.
If no profile exists, create it. One way you can create the profile is by
installing Outlook.

This profile could have Exchange services listed. If so, remove the
Exchange services. If you do not remove the services, you will be
prompted for Exchange logon credentials once for every user you migrate.
To avoid this logon request, make sure the only services listed in the
migration server’s mail profile are Novell GroupWise Message Store, Novell
GroupWise Address book, and Novell Personal Address Book.

Nightly Migration Process

Each night after normal working hours, the Fabrikam migration team migrated 30 to
40 users. Because Fabrikam has over 1,000 employees, the GroupWise Connector
and Calendar Connector were instrumental in allowing employees to continue
collaborating regardless of which system they were on at any given time.

Exchange Migration Wizard ran on four migration servers. Migration Wizard


communicated with both messaging systems because, as discussed in the
“Configuring the Migration Servers” section earlier in this chapter, the migration
team installed a Novell client, a GroupWise client, and System Manager the
migration server.

The migration team created a migration account for every GroupWise post office on
the NDS and GroupWise system. GroupWise users gave their post office’s migration
account proxy access to their e-mail so that the migration account could read the
user’s e-mail and extract it. In Active Directory, you need only one migration
account: the account administrators use to run Migration Wizard.

Migration Wizard extracted the mail data, converted it, and inserted the data into
the Exchange system. During the insertion, Migration Wizard checked to see if an
account existed in Active Directory that corresponded to the mail data. Fabrikam
administrators could do either a two-step migration (where they specified the
accounts to receive the mail data) or a one-step migration (where Migration Wizard
is configured to create Active Directory accounts and load the data into these
accounts). For more information about single-step and two-step migrations, see
“Microsoft Exchange Migration Wizard” later in this chapter.

Before you migrate any users, Microsoft Consulting Services recommends you
review the migration-related Microsoft Knowledge Base articles listed in Appendix D.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 122
Lessons Learned
The following list itemizes many valuable lessons learned by MCS in the testing and
pilot migration environments at Fabrikam. To avoid the issues listed here, review
this list before you begin your actual migration. After each issue, the section that
discusses the issue is referenced.

• When the migration team tested the GroupWise 5.5.3 client, Migration Wizard
generated a Dr.Watson error. When the team tested the GroupWise 5.2.5 client,
it worked. However, on the server, GroupWise 5.5 introduced database changes
that are not available to the Groupwise 5.2.5 client. Because of these database
changes, for migration purposes, installing the GroupWise 5.2.5 client on the
migration servers was sufficient. For more information, see “Configuring the
Migration Servers” earlier in this chapter.

• Migration Wizard asks for the GroupWise domain, user account, and password.
The password that Migration Wizard wants is the migration account’s GroupWise
password, not NDS password. By default, the GroupWise password is blank, so
you must set the GroupWise password to the same one you use in Migration
Wizard. The GroupWise password and the NDS password are not linked to each
other. It is recommended that you set the migration account’s GroupWise
password the same as its NDS password. For more information, see “Microsoft
Exchange Migration Wizard” later in this chapter.

• The migration account must be in the same GroupWise post office as the
accounts that you plan to migrate. At Fabrikam, each office location was its own
GroupWise domain and post office. Some offices had multiple post offices within
a single GroupWise domain. Therefore, multiple migration accounts had to
created, one for every post office. For more information, see “Creating and
Configuring Migration Accounts” earlier in this chapter.

• To migrate accounts, Migration Wizard must point to the GroupWise domain that
contains the post offices with the users who need to migrate. Even if Migration
Wizard points to the primary GroupWise domain, Migration Wizard cannot see
the post offices in secondary GroupWise domains. For more information, see
“Microsoft Exchange Migration Wizard” later in this chapter.

• When migrating mail data from Groupwise to Exchange 2000, you can migrate
the data from a GroupWise mailbox into any Active Directory account. For more
information, see “Microsoft Exchange Migration Wizard” later in this chapter.

• Exchange Migration Wizard is much faster when GroupWise is in direct access


mode rather than client/server mode. Direct access mode requires configuration
on both the client and server sides. For more information, see “Setting the
GroupWise Access Mode to Direct Access” earlier in this chapter.

• If the GroupWise user has a nickname, you must remove it. Migration Wizard
incorrectly grabs the nickname field instead of the user’s alias. For more
information, see “Microsoft Exchange Migration Wizard” later in this chapter.

• Microsoft Consulting Services found the Migration Wizard works much better
with the Groupwise 5.2.5 client than with the GroupWise 5.5.1, GroupWise
5.5.2, or GroupWise 5.5.3 clients. For more information, see “Client and Server
Software Versions” earlier in this chapter.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 123
• Microsoft Consulting Services found that running Migration Wizard on a
computer running Windows 2000 Server was much faster than running Migration
Wizard on a computer running Windows 2000 Professional. For more
information, see “Software Installed on Migration Servers” earlier in this chapter.

• During the testing phase, Fabrikam administrators discovered that, even though
the migration account was granted Minimum User Access rights on every
GroupWise account, some accounts were still unable to migrate. To simplify the
migration, administrators decided to explicitly grant the migration account all
proxy rights to the user’s account. For more information, see “Creating and
Configuring Migration Accounts” earlier in this chapter.

• During coexistence, the Gateway Service for NetWare tool (which is used by the
GroupWise connector) runs only over IPX. If your organization has disabled IPX
routing, you must enable it beween the Exchange bridgehead server running
Gateway Service for NetWare and the GroupWise API gateway server. For more
information about Gateway Service for NetWare and IPX, see the following
Microsoft Knowledge Base articles:
• Q222059, “Windows 2000 GSNW and CSNW Do Not Support NetWare 5 IP,”
at http://go.microsoft.com/fwlink/?LinkId=3052&ID=222059.
• Q235225, “GSNW and CSNW Do Not Support the IPX/SPX Protocol,” at
http://go.microsoft.com/fwlink/?LinkId=3052&ID=235225.

Migration Preparation Review


This section provides an overview of all the steps Fabrikam took to prepare for its
migration. Use this list to help you ensure you have adequately prepared your own
organization for migration.

Note The following items summarize the actions Fabrikam’s migration


team took as soon as the team successfully implemented Exchange 2000 in
its production environment and established coexistence between Exchange
and GroupWise. The Exchange installation includes all routing group
connectors, the SMTP connector, Outlook Web Access, the GroupWise
connector, and Exchange 2000 Calendar Connector.

After the migration team successfully implemented Active Directory and Exchange,
the team:

• Created disabled user accounts in Active Directory for each GroupWise user who
was to be migrated.

• Populated user accounts with relevant information (name, phone number, and so
on).

• Created security and distribution groups in Active Directory (groups were not
mail-enabled at this time).

• Created an organizational unit in Active Directory called GroupWise Users.

• Assigned appropriate permissions to the migration account in Active Directory


(the account that administrators use to log on to the migration servers).

• Assigned appropriate NDS and GroupWise permissions to migration accounts on


the GroupWise system (there were multiple accounts on the GroupWise system
because one migration account was created for each GroupWise post office).

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 124
• Ran directory synchronization between GroupWise and Active Directory to
create contact objects in Active Directory for GroupWise users and to create
foreign objects in the GroupWise external foreign domain (“Exchange”) for mail-
enabled users in Active Directory.

• Set up the migration servers.

• Created a Microsoft Excel worksheet to use as a migration tracking database and


included all Fabrikam employees and external entities (such as group calendars
and shared mailboxes) to be migrated.

• Determined which GroupWise distribution lists to migrate and added them to the
tracking database.

Four weeks before migration, the migration team:

• Identified the post offices from which users will migrate.

• Developed a user migration schedule and, whenever possible, scheduled users in


the same work group to migrate together.

• Scheduled Outlook and Windows 2000 Professional training for users.

• Identified distribution lists to which users belonged, scheduled a separate


migration for distribution lists, and added this migration to the tracking
database.

• Identified external entities and scheduled external entities to migrate at the


same time as the group that uses them (for example, migrate the legal group’s
calendar on the same night as the legal group).

• Identified the Exchange databases into which each user’s mailbox will be located
and added this informaiton to the tracking database.

• Identified any users who have nicknames on GroupWise and recorded the
nicknames in the tracking database.

Two weeks before migration, the migration team:

• Gave users instructions on how to save their current configuration information,


such as rules, and instructed users to clean up their GroupWise mailboxes.

• Trained users on Outlook and Windows 2000 Professional.

• Identified users with personal digital assistants (PDAs) and added this
information to the tracking database.

• Identified users who were approved by management to have their GroupWise


local archives migrated and added these users to the tracking database.

• Instructed users to identify any Novell Personal Address Books that they want to
migrate. Instructed users to export their personal address books to .nab files,
name each .nab file after the address book name, and save the files on the file
server.

• Use the GWCheck utility (Gwchk32.exe), available from Novell, to run a


structure and contents check on each account to be migrated. A successful
check will return the results “No problems found.”

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 125
The day before migration, the migration team:

• Converted the mail from approved users’ mail archives back to standard mail
data, and put this data on the users’ GroupWise server.

Checklist: Day of Migration


Fabrikam administrators used the checklist in Table 3.6 on the evening a particular
GroupWise post office was scheduled for migration. Use this checklist as a guideline
to be sure your own organization is ready for migration.

Note Some of these steps require configurations in your GroupWise


system. For more information about how to perform these procedures, see
your GroupWise documentation.

Table 3.6 Day of migration checklist


Step Action

1 Identify users to be migrated tonight.


2 Give the GroupWise post office’s migration account proxy access to each
GroupWise user account. Give the migration account read and write permissions
for every option available.
3 In GroupWise, clear any nicknames on migrating users.
4 In Active Directory Users and Computers, right-click the Windows 2000 accounts
for all users being migrated tonight and select Enable Account. After the
accounts are enabled, right-click each account again and select Exchange
Tasks. Use Exchange Task Wizard to mail-enable the Windows 2000 accounts.
Place the accounts in the appropriate Exchange 2000 database.
5 Change the password on each GroupWise account so that the migration team can
access the account.
6 Change the mailbox visibility of each migrating user’s mailbox to System.
7 Log on to each user’s GroupWise account and configure it to give the GroupWise
migration account full proxy rights.
8 Create a forwarding rule in each migrating user’s GroupWise mailbox so that any
new mail is forwarded to the user’s new Exchange mailbox. Also, have the rule
delete the GroupWise copy of the message.
Note After you create this forwarding rule, the users will no longer
receive mail on the GroupWise system, so make sure the users are
ready to migrate.

9 Disable any remaining rules in the user’s GroupWise mailbox, and disable any
message receipts or message tracking that the user set up in his or her
GroupWise mailbox.
10 On a migration server, run Microsoft Exchange Migration Wizard. When
prompted, be sure to migrate the user into the correct Exchange 2000 mailbox
store. For information about how to run Migration Wizard, see the “Microsoft
Exchange Migration Wizard” section later in this chapter.
11 After you migrate users, check to see if any distribution lists are scheduled to be
migrated tonight. If so, in GroupWise, change the visibility of the corresponding
GroupWise public group to Hidden, and then mail-enable the security group in
Active Directory, the same way you main-enabled users in Step 4.

Note After you migrate user accounts, follow the same procedure for any
external entities that may be scheduled for migration that evening.
Migrating external entities includes running Migration Wizard, and then
starting Outlook and performing the steps in the desktop and client
migration tasks checklist (see Table 3.7), just as you would for users.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 126
Microsoft Exchange Migration Wizard
The GroupWise to Exchange migration can be either a single-step or two-step
process, and the primary migration tool, Exchange Migration Wizard, can be
configured to perform either type of migration. In a two-step migration, the
migration servers:

1. Read the GroupWise mail database, extract the data, and convert it to an
Exchange format (.pst files).

2. Import this converted data into Exchange to locations pre-assigned by


administrators.

In a single-step migration, the migration servers do both these steps without user
intervention.

At Fabrikam, the migration team used the one-step approach. However, some
accounts that had no errors during mail export produced errors during mail import.
In these cases, the migration team reset the user’s mailbox, used the temporary
files created during the export process, and ran Migration Wizard in two-step mode.
When administrators ran the wizard a second time, they ran only the import portion
and the migration usually finished without additional errors.

Because the migration team used four migration servers, the team could migrate
about 30 accounts per night. With each migration server migrating 6 to 8 users, the
nightly migration process took 1 to 2 hours to complete, depending on the volume
of data.

Important If any problems occur during the migration, remove the


problem account from the migration list and run Migration Wizard with the
remaining accounts. Then run GWCheck.exe on the problem account while
the remaining accounts migrate.

To run the Microsoft Exchange Migration Wizard

1. Log on to a migration server with the Active Directory migration account.

2. Start Migration Wizard. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click Migration Wizard.

3. On the Welcome page, click Next.

4. On the Migration page, select Migrate from Novell GroupWise 5.x. Click
Next.

5. Click Next again.

6. On the Migration Procedure page, you can select One step migration
(recommended) or Extract migration files only, which is the first step in a
two-step migration. A one-step migration is simplest and is recommended.
However, if you find you receive errors during migration, a two-step migration
separates the process and allows you to troubleshoot the problem file. This
procedure continues based on a one-step migration. Whichever option you
select, on the Migration Procedure page, you must also specify a directory to
store the extracted GroupWise mail data.

7. On the Migration Destination page, click Migrate to a computer running


Exchange Server, and then select the Exchange server and the correct

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 127
database (Mailbox Store is selected by default) to receive the GroupWise data.
On this page, you can also decide to extract the GroupWise information to .pst
files at a later time, which effectively turns a one-step migration into a two-step
migration.

Note If the migration account is not a member of Domain Administrator


for the local domain, you will not see any servers to choose from on this
page.

8. On the GroupWise Domain page, in Path, type the path to the GroupWise
domain database. This path is to the GroupWise domain that contains the post
office with the users you want to migrate. You can enter the path as a UNC path
or it can be a mapped drive path. In Account name, enter the name of the
migration account. In Password, enter the migration account’s GroupWise
password (not the NDS password, unless you have configured these passwords
to be the same).

Important Microsoft Consulting Services discovered over the course of


several migrations at customer sites that when the GroupWise system has
multiple domains and post offices, as Fabrikam did, the path you enter on
this page must be the domain that contains the post offices you want to
migrate. Entering a path to the GroupWise primary domain does not
guarantee that all post offices will be displayed by Migration Wizard on the
next page.

9. On the GroupWise Post Office page, select the post office that contains the
accounts you want to migrate. As noted in Step 8, Migration Wizard lists only the
post offices in the domain that you entered on the GroupWise Domain page.

10. On the Migration Information page, select the type and age of mail and
calendar information you want to migrate.

11. On the Account Migration page, Migration Wizard displays a list of users from
the post office you selected earlier. Select the users you want to migrate.

12. On the Container for New Windows Accounts page, select the migrated
GroupWise users organizational unit that you created prior to running Migration
Wizard. Migrated accounts will be placed in this organizational unit. Click
Options to assign passwords for the newly created accounts.

13. On the Windows Account Creation and Association page, do one of the
following:
• Click to select one or more displayed accounts and choose whether you want
Migration Wizard to create a new Windows account.
• Click Find Existing Account to match an existing Active Directory account
with the selected account.

When done, click Next, and Migration Wizard begins extracting GroupWise mail,
converting it, and inserting the converted GroupWise mail into Exchange.

14. If, on the Container for New Windows Accounts page, you clicked Options
and chose to have a random password assigned to accounts created by
Migration Wizard, the file containing those randomly assigned passwords is
included in the application log file. When Migration Wizard finishes, check the
application log file for these passwords.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 128
Note Log files will be in the folder you designated when you installed
Exchange.

Check list: Desktop and Client Migration Tasks


When Migration Wizard finished extracting the GroupWise data, the Fabrikam
migration team readied the workstations of migrating users. Table 3.7 lists the tasks
performed on each newly migrated user’s computer running Windows 2000
Professional.

Table 3.7 Desktop and client migration tasks checklist


Step Action

1 Install Outlook on each user’s workstation. In addition, be sure to install the


Import and Export tool. This step can be done while Migration Wizard runs.
2 Start Outlook. Import migrated calendar information from the .sc2 file in the
user’s Inbox by running Outlook Import and Export Wizard.
3 Verify that each user’s mail and calendar information migrated. Verify that any
folders created in GroupWise migrated.
4 If you your organization created a NAB customized conversion script, which is
what Fabrikam did, convert Novell personal address books on the file server by
running the script. On the workstation, create a contact folder in Outlook for each
.nab file. Use Outlook Import and Export Wizard to import the converted .nab file
into the appropriate Outlook contact folder.
Without a conversion script, users must re-create their contacts in Outlook by
hand.
5 Communicate to the user, in a sealed envelope, his or her new Active Directory
password.

Check list: Post Migration Tasks


After Migration Wizard finished running and client migration tasks were completed,
Fabrikam administrators performed the tasks listed in Table 3.8.

Table 3.8 Post-migration tasks checklist


Step Action

1 Manually synchronize GroupWise and Exchange by clicking Immediate Full


Reload on the Dirsync Schedule tab of the GroupWise connector.
2 Verify that Step 1 synchronized newly migrated users to the GroupWise external
domain.
3 In GroupWise, change the visibility setting of the accounts you just migrated to
Hidden.
4 Reconfigure users’ PDAs for synchronization with Outlook.
5 Notify users that they need to re-create proxies, rules, shared folders, and words
added to their personal dictionaries.

For more information: http://www.microsoft.com/exchange/

Did this paper help you? Please give us your feedback. On a scale of 1 (poor) to 5
(excellent), how would you rate this paper?

mailto:exchdocs@microsoft.com?subject=Feedback: Microsoft Exchange 2000 and


Novell GroupWise Coexistence and Migration

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 129
Appendix A Procedures
Use the procedures in this appendix to help you configure your Microsoft®
Exchange 2000 organization. You can find most of these procedures in your
Exchange 2000 online documentation; however, in some cases, the procedures
were customized for Fabrikam.

The Fabrikam migration team used these procedures to set up its Exchange system;
depending on your topology, you may need to change some configuration settings.

Administrative Groups and Routing Groups Visibility

By default, System Manager does not display routing groups or administrative


groups. This section describes how to view one or both of these objects.

To view administrative groups and routing groups

1. Start System Manager. On the Start menu, click Programs, point to


Microsoft Exchange, and then click System Manager.

2. Right-click the organization object [in this case, Fabrikam (Exchange)], and
then click Properties.

3. On the General tab, under Administrative views, select the Display routing
groups and Display administrative groups check boxes.

Exchange Administration Delegation Wizard

Exchange Administration Delegation Wizard is a tool that simplifies delegating


permissions to Exchange administrators. When you start Exchange Administration
Delegation Wizard, you are prompted to select users and groups for which you
want to apply the administrative permissions. This tool is particularly useful
immediately after you install Exchange, because the account that installed the first
Exchange server (you designate this account during Forest Prep) can use Exchange
Administration Delegation Wizard to grant administration permissions to all
Exchange administrators in the organization.

To use Exchange Administration Delegation Wizard

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

2. Right-click the organization or administrative group for which you want to


delegate administrative permissions, and then click Delegate control.

3. In Exchange Administration Delegation Wizard, click Next.

4. In Users or Groups, click Add to grant a new user or group administrative


permissions.

5. In Delegate Control, click Browse, and then select a user or group from the
list that appears. To display the list of users and groups from the Active
Directory® directory service, or only the list for a particular domain, click
Locations. You can also type the name or alias of the user or group under

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 130
Enter the object name to select, and then click Check Names. You must
type one name at a time.

6. After you have selected a user or group, in Delegate Control, in the Role list,
select the one of the following types of administrative permissions for the group
or user:
• Exchange Full Administrator. This option can fully administer Exchange
system information and modify permissions.
• Exchange Administrator. This option can fully administer Exchange
system information.
• Exchange View Only Administrator. This option can view Exchange
configuration information.

7. To change the role of an existing user or group, in Users and Groups, select
the user or group, click Edit, and then select the new role.

8. To remove a user or group, in Users and Groups, select the user or group, and
then click Remove.

9. To assign the permissions, click Next, and then click Finish.

Mailbox Size Limits

This section describes setting mailbox size limits. For procedures about setting
mailbox recipient policies and configuring Mailbox Manager, see “Recipient Policies”
later in this appendix.

To set mailbox size limits

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

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, expand the appropriate server, and then expand First Storage
Group.

3. Right-click Mailbox Store (<server name>), and then click Properties.

4. Click the Limits tab. Select the Prohibit send and receive at (KB) check box,
and then type 2500 in the corresponding text box. To warn users when they are
approaching the organization’s mailbox size limit, you can select the Issue
warning at (KB) and Prohibit send at (KB) check boxes and type smaller
numbers in the corresponding text boxes.

Mailbox Store Policies

Use the mailbox size limit procedure to impose size limits in a single mailbox store.
Instead of performing this procedure multiple times on all of Fabrikam’s mailbox
stores, the migration team created a mailbox store policy and applied it to multiple
mailbox stores in the organization. For more information about how to create a
mailbox store policy, see “Create a Mailbox Store Policy” later in this appendix.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 131
Message Size Limits

This section contains procedures for limiting the size of message that can be sent
between users in your organization.

At Fabrikam, internal messages limits were configured using global settings in


System Manager. Global settings apply to all SMTP virtual servers in an Exchange
organization.

Note Message size limits on a user’s mailbox (set through the Active
Directory Users and Computers snap-in) override SMTP virtual server
settings, regardless of whether those settings are global across all virtual
servers or unique to one particular virtual server.

Internal Message Size Limits


Setting internal message size limits determines the size limit for messages sent
between users within an Exchange organization.

To configure internal message size limits

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Double-click Global Settings.

3. Right-click Message Delivery, and then click Properties.

4. On the Defaults tab, set the following options:


• Under Sending message size, click Maximum (KB), and then type the
maximum message size, in kilobytes, that can be sent by users. The default
setting is No limit, which means users are allowed to send a message of any
size.
• Optionally, under Receiving message size, you can click Maximum (KB),
and then type the maximum message size, in kilobytes, that can be received
by users. The default setting is No limit, which means users are allowed to
receive a message of any size.

Note The SMTP virtual servers in your organization do not allow users to
send or receive messages that exceed these limits (except for users who
may have a different limit set on their individual mailboxes).

External Message Size Limits


The global settings described in the “Internal Message Size Limits” section apply to
the SMTP virtual servers in the Exchange organization. Although each SMTP virtual
server can be configured to relay all external messages through a designated smart
host (by clicking Advanced on the Delivery tab), Fabrikam chose to channel all
external (Internet-bound) e-mail through an SMTP connector on its bridgehead
server (MSGBRDGRI-01P) in Richmond.

For more procedures about setting size limits on external messages, see “SMTP
Connectors” later in this appendix.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 132
Deleted Items Recovery

The following procedures describe how to set a deleted items recovery period, how
to recover a deleted mailbox, and how users can recover deleted mailbox items
from within Microsoft Outlook® 2000 or Outlook Web Access (in Exchange 2000
Server Service Pack 2 or later).

Deleted Items Recovery Period


A setting on the computer running Exchange determines the number of days
administrators have to recover deleted mailboxes and the number of days users
have to recover deleted mailbox items.

To set the deleted items recovery period for mailboxes and mailbox items

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

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, expand the appropriate server, and then expand First Storage
Group.

3. Right-click Mailbox Store (<server name>), and then click Properties.

4. Click the Limits tab. Under Deletion settings, in the Keep deleted items for
(days) and Keep deleted mailboxes for (days) boxes, type the number of days
you want.

Repeat this procedure for every mailbox store in your organization.

Recover a Deleted Mailbox


The following procedure describes how to recover a mailbox after a user has been
deleted from Active Directory, which makes the mailbox unowned. If the user is
reinstated in Active Directory, or you want to give the mailbox to another user, use
this procedure. To recover a mailbox that has been deleted from System Manager,
you must use a backup tape.

To recover a mailbox after the mailbox owner is deleted from Active


Directory

1. Start System Manager. On the Start menu, click Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, expand the appropriate server, expand First Storage Group, and
then expand Mailbox Store (<server name>).

3. In the console tree, click Mailboxes.

4. In the details pane, right-click the mailbox you want, and then click Reconnect.

Recover Deleted Items


The following procedures describe how a user can recover a deleted item from their
Deleted Items folder.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 133
To recover deleted items in Outlook

1. From your Deleted Items folder, on the Tools menu, click Recover Deleted
Items.

2. In the list, click the item or folder you want to retrieve, and then click Recover
Selected Items.

To recover deleted items in Outlook Web Access

1. Click the Options icon on the Outlook Bar. Under Recover Deleted Items,
click View Items. The Recover Deleted Items window opens.

Note Another way to open this window is to open your Deleted Items
folder, and then click Recover Deleted Items on the toolbar.

2. In the Recover Deleted Items window, select the item you want to recover. To
select multiple items, press the CTRL or SHIFT keys.

3. Click Recover to return the selected items to your Deleted Items folder.

Message Filtering

The message filtering feature of Exchange 2000 allows you to block predefined
users or domains from sending e-mail to your users. Fabrikam used message
filtering to block unsolicited commercial e-mail from its organization.

Setting up messaging filtering in your organization is a two-step process. First, you


set message filtering in global settings, and then you enable message filtering on
every IP address and TCP port combination ([All Unassigned] and 25 are the
defaults) on every SMTP virtual server to which you want to apply the filter.

Set Message Filtering


This procedure describes how to create a message filtering list. Everyone included
on this list, either individual users or entire domains, cannot send e-mail to your
Exchange organization.

To set message filtering

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

2. Expand Global Settings.

3. Right-click Message Delivery, and then click Properties.

4. On the Filtering tab, click Add.

5. In Add Sender, type the name of the sender whose messages you want to
filter, and then click OK.
• To prevent a specific user in a specific domain from delivering messages to
your site, type the user's alias and domain name in the following format:
username@domain; for example, someone@microsoft.com.
• To prevent all users in a specific domain, including all subdomains of that
domain, from delivering messages to your site, type the domain name,
including the at sign (@). For example, if you use the mask address

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 134
@microsoft.com, the addresses someone@microsoft.com and
someone@support.microsoft.com are both blocked.
• To limit the domain blocking to a specific domain and exclude subdomains of
that domain, precede the domain name with the number sign (#). For
example, to block mail from all users at microsoft.com but allow mail from
users in a subdomain of microsoft.com (for example,
support.microsoft.com), use the mask #@microsoft.com. This setting blocks
someone@microsoft.com, but allows someone@support.microsoft.com.

Important When entering names, you must use an SMTP address format
(someone@microsoft.com) or type in a sender's display name in quotation
marks.

6. Repeat Steps 4 and 5 for every sender you want to add to the message filter list.

7. Filtered messages are deleted unless you select the Archive filtered messages
check box. Messages are kept in the <root>\Exchsrvr\Mailroot\<vsi #>\Filter
directory, where <vsi #> is the SMTP virtual server.

Note When the first message is filtered, the Filter directory is


automatically created in the virtual server's directory.

Enable Message Filtering on a Virtual Server


After you create a message filter list, use the following procedure to apply the filter
to each IP address/TCP port combination in every SMTP virtual server in your
Exchange organization. This procedure allows for flexibility when applying your
message filter to some or all users.

To apply message filtering

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

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, expand the appropriate server, expand Protocols, and then expand
SMTP.

3. Right-click the appropriate SMTP virtual server, and then click Properties.

4. On the General tab, click Advanced.

5. In Advanced, select the IP address to which you want to apply the message
filter, and then click Edit.

6. In Identification, select the Apply Filter check box, and then click OK. In
Advanced, under Filter Enabled, Yes appears.

7. To disable filtering, clear the Apply Filter check box.

Distribution Lists

In Exchange 2000, distribution lists are mail-enabled groups. The following


procedure describes how to restrict one or more users from sending mail to a
particular group.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 135
To restrict one or more users from sending messages to a distribution list

1. On the Start menu, point to Programs, point to Microsoft Exchange, and


then click Active Directory Users and Computers.

2. In the console tree, click the organization unit that contains the mail-enabled
group (Users by default).

3. In the details pane, right-click the group, and then click Properties.

4. Click the Exchange General tab.

5. Under Message restrictions, do one of the following:


• Click From everyone to allow everyone in your organization to send e-mail
to this group.
• Click Add to create a list of users and groups. When you finish creating your
list, select the Only from option to allow only the list you have created to
send mail to this group.
• Click Add to create a list of users and groups. When you finish creating your
list, select the From everyone except option to exclude the list you created
from sending e-mail to the group.

Replies to the Internet

The following procedure describes how to determine which automatic replies (such
as “out of facility” [or OOF] messages) users can and cannot send outside your
organization to the Internet.

To restrict replies to the Internet

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Global Settings.

3. Click Internet Message Formats.

4. In the details pane, right click Default, and then click Properties.

5. In Default Properties, click the Advanced tab.

6. Under Exchange rich-text format, click Determined by individual user


settings. Do not click Always use unless you are certain your users only send
messages to other Exchange organizations.

7. Depending on the needs and policies of your organization, select or clear the six
check boxes at the bottom of the Advanced tab, which allow you to send or
block certain types of messages.

System Policies

To enforce a common configuration across all office locations, the Fabrikam


migration team established server policies, public store policies, and mailbox store
policies. This section contains procedures for creating each of these system policy
types, as well as for creating a system policy container.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 136
Create a System Policy Container
Creating a system policy container is the first step in creating any system policy.

To create a system policy container

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups.

3. Right-click First Administrative Group, point to New, and then click System
Policy Container.

Create a Server Policy


Server policies ensure configuration consistency in all Exchange servers.

To create a server policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative


Group.

3. Right-click System Policies, point to New, and then click Server policy.

For complete information about server policy configuration options, see your
Exchange 2000 online documentation.

The following section describes how Fabrikam configured its system policy; be
aware that settings Fabrikam made may not be optimal for your organization.

How Fabrikam Configured Its Server Policy

Fabrikam administrators used the following procedure to configure their server


policy.

1. Complete Steps 1 through 3 in the To create a server policy procedure.

2. In New Policy, select the General check box, and then click OK.

3. In Properties, on the General tab, type Fabrikam Exchange Server Policy


as a name for the policy.

4. On the Details tab, use Administrative note to add additional information


about the policy.

5. On the General (Policy) tab, set the following options:


• Select the Enable subject logging and display check box to log all
message subject fields.
• Select the Enable message tracking check box to log all mail activity
performed by all Exchange components.
• Select the Remove log files check box to remove all log files older than the
value set in the Remove files older than (days) box. Enter 7 for the
number of days.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 137
Adding Servers to the Server Policy

After the policy was created, administrators added all mailbox servers to the policy.

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and


then expand System Policies.

3. Right-click Fabrikam Exchange Server Policy, and then click Add server.

4. In Select the items to place under the control of this policy, select all
appropriate servers, click Add, and then click OK.

Create a Public Store Policy


With a public store policy, you can quickly apply general, database, replication, and
message and folder limits properties to public folder stores.

To create a public store policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative


Group.

3. Right-click System Policies, point to New, and then click Public store policy.

For complete information about public store policy configuration options, see your
Exchange 2000 online documentation.

At the time of Fabrikam’s migration, Fabrikam administrators concentrated on


getting their Exchange organization running rather than configuring multiple public
folder stores. Administrators planned to implement a complete public folder
infrastructure at a later date, which is why the initial public store policy was a
relatively simple policy. The following section describes how Fabrikam configured its
public store policy; be aware that settings Fabrikam made may not be optimal for
your organization.

How Fabrikam Configured Its Public Store Policy

Fabrikam administrators used the following procedure to configure their public store
policy.

1. Complete Steps 1 through 3 of the To create a public store policy procedure.

2. In New Policy, select the Limits and Replication check boxes, and then click
OK.

3. In Properties, on the General tab, type Fabrikam Exchange Public Folder


Store Policy as a name for the policy.

4. On the Details tab, use Administrative note to add additional information


about the policy.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 138
5. On the Limits (Policy) tab, set the following options:
• Select the Issue warning at (KB) check box to send a warning when the
storage space used reaches the size you specify. In the corresponding text
box, type 25000.
• Select the Prohibit post at (KB) check box to prohibit messages over the
size you specify from posting. In the corresponding text box, type 50000.
• Select the Maximum item size (KB) check box to set a maximum limit for
items in the policy. In the corresponding text box, type 5000.
• In the Warning message interval list, leave the default warning message
interval, Run daily at Midnight.
• Under Deletion settings, in the Keep deleted items for (days) box, set
the maximum number of days that items can remain in the store. Type 3.
• Select the Do not permanently delete items until the store has been
backed up check box to preserve items until the public store is backed up.
• Select the Age limit for all folders in this store (days) check box, and
then type 30 in the corresponding text box.

6. On the Replication (Policy) tab, click Restore Defaults.

Adding Public Folder Stores to the Public Folder Store Policy

After the policy was created, administrators added all public folder stores to the
policy.

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and


then expand System Policies.

3. Right-click Fabrikam Exchange Public Folder Store Policy, and then click
Add Public Store.

4. In Select the items to place under the control of this policy, select all
public folder stores, click Add, and then click OK.

Create a Mailbox Store Policy


With a mailbox store policy, you can quickly apply general, database, and message
limit properties to mailbox stores.

To create a mailbox store policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative


Group.

3. Right-click System Policies, point to New, and then click Mailbox store
policy.

For complete information about mailbox policy configuration options, see your
Exchange 2000 online documentation.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 139
The following section describes how Fabrikam configured its mailbox store policy; be
aware that settings Fabrikam made may not be optimal for your organization.

How Fabrikam Configured Its Mailbox Store Policy

Fabrikam administrators used the following procedure to configure their mailbox


store policy.

1. Complete Steps 1 through 3 of the To create a mailbox store policy


procedure.

2. In New Policy, select the Limits check box, and then click OK.

3. In Properties, on the General tab, type Fabrikam Exchange Mailbox Store


Policy as a name for the policy.

4. On the Details tab, use Administrative note to add additional information


about the policy.

5. On the Limits (Policy) tab, set the following options:


• Select the Issue warning at (KB) check box to issue a warning when the
storage space used reaches the size you specify. In the corresponding text
box, type 100000, which is 100 MB.
• Select the Prohibit send at (KB) check box to stop sending items when the
storage space used reaches the size you specify. In the corresponding text
box, type 125000, which is 125 MB.
• Under Deletion settings, in the Keep deleted items for (days) box, set
the maximum number of days to keep deleted items in the store. Type 7.
• In the Keep deleted mailboxes for (days) box, set the maximum number
of days to keep deleted mailboxes in the store. Type 30.
• Select the Do not permanently delete mailboxes and items until the
store has been backed up check box to preserve mailboxes and items until
the mailbox store is backed up.

Adding Mailbox Stores to the Mailbox Store Policy

After the policy was created, administrators added all mailbox stores to the policy.

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and


then expand System Policies.

3. Right-click Fabrikam Exchange Mailbox Store Policy, and then click Add
Mailbox Store.

4. In Select the items to place under the control of this policy, select all
mailbox stores, click Add, and then click OK.

Recipient Policies

E-mail address recipient policies generate e-mail addresses for users and contacts in
your organization. Mailbox recipient policies use Mailbox Manager to enforce
message size limits and age limits in one or more mailboxes in your organization.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 140
For information about both kinds of recipient policies and their configuration options,
see the Exchange 2000 online documentation.

How Fabrikam Created and Configured Its E-Mail Address Recipient Policies
For each e-mail address recipient policy you create, you can define the membership
of the recipient policy and select the address types for policy members. The default
recipient policy creates SMTP and X.400 e-mail addresses for all mail objects in
Active Directory.

The Fabrikam migration team needed three e-mail recipient policies:

• A policy called Fabrikam Recipient Policy, which applied to Fabrikam employees


with Exchange mailboxes (priority: 1)

• A policy called Fabrikam Contact Recipient Policy, which applied to the contact
objects created by the GroupWise connector. (priority: 2)

• The default policy, called Default Policy, which applied to all mail-enabled objects
in the Active Directory forest (priority: Lowest)

Default Policy

The default policy cannot be deleted, and its membership cannot be altered. The
Fabrikam migration team discovered it had to add GroupWise to the types of
addresses created by the default policy. This information was necessary for
coexistence, as Exchange 2000 Calendar Connector does not work properly unless
Exchange System Attendant has a GroupWise e-mail address. System Attendant,
like all system services that have e-mail addresses, is assigned its e-mail address by
the default policy. For this reason, ensure that the GWISE check box is selected in
the default policy.

To add GroupWise addresses to the default policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Recipients, and then click Recipient Policies.

3. In the details pane, right-click Default Policy, and then click Properties.

4. In Default Policy Properties, on the E-Mail Addresses (Policy) tab, click


New.

5. In New E-mail Address, click Novell GroupWise Address, and then click OK.

6. In Novell GroupWise Address Properties, in the Address box, type the


GroupWise address format you want all mail-enabled objects in Active Directory
to have, and then click OK. At Fabrikam, this format was Exchange.First
Administrative Group.&m.

7. On the E-Mail Addresses (Policy) tab, ensure that GWISE is selected.

Fabrikam Recipient Policy

The Fabrikam Recipient Policy applied to all users with Exchange mailboxes, mail-
enabled groups, and public folders. This recipient policy consisted of the default
X.400 and SMTP addresses (for example, alan.steiner@fabrikam.com), as well as a
GroupWise address like the one created in the Default Policy. The GroupWise

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 141
address is generated so that, during coexistence, Exchange users can communicate
with GroupWise users.

In addition, a secondary SMTP address was included in this policy. The secondary
SMTP address used a logon ID (for example, asteiner@fabrikamworldwide.com),
similar to each employee’s GroupWise e-mail address. This address was included in
the policy to ensure that users would continue receiving e-mail from the Internet,
even if the mail was addressed to their old GroupWise e-mail address.

To create the recipient policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Recipients, right-click Recipient Policies, point to New, and then


click Recipient Policy.

3. In New Policy, under Property pages, select the E-Mail Addresses check
box, and then click OK.

4. In Properties, on the General tab, in the Name box, type Fabrikam


Recipient Policy.

5. To define policy membership, click Modify.

6. In Find Exchange Recipients, under Show these recipients, select the


Users with Exchange mailbox, Groups, and Public folders check boxes.
Clear all other check boxes, and then click OK.

7. In Properties, on the E-Mail Addresses (Policy) tab, click New.

8. In New E-mail Address, click SMTP Address, and then click OK.

9. In SMTP Address Properties, under Address, type the secondary SMTP


address, and then click OK. At Fabrikam, this address was
%m@fabrikamworldwide.com.

10. On the E-Mail Addresses (Policy) tab, select the new SMTP address check
box.

Fabrikam Contact Recipient Policy

The GroupWise connector creates contact objects in Active Directory for every
migrating GroupWise user. The default policy assigns SMTP addresses to these
contact objects. However, having the default policy assign SMTP address to these
objects is not desirable because, when you migrate the users to Exchange and
assign the users SMTP addresses, the SMTP address (for example,
alan.steiner@fabrikam.com) is already taken by the contact object.

For this reason, the Fabrikam migration team created a contact recipient policy
whose membership consisted of only contact objects. This policy created SMTP
addresses in the format @fabrikamgw.com so that, when the user migrated, no
conflict occurred when assigning the new Exchange user an SMTP address.

To create a contact recipient policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 142
2. Expand Recipients, right-click Recipient Policies, point to New, and then
click Recipient Policy.

3. In New Policy, under Property pages, select E-Mail Addresses, and then
click OK.

4. In Properties, on the General tab, in the Name box, type Fabrikam Contact
Recipient Policy.

5. To define policy membership, click Modify.

6. In Find Exchange Recipients, under Show these recipients, select the


Contacts check box. Clear all other check boxes, and then click OK.

7. In Properties, on the E-Mail Addresses (Policy) tab, click New.

8. In New E-mail Address, click SMTP Address, and then click OK.

9. In SMTP Address Properties, under Address, type the contact SMTP address.
At Fabrikam, this address was @fabrikamgw.com. Click OK.

10. On the E-Mail Addresses (Policy) tab, select the new SMTP address check
box.

Create a Mailbox Recipient Policy (Mailbox Manager)


Fabrikam created a mailbox recipient policy, which configures Mailbox Manager to
maintain employees’ mailboxes by deleting messages that exceed a time or age
limit.

Note Mailbox Manager is available in Exchange 2000 SP1 or later.

For complete information about mailbox recipient policies, see your Exchange 2000
online documentation.

Fabrikam administrators used the following procedure to create a mailbox recipient


policy; be aware that not all of their configurations may apply to your organization.

To create a mailbox recipient policy

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Recipients, and then click Recipient Policies.

3. In the details pane, right-click Fabrikam Recipient Policy (created earlier


when setting up e-mail address recipient policies), and then click Change
property pages.

4. In New Policy, select Mailbox Manager Settings, and then click OK.

5. In the details pane, right-click Fabrikam Recipient Policy again, and then click
Properties.

6. In Fabrikam Recipient Policy Properties, click the Mailbox Manager


Settings (Policy) tab.

7. In the When processing a mailbox list, select Move to Deleted Items


folder.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 143
8. Under Folder, select the Inbox, Sent Items, Deleted Items, and System
Cleanup Folders check boxes. Clear all other check boxes.

9. Click Inbox, and then click Edit.

10. In Folder Retention Settings, clear the Message Size (KB) check box and
ensure that the Age Limit (days) check box is selected. In the Age Limit
(days) text box, type 45, and then click OK. Fabrikam wants to delete all
messages older than 45 days, regardless of the size of the messages.

11. Repeat Step 10 for every folder selected in Step 8, except Deleted Items.

12. Click Deleted Items, and then click Edit.

13. In Folder Retention Settings, clear the Message Size (KB) check box. In the
Age Limit (days) text box, type 7, and then click OK.

Starting the Mailbox Management Process

After you create a mailbox recipient policy, Mailbox Manager does not run until you
activate it on the server object.

To start the mailbox management process

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, right-click a server that contains Exchange mailboxes, and then click
Start Mailbox Management Process.

3. Repeat Step 2 for every server.

Recipient Update Service

The Recipient Update Service ensures accurate address list memberships by


updating address lists to reflect the modifications you make. The frequency and
method you use to update address lists depends on your organization's needs,
network topology, and resources. By default, Exchange creates a Recipient Update
Service for the enterprise and for the domain in which it is installed.

For complete information about the Recipient Update Service, see your
Exchange 2000 online documentation.

To expedite replication when administrators make changes to an address list or


policy from any location, Fabrikam administrators installed a Recipient Update
Service in every office location.

To create a Recipient Update Service

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Recipients.

3. Right-click Recipient Update Service, point to New, and then click Recipient
Update Service.

4. In New Object – Recipient Update Service, click Browse.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 144
5. In Browse for Domain, select corp.fabrikam.com, and then click OK.

After Recipient Update Services were created, Fabrikam administrators in each office
location could update address lists with any changes or rebuild address lists on their
local domain controllers. The local domain controllers then replicated the changes to
the rest of the organization.

To update or rebuild address lists

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Recipients, and then click Recipient Update Services.

3. In the details pane, right-click the appropriate Recipient Update Service, and
then click Update Now or Rebuild. The appropriate Recipient Update Service is
Recipient Update Service (FABRIKAM) where, under Domain Controller,
the local domain controller is listed.

Routing Groups

Figure 2.11 (in Chapter 2) displays the routing group design implemented by
Fabrikam administrators. This section describes how to create routing groups. To
begin, create a routing groups container in each administrative group.

To create a routing groups container

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups.

3. Right-click First Administrative Group, point to New, and then click Routing
Groups Container.

The Fabrikam migration team named its routing groups container “Routing Groups.”

To create a routing group

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, and then expand First Administrative


Group.

3. Right-click Routing Groups, point to New, and then click Routing Group.

4. In Properties, in the Name box, type a name for the routing group. The first
routing group created by Fabrikam for its Richmond headquarters was called RI
RG.

5. Repeat Steps 3 and 4 to create routing groups for Alexandria, Chicago,


Braintree, and Munich.

To populate routing groups

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 145
2. Expand Administrative Groups, expand First Administrative Group, expand
Routing Groups, and then expand the routing group you want to populate.

3. Select a server, and then drag it with your mouse into the Members folder in
the routing group to which you want that server to belong.

Routing Group Connectors

Within the Fabrikam organization, routing group connectors were required so that
all the routing groups could communicate with one another. Figure 2.11 (in Chapter
2) displays the routing group connector architecture designed by the Fabrikam
migration team.

For complete information about configuring routing group connectors, see your
Exchange 2000 online documentation.

Fabrikam used the following procedure to configure its routing group connectors; be
aware that not all settings may apply to your organization.

To create a routing group connector

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Routing Groups, and then expand the routing group for which you want to
create a connector.

3. Right-click Connectors, point to New, and then click Routing Group


Connector.

4. In Properties, on the General tab, in the Name box, type the name of the
routing group connector. For example, Fabrikam named its connector from the
Richmond routing group (RI RG) to the Alexandria routing group (AL RG) RI-AL
RGC.

5. In the Connects this routing group with list, select the target routing group.

6. On the Remote Bridgehead tab, click Add.

7. In Add Bridgehead, select the server and virtual server. At Fabrikam, this
server was always the target server and the virtual server was Default SMTP
Virtual Server.

8. On the Delivery Options tab, select the Use different delivery times for
oversize messages check box.

9. In the Oversize messages are greater than (KB) box, type 10000, which is
10 MB.

10. Click Customize (the bottom button) and, in Schedule, select non-working
hours. These hours will be the times that messages over 10 MB are delivered.

11. When you finish configuring the connector, a prompt appears asking Do you
want to create the routing group connector in the remote routing
group? Click Yes.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 146
SMTP Connectors

Although computers running Exchange 2000 can communicate with the Internet
directly, Fabrikam created SMTP connectors on a designated bridgehead server
(MSGBRDGRI-01P). The SMTP connectors routed all of Fabrikam’s outbound SMTP
mail through the intranet firewall to one of two SMTP mail relay servers in
Fabrikam’s perimeter network. The SMTP mail relay servers then sent the messages
through the Internet firewall to the Internet.

For complete information about creating and configuring SMTP connectors, see your
Exchange 2000 online documentation.

Fabrikam administrators used the following procedure to set up their SMTP


connectors; be aware that not every setting may apply to your organization.

To create an SMTP connector

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Routing Groups, and then expand RI RG (the Richmond routing group).

3. Right-click Connectors, point to New, and then click SMTP Connector.

4. In Properties, on the General tab, in the Name box, type Fabrikam SMTP
Connector.

5. Click Forward all mail through this connector to the following smart
hosts, and then, in the corresponding text box, type the IP addresses of the two
SMTP mail relay servers in the perimeter network. Organizations that use an ISP
can type the IP address of mail relay servers hosted at the ISP sites. Be sure to
enclose each IP address in brackets ([ ]) and separate IP addresses with
commas (,).

6. Under Local bridgeheads, click Add.

7. In Add Bridgehead, under Server, click MSGBRDGRI-01P (with Default


Virtual Server), and then click OK.

8. Select the Do not allow public folder referrals check box.

9. On the Address Space tab, click Add.

10. In Add Address Space, click SMTP, and then click OK.

11. In Internet Address Space Properties, in the E-mail domain box, leave the
default e-mail domain of *. In the Cost box, change the default cost to 10, and
then click OK.

12. On the Address Space tab, under Connector scope, ensure that the Entire
organization button is selected.

13. On the Content Restrictions tab, ensure that every check box under Allowed
priorities and Allowed types is selected. Under Allowed sizes, select the
Only messages less than (KB) check box, and then type 5000 in the
corresponding text box. This option imposes a 5 MB limit on all messages sent
by Fabrikam employees to the Internet.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 147
SMTP Connector for Executive Group
Executives at Fabrikam wanted to send messages up to 10 MB in size to the
Internet. Administrators created a group called Fabrikam Execs and used the
following procedure to create an SMTP connector just for this group.

To create the executive SMTP connector

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Routing Groups, and then expand RI RG (the Richmond routing group).

3. Right-click Connectors, point to New, and then click SMTP Connector.

4. In Properties, on the General tab, in the Name box, type Fabrikam SMTP
Connector.

5. Click Forward all mail through this connector to the following smart
hosts, and then, in the corresponding check box, type the IP addresses of the
two SMTP mail relay servers in the perimeter network. Organizations that use an
ISP can type the IP address of mail relay servers hosted at the ISP sites. Be sure
to enclose each IP address in brackets ([ ]) and separate IP addresses with
commas (,).

6. Under Local bridgeheads, click Add.

7. In Add Bridgehead, under Server, click MSGBRDGRI-01P (with Default


Virtual Server), and then click OK.

8. Select the Do not allow public folder referrals check box.

9. On the Address Space tab, click Add.

10. In Add Address Space, click SMTP, and then click OK.

11. In Internet Address Space Properties, in the E-mail domain box, leave the
default e-mail domain of *. In the Cost box, change the default cost to 30, and
then click OK.

12. On the Content Restrictions tab, under Allowed sizes, select the Only
messages less than (KB) check box, and then, in the corresponding text box,
type 10000. This option imposes a 10 MB limit on all messages sent through
this connector.

13. On the Delivery Restrictions tab, under By default, messages from


everyone are, click Rejected.

14. Under Accept messages from, click Add.

15. In Select Recipient, select Fabrikam Execs, click Add, and then click OK.

Public Folders

For complete information about public folders, how to use them, and how to
configure them, see your Exchange 2000 online documentation. The following

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 148
procedures describe the two most important public folder configuration performed
by Fabrikam administrators.

Configure Public Folder Permissions


You can specify the users and groups who can change the replication, limits, and
other settings for the public folder. The following procedure describes how to grant
administration rights to a public folder. There are other permissions you can grant
or deny to users in your organization, at different levels in your public folder
hierarchy. For more information about these procedures, see your Exchange 2000
online documentation.

To grant administration rights to a public folder

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Folders, and then expand the folder tree containing the folder you want.

3. Right-click a folder you want to grant administration rights, and then click
Properties.

4. In <folder name> Properties, on the Permissions tab, click Administrative


rights.

5. In Permissions for <folder name>, to grant access to a specific user, click


Add.

6. Select a user, and then click Add. Repeat this step for all users you want to add.

7. In Permissions for <folder name>, under Permissions for <user or


group>, select the Allow or Deny check box to grant or deny the selected user
or group access to the available options.

Configure Public Folder Replication


Public folders are created underneath top-level roots and belong to public folder
hierarchies. Each hierarchy has its own public folder store, and all folders in a
hierarchy are contained within the same public folder store. You are not required to
replicate every public folder in a public folder store. You can replicate a specific
public folder or subset of folders, or you can replicate all of them. You can configure
a public folder to have replicas on multiple public folder servers within an
organization.

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

The following procedure describes how to replicate a public folder; be aware that
there are many more options than the results of this procedure.

After you create a public folder store on an alternate server, you need to identify
which folders to replicate in that public folder store. Although the storage location
on the alternate server is associated with a specific folder hierarchy, the folders in
the public folder store are not replicated to the alternate server by default. You
must access the folder and specify that it should be replicated to the alternate
server.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 149
To add a replica (a copy of a public folder) to another public folder store

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Folders, and then expand the folder tree containing the folder you want to
replicate.

3. Right-click a folder you want to replicate, and then click Properties.

4. On the Replication tab, click Add.

5. Select a public folder store on the alternate server.

Transaction Logs

After the Exchange installation, Fabrikam administrators moved the transaction logs
to drive L on each computer running Exchange that contained user mailboxes.
Before you perform the following procedure, be sure to create a folder called
mdbdata on drive L.

To move the transaction logs

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, and then expand the appropriate server.

3. Right-click First Storage Group, and then click Properties.

4. In First Storage Group Properties, beside Transaction log location, click


Browse.

5. In Transaction Log, select L:\mdbdata, and then click OK.

Databases

After the Exchange installation, Fabrikam administrators moved the databases to


drive N on each computer running Exchange that contained user mailboxes. Before
you perform the following procedure, be sure to create a folder called mdbdata on
drive N.

To move the databases

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, and then expand the appropriate server.

3. Right-click First Storage Group, and then click Properties.

4. In First Storage Group Properties, beside System path location, click


Browse.

5. In System Path, select N:\mdbdata, and then click OK.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 150
6. In System Manager, expand First Storage Group, right-click Mailbox Store
(<server name>), and then click Properties.

7. In Mailbox Store (<server name>) Properties, click the Database tab.

8. Beside Exchange database, click Browse.

9. In Exchange Database, save priv1.edb and pub1.edb to N:\mdbdata.

10. Repeat Steps 6 through 9 for Public Folder Store (<server name>).

Log Buffers

After the Exchange installation, Fabrikam administrators used the following


procedure to increase the log buffers on all computers running Exchange. Fabrikam
administrators found the default value of 84 was too low for the back-end servers in
their organization.

To increase the size of the log buffers

1. Start the Microsoft Windows® 2000 Support Tool ADSI Edit. Support tools are
available on your Windows 2000 Server CD-ROM.

2. Expand Configuration Container [corp.fabrikam.com],


CN=Configuration,DC=corp,DC=Fabrikam,DC=com, CN=Services,
CN=Microsoft Exchange, CN=Fabrikam, CN=Administrative Groups,
CN=First Administrative Group, CN=Servers, and CN=<server name>.

3. Click First Storage Group, and then click Properties.

4. In First Storage Group Properties, on the Attributes tab, beside Select a


property to view, select msExchESEParamLogBuffers.

5. In the Edit Attribute box, type 9000, and then click OK.

Outlook Web Access

Fabrikam used the procedures in this section to configure Outlook Web Access. Be
aware that not every setting made by Fabrikam may be optimal for your
organization.

Configure the Server As a Front-End Server


Fabrikam administrators installed Exchange 2000 on MSGOWARI-01P, their
dedicated Outlook Web Access server. MSGOWARI-01P was placed in the perimeter
network in Richmond and acted as an Exchange front-end server, which means it
sends HTTP requests from Outlook Web Access users to their mailboxes behind the
intranet firewall. Table A.1 summarizes the ports that Fabrikam had to open in both
the Internet and intranet firewalls.

Important You must configure the virtual directories and HTTP virtual
server the same way on the Outlook Web Access server as they are on all
back-end servers. Take note of any configurations on one so that you can
do the same on the other. By default, the exchange and public virtual
directories are identical.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 151
To configure the server as a front-end server

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, and


then expand Servers.

3. Right-click MSGOWARI-01P, and then click Properties.

4. In MSGOWARI-01P Properties, on the General tab, select the This is a


front-end server check box.

5. Click OK, and then restart the computer.

Table A.1 Firewall ports opened for Outlook Web Access


Connection Connection to Firewall Protocol/ports used
from (Internet or
intranet)
Internet Outlook Web Access server Internet HTTPS/TCP 443
Outlook Web Domain controllers (DCRI-03P Intranet LDAP (to domain controller)/TCP 389
Access server and DCRI-04P) LDAP (to global catalog server)/TCP
3268
Kerberos/TCP 88 or Kerberos/UDP 88
DNS/TCP 53 or DNS/UDP 53
Outlook Web Back-end servers (MSGRI0- Intranet HTTP/TCP 80
Access server 1P, MSGAL-01P, and so on)
Outlook Web Internet Internet HTTPS/TCP 443
Access server
Local Fabrikam Outlook Web Access server Intranet HTTP/TCP 80 or HTTPS/TCP 443
users

Set the Default Domain Name


Fabrikam administrators used the following procedure so that Outlook Web Access
users did not have to specify a domain name during authentication. This
configuration was possible because all Fabrikam users were in the same domain,
corp.fabrikam.com.

To set the default domain name

1. Start System Manager. On the Start menu, point to Programs, point to


Microsoft Exchange, and then click System Manager.

2. Expand Administrative Groups, expand First Administrative Group, expand


Servers, expand MSGOWARI-01P, expand Protocols, expand HTTP, and
then expand Exchange Virtual Server.

3. Right-click Exchange, and then click Properties.

4. In Exchange Properties, on the Access tab, click Authentication.

5. In Authentication Methods, in the Default domain box, type the domain


name, corp.fabrikam.com.

Users do not have to authenticate themselves with a <domain name>\<user


name> format. Only a user name or logon ID is necessary.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 152
Reroute Users to a Secure Connection
If users accidentally type http:// instead of https:// when connecting to Outlook
Web Access, the following procedure automatically redirects them to a secure
connection.

To redirect users to a secure connection

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


then click Internet Information Services .

2. In Internet Information Services, expand *msgowari-01p, expand Web


Sites, right-click Default Web Site, and then click Properties.

3. In Default Web Site Properties, on the Directory Security tab, under


Secure communications, click Edit.

4. In Secure Communications, verify that the Require secure channel (SSL)


check box is not selected.

5. In <drive>:\inetpub\wwwroot, create an HTML file called default.htm. Make


the contents of this file:

<html>
<head>
<meta http-equiv=”refresh”
content=”0;URL=https://webmail.fabrikam.com/exchange”>
</head>
</html>

Install Digital Certificates for SSL Security


The IIS Web Server Certificate Wizard allows you to create and install a certificate
that enables SSL communications between the Outlook Web Access server and your
users.

To install a digital certificate

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


then click Internet Information Services.

2. In Internet Information Services, expand *msgowari-01p, expand Web


Sites, right-click Default Web Site, and then click Properties.

3. In Default Web Site Properties, on the Directory Security tab, under


Secure communications, click Server Certificate.

4. Use Web Server Certificate Wizard to create a new certificate, with a bit length
of 1024.

5. On the Your Site’s Common Name page, under Common name, type
webmail.fabrikam.com. This entry is very important. It must match the URL
you want users to type to access Outlook Web Access.

6. Provide the rest of the information, and then send your certificate request to a
certificate authority, such as VeriSign. You may need to fill out an enrollment
form on the certificate authority’s Web site.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 153
7. Upon approval, Fabrikam received its certificate in e-mail, as a cert.cer
attachment. Save this file on the Outlook Web Access server.

8. On MSGOWARI-01P, repeat Steps 1 through 3 above.

9. Enter the path to cert.cer.

Multimedia Outlook Web Access


As of January 2002, if Outlook Web Access users install the Exchange Multimedia
Control, but administrators did not install the HTML Source Edit component of
Microsoft Office 2000, the first time users run Outlook Web Access, the Office 2000
installer prompts them to insert the Office 2000 compact disc. Inserting the CD is
not necessary; users can click Cancel.

To fix this problem, install the HTML Source Editor.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 154
Appendix B Exchange Installation Checklists
To ensure that a consistent process was used to build each server in the Fabrikam
Worldwide organization, the Fabrikam migration team used checklists extensively.
In addition, the team saved checklists in a documentation folder on each server and
used the checklists for troubleshooting and maintenance purposes.

Fabrikam administrators used the first two checklists (Tables B.1 and B.2) to install
Microsoft® Exchange 2000 on servers that were intended for medium and small
offices. They used the last two checklists (Tables B.3 and B.4) to install a
bridgehead server and to install a front-end server used to process HTTP requests
by Outlook® Web Access users.

Use these checklists as a guideline for your own organization when you configure
the first Exchange server installed in your organization. Before you use any of these
checklists, remember to consult the installation prerequisites covered in “Installing
Exchange” in Chapter 3.

For more information about server roles (medium office mailbox server, bridgehead
server, and so on), see “Exchange Server Hardware Planning” in Chapter 2.

Note The primary difference among the large, medium, and small office
server configurations is the disk subsystem configuration.

Medium Office Mailbox Server

A computer running Exchange 2000 that is used to service a medium-sized office


can hold 40 to 100 mailboxes.

Table B.1 Installing Exchange in a medium office


Step Action

1 Receive server from the Microsoft Windows® 2000 team.


2 Confirm that the RAID configuration matches designed configuration:
• Two 9 GB or two 18 GB; RAID1; Disk 0
• Drive C: (3.71 GB); formatted NTFS; System
• Drive E: (1.17 GB); formatted NTFS; Operating system recovery partition
• Drive F: (1.59 GB); formatted NTFS; Application
• Drive Z: (2 GB); formatted NTFS; Paging (swap) file
• Two 9 GB; RAID1; Disk 1
• Drive L: (8.46 GB); formatted NTFS; Exchange transaction log files
• Four 18 GB; RAID5; Disk 2
• Drive N: (36 GB); formatted NTFS; Exchange databases and Exchange binary
files
Use the disk array management tool from your hardware vendor. Although Windows
provides software-level RAID, Microsoft Consulting Services recommends using the
hardware RAID provided by the SCSI controllers.
Note The Exchange transaction log files must be on a dedicated RAID1
drive set. Do not allow any other applications to use the Exchange 2000
transaction log set.

3 Verify Windows 2000 Licensing Mode is set to per seat.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 155
Step Action

4 Confirm TCP/IP settings:


1. At a command prompt, type ipconfig /all.
2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the
predetermined design.
Note DNS is critical for Exchange. If you install Exchange on a DNS server,
do not configure the DNS setting on the Exchange network interface card
(NIC) to the local server; instead, use another DNS server.

5 In My Network Places, verify that the File and Printer Sharing for Microsoft
Networks setting is set to Maximize Data Throughput For Network Applications.
6 Confirm that the computer name is set correctly, and then join the computer to the
domain (corp.fabrikam.com).
7 In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8 Create the MMC Exchange 2000 console, and add the following MMC snap-ins:
• Active Directory Users and Computers
• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Event Viewer
• Disk Management
• Services
Save the MMC at Desktop Level for All Users. For information about creating MMC
snap-ins, see your Windows 2000 online documentation.
9 On the desktop, rename the My Computer icon to <computer name>.
10 Perform the following steps:
1. Check Event Log properties.
2. Confirm that Maximum Log Size is set to 16384 for Application, System, and
Security log files.
3. Confirm that Overwrite as needed is selected.
11 Confirm the paging file is set to:
• Drive C: 5 MB
• Drive Z: 1955 MB
To confirm the paging file is set
1. On the desktop, right-click the <computer name> icon (formerly My Computer,
which you renamed in Step 9), and then click Properties.
2. In System Properties, on the Advanced tab, click Performance Options.
3. In Performance Options, under Virtual memory, click Change.
4. In Virtual Memory, check the paging file settings. If they are not set properly, type
the appropriate sizes, and then click Set.
Note These settings were optimized for Fabrikam’s networking
environment. Your organization may require different paging file settings. For
more information about paging files, see your Windows 2000 online
documentation.

12 Confirm that Maximum Registry Size set to 150 MB.


To confirm Maximum Registry Size is set
1. Follow the same procedure in Step 11.
2. In Virtual Memory, under Registry size, verify the Maximum registry size
(MB) setting is correct.
For more information, see your Windows 2000 online documentation.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 156
Step Action

13 If you have not done so already, add the /3gb switch to the Boot.ini file for servers with
more than 1 GB of memory.
For more information about this switch, see the Microsoft Knowledge Base article
Q266096, “XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of
Physical RAM,” at http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14 Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000
Server CD-ROM.) This test ensures correct Active Directory® directory service and DNS
integration and verifies where the Exchange servers look to find domain controllers,
global catalog servers, and other services.
Run the following variations of Nltest.exe in the corp.fabrikam.com domain:
• nltest /dsgetdc:corp
• nltest /dclist:corp
• nltest /dsgetsite
Note If you get an error, restart the Net Logon service. If restarting the
service does not correct the error, you have a DNS problem, or your
Windows 2000 sites are not defined correctly. You must work with Active
Directory and network administrators to remedy the situation before
proceeding.

15 Perform the following steps:


1. Start the Active Directory Sites and Services snap-in.
2. Expand Sites, expand Default-First-Site-Name (or whatever you have named
your first site), and then click Servers.
3. Confirm that the Exchange server is listed.
16 Insert the Exchange 2000 Enterprise CD-ROM and run Setup.
When prompted, be sure to install Exchange files to drive F.
17 Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at
http://go.microsoft.com/fwlink/?LinkId=5909.
Note After installing SP2, the help files for Outlook Web Access clients must
be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the
first screen you see when you launch EX2KSP2_server.exe), you must
select Outlook Web Access Help Files, and then double-click the
appropriate .msi file for each client language you support.

18 Move the transaction log files to the transaction log drive (drive L). For more information
about how to move the files, see “Transaction Logs” in Appendix A.
19 Move the Exchange databases to drive N. For more information about how to move the
databases, see “Databases” in Appendix A.
20 Create a mailbox recipient policy and start the mailbox management process. For more
information, see “Create a Mailbox Recipient Policy (Mailbox Manager)” in Appendix A.
21 Increase the log buffers. For more information about how to increase the log buffers, see
“Log Buffers” in Appendix A.

Small Office Mailbox Server

A computer running Exchange 2000 that is used to service a small office can hold up
to 40 mailboxes.

Table B.2 Installing Exchange in a small office


Step Action

1 Receive server from the Windows 2000 team.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 157
Step Action

2 Confirm that RAID configuration matches designed configuration:


• Two 9 GB or two 18 GB; RAID1; Disk 0
• Drive C: (3.71 GB); formatted NTFS; System
• Drive E: (1.17 GB); formatted NTFS; OS recovery partition
• Drive F: (1.59 GB); formatted NTFS; Application
• Drive Z: (2 GB); formatted NTFS; Paging (swap) file
• Two 9 GB; RAID1; Disk 1
• Drive L: (8.46 GB); formatted NTFS; Exchange transaction log files
• Two 18 GB; RAID1; Disk 2
• Drive N: (18 GB); formatted NTFS; Exchange databases and Exchange binary
files
Use the disk array management tool from your hardware vendor. Although Windows
provides software-level RAID, Microsoft Consulting Services recommends using the
hardware RAID provided by the SCSI controllers.
Note The Exchange transaction log files must be on a dedicated RAID1
drive set. Do not allow any other applications to use the Exchange 2000
transaction log set.

3 Verify Windows 2000 Licensing Mode is set to per seat.


4 Check TCP/IP settings:
1. At a command prompt, type ipconfig /all.
2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the
predetermined design.
Note DNS is critical for Exchange. If you install Exchange on a DNS server,
do not configure the DNS setting on the Exchange network interface card
(NIC) to the local server; instead, use another DNS server.

5 In My Network Places, verify that File and Printer Sharing for Microsoft Networks
setting is set to Maximize Data Throughput For Network Applications.
6 Confirm that the computer name is set correctly, and then join the computer to the
domain (corp.fabrikam.com).
7 In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8 Create the MMC Exchange 2000 console, and add the following MMC snap-ins:
• Active Directory Users and Computers
• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Event Viewer
• Disk Management
• Services
Save the MMC at Desktop Level for All Users. For information about creating MMC
snap-ins, see your Windows 2000 online documentation.
9 On the desktop, rename the My Computer icon to <computer name>.
10 Perform the following steps:
1. Check Event Log properties.
2. Confirm that Maximum Log Size is set to 16384 for Application, System, and
Security log files.
3. Confirm that Overwrite as needed is selected.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 158
Step Action

11 Confirm the paging file is set to:


• Drive C: 5 MB
• Drive Z: 1955 MB
To confirm the paging file is set
1. On the desktop, right-click the <computer name> icon (formerly My Computer,
which you renamed in Step 9), and then click Properties.
2. In System Properties, on the Advanced tab, click Performance Options.
3. In Performance Options, under Virtual memory, click Change.
4. In Virtual Memory, check the paging file settings. If they are not set properly, type
the appropriate sizes, and then click Set.
Note These settings were optimized for Fabrikam’s networking
environment. Your organization may require different paging file settings. For
more information about paging files, see your Windows 2000 online
documentation.

12 Confirm that Maximum Registry Size set to 150 MB.


To confirm Maximum Registry Size is set
1. Follow the same procedure in Step 11.
2. In Virtual Memory, under Registry size, verify the Maximum registry size
(MB) setting is correct.
For more information, see your Windows 2000 online documentation.
13 If you have not done so already, add the /3gb switch to the Boot.ini file for servers with
more than 1 GB of memory.
For more information about this switch, see the Microsoft Knowledge Base article
Q266096, “XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of
Physical RAM,” at http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14 Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000
Server CD-ROM.) This test ensures correct Active Directory and DNS integration and
verifies where the Exchange servers look to find domain controllers, global catalog
servers, and other services.
Run the following variations of Nltest.exe in the corp.fabrikam.com domain:
• nltest /dsgetdc:corp
• nltest /dclist:corp
• nltest /dsgetsite
Note If you get an error, restart the Net Logon service. If restarting the
service does not correct the error, you have a DNS problem, or your
Windows 2000 sites are not defined correctly. You must work with Active
Directory and network administrators to remedy the situation before you
proceed.

15 Perform the following steps:


1. Start the Active Directory Sites and Services snap-in.
2. Expand Sites, expand Default-First-Site-Name (or whatever you have named
your first site), and then click Servers.
3. Confirm that the Exchange server is listed.
16 Insert the Exchange 2000 Enterprise CD-ROM and run Setup.
When prompted, be sure to install Exchange files to drive F.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 159
Step Action

17 Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at
http://go.microsoft.com/fwlink/?LinkId=5909.
Note After installing SP2, the help files for Outlook Web Access clients must
be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the
first screen you see when you launch EX2KSP2_server.exe), you must
select Outlook Web Access Help Files, and then double-click the
appropriate .msi file for each client language you support.

18 Move the transaction log files to the transaction log drive (drive L). For more information
about how to move the files, see “Transaction Logs” in Appendix A.
19 Move the Exchange databases to drive N. For more information about how to move the
databases, see “Databases” in Appendix A.
20 Create a mailbox recipient policy and start the mailbox management process. For more
information, see “Create a Mailbox Recipient Policy (Mailbox Manager)” in Appendix A.
21 Increase the log buffers. For more information about how to increase the log buffer, see
“Log Buffers” in Appendix A.

Bridgehead Server

An Exchange 2000 bridgehead server contains one or more connectors, most


notably the SMTP connector, GroupWise connector, and Exchange 2000 Calendar
Connector. The bridgehead server handles all outgoing and incoming messages from
the Internet to users behind your firewall.

At Fabrikam, SMTP connectors communicated with two SMTP mail relay servers
outside the intranet firewall in Fabrikam’s perimeter network. A second firewall
protected the SMTP mail relay servers from the Internet, as illustrated in Figure 1.3
(in Chapter 1). In this scenario, no e-mail could reach a Fabrikam employee without
first passing through the Internet firewall, an SMTP mail relay server, the intranet
firewall, and finally an SMTP connector on a bridgehead server. For information
about configuring SMTP connectors, see the “SMTP connectors” section in Appendix
A.

The bridgehead server also contains the GroupWise connector and Exchange 2000
Calendar Connector, which allow the GroupWise and Exchange messaging systems
to communicate during coexistence.

Table B.3 Installing Exchange on a bridgehead server


Step Action

1 Receive server from the Windows 2000 team.


2 Confirm that RAID configuration matches designed configuration:
• Two 18 GB; RAID1; Disk 0
• Drive C: (3.71 GB); formatted NTFS; System
• Drive E: (1.17 GB); formatted NTFS; OS recovery partition
• Drive F: (10.59 GB); formatted NTFS; Application
• Drive Z: (2 GB); formatted NTFS; Paging (swap) file
3 Verify Windows 2000 Licensing Mode is set to per seat.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 160
Step Action

4 Confirm TCP/IP settings:


1. At a command prompt, type ipconfig /all.
2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the
predetermined design.
Note DNS is critical for Exchange. If you install Exchange on a DNS server,
do not configure the DNS setting on the Exchange network interface card
(NIC) to the local server; instead, use another DNS server.

5 In My Network Places, verify that the File and Printer Sharing for Microsoft
Networks setting is set to Maximize Data Throughput For Network Applications.
6 Confirm that the computer name is set correctly, and then join the computer to the
domain (corp.fabrikam.com).
7 In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8 Create the MMC Exchange 2000 console, and add the following MMC snap-ins:
• Active Directory Users and Computers
• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Event Viewer
• Disk Management
• Services
Save the MMC at Desktop Level for All Users. For information about creating MMC
snap-ins, see your Windows 2000 online documentation.
9 On the desktop, rename the My Computer icon to <computer name>.
10 Perform the following steps:
1. Check Event Log properties.
2. Confirm that Maximum Log Size is set to 16384 for Application, System, and
Security log files.
3. Confirm that Overwrite as needed is selected.
11 Confirm the paging file is set to:
• Drive C: 5 MB
• Drive Z: 1955 MB
To confirm the paging file is set
1. On the desktop, right-click the <computer name> icon (formerly My Computer,
which you renamed in Step 9), and then click Properties.
2. In System Properties, on the Advanced tab, click Performance Options.
3. In Performance Options, under Virtual memory, click Change.
4. In Virtual Memory, check the paging file settings. If they are not set properly, type
the appropriate sizes, and then click Set.
Note These settings were optimized for Fabrikam’s networking
environment. Your organization may require different paging file settings. For
more information about paging files, see your Windows 2000 online
documentation.

12 Confirm that Maximum Registry Size set to 150 MB.


To confirm Maximum Registry Size is set
1. Follow the same procedure in Step 11.
2. In Virtual Memory, under Registry size, verify the Maximum registry size
(MB) setting is correct.
For more information, see your Windows 2000 online documentation.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 161
Step Action

13 If you have not done so already, add the /3gb switch to the Boot.ini file for servers with
more than 1 GB of memory,
For more information about this switch, see the Microsoft Knowledge Base article
Q266096, “XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of
Physical RAM,” at http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14 Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000
Server CD-ROM.) This test ensures correct Active Directory and DNS integration and
verifies where the Exchange servers look to find domain controllers, global catalog
servers, and other services.
Run the following variations of Nltest.exe in the corp.Fabrikam.com domain:
• nltest /dsgetdc:corp
• nltest /dclist:corp
• nltest /dsgetsite
Note If you get an error, restart the Net Logon service. If restarting the
service does not correct the error, you have a DNS problem, or your
Windows 2000 sites are not defined correctly. You must work with Active
Directory and network administrators to remedy the situation before you
proceed.

15 Perform the following steps:


1. Start the Active Directory Sites and Services snap-in.
2. Expand Sites, expand Default-First-Site-Name (or whatever you have named
your first site), and then click Servers.
3. Confirm that the Exchange server is listed.
16 Insert the Exchange 2000 Enterprise CD-ROM and run Setup.
When prompted, be sure to install Exchange files to drive F.
On the Component Selection page of Exchange 2000 Installation Wizard, select a
custom installation, and then select Microsoft Exchange Connector for Novell
GroupWise, as shown in Figure 3.3 (in Chapter 3).
17 Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at
http://go.microsoft.com/fwlink/?LinkId=5909.
18 Install Exchange 2000 Calendar Connector (available in SP1 and later). For information
about installing Calendar Connector, see the Exchange 2000 Server online
documentation.
19 Enable circular logging.
To enable circular logging
1. Start System Manager. On the Start menu, point to Programs, point to
Microsoft Exchange, and then click System Manager.
2. Expand First Administrative Group, expand Servers, and then expand
<bridgehead server name>.
3. Right-click First Storage Group, and then click Properties.
4. In First Storage Group Properties, on the General tab, select Enable circular
logging.
20 Set up the SMTP connector and the “Executive Group” SMTP connector. For information
about setting up the SMTP connectors, see “SMTP Connectors” in Appendix A.
21 Create a mailbox recipient policy and start the mailbox management process. For more
information, see “Create a Mailbox Recipient Policy (Mailbox Manager)” in Appendix A.
22 Increase the log buffers. For more information about how to increase the log buffers, see
“Log Buffers” in Appendix A.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 162
Outlook Web Access Server

The Outlook Web Access server is an Exchange 2000 front-end server that handles
HTTP requests. The requests come from users who access their Exchange mailbox
data with a Web browser.

At Fabrikam, the Outlook Web Access server (MSGOWARI-01P) was placed in the
perimeter network, as illustrated in Figure 2.14 (in Chapter 2). Objects in the
perimeter network are inside the Internet firewall but outside the intranet firewall.

The following checklist details the basic procedures for installing and configuring an
Outlook Web Access server. For more detailed information about installing Outlook
Web Access, see “Outlook Web Access” in Appendix A. For more information about
the basics of Outlook Web Access and Exchange 2000 front-end and back-end
architecture, see “Outlook Web Access” in Chapter 2.

Table B.4 Installing Exchange on an Outlook Web Access server


Step Action

1 Receive server from the Windows 2000 team.


2 Confirm that RAID configuration matches designed configuration:
• Two 18 GB; RAID1; Disk 0
• Drive C: (3.71 GB); formatted NTFS; System
• Drive E: (1.17 GB); formatted NTFS; OS recovery partition
• Drive F: (10.59 GB); formatted NTFS; Application
• Drive Z: (2 GB); formatted NTFS; Paging (swap) file
3 Verify Windows 2000 Licensing Mode is set to per seat.
4 Confirm TCP/IP settings:
1. At a command prompt, type ipconfig /all.
2. Confirm IP Address, Subnet Mask, Default Gateway, and DNS servers all match the
predetermined design.
Note DNS is critical for Exchange. If you install Exchange on a DNS server,
do not configure the DNS setting on the Exchange network interface card
(NIC) to the local server; instead, use another DNS server.

5 In My Network Places, verify that File and Printer Sharing for Microsoft Networks
setting is set to Maximize Data Throughput For Network Applications.
6 Confirm that the computer name is set correctly, and then join the computer to the
domain (corp.fabrikam.com).
7 In the corp.fabrikam.com domain, log on with the ExchSrvc account.
8 Create the MMC Exchange 2000 console, and add the following MMC snap-ins:
• Active Directory Users and Computers
• Active Directory Domains and Trusts
• Active Directory Sites and Services
• Event Viewer
• Disk Management
• Services
Save the MMC at Desktop Level for All Users. For information about creating MMC
snap-ins, see your Windows 2000 online documentation.
9 On the desktop, rename the My Computer icon to <computer name>.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 163
Step Action

10 Perform the following steps:


1. Check Event Log properties.
2. Confirm that Maximum Log Size is set to 16384 for Application, System, and
Security log files.
3. Confirm that Overwrite as needed is selected.
11 Confirm the paging file is set to:
• Drive C: 5 MB
• Drive Z: 1955 MB
To confirm the paging files is set
1. On the desktop, right-click the <computer name> icon (formerly My Computer,
which you renamed in Step 9), and then click Properties.
2. In System Properties, on the Advanced tab, click Performance Options.
3. In Performance Options, under Virtual memory, click Change.
4. In Virtual Memory, check the paging file settings. If they are not set properly, type
the appropriate sizes, and then click Set.
Note These settings were optimized for Fabrikam’s networking environment.
Your organization may require different paging file settings. For more
information about paging files, see your Windows 2000 online documentation.

12 Confirm that Maximum Registry Size set to 150 MB.


To confirm Maximum Registry Size is set
1. Follow the same procedure in Step 11.
2. In Virtual Memory, under Registry size, verify the Maximum registry size (MB)
setting is correct.
For more information, see your Windows 2000 online documentation.
13 If you have not done so already, add the /3gb switch to the Boot.ini file for servers with
more than 1 GB of memory,
For more information about this switch, see the Microsoft Knowledge Base article
Q266096, “XGEN: Exchange 2000 Requires /3GB Switch with More Than 1 Gigabyte of
Physical RAM,” at http://go.microsoft.com/fwlink/?LinkId=3052&ID=266096.
14 Run Nltest.exe. (This Windows 2000 Support Tool is available on the Windows 2000
Server CD-ROM.) This test ensures correct Active Directory and DNS integration and
verifies where the Exchange servers look to find domain controllers, global catalog
servers, and other services.
Run the following variations of Nltest.exe in the corp.Fabrikam.com domain:
• nltest /dsgetdc:corp
• nltest /dclist:corp
• nltest /dsgetsite
Note If you get an error, restart the Net Logon service. If restarting the
service does not correct the error, you have a DNS problem, or your
Windows 2000 sites are not defined correctly. You must work with Active
Directory and network administrators to remedy the situation before you
proceed.

15 Perform the following steps:


1. Start the Active Directory Sites & Services snap-in.
2. Expand Sites, expand Default-First-Site-Name (or whatever you have named your
first site), and then click Servers.
3. Confirm that the Outlook Web Access server is listed.
16 Insert the Exchange 2000 Enterprise CD-ROM and run Setup.
When prompted, be sure to install Exchange files to drive F.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 164
Step Action

17 Install Exchange 2000 Service Pack 2 (SP2). SP2 is available on the Web at
http://go.microsoft.com/fwlink/?LinkId=5909.
Note After installing SP2, the help files for Outlook Web Access clients must
be updated to SP2 manually. On the Exchange 2000 SP2 splash screen (the
first screen you see when you launch EX2KSP2_server.exe), you must select
Outlook Web Access Help Files, and then double-click the appropriate .msi
file for each client language you support.

18 Enable circular logging.


To enable circular logging
1. Start System Manager. On the Start menu, point to Programs, point to Microsoft
Exchange, and then click System Manager.
2. Expand First Administrative Group, expand Servers, and then expand <Outlook
Web Access server>. Right-click First Storage Group, and then click Properties.
3. In First Storage Group Properties, on the General tab, select Enable circular
logging.
19 To finish setting up the Outlook Web Access server, perform all the tasks in the “Outlook
Web Access” section of Appendix A.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 165
Appendix C Migration Flowchart
The following flowchart provides a logical view of the migration process at Fabrikam.
The migration team was divided into three groups. The two main groups were the
server migration team and the desktop migration team. The third, less formal group
was the logistics team, who was responsible for tracking migration details such as
which users migrate on a given night. The server migration team prepared the
Novell GroupWise and Microsoft® Exchange 2000 messaging systems and used
Exchange Migration Wizard to migrate users’ data. The desktop migration team
prepared employees’ computers running Microsoft Windows® 2000 Professional,
including setting up each user’s Microsoft Outlook® 2000 profile. The desktop team
also ensured that all employees had everything they needed after their mailbox data
was migrated from Exchange.

Appendix D Additional Resources


This appendix contains migration-related articles from the Microsoft® Knowledge
Base and other useful technical papers. Microsoft recommends that you read any of
these articles that may apply to your organization before you migrate users.

Microsoft Knowledge Base Articles

These articles can be accessed on the Web at http://support.microsoft.com/. To


search for a Microsoft Exchange 2000 article using a key word from the title or the
article ID number, select Exchange 2000 Server from the product menu. You can
also use the URL beside each article to access the information directly.
Article ID Title Summary URL
Q268496 XFOR: Migration Wizard Use a GroupWise client older than http://go.microsoft.com
Generates Dr. Watson Events version 5.5.3 on the migration /fwlink/?LinkId=3052&I
When Migrating from GroupWise server. D=268496
5.5
Q238285 XFOR: GroupWise Migration Fails The GroupWise migration account http://go.microsoft.com
with Event ID 4012 must be in the same post office /fwlink/?LinkId=3052&I
as the accounts you are trying to D=238285
migrate.
Q273349 XFOR: GroupWise Migration Is Always give the migration http://go.microsoft.com
Unsuccessful When Migration account proxy access to any /fwlink/?LinkId=3052&I
Account Is the Same as Mailbox account that you are migrating, D=273349
Owner even for the mailbox belonging to
the migration account.
Q258175 XFOR: Migrating from GroupWise You need to ensure that only the http://go.microsoft.com
5.x to Exchange 2000 May Cause migration account has proxy /fwlink/?LinkId=3052&I
Event 4012: Insufficient Access permissions on a user’s D=258175
Rights GroupWise account.
Q174254 XADM: GroupWise Users must GroupWise users must grant read http://go.microsoft.com
Grant Access Rights to be and write access to the migration /fwlink/?LinkId=3052&I
Migrated account for certain items in their D=174254
mailboxes, or those items will not
be migrated.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 166
Article ID Title Summary URL
Q198013 XFOR: GroupWise 5.x Migration Discusses causes for and http://go.microsoft.com
Error solutions to the error message: /fwlink/?LinkId=3052&I
An error occurred logging on to D=198013
the GroupWise 5 Admin API.
Q198014 XFOR: Troubleshooting Informative article addressing a http://go.microsoft.com
GroupWise 5.x Migration permissions error MCS has /fwlink/?LinkId=3052&I
Problems encountered from the migration D=198014
server.
Q266096 XGEN: Exchange 2000 Requires Explains how to install http://go.microsoft.com
/3GB Switch with More Than 1 Exchange 2000 on a computer /fwlink/?LinkId=3052&I
Gigabyte of Physical RAM that has more than 3 GB of RAM. D=266096
Q197132 Windows 2000 Active Directory Provides a summary of http://go.microsoft.com
FSMO Roles Windows 2000 FSMO roles. /fwlink/?LinkId=3052&I
D=197132
Q224543 Using Ldp.exe to Find Data in the Explains how to use an important http://go.microsoft.com
Active Directory Windows 2000 utility to query /fwlink/?LinkId=3052&I
Active Directory. D=224543
Q222059 Windows 2000 GSNW and CSNW Valuable troubleshooting http://go.microsoft.com
Do Not Support NetWare 5 IP information. /fwlink/?LinkId=3052&I
D=222059
Q235225 GSNW and CSNW Only Support Valuable troubleshooting http://go.microsoft.com
the IPX/SPX Protocol information. /fwlink/?LinkId=3052&I
D=235225

Technical Papers and Other Web Sites

• Microsoft Exchange Server, Novell GroupWise Web site:


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

• Coexistence and Migration Using Microsoft Exchange Connector for Novell


GroupWise
http://go.microsoft.com/fwlink/?LinkId=5907

• Team Model for Application Development


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

• Risk Management Process


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

• Mailbox Recovery for Microsoft Exchange 2000 Server


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

• ForestPrep and DomainPrep


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

• Best Practices for Deploying Full-Text Indexing


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

• Exchange 2000 Front-end and Back-end Topology


http://go.microsoft.com/fwlink/?linkid=4721

• Microsoft Exchange 2000 Internals: Installation and Setup


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

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 167
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 168
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part
of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY,
AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in
this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not
give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and
events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo,
person, place or event is intended or should be inferred.

 2002 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveSync, Outlook, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 169

You might also like