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

By /

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

Introduction

In the first part of this multi-part series, we looked at the existing Exchange 2007 infrastructure, how it will look during and after migration and walked through the high level steps we’ll need to take to migrate to Exchange 2013. In the second part of this series, we’ll guide you through the first part of the discovery you need to perform. This will help you better understand your Exchange 2007 organization before planning and implementing Exchange 2013.

Discovery

Depending on your organisation, you might need to look into more areas than we look in within this article – for example if you use a Mobile Device Management solution or have custom applications that are written to integrate with Exchange. However as a bare minimum, we’d expect to find out the information we’ll collect here.

Tools to use

Where possible it makes sense to use existing tools you’ve got available to minimise the amount of time it takes to collect information and the amount of work that we need to do. Therefore we can use the following tools to collect data from Exchange:

  • The Exchange Management Console
  • The Exchange Management Shell for basic data collection and export
  • Exchange Environment Report Script
  • Exchange Profile Analyser
  • Exchange Best Practices Analyser
  • IIS Log Analysis
  • Windows Server Update Services reporting

We’ll begin though by collecting some very basic environment information.

Current Exchange Server Namespaces

When we realm about namespaces, we are looking to find out the names that are defined in Exchange for communication with Client Access Servers via protocols including HTTPS, IMAP and where used, access to Hub Transport Servers via the SMTP protocol.

For larger organisations, it makes more sense to script the reporting of URLs, but for a small organisation it takes a couple of minutes to collect this information.

We’ll begin by using the Exchange Management Console (EMC) to collect information about Internal and External URLs for Outlook Web App, The Offline Address Book and ActiveSync. For each service, navigate to the relevant tab within Server Configuration>Client Access then double click the listed Virtual Directory:

Image
Figure 1: Image of EMC with Virtual Directory highlighted

After opening the properties dialog window for the virtual directory, record the External URL and Internal URL for each.

Image
Figure 2: Virtual directory for Outlook Web App shown

Next, we’ll collect the value used for Outlook Anywhere. Right click the Server Name in the EMC, and choose Properties:

Image
Figure 3: Open the Properties for the Client Access Server

Then, choose the Outlook Anywhere tab and make a note of the External Host Name:

Image
Figure 4: Viewing the Outlook Anywhere Hostname

There’s a couple for URL values we aren’t able to collect from the EMC, so we’ll need to open the Exchange Management Shell and use a couple of commands to return the information we need. First, lets grab the Internal URL and External URL for Exchange Web Services:

Get-WebServicesVirtualDirectory | fl Name, InternalURL, ExternalURL

Image
Figure 5: Output of Get-WebServicesVirtualDirectory

We’ll also need to retrieve the Service Connection Point value used for the Exchange Server. This value (or values for multiple servers) is the AutoDiscover URL that is provided to Outlook clients that are domain joined:

Image
Figure 6: Output of Get-ClientAccessServer

Finally we’ll examine the SSL certificates and subject alternative names in use. You can if you wish view these details by accessing the server directory, or simply by visiting the Internal and External URLs from the LAN and externally examining the Subject Alternative Names recorded on the certificate:

Image
Figure 7: Viewing Subject Alternative Names using a web browser

Record the names listed on the certificates, and then verify the names listed are actually in DNS. If they aren’t listed in either internal or external DNS then that means the names aren’t actually in use and we can consider ignoring them. For example, to check internal Active Directory-integrated DNS, we’ll access a Domain Controller and open DNS Management. Navigate to the domain and verify each Subject Alternative Name (and FQDN) listed.

Image
Figure 8: Verifying Exchange Names in the DNS management console

Finally we’ll revisit the Exchange Management Console and view the name used – if any – for services including POP and IMAP. Navigate to Server Configuration, then select the respective IMAP and POP tabs and select the properties for each service. Record the x509 certificate subject name from the Authentication tab as shown below.

Image
Figure 9: Viewing the x509 certificate subject name

To determine whether you need to consider either IMAP or POP namespaces, we’ll check the service startup settings for both. Open the Services Management Console via Start>Run then entering services.msc and scroll down to find the Microsoft Exchange POP3 and Microsoft Exchange IMAP services as shown below.

Image
Figure 10: Viewing startup state for IMAP and POP3 services

By default these will be set as Disabled and Stopped. If they are set to start up automatically, then we’ll need to record the names.

After collection the namespaces, we’ll record them as shown below:

Service Internal URL External URL / FQDN
OWA https://mail.exchangelabs.co.uk/OWA https://mail.exchangelabs.co.uk/OWA
OAB https://mail.exchangelabs.co.uk/OAB https://mail.exchangelabs.co.uk/OAB
EWS https://mail.exchangelabs.co.uk/EWS/Exchange.asmx https://mail.exchangelabs.co.uk/EWS/Exchange.asmx
Outlook Anywhere N/A mail.exchangelabs.co.uk
POP3 N/A mail.exchangelabs.co.uk
SCP https://autodiscover.exchangelabs.co.uk/Autodiscover/Autodiscover.xml

Table 1

Exchange Environment Report

A great way of collecting information about the overall Exchange environment is by using my Exchange Environment Report script. This script will provide information about the Exchange Servers within the organisation and includes site-level topology, installed roles, patch levels and information about Mailbox Databases such as used space.

