Saturday, April 26, 2014

Exchange 2013 (SP1) - Migration - Part 3 - More preparation...

There are a number of other steps to take before we install Exchange 2013:

  • Enable Outlook Anywhere on the Exchange 2007 server (if it is not already enabled - it may be).
  • Assign all mailbox databases an Offline Address Book (once again, if this is not already the case).
  • Disable IPv6 on the Exchange 2007 server (if the Exchange 2013 server will host both the Client Access and Mailbox roles).
  • Create a legacy Exchange host name in DNS.
  • Prepare storage. In my test environment, there is not much to do here. In a production environment, especially a large one, this could require much planning.
  • Ensure that our client software (Outlook for example) is compatible with Exchange 2013.


Note:  I refer to the Exchange Server Deployment Assistant in the lines that follow (and may have in previous posts for that matter). This is a tool that helps the administrator plan migrations from one version of Exchange to another, or to Office 365 (Exchange Online).

It can be found here:

Exchange Server Deployment Assistant



Enable Outlook Anywhere (and adjust authentication methods)

With Exchange 2007 (and 2010), Outlook clients use "MAPI over RPC" to connect to the mail server internally (on the LAN).

If they connect remotely, over the Internet, for example, they would use Outlook Anywhere, which uses "RPC over HTTP".

In Exchange 2013, this all changes.

RPC over HTTP is now the only access method for Outlook clients. Or Outlook legacy clients... In fact, Outlook 2013 can use a newer method called "MAPI over HTTP"

We could say, then,  that now all Outlook (legacy) clients connect to Exchange with Outlook Anywhere.

So Outlook Anywhere must be enabled on the Exchange 2013 server but also the Exchange 2007 server. During the transition, clients will first connect to the Exchange 2013 server that will redirect those with a mailbox still on the Exchange 2007 server to this server.

Since Exchange 2013 uses RPC/HTTP, the redirected connection also uses this method and we need to enable Outlook Anywhere on the Exchange 2007 server.

In my case, Outlook Anywhere is already enabled.



But there's one more step here. In my case, Basic authentication is selected. This is fine but the redirected connections (from the Exchange 2013 server to the 2007 server) require Windows Authentication. We have to enable this in IIS Manager (Sites, Default Website, RPC) as shown below:



At the command line, I have to type...

iisreset /noforce

for the new setting to take effect.

Note: this is not the same as changing Basic authentication to NTLM authentication in the GUI. Even after enabling Windows authentication in IIS, Basic authentication should remain selected in the server's Outlook Anywhere properties.

Reference:

Exchange Server 2013 Transitions from RPC to HTTP

MAPI over HTTP (article by Tony Remond)



Offline Address Book

Before we install Exchange 2013, we should ensure that all existing mailboxes are assigned a default Offline Address Book (OAB). If not, they will download the OAB generated by Exchange 2013. 

According to the Exchange Server Deployment Assistant, this may cause significant network traffic if there are many mailboxes. In my test environment, this would not be an issue but I will verify all the same.

First, an OAB has been desginated for the (sole) mailbox database:



Note: mailboxes created in the mailbox database inherit this setting.

If this were not the case, we could set the OAB like this (for example):

Set-MailboxDatabase "EX1\MBXDB1" -OfflineAddressBook "Default Offline Address Book"



IPv6

We need to disable IPv6 on the Exchange 2007 server (not the future Exchange 2013 server).

According to the Exchange Server Deployment Assistant, some connections between the 2007 and 2013 server will not work correctly if...

1) the Exchange 2007 server holds both the Mailbox and Client Access roles.
2) the Exchange 2007 server has IPv6 enabled.

How do we disable IPv6?

One might think that we would go the the TCP/IP settings of the Exchange 2007 server network interface and uncheck IPv6.

In fact, this is not the method recommended by the Exchange Server Deployment Assistant.

Instead, we would open the registry editor (regedit) and navigate to this location:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters

We create a new DWORD (32 bit) value named "DisabledComponents" (if it does not already exist) and enter the following value:

0xFFFFFFFF

Here is an illustration:



We click OK and reboot the server.

To my surprise, IPv6 was still checked in the TCP/IP settings of the Exchange 2007 network interface. It appears that there are several methods to "disable IPv6" and depending on the method, IPv6 is disabled to a greater or lesser extent.

Entering 0xFFFFFFFF disables "all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6."

Other values would disable other components, as outlined in this article:

How to disable IPv6 or its components in Windows

Apparently, and according to the Exchange Server Deployment Assistant, we do not need to disable IPv6 entirely (the loopback interface can remain enabled).

Reference:

Outlook Anywhere does not work if IPv6 is enabled on an Exchange Server 2007 multi-role server



Legacy Exchange name (DNS)

