I'm new to RoyalTS, evaluating it as a Devolutions Remote Desktop Manager replacement.
My company is interested in using the RoyalTS Document Store feature. We want to store our documents on the RoyalTS Server and have our technicians access the Documents from the Royal Server.
We've set up a RoyalTS Server. And added the Royal Server object to our local installs. What I'm finding, however, is that we have to set our credentials in the Royal Server object. What I would like is that each time Royal TSX opens and attempts to connect to the RoyalTS Server, we're prompted for our credentials (to connect to the Royal Server and pull down the Document(s)).
How can I accomplish this?
prompting for credentials on Royal Server objects is not supported. Instead of specifying credentials (username and password) directly on the Royal Server object, we suggest you set a credential by "Name". Each user just needs a credential with that name (and their username and password set) in one of the opened docs (incl. the application document) to make this work. See also: https://www.royalapps.com/go/kb-all-teamsharing
I hope this helps.
The help desk article you provided focuses on how team members can use their individual credentials with the team-shared Royal TS team documents. Right now, I am focused on protecting access to the Royal TS team documents. The idea is to prevent the wrong people from being able even to find or access the Royal TS files. I was hoping to use the Document Store feature on the Royal TS server to do this.
It might be that I've misunderstood your response, but asking the technician to store their network credentials (used to connect to the Royal TS server) in a personal Royal TS document on their PC isn't a good fit for us. I'm concerned about having network credentials stored anywhere.
I wish there were an option in Royal TS where, when connecting to the Royal TS server, the technician was prompted for their network credentials (to use to connect to the RoyalTS server), similar to what happens when connecting to a Windows or Linux server.
I am struggling to see that Royal TS overlooked that feature. And so, is there an alternative option I should be looking at for using Royal TS in a team environment? Since COVID our technicians are now dispersed geographically so the traditional methods (e.g. a file share) is no longer a viable option for us.
Please let me know.
unfortunately credentials must be provided upfront. This is by design. Please note that all credentials are always stored encrypted in our document(s). If you save your credential in the app doc or any other doc, we strongly suggest to provide a strong "master password" to safely store your credentials in the document. We are using industry standard 256 bit AES-XTS encryption and I would argue it's much safe to keep all the creds safely stored in a document like this instead of storing them anywhere else (post-it, excel, etc.). Because this way, you can't really control where your employee writes down the password so it's much unsafer keeping them in a properly secured .rtsz file.
Btw. there's even a policy we have in place to prevent users from creating credentials in documents without password protection:
I don't think that's going to work for us, unfortunately.
It's a bit of a shame that the password has to be added to the Royal Server object embedded within a personal .rtsz file on the technician's PC. I am now exploring using a file sync platform as an alternative in response to that news.
If I may make a feature enhancement request, it would be that end-users should be able to create a Royal Server object in their personal .rtsz file, but NOT need to specify credentials in there. Instead, the experience should be exactly what we get when connecting via RDP or SSH to other computers. i.e. When RoyalTS opens and sees a Royal Server object with no embedded credentials, it should pause and ask the end-user for the credentials to connect to the RoyalTS server.
That just seems like a sensible experience.
I understand your disappointment. I kindly ask you to post a feature request in our ideas forum. This is the best way to gauge interest in certain features and help us prioritize which features to implement sooner.