Professional Documents
Culture Documents
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 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
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
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.
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.
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
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:
• 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.
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
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
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:
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.
During the planning phase, the Fabrikam migration team performed the following
tasks:
• 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 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
Proactively managing risks, real or anticipated, is crucial for any project, and a
migration from GroupWise project is no exception.
• 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.)
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.
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.
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).
• 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.
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.
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 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.
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 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.
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.
• The mail account that receives feedback from the Fabrikam Web site; this
account is monitored by a group of administrators.
• Group calendars.
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.
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
https://webmail.fabrikamworldwide.com
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.
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 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.
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.
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 reduce the number of mail servers and centralize them?
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.
• 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.
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
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:
Fabrikam corporate policy is to delete all e-mail messages older than 45 days. The
Exchange 2000 messaging system must continue this policy.
Exchange provides the capability to link the mailbox of a user account to a new
account. This linking can be done as long as the mailbox is linked within a specified
interval called the deleted mailbox recovery period.
Fabrikam 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.
• 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
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:
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.
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.
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
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).
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.
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
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
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
By the end of the planning phase, the following deliverables were produced:
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.
• Naming standards
• Hardware requirements
• System policies
• Public folders
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).
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.
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
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.
• Local archives
• Centralized administration
• External entities
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.
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.
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.
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.
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.
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.
• 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.
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:
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.
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.
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.
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.
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.
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.
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.
• Policies
• Address lists
• Storage groups
• Mailbox stores
Although the characters in Table 2.5 are not prohibited in other Exchange object
names, avoid the use of such special characters whenever possible.
• You can install only one Exchange organization per Active Directory forest.
For Fabrikam Worldwide, Inc., the migration team recommended the organization name
Fabrikam.
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.
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.
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
• First name
• Initials
• Last name
• Full name (by default, Windows 2000 generates Full name from the first
name, middle initial, and last 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.
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.
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.
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.
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.
• Dashes will be used instead of spaces when connecting multiple words together
in the alias and display name.
• 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
For more information about drive letters, see “Exchange Server Hardware Planning”
later in this chapter.
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:
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.
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.
• Adds the Exchange Domain Servers group to the Exchange Enterprise Servers
group.
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.
Fabrikam decided on the following goals for its Exchange administrative model:
Figure 2.6 shows the administrative group design as displayed in System Manager,
the primary Exchange management tool.
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.
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.
After the migration team analyzed Fabrikam’s network, the team suggested the
routing group design shown in Figure 2.7.
• 5 routing groups
Although this design is simple and straightforward, it does not allow for redundancy,
should any of Fabrikam’s WAN links become unavailable.
• 4 routing groups
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.
Because Fabrikam chose a design that requires added redundancy, the migration
team made Braintree a hub site, as shown in Figure 2.9.
• 5 routing groups
The design shown in Figure 2.10 builds on routing group design 3 and adds a
redundant path for the Alexandria office.
• 5 routing groups
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).
• 5 routing groups
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).
• 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 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
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.
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.
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
• Clustering
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).
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.
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
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.
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:
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.
100% - (100% ÷ n)
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.
The Fabrikam migration team made the following assumptions to determine the
design of its Exchange databases:
• Minimize the number of users in each Exchange database, but use more
databases.
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.
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:
Design Results
Table 2.9 illustrates how the storage requirements and design solutions described in
this section were implemented at each Fabrikam office location.
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.
• 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.
• 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.
• 2 GB RAM
• 2 GB RAM
• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; System
• 1 GB RAM
• Two 9-GB drives; RAID 1 (creates 9 GB total storage); formatted NTFS; System
• 1 GB RAM
Gateway/Bridgehead Server
• 1 GB RAM
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.
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.
For information about RAID and mirrored disk configurations, see your
Windows 2000 Server documentation.
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.
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.
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.13 lists the configuration settings that can be made on each tab.
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.
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.
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
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.
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
• First, the connector can only create Active Directory accounts in a single
organizational unit.
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.
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.
• Generates address lists (for example, the global address list [GAL], any custom
address lists, any offline address lists, and so on).
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.
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.
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.
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.
• 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.
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
• 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
Front-End Architecture
Figure 2.14 illustrates the planned configuration of the front end architecture.
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.
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.
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.
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.
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.
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.
• 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.
• 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.
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.
• 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.
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 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.
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.
When you configure portable computers for offline use in the Outlook 2000 client
configuration, select Enable Offline Folder (OST) Use. Select this option for
portable computers, but do not select this option for desktop computers. This option
creates a file on the local computer that mirrors the contents of the user’s mailbox,
including all of the items in the Exchange database. An .ost file can be very large, so
this option should not be used unless necessary. On a portable computer, an offline
file is useful because it allows the user to read and answer mail without being
constantly connected to the network over a phone line. On a desktop computer, the
server is assumed to be always available and using an offline file should not be
necessary.
Outlook Web Access 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).
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.
Outlook 2000
Outlook 2000 cannot match the following functionality that Fabrikam employees had
in GroupWise:
• 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.
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.
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.
The migration team decided to name the foreign domain in the GroupWise system
“Exchange.”
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.
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
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 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.
Figure 2.17 shows how mail is received from the Internet and routed between the
two messaging systems.
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.
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.
After the migration, Fabrikam users on Exchange will have multiple e-mail
addresses associated with their account. They are as follows:
• 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.
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.
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).
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.
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.
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.
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.
Migration Considerations
As you plan your migration, the following sections contain other data and process
considerations for migration.
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.
• 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.
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 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.
Personal Dictionaries
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
• Local archives
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.
1. A member of the migration team logs on to one of the migration servers and
starts Exchange Migration Wizard.
2. Migration Wizard reads users’ mail in their GroupWise mailboxes and then
converts the mail to an Exchange format. After conversion, Migration Wizard
puts the mail into the users’ new Exchange mailboxes.
3. During the migration process, Migration Wizard creates a message in each user’s
Exchange mailbox with the subject line Calendar Information. This message
contains an attachment that contains the user’s GroupWise calendar information.
During the setup of the user’s computer running Windows 2000 Professional,
including Outlook 2000 (at Fabrikam this task was performed by a dedicated
desktop team), an administrator uses the Outlook Import and Export Wizard to
complete the migration of the calendar information.
Figure 2.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.
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.
7. The user copies the mail data that had been previously stored in the GroupWise
local archive to his or her .pst file.
Figure 2.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.
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.
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.
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.
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:
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.
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
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.
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.
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.
Fabrikam used the Active Directory Users and Computers Microsoft Management
Console (MMC) snap-in to create the following groups:
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.
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 administrators who ran DomainPrep belonged to the Domain Admins group
in the corp.fabrikam.com domain.
• 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.
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
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.
Use this checklist as a guideline for your own organization before you install your
first Exchange server.
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.
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.
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.
• SMTP and NNTP are installed on all servers that Exchange will be installed on.
• The team installing Exchange has all necessary Windows passwords and
permissions.
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.
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.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 103
Step Action
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.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 104
Step Action
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.
Use this checklist as a guideline for your own organization when you configure the
first Exchange server installed in your organization.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 106
Step Configuration Section in Appendix A
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.
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.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 107
administrators in your organization before making changes to your
GroupWise system.
Note This migration case study is based on Novell GroupWise version 5.5.
Based on the information above, Fabrikam installed the following patches on its API
gateway:
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.
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 (;).
For these changes to take effect, you must restart the API gateway.
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.
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.
6. Click Define additional properties, and then click Create to open the
GroupWise Gateway/Internet Agent property page.
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.
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.
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.
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.
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.
13. In Gateway Link, select the API gateway that connects to Exchange, and then
click OK.
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.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 111
After the migration team created the NTGateway group, the team performed the
following tasks:
• 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.
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.
• 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.
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.
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
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.
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.
3. Click Install.
6. When prompted, restart the computer. Perform the “To configure Gateway and
Client Services for NetWare” procedure immediately after you restart your
computer.
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.
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.
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.
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.
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.
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.
After configuring the connector, verify that the two GroupWise connector services
started.
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.
2. Open Windows Explorer, click the CD-ROM drive, and then open the calcon
directory.
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.
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.
5. In Select a Public Store, select the public folder stores on all other Exchange
servers, and then click OK.
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.
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.
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.
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).
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.
Your Exchange organization must be installed and running before you can configure
your migration servers.
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.
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.
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.
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.
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.
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.
• 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.
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).
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.
• Determined which GroupWise distribution lists to migrate and added them to the
tracking database.
• 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.
• Identified users with personal digital assistants (PDAs) and added this
information 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.
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.
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).
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.
4. On the Migration page, select Migrate from Novell GroupWise 5.x. Click
Next.
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.
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.
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).
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.
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?
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.
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.
1. Start System Manager. On the Start menu, point to Programs, point to Microsoft
Exchange, and then click System Manager.
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.
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.
1. Start System Manager. On the Start menu, click Programs, point to Microsoft
Exchange, and then click System Manager.
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.
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.
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.
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).
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).
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.
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.
4. In the details pane, right-click the mailbox you want, and then click Reconnect.
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.
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.
1. Start System Manager. On the Start menu, point to Programs, point to Microsoft
Exchange, and then click System Manager.
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.
1. Start System Manager. On the Start menu, point to Programs, point to Microsoft
Exchange, and then click System Manager.
3. Right-click the appropriate SMTP virtual server, and then click Properties.
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.
Distribution Lists
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 135
To restrict one or more users from sending messages to a distribution list
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.
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.
4. In the details pane, right click Default, and then click Properties.
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
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.
3. Right-click First Administrative Group, point to New, and then click System
Policy Container.
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.
2. In New Policy, select the General check box, and then click OK.
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.
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.
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.
Fabrikam administrators used the following procedure to configure their public store
policy.
2. In New Policy, select the Limits and Replication check boxes, and then click
OK.
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.
After the policy was created, administrators added all public folder stores to the
policy.
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.
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.
2. In New Policy, select the Limits check box, and then click OK.
After the policy was created, administrators added all mailbox stores to the policy.
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.
• 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.
3. In the details pane, right-click Default Policy, and then click Properties.
5. In New E-mail Address, click Novell GroupWise Address, and then click OK.
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.
3. In New Policy, under Property pages, select the E-Mail Addresses check
box, and then click OK.
8. In New E-mail Address, click SMTP Address, and then click OK.
10. On the E-Mail Addresses (Policy) tab, select the new SMTP address check
box.
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.
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.
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.
For complete information about mailbox recipient policies, see your Exchange 2000
online documentation.
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.
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.
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.
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.
After you create a mailbox recipient policy, Mailbox Manager does not run until you
activate it on the server object.
For complete information about the Recipient Update Service, see your
Exchange 2000 online documentation.
2. Expand Recipients.
3. Right-click Recipient Update Service, point to New, and then click Recipient
Update Service.
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.
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.
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.”
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.
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.
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.
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.
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.
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 (,).
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.
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 (,).
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.
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.
3. Right-click a folder you want to grant administration rights, and then click
Properties.
6. Select a user, and then click Add. Repeat this step for all users you want to add.
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
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.
Databases
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.
10. Repeat Steps 6 through 9 for Public Folder Store (<server name>).
Log Buffers
1. Start the Microsoft Windows® 2000 Support Tool ADSI Edit. Support tools are
available on your Windows 2000 Server CD-ROM.
5. In the Edit Attribute box, type 9000, and then click OK.
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.
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
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.
<html>
<head>
<meta http-equiv=”refresh”
content=”0;URL=https://webmail.fabrikam.com/exchange”>
</head>
</html>
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.
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.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 155
Step Action
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.
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.
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.
A computer running Exchange 2000 that is used to service a small office can hold up
to 40 mailboxes.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 157
Step Action
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
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
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.
Microsoft Exchange 2000 and Novell GroupWise Coexistence and Migration 160
Step Action
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.
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.
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.
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
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.
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.
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
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.
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