When doing a migration from Exchange 2007 to Exchange 2010, one of the biggest item’s you need to watch out for is the migration of the ActiveSync environment, and be aware of how it can affect your end users. You should also be aware of potential issues depending on the TYPE of active sync device you are using, as some will work, and other’s will have issues.
First we’ll start with the migration. Our current Exchange 2007 ActiveSync environment is as follows:
Here, we have one internet facing site, the NY site. There is a DNS record for the CAS server in NY, activesync.company.com that points to the IP of the CAS server on the internet. We have set the –externalurl to activesync.company.com and the –internalurl to newyork2007.company.local. Note that newyork2007 is the NETBIOS name of the CAS server in NY. We set both of these values with the following command:
Set-ActiveSyncVirtualDirectory –Identity “newyork2007\Microsoft-Server-ActiveSync” –InternalURL newyork2007.company.local –ExternalURL activesync.company.local
In London, we have set the InternalURL attribute to the local name of the server, but leave the ExternalURL attribute blank. We do not populate the ExternalURL attribute because London is not accessible directly from the internet.
Setting the –internalurl attribute updates the SCP in active directory, so that any system that query’s AD itself, will be able to return the internal URL the user should access. For instance, in our above scenario, LON07 the user configures his active sync device from the internet. He put’s in activesync.company.com as the server address, which is the external DNS name of the NY CAS server. The NY CAS server, as part of the Active Sync process, query’s Active Directory for the home mailbox of LON07, and then determines which site LON07 is in. Since LON07 is not in the same site as the NY CAS, the NY CAS then returns the value for ExternalURL. If we had entered a value here, such as lonactivesync.company.com, the users device would be redirected to it (as long as the device supported auto discovery, more on that later), and the user would connect, as long as that was configured properly. In our case, since there isn’t, the NY CAS uses the InternalURL entry to determine what address the NY CAS should use to proxy on behalf of the LON07 user. Essentially the NY CAS connects to the London CAS, and returns the Active Sync info to the users device, all seamless to the LON07 user.
Now, we start to introduce Exchange 2010 to the equation. Microsoft’s high level recommendation is to create a new namespace, called legacy.company.com and have this entry point to the 07 CAS, and slide the 2010 CAS into the existing activesync.company.com namespace. See the below diagram:
So we would need to reconfigure the –ExternalURL and –InternalURL attributes of the NY 07 CAS servers, as well as the NY 2010 CAS servers. They can all be done by changing the values of the command listed earlier in this article. The logic here is the same as 07-07 proxy. If the NYC07 user enters in activesync.company.com into his/hers server address on their ActiveSync device, the 2010 CAS server will query AD, and determine that he is a 2010 user, but in the same AD site. It will then query to see if an ExternalURL setting is populated, in which case ours is. That users device, if it supports activesync, will automatically be redirected to legacy.company.com and their profile loaded, all seamless to the end user.
If LON07 enters in activesync.company.com the NY 2010 CAS server query’s Active Directory, finds his mailbox is in another site, and checks to see if there is an ExternalURL entry. Since their isn’t, like before, it proxies the connection to the London 07 CAS server, all seamless to the end user.
Now, this is all great, but what happens if your device does not support auto discovery? Some active sync devices don’t work properly with auto discovery, and in that case, Microsoft recommends that you manually change their profile to point to legacy.company.com. Maybe not even that, but for security purposes you don’t allow external devices to use auto discover to determine the settings. In this case, you again have to manually point those devices to legacy.company.com If you have any significant number of users, this can be insanely time consuming.
Let me show you an example. I had configured everything as it was in the above diagram. I was configuring his active sync on an Apple iPad, a device that supports activesync. Problem was, his account wasn’t working. The following log file was taken from the NY 2010 CAS server for the NYC07 user, they are located at c:\inetpub\logs\LogFiles\W3SVC1:
Here, we can see that the NY 2010 CAS server is telling the device that it has the wrong URL, and is redirecting it to legacy.company.com. This is because the device has advertised that it can do auto discover. In our example, since auto discover is disabled, or because the device doesn’t handle auto discover properly, the user was getting a connection to server error on the iPad.
Now, with NO changes, let’s try configuring the same user, but not using the iPAD, but using Touchdown for the Android. Now, all work’s without issue, here is the log files:
In this case, the configuration worked without issue. Notice how it also says PrxTo:newyork07.company.local. This is because since Touchdown did not advertise to Exchange that it could do auto discovery, Exchange knew it would have to proxy the connection back to the NY 07 CAS server to allow this to complete successfully.
The funny thing is, if we were to configure LON07 on the iPAD it would work fine. Why? Because since the London 07 CAS server does NOT have a value for ExternalURL, Exchange knows it HAS to proxy to London 07 CAS for all London users.
So, we want the same behavior for the NY users on 07. To do so, we simply need to clear the ExternalURLvalue on the NY 07 CAS server. We would do so with the following command:
Set-ActiveSyncVirtualDirectory –Identity “newyork2007\Microsoft-Server-ActiveSync” –InternalURL newyork2007.company.local –ExternalURL $null
This would wipe out the ExternalURL value. The downside to this, is that auto discover for this URL would not be included, so if you used Outlook Anywhere, or other devices to connect using Auto discover, it would cause issues. If you didn’t though, for instance you disable auto discover, this fixes all your issues. Now when you try to connect NYC07’s mailbox to the iPad, since there is no ExternalURL entry for the NY 07 CAS server, the NY 2010 CAS server is forced to proxy:
Now, all existing 07 users will continue to have access to their mailbox’s via active sync and will not need any changes when their mailbox’s are moved to 2010.