Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 11)

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

Configuring the Exchange 2010 Multi-Role Server

Exporting the certificate as PFX format

The CSR file and SSL certificate files created in the previous part of this series won’t be suitable to apply to our Exchange 2013 server when we install it later, so we’ll take the opportunity to clean up those files and export the actual certificate and private key pair from the Exchange 2010 server now.

To perform this step, again navigate to Server Configuration in the Exchange Management Console, select the valid SSL certificate with the correct name, then select Export Exchange Certificate from the Actions pane on the right hand side.

Figure 1: Exporting the SSL certificate

The Export Exchange Certificate wizard should open. Select a location to save the Personal Information Exchange (PFX) file and an appropriate strong password, then choose Export:

Figure 2: Selecting a path and password for the PFX file

Make a note of this location, as we’ll specify the UNC file share path on our Exchange 2013 server later on in this guide.

Assigning the SSL certificate to services

Although we have an SSL certificate correctly installed on the Exchange 2010 server it’s not automatically used by services. We’ll need to specify which services we want to allow it to be used with. To perform this step, within Server Configuration select the certificate again and then choose Assign Services to Certificate:

Figure 3: Selecting the correct certificate to assign services to

Next, after ensuring our new Exchange 2010 server is chosen, select the appropriate services, typically Internet Information Services (IIS):

Figure 4: Assigning services to IIS

After the certificate is assigned, ensure it is in use by running the following command:

Iisreset /noforce

Configuring Exchange URLs using the Exchange Management Shell

Now our certificate is in place and enabled, it’s time to set the appropriate URLs for each Virtual Directory on Exchange Server 2010.

We’ll configure the following services

  • Outlook Web App
  • The Exchange Control Panel
  • Exchange ActiveSync
  • Exchange Web Services
  • The Offline Address Book
  • Outlook Anywhere
  • and the Exchange Connection Point

As we are using a single HTTPS name, this is a straightforward process best accomplished using the Exchange Management Shell.

To update the Service Connection Point, we’ll use the Set-ClientAccessServer cmdlet from the Exchange Management Shell, using the AutoDiscoverServiceInternalURI parameter to update the actual SCP within Active Directory.

Set-ClientAccessServer   -Identity LJD-E1401 -AutoDiscoverServiceInternalURI

Figure 5: Updating the SCP

As there are quite a few places we’ll need to change the URLs, this is best accomplished using PowerShell, using the simple script below.

What we’ll do is use the first two lines of the script to specify the name of the Exchange 2013 server, in the $Server variable, and the HTTPS name used across all services in the $HTTPS_FQDN variable. The subsequent lines use this information to correctly set the Internal and External URLs for each virtual directory:

$Server =   “LJD-E1401”

$HTTPS_FQDN   = “”

Get-OWAVirtualDirectory   -Server $Server | Set-OWAVirtualDirectory -InternalURL   “https://$($HTTPS_FQDN)/owa” -ExternalURL   “https://$($HTTPS_FQDN)/owa”

Get-ECPVirtualDirectory   -Server $Server | Set-ECPVirtualDirectory -InternalURL   “https://$($HTTPS_FQDN)/ecp” -ExternalURL   “https://$($HTTPS_FQDN)/ecp”

Get-OABVirtualDirectory   -Server $Server | Set-OABVirtualDirectory -InternalURL   “https://$($HTTPS_FQDN)/oab” -ExternalURL   “https://$($HTTPS_FQDN)/oab”

Get-ActiveSyncVirtualDirectory   -Server $Server | Set-ActiveSyncVirtualDirectory -InternalURL   “https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync” -ExternalURL   “https://$($HTTPS_FQDN)/Microsoft-Server-ActiveSync”

Get-WebServicesVirtualDirectory   -Server $Server | Set-WebServicesVirtualDirectory -InternalURL   “https://$($HTTPS_FQDN)/EWS/Exchange.asmx” -ExternalURL   “https://$($HTTPS_FQDN)/EWS/Exchange.asmx”

In the example below, we’ve specified both our server name LJD-E1401 and HTTPS name and then updated each Virtual Directory accordingly:

Figure 6: Updating Internal and External HTTPS URLs

Configuring Send and Receive Connectors

In part three of this series we examined the configuration for the SMTP service on Exchange 2003 and recorded any IP addresses allowed to relay through the server. In Exchange 2007 and above, Receive Connectors are used to specify which clients or servers can connect via SMTP and how the server handles them. Therefore we will need to create a specific Receive Connector for the clients that are allowed to relay anonymously.

To begin, launch the Exchange Management Console and navigate to Server Configuration>Hub Transport and select the Exchange 2010 server from the list, then choose New Receive Connector:

Figure 7: Selecting the Exchange 2010 and choosing to create a new Receive Connector

Because your configuration is likely to vary ensure that as you proceed through this wizard you enter relevant settings for your organization, so use this example to help familiarize yourself with how we apply the settings for Lisa Jane Designs’ Anonymous relay connector.

On the first page of the wizard, enter the name for the receive connector. For consistency we’ve specified the server name after entering Anonymous Relay. We’ll also choose Custom as the type:

Figure 8: Selecting a Receive Connector name and type

On the next page, we’ll be provided with the opportunity to specify Network Adapter Bindings – the IP address and TCP/IP port that the receive connector will listen on. Our example receive connector will listen on the standard port for SMTP, port 25:

Figure 9: Selecting TCP/IP port and bindings

On the final page of the wizard, we’ll choose which IP addresses that the receive connector will accept mail for. This allows multiple receive connectors to listen on the same TCP/IP port and IP address and swing into action depending on the remote IP address of a client. As our SMTP service on Exchange 2003 only allowed mail relay from the IP addresses, we’ll specify that range here:

