Microsoft Graph is gaining more and more attention by developers. Also due to the fact of deprecation of Basic Authentication (please read more about this here!), many are shifting to the new protocol.
I welcome this change, but what I just came across is something I don’t like:
A colleague opened a ticket and complained about something is modifying his calendar items. So far, I saw this an easy task and used my Get-CalendarItems script, but I had to learn not everything is logged, when Microsoft Graph is used…
Update August, 12 2020
I got word that the multi-geo issue will be addressed. No ETA as of now. But at least for calendar items a fix is currently rolling out. Now the used AppID is logged:
The only drawback: Looks like every component team is doing their own thing. That’s why we don’t see proper entries on the item in the Sent Items folder.
Over the last months a lot of changes needed to be addressed. The script was intended to extract data from the IIS logs. With PowerShell in combination with LogParser it did a great job. But different versions of Exchange, changed infrastructure and multiple versions of Exchange ActiveSync protocol demanded an update to fulfill these needs.
The latest version focused on code improvement and added support for the new version of Exchange ActiveSync protocol v16.1 .
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:
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.
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.
Starting with Exchange 2013 an Exchange server is logging a vast amount of data. As not every installation has enough space or there is a compliance rule, which forces you not to keep log files older than x days, you might need something to delete these files.
Since Exchange 2013 the logging on an Exchange server was dramatically increased. Note: This doesn’t mean that other logs like IIS, HTTPERR, RCA and EWS are not important anymore. HttpProxy logs are only a subset of the logging!
By default the HttpProxy logs for various protocols can be found in <exchange server installation directory>\Logging\HttpProxy\<protocol>
As you can see there is for each protocol a dedicated folder.
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
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.