If the migration from Exchange 2007 to Exchange 2013 happens immediately, and all mailboxes are moved at the same time, this operation is not necessary. On the other hand, if we are in a situation of "coexistence" where users access mailboxes on both the Exchange 2007 and Exchange 2013 server (depending on the location of the mailbox), there must be a way to distingush the two servers in DNS.

The example used by Microsoft in the Exchange Server Deployment Assistant is contoso.com

So, for example, the DNS record for the Client Access server is mail.contoso.com and points to 10.0.0.7

Note: we'll pretend that the IP of the Exchange 2007 server is 10.0.0.7 and 10.0.0.13 for the future Exchange 2013 server.

When we introduce the Exchange 2013 server, we will need to point mail.contoso.com to 10.0.0.13

But how will we locate the Exchange 2007 server now (from the client access perspective)?

We will create a so-called "legacy" record in DNS, that points to the Exchange 2007 IP address, like this:

legacy.contoso.com 10.0.0.7

This allows clients whose mailbox is still on the Exchange 2007 server to be redirected to that server.

In my case, the "autodiscover" and "mail" DNS A records both point to 10.0.0.20.

So I create a "legacy" A record that points to 10.0.0.20

Here is an illustration:



When I am ready to move mailboxes to the Exchange 2013 server, I can change the A records for autodiscover and mail so they point to 10.0.0.23 (the IP address that I intend to assign to the Exchange 2013 server).

Exchange will then use the "legacy" record, still pointing to 10.0.0.20, to designate the Exchange 2007 server.



Storage

The traditional recommendation is to place the server operating system, the log files and the database(s) on separate volumes (and even the Exchange program files).

In some cases, if we use local storage, that would mean placing the operating system on the C: drive (most likely), the log files on the E: drive (if the D: drive is the CD/DVD drive) and the database on the F: drive (and the Exchange binaries on yet another drive if we go to that extent).

In other cases, the log and database files might be stored on various volumes of a SAN (Storage Area Network).

Since IOPS (input/out per second) has improved with Exchange 2010 (apparently by 70% compared to Exchange 2007) and even more with Exchange 2013, some sources state that it may be acceptable (depending on the environment) to place log and database files on the same volume.

For my lab environment, I will simply create separate folders on the C: drive for the log and database files:

- C: (operating system and Exchange program files)
- C:\EXLOG1
- C:\EXDB1

Some comments...

The concept of "storage group" no longer exists in Exchange 2010 or Exchange 2013. Each database has its own set of log files. This is why I created an "EXLOG1" folder and an "EXDB1" folder.

If we use DAGs, we should remember that the path for the different copies of a database must be identical on the different servers housing a copy of that database. So if the path is D:\Database1 on Server 1, we have to use the same path on Server 2. If Server 2 has a CD\DVD drive with drive letter D:, that would need to be changed.

In production, we would, once again, want to organize the storage like this:

- C: (operating system and Exchange program files)
- E:\EXLOG1
- F:\EXDB1

Note: this only makes sense if the different volumes are on different physical disks or, for redundancy, different RAID arrays. Nothing would be gained, for performance (or redundancy) if we simply create different volumes on "Disk 0".

If I am placing all these elements on the same physical disk here, that is merely a concession that I've made to simplify matters in my lab environment.


Clients

We should ensure that Outlook clients are compatible with Exchange 2013.

  • Outlook 2003 is not compatible.
  • Outlook 2007 is compatible with SP3 (and updates as of November 2012 or later)
  • Outlook 2010 is compatible with SP1 (and updates as of November 2012 or later)
  • Outlook 2013 is compatible.


Note: the version of Outlook used by my clients is Outlook 2010 SP2.

As for web browsers, Internet Explorer 9 is the oldest version that provides what is rated a "best" experience with Exchange 2013. For other browsers, and the level of experience, consult this article:

 What's New for Outlook Web App in Exchange 2013


***

In my next blog post, and after several posts about "preparation", I will - finally - install Exchange 2013.

Saturday, April 19, 2014

Exchange 2013 (SP1) - Migration - Part 2 - Preparing the environment (prerequisites)

I've already presented the prerequsites for an Exchange 2013 (SP1) installation in a previous post:


That was for a fresh install.

In the case of a migration (from Exchange 2007, for example), most of the steps are identical to what was presented in that post. Here are some additional notes for the installation of Exchange 2013 in an existing environment.



Prepare Active Directory

We still need to prepare Active Directory with the following commands:

PS C:\E2K13-SP1> .\setup /ps /IAcceptExchangeServerLicenseTerms

PS C:\E2K13-SP1> .\setup /p /IAcceptExchangeServerLicenseTerms


Now, I've just copied and pasted those commands without the slightest explanation!

Let's clarify some matters for those who might be doing this for the first time.

