Exchange 2007 autodiscover quit working after last COA

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: out of office assistant for Office 2007 and Office 2010

It produced this output: every user quit working after last certificate update

My web server is (include version): Exchange 2007

The operating system my web server runs on is (include version): SBS 2008 (not R2)

My hosting provider, if applicable, is: none

I can login to a root shell on my machine (yes or no, or I don’t know): yes, I’m the admin

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): DNS management is through the Network Solutions manager

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): sorry, cannot recall… because this is SBS 2007, I had to use a really old version of whatever it was… but it has worked, and continues to work, flawlessly… let me know if this is needed, and I’ll do the best I can (I have to because of the retired ACMEv1 change due in a few months anyways)

Here’s the deal. With the install of the Feb 8 certificate, it appears that ALL of my users can no longer use their Outlook (primarily Office 2007 and 2010) Out of Office assistant function. All users are getting a “cannot connect to server” error.

All users connect to Exchange through HTTP. (Note: I changed one user to connect directly to the Exchange server internal IP, but the error remained.)

OofO assistant has worked flawlessly until the latest certificate. (Note; there have been no changes to the Exchange server since the last restart in October 2019… so I know that wasn’t a problem.)

I have used the Microsoft Remote Exchange connectivity test suite, and it passes (obviously: all users can still send/receive emails) using the SRV record (i.e., via DNS at Network Solutions).

I have tested local autodiscover on the Exchange server, and it too passes.

But after a dozen hours of troubleshooting… and “trying stuff”… I just this morning realized the confluence of the new certificate date, and the first user informing me they were having and issue.

The latest cert’ date is Feb 08 to May 08, and the first users informed me there was a problem with Outlook native Out of Office on Feb 13… and in investigating more fully starting Fri Mar 6, I realized the extent (i.e., all users).

NOTE: I had long ago created an Outlook Web Access bookmark for all users to easily use the OWA Out of Office settings option. I also noted that link no long worked. (I solved that problem through editing all user host files and adding a line to point directly to the server IP address… and coincidentally I’m in the process of creating new mail profiles using the server IP instead of HTTP, although that change has NOT fixed the “cannot connect to server” issue.)

It is difficult to know for certain, but from what I can see, your site only provides access via 4 weak ciphers (all using SHA1):

You might do better by including some more ciphers (with GCM and SHA2).
Have you tried using IISCrypto (free tool) to configure more allowed ciphers?


Thanks for your response.

I’m familiar with IISCrypto (it’s installed on this server), although I haven’t used it for much more than testing.

What I’m trying to understand is why the only change on the aging IIS7/Exchange 2007 server environment since last October (the server had not been patched or restarted since October 2019) - where the only environmental “change” is the Feb 8 COA renewal - would have caused Outlook’s native Out of Office assistant to [seemingly] simultaneously fail for every user.

I can’t see where I’m barking up the wrong tree here…

We have a fairly fixed [business] user server (server 2008 AD) and user (mixed W7 and W10) environment.

I am aware of any and all significant systemic changes… there simply were no changes at all previous to the first user asking for help with the issue (for the first reports of a problem beginning Feb 13, I thought it was just some glitchy thing, and had them use Outlook Web Access out-of-office messages).

Note: Users are not having issues connecting via HTTP or via local IP to Exchange services with PCs or mobile devices from onsite or offsite. Emails are being delivered and sent just fine. Everything had been working perfectly for every user since the change to a new ISP in March 2019.

But from extensive testing beginning early last week (Mar 2) , I realized that every user’s Outlook native out-of-office assistant was experiencing the same error: your automatic reply settings cannot be displayed because the server is currently unavailable. Which is a pretty ridiculous error message on its face, since there are no connectivity issues for anyone on any local or mobile device to the Exchange server… and how would a PC whose mail profile is via direct connection to the server mail services through a local LAN IP even be “not available” when emails are working perfectly?).

It was only Sunday morning (Mar 8) after trying dozens of suggested fixes (including server, workstations, and Internet DNS) and testing that I finally realized that the issue was systemic, and started looking for any changes to our network environment.

And finally realized the only thing that could be considered “different” (for a server that hadn’t even been restarted since October 2019) was: the Feb 8 COA renewal.

So I guess what I’m really asking here, is: was there something different about the Feb COA renewal or cert’ that might have changed something? Or anything?

I do know that the LetsEncrypt sent me a warning email on Feb 18 that “…, the software client you’re using to get Let’s Encrypt TLS/SSL certificates issued or renewed at least one HTTPS certificate in the past two weeks using the ACMEv1 protocol”. And that was the only thing different I’ve seen about the COA renewal process during the past year.

… so was there some kind of change that threw a spanner in the works that would have somehow affected my install script? Anything?

(I had to futz around quite a bit last year to get scripting to even work with IIS7 in the first place lol. I still don’t know what hoops I’m going to have to jump through to get this old server to work with ACME v2 sigh.)

Thanks again for taking the time to read through a definitely TL/DR subject.

1 Like

I don’t work for Microsoft, so I can’t say with any certainty what has changed there.
I do know that TLSv1.0 & 1.1 are being deprecated at this time and that may have a lot to do with this issue. Which is why I asked for you to use IIScrypto to add newer ciphers.


Hi @brd

a certificate is a certificate. There are not two different Letsencrypt certificates last year (or this year, january) and this year, february.

So it’s nearly impossible that the new certificate is the problem.

May be some Microsoft patches. May be port 80 is blocked, so OCSP checks don’t work.

May be some browser updates. You have really weak cipher suites.

And it’s possible that clients block SHA1 signatures.

Check, if you can find a more specific error message.


The server was patched in 2017 to TLS 1.2.

