Exchange 2010 To 2013 Migration Guide PDF

© Copyright 2015 Paul Cunningham, LockLAN Systems Pty Ltd
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.
About the Author
Paul Cunningham is an Exchange Server MVP and Systems Consultant living

in Brisbane, Australia. Paul is the founder of ExchangeServerPro.com, a
leading website in the Exchange Server community. He also holds several
Microsoft certifications including for Exchange Server 2007, 2010 and 2013.
Connect with Paul on Twitter (@ExchServerPro).
Table of Contents
Before You Begin ................................................................................................................................................... 1
Environment Overview....................................................................................................................................... 2
Current Environment ..................................................................................................................................... 2
Target Environment ........................................................................................................................................ 4
Pre-Requisites and Information Gathering ................................................................................................. 5
Active Directory Requirements .................................................................................................................. 5
Supported Clients ............................................................................................................................................. 6
Storage Quotas .................................................................................................................................................. 6
Email Routing Topology ................................................................................................................................ 7
Internal/External Client Access DNS Names ......................................................................................... 8
SSL Certificates .................................................................................................................................................. 9
Applications and Devices Integration ................................................................................................... 10
Namespace and Certificate Planning .......................................................................................................... 11
Namespace Planning .................................................................................................................................... 11
Certificate Planning ...................................................................................................................................... 12
Reviewing Autodiscover Configuration .................................................................................................... 14
Reviewing Offline Address Book Configuration ..................................................................................... 18
Server Sizing Guidance .................................................................................................................................... 20
Preparing Active Directory ............................................................................................................................ 21
Preparing the Active Directory Schema ............................................................................................... 22
Installing Exchange Server 2013 ................................................................................................................. 25
Installing the Exchange Servers............................................................................................................... 26
Configuring the Autodiscover URI .......................................................................................................... 26
Managing a Co-Existence Environment..................................................................................................... 27
Exchange Server 2013 Management Tools ......................................................................................... 27
Accessing the Exchange Admin Center During Co-Existence....................................................... 27
Exchange Admin Center Redirects to Exchange Server 2010 Outlook Web App ................. 28
Managing Exchange Objects During Co-Existence ........................................................................... 29
Configuring SSL Certificates........................................................................................................................... 31
Configuring Client Access Servers ............................................................................................................... 33
Configuring Client Access URLs ............................................................................................................... 33
Configuring OWA and ECP Authentication.......................................................................................... 34
Restart IIS ......................................................................................................................................................... 35
Configure POP/IMAP Settings .................................................................................................................. 35
Testing the Client Access Server Configuration ................................................................................ 36
Configuring Transport ..................................................................................................................................... 39
Inbound/Outbound Email ......................................................................................................................... 39
Internal/External SMTP Relay ................................................................................................................. 41
Preparing for Co-Existence ............................................................................................................................ 42
General Health Check................................................................................................................................... 42
Configure Outlook Anywhere ................................................................................................................... 42
Configure Virtual Directories ................................................................................................................... 43
Communicate Changes to Users .............................................................................................................. 44
Cut Over Namespaces ....................................................................................................................................... 45
Cut Over External Namespaces ................................................................................................................ 45
Cut Over Internal Namespaces................................................................................................................. 47
What About Internal Outlook Users? ..................................................................................................... 48
Moving Mailboxes .............................................................................................................................................. 49
Moving Public Folders ...................................................................................................................................... 51
Download Scripts and Prepare Organization ..................................................................................... 52
Generate CSV Files and Create Public Folder Mailboxes ............................................................... 53
Migrating the Public Folders ..................................................................................................................... 55
Removing Legacy Servers ............................................................................................................................... 59
Edge Transport Servers .............................................................................................................................. 59
Client Access Servers ................................................................................................................................... 61
Hub Transport Servers................................................................................................................................ 62
Mailbox Servers ............................................................................................................................................. 63
Before You Begin
So you're planning to migrate to from Exchange Server 2010 to Exchange Server 2013. It's
an exciting project to be involved in, and I know you're eager to dive in and set up that first
Exchange 2013 server.
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.
Active Directory Requirements

The system requirements for Exchange Server 2013 include the following for Active
Directory:
 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
*** Forest: exchangeserverpro.net ***
Forest Mode: Windows2003Forest

