With Exchange 2016 a huge improvement in regards of document collaboration with OneDrive for Business was introduced when you have a Hybrid configured.
You can read more about it here:
When I introduced Exchange 2016, I was more than happy to configure and make this feature available to my end-users. But after I run through the prerequisites and steps, I wasn’t able to get the option in OWA and with Outlook I received the following error:
The same happened when I was using Outlook for Mac. As different clients, protocols and servers where affected, I assumed a general issue and started troubleshooting.
Every now and then I hear complaints about Free/Busy information retrieval issues. There are a lot of reasons for such issues, but the interesting part by these issues is that accessing the shared Calendar is not a problem. Only when users set up a meeting and using the Scheduling Assistant, they suddenly see only the beloved hash marks:
Using OWA the user was able to retrieve Free/Busy information using Scheduling Assistant.
And this happens usual to VIPs like the CEO or CIO. So I started troubleshooting with highest priority and found an easy fix.
A while ago we had a special request: For a dedicated AD site, only a subset of users should be able to access their mailbox with Outlook for Windows from outside the corporate network. My first thoughts were this is not possible. I wasn’t aware of any setting to limit Outlook Anywhere or MapiHttp external access on user base.
But we were told by a PFE that there is a way:
Combining MAPI over HTTP configurations and internal or external connections
There is always something new, you can learn!
We did some testing and the results were very promising. So we were able to fulfill the request.
But the description of Set-CASMailbox for the parameter MAPIBlockOutlookExternalConnectivity and the article doesn’t reflect all consequences and soon we received a lot of complains, reports about connectivity issues with devices and applications other than Outlook for Windows.
When it comes to the point to troubleshoot Exchange Web Services related issues, where do you start? When it’s related to F/B requests of Outlook there used to be some client-side logs available. Since Office 2013 not anymore, as these data are all moved into ETL files, which are encrypted. It can be also hard to troubleshoot a Mac client or even cross-org or Hybrid scenarios.
So how can you start troubleshooting?
Starting with Exchange 2010 you will find EWS related logs on the servers and you can easily parse them. The newer the Exchange version is the more information is logged.
I just had another issue with some users in regards of Free/Busy data. The issue, which was reported was that the user is not able to lookup F/B data for some people.
Well normaly this happens when users are smart and start playing with their proxy settings, which breaks their HTTP related traffic.
But this case turned-out to be more interesting….