© 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

1

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!

2

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.

3

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.

4

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

5

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

6

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

7

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

Review your storage quotas, as well as any mailboxes exempt from storage quotas, to make sure that your new Exchange Server 2013 databases are correctly configured.

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

8

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

9

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

10

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.

11

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)

12

• 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

13

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.

14

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:

• autodiscover.exchangeserverpro.net

• 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

15

AutoDiscoverServiceInternalUri : https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml AutoDiscoverSiteScope : {HeadOffice} Name : HO-EX2010-MB2 AutoDiscoverServiceInternalUri : https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml AutoDiscoverSiteScope : {HeadOffice}

Notice the AutoDiscoverSiteScope value above. This is also referred to as “Site Affinity” and is used to tell Outlook clients which Client Access servers to prefer when they are looking for an Autodiscover service to connect to.

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

16

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.

17

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

18

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

19

[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.

20

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

21

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

22

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.

23

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

24

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

25

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.

26

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 https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml [PS] C:\>Set-ClientAccessServer ex2013srv2 -AutoDiscoverServiceInternalUri https://autodiscover.exchangeserverpro.net/Autodiscover/Autodiscover.xml

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

27

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

28

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.

29

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

30

"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.

31

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.

32

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

33

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

34

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).

35

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 -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 EX2013SRV2.

Restart the POP services for the servers.

[PS] C:\>Invoke-Command -ComputerName ex2013srv1,ex2013srv2 {Restart-Service MSExchangePOP3}

36

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 -ExternalConnectionSettings 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 -ExternalConnectionSettings 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

37

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.

38

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

39

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.

40

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

41

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

42

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

43

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 ExternalHostname : mail.exchangeserverpro.net ClientAuthenticationMethod : Basic IISAuthenticationMethods : {Basic} ServerName : BR-EX2010-MB ExternalHostname : mail.exchangeserverpro.net ClientAuthenticationMethod : Basic IISAuthenticationMethods : {Basic}

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.

44

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

45

Cut Over Namespaces With all co-existence preparations complete we can now cut over the namespaces to Exchange Server 2013.

First, let’s be clear that this is a significant change and should be approached with due care. Although the changes themselves are quite simple (mostly DNS changes), they are best performed during a window of time when they will have the least impact on your end users, with enough time for you to test the outcome and roll back if there is a problem.

On the topic of rolling back, your changes should be well planned and well documented as you go along, so that you can easily reverse them if you need to.

Cut Over External Namespaces For the Exchange Server Pro organization the external namespaces are:

• autodiscover.exchangeserverpro.net

• mail.exchangeserverpro.net

In a scenario where the external IP addresses are staying the same the cut over would occur on the edge router or firewall that performs NATing for the network. However in this case the internet-facing Exchange 2010 servers are in the Head Office site, while the new internet-facing Exchange 2013 servers are in the Datacenter1 site which has its own internet connection and a new public IP range.

46

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

47

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:

• autodiscover.exchangeserverpro.net

• mail.exchangeserverpro.net

• imap.exchangeserverpro.net

• pop.exchangeserverpro.net

• smtp.exchangeserverpro.net

High availability for Exchange 2013 Client Access services in Datacenter1 will initially be handled by DNS round robin. So the DNS records for the above namespaces (except SMTP) are updated in the internal DNS zones with two A records, which point to each of the Exchange 2013 IP addresses.

SMTP is a little different. SMTP doesn’t work well with DNS round robin, because many SMTP clients (such as printers) will simply fail a connection if the IP they attempt to connect to doesn’t respond, rather than retry with a different IP as most modern HTTP clients do (including Outlook).

For now the Exchange Server Pro organization is retaining a load balancer for SMTP, so the cut over for SMTP is performed on the load balancer configuration itself. If this cost wasn’t practical or high availability for SMTP wasn’t important then pointing the SMTP namespace at just one Exchange 2013 server IP address would be a reasonable solution.

After making the changes to internal DNS repeat the testing and health checks performed earlier to verify that services are working as expected.

48

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).

49

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

50

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

51

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

52

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

53

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

54

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...

55

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 ---- ----- ---------- ----------------- Mailbox2 Mailbox2 ex2013srv1 Unlimited Mailbox3 Mailbox3 ex2013srv1 Unlimited

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.

56

[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

57

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

58

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.

59

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

60

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.

61

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

62

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.

63

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 Are you sure you want to perform this action? Removing public folder database "PF-BR-01". [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y WARNING: The specified database has been removed. You must remove the database file located in C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\PF-BR-01\PF-BR-01.edb from your computer manually if it exists. Specified database: PF-BR-01

Mailbox databases can be removed if the mailbox migration to Exchange 2013 has been complete. Again, you can use PowerShell to remove them.

[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

64

[PS] C:\>Remove-MailboxDatabase MB-BR-01 Confirm Are you sure you want to perform this action? Removing mailbox database "MB-BR-01". [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y WARNING: The specified database has been removed. You must remove the database file located in F:\Data\MB-BR-01\MB-BR-01.edb from your computer manually if it exists. Specified database: MB-BR-01 [PS] C:\>Remove-MailboxDatabase MB-BR-02 Confirm Are you sure you want to perform this action? Removing mailbox database "MB-BR-02". [Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y WARNING: The specified database has been removed. You must remove the database file located in F:\Data\MB-BR-02\MB-BR-02.edb from your computer manually if it exists. Specified database: MB-BR-02

For DAG members the approach is a little different. The process involves:

1. Removing database copies from the server (unless it is the last DAG member hosting

the single copy of the databases)

2. Removing the server from DAG membership

3. Removing the databases from the standalone server

4. Uninstalling Exchange from the standalone server

5. Removing the DAG object from the organization

For example, removing database copies from HO-EX2010-MB2, first move any active database copies to another DAG member.

[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

65

7/25/2014 10:35:27 AM Healthy MB-HO-04\HO-EX2010-MB2 Healthy 0 0 7/25/2014 10:35:21 AM Healthy MB-HO-02\HO-EX2010-MB2 Healthy 0 0 7/25/2014 3:08:47 PM Healthy

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.