In the past month I had several times the need for collecting event logs across multiple servers or parsing exported ones from *.evtx files. Get-WinEvent is the perfect Cmdlet for doing this as you can use it for querying both with.
But of course the out-of-the-box experience, usage and output didn’t fit others and my own requirements. Therefore I ended-up in writing a new script.
Continue readingIn my Ignite session with fellow MVP Andrew Higginbotham Troubleshooting Complex Exchange operational issues, I mentioned Fiddler as a perfect tool for troubleshooting also Exchange ActiveSync clients as well as Exchange servers itself.
After this session a lot of people reached out to me and asked me about how to do this. So I thought a write-up would be a good idea.
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 a previous post here, I wrote about a few basic commands, which are useful to quickly gather information about transport component of an Exchange server.
In this post I want to give you a deep dive about it and how you can explore what the CmdLet can do for you as it evolves in each Exchange version and can be very useful.
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:
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.
A while ago I wrote the post Troubleshooting Exchange with LogParser:RCA logs, which describes how you can parse RCA logs using PowerShell and LogParser.
With the new protocol MAPI over HTTP also new kinds of logs were introduced. When it comes to connectivity or performance issues, those logs might help you to find the root cause.
In the past I had to deal with some performance issues, which were really tricky to narrow down. It turned out that the servers spent too much time in Garbage Collection for a protocol used by Outlook clients: MAPI over HTTP.
As this was not obvious and it took some time to identify, but the impact could be extremely critical, I thought it would makes sense to explain what happened and how you can avoid this situation. Continue reading
A while a go I wrote the initial script and post about it here. Due to my experience over the last few weeks and to meet additional requirements it was time to go over the script and extend its functionality. I thought about updating the previous post, but due to the major changes I decided to create this new post.
Many thanks to fellow MCM/MCSM Thomas Stensitzki, who added some code for nicer format and preview when sending the output as e-mail:
There is a new version available on GitHub. You can find the script and any new version here:
https://github.com/IngoGege/Get-ActiveExchangeUsers
I added a bunch of new features and improvements:
Please read the Readme. I have also some posts queued to show the daily usage.
The script will query multiple performance counters from Exchange servers in a given AD site.
Shows the number of users connected to the service.
Shows the total number of client connections maintained.
Shows the number of unique users currently connected to a back-end server via RPC/HTTP.
The clueless guy 