Matthew Cooper's community posts

For me, so far on my test site, I have not had any hosts go offline, but I also have not spotted any restart events in the host log. So either the new 7.2.20 update is more stable in this regard, or my luck has changed.

This site has 6 hosts all running on Server 2019 and Server 2022

@Conrad, could you advise what the host log entry would look like if the software restarts itself? I can then do a thorough search and see if it has taken place.

Matthew

I am out of the office today, I will check when I can. I had a thought about this though.

Is this restart going to be logged anywhere? If not. It will need to be in order to be sure it has helped.

Matthew

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

I had considered this too. The security software running on our endpoints is varied. The majority run either Emsisoft [www.emsisoft.com] or Webroot [www.webroot.com].

We have a small number of machines that run customer choice software - Norton, TrendMicro and some with just plain Windows Defender.

I have created exceptions in Emsisoft and Webroot previously as a precaution, I did not see any change. With the other systems, I have not created any exceptions.

I have now updated all the servers [8] on a single site to the new 7.2.10 host and disabled the RUM. I have also enabled the local logging on these machines. I have not yet updated the self hosted server version. Does that need to be done in order to test the new version effectively?

Matthew

Hi Conrad

For me, no, the issue of the host going offline does not coincide with a reboot of the machine. It can go offline at any time. That is why I have the task setup to check the service hourly.

Matthew

Hi Pauline

Yes, what I call the RUM is a series of scheduled tasks that check for and or restart the rmanservice on the host machine.

There is no need for you to provide support on this. That system is only there to assist with keeping RU working. I see you routinely respond to this issue asking for host logs, however, I am yet to see any real solution to the issue. You often point at windows updates, but for us, even machines with Windows Update disabled, these issues still occur.
My point above was that without these scheduled tasks, Remote Utilities is so unreliable it cannot be considered a long term remote support solution on its own. I am not alone in this experience. Shane has given up, as per his post above. I have a handful of hosts on the same LAN as the Self Hosted Server that connect via local IP and they too go offline in this same way.

I have previously posted a laundry list of issues that are ongoing as of 7.1.7.0
https://www.remoteutilities.com/support/forums/messages/forum1/message10215/1977-is-it-just-me


My opinion is that if RU is loosing customers to a system such as VNC, then you should take that very seriously.
I have nothing against VNC, but by comparison it is a very very basic remote access platform, and no full featured paid software should be seeing its customers heading that way.


The RU software potential is incredible. It has all the bones of an unbeatable platform in its versatility. What it lacks is reliable function. If users cannot reliably hit connect, and reach their target host systems, then it is all for nothing. I don't know about others here, but for me, when my customer calls and needs support, if I have to tell them to wait as my remote access will not let me connect, that defeats the purpose. My RUM goes a long way towards making the software reliable, but it is far from a perfect solution.

Matthew

Hi Thr0nic

For us, the only way to make the self hosted server work consistently has been an automated weekly reboot of the entire server. We tried an auto restart of the service, but that wasn't always effective. We reboot now every Monday morning at 5am.

There are occasions every now and then where we have to reboot the server during the week, but it has become rare.

The feeling over here is that RU components (Server, Host, Viewer) are very particular about internet connectivity. If any component looses connectivity for a period of time (seems like anything longer than a few minutes) it is enough to throw it out. We have gotten used to it but it would great to see it get better at staying online.

Matthew

I am yet to try the new version. I can firm that without the RUM (Cooper fix), this software is, for me, simply not reliable enough to use. Even the RUM is not 100% perfect, I still get issues connecting randomly.

@Pauline, I am very surprised that the problem cannot be replicated, it happens on every machine I install on, and I am over 500 hosts now.

I have not given up yet, but I have been installing a backup product for emergencies.

Reading the release notes of 7.2.1.0 it does not seem to me that anything specific will address this issue. I will optimistically update a few hosts and disable the RUM then report back.

I look forward to the clipboard transfer fixes, that has been driving me crazy for a long time.

Matthew

Hi Shane

Your mileage may vary, but for us, windows update does not appear to be a defining factor. We have RU on Windows XP and Windows 7 machines in manufacturing that are not updated and have no general internet access, and these still suffer from this issue.

Rebooting after a windows update may appear to trigger the issue, but rebooting without any updates being applied is also a cause in our case.

The only workaround we have been able to make work is the service refresh as mentioned earlier in this tread.
I have not noticed the problem being worse on the last couple of RU versions, but I cannot see an improvement either.

Matthew

I initially thought I had this solved with my 2 tasks [1 to start service upon startup and s second running every hour]
However, this was not totally effective in keeping all hosts online.

I have had to go a step further and add a task that performs a stop service then start service at 4am every day.
Without this task, I was finding that some [not all] hosts would go grey, and never come back online. The service itself was running, but the host was just offline.
It is not an issue that occurs every day, it seems very random. The best theory I have is that if the host loses connectivity to the RU server for an [as yet unknown] extended amount of time, it seems to give up trying, and never reconnects. Maybe there is a connection retry limit in the hosts somewhere.

The 4am daily restart so far appears to be dealing with this issue for me, and as I typically do not need overnight sessions to stay active, it does not have any negative impact here. However, my gripe is that if the remote host restarts and I have left a session running, the screen at my viewer end will show offline, but does not close, then when I have to close the viewer window, it takes about 5-8 seconds for each window to close, which is frustrating.

I have only implemented these recurring tasks [I call it the RUM; Remote Utilities Monitor] on a small number of our hosts, but overall, the reliability has improved significantly on these, whilst the non RUM'd machines are often problematic.

It would be great if RU could have its own watchdog service built in, so we would not have implement our own.

Matthew