I was speaking to somebody recently about how they connect to many remote Windows systems – in this instance they were opening up multiple MSTSC.exe windows and connecting that way.
This is something I had done in the past till I came across the Remote Desktop Connection Manager software from Microsoft. It’s a great tool that makes life far easier and in this post I’ll cover some of the cool things you can do with it. I’m planning to be pretty in depth on this post so expect lots of screenshots and info.
Download & Requirements
First off where do you get this fancy software? Well seeing as you asked so nicely I shall provide you with a link to the official download page!
Currently we are on version 2.7 although to be fair it isn’t updated very often, the last release was on the 18th November 2014. That being said the core features are pretty much all there so don’t let that put you off.
To save you the trouble I will list provide the system requirements and details below –
Supported Server Operating System
- Windows Server 2008
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server Tech Preview (Assume this means 2016)
Supported Client Operating System
- Windows 7
- Windows 8
- Windows 8.1
- Windows 10 Tech Preview
Users using Windows XP or Windows Server 2003 will need to obtain version 6 or newer of the Remote Desktop Connection client software.
Features introduced in version 2.7 are as follows –
- Virtual machine connect-to-console support
- Smart groups
- Support for credential encryption with certificates
- Windows 8 remote action support
- Support for Windows 8, Windows 8.1 / Windows Server 2012, Windows Server 2012 R2
Configuration and Setup
Once RDCMan is installed we can start to configure it and take advantage of it’s various features. Let’s take a look at the interface following a standard installation –
Following installation we have a basic screen with various menu options – we need to create a new ‘RDCMan Group’ which has a file extension of .rdg
We can either use the typical Windows shortcut of Ctrl+N to create a new item or via the File menu. The RDCMan group object will contain all of our settings, folder structures and remote desktop sessions. It’s important to consider where this will be stored as we can store authentication credentials within this object. I typically suggest saving this to your personal documents folder as it most cases in a business you are the only user to have access and it is likely backed up so you won’t lose it if your workstation dies on you.
It is possible to share the .rdg file with other people – if you’re going to do this I’d suggest removing any credentials you may have saved (see below) or it may cause problems when they try to open and use it. Assuming all is good though this is a great way of building out a connection profile that can be shared between admins and new starters.
Now that we have our root level group created we can begin to create a folder structure to represent the various systems we manage on a daily basis. It is possible to add servers (remote desktop sessions) directly to this root object however I would recommend you create a logical folder structure to better organise and manage your connections. Let’s add a new group and review some of the options provided to us.
We are presented with a new menu which gives us the chance to configure inheritable options for the remote desktop sessions which will be added to this group. As you can see below I have given the group a name of ‘Domain Controllers’ and also added a comment. We will come back to the other menu options later in the article so for now don’t worry about them.
The next step is to add some sessions to this group – in this case I will add the two domain controllers from my home lab.
In the first example I have only provided a short name for the ‘Server name’ attribute – either a fully qualified domain name (FQDN) or IP address is also a valid option. As my system has been setup correctly to append my lab domain name to short name addresses this will work just fine for me. In the second example below I have used the IP address of the second domain controller but amended the ‘Display name’ to show the short name. By default the display name field will match the server name field.
There are now two sessions contained within our ‘Domain Controllers’ group. With the group selected we see that both objects are in a ‘Disconnected’ state which is also demonstrated by the red circle with a white cross. The sessions have a title and a white box below, when we connect to a session this area will display a small thumbnail sized image of the current session screen. I’ll add a few more groups and sessions to demonstrate how things look.
As you can see we have a parent child relationship between groups and servers – it’s important to note that you can’t create another group within an existing one, groups can only contain servers. It’s probably obvious but you can shrink groups by clicking on the – symbol next to the name and of course once shrunk this icon changes to a + which can be clicked to expand said group again.
Right now we need to save our progress – this can be done via the File menu.
If you make changes to any aspect of the .rdg object and try to exit the program it will prompt you that there are changes which have not been saved. At this point you can either choose to save them, click the ‘No’ option to quit without saving or use the ‘Cancel’ option to return to the program.
The eagle eyed amongst you will have noticed that while creating a group there was an option for ‘Smart Groups’ – what exactly are these I hear you cry? Well the simple answer is that smart groups are a way of defining simple logic that adds a session to a group based on the parameters we provide.
Let’s take a look using our domain controllers as an example.
In my example you can see I have provided a group name and then defined some simple logic – any session which matches ‘BSA-DC*’ will be added to this group. We have a few options when defining the smart group parameters as shown below –
Smart groups are easy to identify in the program as they have a lightening bolt symbol next to them – I have added the ‘Smart Group’ text as part of the group name, this is not something that is done for you.
I’m sure you’ve already realised how useful this type of grouping can be, it’s certainly worth playing around with.
Options and Group Settings
Time to make some final configuration choices and we can start connecting to our servers. The ‘Tools’ menu provides a link to the program options, let’s take a look.
The ‘General’ settings are fairly brief – I find it quite useful to have the reconnect option enabled (default on install), if the program crashes and you had a number of connections active it’s a handy way of quickly getting them all back again without having to remember what they were.
The ‘Default group settings’ menu is very similar to the standard options menu on MSTSC.exe but with a few extra sections that I will mention in more detail below. The other menu options are pretty self explanatory and likely familiar to anyone who has looked through the MSTSC.exe equivalents – I’ll provide screenshots for reference.
First off we have the ‘Logon Credentials’ tab which allows us to pick the default logon settings we will use when connecting to a session. In this case I have a domain admin account from my home lab Active Directory configured.
The next tab I want to draw your attention to is the ‘Profile Management’ option – this allows us to configure the various credential profiles which we can then quickly assign to new sessions when we add them. This is vital if like me you work in a AD forest and also support other AD domains or systems that run in a DMZ using local credentials for example.
Adding a profile is very simple, you simply provide a name for the new profile and then the username, password and where relevant domain name.
Finally you may be wondering if the program is saving credentials how and where is it doing so? This is an important consideration and RDCMAN provides two options based on the documentation and menu settings. Credentials can be protected either with the local users credentials using CryptProtectData or an x.509 certificate can be leveraged. The choice of which is configured in the ‘Encryption Settings’ tab as shown below.
If you select to use a certificate your account will need a valid one to choose from. Below I have provided an example screenshot from a system with no user certificate and from another with a user certificate. If you are running in an Active Directory environment you likely have a certificate authority in your domain you can request from.
I’m not going to discuss the following tabs as they are all pretty self explanatory to anyone who has used the MSTSC program and looked at the options it has.
That’s all of the ‘Default Group Settings’ menus out of the way, let’s take a quick look at the remaining ‘Options’ tabs. I think these are all pretty self explanatory so I won’t go through explaining them all.
If you’ve ever found yourself in a position where you need to logon to a whole group of servers to perform some task or check something (and PowerShell or other remoting tools are not an option) the ‘Connect Group’ option is a fantastic feature. Simply right-click on the desired group and it is the first option available to you.
Conversely if you need to disconnect or log off from all the servers in a group you can use those options as presented in the right-click menu shown above.
This ability to connect en-masse to a large number of servers is incredibly useful, it’s something I use on a regular basis and saves me opening one MSTSC window after another and filling in the details for them all.
The program also supports a CTRL+F ‘Find’ option which again is really handy when you have a large number of servers, even when using groups.
There are a few other options and capabilities of RDCMAN but to be honest I think the most important parts have been covered to get you up and running. Hopefully if you haven’t seen or used the tool before this will spark some interest and help make you more productive. As a reference I’ve included some of the programs help output below.
By default, RDCMan will open the files that were loaded at the time of the last program shutdown. You can override this by specifying a file (or files) explicitly on the RDCMan command line.
Additionally, the following switches are accepted:
/reset – reset the persisted application preferences such as window location and size.
/noopen – do not open the previously loaded files, starting with an empty environment.
/c server1[,server2…] – connect specified servers
/reconnect – connect all servers that were connected at shutdown without prompting
/noconnect – do not prompt to connect servers that were connected at shutdown
Credential profiles store logon credentials globally to RDCMan or in a file. This allows for using the same stored credentials across groups that do not have a common ancestor. One use scenario is to store credentials used for logging into servers and gateways in a single place. When a password changes, it can be edited once. Another scenario is when sharing RDG files across a group. Instead of storing passwords in the file (which would have issues due to the user-specific nature of the encryption RDCMan uses), a profile is created such as “Me” which each user defines in their Global store.
You can update the settings for a credential profile in two ways. The first is to edit from a credentials dialog and then save the exact same profile name/domain to the same store (file or global). That will ask if you want to update. The other way is to go to the group properties for the credential store (again, file or global) and use the Profile Management tab.
File scope credential profile passwords are encrypted according to the containing file’s Encryption Settings. Global credential profiles use the Default Group Settings.
RDCMan can encrypt the passwords stored in files either with the local user’s credentials via CryptProtectData or an X509 certificate. The Encryption Settings tab is available in the Default Group Settings and File Settings dialogs.
Personal certificates of the current user which have a private key are available for encryption. You can create such a certificate in the following manner:
makecert -sky exchange -r -pe -a sha1 -len 2048 -ss my -n "CN=MyRDCManCert"
This will create a certificate called “MyRDCManCert” in the Personal Certificates store of the current user. To install this cert on another computer, you must export it with the private key.