In an intra-org migration the
migration takes place within the same Exchange organization. In other
words, multiple Exchange Server versions coexist within the same Active
Directory. This is by far the most
straightforward of Exchange migrations because it involves many fewer
complexities than an inter-org migration.
With Exchange version coexistence in mind,
it must be noted that Exchange Server 2013 cannot coexist in the same
Active Directory forest with Exchange Server 2003 or earlier versions.
Regarding Exchange 2007 and Exchange 2010
coexisting with Exchange Server 2013, during an intra-org migration you
essentially install Exchange 2013 into the existing environment and
then move the mailbox from one Exchange Server to another, though
running different versions of Exchange. This happens all the time in
most Exchange organizations, and it is a well-understood process.
The potential problem areas we identified
for inter-org migration remain considerations with an intra-org
migration as well. They are far less likely, however, to cause problems
since the majority work well once you have deployed Exchange 2013 in
coexistence with an older version.
Outlook Client Reconfiguration
Outlook client reconfiguration is provided via
the MAPI protocol. Autodiscover is provided natively within an Exchange
organization.
Availability Data Sharing
Availability data sharing again occurs natively
when you have multiple versions of Exchange installed in the same
organization. Some planning is required to ensure that autodiscover and
the Availability services are properly configured, but from a migration
perspective, end users should not notice any significant impact as
their mailboxes are migrated from one version of Exchange to another.
Global Address List Synchronization
The global address list remains the same before and after migration. However, it may now be supplied from a different server.
Public Folder Data Synchronization
Public folder data synchronization becomes public
folder migration and becomes slightly less problematic. However, with
Exchange 2013 and modern public folders, things become more
interesting. Exchange 2013 introduces a totally new implementation of
public folders, and although they look the same to the end user, they
actually function completely differently from an administrative
perspective.
Mail Flow and Mailbox Permissions
Mail flow and mailbox permissions “just work”
when migrating between Exchange Servers in the same organization.
Assuming that the Exchange 2013 infrastructure has been deployed
correctly, the mailbox migration will maintain all previous email
addresses and permissions throughout the move. Additionally, since the legacyExchangeDN of the mailbox remains the same, there is no need to modify any proxy addresses during the migration.
Mobile Device Reconfiguration
Again, mobile devices vary
in their behavior. However, the majority of mobile devices support
mailbox moves within the same Exchange organization with little or no
impact on the end user. BlackBerry and Good for Enterprise require a
specific minimum version to support Exchange Server 2013. At the time
of this writing, BlackBerry requires BES 5.0 SP4, and Good for
Enterprise has not yet provided a definite release date, but they have
confirmed that they are developing support for Exchange 2013.
ActiveSync devices such as those from Apple, Google, Microsoft, and
others all support mailbox moves natively within the same organization.
External URL Publishing
External publishing needs to be moved over to the
newest version of Exchange within the organization prior to a migration
being initiated. But once the infrastructure has been correctly
configured, an end user can connect to the same URLs initially and rely
on Exchange to connect them to the correct server after authentication.
Exchange Application Integration
Application integration remains largely as
tedious and manual a process as it does with an inter-org migration. As
Exchange has evolved, the methods and APIs used for application
integration have changed. The older the application, the more likely it
is that problems will be present after migration to Exchange Server
2013. The key to mitigating these is the same as with inter-org
migration: 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.
Offline Address Book
The offline address book (OAB) is likely to
change publishing location, and the server that generates it will
change after Exchange 2013 has been installed. Nothing specific,
however, is required post-mailbox migration. Outlook will take care of
updating the OAB file via its normal incremental update mechanism, and
no additional action is required.
Distribution Groups
Normal distribution groups (DG) do not
have to be migrated during an intra-org migration. Dynamic distribution
groups, however, may need to have their LDAP search filters upgraded to
OPATH filters. The change from LDAP to OPATH was introduced with
Exchange 2007, because of PowerShell's use of OPATH filtering. This
means that, for an Exchange 2013 migration, it is very likely that this
has already been done. Nevertheless, in case it hasn't, it is worth
verifying this after the installation of Exchange Server 2013.