I performed a search for "Exchange 2013 SP1" and downloaded the (large) file in question. From this single file, I extracted the many installation files into the "E2K13-SP1" folder on my C: drive.

That's right: we need to download and extract the installation files for those commands to function.

Among the installation files, there is a setup.com file that can be used to install Exchange, from start to finish, or simply prepare Active Directory as a preliminary step. In this last case, the complete installation happens later.

That is the method I prefer: I prepare the environment step-by-step and can thus isolate any problems at a particular step.

If you have read the blog post referenced above, you will have seen that we have to type a period and then a backslash before the command itself:

.\

That is how Powershell functions when we execute a script or a setup file. If we omit the .\ combination, an error message will display.

The unabbreviated commands are:

setup /PrepareSchema

and

setup /PrepareAD

So why do I enter...

setup /ps

and

setup /p

???

These are simply the abbreviated forms of the command. Either set of commands will work.

These commands can be executed on the Exchange server itself provided that the domain controllers are accessible, the schema master FSMO role in particular. The user running the commands must be a member of the schema, enterprise and domain administrator groups.

As for the /IAcceptExchangeServerLicenseTerms parameter, this is new to Exchange 2013 and indicates that you accept the Exchange 2013 license terms.

So these commands should suffice but there could be particular circumstances in which we would want to designate a particular domain controller, for example. This Technet article explains some of these options as well as additional details on the points I have mentioned:

Prepare Active Directory and Domains (for Exchange 2013)

The article also outline the changes that the commands make, essentially extending the Active Directory schema with attributes necessary for Exchange 2013 and (if they do not already exist) creating various containers and groups in Active Directory.

The article also explains how the administrator can determine if the operations were successful. In my case, most of the groups already existed. As for the schema level, we can make a before-and-after comparison to verify the upgrade with the "ADSI Edit" tool (available in "Administration Tools" on a domain controller - or the Exchange server itself if RSAT for Active Directory is installed).

We open ADSI Edit, select the configuration naming context, and navigate to the location shown here:



The attribute to consider is "objectVersion". Before the schema upgrade, the number is 11222 which corresponds to Exchange 2007 SP3. After "setup /ps", we are at 15844 which corresponds to Exchange 2013 SP1:



At this point, then, Active Directory is prepared for Exchange 2013.



Install required Windows Features

Exchange 2013 requires a number of Windows Features. As the reader may already know, there are only two Exchange 2013 roles: Client Access and Mailbox. If we are only installing the Client Access or Mailbox role, we may not need all the roles below on a given server. Since I am going to install both the Mailbox and Client Access Server role on the same server, I will install all of the following features with the Add-WindowsFeature cmdlet:


Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI


Note: unless you like to type, the best method to install these features is to copy and paste the text above into Powershell.



Install required software (other)

As mentioned in the blog post referenced above, there is almost nothing to install if we use Windows 2012 as the operating system on the (future) Exchange server. If that is the case, only the Unified Communications Managed API needs to be installed.

If we use Windows 2008 R2, we need to install all the software indicated below.

If we run the setup commands for Active Directory on the Exchange server, we will have to install the RSAT, .NET Framework and WMF 4.0 components before that step.


  • .NET Framework 4.5
  • Windows Management Framework (WMF) 4.0 - includes Powershell version 4
  • Remote Server Administration Tools for Active Directory Domain Services (RSAT-ADDS)
  • Microsoft Unified Communications Managed API (UCMA) 4.0, Core Runtime 64-bit
  • Microsoft Knowledge Base article KB974405 (Windows Identity Foundation)
  • Knowledge Base article KB2619234 (Enable the Association Cookie/GUID that is used by RPC over HTTP to also be used at the RPC layer in Windows 7 and in Windows Server 2008 R2)
  • Knowledge Base article KB2533623 (Insecure library loading could allow remote code execution)


With one exception (assuming once again that we are using Windows 2008 R2), we need to download the items listed above and then execute the files in question to complete the installation. As for RSAT-ADDS, we can run the following command:

Add-WindowsFeature RSAT-ADDS

***

It is not absolutely necessary to follow the order presented above. We could, for example, install the other required software before the Windows Features. In fact, I tried this once and although everything functioned correctly at the end, there was at least one error message because one of the software items (the Unified Communications Managed API) required the Desktop Experience feature:


If we install the Windows Features first, there should be no error messages.

Based on my experience, I would add the future Exchange server to the domain before attempting the operations indicated above - and make sure that you are connected as a domain (and enterprise / schema) administrator, rather than the local server administrator. Occasionally, I'll see a conversation in the Technet forums where this was the source of some apparently inexplicable problem.

Once we have completed all the steps above, we should be ready to install Exchange 2013.

Almost ready... please read the next post of this series.