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.

3 comments:

  1. If the Exchange 2007 servers are separate, for example: Client Access Server is 10.0.0.7 and Mailbox server is 10.0.0.12, which ip address is used for the legacy DNS A record? Autodiscover DNS A record points to 10.0.0.7 and mail DNS A record points to 10.0.0.12. Should the legacy DNS A record point to the Client Access Server?

    ReplyDelete
  2. Yes, the client access server.

    Why would you have the mail record point to the mailbox server? For example, mail.contoso.com.

    All those records would point to a CAS. Initially the 2007 CAS and then the 2013 CAS with the legacy then pointing to the 2007 CAS.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete