Pauline's community posts

Hello,

let's say i have a machine, that is used by an employee.
that employee is NOT allowed to have the administrator password for that machine.

As soon as we implement the feature that allows converting Agent to a Host installation, it will be possible to do directly within the remote session. Unfortunately, we cannot provide any specific ETA on this feature.

Meanwhile, you can restart Agent with elevated (admin) privileges by using the Restart Agent as... feature that allows you to control the UAC prompts on the remote machine when you perform actions that require administrative access (for example, installing software). In case if you want to install Host you can also configure a custom MSI installation package or a One-Click installer and enable the Send Internet-ID to email feature that sends an email with the Host's access credentials to a specified email address upon the installation.
Alternatively, if you want to install Host on a domain or across your Windows network, you can also push-install Host using GPO or use the Remote Install Tool.

Hope that helps.

Hello,

Thank you for your message.

--> user01
Error #67
Unable to connect a network drive.
The network name cannot be found

This error usually means that the admin$ (admin share) isn't found or unavailable on the remote PC. Admin$ is required to be available whenever you need to push-install Remote Utilities (or any Windows software) onto a remote machine. For more information please refer to this guide.

it seems to be running but take a look at this snippet.

Please note that you should also have a rfusclient.exe running on the Host machine in addition to the rutserv.exe process as these processes must be running in order for Host or Agent to work properly. For more information please also see this page.
If the rfusclient.exe is not running or you cannot locate a corresponding file in the Host installation folder, then the issue might be occurring doe to some file in the Host installation folder being somehow damaged or corrupted (perhaps, by some firewall or software activity). Please try fully uninstalling Host as described here and please make sure to clean up the previous installation traces, then restart remote PC and install Host from scratch. After installing please make sure to add the Host installation folder C:\Program Files (x86)\Remote Utilities - Host\* to the exception list as described here.

In addition, please make sure that the Host service is running on the remote machine as it's required in order for the Host to work properly. You can identify the service as Remote Utilities - Host. Here's a related guide on the Host service that might also provide some useful information.

Hope that helps.

Hello,

Thank you for your message.

Unfortunately, running Host and Agent at the same time is not currently supported by Remote Utilities. However, I'll forward your request to our development department for a review to see if it's possible to implement this at some point in the future. Sorry if this makes our software less useful for you.

i found this post, but not sure what it means?

The feature mentioned in the referred post is already in our wishlist and, once implemented, it will allow users to convert a running Agent to Host, i.e. the Host will be installed automatically with all Agent's settings imported to the new Host installation.

Hope that helps.

Hello,

Thank you for your message.

This issue might have occurred due to some kind of False Positive which might block/restrict Remote Utilities or block access to our servers. Most of the times the end user is not notified of this type of security software (or ISP) activity, so it seems like there were no changes that might have caused the issue.

Could you please let us know if you have an antivirus or firewall installed on your remote Host machines or somewhere on the perimeter? If yes, then please make sure to add Remote Utilities installation folders to the exception lists as described here.
In addition please make sure that the outbound TCP ports 5655 and 443 are not blocked or used by another software since these ports are required to be opened (or at least one of them) in order for the Internet-ID connection to work properly. For more information on ports used by RU please see this page.
Last but not least please make sure that the DNS name id.remoteutilities.com which points to our servers is not blocked anywhere on your network or at the ISP level.
Please also try referring to this troubleshooting guide that might provide some helpful information.

Hope that helps.

Hello Michael,

Thank you for your message.

Please note that our Free License does not restrict you to a specific workstation - the only limitation for the free license users is that they can only add up to 10 remote connection to their address book.  For more information on the Free License please refer to this page.

In this case, if your Viewer is not minimized to the taskbar, then the issue might be occurring due to some files in the Viewer installation folder being somehow corrupted (perhaps, by some firewall/antivirus software activity). Please try the following:
1. Fully uninstall Viewer on the machine where you get the "Error: Another user is using this copy of R-viewer" error message as described in this tutorial and make sure to clean up the previous installation traces.
2. Re-install Viewer.
3. Make sure to add the Viewer's installation folder C:\Program Files (x86)\Remote Utilities - Viewer\* to the exception list as described here.
4. Run Viewer and see if the issue persists.