Schema Master: HO-DC.exchangeserverpro.net
*** Domain: exchangeserverpro.net ***
Domain Mode: Windows2003Domain

PDC Emulator: HO-DC.exchangeserverpro.net
Infrastructure Master: HO-DC.exchangeserverpro.net
RID Master: HO-DC.exchangeserverpro.net
*** Global Catalogs by Site/OS ***
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.
For more information on discovering client versions in an existing Exchange environment

see the following article:
 Exchange Server 2013 Planning and Discovery – Client Versions3
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.
To review existing database quotas use the following script:
• PowerShell Script to Audit Exchange Server Database Storage Quotas4

Mismatched database quotas can cause mailbox migrations to fail, and it will also be a poor
experience if your users unexpectedly reach a quota shortly after they are migrated to
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.
Email Routing Topology

Gaining an understanding of the email routing topology for the environment will be helpful
when planning changes to Transport services as the migration project continues.
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.
Internal/External Client Access DNS Names

The existing Exchange Server 2010 configuration will tell you what the Client Access
namespaces are for the environment.
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.
Applications and Devices Integration

For many organizations the Exchange Server also provides an SMTP service for other
applications or devices on the network that need to send email messages or alerts. And
most Exchange Servers will be integrated with at least two or three third party software
products.
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.
To simplify the namespace configuration and certificate provisioning the following

namespaces have been chosen. These are based on the existing namespaces deployed in the
Exchange Server Pro organization, collected during the information gathering stage using
the Get-VirDirInfo.ps1 script.
• autodiscover.exchangeserverpro.net (HTTP – Autodiscover)
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:
 include the HTTP, SMTP and POP/IMAP namespaces (a SAN certificate)

 does not include any server host names
 be installed on all Client Access servers (ie, same certificate for all servers, not
separately provisioned certificates for each)
 be issued by a trusted third party certification authority such as Digicert
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.
First, a quick review of existing Autodiscover configurations should be performed.
From the information gathering stage where we ran the Get-VirDirInfo.ps1 script we
already know that the following Autodiscover URLs are configure:
• br-ex2010-mb.exchangeserverpro.net
Another view of this information can be seen by running Get-ClientAccessServer.
[PS] C:\>Get-ClientAccessServer | Select

Name,AutodiscoverServiceInternalURI,AutodiscoverSiteScope | Fl
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 :
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.
For more on configuring site scope refer to this article:
• Modifying Autodiscover Site Scope for Exchange 20109

In a migration scenario where new servers are being introduced to the organization in a
different Active Directory site, the site scope can be used to avoid having Outlook clients
connecting to your new servers for Autodiscover. If you have not configured site scope it is
recommended to do so before installing the first Exchange 2013 server.
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.
For example, if a single site exists and the Autodiscover namespace is

autodiscover.exchangeserverpro.net, then as long as the Exchange 2013 server is also
configured with that Autodiscover namespace, you can use DNS to only resolve that name
to your existing Exchange servers IP addresses, or resolve to a load balanced VIP that
distributes the traffic only to those Exchange 2010 servers.
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:
• Avoiding Server Names in SSL Certificates for Exchange Server 201310

To summarize, the primary objectives here are to use Autodiscover namespace and/or site
scope configurations to prevent Outlook clients from connecting to an Exchange 2013
server that has not been full provisioned, to avoid SSL warning dialogs appearing, and also
to optimize the Autodiscover configuration in larger environments.
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.
[PS] C:\>Get-MailboxDatabase | select name,offlineaddressbook | sort name
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.
PS C:\> "Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt,"

+ ([ADSI]"LDAP://RootDSE").schemaNamingContext)).rangeUpper
Exchange Schema Version = 14734
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.
Next, launch a CMD prompt as administrator.
22
Run setup /PrepareSchema, including the /IAcceptExchangeServerLicenseTerms switch as
well.
C:\Admin\ex2013sp1>setup /prepareschema /iacceptexchangeserverlicenseterms
Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup

Copying Files...
File copy complete. Setup will now collect additional information needed for
installation.
Performing Microsoft Exchange Server Prerequisite Check
Prerequisite Analysis COMPLETED
Configuring Microsoft Exchange Server
Extending Active Directory schema COMPLETED
The Exchange Server setup operation completed successfully.
Run the schema version script again to compare the results.
PS C:\> "Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt,"

