Outlook 2013 Security Update breaks Out of Office for Exchange 2007 Mailboxes


In the past two weeks I’ve had two customer environments come to me with the same issue. Random Outlook 2013 clients are unable to configure their Out Of Office settings. Specifically, they would get an error message when trying to open their OOF settings to set them. Some users had no issue while others got the error. Both environments were Exchange 2007 on latest Service Pack/Update Rollup & had a few users running Outlook 2013; only a few of which were having this issue.


After some searching online I found this thread pointing to a recent (November 12th 2013) Outlook Security Update as the culprit. In my case, after uninstalling KB2837618, rebooting the client, & re-creating the Outlook Profile (a profile repair did not work) then Out Of Office started working again.

In fact, after reading the full KB it appears this is a known issue:

  • If you are using Outlook to connect to a Microsoft Exchange Server 2007 mailbox:
    • You receive an error message that resembles either of the following when you try to configure Automatic Replies (Out of Office): 
      Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later. 
    • You cannot retrieve Free/Busy data for calendar scheduling.
    • Add-ins that use the Account.SmtpAddress property no longer work.

    These features rely on an underlying Autodiscover technology. After you install this security update, Autodiscover may fail for Exchange 2007 configurations. Therefore, Outlook features that rely on Autodiscover will also stop working.

    Microsoft is researching this problem and will post more information in this article when it becomes available.

It appears the reason only random Outlook 2013 clients were experiencing the issue was because not all of them were up to date via Microsoft Update. Of course most Exchange folks will never read all the release notes of KBs pushed to Outlook via Microsoft Update ahead of time. I suppose the answer to an actual admin (which I am not) who complains will be “What, you don’t use WSUS & test every update for Office?” 😀


As Jim Morris pointed out in the comments below, the issue is addressed in http://support.microsoft.com/kb/2850061

New behavior in Outlook 2013 causing certificate errors in some environments


I originally discovered this issue back in early Feb & let a couple people on the Exchange Product Team know about it via the TAP but it seems to be affecting more customers than initially thought so I thought I’d share.

In Outlook 2007 through Outlook 2010 all domain-joined Outlook clients would initially query Active Directory for AutoDiscover information & ultimately find a Service Connection Point (SCP) value that would point them to their nearest Client Access Server’s AutoDiscover virtual directory. If that failed then they would revert to using DNS like any non-domain-joined Outlook client. The order of this non-domain-joined lookup is as follows:



Local XML File

http://company.com/autodiscover/autodiscover.xml (looking for a redirect website)

SCP AutoDiscover Record

Why it ever looked to https://company.com/autodiscover/autodiscover.xml I’ll never really know because honestly I’ve never come across a customer who had it deployed that way; most have https://autodiscover.company.com/autodiscover/autodiscover.xml but I imagine when Exchange 2007 was first being developed they weren’t exactly sure how customers would be implementing AutoDiscover.


The above methods have served us well since Exchange 2007 timeframe but for some reason the Outlook team decided to try & implement some giddyup into Outlook & try to speed up the process. They decided to have domain-joined Outlook 2013 clients query both the SCP values in AD as well as the DNS records at the same time. If an SCP record was found it would still be used but in the event it failed then it would already have the DNS response ready to go. Great idea, however there’s one problem in the implementation.

If Outlook 2013 encounters any kind of Certificate error while doing the simultaneous DNS query then you will receive a pop-up in Outlook about the cert.

I actually stumbled upon this while in the middle of the scenario below:


That’s right, I actually get a certificate pop-up for my lab’s domain name (ash15.com) & not autodiscover.ash15.com like one would expect if I were to have a certificate issue on Exchange.

When Outlook 2013 does it’s simultaneous DNS AutoDiscover query the first URL it tries is https://company.com/autodiscover/autodiscover.xml, which in my lab environment resolved to my Domain Controller, which was also serving DNS, as well as a Certificate Authority. Ash15.com resolved to this server because it’s my internal Active Directory domain name & the name server entry resolves to my DC (just ping internaldomainname.local in your AD lab environment & you’ll see the same thing).

Now because I have web enrollment enabled & am listening on 443 in IIS the server responded. Also, because I did not have a cert installed on the server with ash15.com in the Subject or Subject Alternative Name then it gave the certificate error we see above.


The error is easy enough to get through & it only occurred on initial profile creation but this can definitely prove painful for some customers. Obviously my lab environment is a corner case but there have been several other customers report this issue with Outlook 2013 as well.

Here’s an example scenario.

Imagine you have a public website for andrewswidgets.com hosted by a third-party hosting site & you did not pay for HTTPS/443 services. However if you were to query the website using https then it could respond & obviously not return a certificate with andrewswidgets.com on it (because you haven’t paid for it you cheapskate…). Now imagine you begin deploying users using Outlook 2013 in your internal environment. In the past, they would have found the SCP record that would have pointed them to your internal Exchange 07/10/13 server for AutoDiscover & would have been happy as a clam (one Exchange Product Manager’s favorite way to describe Exchange bliss). However, now they may get a certificate pop-up for andrewswidgets.com when creating a new profile.

There are a couple ways around this. Make sure andrewswidgets.com doesn’t listen on 443, or possibly get a proper cert on your website that is listening on 443. Simply put, just make sure whatever andrewswidgets.com resolves to is something that’s not going to throw a certificate error.

I’ve heard nothing concrete or public but the Outlook team is aware of the issue & listening to customer feedback. I suggest contacting Microsoft Support if your organization is running into this issue.


Also, this KB offers methods to control which AutoDiscover methods are used by your Outlook clients