We have identified a curious issue with Exchange 2010 when SP2 Rollup 4 is applied. Here’s what happened, in a nutshell, on our servers:
Users who have ‘Full Access’ permissions over a secondary mailbox lose the ability to open that secondary mailbox via OWA.
The problem was clearly directly attributable to the rollup and we confirmed this: prior to SP2 RU4 it works; after the update is applied it no longer works. Removing rollup 4 restored the functionality and stopped the error (‘System.ArgumentNullException’) from being returned.
Initially we were confused both by this behaviour and also that it didn’t apparently seem to be a widespread issue. Had we found a problem that was unique to our installation? After our diagnostics had drawn a blank we naturally escalated our report of the problem. A bit of email to-ing and fro-ing eventually led to confirmation that Microsoft can reproduce the error we’re experiencing – but only under a certain very specific condition. This seems to be the explanation for why the issue isn’t widespread – our installation differs in one crucial respect from the majority of others out there. This problem is caused by a revision, introduced in SP2 RU4, which changes the server’s behaviour when trying to access secondary mailboxes from within OWA. Here is what we’ve been told:
“When there is an additional mailbox that is being accessed through OWA, we perform a search for the same and return it back based on the permissions on the mailbox. The way this search is being performed has changed starting E14 SP2 RU4.
In Exchange 14 SP2 RU3 and previous versions, we just did an un-scoped search. So in a large organization and in a hybrid setup (cloud + On Premise), the search results could be ambiguous. There was a change in this logic introduced starting Exchange 14 SP2 RU4. We now do a scoped search, using the scope of the Primary SMTP Domain of the additional mailbox. We go ahead and search for an Organization ID for this domain in the OrgID Cache that is built. This Cache is built based upon the list of domains in the “Accepted Domain List”. When this domain entry is not in the “Accepted Domain List”, the cache would return a null organization id, resulting in the System.ArgumentNullException. We need to also note here that the cache is built upon the actual domain name, and not a wild card. So a domain entry in the Accepted Domain List, similar to “*.something.com” does not mean that we will have all the domains under something.com in the cache. We will need to add all the domains explicitly in the Accepted Domain List. The cache will be formed based on this list, so that we need not iterate the accepted domain list frequently.”
The university, by virtue of its many departments, divisions and colleges has a great many domain names – 208 at the current count* – and this list changes regularly. To avoid the maintenance overhead of altering the Accepted Domain List we have long since used a wildcard entry for the ox.ac.uk domain. It seems that we therefore fall foul of this new scoped search functionality as a consequence of our wildcard. At the moment the ‘fix’ seems to be to remove the wildcard entry and instead add an entry for every accepted domain.
*Some way off the limit.