+ ([ADSI]"LDAP://RootDSE").schemaNamingContext)).rangeUpper
Exchange Schema Version = 15292
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.
C:\Admin\ex2013sp1>setup /preparead /iacceptexchangeserverlicenseterms
Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup

Copying Files...
File copy complete. Setup will now collect additional information needed for
installation.
Performing Microsoft Exchange Server Prerequisite Check
Prerequisite Analysis COMPLETED

Setup will prepare the organization for Exchange 2013 by using 'Setup /PrepareA
D'. No Exchange 2007 server roles have been detected in this topology. After thi
s operation, you will not be able to install any Exchange 2007 servers.
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms
.exch.setupreadiness.NoE12ServerWarning.aspx
Configuring Microsoft Exchange Server
23
Organization Preparation COMPLETED
The Exchange Server setup operation completed successfully.
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.
The installation involves:
• 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)
Configuring the Autodiscover URI

To avoid Outlook security alert issues for end users the AutoDiscover URI should be
immediately updated on the Exchange 2013 Client Access servers to use the AutoDiscover
namespace for the organization. This is performed by opening the Exchange Management
Shell on an Exchange 2013 server and running the following commands.
[PS] C:\>Set-ClientAccessServer ex2013srv1 -AutoDiscoverServiceInternalUri

[PS] C:\>Set-ClientAccessServer ex2013srv2 -AutoDiscoverServiceInternalUri

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.
Exchange Server 2013 Management Tools

On the Exchange 2013 servers there are three parts to the Exchange management tools:
• The Exchange Admin Center, a web-based administration console

• The Exchange Management Shell, a PowerShell interface for Exchange 2013
• The Exchange Toolbox, which contains a few MMC-based tools for Exchange 2013
For a migration scenario you will primarily be using the Exchange Admin Center and the
Exchange Management Shell.
• A Quick Look at Exchange Server 2013 Management Tools23
Accessing the Exchange Admin Center During

Co-Existence
The Exchange Admin Center is accessed using a web browser. It is available on any
Exchange 2013 server with the Mailbox server role installed. Because this is a web-based
console you do not need to log on directly to the server to use it, nor do you need to install
any management tools on your admin workstation to access it.
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.
Exchange Admin Center Redirects to Exchange

Server 2010 Outlook Web App
If you log on to the Exchange Admin Center with a user account that has an Exchange 2010
mailbox then you may be redirected to the Exchange 2010 OWA page instead.
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:
1. Manage Exchange 2013 mailboxes, servers, and corresponding services.
2. View and update Exchange 2010 mailboxes and properties.

3. View and update Exchange 2007 mailboxes and properties.
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."
Transport rules are a slightly different situation. From TechNet24:
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:
 autodiscover.exchangeserverpro.net (HTTP – Autodiscover)

 mail.exchangeserverpro.net (HTTP – Outlook Anywhere, OWA, ECP/EAC,
ActiveSync, EWS, OAB)
 imap.exchangeserverpro.net (IMAP)
 pop.exchangeserverpro.net (POP)
 smtp.exchangeserverpro.net (SMTP)\
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:
1. Generate a Certificate Request for Exchange 201325

2. Submit the certificate request to the CA to generate the SSL certificate. For real world
production environments I recommend Digicert26 for their competitive pricing, good
support, flexible licensing, and free re-issues if you happen to make an error.
3. Complete the pending certificate request27
4. Export/import an SSL certificate to multiple Exchange 2013 servers28
5. Assign the SSL certificate to services in Exchange 201329
The same SSL certificate is used on both servers. This means that the certificate is acquired
for EX2013SRV1, then exported and imported for EX2013SRV2. You should not provision
separate SSL certificates for Client Access servers that will be accessed by clients via the
same namespaces.
Install an SSL certificate on your new Exchange 2013 servers.
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.
Configuring Client Access URLs

The Client Access URLs are configured to match the namespaces that we planned earlier.
Because the AutoDiscover URL was already configured immediately after Exchange 2013
was installed that only leaves:
• 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:
[PS] C:\Admin>.\ConfigureURLs.ps1 -Server ex2013srv1 -InternalURL

mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net
[PS] C:\Admin>.\ConfigureURLs.ps1 -Server ex2013srv2 -InternalURL

mail.exchangeserverpro.net -ExternalURL mail.exchangeserverpro.net
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.
[PS] C:\Admin>iisreset ex2013srv1
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
[PS] C:\Admin>iisreset ex2013srv2
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
Configure POP/IMAP Settings

If you are also using POP or IMAP in your environment you should configure those services
as well. For each server set the X509 certificate name, and the internal/external connection
settings.
[PS] C:\>Set-PopSettings -Server ex2013srv1 -X509CertificateName

pop.exchangeserverpro.net -InternalConnectionSetting
pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS -
ExternalConnectionSettings
pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS
WARNING: Changes to POP3 settings will only take effect after all Microsoft Exchange
POP3 services are restarted on
server EX2013SRV1.
[PS] C:\>Set-PopSettings -Server ex2013srv2 -X509CertificateName

pop.exchangeserverpro.net -InternalConnectionSetting
pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS -
pop.exchangeserverpro.net:995:SSL,pop.exchangeserverpro.net:110:TLS
WARNING: Changes to POP3 settings will only take effect after all Microsoft Exchange
POP3 services are restarted on
server EX2013SRV2.
Restart the POP services for the servers.
[PS] C:\>Invoke-Command -ComputerName ex2013srv1,ex2013srv2 {Restart-Service

MSExchangePOP3}
35
The same basic process applies to IMAP as well.
[PS] C:\>Set-ImapSettings -Server ex2013srv1 -X509CertificateName

imap.exchangeserverpro.net -InternalConnectionSetting
imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS -
imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS
WARNING: Changes to IMAP4 settings will only take effect after all Microsoft Exchange
IMAP4 services are restarted on
server EX2013SRV1.
[PS] C:\>Set-ImapSettings -Server ex2013srv2 -X509CertificateName

imap.exchangeserverpro.net -InternalConnectionSetting
imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS -
imap.exchangeserverpro.net:993:SSL,imap.exchangeserverpro.net:143:TLS
WARNING: Changes to IMAP4 settings will only take effect after all Microsoft Exchange
IMAP4 services are restarted on
server EX2013SRV2.
[PS] C:\>Invoke-Command -ComputerName ex2013srv1,ex2013srv2 {Restart-Service

MSExchangeIMAP4}
Configuring Mailbox Databases

Exchange 2013 setup places a mailbox database in a default location on the C: drive of the
server. After install you should move the transaction logs and database files to the volumes
that you have provisioned to host them.
 Move an Exchange Server 2013 Database to a New Location31
Testing the Server Configuration

Ideally we would test the new configuration before pointing any production users at it.
However, to test in this case we would need to change the DNS records for our Client
Access namespaces (autodiscover.exchangeserverpro.net and mail.exchangeserverpro.net)
to resolve to the IP address of the Exchange 2013 servers. Since that would potentially have
a negative impact on end users, instead we can use a hosts file to point a test PC at the new
servers.
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:
• Installing an Exchange Server 2013 Database Availability Group33

• Configuring Database Copies in an Exchange Server 2013 Database Availability
Group34
Complete the configuration of Client Access and Mailbox services.
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.
• Configuring Outbound Mail Flow in Exchange Server 201335

Inbound mail flow does not go to the new Exchange servers until the MX records or firewall
rules are updated.
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.
• How to Configure a Relay Connector in Exchange Server 201336
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.
General Health Check

Before any migration or cutover of services it pays to verify that the current Exchange
Server 2010 environment is in good health. This avoids potential support confusion if a
service is cutover to Exchange 2013, is found to be not working, and then it is unknown
whether the service was already faulty or whether it was the cutover that caused the fault
to occur.
Here are a few suggestions:
• Run Test-ExchangeServerHealth.ps137 to perform a health check of the servers

• Use the ExRCA tools to test external access
– Note that the ActiveSync test may fail on the final step if your ActiveSync
mailbox policy does not allow non-provisionable devices. Either use a different
mailbox policy for the test user you use for ExRCA, or use a mobile device to
perform the testing instead.
• Confirm that backups for Exchange 2010 are functioning correctly
• Review the Exchange 2010 server event logs for any unusual errors
• Launch Outlook for a new test user and verify that Autodiscover works correctly
• Test Exchange Web Services by doing free/busy lookups
• Verify that mail flow between existing servers is healthy by sending email between
mailboxes on each server.
Run health checks and tests of your new servers do verify readiness for co-existence and
the cutover of production namespaces and services.
Configure Outlook Anywhere

During co-existence all Outlook connections to mailboxes are via the Exchange 2013 Client
Access servers using RPC-over-HTTPS (Outlook Anywhere), even internal connections.
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:
[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and

$_.IsClientAccessServer} | Get-OutlookAnywhere | fl
servername,externalhostname,*auth*
ServerName : HO-EX2010-MB1
ExternalHostname : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods : {Basic}
ServerName : HO-EX2010-MB2
ServerName : BR-EX2010-MB
The IISAuthenticationMethods need to be updated to include NTLM.
[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and

$_.IsClientAccessServer} | %{Set-OutlookAnywhere "$_\RPC (Default Web Site)" -
IISAuthenticationMethods Basic,NTLM}
Review and correct the Outlook Anywhere configuration on your Exchange 2010 servers in
readiness for co-existence.
Configure Virtual Directories

The Exchange 2013 Client Access server virtual directories should be checked to ensure
they are configured correctly for your environment.
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:
• Publishing Exchange Server 2013 using TMG38

For organizations that are simply NATing port TCP 443 (HTTPS) to the Client Access
servers then this is less of an issue and changing authentication types likely has no other
significant technical considerations.
Review the virtual directory configurations on your Exchange 2013 servers.
Communicate Changes to Users

This may seem obvious but communicating the upcoming changes to end users is
important. Particularly for OWA, which will present the Exchange 2013 OWA logon to
Exchange 2010 users once the OWA namespace is pointed at the Exchange 2013 CAS and it
is pre-authenticating and proxying connections to Exchange 2010. Naturally the OWA
interface itself is new in Exchange 2013, so some training or documentation updates for
end users may be wise.
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
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.
Cut Over External Namespaces

For the Exchange Server Pro organization the external namespaces are:
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.
For more on managing changes to MX records see the following article:
• Managing Changes to MX Records and Incoming Email Traffic39

After making the changes to public DNS and/or your firewall NATing repeat the testing and
health checks performed earlier to verify that services are working as expected.
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.
Cut Over Internal Namespaces

For the Exchange Server Pro organization the external namespaces are:
• 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.
What about Internal Outlook Users?

At this point you may be wondering what are the real impacts to internal Outlook users
when you make the internal namespace changes in DNS.
Exchange 2010 mailbox users will continue to connect to the same

RPCClientAccessServer as before. Their Outlook profiles do not change. However, their
connectivity for the namespaces that have been pointed to Exchange 2013 (ie
Autodiscover, EWS, etc) will go to the Exchange 2013 CAS where they are then proxied to
Exchange 2010 as necessary to fulfil the requests.
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.
Get-Mailbox -Arbitration -identity "SystemMailbox{e0dc1c29-89c3-4034-b678-

e6c29d823ed9}"
You can learn more about the mailbox move process here:
• Moving Exchange Server 2013 Mailboxes41

For the rest of the organization the migration follows this process:
1. Run the Get-MailboxReport.ps1 script

2. Choose a sample of pilot users, with the rest of the mailboxes assigned to a small
number of batches that increase in size from first to last
3. Migrate the pilot mailboxes
4. Migrate each subsequent batch
For each migration batch the administrator running the migration only needs to:
1. Create and start each migration batch

2. Monitor the progress of the migration batch
3. When ready, notify end users of a brief outage for that evening and then complete the
migration batch
4. Repeat for the next batch
With the mailbox migrations complete the next step is to look at public folder migration.
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.
At a high level the process involves:
1. Downloading the migration scripts

2. Preparing for the migration
3. Generating the CSV files
4. Creating the public folder mailboxes in Exchange 2013
51
5. Starting the migration
6. Lock the public folders for final migration (which requires some downtime)
7. Finalize the migration (downtime still required)
8. Test and unlock the public folder migration
Of course the reality is that there are many caveats and ways for a public folder migration
to go wrong. Generally speaking you should always refer to the TechNet article as it will
document the latest requirements and limitations for a public folder migration. However
you can also refer to the following resources for some additional real-world advice:
• The dirty little secret about migration to modern public folders42

