MCITP Microsoft Exchange Server 2007 Messaging Design and Deployment Study Guide phần 3 pdf

Designing and Planning Migration of Legacy Exchange Features

137

Migrating Public Folders

Microsoft has de-emphasized public folders in Exchange Server 2007—for example, free/busy
calendaring functionality is provided by the Availability service, and offline address books are
now distributed using HTTP or HTTPS and BITS (Background Intelligent Transfer Service).
Additionally, Microsoft is encouraging the use of SharePoint for collaboration, and is provid-
ing guidance for migrating public folders to SharePoint. However, public folders are still fully
supported, and system folders in particular are actually

required

in certain topologies. Fur-
thermore, for many enterprises that have developed custom applications or forms using public
folders, transitioning the data held in public folders to SharePoint is simply not feasible, so this
data must be migrated to Exchange Server 2007.

The result of the

Set-WebServicesVirtualDirectory

cmdlet can be verified using the

Get-
WebServicesVirtualDirectory

cmdlet as follows:

Get-WebServicesVirtualDirectory -Identity "

CAS_server

\EWS (Default Web Site)"

The output of the cmdlet will be as shown in this image:
Note that the

Set-WebServicesVirtualDirectory

cmdlet is also used to set the

–InternalURL


parameter for NLB clusters of CAS computers. For example, to set the Availability service to
use an internal NLB cluster named

nlb.wiley.com

instead of

cas1.wiley.com

, you would run
the following cmdlet:

Set-WebServicesVirtualDirectory -Identity "

CAS_server

" -InternalUrl "Https://
nlb.wiley.com/EWS/Exchange.asmx"

EXERCISE 4.1

(continued)

81461c04.fm Page 137 Thursday, December 13, 2007 9:07 AM

138

Chapter 4


Designing and Planning Coexistence and Migrations

In the rest of this section, references to public folders also apply to system

folders unless otherwise stated.

The following are the public folder features that have been removed or de-emphasized. The
strategy for dealing with these features is to retain a computer running Exchange 2000 or
Exchange Server 2003 in the organization. This applies to the following public folder features:


Public folder graphical user interface (GUI) management


Non-MAPI top-level hierarchies in a public folder store


Public folder access using Network News Transfer Protocol (NNTP)


Public folder access using IMAP4


Public folder access via Outlook Web Access (OWA)

In the RTM (Release to Manufacturing) version of Exchange Server 2007,
public folders were configurable only through the Exchange Management
Shell and were not accessible via OWA. However, in Exchange Server 2007
Service Pack 1, public-folder configuration was added to the Exchange Man-
agement Console (EMC) GUI, as was public-folder access via OWA, as
shown in Figures 4.3 and 4.4.
FIGURE 4.3 Public-folder management through SP1 EMC
81461c04.fm Page 138 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
139
FIGURE 4.4 Public folder access through SP1 OWA
Public Folder Hierarchy
The public folder hierarchy is contained in the public-folder database, and is replicated to all
public-folder databases in the Exchange organization, regardless of whether that database
contains replicas of public folders. This replication is independent of the public-folder content
replication, and is message-based.
The hierarchy contains information on the following:


Client public-folder permissions

A public folder’s description

Public folder priority settings

The public folder replication schedule

A public folder’s position within the public-folder hierarchy

The replica list for each public folder (which public folder databases host copies of the
public folder)
The hierarchy is referred to by clients accessing public folders, and provides the folder listing
displayed within Outlook as well as referrals to the appropriate public-folder replica so that
clients can access the data contained within the public folders.
81461c04.fm Page 139 Thursday, December 13, 2007 9:07 AM
140
Chapter 4

Designing and Planning Coexistence and Migrations
Public Folder Content
Public folder content is also contained within the public-folder database. Unlike with the public
folder hierarchy, public folder data is replicated selectively to databases hosting replicas of the
particular public folder, dictated by the replica lists configured by the administrator and stored
in the public folder hierarchy. Like with the public folder hierarchy, public folder content repli-
cation is message-based.
For various reasons, you may elect to deploy dedicated public folder servers in
your environment. A common error in planning and deploying multiple dedi-
cated public folder servers for redundancy is to configure all the mailbox data-
bases to use one of the dedicated servers as their client’s default public folders

