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 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 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.
Looks like this is somehow an ongoing task:
Narrow down Outlook prompts for credentials. And it seems a new root cause comes into play each time. So like in the latest issue after I upgraded to Click-to-Run Office 2016. After my upgrade and on the first start I got immediately prompted for credentials. First thought was this is related to my machine or account. But my co-worker also got it and we could reproduce it constantly everytime you logon to the machine after a complete logoff.
Update June, 2017:
Good news that this particular issue is also fixed for Outlook 2013 already in October, 2016. Somehow I missed this one, but here it is:
You need to apply KB3118367.
Update September, 2016:
This issue is fixed and currently available in the September update in the First Released for Deferred channel:
“Fix an issue where, when connecting to Exchange Server 2013 that is enabled for MAPI/HTTP, the user is prompted for credentials instead of being silently logged in with the user’s desktop credentials.”
The good news is that this is related to 2 consecutive failed requests. The bad news is, I found the same issue in Outlook 2013.
This was confirmed by the Outlook team and currently work on a fix for Outlook 2013 is ongoing.
You might have an LOB application at your company that uses IMAP to pull data from specific mailboxes. In order to access those mailboxes you don’t need necessarily to have a mail-enabled user or a mailbox assigned to the account. In general it was enough to grant FullAccess on the shared mailboxes to the account, which might be a service account.
Well, it was sufficient. This changed with Exchange 2013/2016.