One more thing to remember when troubleshooting free/busy issues (EwsAllowOutlook and similar)

We often joke with my colleagues about our age that ​we need to take our ‘old-man’ pills to treat our forgetfulness (Our age is actually pretty young compared to what the average age of IT experts is in other countries). Well, there is definitely a reason in my case…

Here’s how the story went. Some time ago I noticed an issue with the getting free/busy info for my O365 mailbox. Since I’ve been dealing with such issues for years now, I did the standard troubleshooting, found nothing wrong and forgot about it. The process repeated itself few weeks later, when I noticed the same issue on my work PC and I suddenly realized that I might be facing some real problem. So I finally decided to tackle it, and was baffled. Nothing seemed to explain the issue, and even after extensive research on the internet I was still not able to resolve it. I was almost convinced there must be something wrong with the mailbox itself, or even the whole tenant I am using. So I reached for help on OTN, TechNet forums and raised a ticket with O365 support. Here’s the summary I put there:

I have a very annoying issue with my personal email account, which I cannot seem to tackle on my own.

It seems that I have some issue obtaining availability info and/or MailTips. However, AutoDiscover works perfectly fine, as does the EWS test from ExRCA. Still, on multiple machines in multiple network locations I am unable to see MailTips, check/configure OOO from Outlook, or see availability info in the scheduling assistant. And vice versa, on the same machines, other accounts work just fine.

What’s even more interesting, I CAN see the availability info in the calendar of the other person. It even works OK for FEDERATED free/busy. If I look in the scheduling assistant however, I am greeted by the good old ‘No free/busy info can be retrieved’ message. Another interesting moment is that in OWA, I CAN see the info in the scheduling assistant, again both for same tenant and federated.

If I look from the other side, users cannot see my availability info in either the shared calendar or the scheduling assistant. But again, they CAN see the info for another mailbox in both situations, even for a federated sharing.

I’ve tried everything I can think of, permissions, profile recreation, Online mode, another machine, another network. ExRCA works fine, OffCat doesn’t find any issues, CalCheck doesn’t report anything useful either.

It doesn’t really cause me any trouble to be honest, but it annoys the heck out of me 🙁 The only thing I have not tried is to move the mailbox to another database, so I will bug the O365 support guys until they agree to do so 🙂 Any other ideas welcome of course, I hope I have missed something in my troubleshooting.


So I posted this and waited for people to point to something that I might have missed, or enforce my suspicion that the issue is indeed ‘server-side’. Surprisingly, I received a call from Office 365 support engineer regarding this issue on a Sunday afternoon (!), and we agreed to provide him additional troubleshooting information. Later that day I was collecting output from various PowerShell cmdlets and Outlook logs. I even configured my profile on a VM running Outlook 2010 to take a look at the availability service logs (@Exchange PG, why did you remove those with 2013?), and they gave a useful hint:

Response error code: 0x80004005 HTTP status code: 403

And then I finally found it! The cause was of course my own stupidity – being the curious type, I always test stuff with my own mailbox and Office 365 tenant and later forget about them. The same thing happened in this case as well. I’ve had the EwsAllowOutlook setting configured to $false on the organizational level. I did this to test a solution for one of our clients few months back, and then the memory of it went into oblivion. The issue was finally solved and I was quick to close the case before having the engineers laugh at me 🙂

So, for those of you that skipped the announcement of the EWS controlling features with Exchange 2010 SP1, here’s a reminder. Several settings were introduced that allow the administrators to control EWS for individual users or on the company level. Here are the settings in question:

EwsEnabled
EwsAllowOutlook
EwsAllowMacOutlook
EwsAllowEntourage
EwsApplicationAccessPolicy
EwsAllowList
EwsBlockList

Most of them are self-explanatory, and detailed information on each of the parameters can be found in the help for Set-CasMailbox and Set-OrganizationConfig cmdlets. Yes, you can only modify those via PowerShell.

So, next time you are faced with ‘unexplainable’ issue with MailTips, free/busy or OOF, remember that idiot from that blog site that messed up the EwsAllowOutlook setting 🙂

This entry was posted in Exchange Online, Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *