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 3)
- 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)
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:
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:
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.
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:
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:
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:
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:
Figure 7: Preparing to export users from BES
Then choose Select all results in the entire set:
Figure 8: Selecting all users to export
After selecting all results, choose Export all results to download the user list as a CSV file:
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:
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:
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:
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:
Figure 13: Viewing clients allowed to relay
Within the Relay Restrictions window, you can view which hosts are allowed to relay:
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.
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:
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:
- 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 3)
- 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)