Planning and migrating a small organization from Exchange 2007 to 2013 (Part 13)

By /

If you would like to read the other parts in this article series please go to:

Introduction

With HTTPS URLs, Outlook Anywhere and Transport configured for Exchange, a number of key components required before Exchange 2013 can coexist are now in place.

In the next part of this series, we’ll get our Exchange Server ready for Mailbox Moves by configuring Mailbox Databases before moving onto testing everything works as expected.

We’ll finish by starting to implement coexistence by enabling new SSL certificates, adding new DNS records and making changes to virtual directory settings on Exchange 2013.

Configuring Mailbox Databases

We’re now ready to configure our new Exchange Server’s Mailbox Databases. We’ve already got the first one ready to go – this was installed as part of the server installation and simply needs some tweaking to move it into the right place, and configure it’s settings. We’ll then need to create our additional databases.

These are going to be laid out logically on the volumes we’ve created for them, mounted within C:\ExchangeVolumes:

Image
Figure 1: Mount points for Exchange Databases

Moving Default Mailbox Databases

For simplicity, we’ll move the initial database and make it our first Mailbox Database, DB01. To rename and move the database is a simple, two step process, most easily accomplished using the Exchange Management Shell. We’ll launch it and use the following command to get the single database on the server, and rename it to DB01:

Get-MailboxDatabase -Server E15M01 | Set-MailboxDatabase -Name DB01

Image
Figure 2: Renaming the existing Database

You’ll see by executing the command Get-MailboxDatabase, as shown above how the database looks within Exchange both before, and after, the command is executed.

With our database renamed correctly, we now need to move it to the right location, as it’s still sitting within the Exchange installation folders. We’ll accomplish this using the Move-DatabasePath command, specifying both the Database location (the EdbFilePath) and the location for the Database’s associated log files (the LogFolderPath):

Move-DatabasePath -Identity DB01 -EdbFilePath C:\ExchangeVolumes\DB01\DB01.EDB -LogFolderPath C:\ExchangeVolumes\DB01_Log

Image
Figure 3: Moving the existing database

To move the database, it must be first dismounted within Exchange, so if it is currently mounted, we’ll be given the opportunity to confirm to proceed with the move, as shown above.

Creating Additional Mailbox Databases

With our first mailbox database moved to the right place, it’s time to create our remaining mailbox databases. This is a simple affair, whether you prefer to use the Exchange Admin Center or the Exchange Management Shell.

If the EAC is your weapon of choice, simply navigate to Servers>Databases and choose Add, as shown below:

Image
Figure 4: Using the EAC to create databases

Then, enter the Mailbox Database name, database location and log folder path. Because database information is stored within Active Directory, it’s advisable to unselect Mount this database as you create the database, as shown below:

Image
Figure 5: Specifying basic settings for new databases

After creating each Mailbox database, you’ll be recommended to restart the Microsoft Exchange Information Store Service. This is because the amount of cache the Information Store allocated depends on the number of databases with copies on the server. Therefore, for it to correctly calculate the amount of memory it requires for cache purposes, restart the service.

After giving the service a quick restart, select each database and choose Mount from the More Options (…) drop-down:

Image
Figure 6: Using the EAC to mount new databases

We can accomplish the same tasks using the Exchange Management Shell, using the New-MailboxDatabase, Restart-Service and Mount-Database commands. You’ll see in the example PowerShell commands below we create each database using the New-MailboxDatabase command, restart the Information Store, and then mount each database:

New-MailboxDatabase -Name DB02 -Server E15M01 -EdbFilePath C:\ExchangeVolumes\DB02\DB02.EDB -LogFolderPath C:\ExchangeVolumes\DB02_Log

Restart-Service MSExchangeIS

Get-MailboxDatabase | Mount-Database

Image
Figure 7: Creating new databases and mounting databases using PowerShell

Configuring Mailbox Database Settings

Databases moved or created, we need to configure the right settings for each to meet our design parameters. Let’s have a quick refresh of those settings:

Warning Limit

Prohibit Send Limit

Prohibit Send/Receive Limit

Keep Deleted Items for (days)

Keep Deleted Mailboxes for (days)

800MB

825MB

850MB

14

30

Table 1

First, let’s look at how to accomplish this via the EAC. Navigate to Databases, then after choosing the first database we’ll edit, choose Edit, as shown below:

Image
Figure 8: Modifying database settings using the EAC

In the Mailbox database properties window that open, choose Limits and adjust as appropriate to match your design. We’ll also set the default Offline Address Book, which is specified in the Client Settings section. After completing this task for the first database, repeat manually for each other mailbox database on the new Exchange 2013 server.

