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.
In the past month I had to troubleshoot a lot of EAS related issues. This is always a complex process and you as an administrator have to collect a lot of data and provide them to your vendors. After providing these, you often feels like a ping-pong ball. Especially when multiple vendors are involved.
Based on two examples I want to explain, how I was able to proof some misbehaviour of EAS clients. Meanwhile both have been acknowledged by the vendor as a bug:
With iOS 10 this feature can trigger a meeting forward to multiple recipients using SmartForward command.
When a user marks an item read or unread, the flag does not get synced to the mailbox.
Update 27.06.2017: There is also a fix in KB4012108 related to this issue. It’s not exactly the issue I’ve found, but a similar one. The details can be found in KB4024649.
For troubleshooting I used the following tools:
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.
There are always issues with appointments, meeting requests and meeting series with delegates or mobile devices. Sometimes appointments disappear, got shifted or updates don’t make it to all involved parties.
In the past I opened a case with Microsoft and get these issues analyzed. But this is very time intensive and often the affected users are VIPs, which want to have as quick as possible a report about what happened.
I spent some time on this topic and I wrote about it here. I also wrote my script to pull all the relevant data from mailboxes in a way, which is much faster and has more capabilities. You can read more about this script here. This script was recently updated to translate the properties PidLidClientIntent and PidLidChangeHighlight in a human readable format. You can read more about it here.
In this post I will go through the history of a calendar item. There will be several changes and I will show what happened with each change. I know that this post has a lot of pictures, but to get an understanding what exactly happens, pictures are sometimes a better way to explain something.
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.
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?