Monday, March 31, 2014

Exchange 2013 (SP1) - Migration - Part 1 - Documenting the existing environment

INTRODUCTION


In this blog post, first of a series about migrating to Exchange 2013 (from 2007 in this case), I'll take a look at documenting the existing environment and also verifying the absence of any issue likely to complicate migration.

This will be a simple migration from a single Exchange 2007 (SP3) server to a single Exchange 2013 (SP1) server. This implies that both Exchange 2013 roles (Mailbox and Client Access) will be on the same single server.

First, we need to document the existing environment so we can configure the new Exchange 2013 server like the Exchange 2007 server (when appropriate). Some settings, those at the Organization level (in the Exchange Management Console, for example) should transfer automatically. On the other hand, at least some settings at the Server level will have to be configured manually (or with a script). These would include URLs, URIs and authentication methods of various services such as OWA, OAB, and ActiveSync.

Please note that I will concentrate on elements used in my test environment. For example, I use Outlook and OWA but not POP or IMAP. I happen to have a Cisco ASA firewall and no longer use ISA or TMG (products that Microsoft is abandonning for that matter).  My objective is not to present every conceivable scenario but to share knowledge acquired in certain areas.

For the areas not covered here, I would direct the reader to official Microsoft documentation or the multitude of other literature available on the Internet.

Second, it is also a good idea to confirm that the existing environment is healthy. If the existing environment is not functional, it is unlikely that adding another element of complexity (migration to Exchange 2013)  will make the system more efficient.

These are the tools that I will use:


  • Exchange Server Deployment Assistant
  • Exchange Best Practices Analyzer
  • Exchange Remote Connectivity Analyzer
  • Exchange Server Profile Analyzer
  • Powershell Get-* cmdlets (for information on the virtual directories)
  • Powershell Test-* cmdlets (Test-ServiceHealth, Test-OWAConnectivity, etc.)


There are a number of other tools that could be used as well but that I will only mention. Some require the creation of a entire test environment that would exceed, by far, the scope of this project and series of blog posts.

We can use Performance Monitor data to measure the requirements for the new server in this area. This data, as well as data from other sources (like the Exchange Profile Analyzer) can be entered into what is now called the Exchange (2013) Server Role Requirements Calculator.


The resulting data from the Calculator can be used with the JetStress and LoadGen tools to simulate the load on the Exchange server.


Warning ! JetStress and LoadGen should be used in a lab setting (that replicates the production environment) and not in the production environment itself. Please read the documentation if you intend to use these tools.


***


Exchange Server Deployment Assistant

This is a web-based tool that, based on the information provided by the user, provides a deployment plan. here is the presentation of the tool on the website itself:

"The Exchange Server Deployment Assistant is the IT pro’s source for Exchange deployment technical guidance. Tell us what kind of deployment you’re interested in, answer a few questions about your environment, and then view Exchange deployment instructions created just for you."

Microsoft Exchange Server Deployment Assistant

In our case, we are interested it an on-site migration from Exchange 2007 to Exchange 2013. Even in these circumstances, there are a multitude of deployment options depending on our particular environment or the features we intend to use. I'll only illustrate (and briefly) some of the primary steps:

So, I select the "On-Premises" option:



I select the Exchange 2013 option (the other option being Exchange 2010):



We will upgrade from Exchange 2007 (only):



There are a number of additional questions:

Do we intend to install the Mailbox and Client Access roles on the same server?

In my case, yes.

Are we running "disjoint namespaces"?

In my case, no.

Do we have an existing Edge Transport server?

In my case, no.

In other scenarios, different questions may be asked and the recommendations will be different.

In any case, the Assistant will produce a checklist that can be used to guide the deployment of Exchange 2013 (in this case).



Exchange Best Practices Analyzer

The ExBPA (Exchange Best Practices Analyzer) compares the configuration of the Exchange server to Microsoft's "best practices", or recommendations for (in this case) an Exchange server.

Note: it is not feasible to examine every component of each of these tools in detail. One could probably dedicate a blog post to each of them and even then, not cover everything. So I'll make some assumptions: the reader

- can find where these tools are located or...
- can find information online explaining the use of these tools in greater detail.

In other words, I will not necessarily provide step by step instructions .

In the EMC, Toolbox section, open the ExBPA:



You may search updates if you want. If you use the ExBPA often, it is probably not necessary to check every single time the tool is opened. Otherwise, go to the "Welcome Screen" and then "Select options for a new scan". Connect to Active Directory (indicate a domain controller, if one is already selected, that should be fine) and select a "New Best Practices" scan. There are several possible scans. I'll select the "Health Check" and click on "Start Scanning" (not shown on screenshot):



