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

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

• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 1)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 2)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 4)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 5)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 6)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 7)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 8)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 9)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 10)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 11)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 12)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 13)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 14)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 15)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 16)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 17)

Mailbox Quotas

Quota limits for mailboxes are by default defined at a Mailbox Database level. We’ll therefore collect details about the limits currently in place. Within the Exchange Management Console, navigate to Server Configuration>Mailbox and view each respective Database properties as shown below:

Figure 1: Viewing Mailbox Database Properties in the Exchange Management Console

From the Database Properties dialog window, record the Warning, Send and Send/Receive Limits as highlighted below:

Figure 2: Viewing Database Limits

As the database limits are shown in Kilobytes, we can divide the values by 1024 (for example 1048576 KB divided by 1024 equals 1024 MB) and then record the values as shown below:

Table 1

To record any exceptions from these defaults we need to be aware of, we’ll then open up the Exchange Management Shell and run the following command to display a list of users with overrides set and the values of those overrides.

Get-Mailbox -ResultSize Unlimited | Where {$_.UseDatabaseQuotaDefaults -eq $False} | Select Name,Prohibit*,Issue*

You’ll see the output below:

Figure 3: Viewing Mailbox Quota Exceptions

If this represents a large number of users, then re-run the command with the following options to export the data to a file name QuotaExceptions.csv:

Get-Mailbox -ResultSize Unlimited|Where {$_.UseDatabaseQuotaDefaults -eq $False} `
| Select Name,Prohibit*,Issue* `
| Export-CSV .\QuotaExceptions.csv -NoTypeInformation

We can then record that information in a table as shown below:

Table 2

Send and Receive Connector Configuration

Send Connectors help your Exchange organization know where to route outbound email destined for non-local recipients, and Receive Connectors provide SMTP connectivity for other Exchange Servers, SMTP clients and inbound external mail.

We’ll collect information about the configuration here to ensure that we know what Send Connectors we’ll be switching across to Exchange 2013, so that any changes elsewhere (such as IP restrictions for relaying) can be actioned; and make sure we understand the Receive Connector configuration that we’ll need to re-create and apply to Exchange 2013.

Examine each Send Connector, by navigating to Organization Configuration>Hub Transport and choosing the Send Connectors tab. You’ll see each Send Connector listed.

Figure 4: Viewing all Send Connectors

Record details of each Send Connector, including which Exchange Servers are currently specified as Source Servers. You’ll find that information by choosing Properties for each Send Connector.

Figure 5: Verification of Source Server settings

Of course, if you’ve only got a single server and send connector like in our example, your job is very easy. We won’t need to re-create the send connectors; but we’ll need to examine the configuration of where they send to and ensure they are allowed to connect. The details we’ve recorded are shown below:

Table 3

Next, we’ll collect information to ascertain if any Receive Connectors have Anonymous relay permissions granted via Active Directory permissions.

We’ll perform this using the Exchange Management Shell using the snippet below:

Get-ReceiveConnector | Get-ADPermission | Where {$_.ExtendedRights -like “*Ms-Exch-SMTP-Accept-Any-Recipient*” -and $_.Deny -eq $False -and $_.User -like “*NT AUTHORITY\Anonymous Logon*”} | fl Identity

After running the commands, you’ll see output similar to that shown below:

Figure 6: Verification of Receive Connectors with Anonymous Relay Permissions

Then, examine each Receive Connector, within Server Configuration>Hub Transport and select the first server you wish to record details for:

Figure 7: Collecting information about each Receive Connector

Open each Receive Connector, and record details both from the PowerShell output, and from each connector’s Properties tab, as shown in the example table below.

Table 4

Public Folder Infrastructure

In previous versions of Exchange, a public folder migration could certainly be a pain, but it was a rather straightforward procedure (unless you needed to troubleshoot) as the key method was to replicate the current public folders to the new Exchange servers, then remove the original replica.

With Exchange 2013, we’ll migrate our Public Folder infrastructure to Modern Public Folders. This means the approach is different, and for larger organizations has additional planning concerns due to the removal of the multi-master model, that while troublesome, allowed users in different sites to access a local copy of the Public Folder they were using.

Our small example site doesn’t have such concerns, but we’ll take a quick snapshot using the Exchange Management Shell to ensure we know the sizes we’ll need to migrate, and in the case you have multiple Public Folder databases, list the replicas.

Get-PublicFolder -Recurse `
|Where {$_.Identity.ToString() -ne “\NON_IPM_SUBTREE”} `
|Select Identity,@{N=”Replicas”;E={[String]::Join(“;”, $_.Replicas)}}, `
MailEnabled,@{N=”Size MB”;E={(Get-PublicFolderStatistics $_).TotalItemSize.Value.ToMB()}} `
|Export-CSV .\PublicFolderOverview.CSV -NoTypeInformation

Figure 8: Exporting Public Folder information

The example above will output a CSV file, which when opened in Excel will show a table of information similar to the one shown below:

Table 5