(If I recall, disabling TLS 1.1 has a deleterious affect on various features in SBS 2008… I can’t recall specifically what those were… nor if they were vital to the Exchange and IIS functionality, but I’ll look again… the problem may have only been Sharepoint daily reports or something.)

I’m not sure how to add newer ciphers.

(I mean, I know how to click stuff in IISCrypto lol, but I’d rather not start wading through web info on what those various changes do until I have a handle on why something - whatever it was - broke on an otherwise static system.)

If you have a link to suggestions/explanations of the various minimum ciphers, I’d appreciate it.

1 Like

Thanks for reply.

It’s fairly easy to know what it isn’t from your suggestions.

There are not two different Letsencrypt certificates last year (or this year, january) and this year, february:
Thanks for the confirmation. The validation process used by Microsoft Remote Connectivity Analyzer didn’t show any cert’ issues (but “what do I know” when it comes to certs… practically nothing lol).
Question: Do you know if the ACME version testing may have changed anything on the server’s local environment? (The email about the testing that LetsEncrypt sent out was “new”, as in I’ve-never-received-that-notice-before, and have no idea how they determined the use of ACME v1.)

Microsoft patches:
none on the server from October 15? 2019 through Mar 6 2020
none on W7 PCs (obsoleted in Jan 2020, so no new patches)
none recently on the older 2007/2010 Office suites used onsite

browser updates:
none - IE9 on server (the server is never used for browsing anyways)
none - IE11 on all PCs (all OWA - Outlook Web Access - testing done via IE11) Note - IE9/11 obsoleted
I’m sure Chrome and FF are reasonably current on various PC’s, but updates to those wouldn’t affect IE

Port 80:
open (checked with GRC’s Sheilds Up) ditto, port 25 & 443
Note The usual panoply of SBS 2008 ports are being port forwarded through various NAT’ed in house routers. Regardless, there’s been no changes to the router environments.

weak cipher suites:
Yeah, rg305 has mentioned it lol. I’ll work on that. Regardless, they were working just fine prior from Mar 2019 through to Feb 08.

it’s possible that clients block SHA1 signatures:
I’ve no idea how to test SHA1 on client PC’s, but I’ll look it up. Thanks.
Regardless, there was no problem on Feb 6 (I just got a date confirmation from a user), the cert’ update was Feb 8, and Feb 13 two users reported the issue

Check, if you can find a more specific error message:
Sadly, that’s the only result message of OoO assistant that Outlook is throwing. There’s nothing in the various logs on PCs or the Exchange server that seems out of the ordinary.

1 Like

JuergenAuer -

I screwed up making my response a reply to you, and after I deleted it and tried to specifically reply to you, I got both a “too similar to previous post”, and a 24-hours-to-delete warning.

I saved the reply to Notepad before deleting it here, so I’ll try again re-posting again later.

In the meantime, thanks.

UPDATE: LOL, I’m still learning this forum. And I just learned to “undelete”. Whoo-hoo.

1 Like

I don’t know. But the certificate has nothing to do with the ACME protocol. A certificate doesn’t know if it is created with ACME v1 or v2. These are different things.

Really? No update? That’s bad.


IISCrypto can allow you to ADD ciphers to the supported list WITHOUT removing any existing ciphers.
It will also allow you to (re)order the ciphers.

I would suggest taking a screenshot of the current settings and then add as many as makes sense.
And order them in a way that also makes sense (like: strongest to weakest).
Rinse and repeat (and reboot) until it works or there are no ciphers left to add.


Thanks… I wasn’t 100% sure, and your definitive response meant I started digging into the problem with the certainty that “it can’t be an issue with the cert’ renewal”.

The date had to be purely coincidental.

LOL. Not as bad as it’d ordinarily be: I’m the only one at that particular office who still uses IE11, and - because it is “locked”, due to EOL - I only use it for testing things like this.

My W7 users almost all use Chrome a couple of FF users), and the W10 users divide their choice mostly between Edge and Chrome. Those are current, supported, browsers. (And none of them operate under admin privileged user accounts either. So I think we’re good.)

(OTOH, I use whatever tool works best lol. After almost 36+ years in IT, if it works, I don’t care what flavor it is.)

Thanks again for your help JuergenAuer.

Well, kind of.

Your clarification forced me to dig back a month ago to see if there had been any other, unique, rare, systemic occurrence.

And… yeah. There was.

And that “event” was a biggie. How I’d overlooked it was… well, I was very sick with the flu for most of Feb, so my memory of the month is not exactly sharp lol.

On exactly the same day as the cert’ renewal - and yeah, I’d completely forgotten - our new website went live. With a new hosting provider. And new IP pointers in the A records.

I’d changed not merely the www A record, but also the @ and [asterisk] A records.

And as it turned out in testing yesterday, the @ A record is vital for both autodiscover and the www hosting provider.

So. If I change the IP to point to one, the other breaks…

So… a real cluster fark. Aargh.


Anyways. I’m getting together later today (hopefully) with the web developer to see if we can figure out a work-around.

Aargh. 30+ hours of troubleshooting down the tubes. My bad.

Thanks again!


Thanks again for your help rg305.

If you check out my reply to JuergenAuer, you’ll see the details of why this turned out to be my bad (I’d completely forgotten that I’d changed DNS Records on exactly the same date as the cert’ renewal… so while the date was purely coincidental, it was a systemic, “affects all users”, cause. It can suck being old AND getting sick. Sigh)

But I’d like to give you a shout-out for pointing out that I really need to put some time into strengthening the depth of the ciphers here.

I’ll be putting your suggestion to good use over the next several days at several client sites.

So your input was greatly appreciated, is actionable, and I’m sure will prove beneficial.