database. Unfortunately, the default public folder database is the location from
which clients access the hierarchy, which provides them with information on
public-folder replicas and which databases contain that content. This means
that if the configured default public folder database is inaccessible, clients have
no way to locate other public folder replicas. In this case, it is better to create
public folder databases on each mailbox server to provide the hierarchy to the
clients, and host all the public-folder data on the dedicated servers. This way,
if one of the dedicated public-folder servers becomes unavailable, clients can
be referred to other replicas.
Creating a Public Folder Database
When you install the first Exchange Server 2007 computer hosting the Mailbox server role
into an existing Exchange Server 2003 environment, a public folder database is created on
that computer by default, and as with Exchange Server 2003 there can be only one public
folder database per Exchange Server 2007 computer. However, in an environment with a
large number of public folders, you may want to deploy a dedicated Exchange Server 2007
public folder server.
Exercise 4.2 outlines the steps to create a public folder database on an Exchange Server
2007 Mailbox server.
Although it is technically possible to create a public-folder database in an
existing storage group, Microsoft recommends in Exchange Server 2007 that
you create a separate storage group for each database—whether they are
mailbox or public folder databases.
81461c04.fm Page 140 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
141
EXERCISE 4.2
Public Folder Database Creation
To create a public-folder database, you first create a new storage group, and then you create
the database itself. Let’s walk through the steps for each.
Creating a New Storage Group

There are six steps to create a new storage group.
1. Click Start  Programs  Microsoft Exchange Server 2007, and then select Exchange
Management Console (EMC).
2. Under the Microsoft Exchange root object, expand the Server Configuration work center
and then select the Mailbox node.
3. Within the Mailbox result pane, select the server on which you want to add a storage group.
4. In the right-hand Actions pane for that Mailbox server, click the New Storage Group link
as seen here.
81461c04.fm Page 141 Thursday, December 13, 2007 9:07 AM
142
Chapter 4

Designing and Planning Coexistence and Migrations
5.
In the New Storage Group wizard shown in the next image, provide a name for the storage
group, specify the log files path and the system files path as necessary, and then select New.
6. Click Finish on the Completion screen of the New Storage Group wizard shown here to
complete the wizard and create the storage group.
EXERCISE 4.2 (continued)
81461c04.fm Page 142 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
143
Creating the Database
Now you are ready to create the database. Just follow these steps.
1. In the Exchange Management Console, highlight the storage group created previously
and select New Public Folder Database from the Action pane as seen here.
2. In the New Public Folder Database wizard shown next, enter a name for the database and
specify a database path to place the database on a separate disk from the storage group’s
transaction logs. Click New to create and mount the database.
EXERCISE 4.2 (continued)

81461c04.fm Page 143 Thursday, December 13, 2007 9:07 AM
144
Chapter 4

Designing and Planning Coexistence and Migrations
Migrating Public Folder Content
You can migrate public folders from Exchange Server 2003 to Exchange Server 2007 in
several ways. All public folder migration methods accomplish the same basic sequence of
events, however:
1. You create replicas of the source public folders on the target server (Exchange
Server 2007).
2. The public folder hierarchy is then replicated by Exchange, reflecting the changes you
have made in the replica lists for the public folders.
3. Based on the replica changes made by you, the public folder data is replicated from the
source server (Exchange Server 2003) to the target server by Exchange.
4. The source server is then removed from the replica lists of the public folders, either
manually by you or automatically through a script or Exchange utility.
5. The updated public folder hierarchy reflecting the removal of the source server from the
replica lists is replicated by Exchange.
6. Exchange removes the public folder data from the source server.
3. Click Finish on the Completion screen to close the New Public Folder Database wizard.
EXERCISE 4.2 (continued)
81461c04.fm Page 144 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
145
Migrating Public Folders Using Exchange System Manager
You can move public folders from Exchange Server 2003 to Exchange Server 2007 using the
Exchange System Manager GUI. Exercise 4.3 walks you through the necessary steps to do so.
Although using Exchange System Manager to migrate public folders is pos-
sible, this method may not be very practical in an enterprise environment

