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.
Lately I installed my first DAG with Exchange 2016 CU3 in productive environment. In the beginning it went really smoothly. But after all databases have been created, I realized that databases got bounced around the nodes and a lot of errors in the Event Log like these:
Log Name: Application
Date: 12/14/2016 9:53:07 AM
Event ID: 1001
Task Category: General
Microsoft Exchange Server Information Store has encountered an internal logic error. Internal error text is (ProcessId perf counter does not match actual process id.) with a call stack of ( at Microsoft.Exchange.Server.Storage.Common.ErrorHelper.AssertRetail(Boolean assertCondition, String message)
at Microsoft.Exchange.Server.Storage.Common.Globals.AssertRetail(Boolean assertCondition, String message)
The store worker processes kept constantly crashing.
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
I stumbled across a performance issue for Outlook, which was really not easy to troubleshoot:
Some users, migrated to Exchange 2013, reported very poor performance in Outlook. Switching between e-mails or folders was just horrible. Sometimes they even couldn’t connect to Exchange and they got an error like this:
But not all users experienced this issue. I also had to mention we started seeing this first on Terminal Servers, where cached mode was not available.