If you’d prefer to use a handy one liner to accomplish this via the Exchange Management Shell, we can use the Set-MailboxDatabase command to alter the properties of each database. Making that even easier, we’ll retrieve all the databases on our Exchange 2013 server using the Get-MailboxDatabase cmdlet:

Get-MailboxDatabase -Server E15M01 | Set-MailboxDatabase -IssueWarningQuota 800MB -ProhibitSendQuota 825MB -ProhibitSendReceiveQuota 850MB -OfflineAddressBook “Default Offline Address Book (Ex2013)” -DeletedItemRetention “14:00:00” -MailboxRetention “30:00:00”

Image
Figure 9: Using PowerShell to modify all new databases

Getting ready for coexistence

With our database settings in place and ready to go, we can start thinking about co-existence – before we do though, it’s time to make sure things work within Exchange 2013! So far we’ve got our new server up and running, but we’ve still not logged in and checked everything works as expected.

Creating test accounts

First, we’ll create some test accounts to allow us to verify functionality. We’ll create these accounts via the Exchange Admin Center, by opening the EAC, and navigating to Recipients>Mailboxes, then selecting Add>User Mailbox, as shown below:

Image
Figure 10: Creating test mailboxes using the EAC

We don’t need any special settings for these new test mailboxes – by creating the mailboxes using the EAC they will automatically be created on Exchange 2013.

Testing base functionality

After creating our test mailboxes we’ll now need to test that they are functional from a client. We’ll expect that by navigating to OWA via the server’s name things should work, but really we want to test using the new URLs and HTTPS namespace we’ve configured. Unfortunately that’s not altogether straightforward, because the name we’ll be using while we co-exist with Exchange 2007 is currently being used by the Exchange 2007 Server.

Naturally there’s a simple solution for the aforementioned problem, and this is to alter the hosts file on the test client we’ll be using to verify functionality from. The hosts file is used by clients before checking the organization’s DNS server and allows us to override settings, temporarily, on our test client. This enables us to accurately test what the experience should be like before we actually configure co-existence.

To edit our host file, we’ll use Start>Run from our test client and then execute the following command, which will attempt to open the hosts file in Notepad:

notepad %systemroot%\system32\drivers\etc\hosts

After choosing OK, you’ll see the host file displayed. Entries in the host file are specified in the format <IP Address> <Hostname>, so we’ll just add a couple of new entries; first pointing our mail and autodiscover HTTPS names towards our Exchange 2013 server, and a second entry pointing our legacy name at our Exchange 2007 server as shown below:

Image
Figure 11: Editing the hosts file using Notepad

With our hosts file updated, we’ll then navigate to our normal OWA URL. Whilst existing clients will continue to see Exchange 2007 OWA, our test client should be presented with the Exchange 2013 OWA login screen, with the correct, valid SSL certificate, as shown below:

Image
Figure 12: Testing login and SSL certificates using a web browser

After checking the SSL certificate is indeed valid and correct, login to the test mailbox created above, and ensure functionality within OWA works as expected. As a minimum test mail flow works correctly between our new Exchange 2013 test user and existing Exchange 2007 users.

Image
Figure 13: Verifying OWA functionality

With OWA working, we’ll move on to test our desktop clients like Outlook. As our test client has an updated hosts file to look directly towards Exchange 2013, we’ll expect that setup of Outlook 2007 and above will fly through without any issues. To test this, launch Outlook and click through the setup wizard, allowing AutoDiscover to automatically configure the account. After it’s configured settings correctly, we’ll choose Manually configure server settings to give us a change to double check it’s picked up the right settings:

Image
Figure 14: Testing configuration of a new mailbox using Outlook

After choosing to manually configure settings, we’ll then see Exchange 2013 details within the server name field. If you’re used to seeing the physical server name here, then prepare for a surprise. What you’ll see in the server name field will be the GUID that corresponds to the mailbox, rather than the server name itself:

Image
Figure 15: Verifying Outlook client settings

The above GUID is completely normal and we won’t expect to ever see the actual Exchange 2013 server name, so if you’re seeing the GUID, simply press Finish and allow Outlook to launch for the first time:

Image
Figure 16: Verifying Outlook client functionality with Exchange 2013

As with OWA, perform some basic tests to ensure mail flow functions correctly and the client experience is as expected.

Configuring Coexistence

The coexistence stage of our migration will allow us quite simply to run both Exchange 2007 and Exchange 2013 side-by-side while we migrate users to Exchange 2013. Clients will continue to connect, users will still be able to login to Outlook Web App, use ActiveSync devices and more without interruption and without needing to make any changes to the clients they use.

