Exchange 2010 applcation issue

These templates actually use RPC to collect Windows Performance Counters remotely, similar to Perfmon.exe. I would recommend opening Perfmon.exe on the SAM server and attempt to connect to these remotely monitored hosts and monitor performance counter data. If perfmon.exe also fails then it's likely as issue with the monitored hosts. It could be a firewall issue or the performance counters need to be rebuilt using the "lodctr /R" at the command line of the monitored host.

There is also a rare circumstances we've had one or two customers who've reported similar issues where CounterFetcher.exe was not properly upgraded, either due to permissions issues or the file being locked by the operating system. We're not exactly sure what the reason is since it's only occurred twice before. If this is indeed the issue then you'll need to stop all SolarWinds services, navigate to C:\Program Files (x86)\SolarWinds\Orion\APM and rename CounterFetcher.exe to CounterFetcher.old. Lastly, run a repair on SAM 5.0 and re-run the configuration wizard.

Thanks for the fast reply.

With perfmon.exe all the counters related to the monitored host works fine.

The strange things is that all the application monitor related to other services (for example we use SAM to monitor our EDGE Servers) works fine, but when we try to use SAM to monitor Client Roles, hub transport or MAilbox Roles conuter, we obtain the error and only after the upgrade to the new version.

Regards.

If the performance counters work remotely using perfmon.exe and the problem only started cropping up after upgrading to SAM 5.0 then I'd recommend you open a support case so we can look through your diagnostics to determine the cause of the issue.

I've opened a support ticket and now the applications works perfectly.

We need only to restart the "Remote Registry" service in the Remote host.

Thanks for your support.

Great catch on the Remote Registry service.  We had a handful of servers reporting similar issues, but not specifically Exchange. It turns out there is a memory/handle leak in 2008R2 and Windows 7 Remote Registry service that has been known to eat up handles and then go off to lala land.  There is a hot fix from Microsoft that has resolved the issue in our environment, but your reminder of the Remote Registry playing an important part helped me get to the right location again.

For reference KB2699780 is the details on the error and link to the hot fix.