with a large number of public folders. You would probably employ scripts,
the Exchange Server 2007 Exchange Management Shell, third-party tools, or
some combination of those elements to achieve the economies of scale
required in a large public-folder migration.
Public Folder Replication
When you are planning your public folder implementation, it is important to note that there are
two types of replication involved (and in some cases, three). Here are the two most common:

The public folder hierarchy, which contains the replica lists and client permissions,
among other data, and is replicated separately from the public folder data

The public folder data, which, as mentioned earlier, replicates separately from the hierarchy
Neither of those replications are accomplished by Active Directory replication. Public-folder
hierarchy and data replication are message-based and the data is not stored in Active Direc-
tory. These system messages can be tracked using the same mechanisms as user messages;
as a consequence, email connectivity, routing, and addressing play a large role in the suc-
cessful replication of public folders.
The third type of replication that is used is Active Directory replication, but only if mail-enabled
public folders exist in the environment. These are represented in Active Directory, so they can be
assigned addresses and be listed in the address books. This is the only time when Active Directory
replication plays a direct role in public-folder replication.
EXERCISE 4.3
Migrating Public Folders with Exchange System Manager
In lieu of using the Exchange Server 2007 Exchange Management Shell (built on PowerShell)
you can migrate public folders using the Exchange Server 2003 Exchange System Manager
GUI. Let’s walk through the steps required to accomplish this.
1. On the Exchange Server 2003 computer or management station, click Start  All Pro-
grams  Microsoft Exchange  System Manager.
81461c04.fm Page 145 Thursday, December 13, 2007 9:07 AM
146

Chapter 4

Designing and Planning Coexistence and Migrations
2.
Within Exchange System Manager, expand Administrative Groups, expand the adminis-
trative group containing the Exchange Server 2003 public folders, expand Folders, and
expand Public Folders.
3. If you will be migrating system folders, right-click Public Folders and select View System
Folders from the context menu, as shown here.
4. Under Public Folders, right-click the public folder to move to Exchange Server 2007 and
select All Tasks  Manage Settings from the context menu as shown here.
EXERCISE 4.3 (continued)
81461c04.fm Page 146 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
147
5. On the Welcome screen of the Manage Public Folder Settings Wizard, click Next.
6. On the Specify Action screen, select Modify Lists of Replica Servers and click Next.
EXERCISE 4.3 (continued)
81461c04.fm Page 147 Thursday, December 13, 2007 9:07 AM
148
Chapter 4

Designing and Planning Coexistence and Migrations
7.
On the next Specify Action screen, select Replace a Server and click Next.
8. On the Replace a Replica Server screen, confirm that Replica Server to Replace has the
source Exchange Server 2003 computer listed. Select the target Exchange Server 2007
computer from the Replacement drop-down list and click Next.
EXERCISE 4.3 (continued)
81461c04.fm Page 148 Thursday, December 13, 2007 9:07 AM

Designing and Planning Migration of Legacy Exchange Features
149
Migrating Public Folders Using Scripts
A more practical method of migrating public folders from Exchange Server 2003 to Exchange
Server 2007 is to use scripts via the Exchange Management Shell. Exchange Server 2007 comes
with several PowerShell scripts for managing public folders, including the MoveAllReplicas.ps1
and AddReplicaToPFRecursive.ps1 scripts, which can be used to move public folder replicas.
These scripts can be found in the c:\Program Files\Microsoft\Exchange Server\Scripts
directory, where c: is the drive where Exchange Server 2007 was installed.
Exercise 4.4 outlines the steps for migrating public folders using the MoveAllReplicas
.ps1 and AddReplicaToPFRecursive.ps1scripts.
9. On the Completing the Manage Public Folders Settings Wizard screen, confirm your
selections and click Finish.
EXERCISE 4.4
Migrating Public Folders with Scripts
In most larger environments, you will find it more practical to use the PowerShell scripts pro-
vided with Exchange Server 2007 to migrate your public folders. This exercise will walk you
through the steps necessary to accomplish this.
1. Start the Exchange Management Shell by selecting Start  All Programs  Microsoft
Exchange Server 2007  Exchange Management Shell.
2. Within the Exchange Management Shell, enter cd “c:\Program Files\Microsoft\
Exchange Server\Scripts” and press Enter.
EXERCISE 4.3 (continued)
81461c04.fm Page 149 Thursday, December 13, 2007 9:07 AM
150
Chapter 4

Designing and Planning Coexistence and Migrations
Offline Address Books
In Exchange Server 2003 and earlier, offline address books (OABs) were stored in and distributed

from public folders—system folders in particular. However, Exchange Server 2007 has introduced
a new method of distributing offline address books called Web-based distribution that uses HTTP
(or HTTPS) and BITS. This new distribution mechanism has the potential to provide greater control
over distribution points, support more concurrent clients, and reduce bandwidth consumption.
In a new Exchange Server 2007 environment, Web-based distribution is configured by
default, and for internal use no further configuration is generally required. If you did not specify
that you have clients running Entourage or Outlook 2003 or earlier during setup, then no public
folder databases are created and offline address book distribution will be exclusively web-based.
As in Exchange Server 2003, the offline address book can be generated in three versions to
support various clients, as Table 4.2 outlines:
3. To move a public folder called Ex2003TL and all of its subfolders within that hierarchy
from Exchange Server 2003 to Exchange Server 2007, run the following command:
ReplaceReplicaOnPFRecursive.ps1 -TopPublicFolder "\Ex2003TL" -ServerToAdd
Targetserver -ServerToRemove Sourceserver
In that command, the following is true:
Targetserver is the Exchange Server 2007 server folders are being moved to.
Sourceserver is the Exchange Server 2003 server public folders are being removed from.
4. To replicate all public folders from Server01 to Server02, run the following command:
MoveAllReplicas.ps1 -Server Sourceserver -NewServer Targetserver
In that command, the following is true:
Sourceserver is the source Exchange Server 2003 computer.
Targetserver is the target Exchange Server 2007 computer.
TABLE 4.2 Offline Address Book Versions
OAB Version Clients Supported
Version 2 Outlook 98 SP1 or earlier
Version 3 Outlook 98 SP2 or later
Version 4 Outlook 2003 SP2 or later
EXERCISE 4.4 (continued)
81461c04.fm Page 150 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features

151
If you require OAB versions prior to version 4 in your environment to support
older Outlook clients, then you will also need to retain public folder distribution.
When introducing Exchange Server 2007 into an existing Exchange 2000 Server or
Exchange Server 2003 organization (a much more common scenario), however, you will need
to configure web-based distribution if you will be supporting Outlook 2007 clients. When you
introduce the first Exchange Server 2007 server into your organization, the offline address
book remains hosted on Exchange 2000 Server or Exchange Server 2003, and web-based dis-
tribution is unavailable, as shown in Figure 4.5. After all clients have been upgraded to Out-
look 2007 and all mailboxes have been moved to Exchange Server 2007, public folder
distribution can be disabled.
FIGURE 4.5 Exchange Server 2003 offline address book
To enable web-based distribution, the offline address book needs to be moved to an
Exchange Server 2007 computer, as Exchange 2000 Server and Exchange Server 2003 do
not support this feature.
If you have users with Outlook 2007, then during the migration phase to
Exchange Server 2007 from Exchange 2000 Server or Exchange Server 2003,
you will need to support both web-based and public-folder distribution for
offline address books until all users are migrated. Additionally, if any users
will be remaining on Outlook 2003 or earlier after the migration is completed,
you will need to continue supporting public-folder distribution for your offline
address books.
81461c04.fm Page 151 Thursday, December 13, 2007 9:07 AM
152
Chapter 4

Designing and Planning Coexistence and Migrations
Migrating Offline Address Books Using Exchange
Management Console
Exercise 4.5 outlines the steps to move an offline address book from Exchange Server 2003 to