Download the Exchange Environment Report script from the TechNet Script Gallery and copy it to either the Exchange Server, or a host with the Exchange Management tools installed. As a pre-requisite for running the script you will need to ensure the host running the script has PowerShell 2.0 installed.

From an Exchange Management Shell, navigate to the directory you’ve downloaded and extracted the script to. Then to generate a simple one-time report, execute the command with the following parameters:

.\Get-ExchangeEnvironmentReport -HTMLReport .\Report.html

You should see the script collecting data, as shown below:

Image
Figure 11: Exchange Environment Report in progress

After the script completes, examine the output which should be similar to the HTML report shown here:

Image
Figure 12: Screenshot of Exchange Environment Report HTML output

If you have any issues executing the script, you might need to perform one of the following actions:

  • Unblock the script file in Windows Explorer, by right-clicking the file and choosing properties, and then choosing ‘Unblock File’
  • Temporarily relax script execution permissions in PowerShell using the command Set-ExecutionPolicy Unrestricted. After you’ve used the script you may to change this back to it’s original value.

Exchange Profile Analyser

The EPA tool allows us to scan mailboxes within the existing environment to determine some very important values that will assist with sizing the environment. When we size Exchange 2013, we’ll need to know the average message size and the average number of messages sent and received each day. We can collect this data using this tool.

First, we’ll need to assign the correct permissions to allow the EPA to read data from the mailboxes within the environment. To allow EPA to scan all mailboxes on our single Exchange Server, we’ll use the following set of commands at the Exchange Management Shell to set permissions against all Mailbox Databases on the server. In our case we’ll use E12M01 as the server name and Administrator as the username, so replace those values with appropriate ones for your environment:

Get-ExchangeServer E12M01 | Add-ADPermission -user Administrator -AccessRights ExtendedRight -ExtendedRights “Send-As”

Get-ExchangeServer E12M01 | Add-ADPermission -user Administrator -AccessRights ExtendedRight -ExtendedRights “Receive-As”

Image
Figure 13: Setup for EPA account permissions

Next, we’ll download the Exchange Profile Analyser from the Microsoft website. We can install this tool on an administrative workstation or for our example, we’ll install the tool on the local, single Exchange Server for simplicity.

After install using the default options, launch the Exchange Profile Analyser. After launch, choose Connect to Active Directory and press, next. Then, we’ll choose to connect to Active Directory using the current user credentials:

Image
Figure 14: Selecting to connect the EPA to Active Directory using the current user

The current Exchange topology will be loaded by the EPA.

Before beginning the scan, we’ll then set options including leaving Logging/Stats Options as-is with Information selected, and Output Statistics for Individual Mailbox left unselected, and select our Exchange 2007 Servers.

We’ll then ensure scanning over a period of time that is representative. For example, if it’s currently during the summer holidays and we only scan a couple of weeks, our data may be incorrect because end users are on holiday and therefore sending less mail. Or if we are only scanning a period of time that represents then busiest period, for example the week that coincides with the year end, then our average figures may be skewed too high. A period of perhaps three to six months therefore may be a good starting figure to consider.

Image
Figure 15: Screenshot of EPA options

After setup of the base options, we’ll begin the scan by choosing Start Collect. Expect this to take quite a long time especially if you’ve got a larger number of mailboxes and needed to scan a longer period of time.

Upon completion, we’ll be presented with a number of statistics. First, scroll down and look for the section Results with Time Frame Applied:

Image
Figure 16: Viewing the EPA Report

First, expand Message Size. The value shown below Avg shows our Average Message Size.

Image
Figure 17: The Average Message Size

For the Send and Receive averages, expand Message Frequency and record the Avg figure shown against Aggregates of messages received per weekday including dumpster (real) and Aggregates of messages sent per weekday including dumpster (real).

Image
Figure 18

We’ll use those figures to generate a table of average message size and average send/receive daily counts.

Average Message Size Average Received Average Sent
147.61KB 15.25 14.94

Table 2

Exchange BPA

Sadly the Exchange Best Practices Analyser, and it’s sibling the Exchange 2010 Pre-Deployment Analyser are no longer a part of Exchange 2013, but that isn’t to say that they are not useful. We’ll use the output from the Exchange BPA to help identify whether there’s any well known underlying issues we need to be aware of and correct before moving forward with the Exchange 2013 deployment.

To launch the BPA, open the Exchange Management Console and navigate to the Toolbox. Then select Exchange Best Practices Analyser:

Image
Figure 19: Launching the BPA

After launching the BPA, first check for updates, select a domain controller, and then select scan settings as shown below:

Image
Figure 20: Choosing Exchange BPA Scan options

After the scan completes, review the BPA results and save the results of the scan using the Export option shown below:

Image
Figure 21: Viewing BPA results and exporting data

Summary

In the second part of this series we’ve started performing discovery against our Exchange 2007 environment. In the next part in this series, we’ll continue to retrieve important data about the existing Exchange environment, focusing on Quotas and limits next before moving onto Client information.

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

1 thought on “Planning and migrating a small organization from Exchange 2007 to 2013 (Part 2)”

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