Figure 10: Selecting IP ranges or IP addresses to receive mail for

After completing the wizard, we will then open the new Receive Connector’s properties page. We’ll first select the Permission Groups tab and select Anonymous users and Exchange servers, the first of which ensures that unauthenticated mail can be received by this connector.

Figure 11: Selecting Permissions for the Receive Connector

We’ll then select the Authentication tab and ensure Externally Secured is selected

Figure 12: Selecting authentication for the Receive Connector

With this configuration complete, our Exchange 2010 staging server should be ready to relay email from the same devices that currently relay through via Exchange 2003. When we’ve finished and tested the confiugration consider starting to move devices to use the DNS name internally rather than the IP address – that will help ensure you only need to reconfigure devices once as we move to Exchange 2013 later on.

Configuring Mailbox Databases

After the installation of Exchange Server 2010 we get a default mailbox database that contains arbitration mailboxes and the default Discovery Search mailbox, along with a Public Folder Database. As the installation of Exchange uses a default name for the Mailbox Database and uses a default location, we’ll want to move the first database to its correct location and create the additional databases we need.

As a quick recap we have designed our example Exchange 2010 organization for Lisa Jane Designs to use the following database names and locations:

Database Database File Log Folder
DB01 C:\ExchangeDatabases\DB01 C:\ExchangeDatabases\DB01_Log
DB02 C:\ExchangeDatabases\DB02 C:\ExchangeDatabases\DB02_Log
DB03 C:\ExchangeDatabases\DB03 C:\ExchangeDatabases\DB03_Log
DB04 C:\ExchangeDatabases\DB04 C:\ExchangeDatabases\DB04_Log
DB05 C:\ExchangeDatabases\DB05 C:\ExchangeDatabases\DB05_Log

To rename and move the first 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 LJD-E1401 | Set-MailboxDatabase -Name DB01

Figure 13: Renaming the default Mailbox Database

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

With our database renamed, we now need to move it to the right location. 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:\ExchangeDatabases\DB01\DB01.EDB -LogFolderPath   C:\ExchangeDatabases\DB01_Log

Figure 14: Moving the default Mailbox 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 or proceeding 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 fairly straightforward and accomplished using the Exchange Management Console or the Exchange Management Shell.

We’ll first look at how to do this using the EMC. From Exchange 2010 onwards, Databases are stored at the organization level rather than with each server, even for a small deployment like this one. Therefore navigate to Organization Configuration>Mailbox then choose the Database Management tab. Choose New Mailbox Database to get started:

Figure 15: Using the EMC to create an additional Mailbox Database

In the New Mailbox Database wizard, enter the second database name when prompted:

Figure 16: Using the wizard to specify the Mailbox Database name

Next, enter the paths as per the design for the Database file path and Log folder path, similar to below. Ensure you unselect the option to Mount this database – we’ll mount the database after removing the default Public Folder Database (remember, we’re not moving Public Folders across as part of this series):

Figure 17: Using the wizard to specify the Mailbox Database locations

We can accomplish the same tasks using the Exchange Management Shell, using the New-MailboxDatabase command. You’ll see in the example PowerShell commands below we create each database using the New-MailboxDatabase command:

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

Figure 18: Using PowerShell to create new Mailbox Databases

Configuring Mailbox Database Settings

With our databases either moved or created we will now need to configure the right settings for each database to meet our design parameters. Let’s have a quick refresh of those settings:

Setting Value
Issue warning at 490MB
Prohibit send at 495MB
Prohibit send and receive at 500MB

In addition to those settings above we’ll make two more changes to our new databases; firstly we will change the Public Folder Database to an Exchange 2003 database (again – we’re not moving Public Folders over in this series) and we will set the Default Offline Address Book.

We’ll quickly look at how to do this via either the Exchange Management Console or Exchange Management Shell – just like with creating the Databases, it’s up to you which you prefer.

In the EMC we’ll navigate to our Databases and for each one run through the same steps. First we’ll choose Properties:

Figure 19: Editing the properties for each Mailbox Database using the EMC

Then on the Limits tab of the Properties window we’ll enter the values from our design into the Issue warning at, Prohibit send at and Prohibit send and receive at fields:

Figure 20: Editing Mailbox Database limits

Next, on the Client Settings tab we’ll select the Default Public Folder Database to be our old Exchange 2003 back-end server, then choose the current default Offline Address Book.

Figure 21: Changing the Public Folder Database and Offline Address Book

Wondering why we’re specifying the Default Offline Address book, even though by leaving it blank Exchange will select it? The reason for setting this now is because when we install Exchange 2013 it will create a new Offline Address Book and set it as the default instead.

If you would prefer to accomplish this via the Exchange Management Shell, we can use the Get-MailboxDatabase command to select all databases on the server, then pipe the results to the Set-MailboxDatabase command to alter the properties of all databases:

Get-MailboxDatabase -Server LJD-E1401 | Set-MailboxDatabase   -IssueWarningQuota 490MB -ProhibitSendQuota 495MB -ProhibitSendReceiveQuota   500MB -OfflineAddressBook “Default Offline Address List”   -PublicFolderDatabase “LJD-E2003BE\First Storage Group\Public Folder   Store (LJD-E2003BE)”

Figure 22: Using PowerShell to set Mailbox Database settings

We’ll revisit the Mailbox Database settings later on, as after migration to Exchange 2010 and removal of any pre-Outlook 2007 clients we will clear the Public Folder database setting on each database and say goodbye to Public Folders for good.


Our base configuration of our Exchange 2010 staging server is complete, we’ll remove the default Public Folder database and move on to testing the server ready for mailbox moves in the next part of this series.

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

Leave a Comment

Your email address will not be published.

Scroll to Top