Here is the scenario. We have been running on exchange 2007 for the past three years. We have been using outlook anywhere for the past year and a half. However, sometime during the setup and integration of exchange 2010 into our environment over the past two months, outlook anywhere users as well as users who connect through VPN have started to complain that they have stopped being able to see other users calender appointments (free/busy connector) as well as access to the out of office assistant. This does not affect users internally. Now all my research into this problem indicates that outlook is hardcoded to look for autodiscover.mydomain.com. So I went ahead and added the domain to our external DNS and sure enough, these options seem to work again, HOWEVER We are being prompted with a cert warning now. This is because the only cert we have established with our exchange 2007 environment is owa.mydomain.com. We have never had the autodiscover dns name setup before and our cert does not include it, but we have also never experienced this problem before. So what I am trying to understand is, what has changed that would have suddenly caused this problem? And how do I revert back to allowing users access to the out of office assistant and to view other users calendar appointments without requiring the use of the autodiscover service to be published from our external dns? I have performed both of the following commands specifying our owa.mydomain.com in place. 1) set-WebServicesVirtualDirectory -identity MAIL01\EWS (Default Web Site) -externalurl https://owa.mydomain.com/ews/exchange.asmx 2) Set-OutlookProvider EXPR -CertPrincipalName:"msstd:owa.mydomain.com" In case this somehow matters, our exchange 2010 cert DOES have autodiscover.mydomain.com as part of it (SAN cert). However exchange 2010 has been completely removed two weeks ago as it was decided to hold off until next quarter to purchase licensing. Any additional insight would be really, really helpful.

The "Free Busy Connector" is for Lotus Notes. You don't have Lotus Notes in this equation, do you? Assuming you just mean "Free Busy" and no "Connector", what versions of Outlook are having trouble? This matters because different versions of Outlook get Free Busy data differently. Can you get Free Busy data in OWA? If you're having trouble with Free Busy and the Out of Office Assistance, that indicates that your availability service isn't working, and that points to trouble with Exchange Web Services. Domain-joined machines connected to the internal network will first try to look up Autodiscover information using the service connection point in Active Directory. That is controlled by the Set-ClientAccessServer cmdlet to set the -AutodiscoverServiceInternalURI property. You can use Get-ClientAccessServer to examine the value. This should be of the form https://casarray.mydomain.com/Autodiscover/Autodiscover.xml, where casarray.mydomain.com is the load-balanced address of your CAS array, or the CAS server name if you have just one CAS. You only need autodiscover.mydomain.com in the SAN if something points to it or non-domain-joined machines are looking to autodiscover, since Outlook and ActiveSync on mobile devices are programmed to look for that URL. Just a hunch: Has the certificate expired?Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Ed, Apologies for the slow reply and thanks for taking the time to help. You are right, I did mean just the Free Busy and OOF. The clients experiencing the issues are outlook 2007, 2010 seems/seemed unphased. This only happens when the clients are connected through outlook anywhere or vpn. This was a combination of both domain joined systems accessing outlook anywhere outside the firewall as well as personal standalone systems. Same for VPN. These same domain joined clients have no problem inside the network however. The autodiscover server resolves properly internally and resolves properly using outlook 2010 client or did. We implemented the workaround of having an autodiscover.domain.com certificate and implemented a srv record in the external dns. Kind of a workaround that has caused other issues by prompting users to accept the redirection of the autodiscover.xml location. Some outlook 2010 and mac entourage clients keep prompting though. Though I think this is client specific. Regardless of the workaround we have implemented which appears to be working for the most part now, any ideas on why this would have started since implementing exchange 2010? As mentioned, we were using outlook anywhere prior to exchange 2010 existing in the environment with the autodiscover domain name record, public certificate or srv record in our external DNS. Really not sure what caused this to start.

The first place to look is to run Test E-mail Autoconfiguration (Ctrl - click the Outlook icon in the system tray) and run just the AutoDiscover test (clear both Guessmart checkboxes). That should tell you the URLs that Outlook is using for the various features, and you can verify that they're configured properly, name resolution works and the proper holes are poked in the firewall.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Scott, Any update for your issue? Do you mean that just some of the outlook 2010 and MAC clients have the issue? If so, like you referred, it is just client specific. How about use the https://www.testexchangeconnectivity.com/ to retrieve some information, about your web services for the external users. Regards! GavinPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

What I am guessing is you do not have all the correct subject alternate names on your certs on all your cas. From each CAS server, run a "get-exchangecertificate | fl certificatedomains" and "Get-ClientAccessServer |fl AutoDiscoverServiceInternalUri", you need to make sure your autodiscover hostnames are also in the subject alternate names of all your certs, I am guessing this is your issue. You can request a cert from the cas servers in powershell with all the SAN's you need, and then either generate one internally or through a trusted cert provider (verisign/thawte/etc). We use internally generated certs provided by our enterprise CA for internal needs an a wildcard cert for external autodiscover/OWA.