Exchange Server 2007 and enable web-based distribution.
EXERCISE 4.5
Migrating an Offline Address Book with Exchange Management Console
As with many Exchange Server 2007 tasks, you can migrate offline address books through the
Exchange Management Console GUI or with PowerShell via the Exchange Management Con-
sole. In this exercise, you will walk through the offline address book migration using the GUI.
Moving the Offline Address Book
1. Click Start  Programs  Microsoft Exchange Server 2007, and then select Exchange
Management Console.
2. Under the Microsoft Exchange root object, expand the Organization Configuration work
center and then select the Mailbox node.
3. Within the Mailbox result pane, select the Offline Address Book tab.
4. In the right-hand Actions pane, select the Move link in the Default Offline Address List
section, as shown here.
81461c04.fm Page 152 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
153
5. In the Move Offline Address Book wizard shown next, click Browse and select the
Exchange Server 2007 computer to move the offline address book to. Select Move to
begin the move operation.
6. On the Completion screen of the Move Offline Address Book wizard, read the warning
advising you not to turn off public-folder publishing before the offline address book is
generated on the target folder, and then click Finish.
EXERCISE 4.5 (continued)
81461c04.fm Page 153 Thursday, December 13, 2007 9:07 AM
154
Chapter 4

Designing and Planning Coexistence and Migrations
Enabling Web-Based Distribution

Once you have moved the offline address book to Exchange Server 2007, you can enable
web-based distribution for Outlook 2007 clients as outlined here.
1. Back in the Mailbox node of the Organization Configuration work center, select the
Offline Address Book tab.
2. In the right-hand Actions pane, select the Properties link in the Default Offline Address
List section, as shown here.
3. In the Default Offline Address List Properties dialog, select the Distribution tab, then
select the Enable Web-Based Distribution check box. Click Add to access the Select OAB
Virtual Directory dialog.
EXERCISE 4.5 (continued)
81461c04.fm Page 154 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
155
4. In the Select OAB Virtual Directory dialog, select the virtual directory to host the OAB and
click OK to return to the Default Offline Address List Properties dialog.
5. Click OK to apply the changes and close the Default Offline Address List Properties dialog.
6. Back in the Exchange Management Console, select Update in the right-hand Actions
pane in the Default Offline Address List section, as shown here. Select Yes in the confir-
mation dialog to regenerate the address book.
EXERCISE 4.5 (continued)
81461c04.fm Page 155 Thursday, December 13, 2007 9:07 AM
156
Chapter 4

Designing and Planning Coexistence and Migrations
Migrating Offline Address Books Using Exchange
Management Shell
Alternatively, migrating the offline address book can be accomplished using Exchange Man-
agement Shell cmdlets.
For an Exchange organization with a single offline address book, the cmdlet to move

the Default Offline Address List from an Exchange Server 2003 computer called E31 to an
Exchange Server 2007 computer called E72 would be as follows:
Get-OfflineAddressBook -Server E31 | Move-OfflineAddressBook -Server E72
The Move-OfflineAddressBook cmdlet requires the GUID of the offline address book to
be moved. The Get-OfflineAddressBook cmdlet retrieves the Default Offline Address List
from the source server, and this output is then piped to the Move-OfflineAddressBook
cmdlet to provide the GUID of the offline address book to be moved.
The Default Offline Address List on Exchange Server 2007 computer E72 can be updated
as follows:
Get-OfflineAddressBook -Server E72 | Update-OfflineAddressBook
Enabling web-based distribution for this address book requires either determining the
virtual directory to be used for a distribution point or creating a new one for the purpose.
In an environment with a single Exchange Server 2007 Client Access Server (CAS) named
E71, the following cmdlets will determine the OAB virtual directory on E71, then configure
web-based distribution for the Default Offline Address List using the OAB virtual directory
on E71 as the distribution point:
$a=Get-OabVirtualDirectory -Server E71
and
Set-OfflineAddressBook "Default Offline Address List" -VirtualDirectories $a
Recipient Update Service Migration
The Recipient Update Service (RUS) component first introduced in Exchange 2000 Server and
carried over to Exchange Server 2003 has been removed from Exchange Server 2007. This is
because recipients in Exchange Server 2007 are fully provisioned as they are created, making
the RUS unnecessary. However, you need to provide RUS functionality in a mixed environ-
ment for the duration of your migration. You also need to know how to update recipients in
your Exchange Server 2007 organization when your migration is completed.
An Overview of RUS
Introduced in Exchange 2000 Server and used in Exchange Server 2003 as well, the job of the
RUS is to locate newly created recipient objects in Active Directory and provision them by cre-
ating Exchange-specific attribute values in Active Directory. The RUS is also responsible for

