I’ve found some shortcomings in the material that I was able to scrape together through many a Google search related to autodiscover and Exchange 2007. There are many great resources out there for setting up your Exchange 2007 organization, migrating from 2000 or 2003, even some great examples of tweaks you can do to make Exchange 2007′s great new features work for you.

Let me set this up…about a year ago I did an upgrade from Exchange 2003 Standard to Exchange 2007 Standard for a client of ours. This client (who happened to be a school) wanted to disallow the students from sending email to Faculty and Staff distribution groups. Another requirement of theirs was that the faculty and staff/admin should be able to see all students, users, and groups and send mail freely. I must mention our means of accessing the email accounts for the different sets of users, because this played a vital role. The faculty required access via MAPI Outlook 2007 and OWA internally and externally, while the students were allowed access only via OWA internally and externally. The solution as to create segregated address lists.

If you’ve even toyed with the idea of segregating address lists in Exchange, then you’ve seen this white paper on virtual organizations and segregating address lists. A very good white paper; it’s what I used to get me started on this project. There were some caveats with that, the procedure is intended to completely segregate two or more address lists for the purpose of maintaining multiple virtual organizations within the same Exchange storage group. In my case, the goal was to segregate the address lists, but allow permission to view and to email in one direction, i.e., staff to student. This was obtained through a deny permission for download default OAB for all students. That, coupled with making the Faculty OAB the default OAB, and then allowing all access to the student OAB gave us the desired result. A caveat here is that if you have both groups of users setup with outlook 2007, you will be unable to configure new users in outlook because they are unable to find themselves in the default OAB.

The next challenge was to populate the two segregated address lists with the correct user accounts. The procedure for addressing this challenge again can be drawn from the whitepaper that I previousliy mentioned. The key point that I want to make here is that to make this work you are required to set the msexchquerybasedn user attribute for all users. This atribute’s value should correlate to the DN of the OU containing the users that you wish to populate your address book with. In my case for example, for the faculty accounts, I set the msexchquerybasedn attribute to OU=Faculty, DC=domain, DC=com, and the students set to the OU containing the students. This worked and all was well for some time.

Very recently we started to notice some anomalies with some staff user accounts. From within their outlook client the users were unable to launch the Out of Office Assitant and were also experiencing sync errors related to downloading the address book. Keep in mind that the solution in place had worked well for the past 10 months or so. After further investigation we found that the autodiscover service was to blame. As it turned out, there are quite a few pieces that must be in place for the autodiscover service to function properly.

Autodiscover is highly dependant on DNS and certificate services. For error free autodiscover you must have a certificate from a trusted CA that matches the FQDN of the autodiscover web page that you’ll find in the IIS manager under your default website (assuming you haven’t done something custom with your IIS). In my case I had a valid single certificate which was used for access to OWA and autodiscover; this is a valid configuration according to Microsoft. We were also able to resolve the FQDN that was on the certificate to the IP of the mail server running IIS and the Exchange CAS service. Simply put these things must be in place and working properly; however, all of these things were testing satisfactorily and we were still experiencing the error.

Here is what I was finally able to trace this problem to: the msexchquerybasedn user attribute that we set to an OU containing the faculty users was to blame. Apparently (this is news to Microsoft) the autodiscover service uses the msexchquerybasedn attribute (if it’s set) to correlate a user to their location in AD. This was not always so, we ran this configuration for 10 months without issue. The msexchquerybasedn user attribute must be set to the OU of which the user is a member, or not contain a value. For installations where you have a single default OAB you do not need to set this user attribute to any value. However if you are using this attribute to populate your address books and are unable to change it, then you must alter your OU structure to remedy this.

Dan Kaupp