Extending Remote Desktop Services via PowerShell – Part 2

(Post courtesy Manoj Ravikumar Nair, who you can follow on his excellent blog at https://www.powershell.ms)

Previous Post: Extending Remote Desktop Services via PowerShell – Part 1

Configuring Remote Desktop Session Host Server using RDS Provider for PowerShell

If you have installed the RD Session Host Role via PowerShell, the first thing you will note is that the RD Session Host Server is set to “Don’t allow connections to this computer” and the Remote Desktop Users Group is empty.

clip_image001

clip_image002

To allow connections, we will browse to the SessionSettings Container and set the value of AllowConnections to 1.

Dir .\AllowConnections | fl *

Set-Item .\AllowConnections 1

clip_image004

clip_image006

Having set the value of AllowConnections to 1, we can verify if the RDS Server now accepts connections by going to the Remote Properties of the RD Session Server

clip_image007

Awesome, it worked. But it is using a less secure way to allow connections. In other words, it is not using Network Level Authentication.

To enable the NLA, we will have to browse to the path RDS:\RDSConfiguration\Connections\RDP-Tcp\SecuritySettings and set the value of the UserAuthenticationRequired to 1 as shown in the screenshot below.

Set-Item .\UserAuthenticationRequired 1

If you are wondering where did I get this path, its all about browsing each directory and reading the help by using the dir <setting name> | format-list *

There are so many settings in Remote Desktop Services and hence it made sense to not to create a cmdlet for each configuration. Rather expose them via the RDS Provider and simply use the get-item or the set-item to retrieve and configure settings accordingly.

clip_image009

When we pop up the Remote Properties of the RD Session Host Server, we see that it has now be configured to use NLA

clip_image010

So we set up the RD Session Host server to accept connections using NLA. Now, let’s populate our Remote Desktop Users Group.

To add Users to the Remote Desktop Users Group, we will use the Microsoft.TerminalServices.PSEngine.UserGroupHelper Runtime. To view a list of static members, I pipelined the runtime to Get-Member (alias is gm) and used the –static parameter

[Microsoft.TerminalServices.PSEngine.UserGroupHelper] | gm –Static

clip_image012

As verified earlier via GUI and now with PowerShell below, the Remote Desktop Users group is empty

[Microsoft.TerminalServices.PSEngine.UserGroupHelper]::ListMembers(“Remote Desktop Users”)

clip_image014

But if we use the same Runtime to list members of the Administrators Group which is obviously having the Domain Admins and the Administrator Account, we do get results displayed as shown below

clip_image016

Pay close attention to the syntax in which the Administrator (User Account) and the Domain Admins (Group) has been returned.

So if we need to add a group say Domain Users to the Remote Desktop Users Group, the input should go as Domain Users@POWERSHELL

We will now leverage the AddMembers member to add Domain Users to the Remote Desktop Users group

[Microsoft.TerminalServices.PSEngine.UserGroupHelper]::AddMembers(“Remote Desktop Users”, “Domain Users@POWERSHELL”)

clip_image018

clip_image019

Configuring Certificates for our RD Session Host Server:

To assign a SAN certificate to my RD Session Host Server, we will first need to obtain the thumbprint of the Certificate.

clip_image020

You can get this information either by accessing the Details tab of the Certificate or via PowerShell itself. Browse to the Cert: PS Drive as shown below:

Dir –path Cert:\LocalMachine\My

clip_image022

Copy the Thumbprint and provide it as an input to the following command shown below

clip_image024

Let’s verify via the GUI.

clip_image025

To digitally sign our RemoteApp Servers, we will assign the same SAN certificate to the RemoteApp Configuration.

Browse to the DigitalSignatureSettings container and first set the value of HasCertificate to 1 and then it will prompt you for the certificate thumbprint as shown below:

clip_image027

Check the RemoteApp Manager and refresh it if required. It should have the Digital Signature Settings use the SAN certificate we just assigned.

clip_image028

While on RemoteApps, let quickly populate our TS Web Access Computers Group with the name of our FUJI Server which is essaying the role of the RD Web Access Server

To do that, we will connect to the WebAccessComputers container (RDS:\RemoteApp\WebAccessComputers) and use the New-Item command to add the computer FUJI as given below

New-Item –Name FUJI@POWERSHELL

The following command will work from any location within PowerShell

New-Item –Path RDS:\RemoteApp\WebAccessComputers -Name FUJI@POWERSHELL

clip_image030

clip_image031

clip_image032

Configuring IP Virtualization:

To Configure IP Virtualization, we will first set the value of VirtualIPActive to 1 and then set the value of VirtualIPMode to 1 which defaults to Per Program

Set-Item .\VirtualIPActive 1

Set-Item .\VirtualIPMode 1

clip_image034

Again, remember the golden rule, to see what 1 or 0 means, refer the help by using the dir <setting name> | format-list * command

clip_image035

To add a Program to the list, we will use the new-item command as shown below

New-Item –Name Notepad

clip_image037

clip_image038

Installing RemoteApps:

To Add a Program to the RemoteApp Program List, you the following command. In the example below, we would be adding the Notepad application and set it to not use any CommandLine Argument

New-Item –Path RDS:\RemoteApp\RemoteAppPrograms –Name “Notepad” –ApplicationPath “C:\Windows\System32\Notepad.exe” –CommandLineSetting 0

clip_image040

You can further drill down and go to the Notepad Container to assign users to the Notepad Application

clip_image042

clip_image044

clip_image046

clip_image047

clip_image048

In this way, you configure every setting that is available on the RD Session Host Server by using the RDS Provider for PowerShell.

Offline, I will install the RD Session Host Role on another server, FUJI, which also has the RD Web Access Role. Ideally we would separate out the workloads but since I have just a few VMs to play around with, we would use FUJI as our second RD Session Host Server.

Also note that the RD Web Access Role does not install the PowerShell Module for Remote Desktop Services which is quite obvious because in a typical environment there are only few instances of the Web Access role and it has just one time configuration involved.

Next Post: Extending Remote Desktop Services via PowerShell – Part 3