End of last year I run into this issue along with another one related to LSA protection and code integrity check (which will be covered in another post).
This issue might be rarely, but you can run into even your environment is not large and even you followed the Preferred Architecture (PA) for Exchange and used the calculator. If you have this issue, it can have serious and unforeseen consequences and impact your setup.
If you want to read more about: I wrote about this on a guest post on the ENow blog.
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.
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:
Update November 11, 2018:
There is a new version available on GitHub. You can find the script and any new version here:
I added a bunch of new features and improvements:
- UseASPDOTNET: As the Exchange performance counters are not reliable, you can now query IIS performance counters to gather current requests
- IISMemoryUsage: This will gather the memory usage of the application pools (we had some issue with memory leaks).
- UseCIM: As you’ll get only a generic name when you use IISMemoryUsage (performance counters doesn’t know any names of application pools), you can use CIM for gathering the data
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.
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.
Recently I run into the problem where Exchange return with the error:
“An Active Directory error 0x51 occured when trying to check the suitability of Server…”
Weird thing this happened not for all commands. It was somehow randomly, but this caused several issues:
- prompt for credential (which was the most ugly side effect!)
- errors in scripts
- CmdLets didn’t return all values
This post is about my personal journey with a cross-forest migration.
When it comes to account migration there is no way to do so without sIDHistory. It would be really hard to have a smooth migration without.
By using this attribute a end-user most likely won’t experience any impact…..unless you start doing a cleanup of this attribute.
In terms of Exchange users might see something like this
But what’s behind those issues and how could you mitigate this? I was part of a migration, where those issues popped up and I’m going to describe how you could determine possible impact for end-users before it happens.
In my previous post I described how to extract data from the IIS logs for one or multiple user/users or device/devices. This post is more about analytic or statistic tasks you can perform with this script.
There are the following reports available:
This is the first part of a serie about troubleshooting Exchange using LogParser. I bet all of you know the situation, where users complain about connectivity issue. But how do you troubleshoot?
In this post I will cover how to parse IIS logs. There are a few great tools out there to parse those logs:
But they have one big drawback in common:
You need to collect the logs from all servers into one place in order to parse them. If you have only 2-3 server that might me okay, but what when you have more than 10, 20 or 30 server? It also takes time to copy the logs depending on your settings what you are logging. Easily a log could be larger than 1GB.
Wouldn’t it be great to be able to parse the logs without the need of copying them?
Well here is the solution:
Sometimes you want to get Exchange server objects from AD without having the need to install management tools. For those cases the option to get your objects with just a search using LDAP is your friend.
A simple filter will return all existing Exchange server:
But what when you want server with a specific role in a specific AD site?