Professional Documents
Culture Documents
The right of Paul Cunningham, LockLAN Systems Pty Ltd to be identified as author and
copyright owner of this work is asserted by Paul Cunningham, LockLAN Systems Pty Ltd in
accordance with Australian copyright laws as determined by the Australian Copyright
Council.
Copyright extends to any and all countries in which this publication is purchased and/or
viewed and/or read.
The reader of this publication indemnifies Paul Cunningham and LockLAN Systems Pty Ltd
and its directors, officers, employees and agents from and against all losses, claims,
damages and liabilities which arise out of any use of this publication and/or any
application of its content.
Before you do that, I want to share some advice with you that is based on my experience in
these types of migration projects.
1. Do the planning - collecting information about your existing environment and really
understanding how Exchange integrates with the rest of your systems is a very important
step.
2. Read through the migration guide - before you make any changes or install that first
server I recommend you read through the full Exchange Server 2010 to 2013 Migration
Guide to gain an understanding of how the full migration process works. This also gives you
the chance to look for any surprises or concepts that you are not sure about and may need
to research further.
3. Use the sizing calculator - Microsoft provides a very useful Exchange Server 2013 server
sizing calculator that you can use to work out the specifications for the servers you're
deploying. Take your time with the calculator, it can be confusing if it's the first time you've
used it.
4. Consider a test lab - building a small test lab environment and doing a practice run of the
full migration is a great way to get comfortable with the different stages of the migration
process. It also gives you the chance to test anything special or unique about your
environment, such as third party software that will be integrating with your new Exchange
2013 server.
Now let’s get into the migration project. Good luck!
1
Environment Overview
For this migration scenario the Exchange Server Pro organization will be migrating from
Exchange Server 2010 to Exchange Server 2013. Although this scenario will not precisely
match yours, it is intended to provide as much useful information as possible to help you
with your own migration project. Naturally as you work through your migration project
you’ll need to use different domain names, server names, and other details that are unique
to your own environment.
Current Environment
The current environment is built on a “head office/branch office” topology, with the head
office location being the only internet-facing site.
At the head office location, a pair of multi-role Exchange 2010 servers are deployed in a
DAG, along with a public folder server, and an Edge Transport server in the DMZ. The
internet connection is firewalled using Forefront TMG which is also used to publish
Exchange services to the internet.
2
At the branch office location, a single multi-role Exchange 2010 server is deployed. There is
no internet connection at this site.
Client machines exist at both the head office and branch office locations.
3
Target Environment
Although the existing environment was suitable at the time it was deployed, a different
topology is planned to be deployed to meet new requirements for the business.
For the Exchange Server environment this means moving to a highly-available and site-
resilient solution hosted in two dedicated datacenters. The head office and branch office
locations will continue to host end users, with upgraded WAN connections to manage the
increase in network traffic.
The Exchange Server Pro organization will deploy a solution that aligns with the Preferred
Architecture for Exchange Server 2013, beginning with Datacenter 1 and expanding to
Datacenter 2 in a later phase of the project.
This guide will focus on the migration process itself, rather than the design and
configuration of a high availability deployment. If you are deploying a single server then
your own migration project will probably closely match this example scenario.
If you’re planning a highly available or site resilient deployment, then there is a lot more to
consider that is not included in this guide. I recommend that you check out Deploying and
Managing Exchange Server 2013 High Availability1 for more detail.
1 http://bit.ly/1uUDuYn
4
Pre-Requisites and
Information Gathering
There are a number of factors that you should consider before your migration to Exchange
Server 2013. Take your time with this planning and information gathering, because it will
help you run a successful migration project.
For the upgrade from Exchange Server 2010 to Exchange Server 2013 the Exchange Server
Pro organization has gathered the following information.
Forest and domain functional level of Windows Server 2003 or higher (up to
Windows Server 2012 R2 is supported with Exchange Server 2013 SP1 or later)
Schema Master running Windows Server 2003 SP2 or later
At least one global catalog server in each Active Directory site where Exchange 2013
will be installed that runs Windows Server 2003 SP2 or higher
Using the ADInfo.ps1 PowerShell script2 the following information was discovered.
PS C:\Scripts\Exchange2013Planning> .\ADInfo.ps1
2 http://bit.ly/1N1aFm3
5
Site, OS Count
-------- -----
HeadOffice, Windows Server 2008 R2 Enterprise 1
HeadOffice, Windows Serverr 2008 Standard 1
BranchOffice, Windows Serverr 2008 Standard 1
This meets the Active Directory requirements for Exchange Server 2013. As Exchange
Server Pro will be building the Exchange 2013 infrastructure in new datacenters there will
be new domain controllers installed and Active Directory sites created for the datacenters.
Review your Active Directory environment to verify that it meets the requirements for
Exchange Server 2013.
Supported Clients
For the Exchange Server Pro organization, work has already been performed to ensure all
client workstations have been upgraded to Windows 7 with Office 2013 to meet the
minimum support client versions for Exchange Server 2013.
Outlook 2013
Outlook 2010
Outlook 2007
Entourage 2008 for Mac, Web Services Edition
Outlook for Mac for Office 365
Outlook for Mac 2011
Microsoft recommends that you deploy the latest updates for those versions of Outlook to
ensure the best compatibility for Exchange Server 2013.
Review your client versions to ensure they are up to date for Exchange Server 2013.
Storage Quotas
The Exchange Server Pro organization does not plan to use storage quotas for mailboxes on
Exchange Server 2013. However, a small number of individual mailboxes were found to
have a quota configured on them by running the following command:
3 http://bit.ly/1Ljt5yZ
6
Get-Mailbox | Where {$_.UseDatabaseQuotaDefaults -eq $False} | ft
name,prohibit*,issue*
These mailboxes have had their mailbox quota overrides removed in readiness for
migration to Exchange Server 2013.
Review your storage quotas, as well as any mailboxes exempt from storage quotas, to make
sure that your new Exchange Server 2013 databases are correctly configured.
The Exchange Server Pro organization’s email routing topology has been documented in
the following diagram.
4 http://bit.ly/1N1aGGu
7
The following configurations are typically within control the IT department, although in
some cases you may need to engage other teams within the department, or even third
parties who manage some systems for you:
• DNS/MX records
• Firewalls
• Load balancer
• Exchange servers
• Devices (eg printers and MFPs)
The following configurations are not typically not entirely within control of the IT and may
be controlled by other application or device support teams:
• Business Applications
• Building/infrastructure components
Produce a diagram of your email routing topology, and begin to engage any additional
teams or third parties so that you can plan the changes that are coming up.
For the Exchange Server Pro organization, a virtual directory report has been generated
using Get-VDirInfo.ps15. The report shows that there are two namespaces and split DNS in
use:
• autodiscover.exchangeserverpro.net
• mail.exchangeserverpro.net
5 http://bit.ly/1La50He
8
Run a virtual directory report for your Exchange Server 2010 environment and review
your existing Client Access namespaces.
SSL Certificates
For an Exchange Server 2010 to 2013 migration in many cases the existing SSL certificate
for Exchange Server 2010 can be re-used for Exchange Server 2013 as well. But that only
applies if the namespace and SSL configuration for Exchange Server 2010 was correct and
matches what you’re planning for Exchange Server 2013. Also, in many cases companies
choose to simply purchase a new SSL certificate for Exchange Server 2013.
For the Exchange Server Pro organization an SSL certificate report has been generated
using CertificateReport.ps16.
6 http://bit.ly/1P21NiZ
9
Run an SSL certificate report for your Exchange Server 2010 environment.
For example:
• Antivirus/Antispam
• Backup products
• Fax/SMS gateways
• Virtualization
• Telephony/Voice integration
• Scan-to-email devices
For the Exchange Server Pro organization a review of mail-integrated applications and
devices has been conducted to produce an inventory of items that need to be tested and
migrated to Exchange Server 2013 before the legacy server can be decommissioned.
Perform an inventory of applications and devices in your environment that integrate with
Exchange Server 2010 or rely on Exchange for operation.
10
Namespace and Certificate
Planning
Namespace planning refers to the decisions that need to be made for the DNS names that
will be used by clients such as Outlook and mobile devices when they are connecting to
Exchange 2013 services.
When you install Exchange Server 2013 it is pre-configured with default Client Access
namespaces matching the servers fully-qualified domain name (FQDN). For example, a
server named sydex1.exchangeserverpro.net would be pre-configured with an Outlook
Web App (OWA) URL of https://sydex1.exchangeserverpro.net/owa.
Even the simplest, single server deployment of Exchange Server 2013 should include
namespace planning and reconfiguration of URLs to use an alias instead of the server’s
FQDN. This has a number of benefits, such as allowing the namespace to be moved during
server replacement, scale out, or migration in the future. It also gives end users easy to
remember aliases for services such as OWA. After all, they are more likely to remember an
alias such as “webmail.company.com” than a real server name of
“consydexc01.company.com“.
The Microsoft Exchange Team blog has a comprehensive article on namespace planning
that covers the unbound vs bound model, internal vs external namespaces, regional
namespace considerations, legacy namespace considerations (for Exchange 2007 -> 2013
migration), and the changes in namespace requirements since Exchange Server 2007.
Namespace Planning
For this deployment that is aligning with the Preferred Architecture the unbound model
will be used, which means a unified namespace for both datacenters that allows clients to
connect to either datacenter under normal conditions. DNS round robin will be used to
direct traffic to servers in both sites, with the option later to add hardware load-balancers
at each site to make the solution more reliable by only performing DNS round robin
between the two load-balanced VIPs instead of four server IP addresses.
11
• mail.exchangeserverpro.net (HTTP – Outlook Anywhere, OWA, ECP/EAC, ActiveSync,
EWS, OAB)
• imap.exchangeserverpro.net (IMAP)
• pop.exchangeserverpro.net (POP)
• smtp.exchangeserverpro.net (SMTP)
Review existing Client Access namespaces and plan whether to use the same names, or to
use new Client Access namespaces.
Certificate Planning
With the namespaces chosen we can plan the SSL certificates for Exchange Server 2013.
Even though Exchange Server 2013 installs with a self-signed certificate automatically, this
certificate is unsuitable for client connectivity to Exchange because it will fail the validity
check on at least two counts:
• That it doesn’t match the hostname the client is connecting to (after we’ve configured
the new namespaces shown above)
• That it hasn’t been issued by a trusted certification authority
12
The third validity check is whether the certificate has expired or not, which is unlikely as
the self-signed certificate is valid for 5 years.
Again, aligning with the Preferred Architecture and following the certificate planning and
best practices advice from Microsoft we can arrive at a configuration involving one SSL
certificate that will:
If the existing SSL certificate on your Exchange servers meets all of these requirements you
can export it with the private key and later import it into your Exchange 2013 servers.
Otherwise, you will need to purchase a new certificate.
Review existing SSL certificates and prepare to export them for re-use in Exchange Server
2013. Alternatively, choose an SSL certificate provider that you will purchase a new
certificate from. You may also need to seek approval for additional budget to cover the cost
of the new certificate.
13
Reviewing Autodiscover
Configuration
One of the risks during Exchange Server 2013 deployment is that the installation of a new
Client Access server may cause certificate warnings7 to begin appearing in the Outlook
client of your end users.
This is similar to the certificate warning issue often seen during Exchange Server 2010
installation8, which was caused by the Outlook client making Autodiscover or Exchange
Web Services connections to an Exchange server with a self-signed (ie, untrusted by the
client) SSL certificate.
If there is going to be a delay in SSL certificate provisioning for the new Exchange 2013
servers (which is common when third party certification authorities are used) then steps
should be taken to mitigate this risk.
This issue can be avoided with a little bit of planning before you deploy the first server.
Let’s take a look at the existing Exchange Server Pro organization.
From the information gathering stage where we ran the Get-VirDirInfo.ps1 script we
already know that the following Autodiscover URLs are configure:
• autodiscover.exchangeserverpro.net
• br-ex2010-mb.exchangeserverpro.net
Another view of this information can be seen by running Get-ClientAccessServer.
Name : BR-EX2010-MB
AutoDiscoverServiceInternalUri : https://br-ex2010-
mb.exchangeserverpro.net/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope : {BranchOffice}
Name : HO-EX2010-MB1
7 http://bit.ly/1MiO5Xy
8 http://bit.ly/1N2Bp5p
14
AutoDiscoverServiceInternalUri :
https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope : {HeadOffice}
Name : HO-EX2010-MB2
AutoDiscoverServiceInternalUri :
https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope : {HeadOffice}
Notice the AutoDiscoverSiteScope value above. This is also referred to as “Site Affinity” and
is used to tell Outlook clients which Client Access servers to prefer when they are looking
for an Autodiscover service to connect to.
However, this solution requires that the new Exchange 2013 servers are being deployed in
an Active Directory site that is different to the existing site(s). In our Exchange Server Pro
deployment scenario this is true; the new servers are being deployed into new datacenters
that have different IP subnets and different Active Directory sites configured.
9 http://bit.ly/1ZjkcLP
15
However most customers tend to deploy into the same site as the existing customers. This
means that using the same Autodiscover SCP URL for the new servers, so it matches the
Autodiscover SCP URL of the existing servers, is the best approach.
This approach may raise some concerns - for example, does that mean that clients will start
connecting to the Exchange 2013 server for Autodiscover? The answer is no, because you
still control where the Autodiscover SCP URL resolves to using DNS.
16
To achieve this you would need to configure the Autodiscover URL on the Exchange 2013
server immediately after it is installed. You can see a demonstration of this in the following
article:
Review your Autodiscover SCPs so that you can plan for the first installation of Exchange
Server 2013 into your environment. If you need to make changes to your existing
Autodiscover namespace make sure you also consider the SSL certificates on your existing
Exchange servers to ensure they have the correct name included on them.
10 http://bit.ly/1xPVOWl
17
Reviewing Offline Address
Book Configuration
Before installing your first Exchange 2013 server during a migration project you must first
review your offline address book configuration.
The issue, as explained in detail by Exchange MVP Andrew Higginbotham here11, and
mentioned by Microsoft in the release notes12 and a subsequent blog post13, is that
Exchange Server 2013 will create a new default offline address book for the organization.
Any mailbox users who do not have an existing OAB assigned to their mailbox directly, or
to the mailbox database that they are located on, will download the entire OAB from the
new default OAB that Exchange 2013 creates. In organizations with a large OAB or
distributed network environment, this is obviously not ideal.
The solution is to review your existing OAB configuration. You can check the OAB
configured on mailbox databases with a single PowerShell command.
Name OfflineAddressBook
---- ------------------
MB-BR-01 \Default Offline Address Book
MB-BR-02
MB-HO-01 \Default Offline Address Book
MB-HO-02
MB-HO-04
MB-HO-Archive
As you can see, only two of the six databases in the Exchange Server Pro organization have
an offline address book configured.
To avoid mailbox users on the other four databases re-downloading the entire OAB we can
assign an OAB to the databases. Again, this can be performed with a single PowerShell
command in many cases.
11 http://bit.ly/1LD9wUs
12 http://bit.ly/1Ll5HkJ
13 http://bit.ly/1R1ZhXz
18
[PS] C:\>Get-MailboxDatabase | Where {$_.OfflineAddressBook -eq $null} | Set-
MailboxDatabase -OfflineAddressBook "\Default Offline Address Book"
Alternatively you can assign the OAB to a database using the Exchange Management
Console by opening the mailbox database properties and selecting the Client Settings tab.
This is an important configuration item to review during a migration project and should
not be overlooked.
Review your OAB configurations and apply the fix where necessary.
19
Server Sizing Guidance
Any Exchange Server 2013 deployment should include the use of the server sizing
calculator published by Microsoft. This calculator represents the best and latest sizing
guidance available for Exchange Server 2013, based on real world deployments.
As such, the calculator does vary over time, with changes such as minor calculation fixes all
the way up to major changes such as the additional CPU requirements for MAPI-over-HTTP
released in Service Pack 1.
You can download the Exchange 2013 Server Role Requirements calculator14 from
TechNet. Always check to make sure you are downloading the latest version.
A detailed walk through of the calculator is beyond the scope of this guide due to the
evolving nature of the guidance it provides. However it is recommended that you refer to
the following Microsoft content to better understand how the calculator is used:
• Plan it the right way – Exchange Server 2013 sizing scenarios15 (MEC 2014 session
recording)
• Ask the Perf Guy: Sizing Exchange 2013 Deployments16
You should also review the Preferred Architecture17 for Microsoft’s specific
recommendations about Exchange Server 2013 design.
Complete your server sizing calculations and design the server sizing specifications for
your deployment.
14 http://bit.ly/1LQBPIU
15 http://bit.ly/1Lnwaul
16 http://bit.ly/1MFVeRS
17 http://bit.ly/1VVhN5A
20
Preparing Active Directory
Before installing the first Exchange 2013 server during a migration project we must first
prepare Active Directory.
These preparation steps can happen automatically during installation of the first server, as
long as the correct conditions are in place. For example, if you are running Exchange Server
2013 setup:
On a 64-bit server in the same Active Directory site as the Schema Master, and as a
writeable global catalog for each domain in the forest
With an account that has Schema Admins, Domain Admins and Enterprise Admins
permissions
For a simple environment with one or just a few sites and only one domain in the forest it
can be easier to just allow this preparation to run as part of the first server installation.
However more complex environments, or those that need to control their change schedule
a bit more closely, running the Active Directory preparation tasks separately may be more
suitable.
You can read more about Active Directory preparation on TechNet here18.
The Exchange Server Pro organization has four Active Directory sites and a single domain
in the forest. The FSMO roles have been moved to the domain controller in the DataCenter1
site where the first Exchange 2013 servers are being deployed, so that is where the
preparation steps will be performed.
Before we start, it is recommended to note the current schema version so that you can
compare it later when you are verifying the results of Exchange setup. Use Michael B
Smith’s PowerShell script here19 to perform this task.
18 http://bit.ly/1k8AVBp
19 http://bit.ly/1VVPOrI
21
Preparing the Active Directory Schema
The first step is to apply the Exchange Server 2013 schema update to Active Directory.
Extract the Exchange Server 2013 setup files to a folder on the server. In this example, I am
deploying Exchange Server 2013 with Service Pack 1, which is the latest version available
at the time of writing.
It is recommended that you always check for the latest version of Exchange Server 2013,
and deploy the latest that is available unless you have a specific compatibility requirement
with a third party product that requires you to deploy an earlier version.
22
Run setup /PrepareSchema, including the /IAcceptExchangeServerLicenseTerms switch as
well.
After extending the schema we can proceed with preparing the Active Directory forest and
domains.
Again, from an elevated CMD prompt run setup /PrepareAD and use the
/IAcceptExchangeServerLicenseTerms switch as well. Because we are installing into an
existing organization there is no need to use the /OrganizationName switch.
23
Organization Preparation COMPLETED
With only one domain in the forest there are no additional steps to perform here. If you
have multiple domains you should refer to the TechNet instructions here20.
Review your Active Directory backups and disaster readiness. Prepare your Active
Directory for Exchange Server 2013.
20 http://bit.ly/1k8AVBp
24
Installing Exchange Server
2013
After preparing Active Directory we can proceed with the installation of the Exchange 2013
servers into the Exchange Server Pro organization.
For the Exchange Server Pro organization the first servers to be installed are EX2013SRV1
and EX2013SRV2 in the Datacenter1 site. The servers in Datacenter2 will be deployed later
in the project as the HA environment is expanded to include site resiliency.
Before you proceed with the first Exchange 2013 installation I recommend you read and
understand the guidance in the “Reviewing AutoDiscover Configuration” part of this guide.
You should also have already performed your namespace and certificate planning.
25
Installing the Exchange Servers
The Exchange Server Pro organization has chosen to deploy Exchange Server 2013 SP1 on
Windows Server 2012 R2. If you are planning to deploy Exchange Server 2013 there may
be a more recent build available for you to deploy instead.
• Building the new servers to the specifications determined using the Exchange 2013
server sizing guidance from Microsoft
• Installing the Exchange Server 2013 pre-requisites21
• Installing Exchange Server 201322 on both servers as a multi-role server (Mailbox and
Client Access server roles)
Install your new Exchange 2013 servers and configure the Autodiscover URI to avoid
Outlook security warnings due to certificate validity issues.
21 http://bit.ly/1jFc9s6
22 http://bit.ly/1NKDExE
26
Managing a Co-Existence
Environment
After installing the first Exchange 2013 server into an existing Exchange 2010 organization
we are effectively in a co-existence state. During this phase of the Exchange 2013 migration
project there are some management considerations to be aware of.
The URL for the Exchange Admin Center is https://serverFQDN/ecp, for example
https://ex2013srv1.exchangeserverpro.net/ecp, or
https://mail.exchangeserverpro.net/ecp if you have already configured and migrated
your Client Access namespaces.
23 http://bit.ly/1PweO3M
27
It is likely you will see an SSL certificate warning in your browser when you first access the
EAC, due to the default self-signed certificate on the server. Later when you have
configured the correct namespaces and SSL certificates this warning will not appear.
To avoid this you can append the ?ExchClientVer=15 string to the end of the URL, for
example https://ex2013srv1.exchangeserverpro.net/ecp?ExchClientVer=15.
However, in some cases such as when the new Exchange 2013 servers are located in a
different AD site to the Exchange 2010 servers, this workaround may not be successful.
In such cases it is often simpler to create a new admin account specifically for use during
the co-existence period. In this example scenario I’ve created an account called “E15Admin”
and added it to the Organization Management group.
28
Managing Exchange Objects During Co-
Existence
There are some general rules for managing Exchange objects during co-existence. From
TechNet:
"You can’t use the Exchange 2010 EMC to manage Exchange 2013 objects and servers. While
customers upgrade to Exchange 2013, we encourage them to use the EAC to:
We encourage customers to use Exchange 2010 EMC to create Exchange 2010 mailboxes.
We encourage customers to use Exchange 2007 EMC to create Exchange 2007 mailboxes.
Customers can continue to perform management tasks using the Exchange Management Shell
and script tasks."
24 http://bit.ly/1QyPusb
29
"When you coexist with Exchange 2010 or Exchange 2007, all transport rules are stored in
Active Directory and replicated across your organization regardless of the Exchange Server
version you used to create the rules.
However, all transport rules are associated with the Exchange server version that was used to
create them and are stored in a version-specific container in Active Directory. When you first
deploy Exchange 2013 in your organization, any existing rules are imported to Exchange
2013 as part of the setup process.
However, any changes afterwards would need to be made with both versions. For example, if
you change an existing rule using the Exchange 2013 EAC, you need to make the same change
using the Exchange 2010 or Exchange 2007 EMC."
Review the Exchange 2013 management tools and verify that they are working correctly
for your administrative account.
30
Configuring SSL Certificates
For the Exchange Server Pro organization a new SSL (SAN) certificate is being provisioned
for the Exchange 2013 servers. From the namespace and certificate planning part of this
series we know that the following namespaces are required for the certificate:
The Exchange 2010 SSL certificate can be re-used if it contains the correct namespaces. You
can export the SSL certificate from Exchange 2010 and import it into Exchange 2013.
However if the names on the certificate are not correct, or the certificate is due to expire
soon anyway, you may find it easier to simply acquire a new SSL certificate.
31
To complete the SSL certificate configuration the following process is used:
25 http://bit.ly/1jrILpF
26 http://bit.ly/1X861as
27 http://bit.ly/1ZH4bzB
28 http://bit.ly/1MsRDSC
29 http://bit.ly/1RdMdP5
32
Configuring Client Access
Servers
With the correct SSL certificates installed on the Exchange 2013 servers we can now
proceed with configuration of the Client Access server role.
Both of the Exchange 2013 servers deployed so far, EX2013SRV1 and EX2013SRV2, are
multi-role servers, and need their Client Access roles configured.
• Outlook Anywhere
• Outlook Web App
• Exchange Control Panel
• ActiveSync
• Exchange Web Services
• Offline Address Book
• MAPI/HTTP
These are easy to configure with a simple PowerShell script. Here is an example:
• ConfigureExchangeURLs.ps130
Simply run the script using the Exchange Management Shell (from a server or workstation
with the Exchange 2013 management tools installed) with the required parameters, for
example:
30 http://bit.ly/1hHQD4v
33
Configuring OWA and ECP Authentication
The default authentication for Exchange 2013 OWA is forms-based. If you need to use a
different authentication type then you should configure it now on the OWA and ECP virtual
directories for your Exchange 2013 servers. The virtual directory configuration is found in
the Exchange Admin Center in the Servers -> Virtual Directories area.
For example, here I am changing the username format to UPN so that users can login with
their “email address” (because the organization uses UPNs that match the primary SMTP
address).
34
Restart IIS
An IISReset of each server should also be performed so that the virtual directory changes
can take effect.
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
WARNING: Changes to POP3 settings will only take effect after all Microsoft Exchange
POP3 services are restarted on
server EX2013SRV1.
WARNING: Changes to POP3 settings will only take effect after all Microsoft Exchange
POP3 services are restarted on
server EX2013SRV2.
35
The same basic process applies to IMAP as well.
WARNING: Changes to IMAP4 settings will only take effect after all Microsoft Exchange
IMAP4 services are restarted on
server EX2013SRV1.
WARNING: Changes to IMAP4 settings will only take effect after all Microsoft Exchange
IMAP4 services are restarted on
server EX2013SRV2.
First, create a new user and mailbox on an Exchange 2013 database. This is performed
using the Exchange Admin Center.
31 http://bit.ly/1hHRzWM
36
Next, modify the hosts file on a test PC. The file is located in
C:\Windows\System32\Drivers\Etc, and will require admin/elevated rights to modify.
Note: Without a load balancer in place you may need to repeat your tests multiple times for
each Exchange 2013 server IP. Later when the production cut over takes place you can use
DNS round robin instead.
From the test PC logged in as the Exchange 2013 test user you should be able to launch
Outlook and have the profile automatically configured to open the mailbox. While you’re
logged in to the mailbox you may also like to do some send/receive tests between the
Exchange 2013 test mailbox and some Exchange 2010 test mailboxes to verify that mail
flow is working between the servers. #Configuring Mailbox Servers
After configuring the Client Access servers we can next turn our attention to configuring
the Exchange 2013 Mailbox servers.
37
The Exchange Server Pro organization is planning to deploy a database availability group
spanning two datacenters. However in this initial phase, only the DAG members in
Datacenter1 will be provisioned. The DAG will be extended to Datacenter2 later.
The server and storage layout has already been determined from the server sizing exercise.
In particular, because we plan to use AutoReseed32 the correct database storage layout has
been configured.
The DAG has been provisioned and the database copies have been configured. For more
information on these steps see the following resources:
32 http://bit.ly/1OGOGCp
33 http://bit.ly/1jrKjjs
34 http://bit.ly/1GgY66g
38
Configuring Transport
With the Exchange 2013 servers deployed in the new Datacenter1 location we can also
configure Transport. For the Exchange Server Pro organization there are two elements to
this:
• Inbound/outbound email
• Internal/external SMTP relay
Let’s take a look at each of these.
Inbound/Outbound Email
Currently the Exchange Server Pro organization has inbound/outbound email flowing via
an Exchange 2010 Edge Transport server in the Head Office site.
The Exchange 2013 servers in DataCenter1 will send and receive internet email directly,
without the use of an Edge Transport server. The routing topology during the co-existence
period will look like this.
39
The outbound mail flow from Datacenter1 is established by creating a send connector.
However, with the send connector in place some Exchange Server Pro organization email
will possibly flow out via Datacenter1. The "cost" that you configure on the send connector
will influence whether email routes out this connector or the other existing connectors
(messages will take the lowest "cost" route out of the organization).
This means that with the send connector in place the Exchange 2013 servers can be
considered to be in production, however as long as the Head Office servers are functioning
there should be two routes for outbound email, so the Exchange 2013 servers are not yet of
critical importance.
Configure the Send Connector for outbound email from your new Exchange 2013 servers.
You can leave the existing Send Connectors for Exchange 2010 in place for now.
35 http://bit.ly/1LQGVVw
40
Internal/External SMTP Relay
For the Exchange Server Pro organization the existing Head Office Exchange 2010 servers
have relay connectors configured for a variety of systems and applications to use as an
SMTP service. These are currently load balanced.
The load balancer will be moved to Datacenter1 later, so the change to that traffic can be
made on the load balancer itself. Otherwise the change would be made in DNS, to point the
SMTP alias to the new server(s).
First, the new servers require relay connectors to be created with matching configurations.
The default Frontend connector on Exchange 2013 servers permits sending email to
internal recipients, so only those that require external relay need to use the relay
connectors.
However, like many organizations, the Exchange Server Pro organization uses one SMTP
alias for both internal and external relay needs.
Review any additional receive connectors on your Exchange 2010 servers and determine
whether you need new receive connectors created on Exchange 2013 servers for the same
purpose. Plan the DNS change to cutover applications and devices that use an SMTP alias to
connect to the server, or review any configurations that rely on a fixed server name or IP
address so you can prepare to change them at cutover time.
36 http://bit.ly/1C0zeNu
41
Preparing for Co-Existence
Before the Exchange 2013 migration project moves into the co-existence phase, where
production services are provided from both the Exchange 2010 and 2013 servers, there are
some final checks and configurations that should be performed.
Run health checks and tests of your new servers do verify readiness for co-existence and
the cutover of production namespaces and services.
37 http://bit.ly/1hzUktg
42
If Outlook Anywhere was not previously used in your Exchange 2010 organization it needs
to be enabled and configured.
If Outlook Anywhere was already enabled and configured, it needs to be checked to confirm
that the correct authentication settings are in place to allow Exchange 2013 to proxy
connections to Exchange 2010 for users who have not yet been moved to Exchange 2013.
For the Exchange Server Pro organization the servers are configured as follows:
ServerName : HO-EX2010-MB1
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
ServerName : HO-EX2010-MB2
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
ServerName : BR-EX2010-MB
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
Review and correct the Outlook Anywhere configuration on your Exchange 2010 servers in
readiness for co-existence.
The Exchange Server Pro organization has OWA and ECP virtual directories configured for
Basic and Integrated authentication, and uses Forefront TMG to publish them to the
internet with Forms-based Authentication. Therefore, the OWA/ECP virtual directories for
Exchange 2013 also need to be configured the same way so that the TMG publishing can
continue to work.
43
This is particularly important for TMG authentication delegation to continue working.
Using a different authentication type for Exchange 2013 potentially means the TMG
configuration also needs to be re-assessed.
For more information on publishing Exchange 2013 with TMG see the following article:
Other than that, as long as you’re re-using the same namespaces as the existing Exchange
organization there is not likely to be any other user-visible changes that need
communicating.
38 http://bit.ly/1KcmDob
44
Cut Over Namespaces
With all co-existence preparations complete we can now cut over the namespaces to
Exchange Server 2013.
First, let’s be clear that this is a significant change and should be approached with due care.
Although the changes themselves are quite simple (mostly DNS changes), they are best
performed during a window of time when they will have the least impact on your end
users, with enough time for you to test the outcome and roll back if there is a problem.
On the topic of rolling back, your changes should be well planned and well documented as
you go along, so that you can easily reverse them if you need to.
• autodiscover.exchangeserverpro.net
• mail.exchangeserverpro.net
In a scenario where the external IP addresses are staying the same the cut over would
occur on the edge router or firewall that performs NATing for the network. However in this
case the internet-facing Exchange 2010 servers are in the Head Office site, while the new
internet-facing Exchange 2013 servers are in the Datacenter1 site which has its own
internet connection and a new public IP range.
45
Therefore the change is made in public DNS, updating the records to the new IP addresses.
Depending on the TTL (time-to-live) on those DNS records this change may take anywhere
from several minutes to several hours to take effect. It is recommended before making
planned DNS changes to lower the TTL to a short timespan (eg 5 minutes) at least a day or
two in advance of the change so that it will take effect faster, as well as allowing faster roll
back.
Note that for the Exchange Server Pro organization this change will impact Client Access
services (such as OWA, ActiveSync, Outlook Anywhere), as well as Transport services (ie
MX records, mail flow), because the MX record for the domain points to
mail.exchangeserverpro.net as well. If the MX record pointed to a different DNS name, or
the IP addresses weren’t actually changing, then services on different ports could be cut
over at different times.
39 http://bit.ly/1LwDyXZ
46
The outcome of the external DNS changes is that external access (eg Outlook Anywhere,
ActiveSync, OWA, and inbound SMTP) will go via the Exchange 2013 servers and be
proxied/routed internally as required.
Complete the cutover of your external namespaces to Exchange 2013 following your
standard change control processes.
• autodiscover.exchangeserverpro.net
• mail.exchangeserverpro.net
• imap.exchangeserverpro.net
• pop.exchangeserverpro.net
• smtp.exchangeserverpro.net
High availability for Exchange 2013 Client Access services in Datacenter1 will initially be
handled by DNS round robin. So the DNS records for the above namespaces (except SMTP)
are updated in the internal DNS zones with two A records, which point to each of the
Exchange 2013 IP addresses.
SMTP is a little different. SMTP doesn’t work well with DNS round robin, because many
SMTP clients (such as printers) will simply fail a connection if the IP they attempt to
connect to doesn’t respond, rather than retry with a different IP as most modern HTTP
clients do (including Outlook).
For now the Exchange Server Pro organization is retaining a load balancer for SMTP, so the
cut over for SMTP is performed on the load balancer configuration itself. If this cost wasn’t
practical or high availability for SMTP wasn’t important then pointing the SMTP namespace
at just one Exchange 2013 server IP address would be a reasonable solution.
After making the changes to internal DNS repeat the testing and health checks performed
earlier to verify that services are working as expected.
47
Complete the cutover of your internal namespaces to Exchange 2013 following your
standard change control processes.
It is only after moving mailboxes to Exchange 2013 that Outlook MAPI/RPC connectivity
for those users will switch over to the Outlook Anywhere namespace for Exchange 2013
(mail.exchangeserverpro.net in this example scenario).
48
Moving Mailboxes
With co-existence established and the Client Access namespaces cut over to Exchange
Server 2013 we can begin the mailbox migrations.
When you’re planning a mailbox migration it helps to know what you’re dealing with in
terms of number of mailboxes, their sizes, and the number of items they contain. To gather
this information I recommend using the Get-MailboxReport.ps1 script40.
In earlier versions of Exchange such as 2003 and 2007 the mailbox migration process was
an interactive task that required the administrator to test how much mailbox data they
could move per hour, break up the mailboxes into migration groups, time the moves to
occur out of business hours, and communicate to end users that their mailbox would be
unavailable for what was often a several hour period.
In addition to this, care should be taken not to move so much data in one period that the
transaction log volumes on the destination Exchange server ran out of disk space.
Exchange Server 2010 improved on this with the introduction of move requests. Exchange
Server 2013 improves on this even further with new enhancements.
Exchange Server 2013 will apply self-management of its resources when processing
mailbox moves, backing off when required due to server load or to allow log replication to
catch up. Move requests can be issued and allowed to run without the administrator
40 http://bit.ly/1FfM3Sc
49
needing to micro-manage the process, with only occasional monitoring required and some
intervention at the end to complete the moves.
And in a scenario where mailboxes are being migrated from Exchange 2010 to 2013 the
moves are processed as online moves, which do not require the user’s mailbox to be offline
for the whole move process, only the final completion stage.
First the arbitration mailbox must be moved to an Exchange 2013 Mailbox server. You can
see the arbitration mailbox by running the following command.
You can learn more about the mailbox move process here:
Complete your mailbox migrations before you perform the public folder migration.
41 http://bit.ly/1MsVsXZ
50
Moving Public Folders
After moving all mailboxes from Exchange Server 2010 to 2013 we can turn our attention
to the public folder migration.
Although Exchange Server 2013 provides support for public folders with the new modern
public folders, you may wish to take this opportunity to review whether your organization
needs to retain public folders at all. If they are no longer needed then removing them
entirely from the Exchange organization would be simpler. However if that decision can’t
be made, or they are still required for some reason, then a migration to Exchange 2013 can
be performed.
Initially Microsoft provided a public folder migration method known as serial migration.
Serial migration of public folders to Exchange 2013 has since been deprecated and will not
be supported by Microsoft. The current method for migrating public folders to Exchange
2013 is a batch migration. You can migrate up to 500,000 public folders to Exchange 2013
with this method.
A snapshot of the existing public folder structure, statistics, and permissions is taken. These
commands are run from the Exchange 2010 management shell.
42 http://bit.ly/1RdSiLh
43 http://bit.ly/1RdSDxu
44 http://bit.ly/1KcrKEN
45 http://bit.ly/1MGeoHk
52
Any public folders that have a backslash in the name need to be renamed to remove the
backslash. To identity those folders run the following command in the Exchange 2010
management shell.
Verify that no record exists of a previous public folder migration. The values returned here
should be $false.
PublicFoldersLockedForMigration : False
PublicFolderMigrationComplete : False
In the Exchange 2013 management shell run the following commands to verify that there
are no existing public folder migration requests, and no existing modern public folders.
[PS] C:\PFMigration>Get-PublicFolderMigrationRequest
[PS] C:\PFMigration>Get-PublicFolder
53
Review the folder sizes in the CSV file and make a decision for how big each public folder
mailbox will be. This will determine the number of public folder mailboxes created to store
all of the public folder data in Exchange 2013. For example, if you have 20Gb of public
folder data, and choose a maximum mailbox size of 1Gb, you will end up with 20 public
folder mailboxes.
The Exchange Server Pro organization has very little public folder data, so a maximum size
of 10Gb will result in a single public folder mailbox.
54
On an Exchange 2013 server create a public folder mailbox to be the master hierarchy
mailbox.
Run the following command to create the additional public folder mailboxes to host the
public folder content. The number of mailboxes is determined by the PF mailbox map
generated in the previous step. In the case of the Exchange Server Pro organization only
one mailbox is required, so this step is not required.
[PS] C:\>$numberofmailboxes = 3
Note that you need the CSV file containing the PF mailbox map generated earlier, so copy
that to a server with the Exchange 2013 management tools where you are running this
command.
55
[PS] C:\>New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-
PublicFolderDatabase -Server EX2010SRV1) -CSVData (Get-Content
C:\PFMigration\PFMailboxMap.csv -Encoding Byte) -NotificationEmails
administrator@exchangeserverpro.net
IdentityStatusType TotalCount
------------------ ----------
PFMigration Created PublicFolder
When you’re ready to commence the initial synchronization of public folders start the
migration batch.
Monitor the progress of the public folder migration batch until it reaches a state of
“Synced”.
If you have more than one public folder mailbox in Exchange 2013 you can see the status of
each mailbox’s migration progress using Get-MigrationUser.
When the Synced state has been reached the legacy public folders can be locked for the
final migration. This requires downtime, the length of which depends on how much new
content has been generated in public folders since the Synced state was reached and will
still need to be migrated. Users will not be able to access public folders, and any email sent
to mail-enabled public folders will be queued.
In the Exchange 2010 management shell run the following command to lock the public
folders. In an organization with multiple public folder databases it may take several hours
for all public folders in the organization to receive this change via replication.
56
With the public folders locked we can complete the migration. In the Exchange 2013
management shell run the following commands.
If you see an error that public folders need to be locked down first it’s likely that the lock
down flag has not been picked up by the legacy public folder database yet, and you will
need to wait a little longer.
Wait for the migration batch to reach a state of Complete. Again this can take what seems
like a long time, even in a small organization with very little public folder data.
Next, a test mailbox is set to use the Exchange 2013 public folder mailbox and used to test
public folder functionality.
With the test successful the following command is run from an Exchange 2013 server or
management shell.
Next, the organization config is updated to indicate that the migration of public folders is
complete. This command is run from the Exchange 2010 management shell.
And finally, the following command is run from the Exchange 2013 management shell.
57
During the final migration phase when public folders were locked, regular users were
unable to access the public folders in Outlook. After the migration completion flag is set
above, and the users restart Outlook, they should be able to access public folders again. Any
new items created by the test user should be visible as well.
Complete your public folder migration only after all mailbox migrations have been
completed.
58
Removing Legacy Servers
With all of the services and data migrated to Exchange Server 2013 we can begin the
removal of the legacy Exchange servers from the organization.
Exchange servers must be correctly uninstalled from an organization to avoid future issues
due to orphaned objects. It is not enough to simply shut down the server.
Aside from your own regular server decommissioning steps such as taking a final backup,
removing from monitoring systems, disposing of hardware etc, the Exchange Server
application itself needs to go through a few simple decommissioning steps. These will
depend on the server roles that were installed, but can generally be broken down as
follows.
When you remove the last Exchange 2010 server from the organization any Exchange 2010
management tools (eg on admin workstations) will stop working (although the
management shell may still connect to Exchange 2013 servers). This may seem obvious,
but I have seen people be surprised by this. By the time you are removing the last Exchange
2010 server all of your administrators should be using the Exchange 2013 management
tools.
In a typical case you may still see some traffic hitting the server. This could be due to
incoming SMTP connections still hitting the server, eg spammers hitting an open firewall
port that still allows access to that server. Or it may be due to the occasional outbound
email still routing over that Edge subscription. Review any evidence of ongoing email traffic
and either address it or choose to ignore it and proceed with the decommissioning anyway.
Before an Edge Transport server can be uninstalled the Edge Subscription must be
removed, which can be done from the Exchange Management Console.
46 http://bit.ly/1xPUhzC
47 http://bit.ly/1LQX5hz
59
And from the Exchange Management Shell on the Edge Transport server run Remove-
EdgeSubscription.
[PS] C:\>Get-EdgeSubscription
Confirm
Are you sure you want to perform this action?
Removing Edge Subscription "HO-EX2010-EDGE".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is
"Y"): y
Confirm
Do you want to remove recipients? You don't need to remove the recipients that have
already synchronized to this Edge
server if you will re-subscribe it to the same organization. This would improve the
performance of Edge synchronization
when you re-subscribe.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is
"Y"): y
Launch the Exchange Server uninstall from Programs and Features in the Control Panel of
the Edge Transport server. If the readiness check passes you can click Uninstall to complete
the process.
60
Client Access Servers
Client Access servers can be removed when they are no longer serving any client requests.
This is achieved by completing the cutover of the client access namespaces to Exchange
Server 2013.
You can verify that no more traffic is hitting the Client Access server by reviewing the IIS
logs on the server. Note that you will likely see continued hits in the logs from the Exchange
2013 servers themselves, or from any connections to the /PowerShell virtual directory by
administrators.
If there is too much log data to analyse visually you can use Log Parser to determine which
users (if any) are still making connections to the server. For example:
61
Count Username
----- --------------------
0 -
598 ESPNET\Administrator
Statistics:
-----------
Elements processed: 100861
Elements output: 2
Execution time: 0.27 seconds
Just be aware that querying a wildcard like ‘C:3svc1*.*’ will return results from any log file
in that directory, which may be months or even years worth of log data. You can refine the
search by removing older log files from the directory, or changing the query to only search
file names of a smaller date range, eg ‘C:3svc1_ex1407.’.
If the server is a dedicated Client Access server then you can launch the uninstall from
Programs and Features in Control Panel and uninstall it. If it is a multi-role server you
should wait until you’ve verified all roles are ready to be uninstalled before doing them all
together.
Because internal traffic may still be traversing the server you may still see some hits,
particularly larger organizations where multiple routes exist between internal sites. The
presence of a relay connector on the server could also be an indication that it is still in use
by production systems that require SMTP.
But generally speaking, if there are no mailboxes or public folders still in the site, and no
DNS aliases still pointing at the site for internal SMTP usage, then you can proceed with the
uninstallation.
As a precaution you may consider pausing or stopping the Microsoft Exchange Transport
service on the server for a period of time to verify that the server removal will have no
impact on production services.
If the server is a dedicated Hub Transport server then you can launch the uninstall from
Programs and Features in Control Panel and uninstall it. If it is a multi-role server you may
wish to wait until you’ve verified all roles are ready to be uninstalled before doing them all
together.
62
Mailbox Servers
Mailbox servers an be uninstalled when they no longer host mailboxes or public folders,
are not members of DAGs, and are not responsible for generating offline address books.
The legacy offline address books can be removed from the organization when there are no
more Exchange 2010 mailbox users. Exchange 2013 mailbox users will be using the new
OAB created by Exchange 2013 setup.
Public folder databases can be removed if the migration of public folders to Exchange 2013
is complete. You can remove the databases using PowerShell, for example:
Confirm
Are you sure you want to perform this action?
Removing public folder database "PF-BR-01".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y
WARNING: The specified database has been removed. You must remove the database file
located in C:\Program
Files\Microsoft\Exchange Server\V14\Mailbox\PF-BR-01\PF-BR-01.edb from your computer
manually if it exists. Specified
database: PF-BR-01
Mailbox databases can be removed if the mailbox migration to Exchange 2013 has been
complete. Again, you can use PowerShell to remove them.
63
[PS] C:\>Remove-MailboxDatabase MB-BR-01
Confirm
Are you sure you want to perform this action?
Removing mailbox database "MB-BR-01".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y
WARNING: The specified database has been removed. You must remove the database file
located in
F:\Data\MB-BR-01\MB-BR-01.edb from your computer manually if it exists. Specified
database: MB-BR-01
Confirm
Are you sure you want to perform this action?
Removing mailbox database "MB-BR-02".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y
WARNING: The specified database has been removed. You must remove the database file
located in
F:\Data\MB-BR-02\MB-BR-02.edb from your computer manually if it exists. Specified
database: MB-BR-02
For DAG members the approach is a little different. The process involves:
1. Removing database copies from the server (unless it is the last DAG member hosting
the single copy of the databases)
2. Removing the server from DAG membership
3. Removing the databases from the standalone server
4. Uninstalling Exchange from the standalone server
5. Removing the DAG object from the organization
For example, removing database copies from HO-EX2010-MB2, first move any active
database copies to another DAG member.
Verify that the server only hosts passive database copies. You should see no “Mounted”
status in this output.
64
7/25/2014 10:35:27 AM Healthy
MB-HO-04\HO-EX2010-MB2 Healthy 0 0
7/25/2014 10:35:21 AM Healthy
MB-HO-02\HO-EX2010-MB2 Healthy 0 0
7/25/2014 3:08:47 PM Healthy
If you are removing the second last DAG member you’ll first need to turn off DAC mode.
When all members have been removed from the DAG you can also remove the DAG object
itself.
Wish all Exchange 2010 servers uninstalled the migration from Exchange 2010 to
Exchange 2013 is complete.
Complete the decommission of your legacy Exchange servers to bring the project to an end.
65