• Exchange 2013 modern public folder limitations – what next?43
• Legacy Public Folders to Exchange 2013 migration tips44
• Modern Public Folders Migration & Office 36545
Here is an example migration for the Exchange Server Pro organization, to show you what
the end to end process looks like.
Download Scripts and Prepare Organization

The public folder migration scripts have been downloaded and saved to a server that has
the Exchange 2010 management tools installed.
A snapshot of the existing public folder structure, statistics, and permissions is taken. These
commands are run from the Exchange 2010 management shell.
[PS] C:\PFMigration>Get-PublicFolder -Recurse | Export-CliXML

C:\PFMigration\Legacy_PFStructure.xml
[PS] C:\PFMigration>Get-PublicFolderStatistics | Export-CliXML

C:\PFMigration\Legacy_PFStatistics.xml
[PS] C:\PFMigration>Get-PublicFolder -Recurse | Get-PublicFolderClientPermission |

Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML
C:\PFMigration\Legacy_PFPerms.xml
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.
[PS] C:\PFMigration>Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name

-like "*\*"} | Format-List Name, Identity
Verify that no record exists of a previous public folder migration. The values returned here
should be $false.
[PS] C:\PFMigration>Get-OrganizationConfig | Format-List

PublicFoldersLockedforMigration, PublicFolderMigrationComplete
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-Mailbox -PublicFolder
[PS] C:\PFMigration>Get-PublicFolder
Generate CSV Files and Create Public Folder

Mailboxes
With the preparation completed we can now generate the CSV files that will be used to
create the new public folder mailboxes on Exchange 2013. Run the following command in
the Exchange 2010 management shell. Replace the server name HO-EX2010-PF with the
name of one of your public folder servers.
[PS] C:\PFMigration>.\Export-PublicFolderStatistics.ps1 C:\PFMigration\PFSizeMap.csv

HO-EX2010-PF
[10/7/2015 2:55:24 PM] Enumerating folders under NON_IPM_SUBTREE...

[10/7/2015 2:55:25 PM] Enumerating folders under NON_IPM_SUBTREE completed...6
folders found.
[10/7/2015 2:55:25 PM] Retrieving statistics from server EX2010SRV1
[10/7/2015 2:55:25 PM] Retrieving statistics from server EX2010SRV1 complete...14
folders found.
[10/7/2015 2:55:25 PM] Total unique folders found : 14.
[10/7/2015 2:55:25 PM] Exporting statistics for 14 folders
[10/7/2015 2:55:25 PM] Exporting folders to a CSV file
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.
[PS] C:\PFMigration>.\PublicFolderToMailboxMapGenerator.ps1 10000000

C:\PFMigration\PFSizeMap.csv C:\PFMigration\PFMailboxMap.csv
[10/7/2015 2:56:35 PM] Reading public folder list...
[10/7/2015 2:56:35 PM] Loading folder hierarchy...
[10/7/2015 2:56:35 PM] Allocating folders to mailboxes...
[10/7/2015 2:56:35 PM] Trying to accomodate folders with their parent...
[10/7/2015 2:56:35 PM] Exporting folder mapping...
54
On an Exchange 2013 server create a public folder mailbox to be the master hierarchy
mailbox.
[PS] C:\>New-Mailbox -PublicFolder Mailbox1 -HoldForMigration:$true
Name Alias ServerName ProhibitSendQuota

---- ----- ---------- -----------------
Mailbox1 Mailbox1 ex2013srv1 Unlimited
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
[PS] C:\PFMigration>For ($index = 2; $index -le $numberOfMailboxes; $index++)

{
$PFMailboxName = "Mailbox" + $index
New-Mailbox -PublicFolder $PFMailboxName
}
Name Alias ServerName ProhibitSendQuota

---- ----- ---------- -----------------
Migrating the Public Folders

