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

by [Published on 2 July 2013 / Last Updated on 2 July 2013]

In the last part of this series we began performing discovery against our existing Exchange 2007 organization. In this part we'll continue discovery collecting more information about Exchange, before beginning to collect relevant Client information.

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

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: 

Image
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:

Image
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:

Storage Group

Mailbox Database

Issue Warning

Prohibit Send

Prohibit Send/Recieve

MailboxDatabaseSG01

MailboxDatabase01

500MB

520MB

550MB

MailboxDatabaseSG02

MailboxDatabase02

500MB

520MB

550MB

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:

Image
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:

Name

ProhibitSendQuota

ProhibitSendReceiveQuota

IssueWarningQuota

Deetta Marrara

20000MB

unlimited

20000MB

Hayden Creel

20489000KB

unlimited

20000MB

Britany Gullixson

20490000KB

unlimited

20000MB

Belle Lecaros

unlimited

unlimited

unlimited

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.

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

Image
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:

Send Connector

Source Servers

Address Space

Outbound via Mail Essentials

E12M01

*

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:

Image
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:

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

Server

Receive   Connector

Max   Message Size (KB)

IP/Port

Accept   Mail From

Authentication

Permission   Groups

Anonymous   Relay

E12M01

Anonymous Relay E12M01

10240

All/25

192.168.15.210-192.168.15.220

- TLS

- Externally Secured

- Anonymous users

Yes

E12M01

Client E12M01

10240

All/587

All

- TLS

- Basic (after starting TLS)

- Integrated Windows Auth

- Exchange users

No

E12M01

Default E12M01

1024

All/25

All

- TLS

- Basic (after starting TLS)

- Exchange Server Auth

 - Integrated

Windows Auth

- Exchange users

- Exchange servers

- Legacy Exchange servers

No

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

Image
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:

Identity

Replicas

MailEnabled

Size   MB

\Finance

E12M01\PublicFolderSG01\PublicFolderDB01

FALSE

0

\Finance\Invoices

E12M01\PublicFolderSG01\PublicFolderDB01

TRUE

20

\IT\Support

E12M01\PublicFolderSG01\PublicFolderDB01

TRUE

376

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:

Image
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:

UserName

ClientVersion

Alta Armwood

14.0.6025.1000

Monty Granger

12.0.6606.1000

Rod Klutts

11.0.8200.0

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:

Image
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:

Image
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:

Image
Figure 12:
Completed Inventory Results for Office Readiness

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

Image
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:

Application

Product Type

Software Version

Number of Installed Copies

Microsoft Office Professional Edition 2003

Office Suite

11.0.8173.0

1

Microsoft Office Professional Plus 2010

Office Suite

14.0.6029.1000

1

Microsoft Office Outlook 2007

Individual Office product

12.0.6612.1000

1

Table 7

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

Client

Office 2013 Readiness

Action

OS

Service Pack

Office Version

CPU

RAM

HDD Free

CLIENT01

Not Office 2013 Ready

Upgrade to 2 GB RAM

Windows 7 Ent SP1

SP1

Office Pro 2003

Intel Core i5-3470

1024

38

CLIENT02

Not Office 2013 Ready

Upgrade to 2 GB RAM

Windows 7 Ent SP1

SP1

Office Outlook 2007

Intel Core i5-3470

1024

38

CLIENT03

Not Office 2013 Ready

Upgrade to 2 GB RAM

Windows 7 Ent SP1

SP1

Office Pro Plus 2010

Intel Core i5-3470

1024

35

Table 8

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

Image
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:

Featured Links