Conrad Sallian's community posts

Hello Tom,

Thank you for your report.

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.

Updated the script file - it now accomodates 32-bit OS too. The previous script wouldn't work properly on 32-bit OSes.

Thanks.

Bob Smith wrote:

Thanks for your reply Conrad and that's great news. Let’s hope the next version isn’t 2 years away ;)

Definitely not . A few other issues were fixed so we'll release them all in one update as soon as possible.

Hello Bob,

Sorry if my colleague was a bit straightforward explaining the reason why we implemented this message in the first place.

UPD: I modifed this forum message a bit. The notification won't be movable. We'll simply remove it showing on the Viewer side, just as planned. This will be available in the very next update.

UPD 2: For technical reasons, hiding the notification message on the Viewer side will only be possible if Host is running on Windows 10 version 2004 (20H1) or later.

Hello Keith,

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.

Keith Evans wrote:

just updated i have a Mini license,  i could highlight multiple connections and logoff, now only logs only one at a time

Hello Keith,

Just tested multipe logoff - it works. Have you updated both modules - Viewer and Host(s)?

Peter Gray wrote:

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.

Hello Peter,

What is the operating system on those machines?

Shane Farmer wrote:

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.

Hello Shane,

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.

Matthew Cooper wrote:

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.

Matthew

Hi Matthew,

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 [8] 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.

Download set_config.zip

You can test this for a while on several Hosts - I also encourage anyone else to join the testing. If this resolves the problem we will include the fix in the very next update.

Answering your question about RU Server - it's not necessary, but it will do no harm if you upgrade the server, just in case.

Thanks.

UPD: Updated the script to also accomodate 32-bit versions of Windows.