A yellow triangle on the cloud icon means that Viewer cannot connect to server to sync the book. This points at connectivity problem, not a permissions problem.
We've just tested setting up address book synс with a group added to permissions list on the top level and every works. We were able to sign in on the server as one of the members of that group and sync the book without an issue.
We could use more screenshots or even a short video. You can send them to firstname.lastname@example.org in case you don't to share them on the forum.
Remote Utilities licensing is not affected by whether you use the self-hosted server or not. Using the self-hosted server is a just a free "on top" option.
In order to use Remote Utilities beyond the 30 day trial period you must register it with a license key. This can be a free license key (in which case you are limited by 10 records in your address book) or a commercial key in which case the number of records depends on the tier (Starter/Mini/Pro).
Note that the licensing terms apply to Viewer regardless of where you keep your address book. It can be locally on the Viewer or synced via your self-hosted server.
I have no connections stored in the cloud.
There is no cloud (hosted) connection storage option at all. Our public server only allows/brokers a remote connection, it doesn't store your address book. Although we are considering plans to implement an online account too at some point in the future.
After some extensive testing we found the cause for the "online-offline" pop-ups, the issue was on the Viewer side. You can reproduce this issue yourselves if you do the following:
1. Set up an Internet-ID connection (regardless public server or self-hosted) and log in on a remote Host. Your connection icon in Viewer must show a green monitor or a remote screen preview meaning that you are being authorized on the remote Host.
2. Without logging off the connection in the Viewer stop the remote Host (right click the Host icon - Stop Host) for a 1-2 min. Then start Host by using Windows Start menu -> Remote Utilities Host -> Start Host.
3. Allow some time for the connection to go back online in Viewer and then wait for a few minutes. Notice how the connection starts briefly "going down" and back up with a 1-minute interval.
This issue is going to be fixed in the nearest RU update, in approximately a week from now.
Hoping this helps with the constant pop ups for clients when Viewer is open.
This is an evading issue that we can't reproduce 100% . After you update to the most recent version (Viewer, Host and Server) and you if you continue experiencing these pop-ups, could you please contact us via the tickets. Perhaps, with your help we'll be able to figure out the problem.
Edit: PEBKAC fail. I needed to check the Idle tab instead of the Active tab. My bad.
Just wanted to confirm, if it's working for you now?
The new Server version 184.108.40.206 is available for download. If you are updating from 220.127.116.11 you may still need to restore permissions in your server book. If you have a simple permissions structure, i.e. one account that has full access to the entire book, just do the following:
1. Update to 18.104.22.168 "as is", i.e. just run the installer and complete the installation.
2. In the server address book manager expand Address Books, right click on your address book and select Edit address book.
2. Click Security.
3. In the security window enable Replace all child object permission entires with inheritable permission entries.... This will grant the account (principal) in the list permissions to all objects in this address book and restore permissions for the entries where they were deleted due to the bug. Therefore, when you sign in on the Viewer your "lost" entries should re-appear in Viewer address book.
If you have more granular access levels, i.e. other accounts with access to only some folders you will need to do the same procedure but on the respective folder level.
We have just managed to reproduce the issue and confirmed that it's a bug on the server. This is how you can reproduce it: add a new connection to your synced address book in Viewer and then edit it, e.g. change its name. The connection will disappear from the Viewer book but will remain in the server book.
We will be fixing this bug and updating the server later today. The server version will be incremented too for you to be able to distinguish it from the current one.
Sorry for any inconvenience.
P.S. Viewer 6.10.8 and Host 6.10.8 are not affected by this bug, it's only the server that needs fixing.
I try to keep the client and host versions in sync, but its not easy because the client will prompt for an update regardless of the host versions on the backed.
This can be disabled in Viewer Options -> Update. Besides, the update is never mandatory, the program just notifies you that a new version is available but it's always up to you whether to update or not.
In this case the client got updated first, then the RU server. The connection that got deleted was an older version (6.10.5) of the host software.
The Host version shouldn't be affecting the sync mechanism in any way. An address book record is just a record, its contents doesn't really affect how the sync mechanism works. We tried the same update order but didn't notice any issues.
See the attached screenshots images of the windiff of the files. The left side is the 2.7.6 version of the address book. The right side is the same address book after the 2.7.8 update. It appears the 2.7.8 update made some changes to the address book that may have caused the account I was using to lose access to the connection entry.
Yes, this is interesting. Could you tell me how exactly you set permissions for that book? Did you enable full access to the entire address book at the top level or was it more granular (folder- or even connection-based)? The more details the better - this will help us better reproduce the problem if it's somehow related to permissions.
We have just quickly tested a scenario where we updated Viewer, then (without doing a sign in on the server) updated server, then signed in on the server and got the address book synced normally. There were no issues.
Now we are testing different scenarios, e.g. updating server first, Viewer second, and with different sign in states. That is why we asked in which sequence you updated the modules. Perhaps, the order was different in your scenario and we could thus try to reproduce it.
Thank you for the clarification. Still, this requires a centralized system with our service at the center, and this is exactly what we moved away from (due to abuses of the system and antivirus software being angry at us about that as a consequence).
However, we may look closer at this idea when we start implementing an online account.