Currently I’m upgrading an Exchange 2013 environment to Exchange 2016. In general this upgrade runs very smoothly and is almost seemless for user. It’s a complete different story when you’re coming from Exchange 2010.
So far I got only positive feedback and no issue were reported. Until a bunch of shared mailbox have been migrated.
Users complained they cannot access these mailbox anymore. First I couldn’t reproduce the issue, until I got another important detail:
All these user are using Outlook for Mac and indeed I could reproduce the behavior.
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.
You might have an LOB application at your company that uses IMAP to pull data from specific mailboxes. In order to access those mailboxes you don’t need necessarily to have a mail-enabled user or a mailbox assigned to the account. In general it was enough to grant FullAccess on the shared mailboxes to the account, which might be a service account.
Well, it was sufficient. This changed with Exchange 2013/2016.
It’s been a while since I was troubleshooting prompt for credentials. The last time I was happy to find the root cause and how to fix this (you can read about it here).
Now the same issue seems to come back. But this time it has nothing to do with proxy settings. This time it has to do with KB3114351 and KB3114372 from December 8, 2015.
There were besides security related updates also some major design changes implemented as described more in depth in KB3135145:
- Cloud Based Discovery
- UPN Enforcement for OrgID
- SIP Autodetection from Azure
There are many reasons why you see this error. But last week I learned something new. I had a client, which showed this error in the Configuration Information and also this pop-up
At the same time the MAPI Information was shown with MAPI Status OK. As long as Outlook was running the user had all features, because the client was using the Outlook integration via UcMapi.exe.
First I checked the client for the correct internal and external EWS URLs and that those could be reached succesful.