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

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

Introduction

In part two of this series we began our discovery process to better understand the Exchange 2003 environment we’re migrating away from. After using the Exchange Profile Analyzer and Pre-Deployment Analyzer we collected mailbox quota information before moving onto understanding SMTP transport configuration. In part three, we’ll continue examining the SMTP configuration before looking at Public Folder infrastructure, clients and third-party software and applications.

Discovery and Remediation

Internal Relays

As well as send out mail, we’ll also expect our Exchange 2003 servers to receive it, and in many circumstances allow devices like multi-function scanners or application servers to relay mail through it.

We’ll collect information on which IP addresses are allowed to relay from the Exchange System Manager, by navigating to each server, then expanding Protocols>SMTP then right-click the Default SMTP Virtual Server and choosing Properties:

Image
Figure 1: Viewing the Default SMTP Server

Choose the Access tab, then select Relay:

Image
Figure 2: Viewing device IP addresses that can relay

Record the settings and list of IP addresses that are allowed to relay as we’ll need to create a receive connector on Exchange 2010 and Exchange 2013 after setup.

Public Folder Infrastructure

For larger organizations it is often a challenge to completely move away from Public Folders to alternative technologies, and if you have applications that depend on them you may need to consider keeping them around.

Most smaller organizations will benefit from moving away from Public Folders when moving to Exchange 2013. There is no supported client that requires Public Folders, and the migration path if you only have a small number of Public Folders is not easy. Instead we will look to move away from Public Folders rather than migrating them to Exchange 2010, then migrating them a second time to Modern Public Folders in Exchange 2013.

In our example organization, we’ll use the Exchange System Manager to view the Public Folder infrastructure at a high level:

Image
Figure 3: Viewing Public Folders

In the example above we see there’s not many Public Folders in use. For a lot of organizations who are small or mid-sized, a small number of Public Folders is common. We will replace the shared email addresses and team calendars with Shared Mailboxes. In Exchange 2003, this will simply be mailboxes that we will drag and drop content across to using the Outlook client. After the migration to Exchange 2013, we’ll set the Mailbox type to “Shared” using the Exchange Management Shell.

For each Public Folder, we’ll record important information that will need to be re-applied to the shared mailbox once it is created. Right click each Public Folder and choose Properties, then in the Permissions tab, record the Client Permissions:

Image
Figure 4: Examining Client permissions for a Public Folder

Make a note of the permissions in a table similar to the one shown below:

Public Folder User / Group Permission
Management Calendar lisa.goodman Owner
Management Calendar jane.cartwright Editor
[email protected] marty.junior Owner
[email protected] Sales Team Owner

Table 1

Additionally, for each Public Folder used to receive email, select the Email Addresses tab and record the SMTP values listed – for example:

Public Folder Email Address
[email protected] [email protected]
[email protected] [email protected]
[email protected] sales @lisajanedesigns.co.uk

Table 2

In this article we will not walk through the steps to create an Exchange 2003 mailbox, but the following steps are recommended to ensure best success when moving content from each Public Folder to each replacement Shared Mailbox:

  1. Create a new Mailbox to host content. For mail-enabled Public Folders, give the replacement Mailbox a temporary email address.
  2. For owners of the Public Folder, grant Full Access to the Mailbox.
  3. For users with a lower level of access, such as Editor or Reviewer, access the Mailbox with an administrative account granted Full Access and set folder-level permissions to the Inbox, Calendar, Contacts folder (whichever is appropriate).
  4. For mail-enabled Public Folders, switch the email addresses with the new Mailbox.
  5. From an administrative account with Owner access to the source Public Folder and Full Access to the target Mailbox, move content across. A quick tip – to move Calendar items switch the view in Outlook to list first.
  6. After ensuring content has been moved across, remove the source Public Folder and direct clients to the new Mailbox.

Although it’s not typical to perform these tasks during discovery, the result of the moves should be done before we design our Exchange 2013 solution, as the content moved to mailboxes will affect the storage requirements. After you move your Public Folders revisit Mailbox Quotas and Connectors section in the previous part of this series so you do not miss any important data.

Internal and External Clients

If your organization chose to stay on Exchange 2003 this long, it’s possible you may have one or two older clients hanging around. You will need to ensure Outlook clients in use are upgraded if needed so they are compatible with Exchange 2013, and any incompatible clients (such as WebDav clients like Mac Entourage 2004 and 2008) are replaced too.

The following Microsoft clients are compatible with Exchange 2013:

  • Outlook 2013.
  • Outlook 2010 SP1 with the November 2012 update or higher.
  • Outlook 2007 SP3 with the November 2012 update or higher.
  • Entourage 2008, Web Services Edition.
  • Outlook for Mac 2011.