When the scan finishes, click on "View a report of this Best Practice scan":



I have two issues to examine. I can obtain more information by clicking on the item:



Of course, results will vary depending on each environment and the possible issues that may exist. The administrator in charge will have to act consequently.



Exchange Remote Connectivity Analzyer

This is another web-based tool. The URL is:

https://testconnectivity.microsoft.com/

But a websearch for "Exchange Remote Connectivity Analzyer" will lead the reade rto the same location.

There is a prerequisite: a mailbox must be used for the test. It is recommended that a mailbox be created for the test and then disabled for security reasons.

Once again, I will not detail every possible test and all possible options. Not all are useful for all environments. As an example, I'll select the Outlook Autodiscover test:



I enter the credentials for the test mailbox:



The results of the test are displayed after a minute or so:


Details can be displayed by clicking on the errors.




Exchange Server Profile Analyzer

This tool must be downloaded and installed. The install process is short and simple. We execute the downloaded EPA.msi file and click "Next" or "Finish" as needed.


After installation, we can find the EPA in the Start Menu:




We open it, connect to Active Directory (a couple clicks here) and then select scan options:




We have a number of options (Save Configuration, Start Collect - not shown in screenshot). I'll simply start the collect of data. When the collect finishes, we have this screen:




At the end of the scan, we can view the results, saved to an HTML file:



Note: I encountered several problems with the EPA. These points should be retained:

  • A custom account must be created for the EPA. It should be a member of the Exchange View-Only Administrators group. It also needs Full Access permissions to all the mailboxes. While it was possible to grant this permission to the few mailboxes in my test environment manually, a combination of the Get-Mailbox and Add-MailboxPermission Powershell cmdlets would make more sense if the reader is managing hundreds (or thousands) of mailboxes.
  • I could not expand the headings in the results (by clicking on the + sign) on the Exchange server itself, perhaps because of settings particular to the browser (the file to open is an HTML file). I was able to open it on a Windows 7 machine however.



Powershell Get-* cmdlets

These cmdlets provide output for the documentation of the existing Exchange environment, including some parameters that will be configured on the new Exchange 2013 server.

There are a number of options here. We can concentrate on the urls and the authentication methods as follows. This is achieved by the format-list cmdlet (after the pipeline) and indicating the parameters we wish to display. I use the * before and after "url" for the internal and exernal values and then *auth* for any authentication information. In some cases, we need to indicate something else, *uri* or *host*.

I'll post the cmdlets here, but with the output for the first cmdlet only:

[PS] C:\>Get-AutoDiscoverVirtualDirectory | fl *url*,*auth*

InternalUrl                   : https://autodiscover.mitserv.net/autodiscover/autodiscover.xml
ExternalUrl                   : https://autodiscover.mitserv.net/autodiscover/autodiscover.xml
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True

[PS] C:\>Get-OwaVirtualDirectory "owa (default web site)" | fl *url*

[PS] C:\>Get-OabVirtualDirectory | fl *url*

[PS] C:\>Get-ActiveSyncVirtualDirectory | fl *url*

[PS] C:\>Get-WebServicesVirtualDirectory | fl *url*

[PS] C:\>Get-ClientAccessServer | fl *uri*

[PS] C:\>Get-OutlookAnywhere | fl *hostname*

We can also export the complete output to a text file, like this:

Get-ActiveSyncVirtualDirectory | fl | out-file C:\Scripts\EAS_vDir.txt

If we want only the urls and authentication methods, we can do this:

Get-AutoDiscoverVirtualDirectory | fl *url*,*auth* | out-file C:\Scripts\EAS_vDir.txt

We can use this information to configure the 2013 server with the corresponding Set-* cmdlets. We'll see that once the Exchange 2013 server is ready for configuration.



Powershell Test-* cmdlets

If mail can be sent and received, both to/from internal and external users, if users can use Outlook, OWA, ActiveSync, to communicate, one could conclude that the messaging system is functioning as it should. Otherwise, we can use a number of cmdlets to confirm this. I will not publish the output here (sometimes verbose and dependent on the environment) but the cmdlets themselves:


  • Test-ServiceHealth
  • Test-SystemHealth (essentially the command line equivalent of the ExBPA)
  • Test-MAPIConnectivity
  • Test-OWAConnectivity
  • Test-OutlookWebServices
  • Test-WebServicesConnectivity


The list is not complete. There are, for example, cmdlets for the Edge Transport synchronization, for POP and IMAP connectivity, or for Unified Messaging connectivity, which are all features that I do not use.

Get-Command Test-* will show the cmdlets available on the Exchange 2007 server.

You can select - and run - those that apply to your environment.


No comments:

Post a Comment