Hope that helps.

Hello Martin,

Thank you for the clarification.

We do not plan to stop supporting the 9-digit Internet-ID codes as we do our best to maintain as much backward compatibility as possible. However, we do recommend upgrading the 9-digit codes to the 12-digit ones to improve the overall stability of the connection.
Since you’ve mentioned that you have other Hosts with the 9-digit Internet-ID codes of version 6.10.10.0, then it does seem to be an issue caused by the Host’s outdated version. In this case, simply updating Hosts might help to resolve the issue without actually generating new codes.
However, if you would like to replace the older Internet-ID codes anyway, you can do so with the help of Remote Install Tool which allows you to update the Host remotely along with updating its settings. You simply need to configure a custom MSI installation package to use with the Remote Install Tool.
I’m order to generate new Internet-ID codes please make sure to enable the Generate a new internet-ID code and When updating existing Hosts, overwrite their Internet-ID code with the generated code checkbox - these options will ensure that new Internet-ID code is generated upon the installation. You can also enable the Send Internet-ID to email feature which will automatically send an email with access credentials to a specified email address.
Here’s a related guide with detailed description for each feature in case it might provide some helpful information as well.

Hope that helps.

Hello Martin,

Thank you for the clarification.

That's a nice workaround, but not exactly feasible. The hosts are spread out over a large geophraphic area, so it would take quite a while to visit every site. Since they're offline, I can't get to them to update remotely.

I understand that updating your remote Hosts might be a time-consuming process in this case, but unfortunately, there's very little we can do to help you to resolve the issue unless the Hosts are updated to at least version 6.10.10.0 as in this case their current version is severely outdated and simply updating them will most probably resolve the issue, especially since we've switched to using 12-digits Internet-ID codes for Hosts a few version ago as well (namely, starting version 6.6.0.2).
In addition, we could've also examine the Host log files to see if they might contain any additional error entries, but the log files are stored on the remote Host machine as well.

However, if there's a chance that there might be a remote user at one of the remote Hosts, you can ask them to update the Host manually to the version 6.10.10.0 and see if this works for at least this one Host. You can also configure a custom One-Click installation package and send it over to the remote user, so that they would only need to run it - Host will be updated automatically.
Please note that your Viewer of version 6.10.10.0 will automatically configure Host installation package of the same version (6.10.10.0).

And even if I could, I've found the remote updates have failed, requiring a complete reinstall, about a third of the time. Again, requiring onsite access to the systems.

Unfortunately, the failing remote update is probably caused by an outdated Host version as well since we've completely re-written the "Simple Update" process starting version 6.10.8.0. However, if you can log on to some of the remote Hosts, please try updating them using the Advanced Update method (using the Remote Install Tool) instead as it might be a workaround and a way to update Hosts remotely in this case.

If it's possible to update at least one remote Host to version 6.10.10.0 and the issue with the Host being offline still persists, please feel free to send us the Host log files for examination. You can send them to support@remoteutilities.com or attach to a ticket in the Ticket System.

Hope that helps.

Hello Martin,

Thank you for your message.

Could you please try updating your remote Hosts to the latest version 7.0.2.0 or at least to the previous stable version 6.10.10.0? In this case the issue might be occurring due to the Host version being outdated.
The latest version 7.0.2.0 is available for download on this page. Alternatively, if you want to update your Hosts to the version 6.10.10.0, it's available for download on this page.

Hope that helps.

Hello Dan,

Thank you for your message.

Could you please make sure that you're connecting to the remote Host machine in the Full Control connection mode as described in this tutorial and not in the Terminal mode? Namely, please try switching to the General tab on the Viewer's ribbon toolbar and see if you have Full Control mode selected and not Terminal mode.
Alternatively, please try right-clicking on the remote connection and selecting Full Control in the dropdown menu.

Hope that helps.

Hello Christer,

I'm glad to hear we were able to help!

Seems like it's necessary for some but not all "headless" computers to enable this option then, good to know, thanks!

Yes, such issues might be occurring only on some machines, depending on the graphics card used, OS (e.g. Windows 10 vs Windows 7) or some other parts of the machine's configuration. However, enabling the Legacy capture mode feature usually helps to resolve the majority of similar issues.

Please let us know if you have other questions.