There are many posts and a few KB articles related to legacyExchangeDN and X500 addresses. Here some a few examples:
These are only a few examples. But there is even more: Calendar items and especially recurring meetings are highly depending on legacyExchangeDN.
In a recent M&A scenario the decision was made to perform a cleanup of X500 addresses, which definitely caused quiet a number of tickets.
Currently I see an increasing number of reports about missing body of meeting series. As most of the series are Skype for Business and contain the dial-in information, this is really a bad end-user experience. Imagine you want to join the meeting and have no dial-in information or the attachments are gone.
My first thoughts were that this is a Skype for Business only issue or related to Exchange ActiveSync. But this time it turned out it’s not. After analyzing of several cases, it came down to an Outlook for Windows only issue in a delegate scenario.
The issue was resolved in Version 1706 (Build 8229.2103), which is the July version of the Current Channel. Please be aware about the changes to Office 365 ProPlus update management! You can read more about the changes here. Either way, when you are on Deferred or Semi-Annual Channel you have to wait for this 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.
Recently I had an interesting issue related to a delegate scenario in conjunction with categories:
A delegate was not able use categories in a shared mailbox. It was just greyed out. I knew you need to have at least Reviewer permissions on the shared folder in order to work with categories. So I thought that would be an easy one and I was going to tell them how to fix this…..but before I checked the folder’s permissions and realized that the delegate had Publishing Editor assigned.
After some testing we decided to grant Owner permission, but the delegate were still not able to work with categories.
Why was it still not working, even with Owner permissions?
In the past few month the number of incoming request related to calendar issues increased. There are several reasons for this like message body truncation, Richt text or HTML formated messages get converted to plain text. Those are most likely related to iOS devices and there is a KB available for this here.
But not only iOS is causing issues. Especially when it comes to delegate scenarios with more than one delegate and when all of them have multiple clients with different versions (e.g.: Outlook 2010/2013, Outlook for Mac and a whole bunch of mobile devices).
To get to a point: Just ignored the following recommendations
But how do you troubleshoot those issues? There are several techniques and I will cover some of them in this post:
In this update I fixed a bug, which caused the script to loop, when more than 1000 items were found. I also improved the performance by using ConvertIds rather than ConvertId method. With this only one EWS call for all items instead one for each is made.
Just have a look at the section for the script here.
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….