Autodiscover passes all tests, but OAB, OOO and free/busy all fail to work for Outlook Anywhere
Environment: Exchange 2007 SP1 with legacy Exchange 2003 serversstill in the site.Public Folders are hosted on the Exchange 2007 server. OAB moved to Exchange 2007 server already. My frustration level is growing daily. For Exchange 2007, after working with MS Support for over 12 hours, we got the OAB downloading correctly, then discovered that autodiscover needed VPN running to complete properly (would ask to authenticate to the E2K7 mailbox server)and traced that back to IPV6 still being enabled even though it was disabled in the Network configuration. It was disabled through a registry entry to fix that problem. Great, now autodiscover works fine - passes the Outlook test (only autodiscover checked) and the Shellcommand:"test-outlookwebservices | fl" But it broke: Out of OfficeFree/Busy queriesOAB downloading for Outlook Anywhere clients (not using HTTP Proxying they all work fine). OOO requests get the message: (sic) "Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later." I double checked the IIS settings for the availability of Windows Authentication for all sites in IIS on both the HUB/CAS server and the Mailbox server - it is. My suspicion is that the two servers are trying to communicate with IPV6 for these services and since it is disabled these features don't work. I will be darned if I can find any technical information that would confirm or deny my suspicions, or help me fix the problems. Any E2K7 guru care to hazard a quess?SnoBoy
January 30th, 2009 7:37pm

SnoBoy, I would start by verifying that the endpoints returned by autodiscovery are accessbile from your client. When you perform the Outlook test you will get the Availability Service URL (controls Free/Busy), the OOF URL and the OAB URL. Can you try pinging these servers? You might be getting URLs that are accessible only within the domain and if your client is not domain joined then it wouldn't be able to contact the services. In that case you'd need to configure the external endpoints by using the following cmdlets: Set-WebServicesVirtualDirectory Set-Oabvirtualdirectory Also, since at some point you got OAB working I'll assume you already enabled OAB web distribution but it won't hurt to double check.
Free Windows Admin Tool Kit Click here and download it now
January 31st, 2009 4:39am

The ports 80 and 443 are all open through the firewall, but even clients *inside* the firewall fail in the same way, so it is not a connectivity issue.SnoBoy
February 1st, 2009 5:42pm

Dear customer: Let's focus on that thread on free/busy issue, please. It is easier for us to track your issue and make sure we respond promptly. The Availability service for Microsoft Exchange Server 2007 provides calendar information for your users. This information is known as free/busy information. The Autodiscover service provides information for the Availability service by locating and providing the external and internal URLs for the Outlook 2007 client. If your Microsoft Office Outlook 2007 users cannot view calendar information for other Outlook 2007 users in your Exchange 2007 environment, the problem may involve a failure in either the Autodiscover service or the Availability service. You can use Outlook 2007 to troubleshoot problems with the Autodiscover service. To determine whether the Autodiscover service is unable to provide information to clients by using Outlook 2007, log on to the mailbox of the user for whom you want to troubleshoot Autodiscover connectivity, and then follow these steps: 1) In Outlook 2007, on the Tools menu, click Options, click the Other tab, and then click Advanced Options. 2) On the Advanced Options page, select Enable logging (troubleshooting), and then click OK. 3) Restart Outlook 2007, and then try to view free/busy information for another user. 4) In Microsoft Windows, click Start, click Run, and then type %temp%. 5) In Windows Explorer, open the olkdisc.log file and locate the files in the olkas directory. 6) The information that is contained in this directory can frequently provide information about which service is not functioning correctly. 7) Send the log file to v-rocwan@microsoft.com for analyze. You can also use Outlook 2007 to test the AutoConfiguration information that is provided by the Autodiscover service. To use the Outlook 2007 client to test AutoConfiguration by using Outlook 2007, log on to the mailbox of the user for whom you want to test the AutoConfiguration, and then do the following: 1) While Outlook 2007 is running, hold down the CTRL key, right-click the Outlook icon in the notification area, and then select Test E-mail AutoConfiguration. 2) Verify that the correct e-mail address is in the box next to E-mail Address. 3) Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication. 4) On the Test E-mail AutoConfiguration page, verify that the check box next to Use AutoDiscover is selected, and then click the Test button. 5) Click Results tab, send the screenshot of it to me for analyze. 6) Click log tab, send the screenshot of it to me for analyze. 7) Click XML tab, send the screenshot of it to me for analyze. run the following command and send the txt file to me. Test-OutlookWebServices -ClientAccessServer ClientAccessServer01 >c:\test.txt Open Event Viewer, navigate to application log file, right click it and cleanup. Open EMS, run the following cmd-let, Get-eventloglevel MSExchange Availability | set-eventloglevel level expert Reproduce the issue and save the supplication log as .evt or .evtx file, send it to me. Note: when you send e-mail to me, please let me know the URL of the post. Rock Wang - MSFT
Free Windows Admin Tool Kit Click here and download it now
February 2nd, 2009 5:08am