When we enable coexistence, all connections by clients will initially be directed to Exchange 2013, and depending on the client will be proxied to Exchange 2007, or redirected. The latter is why we’re configuring a legacy namespace to use for Exchange 2007 clients during the migration.

Enabling SSL certificates on TMG and Exchange 2007 Servers

Before we change DNS entries and publishing rules to implement coexistence, we’ll need to implement our new SSL certificate that includes both the main HTTPS namespaces (mail and autodiscover) along with the new legacy namespace on both our Forefront TMG server and on our Exchange 2007 server. We’ve already imported the certificate onto both servers, so now it’s just a case of enabling those certificates.

We’ll start with our TMG server. On our TMG server, we’ll start by opening the properties of the Listener that’s used to accept SSL connections, and navigate to the Certificates tab, then choose Select Certificate:

Image
Figure 17: Changing SSL certificates using the TMG GUI

We’ll then be presented with the Select Certificate window, where we’ll see both the current certificate, and the new coexistence certificate. If you’re not sure which one is which, check both the Friendly Name and the Expiration Date; then select to correct certificate:

Image
Figure 18: Selecting the new SSL certificate to enable on TMG

After changing the certificate, finally ensure the certificate changes are saved and made live by choosing the Apply button within the TMG Console:

Image
Figure 19: Applying SSL certificate changes within TMG

Certificate in place on the TMG server, we’ll move swiftly on to our Exchange 2007 Server. When we imported the certificate earlier, we made a note of the Thumbprint of the certificate to ensure this part is a single command:

Enable-ExchangeCertificate -Thumbprint B7134E94DF2A98D7BC2111B077F9ED241ED8C003 -Services IIS

Image
Figure 20: Enabling the new SSL certificate in Exchange 2007

After making these changes, test clients to make sure no unusual effects are observed – all being well clients should not see any certificate prompts or notice this change in any way.

Creating Legacy DNS records

With the certificate in place on Exchange 2007, it’s time to add our new legacy DNS record that will soon be used for access to our old Exchange server while we migrate mailboxes.

We’ll first add the internal DNS record that will point internal clients to Exchange 2007, using the DNS Manager. Select your split-zone DNS and choose Add new record. We’ll add an A resource record with the internal IP address of our Exchange 2007 server:

Image
Figure 21: Creating internal legacy DNS records using DNS Manager

We’ll also add the new legacy DNS entry into external DNS – in our example organization pointing at the same external TMG server IP address used for Exchange at present:

Image
Figure 22: Creating external DNS records using an example control panel

After adding the new record into DNS, make sure you can successfully access OWA (internally at this stage) using the new name, and receive no certificate warnings, as shown below:

Image
Figure 23: Verifying OWA functionality using the legacy DNS name

Updating Exchange 2013 OWA and EAC Authentication

Because in our example organization we’re using TMG authentication, we’ll need to make another change before we go live with coexistence. Typically, TMG pre-authentication requires that Windows Integrated Authentication is enabled on Exchange internally. Therefore, if your organization is set up this way, you’ll need to make the same change.

We’ll do this by visiting the Exchange Admin Center, and navigating to Servers>Virtual Directories and first selecting the Exchange 2013 OWA virtual directory and choosing Edit, as shown below:

Image
Figure 24: Navigating to edit virtual directory settings within the EAC

We’ll then select the Authentication tab and change from using Forms-Based Authentication, the default, to using Integrated Windows Authentication, then choosing Save.

Image
Figure 25: Updating the OWA virtual directory to use Windows Integrated Authentication

We’ll need to make the same change for the ECP virtual directory, which is used both for OWA options and the Exchange Admin Center:

Image
Figure 26: Selecting the ECP virtual directory to make identical changes

After successfully updating both virtual directories, open a command prompt as an elevated user, then type iisreset to stop and start Internet Information Services, reloading the OWA and ECP applications:

Image
Figure 27: Restarting web services on Exchange 2013

After making this change, double check you can access the Exchange Admin Center. You should automatically get signed in without requiring forms-based authentication, using the credentials you are logged in with.

Summary

In this article we’ve finished the configuration of our new mailbox databases by configuring the settings as per our design. We then created test accounts and verified base functionality of Exchange 2013 before proceeding with our first steps to implement coexistence. In the next part in this series we’ll complete the configuration of coexistence and verify coexistence is implemented correctly.

If you would like to read the other parts in this article series please go to:

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top