Could you please let us know what you specifically select in each configuration step. You can simply take screenshots and post them here. I'm especially interested in Step 3 and 4, and also the Host configuration step (provided you didn't select "Skip Host configuration settings" in step 4). Then we'll try reproducing the issue.
No problem. The server roles can work independently and you might want to use just one role without necessarily enabling another. For example, you can use the server for address book sync only while connecting to remote Hosts using direct connection.
No offense, but... absolutely not. I don't allow anyone to remote view, or access any of my systems, unless I know, and trust them. If you want to see how I logon to the host, I can create a short YouTube video that will show you how I logon, and use the Host with the viewer.
That's no problem, I understand. A video is even better.
EDIT: Here is the video I promised that shows my settings, and how I login to the server from the client.
Much clearer :)
First, I can see that you are using RU Server which is a piece of software optional for Internet-ID connection type and isn't needed at all for direct connection. Apart from acting as an intermediary for Internet-ID connection (relay role) the server can also perform address book synchronization and act as authorization hub (sync and auth roles respectively).
The authorization through the server (Custom Server Security) is what you enabled on the Host together with the default single password authorization:
When there is just one authorization method selected - usually Single password - Viewer simply connects using that method, i.e. it prompts you for password or connects right away if you saved the password previously.
However, when multiple authorization systems are enabled on the Host the Viewer must somehow decide which one to use when you log in on the Host (see comments on the yellow background here ). This is defined by the "Authorization method" dropdown in connection properties:
The default setting here is "Auto". This means that if multiple authorization methods are enabled on the Host, Viewer will follow this order of priority:
Custom Server Security (CSS) Windows Security Remote Utilities Security Single password
This is what happened in your case. You had both single password and CSS enabled as authorization methods for that specific Host. You clicked "Log in" and Viewer used CSS (since you had "Auto" in connection properties) thinking that it's the method that you want to use first.
If you expect Viewer to use Single password, you should either disable CSS in the Host authorization methods or explicitly select Single password in connection properties dropdown list (such selection is meant to let the tech override the default auth sequence for specific Hosts if needed).
Or, if you really wanted to use the CSS you must make sure that you set the rights properly for the server account with which you sign in, because "access denied" says that you didn't set permissions for that server account for accessing the Host in question. This is not your Windows account , this is the account in RU Server that you create yourself on the server and then set permissions for in Host "CSS" authorization settings (the CSS system in this respect resembles Active Directory). Finally, if you want to use Windows accounts to authorize on the Host, just enable the Windows Security method.
Please, note that Remote Utilities can perfectly be used with default out-of-the-box settings. Both RU Server and the CSS authorization method are advanced features. You don't have to use the server unless you really need the features that the Server provides. If you install/enable it as well as enable the supporting features in Viewer and Host modules please be sure that you look through our documentation to avoid possible misconfigurations and pitfalls.
Unfortunately by the time you wrote that message i was on the way to the client to repair the desktop, it had indeed had VIEWER installed and not HOST, it now has a new host installed and is in use migrating servers.
Still I can't see even the slightest possibility of Host downloaded the Viewer installer instead of, well, Host when you initiate simple update. We serve the same Host file from our site to all customers (it is the Host that contacts the update server). How come that one single Host downloads a different file for one customer if the download link is hardcoded into the program? Besides, we haven't received other similar complaints - I mean installing Viewer instead of Host when Simple update is involved.
This can only be possible if you used Remote Install tool for updating a fed a different installer into the Remote Install window. I cannot see other explanations. But you only mentioned Simple Update that's why it's strange.
If there is a log file then the PC i will see in about 4 hours i bet has the viewer installed, so if you want me to track down any install log i might be able to do that. However it has to be working today as i have a huge server migration to do over the weekend from that PC on the clients LAN. So once i get there it will be fixed.
After upodating everything, except the host on the client machine, I was able to login to the host machine via the client's viewer just once. Leaving it over night returned to the access denied errors, so I did manage to log into the host, but I'm still being told it's out of date.
If you managed to access the Host from the Viewer and never changed anything in the authorization system in the Host settings ever since, it cannot all of a sudden start showing "Access denied". Access denied here means that you cannot authorize on remote Host, not issues with connectivity (which would explain why you can connect at some time and cannot at a different time).
Please, double check your Host authorization settings (Settings for Host -> Authorization) and make sure that you enter the correct password. Also, make sure that the connection mode you use is allowed on the Host side (in the Modes section/tab).
If all else fails let me know and we can have a remote session (connect to your Viewer PC) to see how exactly you log in to a remote PC or launch a connection mode.
Using "Simple update" from the updated viewer, or updating by downloading the MSI, and running install BREAKS older versions of the host at this point. My only solution was a complete uninstall, and reinstall of the latest host software.
We have one idea that we will try implementing in the very next RU update (220.127.116.11). In a nutshell, we will see if we can gain complete control over the update process instead of delegating it to msiexec, which seems not to be very reliable. In theory this solution might help eliminate the update issues at least those not caused by antivirus software activity. However, this fix won't start working immediately, meaning that it will work for updating Hosts 18.104.22.168 and higher, and not the earlier Hosts for which the current update mechanism will still be used.
Again, the problem is not with "Simple update" per se. The problem is rather that the uninstall-install process isn't properly performed in certain circumstances my msiexec.
I see you are trying to blame windows for the failed "installs" needing restarts, although i expected this, heres the thing no one of your other updates went this badley, all systems were up to date. Please advise.
Sorry, I am not trying to blame anything or anyone. We are just trying to find the root cause in each specific case. Unfortunately, we cannot reproduce the issue in our testing laboratory which means that there is either an external factor or (if it's still internal) it only manifests itself in certain circumstances.
In order to help we must examine each support case and find the exact reason why re-installing (updating) Remote Utilities doesn't work on that specific machine. Note, that as I mentioned earlier in this thread the "Simple update' itself has nothing to do with this. Once the file is downloaded from the Amazon server (if it isn't your Host log will have an error line about it) then the installation process is run in the same way as if you ran it using the vanilla Host with "msiexec /i <file_path> /qn" command, no difference.
How do you explain a server that was running the HOST, then had this removed and the viewer installed (i manually logged in to the server and found it, the install date was the date i did the upgrade, so why did the "upgrade" remove the host then install the viewer?)
Running a Simple update on a remote Host cannot install the Viewer. This is something most unusual. There is a single link (source link) for downloading the Host package during simple update. If Simple update installed Viewer instead of Host this forum would be flooded with complaints and support requests. Version 6.10 has been around for almost three weeks now and there are thousands of updates already.
I have at least 2 servers (and i believe i will find another later today) that had the HOST removed and viewer installed, i have no idea why the "upgrade" would have done this. It results in "OFFLINE" in the viewer software (as it removed the host so does go offline)
However on removing the viewer then installing the HOST.MSI, i have to then manually restart the remote utilities service otherwise it gets stuck on "logging in".....
Would it be possible to schedule a remote session where you would run a simple update and reproduce the issue?