With the new mailboxes created in Exchange 2013 we can proceed with the migration. The
steps below are for migrating public folders from Exchange Server 2010 to Exchange
Server 2013.
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.
[PS] C:\PFMigration>Start-MigrationBatch PFMigration
Monitor the progress of the public folder migration batch until it reaches a state of
“Synced”.
[PS] C:\PFMigration>Get-MigrationBatch PFMigration
Identity Status Type

TotalCount
-------- ------ ----
----------
PFMigration Synced PublicFolder
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.
[PS] C:\PFMigration>Get-MigrationUser -BatchId PFMigration
Identity Batch Status

LastSyncTime
-------- ----- ------
------------
Mailbox1 PFMigration Synced
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.
[PS] C:\>Set-OrganizationConfig -PublicFoldersLockedForMigration:$true
56
With the public folders locked we can complete the migration. In the Exchange 2013
management shell run the following commands.
[PS] C:\PFMigration>Set-OrganizationConfig -PublicFoldersEnabled Remote
[PS] C:\PFMigration>Complete-MigrationBatch PFMigration
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.
[PS] C:\>Set-Mailbox ex2013test -DefaultPublicFolderMailbox Mailbox1
With the test successful the following command is run from an Exchange 2013 server or
management shell.
[PS] C:\>Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -

IsExcludedFromServingHierarchy $false
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.
[PS] C:\>Set-OrganizationConfig -PublicFolderMigrationComplete:$true
And finally, the following command is run from the Exchange 2013 management shell.
[PS] C:\>Set-OrganizationConfig -PublicFoldersEnabled Local
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.
Edge Transport Servers

To decommission an Exchange 2010 Edge Transport server verify that no more mail is
flowing through the server. This is achieved by configuring transport and cutting over
SMTP namespaces. You can use protocol logs46 and message tracking logs47 to verify this.
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
Name Site Domain

---- ---- ------
HO-EX2010-EDGE exchangeserverpro...
[PS] C:\>Remove-EdgeSubscription HO-EX2010-EDGE
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:
C:\Program Files (x86)\Log Parser 2.2>logparser "select Count(cs-username) as Count,

cs-username as Username from 'C:\inetpub\logs\logfiles\w3svc1\*.*' group by Username
order by Count(Username)" -i:IISW3C
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.
Hub Transport Servers

Hub Transport servers can be removed when there is no more email traffic passing through
them, and they are not the source Transport server for any Send Connectors. As with the
Edge Transport role you can use protocol logs and message tracking logs to verify this.
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:
[PS] C:\>Get-PublicFolderDatabase -Server BR-EX2010-MB | Remove-PublicFolderDatabase
Confirm
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.
[PS] C:\>Get-MailboxDatabase -Server BR-EX2010-MB
Name Server Recovery ReplicationType

---- ------ -------- ---------------
MB-BR-01 BR-EX2010-MB False None
MB-BR-02 BR-EX2010-MB False None
63
[PS] C:\>Remove-MailboxDatabase MB-BR-01
Confirm
Removing mailbox database "MB-BR-01".
located in
F:\Data\MB-BR-01\MB-BR-01.edb from your computer manually if it exists. Specified
database: MB-BR-01
[PS] C:\>Remove-MailboxDatabase MB-BR-02
Confirm
Removing mailbox database "MB-BR-02".
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.
[PS] C:\>Move-ActiveMailboxDatabase -Server HO-EX2010-MB2
Verify that the server only hosts passive database copies. You should see no “Mounted”
status in this output.
[PS] C:\>Get-MailboxDatabaseCopyStatus -Server HO-EX2010-MB2
Name Status CopyQueue ReplayQueue

LastInspectedLogTime ContentIndex
Length Length
State
---- ------ --------- ----------- -
------------------- ------------
MB-HO-01\HO-EX2010-MB2 Healthy 0 0
64
7/25/2014 10:35:27 AM Healthy
7/25/2014 10:35:21 AM Healthy
7/25/2014 3:08:47 PM Healthy
Remove the database copies from the server.
[PS] C:\>Get-MailboxDatabaseCopyStatus -Server HO-EX2010-MB2 | Remove-

MailboxDatabaseCopy
If you are removing the second last DAG member you’ll first need to turn off DAC mode.
[PS] C:\>Set-DatabaseAvailabilityGroup -Identity dag-headoffice -

