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

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

Introduction

The last two parts of this series focused on gathering information about our Exchange 2007 infrastructure before moving on to begin collating client information using statistics from Exchange itself. In this part of the series we’ll complete collecting information about current Exchange clients using free tools available and collect data about our third-party software.

Completing Discovery

Windows Server Update Services

For discovery, and ensuring remediation of Outlook Clients that simply require patching we can use Windows Server Update Services.

In this article we won’t cover setup and installation, but suffice to say you will need to install WSUS and ensure that clients report into it, typically accomplished via the use of Group Policies. If you don’t currently download patches for the Office suite you will need to ensure these are enabled which can be accomplished from within the Update Services management console by selecting the Office products and categories including Service Packs and Updates within Options>Products and Classifications.

Then, to get a view on just Office patches required, we’ll create a specific Update View. Navigate to Updates, right-click and choose New Update View:

Image
Figure 1:
Creating a new update view in WSUS

Then within the update classification choose Service Packs and Updates and within products, choose the relevant Office versions – for example Office 2002/XP, 2003, 2007, 2010 and 2013:

Image
Figure 2:
Specifying classifications and products for the new update view

After creation of the view you should see the installation status of required updates, and as highlighted below, you’ll have the ability to view the list of computers that require the update.

Image
Figure 3:
Identifying Outlook clients requiring updates

IIS Logfile Analysis (The easy way)

We’ll move on to other clients next, starting with clients that communicate with Exchange via the Web, including searching for clients including:

  • Outlook – covering off any external, non domain-joined and seldom used clients using Outlook 2007 or above.
  • Outlook 2011 and Entourage 2008 Web Services Edition and Mail Mail.
  • Older WebDAV clients such as Entourage 2004 and non Web Services editions of Entourage 2008.
  • ActiveSync clients from all vendors.

LogParser is one option for collecting this data, but for our organization we’ll use a script I’ve prepared earlier specifically written to collect data for Exchange 2007 upgrades, which can be downloaded from my website.

After extracting the downloaded script onto the Exchange 2007 server hosting the Client Access role – in our case our multi-role server, we’ll execute it specifying the path to the IIS Log Files, choose to analyse 30 days of log files and specify an output CSV file IISAnalysis.csv:

.\ExIISLogParser.ps1 -LogFilePath C:\inetpub\logs\LogFiles\W3SVC1 -Days 30 -OutputCSVFile .\IISAnalysis.csv

Upon executing the script, you’ll see the progress as log files are analysed. This may take some time, so if you like coffee you might want to grab one:

Image
Figure 4:
Executing the ExIISLogParser.ps1 script

The results table is wider than the output from the previous discovery commands we’ve executed and the output are best represented in Excel as shown below:

Image
Figure 5: Viewing IIS Discovery Results in Excel

IMAP and POP3 Logfile analysis

By default IMAP and POP3 logging are not enabled within Exchange 2007. If you have enabled IMAP or POP3 and want to discover those clients, you’ll need to enable Protocol Logging in advance.

To accomplish this, navigate to the Exchange Install directory, and then find the PopIMAP directory within the ClientAccess folder – for example:

D:\Program Files\Microsoft\Exchange Server\ClientAccess\PopImap

For the protocol you wish to enable (or check it’s configuration settings) open the relevant file in Notepad, either:

  • Microsoft.Exchange.Imap4.exe.CONFIG
  • Microsoft.Exchange.Pop3.exe.CONFIG

Scroll down to the bottom of either file, and then look for the <appSettings> section. To enable protocol logging, change the ProtocolLog value to true, for example:

<add key=”ProtocolLog” value=”true” />

Also, make a note of the LogPath value, as we’ll need this later when we analyse the log files generated. By default these will be under the Exchange install directory within Logging\Imap4 and Logging\Pop3.

After giving clients a chance to log on, we’ll then execute the following three commands in the Exchange Management Shell to create a simple CSV file containing client information. First, we’ll create a new file with headers:

“`”Alias`”,`”Protocol`”” | Out-File .\IMAPPOPLog.csv

Then, we’ll export the information using a similar command for both POP and IMAP.

The commands below:

  • Get the directory contents to list all log files
  • Look in each log file for a line containing “legacyID”.
  • When it matches “legacyID” it splits the line up to find what is usually the user’s alias and creates a line to output.
  • Before appending to the file created above, the lines to output are checked to ensure they are unique.

First collect POP3 information if required, using the default location for POP3 logs:

Get-ChildItem $ExInstall\Logging\Pop3 `
|%{ $_ | Get-Content | Where {$_-like “*legacyId*”} `
|%{ “`”$(($_.Split(“=”))[-1]),`”POP3`”” } } `
| Sort -Unique | Out-File .\IMAPPOPLog.csv -Append

And finally we’ll collect IMAP information – again using the default location for IMAP4 logs:

Get-ChildItem $ExInstall\Logging\Imap4 `
|%{ $_ | Get-Content | Where {$_-like “*legacyId*”} `
|%{ “`”$(($_.Split(“=”))[-1]),`”IMAP4`”” } } `
| Sort -Unique | Out-File .\IMAPPOPLog.csv -Append

The output from the multi-line command should be minimal, as shown below:

Image
Figure 6:
Collecting IMAP and POP3 login information

The output, in CSV format in the file IMAPPOPLog.csv should however be more descriptive containing information about IMAP and POP3 clients, as shown below:

Alias Protocol
Barb.Gravert POP3
Lashell.Zuber POP3
Ariel.Pagliari IMAP4
Roxy.Donaghue IMAP4
Theron.Gomzalez IMAP4

Table 1

We’ll record that data alongside other information, but we don’t need to perform deeper analysis into each IMAP and POP3 client as they should be unaffected during the transition.

Blackberry Enterprise Server

We need to collect two key pieces of information about the Blackberry Enterprise Server – firstly the number of enabled users to feed into the sizing. Secondly we need to check the version of BES that is currently in use so we can ascertain if it requires an upgrade.

To export a list of users currently enabled for BES, login to the Blackberry Administration Service, found in the Start Menu of the BES server itself or at a URL in the following format:

https://bes/webconsole/login

After login as a BES Admin user, choose Manage Users:

Image
Figure 7:
Preparing to export users from BES

Then choose Select all results in the entire set:

Image
Figure 8:
Selecting all users to export

After selecting all results, choose Export all results to download the user list as a CSV file:

Image
Figure 9:
Exporting results as CSV

From the CSV export, we’ll be able to determine not just the number of enabled users on the BES server, but the number that are actually connected to devices by opening the report in Excel:

Image
Figure 10:
Viewing BES User information in Excel

We see in the example above that only a small number of users are BES activated out of the 73 total enabled.

To check the version of Blackberry Enterprise Server installed, open the Control Panel on the Server BES is installed on and navigate to Programs>Program and Features:

Image
Figure 11:
Verification of BES component versions

We are particular interested in the following information:

  • The version of Blackberry Enterprise Server
  • The version of the Messaging API and Collaboration Data Objects
  • Verification that SQL Express is in use rather than MSDE

Under the version heading, check the version against the requirements for Exchange 2013 on the Blackberry Support Website. At the time of writing the requirements include:

  • A minimum of Blackberry Enterprise Server 5.0.4 MR2 (Bundle 70)
  • Messaging API and CDO 1.2.1 version 6.5.8309.0

In our example organization we do not meet the minimum requirements, therefore we know as well as updating Exchange settings for BES we will also need to upgrade BES and the MAPI CDO.

Forefront Threat Management Gateway

With our client discovery completed, we’ll take a brief look at the Forefront TMG 2010 configuration to ensure we understand which services are currently published to external users. We’ll do this by navigating to the TMG Management Console, and selecting Firewall Policy:

Image
Figure 12:
Viewing Forefront TMG Rules for Exchange

For each rule, record the following information. We’ll use this later to determine the changes we need to make when configuring rules for coexistence with Exchange 2013, for example for the first rule we’ll choose the Properties for each rule and record:

Rule Exchange 2007 OA, EWS, OAB and AutoD
Action Allow
From Anywhere
To mail.exchangelabs.co.uk / 192.168.15.3
Public Names autodiscover.exchangelabs.co.uk, mail.exchangelabs.co.uk
Paths /unifiedmessaging/*, /rpc/*, /oab/*, /ews/*, /AutoDiscover/*
Users All Authenticated Users
Authentication Delegation NTLM Authentication
Listener ExchangeListener

Table 2

Repeat this process for each Exchange rule. Next, examine the Listener configuration and after choosing Properties for each relevant listener record details including:

Listener ExchangeListener
Networks External
Connections SSL connections on port 443
Certificate Used Subject: mail.exchangelabs.co.uk

Issuer: Digicert

Expiry Date: 16/05/2014

Subject Alternative Names: mail.exchangelabs.co.uk,   autodiscover.exchangelabs.co.uk, e12m01.exchangelabs.co.uk

Authentication Method HTML Form Authentication; Validated against Windows (Active   Directory)
SSO Enabled Domains Single Sign On enabled for *.exchangelabs.co.uk

Table 3

Mail Gateways

Finally we will collect information about our MailEssentials gateway. The product we’re using interfaces with SMTP using the IIS SMTP Service, therefore we can use the IIS Management Console to examine accepted domains and relay settings. The location of the settings for the product you use may vary, however the information that must be collected is approximately the same.

After login to our Mail Gateway server, we’ll open the Internet Information Services (IIS) 6.0 Manager and navigate to Local Computer>[SMTP Virtual Server #1] and right click the node and choose Properties. We’ll then select the Access tab and choose Relay:

Image
Figure 13:
Viewing clients allowed to relay

Within the Relay Restrictions window, you can view which hosts are allowed to relay:

Image
Figure 14:
Collecting relay information

Make a record of these hosts, and cross reference the list with the list of source servers on the related Send Connector within Exchange:

Relay Host Related Send Connector(s) Source Server on Send   Connector(s)
192.168.15.3 (e12m01.exchangelabs.co.uk) Outbound via MailEssentials Yes

Table 4

We’ll also use this change to validate the maximum size limits specified, by navigating back to the [SMTP Virtual Server #1] Properties window and choosing the Messages tab.

Record the value listed in Limit message size to (KB) and ensure that it matches the maximum sizes specified in the Send and Receive connector configuration gathered in the previous part in this series.

Image
Figure 15:
Verification of message size limits

Finally we will record information relevant to inbound mail from the Internet. Navigate to navigate to Local Computer>[SMTP Virtual Server #1]>Domains and record the Remote domains listed:

Image
Figure 16:
Verification of Accepted Domains

If additional Remote domains that are not an accepted domain within Exchange are listed, these should be investigated separately, but for each accepted domain choose Properties and record the settings within the General tab in the Route Domain section:

Domain Route
exchangelabs.co.uk Forward mail to smart host e12m01.exchangelabs.co.uk

Table 5

Summary

In this part of the series, we’ve completed the final steps required to perform an analysis of the current Exchange environment along with associated clients and third-party software. In the next part of this series we’ll begin planning for deployment.

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

About The Author

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