Tuesday, September 2, 2014

Exchange 2010 (SP3) - Migration - Part 8 - Legacy CAS URLs

If Exchange 2007 and Exchange 2010 are to coexist for some time (more than a week, for example), or in other words, if some mailboxes will remain on the E2K7 server while others will migrate to the E2K10 server, it will be necessary to reconfigure the CAS virtual directory URLs on the Exchange 2007 server and also create and adjust some records in DNS.

Please note that this pertains to web-based client access methods such as OWA and ActiveSync. These are generally HTTPS connections on port 443. Outlook uses RPC\MAPI on port 135 and is not affected by these parameters for sending and receiving messages. However, the EWS (Exchange Web Services) URLs could have an effect on calendar (availability) and "Out of Office" functionality. 


Create a record for "legacy" in the appropriate DNS zone

If the domain name used for client access is, for example, "mitserv.net", we would create a DNS "A" record in that zone for the host "legacy". So we will have something like this... at first:


As we can see, all three records, autodiscover, mail, and legacy designate the Exchange 2007 server with IP address 10.0.0.20.

Note: the "mail" and "autodiscover" records would have already been configured for Exchange 2007 when it was first installed.

Just before we start migrating mailboxes to Exchange 2010, we will have to adjust the "autodiscover" and "mail" records so they point to the Exchange 2010 server... or possibly a load balancer if there are multiple E2K10 servers.

Why?

Because, if all is configured correctly, Exchange 2010 can both accept client requests for connections to mailboxes migrated to Exchange 2010 and also redirect requests for mailboxes still on Exchange 2007 to the "legacy" server (yes, the E2K7 server).

The opposite is not true.

If the DNS record continued to point to the E2K7 server, users could not connect to mailboxes migrated to E2K10 because E2K7 has no mechanism to redirect users to newer versions of Exchange like 2010 and 2013.


Adjust DNS records for "autodiscover" and "mail"

This step is very short. We simply change the DNS records in question so they point to the Exchange 2010 server or the load balancer.

In my network, the modified records would look like this:


The "autodiscover" and "mail" records now point to 10.0.0.23 which is one of the Exchange 2010 servers.

However, since there are two servers, and we want to provide highly available client access services, we would do better to point the records in question at the load balancer, like this:

autodiscover - 10.0.0.28
mail - 10.0.0.28

Note: where 10.0.0.28 is the virtual IP address of the load balancer (in my test network).

Of course, the load balancer would have to be properly configured as well, which is a subject for another blog post. In essence, however, it would have to designate, as the "real servers", the respective IP addresses of EX13-1 and EX13-2 which (despite the number 13) are my Exchange 2010 servers.



Change the URLs on the Exchange 2007 server virtual directories

In fact, it is apparently only necessary to modify the -ExternalUrl value. The -InternalUrl, which by default includes the server FQDN, can remain as is.

Some of the URLs can be changed in the EMC but all can be changed with PowerShell cmdlets in the EMS so that's the tool I will use.

Moreover, there are a number of possible methods to change the URL. We can use a Get-* cmdlet and pipe the result to a Set-* cmdlet or simply use the Set-* cmdlet from the start. That assumes we know the name of the virtual directory, so it can be useful to use a Get-* cmdlet to do this. We can also use the * so we do not have to type the entire virtual directory name. I was able to make the necessary adjustments with these cmdlets only:

Set-OwaVirtualDirectory -id ex1\owa* -ExternalUrl https://legacy.mitserv.net/owa

Set-OabVirtualDirectory -id ex1\oab* -ExternalUrl http://legacy.mitserv.net/OAB

Set-WebServicesVirtualDirectory -id ex1\ews* -ExternalUrl https://legacy.mitserv.net/ews/exchange.asmx

Set-ActiveSyncVirtualDirectory -id ex1\microsoft* -ExternalUrl https://legacy.mitserv.net/Microsoft-Server-ActiveSync

There is no ECP in Exchange 2007 and I do not use Unified Messaging (UM). Autodiscover does not use either the InternalUrl or the ExternalUrl (even though these properties exist) so there is no need to adjust any values there.

Essentially, it is a matter of replacing "mail" with "legacy" (as shown above).


Some notes on the user experience

If the URLs are not changed and a user attempts to access a mailbox already migrated to E2K10, they may see something like this:



If we make the proper changes, the user should first see the "new" Exchange 2010 logon screen...



But once redirected (and logged in), will see the familiar Exchange 2007 colors:



Note the word "legacy" in the Exchange 2007 URL.

Of course, users migrated to Exchange 2010, will see the new interface after logon as well:





Conclusion 

This concludes my series of blog posts on an Exchange 2007 to 2010 migration. As stated in my introduction (please see the first post of the series), it was meant to examine some of the more common aspects of such a migration without any intention of covering them all. I have given the priority to the aspects I am most likely to encounter in a certain production environment. Other aspects, such as Public Folders, Edge Servers or even Outlook Anywhere have not been adressed. Lastly, there is one more important step that I have chosen to postpone (for now) which is the removal of the Exchange 2007 server (essentially because I still need it for testing).

I would add, however, on this subject, that it is important to remove Exchange 2007 properly, which means that we un-install it with "Add/Remove Programs" or "Programs" rather than simply disconnecting the E2K7 server from the network and reformatting the volumes.

In general, I would refer the reader interested in the other aspects of migrating from Exchange 2007 to 2010 (or 2013) to other sources online (or traditional sources).

References:



As for printed sources, the "Exchange Server 2010 - Best Practices" by Siegfried Jagott, Joel Stidley and the Microsoft Server Team (Microsoft Press, 2010) includes a chapiter about migrations to Exchange 2010.

No comments:

Post a Comment