Update 1: The fix for this issue has been released in the 12.1.2 Update for Office 2008 for Mac. See 'Improvements for Microsoft Entourage 2008 for Mac' section in KB 956344.
Update 2: The fix for a subsequent 'CNAME' entry issue discussed in the comments section of this blog post has been released in the 12.1.3 Update for Office 2008 for Mac. See 'Improvements for Microsoft Entourage 2008 for Mac' section in KB 958267.
In this post I wanted to quickly provide an update on an ongoing issue with some specifics to make sure our customers are well informed on its current status.
IssueAfter installing Office 2008 for Mac Service Pack 1 (SP1) when Entourage 2008 users connect to their mailbox on an Exchange 2007 Server, they may see an error like this (you can substitute 'contoso' in the screenshot below with your own root domain):
If you click on 'OK', Entourage will continue to work and you won't see this error message again until the end of that session when you close Entourage. Clicking on 'Cancel' you may end up in 'Not Connected' state with your Exchange account. This error may also come up when:
1. You try to configure your Exchange account using 'Account Setup Assistant' which now uses Autodiscover Service on Exchange 2007 to automatically configure your account or
2. You use any 'Exchange Web Services' based feature in Entourage 2008, like OOF Assistant, Free/Busy Info pull-up, etc. as they also utilize Autodiscover feature or
3. Entourage tries to talk to Autodiscover Service while its running connected to your mailbox to see if any updates were made to Autodiscover Service on server side by your Exchange Administrator, this happens automatically in the background based on a pre-set interval which cannot be modified by user
CauseThis happens as Entourage 2008 tries to establish a secured connection to the first of the 2 default addresses (URLs) in its attempt to contact the Autodiscover Service on your Exchange 2007 Server. This is explained in the Autodiscover Whitepaper, see 'How the Autodiscover Service Works with Clients' section. Most organizations using Exchange 2007 do not publish Autodiscover Service thru the first URL mentioned over there, i.e. 'https://contoso.com/autodiscover/autodiscover.xml', rather they use the other URL, i.e. 'https://autodiscover.contoso.com/autodiscover/autodiscover.xml'. When Entourage finds an error (mostly its 'Common Name' mismatch) with the certificate published at the root of your domain (if there is one, many organizations do, but 'Common Name' on that certificate is 'www.contoso.com', not just 'contoso.com' and Autodiscover Service is not published thru that URL), it displays the above error. It does not move silently to try the other possible URL. Clicking 'OK' on above error makes it exactly do that and thus it finds the Autodiscover Service responding on the other URL and everything then works fine from there.
This issue can also happen in Entourage 2008 if Autodiscover Service is not configured properly as per the guidelines in Autodiscover Whitepaper. See 'Note' below on how to quickly check to see if Autodiscover Service is properly configured and published for users.
ResolutionMicrosoft is working to release a fix for this issue in an update for Entourage 2008 but a final release date is not available yet. I plan to update this post with new information in this regard when it becomes available.
NoteWe need to make sure that when Entourage looks for Autodiscover Service, the related URL as mentioned above in 'Cause' section is configured and published to respond to those requests. A quick way is to look up the A Record (a type of DNS record which is used to map a hostname or URL to the IP Address of the host) which you will have to register with your DNS provider.
A Working Example:For Microsoft, the Autodiscover Service is configured and published at 'https://autodiscover.microsoft.com/autodiscover/autodiscover.xml', you can look it up using this URL in your browser:
You will see an IP Address is mapped to the URL for Autodiscover Service to respond to incoming requests.
Now, if I go and hit the URL for Autodiscover Service in my browser, i.e. 'https://autodiscover.microsoft.com/autodiscover/autodiscover.xml'
I will get a window to enter my user credentials (domain\username & password) and after that I will see the following lines in the main browser window:
<?xml version="1.0" encoding="utf-8" ?> - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">- <Response>- <Error Time="10:29:57.7332076" Id="59171512"> <ErrorCode>600</ErrorCode> <Message>Invalid Request</Message> <DebugData /></Error></Response></Autodiscover>
The response above says 'Error 600, Invalid Request' as the Autodiscover Service URL is not supposed to be accessed thru a browser. This is an expected response in this scenario and confirms the proper configuration and publishing of Autodiscover Service.
A Non-Working Example:Let's use Contoso as a non-working example, the Autodisover Service should be configured and published at 'https://autodiscover.contoso.com/autodiscover/autodiscover.xml', if you look it up using this URL in your browser:
You won't find an IP Address mapped to the URL for Autodiscover Service, instead you will see an error there saying 'server can't find autodiscover.contoso.com'.
The 12.1.2 did not fix mine. I'm getting the error that specifies a domain name, rather the the Exchange server name - which seemed to be the indicator that this was the exact error I was experiencing.
As I mentioned above in 'Cause' section, this issue can also happen in Entourage 2008 if Autodiscover Service is not configured properly as per the guidelines in Autodiscover Whitepaper (linked above). Did you use the info in 'Note' section to check if Autodiscover Service is properly configured and published by your server administrators?
I too am still getting this SSL error. Autodiscover service is configured properly as in Note
Same here, The 12.1.2 did not fix ours as well.
Mitchll & Brooks,
You guys then need to contact Microsoft Professional Support at 1-800-936-4900 (http://support.microsoft.com/default.aspx?scid=fh;EN-US;OfferProPhone)
so that we can see what's going on.
Did not fix mine either ~ ugh. I called the support number above. They said they would look into it for a a fee of $259. Or I can go to the support website for free help.
If you have already run the 2 tests in my blog above ('Notes' section) and you get proper response (be really sure about it, talk to your Exchange Server Admin about Autodiscover Service setup, if you are not one yourself), then either you can get support thru the above paid option (keep in mind that charge is refunded later if the issue is concluded as a bug in Microsoft product) or you can post on Forum (free) at: http://www.officeformac.com/ProductForums, where MVPs can try to help you out.
12.1.2 did not fix our problem, either.
We are using a DNS Service Location (SRV) record to locate the Exchange Autodiscover service on another hostname per the AutoDiscover whitepaper. It works great for Microsoft Outlook. Is this also supported for Entourage? It is not working. It would be great it this could be supported so that it doesn't automatically come up with the warning for all of our Entourage users.
No, SRV Record will not work for Entourage 2008. Only Outlook 2007 has the capability to read the SRV record. Entourage just goes and looks for
https://autodiscover.contoso.com/autodiscover/autodiscover.xml (as I mentioned above in my post), so you will need to put in an A Record for the host which is running Autodiscover Service (Exchange 2007 CAS) and then you can supplement that with a CNAME
entry pointing the above URL for Autodiscover Service to the FQDN of CAS or do it in a way more appropriate for your org setup and infrastructure. In the end, Entourage users should be able to hit the above URL thru a browser (like Safari), get a credentials
prompt, enter their domain credentials (username, password & domain) and get the '600 Invalid Request' error as I mentioned in my post above. After that they will not see the 'SSL Warning' issue.
But I would expect it to still give a hostname mismatch between the server and certificate... replacing our domain name with contoso - We have our CAS NLB set up as webmail.contoso.com This is where autodiscover needs to point. If I set up a CNAME entry pointing autodiscover.contoso.com to webmail.contoso.com ... since our certificate is for webmail.contoso.com, I imagine entourage will complain that when it's looking for a autodiscover.contoso.com certificate it is only finding a webmail.contoso.com certificate (I will have to try this later to verify). We could buy another certificate, but would really rather not (it wasn't in the budget). The other thing I'm not sure about, and I want to set up a network traffic sniff, is what order entourage is checking for things. If it is checking the root domain first of contoso.com, it is going to find a certificate for www.contoso.com, hence another name mismatch.
Hmm, the update hasn't allowed the autodiscover to work with us. Outlook 2007 work with autodiscover, but I tried the auto activation of our Entourage 2008 users and no go ;-(
Certainly say that it is frustrating.
For example if you ping autodiscover.sherweb.com you get 184.108.40.206 (pointing to our CAS servers).
Now if we run the test that Amir has provided (https://autodiscover.sherweb.com/autodiscover/autodiscover.xml) and I substitute my domain name and then
logging in with my domain/username and password shows the link:
https://autodiscover.ihostexchange.net/autodiscover/autodiscover.xml and of course the following:
<?xml version="1.0" encoding="utf-8" ?>
- <Autodiscover xmlns="'>http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
- <Error Time="10:29:57.7332076" Id="59171512">
Because of our hosted environment .ihostexchange.net is the domain of our Exchange organization. In this case our customers don't host the Exchange server and web services. However, they do create the A record autodiscover.theirdomain.com and that works
fine with Outlook 2007. We even allow them the opportunity to use a proxy which is theirdomain-com.ihostexchange.net if they haven't configured their A record. All this works without a hitch in Outlook 2007. However, the way Entourage is configured it appears
as if it is still trying the
and not the second way. I'm lost as to what we need to do. It would be fantastic to tell a user just to plug in their e-mail and let the autodiscover work from there. Unfortunately, OOF and other web services don't work. A real shame.
Yes, you are right, and to address that you can use the Unified Communications Certificate (a certificate that supports multiple DNS names) with an entry for Autodiscover URL in SAN (Subject Alternative Name) field, read the Autodiscover Whitepaper (linked above) for details on that & other possible options. You other concern has already been taken care of with the fix for this issue, read the Cause section above.
I am looking into your scenario currently. Are you sure that your customers are creating an A Record or a CNAME entry which should have a mapping of Autodiscover URL for your customer's domain to your domain, like we require our customers of Exchange Labs Exchange Hosting, see: http://technet.microsoft.com/en-us/exchangelabshelp/cc188653(EXCHSRVCS.140).aspx
I am now getting the error. I am using Intermedia exchange hosting and have been working fine until today. I now get the cert error. I have been running 12.1.2 since it released. SO 12.1.2 is not addressing this issue for me.