Has anyone seen after a user migration from Exchange 2003 to Exchange 2010 user who are unable to access OWA? Using Chrome you can see a 301 redirect loop when hitting the languages page. I can manually force language selection, but then users cannot complete any actions with their mailbox. There is nothing in the CAS server log files indicating issues with the server or account. I have completely torn down and rebuilt the virtual directories, but still have the same issue. My 2010 CAS servers are Windows 2008 R2, Exchange 2010 SP3 RU3.
Iis – Redirection Loop in Exchange 2010 OWA
exchangeexchange-2010iisredirect
Related Solutions
Investigating this issue required me to use a bit of Active Directory know how, as well as some Exchange-2010-Management-Shell-fu.
The first thing I checked is if my 2 domain controllers are replicating properly. My initial thought was when I updated the Hide from Exchange address lists checkbox in Active Directory Users and Computers that I had changed this on one Domain Controller, which was not replicating to the other Domain Controller that the Offline Address Book generation process happened to pick. As it turns out, the Domain Controllers are replicating properly and this is not the issue.
The next thing to do is to check out some Active Directory attributes and their current values. My preferred tool for doing low level things with Active Directory is ADExplorer from Sysinternals, however ADSI Edit will do an equally good job if you prefer that.
The first attribute I looked at on the user is the msExchHideFromAddressLists attribute. This should be FALSE if the user should appear in address lists and TRUE if they shouldn't. This is really just a sense check as it's what Active Directory Users and Computers updates when you (un)tick the Hide from Exchange address lists checkbox. This was correctly showing TRUE.
The next attribute to check is showInAddressBook. This is a multi value attribute that contains all address lists that this user should appear in. Ordinarily, this should contain at least one address list the user should appear in, but for anybody who has the msExchHideFromAddressLists attribute set to TRUE this attribute should not be set at all. This was the biggest clue, as this user still had values in this attribute which should have been removed when the Hide from Exchange address lists checkbox was checked.
The Recipient Update Service on the Exchange 2003 server is responsible for updating the value of the showInAddressBook attribute (among others) in Active Directory so I determined that for some reason the Recipient Update Service was malfunctioning here.
When I initially installed Exchange 2010, I had to run setup.com /PrepareLegacyExchangePermissions
to grant the Recipient Update Service some permissions it needs because Exchange 2010 moves things around a little bit.
To check out the permissions, I opened up Active Directory Users and Computers and selected View => Advanced Features to enable me to view the security attributes for the user account in Active Directory. I then opened the offending user and checked on the security tab, and compared this to another user who should be included in the Offline Address Book. While I didn't check each permission, it was immediately obvious that the user who should be in the Offline Address Book had many more permissions granted than the user who had just left. Checking a few other users, they also had many more permissions granted than the offending user did.
Something I happened to notice purely by chance is that the offending user was not inheriting permissions from parent objects, whereas all the other users I checked were. I know from experience that this usually only happens when the user is (or once was) a member of an Active Directory privileged group. After verifying they are no longer a member of a privileged group, I went back to ADExplorer and changed the adminCount attribute on this user to 0 from 1. I then went back into Active Directory Users and Computers and enabled this user profile to inherit permissions from parent objects.
After I did that, I went into the users properties and unchecked the Hide from Exchange address lists checkbox and then checked it again. I waited a few minutes for the Recipient Update Service to do its thing, and sure enough 5 minutes later when I looked at the user object in ADExplorer the Recipient Update Service had removed the showInAddressBook attributes that it had no permission to do earlier. A quick manual rebuild of the Offline Address Book and everybody is happy.
You're doing it backwards - is there a reason for this?
This is the way it's supposed to work.
- Before you install Exchange 2010, you have Exchange 2003 on
https://mail.acme-widgets.com
- You create
legacy.acme-widgets.com
and make sure your firewall forwards traffic destined for this to Exchange 2003 - You change DNS records/firewall rules so traffic destined for
https://mail.amce-widgets.com
is now forwarded to Exchange 2010.
When you do this, any users whose mailboxes are on Exchange 2010 will use the Exchange 2010 OWA that they have logged in to (using the external or internal URL), and any mailboxes on Exchange 2003 are forwarded to an Exchange 2003 server that you specify.
To set the URL your Exchange 2003 users are sent to, run this cmdlet Set-OwaVirtualDirectory <Your OWA Virtual Directory> -Exchange2003Url https://legacy.acme-widgets.com/exchange
.
Related Topic
- Exchange 2010 and 2003 Coexistence: How to fix a 404 error on Exchange 2003 OWA when clicking the log off button
- Exchange 2010 OWA redirect to Exchange 2003 login issues
- Exchange 2010 sending old Out of Office message
- Exchange 2010 non-mailbox users not visible via EMC
- Upgrading Exchange 2010 SP1 to SP3…got this error
- Exchange 2010-2016 coexistence: Why does OWA do a 301 redirect before login
Best Answer
Often people setup HTTP Redirect incorrectly on the root and it breaks /OWA sub paths. You can setup redirect, BUT you have to make sure it only takes affect for root and not sub paths. Google is your friend.