This is a rather obscure one and requires a very limited set of circumstances for this problem to affect your clients in this way; however, I believe it’s worth noting:
· You’ve already properly configured the Exchange service URLs
o Exchange 2010: http://technet.microsoft.com/en-us/library/bb124251.aspx
· A few (or even a good percentage) of your users are having difficulty setting their Out-Of-Office messages or viewing the Free/Busy scheduling data when scheduling calendar appointments
· You have, at one point in time, used the Microsoft Online Services Sign In client application in order to get folks connected up to Microsoft’s BPOS solution
As alluded to above, you’ll receive the following error messages when attempting to set your Out-Of-Office:
“Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.”
…or when you try to view the Free/Busy data on other calendars (other people and/or resources/rooms):
“No free/busy information could be retrieved. Your server location could not be determined. Contact your administrator.”
If you hold down the Ctrl key and right-click on the Outlook icon, you can “Test E-Mail AutoConfiguration…”:
…and when you un-check “Use Guessmart” and “Secure Guessmart Authentication” and hit the “Test” button, you’ll get the “Autoconfiguration was unable to determine your settings!” error message shown below:
Please note that the standard setup process of creating a new Outlook profile will work without issue; however, it’s only after you set up the profile that Autodiscover (and, by extension, the Exchange Web Services and/or Availability Service) goes to hell in a handbasket.
The following registry entries are the cause of the issue:
What these registry entries are effectively doing is telling Outlook to “not even try” Autodiscover, and to instead prefer a local XML file to tell it how to connect to your Exchange server.
You’ll definitely notice this if you do a two-sided packet capture on a “problem” machine and the Exchange server simultaneously while running the “Test E-Mail AutoConfiguration…” utility—there will not be any traffic from the Outlook client on the “problem” machine to the Exchange server or any of the usual autodiscover URLs. That’s because the registry entries above are preventing Outlook from even going out to check those URLs.
So, you might be asking yourself, “Well, how in the name of Chuck Norris did those get there?”
The answer is: the Microsoft Online Services Sign In client application… you know, this guy:
Let’s check the registry branch before I use the Microsoft Online Services Sign In client application to configure a new Outlook profile to connect to BPOS:
(there are others listed, these are just a sample)
Notice that all keys/values are of type “REG_SZ” (string values) and point to various XML files in the following directories:
· Office 2007: C:\PROGRA~1\MICROS~1\Office12\OUTLOO~1\
· Office 2010: C:\PROGRA~1\MICROS~1\Office14\OUTLOO~1\
Again, prior to using the Microsoft Online Services Sign In client application to configure Outlook, there are no REG_DWORD values in this registry branch.
Now let’s use the utility to configure Outlook. If you’re doing this the first time (i.e. you’re just installing the client application), this will be done automatically. If you ever need to go back and re-do this step, you can do it from Options > Advanced Options > “Reconfigure my desktop applications”:
You’ll select only Outlook and click the “Configure applications” button (you will have to exit Outlook):
…and once that’s done, presto-change-o, you have some shiny new REG_DWORD values like the ones I listed earlier:
You’ll also notice another shiny new REG_SZ value for yourcompany.microsoftonline.com:
Just for giggles, let’s look at what’s in this XML file:
So, it would appear that Microsoft is “hedging their bets” in regards to how autodiscover actually works, even though I have no idea why they would need to do this, seeing as though they already have a CNAME record for autodiscover.mycompany.microsoftonline.com that gets me to the right place:
After working with Microsoft support, they referenced a cached (read: suspiciously deleted from the KB) article that addresses these exact registry entries. Why this KB article was removed I’m not sure. See the attached PDF for the full article, but the key parts are detailed here (emphasis added):
Consider the following scenario:
o The e-mail environment in your organization uses the following programs:
§ Microsoft Exchange Online
§ Microsoft Exchange Server 2007
§ Microsoft Office Outlook 2007
o You have a mailbox in Exchange Online and a mailbox in Exchange Server 2007.
o You have the same primary Simple Mail Transfer Protocol (SMTP) e-mail address in Exchange Online and in Exchange Server 2007.
In this scenario, you experience the following issues:
· The AutoDiscover feature that Outlook 2007 uses does not configure Outlook 2007 for the Exchange Online environment.
· The AutoDiscover feature reverts back to Exchange Server 2007. Additionally, you cannot access e-mail when you use the Outlook 2007 client.
Note: These issues usually occur during the Exchange Online trial period or during an e-mail coexistence period between Exchange Online and Exchange Server 2007. When the Exchange Server 2007 mailbox that you use is fully migrated to the Exchange Online environment, the Exchange Server 2007 mailbox is deleted.
Interestingly, after checking our partner BPOS account (https://admin.microsoftonline.com), I see that neither our primary SMTP domain nor my personal address have our actual @mycompany.com domain set as primary… instead, my primary domain is @mycompany.microsoftonline.com:
…and here’s my user account:
So that still begs the question, “Why would Microsoft change the registry entries when I use the client application if my e-mail domain in BPOS (@mycompany.microsoftonline.com) isn’t the same as my actual primary SMTP domain on my Exchange server (@mycompany.com)?”
I decided to look for a newer version of the client application… as we can see, I’m running version 1.0.1427.0040, and the latest available is 1.0.1442.000 released on 4/25/2011 (at the time of writing). The download page for the newest version is located here: http://www.microsoft.com/download/en/details.aspx?id=11859
So, I tried an experiment. I deleted the “REG_DWORD” keys from the registry branch mentioned earlier (HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover), uninstalled the old client application, installed the new client application, and attempted to have it configure Outlook once again.
So, I reckon that this will continue to be an issue for as long as we continue to use the Microsoft Online Services Sign In client application. Hooray!
The Quick-N-Dirty Fix
Because the registry entries are in HKEY_CURRENT_USER, I can’t easily update these en-masse using our centralized management system, as the HKEY_CURRENT_USER designation is dependent upon who is logged in at the time.
The quickest way to fix this, I’ve found, is to add the following lines to all of the necessary logon scripts (which run in the correct user context of the currently logged on user):
echo Deleting errant registry entries that prevent Autodiscover functionality...
echo Office 2010...
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v PreferLocalXML /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpRedirect /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpsAutodiscoverDomain /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeHttpsRootDomain /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeScpLookup /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeSrvLookup /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover /v ExcludeSrvRecord /f
echo Office 2007...
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v PreferLocalXML /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpRedirect /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpsAutodiscoverDomain /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeHttpsRootDomain /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeScpLookup /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeSrvLookup /f
reg delete HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover /v ExcludeSrvRecord /f
echo Errant registry keys (if they exist) have been deleted!
It appears that the registry entries, once deleted, remain deleted until such time that the user chooses to “Reconfigure my desktop applications” (again, per the screenshot below):
So this is definitely something to be aware of… if a user installs the client application and can no longer access his/her Out-Of-Office settings and his/her Free/Busy data, and assuming that you’ve added the aforementioned lines to everybody’s logon script, just tell him/her to log off and log back on again and the problem should be fixed.
For the record, I’m leaving this as part of everybody’s logon script until we’ve transitioned our partner account to Office 365. :-)