We understand your frustration and we are also concerned by the quality of modern antivirus software, which fails to do a simple task of distinguishing legitimate, digitally signed program from malware.
Of course I can't make exceptions for every temp case because the paths and files are often random names. I can't fix this from my end.
Neither can't we. It's the antivirus software vendor that can fix their errors (but they never acknowledge them). We do our best to alleivate this situation by sending false positive reports. If you as their customer would send a false positive report and specifically mention that faulty operation of their software distrupts your work process, the issue would certainly be resolved faster.
Thank you for the report. Indeed, there is a bug which wasn't evident at first. Actually, the mass logoff works but when the groups are enabled (Viewer Options -> View tab -> Use group view). When groups are disabled, mass logoff only works on the last item.
We'll add the fix to the nearest update of the Windows version, which is pretty soon.
I have not noticed the problem with host service stopping, but I have several old slow machines where the host service does not reliably start on switch on or on reboot. With some of these, I dare not do a reboot unless I am on site, so able to restart the host manually. I have just run the script on one of these machines (while logged on remotely) and rebooted it after doing windows updates. The machine has rebooted (I can ping it) but the host has not restarted. I shall be there on site tomorrow, so can check if the service properties are still changed according to the script. It may be that the script should have been run while the host service was not running.
For me it starts after machine start and it will then stop working after 5 to 10 minutes. I can restart the service, same issue. It's one three machines. All of them have this issue. Since moving to one of the 7.x versions. I will send logs next week as I just quite trying to use it after a year of no fixes.
The reason for stopping the service may well be of an external nature, it cannot just stop by itself. You should carefully check if there's no software (especially security software) that interferes with the host operation.
Hi Conrad, am I correct in my interpretation that this script simply changes the parameters on the Recover tab for the RManService [Remote Utilities - Host]?
It looks as though it is setting the service to run rutserv.exe -restart on the first and second failure, and nothing on subsequent failures.
I had previously set these to 'Restart the Service' upon failure, with no effect.
Yes, it is. But the point is that it now sets this -restart flag which triggers the code in the program that properly performs the restart. Of course, the script is just helper to set these settings, and we are only testing now. I recommend that you test this configuration for a while and see.
I have now updated all the servers  on a single site to the new 7.2.10 host and disabled the RUM.
Yes, please keep it disabled. Let's test one solution now. Please, unzip and run this script on the Host computer as administrator. You should get the following settings as a result (it's in the Remote Utilties - Host sevice properties):
Note: the script will work only if the Host is installed in the default folder, i.e. Program Files (x86). Also note that there's the parameter -restart added. In a nutshell, this modifies the Host restart process slightly by running a code (which has already been there since previous versions) by killing all running instances of rutserv before attempting the restart. We assume that this could have been the bottleneck and the reason why the Host couldn't restart properly even when you used the settings as on the screenshot.