Microsoft spent a lot of time and is still putting a lot of effort to improve their products and services. But sometimes things can go bad. In this case it’s about the new model of calendar sharing, which can cause trouble and impacts negatively end-user experience.Continue reading
There are many posts and a few KB articles related to legacyExchangeDN and X500 addresses. Here some a few examples:
- “0x80070005-0x0004dc-0x000524” error when a user sends updates to Calendar items that were created before Exchange Online migration
- IMCEAEX non-delivery report when you send email messages to an internal user in Office 365 dedicated
- Inbox rules are disabled after migration to Office 365 Dedicated/ITAR (vNext)
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.Continue reading
This post was lingering around for a long time, but the last weeks showed me it’s time.
Actually I came across this topic last year just before Ignite. But somehow this topic felt into oblivion. To make it short:
It’s all about the number of TCP connections an Outlook Client establishes in a Cached Mode. Especially when it comes to shared mailbox or delegate scenarios.
What is Outlook Cached Mode?
Read more about it here. But what you really want to avoid it something like this:
A while ago I wrote a post about Troubleshooting calendar items. Since then our capabilities improved as Microsoft added more functionality to Cmdlets and I enhanced also my own script (description can be found here).
The intention of this post is to give you a deep dive of advanced troubleshooting similar to my Get-ExchangeDiagnosticInfo post.
The content is as follows:Continue reading
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.
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:
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.