I am finding that the BES Client Service is not very resilent. I continue to find it stopped on a number of machines. It needs to be much more resistent against sstopping.
How can we determine whether the service has stopped or a system is just offline. I can’t ping every machine that is offline. Anyway, just because you get a ping response doesn’t mean a machine is online.
I agree, I’ve noticed the same thing. However, as a work around, you could deploy the BES Client Helper. It installs a watchdog service that monitors the “BES CLient” service, and starts it if it stops.
I have noticed the same thing. We had a ticket opened with support due to us consistently seeing the besclient.exe crash. No root cause was found. In the application event logs, we see this often:
Faulting application name: BESClient.exe, version: 8.2.1093.0, time stamp: 0x4edd8bae
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b60
Most of our environment is on Windows 7 SP1 and we have also deployed the helper service which has restarted the service successfully hundreds of times on systems. I would expect it to be more stable as well. On some virtual systems we have seen it restarted thousands of times.
we’re seeing a little different issue, where about a dozen clients break a week. The BES Client service stops and has to be started. Working with IBM on a PMR, but no resolution yet. The hard part is that we can’t identify potential future failing clients, so we can’t enable debug logging.
At 12:17:03 -0600 -
Unhandled error in background evaluation: Windows Error 000006bf: The remote procedure call failed and did not execute.
At 12:17:04 -0600 -
Client shutdown (Unexpected error while evaluating relevance)