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.

Hello, There are three diagrams for the OAB feature: 1. Mailbox Server generate the OAB file. 2. CAS server retrieve the OAB file from the MBX Server. 3. Client download the OAB file from the CAS server. For the OAB issue, we can follow the checkpoints below: 1. Check the time stamp for the OAB file on MBX server; Location: c:\Program Files\Microsoft\Exchange Server\V14\ExchangeOAB 2. Check the time stamp for the OAB file on CAS server; Location: c:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB If the files are all up to date, the issue happens when the clients download the OAB. Try the following steps to diagnostic the download issue: 1. [Check AutoConfiguration Status in Outlook] =================================== a. While Outlook is running, click the CTRL key and then right-click the Outlook icon in the system tray and then select Test Email Autoconfiguration. b. Confirm that your email address is in the address field, uncheck Use Guessmart and secure Guessmart authentication boxes. Then click the Test button. c. Once it runs, Check the Log tab and Results tab. Does autodiscover works and a OAB url is returned? 2. Manually access the OAB url https://xxx.company.com/OAB/OABGUID/oab.xml Thanks, Simon Wu Exchange Forum Support Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

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.

Thanks for the quick reply Simon. I have just done some quick reading on exchange implementation of SRV. My external DNS provider does support it. Below is a screenshot. Just to verify protocol is TCP, target is mail.domain.com, port is 443...not sure of SERVICE OR WGT. Any ideas? Thanks

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!

As long as you are keeping the machines up to date then the SSL certificate shouldn't be an issue. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

As long as you are keeping the machines up to date then the SSL certificate shouldn't be an issue. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.