Naturally all of the above will work best when fully up to date – so take the above as a minimum standard, a fully patched Outlook will work even better.

When it comes to web browsers we’ve got a similar, simple list:

  • Internet Explorer 9 or later.
  • Firefox 17 or later.
  • Chrome 24 or later.
  • Safari for Mac 6 or later.

Our two lists of supported clients and browsers mean that the oldest clients really do need to be upgraded. If you need to keep Windows XP clients around, then they will only be able to use Outlook 2010 and/or an alternative web browser instead of Internet Explorer to access Exchange 2013.

If we’re planning on upgrading clients, we’ve got a secondary problem. If Outlook or Entourage clients are found that require an upgrade, they won’t be able to be upgraded to the latest versions while each user’s Mailbox is on Exchange 2003; Neither Outlook 2013, Entourage 2008 Web Services Edition or Outlook 2011 for Mac support Exchange 2003.

If you encounter the above problem that means you must consider one of the following options:

  • Only upgrade Outlook 2003 or earlier clients to Outlook 2010 rather than Outlook 2013.
  • Leave some mailboxes on Exchange 2010 for a longer period once they can be upgraded to the latest versions, prolonging the migration process.
  • Force unsupported clients to use Outlook Web App instead of Outlook/Entourage after migration, until their client is updated.

To survey our environment we’ll use a combination of tools. The primary tool we’ll use to scan clients is the Microsoft Assessment and Planning Toolkit. This will allow us to see which clients meet minimum requirements, and ascertain if the underlying Windows OS and hardware can support an upgrade to a newer version.

Download MAP and install it on an administrative workstation. For best results, make sure that client firewall rules (adjustable using Group Policy) allow our workstation or server to access them, and of course make sure you run the scan at a time when all client workstations are switched on and accessible.

To begin, we’ll choose the Desktop option and perform scans for Office 2013 readiness by choosing Collect Inventory Data:

Image
Figure 5: Using MAP to collect inventory data

The data collection process may take some time, as it must scan each workstation individually and then collate data. After collecting inventory data about our environment, we’ll then be able to export that from MAP by choosing Generate Office 2013 Report from the Options section:

Image
Figure 6: Exporting MAP data

The data will then be exported as an Excel Spreadsheet named Office2013Assessment-<DateTime>.xlsx to the MAP folder within the current user’s Documents directory.

Open the Excel spreadsheet and examine the OfficeAppSummary and Office2013Assessment worksheets. This data will be your first point of reference when determining how to upgrade clients.

For non-Windows clients, such as WebDAV clients like Entourage and of course ActiveSync devices we will use my Exchange IIS Log Parser PowerShell script, available from the TechNet Exchange Gallery.

Download ExIISLogParser.zip and copy it to a location that has PowerShell (any version) and access to the IIS Log files on the Exchange 2003 server(s) that are accessed by clients – in our example organization LJD-E2003FE which has PowerShell installed.

We’ll run the script with simple options to read from the default log directory, check the last 30 days of logs and output the results to a CSV file in the current directory:

.\ExIISLogParser.ps1 -Days 30 -OutputCSVFile   .\ExternalClients.csv

The output file generated will allow you to filter certain clients, as shown in the example output below:

Image
Figure 7: Viewing parsed logfile data in Excel

We’ll use this data to ensure we know which WebDAV clients to update, as ActiveSync clients should continue to access Exchange 2013 without requiring an update.

Third-Party Software

Finally we’ll need to understand the third-party software in use within the organization. To ensure we don’t detract from the upgrade process itself in this series, our example organization, Lisa Jane Designs does not use any third party software that we need to be concerned about. However in the real world we’ll need to consider:

  • Server-side software including:
    • Mail Server Anti-Virus and Anti-Spam
    • Signature software
    • Monitoring software
    • Fax Server software
    • Voicemail and/or Unified Message software
    • Mobile Device Management software
    • Backup software
  • Client software add-ins and applications including:
    • Microsoft Office Plug-Ins
    • CRM and other line-of-business application integration
    • Applications that interface with or update Outlook Calendars

Each environment is different, but do not assume that software that works with Exchange 2003 (or Outlook 2003) will work with newer versions. In particular the underlying interface clients use (direct MAPI in Exchange 2003 versus RPC over HTTPS in Exchange 2013) will affect the way application software and clients interface. Before beginning, survey all your relevant third-party software and confirm supportability and implications for upgrade.

Summary

In the third part of this series we’ve concluded our discovery of the Exchange 2003 environment and been able to make some decisions for the future of any Public Folders and clients that require upgrades. With third-party software some work will exist to understand what can be upgraded or replaced and work with vendors to help understand their upgrade paths. In this series though we’ll stay focused on our Exchange upgrade and begin planning the upgrade 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.

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

Scroll to Top