Dear customer: I only found the following information in test.txt file, please double check you run it correctly. Id Type Message -- ---- ------- 1010 Error Unable to identify user 'null'. If y... Note: you should replace ClientAccessServer01 with you exact CAS server name. From your olkdisc.log file, I found the following information: 5592 17979286 02/02/09 13:46:32 Autodiscover to https://tamu.edu/autodiscover/autodiscover.xml starting 5592 17979396 02/02/09 13:46:32 Autodiscover to https://tamu.edu/autodiscover/autodiscover.xml FAILED (0x800C8203) 5592 17979396 02/02/09 13:46:32 Autodiscover to https://autodiscover.tamu.edu/autodiscover/autodiscover.xml starting 5592 17979442 02/02/09 13:46:32 Autodiscover to https://autodiscover.tamu.edu/autodiscover/autodiscover.xml FAILED (0x800C8203) 4368 18780211 02/02/09 13:59:53 Srv Record lookup for tamu.edu FAILED (0x8004010F) From you screenshots, it is tees.tamus.edu. install adsiedit.msc tool and open it, navigate to the following location: DC=<domain>, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<Organization>, CN=Administrative Groups, CN=Exchange Administrative Group, CN=Servers, CN=<CAS Name>, CN=Protocols, CN=Autodiscover, CN=<CAS Name> Right click CAS Name and select properties, click attribute editor, select serviceBindingInformation, send the screenshot of it to me for analyze. Open EMS, run the following command and send the txt file to me. Get-OutlookProvider >c:\proivder.txt Get-WebServicesVirtualDirectory | fl * >c:\webservices.txt Rock Wang - MSFT
February 3rd, 2009 10:24am

I still would like anyone to explain to me how Outlook on an non-domain joined PCdetermines what the name of the autodiscover server is - especially what the domain is. That seems to be the crux of the problem here and despite it knowing what the CAS server's domain is, it is using something else. Every discussion of Autodiscovery I see starts with the assumption that just having an A record for the autodiscover server is enough, but when Outlook starts byquerying the wrong domain, that is useless! Assumptions are made that don't always hold. Step one in the autodiscover process is not querying the autodiscover server - it HAS to know what domain to even NSLOOKUP to discover what the autodiscover server is.For example it if think the domain it tamu.edu instead of tees.tamus.edu, querying DNS for autodiscover.tamu.edu is going to zero good. It really needs to know adn query autodiscover.tees.tamus.edu.Silent scream!!!SnoBoy
Free Windows Admin Tool Kit Click here and download it now
February 4th, 2009 2:03am

Dear customer: install adsiedit.msc tool which located in Windows server 2003 setup CD-ROM \setup\tool folder and open it, navigate to the following location: DC=<domain>, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=<Organization>, CN=Administrative Groups, CN=Exchange Administrative Group, CN=Servers, CN=<CAS Name>, CN=Protocols, CN=Autodiscover, CN=<CAS Name> Right click CAS Name and select properties, click attribute editor, select serviceBindingInformation, send the screenshot of it to me for analyze. For more information about autodiscover, please refer to the following article: White Paper: Exchange 2007 Autodiscover Service http://technet.microsoft.com/en-us/library/bb332063.aspx Thanks for your cooperation. Rock Wang - MSFT
February 4th, 2009 4:23am

