I ran into a rather obscure Exchange Availability Service behavior that will be of little interest to most. So, if you are not working at a hosting company or have never heard of the ‘msExchQueryBaseDN’ attribute, save yourself some time and skip this post.
The ‘msExchQueryBaseDN’ attribute is used to restrict Outlook Web Access’ (OWA) search for mail enabled objects in Active Directory (when simulating the Global Address List) — or at least that is what it was originally used for. Rather than searching for all mail enabled objects, it will search only a portion of Active Directory. The attribute is usually not set because most Exchange organizations have only one Global Address List – The ‘Default Global Address List’ which contains all mail enabled objects.
If you don’t understand why there would be more than one GAL, stop reading here.
Hosting companies supply services to many groups or enterprises and therefore have many GAL’s. They set this attribute in each user account to control that users ‘view’ of other users via OWA. It is also sometime set in very large organizations when the GAL becomes very large.
Prior to Exchange 2007, when set, the attribute contained a Distinguished Name (DN) of an OU that was the base of the LDAP query. In Exchange 2007, this attribute could also be set to the DN of an address list in the ‘All Address Lists Container’. In this situation, OWA would use the Address List’s filter for the query. This provided more flexibility in controlling the ‘experience’ of users, especially when they were in different OUs.
Notice that everything I have discussed here is about OWA: Not Outlook. Outlook accesses GAL’s based on security. It had, to my knowledge, never been affected by this attribute. It appears that the new ‘Availability Service’ in Exchange 2007 and 2010 does use it.
When an Outlook 2007 or above user wants the free/busy information for a user it asks the Availability Service on a Client Access Server (CAS) in its site for the information. When that user’s mailbox is on a 2007 or above Exchange server, the CAS server gets the information directly from the user’s calendar in the user’s mailbox. If the Users mailbox is in another site, the request is proxied to a CAS in that site which gets the information from the users mailbox and passes it back to the requesting CAS and then the requesting user. Note: the requesting user can be an OWA, Outlook Anywhere, or Outlook user.
Nothing controls whether the ‘msExchQueryBaseDN’ attribute for a particular user, the Global Address List for that user, or the Offline Address List (if the user is cached) for that user produce the same result.
So here is what happens: User A tries to set up a meeting with User B in Outlook 2007 or above. User B is in their GAL and is added to the meeting request’s scheduling assistant. Outlook asks a local CAS for the User B’s free/busy information. The CAS does not return it. Outlook shows it as unavailable. Why?
In these cases it was discovered that the ‘msExchQueryBaseDN’ attribute for User A was more restrictive than the GAL. It did not include User B so User B’s free/busy was not returned. Change the user’s ‘msExchQueryBaseDN’ attribute to include User B and User A retrieves it.
One reason for this behavior could be that, as mentioned, the Availability Service is servicing requests from multiple sources so it applies the most restrictive rules for all of them. Another possibility is that Auto Discover is somehow involved. If you run ‘Test E-mail Configuration’ from User A’s Outlook and put in User B as the E-mail Address being tested, it is not successful if the ‘msExchQueryBaseDN’ attribute excludes User B. It is successful when the msExchQueryBaseDN’ attribute includes User B.
No matter what the reason, it is necessary make sure that the ‘msExchQueryBaseDN’ attribute is not more restrictive than a user’s GAL if you want to avoid this problem.