It turns out that much of the configuration data for RDSH is stored in the Win32_TSGeneralSetting class in WMI in the root\cimv2\TerminalServices namespace. The configured certificate for a given connection is referenced by the Thumbprint value of that certificate on a property called SSLCertificateSHA1Hash.
UPDATE: Here's a generalized Powershell solution that grabs and sets the thumbprint of the first SSL cert in the computer's personal store. If your system has multiple certs, you should add a -Filter option to the gci command to make sure you reference the correct cert. I've left my original answer intact below this for reference.
# get a reference to the config instance
$tsgs = gwmi -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'"
# grab the thumbprint of the first SSL cert in the computer store
$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint
# set the new thumbprint value
swmi -path $tsgs.__path -argument @{SSLCertificateSHA1Hash="$thumb"}
In order to get the thumbprint value
- Open the properties dialog for your certificate and select the Details tab
- Scroll down to the Thumbprint field and copy the space delimited hex string into something like Notepad
- Remove all the spaces from the string. You'll also want to watch out for and remove a non-ascii character that sometimes gets copied just before the first character in the string. It's not visible in Notepad.
- This is the value you need to set in WMI. It should look something like this: 1ea1fd5b25b8c327be2c4e4852263efdb4d16af4.
Now that you have the thumbprint value, here's a one-liner you can use to set the value using wmic:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"
Or if PowerShell is your thing, you can use this instead:
$path = (Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $path -argument @{SSLCertificateSHA1Hash="THUMBPRINT"}
Note: the certificate must be in the 'Personal' Certificate Store for the Computer account.
There is no more /console RDP switch since Windows Vista.
Yes, the Remote Desktop Services mmc snapins that you were used to in 2008 have been removed.
A Windows license grants you two "administrative" simultaneous remote desktop sessions before you need to install the Remote Desktop Services role with CALs. There is no "2 administrative connections +1 console (which would make 3 simultaneous interactive sessions)" though. It's just two. You can use the /admin switch with the Remote Desktop Client to avoid using up CALs when the RDS Session Host role is installed, but you can only have two admin connections at a time regardless.
From this Microsoft article which does a great job of explaining:
At any point in time, there can be two active remote administration sessions. To start a remote administration session, you must be a member of the Administrators group on the server to which you are connecting.
To RDP to a Windows Server 2012 VM hosted on Azure, you need to ensure that you have opened the endpoint in the Azure portal (think of it like a firewall ACL) in Azure, and also make sure RDP (port 3389-in) is allowed through the Windows Firewall as well. Then you need to make sure you're logging in with a user account who has 'Remote Desktop Users' privileges or better.
Next, disable the setting Restrict Remote Desktop Services users to a single Remote Desktop Services session by using the Group Policy Object Editor MMC-snapin to edit your Local Policy.
It's under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections.
Run gpupdate after you make changes to the policy to apply them immediately.
I have a Server 2012 VM hosted on Azure, and I just followed the above steps, and now I am logged in twice, interactively, as the same user.
Best Answer
I have had great success in making scenarios like this work in VMWare ESXi, but just one experiment with Hyper-V. In that particular instance, I ended up with a very nice setup for client VMs with vGPUs working fine, but for Windows Server edition, I could not make it work. This is actually detailed by MS here. Quoting the document:
That pretty much says it will not (or at least is not intended to) work the way you want.
Using VMWare, you can make it work by passing the physical GPU through to a particular VM. If you are using one of the GPUs that actually work well in this scenario, you can get what you want. I don't know if something similar can be done in Hyper-V.