6. Mailbox Permissions
Mailbox permissions refers to any
permissions that govern access over the mailbox itself, such as full
mailbox rights, send-as, receive-as, and any of the folder-level
delegate permissions. Historically, it has been difficult to migrate
these permissions between Exchange organizations using native Exchange
tools. With Exchange Server 2010 and later, it is possible to migrate
all of the mailbox permissions and delegate access rights as long as
the target environment is correctly prepared using the Prepare-MoveRequest.ps1
script. This script ensures that all of the necessary attributes are
copied from the source object to the target object to enable Exchange
to remap the permissions once the mailbox migration is performed.
7. Mobile Device Reconfiguration
Mobile device reconfiguration is one of
the trickier aspects of an inter-org migration. Fundamentally, there is
no easy solution for all mobile devices, and each mobile platform will need
to be addressed in its own way. Research in Motion has the Enterprise
Transporter that can move BlackBerry devices between domains relatively
seamlessly. Good For Enterprise (GFE) has no known way of doing so
without the end user erasing and re-creating the device relationship.
ActiveSync devices, such as Android, Apple iOS, and Windows Phone, can
all use autodiscover. Not all mobile devices, however, will follow
autodiscover redirection requests to the new target forest, and some
will need to be reconfigured manually.
The bottom line is that migrating mobile
devices between forests is difficult. It will require a significant
amount of time to discuss the issues involved with your mobile device
vendors and to test the proposed solutions in your lab environment.
Since we cannot provide an easy solution here, our best advice is not
to skimp on mobile device migration testing, because the impact on
mobile device email service is one of the most common problems of a
migration. Implementing mobile device infrastructure in a migration
test lab can be complex and costly, but the time spent getting this
aspect of your migration right will more than pay itself back in the
long run.
8. External URL Publishing
External URL publishing, or publishing an
Exchange organization, can be a tricky subject even when you only need
to consider a single Exchange organization. It becomes much more so
during an inter-org migration when you need to account for multiple
organizations. The problem in this case is that Exchange is not aware
of the correct URLs to provide to users who have been migrated. For
example, User1 is trying to access OWA, which is published on the
external URL https://mail.exchange-d3.com/owa that proxies HTTPS requests back to server1.forest1.com.
After the migration, however, forest1 no longer has a mailbox for
User1, and so when the user tries to access OWA, an error message is
received. The most common approach for resolving this issue is to
notify users about a new URL to access OWA post-migration, such as https://owa.exchange-d3.com/owa.
This information can be delivered via an email message after the
mailbox is successfully moved. This approach is relatively trivial from
a design perspective, and it lessens user frustration through a simple
and effective communication.
9. Exchange Application Integration
Exchange application integration is a
minefield of a topic in its own right. During an inter-org migration,
this is one area that cannot be rushed, and it often remains an ongoing
issue long after the majority of mailboxes have been migrated to the
new platform. The reason that application integration is so difficult
is that there are a number of ways that an application or service can
integrate with Exchange: SMTP, MAPI client and Collaboration Data
Objects (CDO), WebDAV, IMAP/POP, or Exchange Web Services. Some
applications will have gone through a formal project-delivery process,
and thus they will be a known quantity. Others, however, may not have
gone through such a process and may have taken advantage of the
Exchange 2003 open SMTP relay to send messages, or they may be using
normal user mailboxes via CDO, and so forth.
The first problem is discovering each and
every application that is relying on the messaging system,
understanding how it connects, and taking into account how it will be
affected by the migration. Some may be easy to migrate, while others
may require a total application upgrade. The key to making this part of
the inter-org migration successful is good communication with the
business units, analyzing server logs (SMTP and IIS), using Microsoft
Exchange Server User Monitor (ExMon), and creating a register of each
service—who owns it, how it connects to Exchange, if it uses a mailbox,
and what is required to migrate the service to the new platform. Be
warned, however, this is a tedious and time-consuming task, which if
not done properly can turn an otherwise excellent migration into a
disaster. We have all worked migrations where this process alone has
caused an Exchange migration project to be viewed as a failure.
10. Offline Address Book
Outlook clients in cached mode use an offline address book (OAB)
to allow offline access to the global address list. Once Outlook has
downloaded an OAB, it will use that by default to query the Exchange
infrastructure directly for directory information. This is a great
efficiency, and it provides a better user experience while reducing the
server workload. It is a problem, however, when you migrate mailboxes
between Exchange organizations. Although the global address list looks
similar from an end-user perspective in two Exchange organizations that
have GALSync configured, the actual attribute data for message delivery
is quite different. This means that a migrated user will be performing
directory lookups against the wrong GAL post-migration. For this
reason, it is necessary to delete the OAB files from Outlook after the
mailbox has been migrated. Typically, you delete the OAB file in the
same client-side script that imports the PRF file, as noted previously.
The downside is that after every user mailbox is migrated, a full OAB
download will be required. Depending on the size of the OAB file, you
may need to take this additional network traffic into account when you
are planning your migration schedule.
11. Distribution Groups
Distribution lists (DL), or distribution groups (DG),
are used heavily in most organizations. Essentially, a distribution
group is a way to send a single email to a group of individuals. The
problem with DG migration is that it must result in a delivery to the
same users, even halfway through a migration. If you think about this
for a minute, this means that you either need to update the DG
membership constantly as each mailbox is migrated, or you need to leave
all of the DGs in the source environment until the end of the
migration, when they can be migrated in one step. There are third-party
software tools that can help. The most common approach is to create
empty DLs in the target environments and then place a single hidden
contact within the DL that has the target address of the source DL.
This has the effect of correctly displaying the DL in the global
address list, but it defers expansion and delivery back to the source
environment where the membership is correct. As each mailbox is
migrated, the moving process will leave behind a mail-enabled user in
the source environment who is a member of the same groups as before the
migration. Once all of the mailboxes have been migrated, the DGs can
then be migrated and the membership can be updated in the target
organization. Although there are various ways of achieving this, most
migration teams tend to use PowerShell or the Active Directory
Migration Tool (ADMT) for this task. It is important to note here that
ADMT does not migrate Exchange attributes, such as proxyAddresses,
so there is also some post-migration processing work that may be
required if this route is taken. The trick to getting this right is the
same as always: Test thoroughly in your migration test environment
before migrating any distribution lists.
