Conrad Sallian's community posts

Hello,

Here is an instruction I mentioned earlier:
https://www.remoteutilities.com/support/kb/how-to-collect-data-for-diagnosing-connectivity-issues/

It will save all of us time when figuring out the problem. Note that Remote Utilities is software of "dual nature". A connection involves at least two and sometimes (in case of ID connection) - three modules including an ID server. So we need logs from all of the modules along with the date and time of when the issue happened.  

Thank you.

Hello Jon,

The Viewer log alone won't help us figure out the issue. We also need the Host's log and other information. If you wait a bit we will come up with  a detailed instruction in our knowledge base on how to collect the necessary logs and what to send to us. I will provide a link to the knowledge base article later today or tomorrow.

Is there a way I can download an older copy of the viewer, as some have stated running an older version fixes this issue?

Downgrading to an older version is not recommended. Besides, before we examine your complete logs we cannot be sure if your issue is the same as the one reported in this thread.

Let me draw an analogy - a high human body temperature is a sign that something is wrong, but it can be caused by many factors (specific illnesses). The same is true about a connectivity problem - on the surface it looks the same, but the cause might be different in each case, although there are not many of them actually.

Hello Greg,

Thank you for the details.

- With remote machines at two locations, the issue seems to be much worse at the location that has a lower bandwidth, and less stable connectivity.

This might be a factor.  

- At this "worse" location (Eastern US time-zone), the problem is almost non-existent prior to 12:00 or 13:00, at which point it gets quite bad and remains so until around ~19:00. Weekends are usually problem free. I've wondered if net usage in local geographic area is a factor.

Yes, perhaps. Our servers can sustain far more load than they experience now so it is very unlikely that the time of day has any significance when it comes to servers themselves.

- It's a far less desirable configuration, but if I establish a VPN connection to this "worse" location, and connect to the remote station by local IP instead of Internet-ID, the issue is reduced (eliminated?).

Direct connection is a totally different thing than Internet-ID.

Hello Chad,

Currently, we are working on a 64-bit server version and it is already available for testing. I recommend that you replace your current server with a 64-bit version and test to see if you still have issues. Here is how:

1. Back up your server installation folder - just copy it elsewhere  

C:\Program Files (x86)\Remote Utilities - Server

2. Back up (export) server's registry entry

HKEY_LOCAL_MACHINE\SOFTWARE\Usoris\Remote Utilities\MiniInternetId

3. Stop the server process in Windows Task Manager - look for "Remote Utilities Server (32bit)".

4. In the server installation folder run uninstall.cmd as administrator.

5. Download new files and replace the files in the server installation folder.

6. In the server installation folder run install.cmd as administrator.

7. Restart the computer. Make sure that the server process is running (it may say "RMS" in this test build).

Your server logs and data should stay intact. Please, test the new build for a while and let us know of the results.

Thanks.

Hi Michael,

Yes, of course, whatever is more convenient to you.

Chad Brandenburg wrote:

I am constantly getting drops, did a constant ping, and never took errors and was constantly around 30ms or less.. But sites just randomly disconnect for no reason.

Hello Chad,

I would recommend that you create a separate thread/topic devoted to self-hosted server connectivity issues. Or you can join this topicthat reports a similar issue.  We need to keep self-hosted server issues separate from public server issues as they are dealt with differently.

Thanks.

Hello Michael,

Thanks for the information. We will examine the log. Perhaps, we'll also need other logs - we'll let you know soon.

As a PRO customer you can also create a personalized support ticket by the way, where you can attach the logs and other non-public information.

Hello Chad,

As it turned out, the above-mentioned issue has nothing to do with the self-hosted server so it doesn't need updating.

Tom Davis wrote:

The old version of RU Server download is all that is available, Version 2.6.0.3, August 26, 2017.
Conrad, Can please clarify your response, when will the update apply to RU server download?
Thanks

Hello Tom,

RU Server hasn't been updated. What was updated is our public server infrastructure. So we are asking everyone who contributed to this thread with the "online/offline" problem to report if the problem has been resolved now.

We encourage everyone to try the current version now that we have updated our public servers and eliminated the cause of this offline/online behavior. At least our in-house tests show that everything should be working now. Your feedback is important for us.

Thank you.