Forum / Remote Desktop Manager - Support

Terminal server deployment best practices

  • Create an Issue
  • Cancel

I am not sure how many others are using a terminal server method (Now RDS Remote Desktop Services) with RDM Server. We chose this method for centralized software standards control and more for security at the network level. But as we grow with this method i think we run into issues that are unique or outside the typical distributed client method i think RDM was designed for.

I wanted to start a topic on this setup type to highlight some of the issues and best practices just for RDS solutions.

First topic i would like to ask is controlling the users client settings more. We have been using the centralized default.cfg method so far to distribute out the default.cfg for RDM but some of the caveats of this is some on the team members do not select the "Lose mine" option when prompted to load the default cfg file. When they do not select this option they continue to use old settings. We would like more control here to force the new CFG settings on users when they log in. I am looking to use GPO to overwrite the .cfg file with the latest but i have concerns as i am not sure what effect this will have. What is not clear to me yet is where are things stored. I know datastores are stored in the default.cfg file but what about other settings like columns shown and layout of RDM? What i have noticed sometimes when excepting the new CFG settings is i see many of my personal settings adjusted or removed like i was saying layout and columns shown. I can easily recreate my settings but i would like to understand more and see which other files i might need to control and distribute to maintain a constant RDM Gui experience for our whole team.

In the future we want these GPO to be tied to roles also as some roles like contractors we might want a more rigid RDM cfg file with no options and for our build team member role we might want them to have more options and control in their RDM.

Clock4 yrs


Our configuration system started with just a single file, and evolved in what we have today.

Not only is there the .CFG file in play, but also the .EXT (Extended configuration), and finally the .LYT (UI Layout) files.

The LYT files are managed by the UI library that we are using, we do not manage them other than specifying which folder to store them in.

The extended options file is supposed to contain settings that are more related to the user: MRUs, Grid columns visibility and width, etc.

The issue with the main cfg file, is that the goal is for it to contain all settings that can be deployed by our custom installer (Custom Installer Service). That is fine for most, but the issue is that not everyone agrees on what should be imposed by the sysadmin, and what should be customizable by the user. We'll never get conscensus on what should be in it therefore we must make the best decision we can with the information we have.

Also, I must admit that some settings from the cfg file could/should be moved to the EXT file, but thats not something that is being brought up by our community. The requests we've had were to block out end users, so thats why we've added Administrative Templates (GPO). (How-To > How to apply policies). If we had to redo that configuration layer, it would mose likely be a multi-layered engine with overrides instead of each setting being defined in one place only, but thats a major undertaking.

As for you strategy, its what I would have recommended. Paired with using our administrative templates, you could disable File- Options, maybe File-Data Sources, and many more.

Apart from opening both cfg and ext files and having a browse, you could ask how a specific option is managed and we'll be able to tell you where it is managed from.

Best regards,

Maurice Côté


Clock4 yrs