When you read the headline, you’re might thinking “Oh no! Another post about this topic!”. But I think this post is worth reading as I’ll go deep into details.
Over the last months I have seen an increase of questions from various teammates and other teams in regards of the Exchange Online Remote PowerShell Module. The questions where mostly related to connectivity issue and prompts for re-authentication as PSSessions got into a broken state.
Also the fact that in some areas a proxy needs to be used, might be confusing as well as the question what to do if you have a service account or want to use the module in ISE.
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.
Recently I had the need to gather some detailed information about an ongoing service degradation.
I remebered fellow MVP Vasil Michev and his blog post here. I like the fact that we now have an insight how many users are affected.
MVP Frank Carius wrote a more detailed post about the API here.
A while ago I wrote a script, which helps me troubleshooting calendar issues:
Troubleshooting calendar items
Lately I wanted to improve the script and needed to translate two properties. These properties reflect what action a user has taken on and how a meeting object has changed:
Both properties are specified by a bit field.
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.
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.
There are several methods to achieve this. One for example is the script from fellow MCM/MCSM Thomas Stensitzki Purge-LogFiles.ps1 (read more about it on his post here).
You can run the script manually or create a scheduled task.
But when you are using Desired State Configuration (DSC), why not add the task to purge those files to your MOFs?
A while a go I wrote the inital 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.
Update May 30, 2016:
Many thanks to fellow MCM/MCSM Thomas Stensitzki, who added some code for nicer format and preview when sending the output as e-mail:
The script will query multiple performance counters from Exchange servers in a given AD site.
Default counter collection
MSExchange RpcClientAccess\User Count
Shows the number of users connected to the service.
MSExchange RpcClientAccess\Connection Count
Shows the total number of client connections maintained.
RPC/HTTP Proxy\Current Number of Unique Users
Shows the number of unique users currently connected to a back-end server via RPC/HTTP.