Environment: Exchange 2010 (was mixed mode but have since decommissioned remaining 2003 servers), "most" Outlook 2010 clients We are experiencing a couple of issues: 1. OAB does not appear to be updating. Clients running in cache mode see old version of OAB. Have tried updating on server using Exchange Console. When force upgrade on client, update of OAB hangs. 2. Admin Asst add's calendar items and attachments to calendars while working online. User who is off-site using cache mode has different calendar items and no attachments. Appears changes not showing when user is in cache mode. I assume it's related to autodiscover?? Any ideas? Thanks

OAB - this is common in migrations, where the public folders were not replicated across correctly, or an OAB is not set as default on the databases. Therefore check each database has a default OAB set. Then check which distribution methods you are using. If you have Outlook 2003 then you MUST use Public Folders. This can be exclusively or as well as web distribution. Autodiscover controls the availability service. Primary reason that doesn't work is SSL certificate issues, followed by DNS issues. Do you have a commercial SSL certificate installed? Does it have all of the correct names? Does autodiscover configure Outlook 2007 and higher clients? Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Thanks to both of you for your replies. - Checked timestamps on both the generation MBX server and a local CAS and both match (this morning at 5am) - I went into each database client settings and none of them had an OAB specified...which is weird because I would have sworn I went through this already. How has anyone had any OAB if it wasn't set? The issue has been the OAB is old data...but there was data none the less. I have now assigned the "New Offline Address Book" which is set as the default OAB and is set for both public folders and web distribution. - Am I able to simply delete the "Default Offline Address Book" which is set to False for default and is only set for public folders distribution? - On the Autodiscover front, we use a godaddy UCC SSL certificate which is set for mail.domain.com with SAN names of autodiscover.domain.com, legacy.domain.com, servname.domain.com - On the DNS side, externally autodiscover.domain.com and mail.domain.com are pointed to the exact external IP address and mail.domain.com works fine for OWA, etc.

One more question on the autodiscover process. We have autodiscover.domain.com setup with an SSL certificate, etc. However, our email server's serve multiple (10+) email domains as we have different companies under one umbrella. For autodiscover to work properly, do I need to configure and buy a certificate for EVERY domain? I noticed on the testexchangeconectivity tool, autodiscover fails with a test user with an email of name@domain2.com where it passes with a user of name@domain.com For these users, we change the Outlook Anywhere settings from autodiscover.domain.com to mail.domain.com and then it works...but when I am troubleshooting these sort of issues, I go into the Outlook Anywhere settings and they have been defaulted back to autodiscover.domain.com Just wanted to point out some things. Hope that clarifies things a bit. Thanks

With regards to autodiscover you have three options for multiple domain sites. 1. Autodiscover for each domain in the same certificate. You cannot really use multiple certificates. 2. Use SRV records. 3. Use a redirect on another web site. SRV records are the most common, but do require the external DNS provider to support them, many do not. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Just an update. I have created an SRV record for one of the alternate email domains and will test in a few hours once all name servers are updated. Our external name servers format is Service = autodiscover (it automatically will pre-pend the underscore), protocol = TCP, Host = @ (to imply the root), port = 443. Will update when i have tested. Thanks.

Autodiscover test passed! However it did kick back this warning: All computers are Windows 7, which I believe the Update Root Certificates feature is enabled correct? Thanks again! Am hoping both the OAB fix and the autodiscover SRV solve the problem!