Maybe I am stupid, but the paper starts with step 1 as:"Outlook 2007 sends a Lightweight Directory Access Protocol (LDAP) query to Active Directory looking for all available SCP objects."How does it determine the Active Directory server to query for the SCP objectsfor an Outlook Anywhere client that is not joined to the domain?This presupposes that the client somehow knows what server to query (domain Catalog Server? Autodiscover server?) and its domain- I want to know how it knows the name of the server to contact and what its domain is. As far as I can tell, the paper never says.It seems to my feeble brain that there is a step missing in all of this. Jusg for jun I did a search of all of the Outlook related files on an Outlook Anywhere client for the domain it is mistakenly trying to contact just to see if some configuration file somewhere has that in it - nothing found.SnoBoy
Free Windows Admin Tool Kit Click here and download it now
February 4th, 2009 4:42am

Dear customer: When Outlook 2007 is started on a client that is not domain-connected, it first tries to locate the Autodiscover service by looking up the SCP object in Active Directory. Because the client is unable to contact Active Directory, it tries to locate the Autodiscover service by using Domain Name System (DNS). In this scenario, the client will determine right side of the users e-mail address, that is, contoso.com, and check DNS by using two predefined URLs. For example, if your SMTP domain is contoso.com, Outlook will try the following two URLs to try to connect to the Autodiscover service: l https://contoso.com/autodiscover/autodiscover.xml l https://autodiscover.contoso.com/autodiscover/autodiscover.xml For Outlook to be able to locate the Autodiscover service by using DNS, there must be a host record in DNS for the Autodiscover service that maps the entry point, or public IP address, to the Client Access server where the Autodiscover service is hosted. Please double check whether you add a host record in DNS for the Autodiscover service. Rock Wang - MSFT
February 4th, 2009 6:28am

Autodiscover.tees.tamus.edu is an A record - you should be able to do an nslookup on it and get the IP address. I can from my ISP.SnoBoy
Free Windows Admin Tool Kit Click here and download it now
February 4th, 2009 3:43pm

Dear customer: Please try to add autodiscover.tamu.edu A record for the Autodiscover service and check the effect. If anything is unclear, feel free to let me know. Rock Wang - MSFT
February 5th, 2009 9:13am

I cannot add an A record for tamu.edu - that domain is at Texas A&M University and is the entire universities domain - over 49,000 students. Even if I could, there would be a lot of angry IT administrators across the University - most of them having to do the same thing I am doing to get their autodiscover problems solved. I will write up what I did to fix my machines and post it here today- surely there are a number of administrators that are facing this issue besides those of us at Texas A&M. I have interfaces with a number of my fellow Exchange administrators and they are having or will have this issue as they roll out Exchange 2007.SnoBoy
Free Windows Admin Tool Kit Click here and download it now
February 5th, 2009 4:02pm

Dear SnoBoy, Based on the conversation, your internal domain name conflicts with Texas A&M Universitys domain name. Is it right? If so, I am afraid that we have no better way to fix the issue except to modify XML file. Rock Wang - MSFT
February 9th, 2009 6:21am

What I did to fix the problem was to create this XML file (server name obfuscated): <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"><Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"><Account><Action>redirectUrl</Action><RedirectUrl>https://CAS_server.tees.tamus.edu/autodiscover/autodiscover.xml</RedirectUrl></Account></Response></Autodiscover>and named it tamu.edu.xmlAnd copied it the the directory (assuming x86 OS):c:\Program Files\Microsoft Office\Office12\OutlookAutoDiscoverTHen made this registry modification:(actual autodiscover.reg file I created after manually adding this key) Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover]"tamu.edu"="C:\\Program Files\\Microsoft Office\\Office12\\OutlookAutoDiscover\\tamu.edu.xml"Manually adding this key, you would not have the double backslashes.TAMU.EDU is the domain that Outlook was trying to use instead of our actual domain for our site. Essentially I am fooling Outlook into using the correct autodiscover server.SnoBoy
Free Windows Admin Tool Kit Click here and download it now
February 9th, 2009 5:20pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics