- 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 2015 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 2015.
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 2015, this all changes.
RPC over HTTP is now the only access method for Outlook clients. Or Outlook legacy clients... In fact, Outlook 2015 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 2015 server but also the Exchange 2007 server. During the transition, clients will first connect to the Exchange 2015 server that will redirect those with a mailbox still on the Exchange 2007 server to this server.
Since Exchange 2015 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 2015 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 2015 Transitions from RPC to HTTP
MAPI over HTTP (article by Tony Remond)
Offline Address Book
Before we install Exchange 2015, 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 2015.
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 2015 server).
According to the Exchange Server Deployment Assistant, some connections between the 2007 and 2015 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 2015 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 2015 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 2015 server.
When we introduce the Exchange 2015 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 2015 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 2015 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 2015, 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 2015. 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 2015.
- 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 2015 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 2015. For other browsers, and the level of experience, consult this article:
What's New for Outlook Web App in Exchange 2015
***
In my next blog post, and after several posts about "preparation", I will - finally - install Exchange 2015.
Thank you for reading the article about Exchange 2015 (SP1) - Migration - Part 3 - More preparation... on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.