Tag Archives: Exchange 2007

User’s Cannot Log into Exchange 2007 or Exchange 2010 OWA with UPN Suffix

Client Access, Exchange 2010, Hosting, Resource Forest

 

Lets say you have the following environment:

Drawing1

ExchangeResource.corp hosts all the Microsoft Exchange 2010 servers, and linked mailbox accounts.  The actual user accounts are stored in the Tailspin.corp and Mantech.corp forests.  The Tailspin.corp and Mantech.corp forests have a one way forest trust with ExchangeResource.corp so that users in the Tailspin.corp and Mantech.corp forests can access their linked mailboxes in the ExchangeResource.corp domain.

Now to make things easy on the users, you set the OWA directory to use UPN suffix names instead of Domainuser:

image

This will allow users in Tailspin to login using username@tailspin.corp and users in Mantech to use username@mantech.corp.

Everything works fine, but then you add a UPN suffix to each individual forest that makes the UPN suffix match the users email address. Below is an example shown with the user Tom Jones in the Tailspin forest:

image

Now users in Tailspin login using username@tailspin.com and users at Mantech login using username@mantech.com.

A user goes to login with the new UPN and is greeted with an error message that they could not login:

image

But using the old UPN still works fine, so what’s going on?

Well, if we check the event logs of the DC in the ExchangeResource.corp domain we find EventID 6034 for LsaSrv in the security event log:

image

The DC is telling us that it does not know how to route the Tailspin.com suffix.  It notes that it has been added to the forest tailspin.corp, as it learns it through the forest trust, but that the name suffix is not enabled.  It does very nicely tell us how to fix this.  Go to Active Directory Domains and Trusts->Right click on ExchangeResource.corp->Properties

image

Go to the Trusts tab.  Here you will see all the forests that you have trusts with.  Highlight the tailspin.corp forest and click on properties:

image

Navigate to the Name Suffix Routing tab:

image

Here we can see the new tailspin.com suffix has been added, it even has a status of “New”, but the Routing is disabled.  Highlight the suffix and then click Enable:

image

If you do not see the new suffix you created listed here, simply click the Refresh button and it should appear.

After hitting apply both names should be enabled:

image

Now if a user try’s to login, they should be all set!

image

Keep in mind you will need to do this each time you add a new UPN Suffix to one of the domains that are being trusted by ExchangeResource.corp.

Enjoy!

Migrating Exchange 2007 ActiveSync to Exchange 2010. And why your Android may work but your Apple iphone / ipad may not.

ActiveSync, Client Access, exchange 2007, Exchange 2010, Security

 

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:

Exchange07as

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 “newyork2007Microsoft-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:

Exchange2010as

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:inetpublogsLogFilesW3SVC1:

 

Sep. 2801 15.56 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:

 

Sep. 2802 15.56

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 “newyork2007Microsoft-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:

 

Sep. 2803 15.56

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.