updating existing objects by modifying the appropriate attributes in Active Directory. There
81461c04.fm Page 156 Thursday, December 13, 2007 9:07 AM
Designing and Planning Migration of Legacy Exchange Features
157
are two types of the RUS in an Exchange organization: One is called the Enterprise Configu-
ration Recipient Update Service, and there is only one instance of this type per organization.
The second type is the domain Recipient Update Service; as its name implies, there is one
instance of the domain RUS for each domain that contains mailbox-enabled users.
When a mail or mailbox-enabled recipient object (such as a user or group) is created in
Exchange 2000 Server or Exchange Server 2003 using the Active Directory Users and Com-
puters (ADUC) console, a few key attributes are set immediately by the console. This allows
the RUS to discover the new object and backfill the remaining Exchange-specific attributes in
an asynchronous process.
In Exchange Server 2007, the primary changes in this process are that recipient objects are
fully provisioned as they are created in the Exchange Management Console GUI or the Exchange
Management Shell command shell, and that the background process to discover and update
objects has been removed. In essence, the “service” part of Recipient Update Service no longer
exists. This means that mailboxes can be used immediately after being created in Exchange
Server 2007; in Exchange 2000 Server or Exchange Server 2003 the RUS had to stamp the user
object before the mailbox was accessible. When the RUS worked, it was great, but when prob-
lems arose it could be complicated to troubleshoot—because it was an asynchronous process it
was difficult to determine if it wasn’t working, or if was just working slowly.
Another role of the RUS was to apply recipient policies in Exchange 2000 Server and
Exchange Server 2003, and to update recipients when recipient policies were modified. Because
the RUS is not present in Exchange Server 2007, you need to implement various processes to
update recipients due to changes in policies; this will be covered in the next section.
RUS Migration Considerations
There are implications of the asynchronous recipient update process being removed from Exchange
Server 2007 in a mixed environment. One implication is that setting an Exchange Server 2007 com-
puter as the “Exchange server” for an existing RUS instance through the Exchange System Manager

GUI will cause that instance to stop working. Until all recipients have been moved to Exchange
Server 2007, you must retain the RUS functionality on an Exchange 2000 Server or Exchange Server
2003 computer, including for domains containing only Exchange Server 2007 computers.
Even after all recipients have been moved to Exchange Server 2007, some user-provisioning tools
or processes may partially provision users expecting the RUS to complete the provisioning process,
and changes to E-mail Address Policies in Exchange Server 2007 may have to be applied to existing
users. This procedure can be accomplished easily with the Update-EmailAddressPolicy and
Update-AddressList cmdlets. The Update-EmailAddressPolicy cmdlet updates recipients
based on the defined E-mail Address Policies, and the Update-AddressList cmdlet updates your
address lists with recipients changes, so these cmdlets should be run together and in that order.
Running these cmdlets is easier if you combine them with their corresponding get cmdlets
as follows:
Get-EmailAddressPolicy | Update-EmailAddressPolicy
Get-AddressList | Update-AddressList
In addition, to update the Global Address List you can run the following:
Get-GlobalAddressList | Update-GlobalAddressList
81461c04.fm Page 157 Thursday, December 13, 2007 9:07 AM
158
Chapter 4

Designing and Planning Coexistence and Migrations
Designing Migration Strategies
The most common Exchange Server 2007 scenario you will encounter is a migration from
Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007. In this section, we
will cover the primary factors to consider when planning your migration strategy.
Message Routing
One of the most important factors to consider when designing your Exchange Server 2007
migration strategy, whether it’s an inter-forest or intra-forest migration, is your Active Direc-
tory site design. In Exchange 2000 Server and Exchange Server 2003, mail routing between
servers in different locations was controlled by routing groups and the routing group connec-

tors created between them using link-state routing. A routing group was defined as a collection
of Exchange servers that have full-time, high-bandwidth connectivity between all members.
This was done to separate Exchange message routing from Active Directory replication.
In Exchange Server 2007, the concept of routing groups has been dropped and message
routing between servers in different locations is implemented by leveraging the existing Active
Directory site topology and least-cost routing. This means that before implementing Exchange
Server 2007, your Active Directory site structure should be reviewed for configuration errors
and optimized as necessary to accommodate Exchange Server 2007’s requirements. In a mixed
environment with Exchange 2000 Server or Exchange Server 2003, all Exchange 2007 com-
puters are associated with a single routing group to allow for message routing to those earlier
versions of Exchange.
In a mixed environment all Exchange Server 2007 computers are placed in a
single routing group named Exchange Routing Group (DWBGZMFD01QNBJR).
The DWBGZMFD01QNBJR is a simple shift replacement cipher; if you change
each letter and number to the next letter in the alphabet or number in
sequence, you get EXCHANGE12ROCKS.
Exchange Server 2007 and Exchange 2000 Server or Exchange Server 2003 com-
puters can’t be in the same routing group, and you can’t create additional routing
groups to hold Exchange Server 2007 computers. Exchange Server 2007 com-
puters must reside in Exchange Routing Group (DWBGZMFD01QNBJR), and this
routing group can’t be renamed.
Exchange Server 2007 and Administrative Groups
Exchange 2000 Server and Exchange Server 2003 used the concept of administrative groups to
allow for delegation of subsets of the Exchange organization to different administrators. While
delegation of administration is a good thing, this model was not as flexible as it could have been.
81461c04.fm Page 158 Thursday, December 13, 2007 9:07 AM
Designing Migration Strategies
159
For example, an Exchange Server 2003 or Exchange 2000 Server computer could not be moved
from one administrative group to another; once a computer was deployed into an administrative

group it was stuck there unless it was removed and re-installed.
In Exchange Server 2007, administrative groups have been replaced with a much more flexible
delegation model that allows for delegation from the organization level down to the server level,
as well as by roles (for example, Exchange Recipient Administrators). For coexistence purposes,
when Exchange Server 2007 is introduced into an Exchange 2000 Server or Exchange Server 2003
organization, all Exchange Server 2007 computers are installed in an administrative group called
Exchange Administrative Group (FYDIBOHF23SPDLT).
Similar to the Exchange Server 2007 routing group, the FYDIBOHF23SPDLT
portion of the Exchange Server 2007 administrative group’s name is a simple
shift replacement cipher; in this case if you change each letter and number to
the previous letter in the alphabet or to the previous number in sequence, you
again arrive at EXCHANGE12ROCKS.
Managing Mailboxes in a Coexistence Environment
In a coexistence environment, Exchange Server 2003 mailboxes are managed using the Active
Directory Users and Computers (ADUC) snap-in extension for Exchange, while Exchange
Server 2007 mailboxes are managed with the Exchange Server 2007 Exchange Management
Console (GUI) or Exchange Management Shell (command line).
Exchange Server 2007 mailboxes must not be managed by using the Exchange
Server 2003 tools. This is not blocked from happening, but Exchange Server 2007
mailboxes modified with the ADUC Exchange Server 2003 snap-in will not be
fully functional.
All mailbox moves between Exchange Server 2003 and Exchange Server 2007 (in either direc-
tion) can be performed with the Exchange Server 2007 tools, but the Exchange Server 2003 move
mailbox functionality can’t be used for any mailbox moves involving Exchange Server 2007 as
either source or destination. In addition, you can modify and remove Exchange 2000 Server and
Exchange Server 2003 mailboxes with the Exchange Server 2007 tools, but you can’t create mail-
boxes on Exchange 2000 Server or Exchange Server 2003 with the Exchange Server 2007 tools.
To create Exchange 2000 Server or Exchange Server 2003 mailboxes, you must use the ADUC
Exchange snap-in.
Discontinued Features