DatacenterActivationMode Off
Remove the server from the DAG.
[PS] C:\>Remove-DatabaseAvailabilityGroupServer -Identity dag-headoffice -

MailboxServer HO-EX2010-MB2
You can then proceed with the uninstall.
When all members have been removed from the DAG you can also remove the DAG object
itself.
[PS] C:\>Remove-DatabaseAvailabilityGroup dag-headoffice
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

Exchange 2010 To 2013 Migration Guide PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Exchange 2010 To 2013 Migration Guide PDF

Încărcat de

Drepturi de autor:

Formate disponibile

© Copyright 2015 Paul Cunningham, LockLAN Systems Pty Ltd

About the Author

Paul Cunningham is an Exchange Server MVP and Systems Consultant living

Active Directory Requirements

*** Forest: exchangeserverpro.net ***

Forest Mode: Windows2003Forest

*** Domain: exchangeserverpro.net ***

Domain Mode: Windows2003Domain

*** Global Catalogs by Site/OS ***

For more information on discovering client versions in an existing Exchange environment

 Exchange Server 2013 Planning and Discovery – Client Versions3

To review existing database quotas use the following script:

• PowerShell Script to Audit Exchange Server Database Storage Quotas4

Email Routing Topology

Internal/External Client Access DNS Names

Applications and Devices Integration

To simplify the namespace configuration and certificate provisioning the following

• autodiscover.exchangeserverpro.net (HTTP – Autodiscover)

 include the HTTP, SMTP and POP/IMAP namespaces (a SAN certificate)

First, a quick review of existing Autodiscover configurations should be performed.

[PS] C:\>Get-ClientAccessServer | Select

For more on configuring site scope refer to this article:

• Modifying Autodiscover Site Scope for Exchange 20109

For example, if a single site exists and the Autodiscover namespace is

• Avoiding Server Names in SSL Certificates for Exchange Server 201310

[PS] C:\>Get-MailboxDatabase | select name,offlineaddressbook | sort name

PS C:\> "Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt,"

Next, launch a CMD prompt as administrator.

C:\Admin\ex2013sp1>setup /prepareschema /iacceptexchangeserverlicenseterms

Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup

Performing Microsoft Exchange Server Prerequisite Check

Prerequisite Analysis COMPLETED

Configuring Microsoft Exchange Server

Extending Active Directory schema COMPLETED

The Exchange Server setup operation completed successfully.

Run the schema version script again to compare the results.

PS C:\> "Exchange Schema Version = " + ([ADSI]("LDAP://CN=ms-Exch-Schema-Version-Pt,"

C:\Admin\ex2013sp1>setup /preparead /iacceptexchangeserverlicenseterms

Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup

Performing Microsoft Exchange Server Prerequisite Check

Prerequisite Analysis COMPLETED

Configuring Microsoft Exchange Server

The Exchange Server setup operation completed successfully.

The installation involves:

Configuring the Autodiscover URI

[PS] C:\>Set-ClientAccessServer ex2013srv1 -AutoDiscoverServiceInternalUri

[PS] C:\>Set-ClientAccessServer ex2013srv2 -AutoDiscoverServiceInternalUri

Exchange Server 2013 Management Tools

• The Exchange Admin Center, a web-based administration console

• A Quick Look at Exchange Server 2013 Management Tools23

Accessing the Exchange Admin Center During

Exchange Admin Center Redirects to Exchange

1. Manage Exchange 2013 mailboxes, servers, and corresponding services.

2. View and update Exchange 2010 mailboxes and properties.

Transport rules are a slightly different situation. From TechNet24:

 autodiscover.exchangeserverpro.net (HTTP – Autodiscover)

1. Generate a Certificate Request for Exchange 201325

Install an SSL certificate on your new Exchange 2013 servers.

Configuring Client Access URLs

[PS] C:\Admin>.\ConfigureURLs.ps1 -Server ex2013srv1 -InternalURL

[PS] C:\Admin>.\ConfigureURLs.ps1 -Server ex2013srv2 -InternalURL

[PS] C:\Admin>iisreset ex2013srv1

[PS] C:\Admin>iisreset ex2013srv2

* Forest: exchangeserverpro.net *

* Domain: exchangeserverpro.net *

* Global Catalogs by Site/OS *

[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "14." -and

[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "14." -and