Bear in mind though that if you don’t use Public Folders, or can easily move away from them, there’s no requirement to implement them with Exchange 2013. As the Outlook 2003 client is no longer supported, there is no client dependency.

Clients

We’ve collected data about our Exchange Server and some high level information about the mailboxes on it that we’ll feed into the design, so now we’ll look at what’s connecting to Exchange 2007 and see if we’ve got any work to do.

Windows Outlook clients supported by Exchange must meet minimum requirements, and for Exchange 2013 that means they must be either:

• Outlook 2013 (Build 15.0.4420.1017 or higher)
• Outlook 2010 Service Pack 1 with at least the November 2012 update (Build 14.0.6126.5000 or higher)
• Outlook 2007 Service Pack 3 with at least the November 2012 update (Build 12.0.6665.5000 or higher)

Remember, Exchange 2007 supports clients as old as Outlook 2002, but in general, we’d expect the majority of older clients to only be as old as Outlook 2003.

Exchange 2013 also supports Mac clients, including Outlook 2011 and Entourage Web Services addition. Apple’s Mac Mail also connects, and naturally you may expect to find ActiveSync, POP3 and IMAP clients if these protocols are enabled. Outside of Exchange, we also have BES users in our environment; however we’ll collect information about these separately when we examine the BES server in a later section.

Logon Statistics

We’ll start on the Exchange Server and use Get-LogonStatistics to grab a snapshot of connected clients. This is a good quick method of checking the build numbers against those shown above; but as it only captures information about currently logged on clients, it’s unlikely this will give you a full picture.

The output from Get-LogonStatistics will only show the current Mailbox server you are logged into by default; and will also show other clients – such as a connected Blackberry Enterprise Server. We’ll use the following command to grab statistics from all Mailbox servers, exclude results that don’t look like Outlook clients using the -match operator, ensure multiple results are removed and export the results to a CSV file:

Get-MailboxServer |% { Get-LogonStatistics -Server $_ } `
| Where {$_.ClientVersion -match “^\d{2}\.”} `
| Select UserName,ClientVersion | Sort -Unique -Property UserName `
| Export-Csv .\UserLogins.csv -NoTypeInformation

When executing the command, you shouldn’t expect to see much output:

Figure 9: Collecting a snapshot of currently logged in clients

However opening the UserLogins.csv file you’ll be shown a table of information as shown below. You’ll see in our output none of the connected clients meet the minimum requirements:

Table 6

If you’re relying on this approach to collect client information then you may need to collect statistics multiple times to provide an accurate picture of your user base.

Microsoft Assessment and Planning Toolkit

Another approach that complements the above, is to use the Microsoft Assessment and Planning Toolkit. The MAP toolkit can be used for many purposes, and in particular can collect and document your existing Outlook client estate.

After downloading and installing the MAP toolkit from the Microsoft Downloads website, navigate to the Desktop tab and scroll down to the Office 2013 Readiness section. We’ll use this to report on the current Office versions in use along with other relevant information that will help if you wish to upgrade clients to the latest version of Office. To begin, select Collect inventory data:

Figure 10: Collecting Inventory data using MAP

The Inventory and Assessment Wizard will be displayed. Within this wizard, enter information about how you will discover client workstations, and credentials you will use to collect. In the example below, a specific Active Directory organizational unit has been selected that contains client workstations and credentials to connect as an Administrator to each workstation have also been provided:

Figure 11: Options specified for Inventory

After choosing Finish discovery will take place and you will be shown clients that could not be contacted. Computers must be switched on, connected to the network and allow the workstation or server the MAP toolkit is installed on to connect via WMI.

After the inventory completes, we’ll now see more information about our readiness for Office 2013. In our example, it doesn’t look good. That’s OK as we’re primarily looking at the versions of Office in use in this scenario. Click on the readiness information as shown below to view more details:

Figure 12: Completed Inventory Results for Office Readiness

To export the data we’ll want to see, choose the option Generate Office 2013 Report:

Figure 13: Generating Office report information

After the data is exported, navigate using Windows Explorer to Documents, then within the MAP subfolder and open the Excel spreadsheet named Office2013Assessement-Date-Time.xlsx.

Within the spreadsheet you’ll find useful information detailed on the OfficeAppSummary worksheet showing the versions in use:

Table 7

On the Office2013Assessment worksheet, you’ll find detailed client information:

Table 8

If Outlook Web App functionality is important to you internally, repeat the post inventory steps, choosing Internet Explorer Discovery instead:

Figure 14: Viewing collected information about IE versions

Summary

In this part of the series we’ve collected information about Mailbox Quotas, Send and Receive Connectors, high level information about our Pubic Folder infrastructure and began collecting information about clients. In the next part of this series we’ll complete our discovery exercise.

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

• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 1)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 2)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 4)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 5)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 6)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 7)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 8)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 9)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 10)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 11)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 12)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 13)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 14)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 15)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 16)
• Planning and migrating a small organization from Exchange 2007 to 2013 (Part 17)