Table 4.3 details the Exchange 2000 Server features that are not supported in Exchange
Server 2007. If any of these features need to be retained, Exchange 2000 Server computers
must be maintained in the environment or the service must be migrated to an Exchange
Server 2007–supported equivalent.
81461c04.fm Page 159 Thursday, December 13, 2007 9:07 AM
160
Chapter 4

Designing and Planning Coexistence and Migrations
The following list shows the Exchange Server 2003 features not supported in Exchange
Server 2007. Organizations using the GroupWise Connector need to either maintain an
Exchange Server 2003 computer to run this service or migrate from GroupWise to Exchange
Server 2007.

Novell GroupWise Connector

Network News Transfer Protocol (NNTP)
Inter-Forest Migration
One consideration when migrating to Exchange Server 2007 is whether to introduce Exchange
Server 2007 into your existing Exchange 2000 Server or Exchange Server 2003 organization, or
to deploy Exchange Server 2007 into a separate organization. As the rule of one Exchange orga-
nization per Active Directory forest still applies, this means deploying a separate AD forest as
well. An inter-forest migration is considerably more complex than an intra-forest one, but you
may have to undertake it for reasons such as the following:

Company divestiture—a division of your organization is splitting off due to business or
technical reasons.

Company merger, acquisition, or consolidation—you are consolidating from multiple
forests down to fewer forests or one forest.


Separating Active Directory and Exchange administration.
In many ways, the implications of and requirements for migrating to a new forest are the
same as migrating to and from any two disparate messaging systems; for example, the follow-
ing requirements hold true for any migration between different messaging systems or forests:

Planning name resolution

Configuring Message routing (cross-forest connectors)
TABLE 4.3 Exchange 2000 Server Features Not Supported in Exchange Server 2007
Exchange 2000 Server Feature Replacement Product or Service
Key Management Service (KMS) Microsoft PKI
Mobile Information Service Exchange ActiveSync
Instant Messaging Service Office Communications Server
Chat Service Office Communications Server
Conferencing Service Office Communications Server
MS Mail Connector None
cc:Mail Connector None
81461c04.fm Page 160 Thursday, December 13, 2007 9:07 AM
Designing Migration Strategies
161

Directory synchronization

Calendaring (free/busy data sharing)

Migration

Decommissioning or reprovisioning of old systems
As the deployment of Exchange Server 2007 in a separate forest is similar to that of deploy-

ment in an existing Exchange Server 2003 forest, this section will focus on the mechanics of
a cross-forest migration. The deployment of Exchange Server 2007 in an existing Exchange
Server 2007 forest, including the order to deploy Exchange Server 2007 server roles, will be
covered in the “Intra-Organization Migration” section of this chapter.
Due to the complexity, the reasons for an inter-forest migration should be com-
pletely understood. If the goals of the project can be met by cleaning up or
reconfiguring the existing environment and then performing an intra-forest
migration, that would be the preferred method.
Planning Name Resolution
Although we won’t go into detail here, the cornerstone to communication between the two
forests is name resolution, particularly DNS. Any issues can be avoided by carefully planning
your Active Directory and DNS namespaces to ensure that computers in both forests can
locate resources in the opposing forest.
A best practice when designing Active Directory and DNS for multiple forests
is to avoid using a contiguous namespace across forests—for example,
companya.com in forest A and exchange2007.companya.com in forest B. A con-
tiguous namespace is generally assumed to be part of the same forest, and
going against this convention can lead to confusion, and support and techni-
cal challenges. A multiple-forest topology is already complex, so it’s best to
avoid this scenario entirely.
Configuring Cross-Forest Connectors
The next step in an inter-forest migration is establishing message routing by creating SMTP
Send and Receive connectors between the Exchange Server 2007 Edge Transport server and
the Exchange Server 2003 bridgehead server or the Exchange Server 2007 Hub Transport
server and the Exchange Server 2003 bridgehead server. The steps to establish the connectors
are as follows:
1. Create a user account in the Exchange 2003 forest to use for authentication to the receiving
server in the Exchange 2007 forest.
2. Create a Send connector and select Internal as the usage for this connector on either the
Exchange 2007 Edge Transport server or Hub Transport server.

81461c04.fm Page 161 Thursday, December 13, 2007 9:07 AM