|
caw1970 -> RE: Error 0X8004010F (1.Mar.2007 8:28:09 PM)
|
Here's what worked for me:
Assuming all the following are true, the problem is likely a public DNS issue:
- You have configured the OAB for web distribution correctly.
- The client computers having this issue are located across a security device or outside your corporate network (The Internet, etc.) where your internal DNS records are not replicated.
- These clients are using the Outlook Anywhere feature in OL2007.
Apparently, the OAB download activity is handled by the Autodiscover feature in OL2007. When downloading the OAB, Outlook tries to connect to a web services Url found on the Client Access Server that resides in an IIS virtual directory called "autodiscover", and access a file called "autodiscover.xml". If the OAB is not configured correctly for web distribution, this file will likely not exist, and your day will be ruined. On the other hand, if the file exists, then you should be able to test client connectivity to the web service by doing the following:
1. From the client machine, open a web browser.
2. Navigate to http://<mail-server>.<your-email-domain-name>.<ext>/autodiscover/autodiscover.xml.
3. Enter your credentials when prompted.
You will get a 600 error. This is ok. It means you are connecting to the autodiscover service, and that you don't have an issue with access to the web service from the client.
By default, Outlook will look for and try to connect to the following preset Autodiscover web service Urls in this order when looking for the "autodiscover.xml" file:
https://<your-email-domain-name>.<ext>
https://autodiscover.<your-email-domain-name>.<ext>
http://<your-email-domain-name>.<ext>
http://autodiscover.<your-email-domain-name>.<ext>
In a nutshell, if you don't have a public DNS "A" record for "autodiscover.<your-email-domain-name>.<ext>", then your OAB downloads will fail miserably, and you will get "0x8004010F" synch errors in Outlook. Since public DNS records take 24 to 48 hours to replicate and become effective, you will likely need a workaround during that time. The easiest interim fix is to modify the client computer's hosts file to include an entry for the autodiscover host name, binding it to the ip address of the CAS or mail server. For example:
65.223.187.51 autodiscover.your-email-domain.com
This is just an educated guess, but it is likely that the reason internal clients (domain member computers) that are configured to use Outlook Anywhere (like laptops) don't have this issue is because of the integrated nature of DNS and Active Directory. Even though you probably don't have an "A" record for the "autodiscover" host internally, Outlook still seems to connect to the web service just fine. I would be interested to know if my thoughts on this are accurate, but I have already spent enough time on this issue...
Good luck!
|
|
|
|