Conrad Sallian's community posts

Hello Alan,

Thank you for your message.

I am using 6.9.1.0 viewer and when trying to do any file transfers with remote computers, the file transfer window is MASSIVE. Now on my computer setup I have 2 4K monitors, one is horizontal, one is vertical, and a 1080p monitor as well. The window shows up spanning multiple monitors and much be resized to see the entire window so you can see buttons and such.

Does this happen each time you start a File Transfer mode session? I.e. it doesn't remember the size that you set.

Additionally, I have a very hard time navigating to directories, I constantly get errors, then after trying a few times it might work. Sometimes I have to just use Remote Utilities to initiate a VNC session so I can do file transfers it has gotten so bad.

This is a known issue, specifically the issue with slow folder browsing in File Transfer mode. Later this year we are going to significantly re-write the File Transfer module and will fix these issues, and also add a couple of useful features.

Hello Rick,

Thank you for your message.

This feature has been on our wish list for a while. Most likely we will implement it in the near future.

Hi Bill,

Please, try the solutions listed on this page https://www.remoteutilities.com/support/kb/full-control-and-view-mode-isn-t-working-or-is-unstable/ . If it doesn't work, update your Host to the recent beta version and see if it makes the difference. You can download the beta from here https://www.remoteutilities.com/download/beta.php

Pedro Peracio wrote:

Hello Everyone..
29-09-2018__21:41:55__042 Connection #739288. Connection to "MERCADO MARLUI". Mode: <Authorization>. Connecting...
29-09-2018__21:41:55__043 InetConnection #739288. Internet connection to MERCADO MARLUI (id.remoteutilities.com:5655).
29-09-2018__21:41:55__297 InetConnection #739288. Method "Connect" - OK. MERCADO MARLUI connected to ID server: id.remoteutilities.com.
29-09-2018__21:41:57__600 InetConnection #739288. Socket error. Name: "MERCADO MARLUI", host: "id.remoteutilities.com:5655". Exception class: "EIdConnClosedGracefully". Message: "Connection Closed Gracefully.".
29-09-2018__21:41:57__602 Connection #739288. Connection to "MERCADO MARLUI" failed. Mode: <Authorization>.
29-09-2018__21:41:57__602 Context #739288 removed. Mode: <Authorization>.

Currently, It's so hard connect my hosts. This issue can be my DNS server ?

Hello Pedro,

This topic discussion is about the use of self-hosted server.  From your log I can see that you use the public server for your Internet-ID connection. In this case please refer to this Internet-ID connection troubleshooting guide https://www.remoteutilities.com/support/kb/cannot-connect-using-internet-id-connection/  

Hope that helps.

Hi Nick,

We already sent a report to Microsoft and they said that they fixed it. Could you please try updating your Windows Defender signature bases and see if the issue persists.

Thanks.

chk out wrote:

I am using a 64bit Windows 10 OS and I am constantly getting disconnected as well.
I am seeing online this is a common problem with your application, and has been for quite awhile, is there any plans for fix this, or to help use determine what needs to be done to stop these disconnects? I really like your product, however, I would not even entertain the idea of purchasing it when the time comes that I get over 10 clients. Unfortunately, I would have to go with "the other guy"

Hello,

We received the log, thank you. However, the log shows connection attempts to our public server (id.remoteutilities.com) rather than any self-hosted server address. This discussion is about self-hosted server.

Still, even if you use the public server I can see that the Host has issues connecting to the server. There is socket error #11004. Here is from Microsoft site:

WSANO_DATA
11004
Valid name, no data record of requested type.
The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record—indicating the host itself exists, but is not directly reachable.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx

Please, check that the dns name of the server is resolved properly on the Host computer. I recommend flushing the dns cache and also check your network settings, e.g. set Google DNS servers instead of your ISPs in your TCP/IP properties.

Hope that helps.

Hi Greg,

No problem. I'm glad you figured out the issue.  

Feel free to post in the community if you ever need assistance with RU.

Thanks.

chk out wrote:

I am seeing online this is a common problem with your application, and has been for quite awhile, is there any plans for fix this, or to help use determine what needs to be done to stop these disconnects? I really like your product, however, I would not even entertain the idea of purchasing it when the time comes that I get over 10 clients. Unfortunately, I would have to go with "the other guy"

Hello,

In order to find the reason why disconnects occur we need to examine the logs, mainly the Host log. Could you please send it to support@remoteutilities.com .

Also, RU version 6.9 beta 2 and Server 2.7 beta 2 are available for download. If you can, please update and let us know if the issue persists. Not that if you decide updating you should update all modules, not just the Viewer or server.

Thanks!

Hello,

Thank you for your message.

The only "issue" (well, actually just a lack of a feature) is that you cannot use "Simple update" to update your Hosts remotely once you updated the Viewer because this feature was implemented starting version 6.6. Otherwise, the update process should be ok.

Any particular instructions in performing the upgrade on the Hosts other than the 'check for updates' option? Loosing connectivity is not an option to most based on location and timing of accessibility. All Hosts are running either Win7 or Win10. Thanks

A rule of thumb when remotely updating your Hosts is that you update the Hosts  in small groups and keep control over the process. First, you upgrade the Viewer, then you upgrade one or two Hosts to test the procedure and see if there are any adjustments you should make to your process, and then proceed with updating the rest of the Hosts (every 10-20 Hosts at a time).

That said I highly recommend that you wait another two weeks and update to version 6.9 when we release it. There were quite a few important changes as compared with version 6.8, see the release notes as well as the recent posts in our blog.

Let me know if you have any questions.

Igor wrote:

InternetIdService.exe in 2.7 beta is an AMD64 image.
My "server" is Windows XP SP3 x86

Hi Igor,

Unfortunately, the new version of server only runs on 64-bit systems. Sorry for that.