Using PowerShell to control RDS in Windows Server 2012 (Part 1)

If you would like to read the next part in this article series please go to Using PowerShell to control RDS in Windows Server 2012 (Part 2).

Introduction

PowerShell has been around for many years now. There is no way to work around PowerShell anymore, and you should not even want to work around it. With every new release of every new Microsoft product or service, we see an even tighter integration with PowerShell. With the upcoming release, it’s even bigger than before. With Windows Server 2012, we have over 2400 cmdlets available! That is a huge number! In this article, we will take a look at how PowerShell is integrated with Remote Desktop Services in Windows Server 2012. We will dive into PowerShell commands for both RDS scenarios that are available with Windows Server 2012. That is, the Virtual machine-based desktop deployment as well as the Session-based desktop deployment.

Let’s get started

As a first step, let us import the new RemoteDestop module that is available with Windows Server 2012. We can do so using the following command;

PS C:\Users\administrator.CRFB> import-module RemoteDesktop

An amount of cmdlets, specifically for Remote Desktop Services, has now been imported. The next obvious command to look at is the command to perform a scenario-based deployment. As you might know with Remote Desktop Services in Windows Server 2012, there are two ways of deployment. There is a Role-and-feature based installation, which was also available with Windows Server 2008 (R2) but new with Windows Server 2012 is the Scenario Based Deployment. With this type of deployment you define a complete scenario and let the wizard install all the necessary roles rather than manually installing and configuring all individual roles.

Installing a Session-based desktop deployment

In this example we’ll emulate a Quick Deployment meaning we’ll install all the initial roles of a deployment (RD Session Host, RD Connection Broker and RD WebAccess) on one server. The command to use in this scenario is New-SessionDeployment

SYNTAX
 New-SessionDeployment [-ConnectionBroker] <string> [-WebAccessServer] <string> [-SessionHost] <string[]>

To perform the Quick Deployment of a Session-based desktop deployment we run the following command;

New-SessionDeployment -ConnectionBroker LS01.CRFB.Local -WebAccessServer LS01.CRFB.Local -SessionHost LS01.CRFB.Local

When we launch this command, we can actually see the progress of what steps are taken to complete the configuration. The three roles mentioned earlier are being installed and configured. Below are some screenshots so you can get an overview of the steps that taken.

At first, the desired setup is being validated.


Figure1

Then the setup starts by installing the RD Connection Broker role.


Figure 2

After that, the RD Web Access role is being installed.


Figure 3

The last role that gets installed is the RD Session Host. As this role requires a reboot, this is also performed by PowerShell as you can see below.


Figure 4

As a final step, all the roles are “glued together” and ready for further configuration.


Figure 5

After the PowerShell setup completes we can open up the Server Manager console on the destination machine and we see that the Remote Desktop Services tab is available and that the three roles are actually installed.


Figure 6:
Server Manager Console

As you might know, new with RDS in Windows Server 2012 are Collections. If you would install the Quick Deployment as described earlier using the GUI, it would also install and configure a first Collection. That takes us to our next step, installing a new collection using PowerShell. The following command will do so; New-RDSessionCollection.

SYNTAX

New-RDSessionCollection [-CollectionName] <string> -SessionHost <string[]> [-CollectionDescription <string>]  [-ConnectionBroker <string>]  [<CommonParameters>]

To perform the installation of a new Collection inside the deployment we created earlier, we run the following command;

New-RDSessionCollection -CollectionName MySessionCollection -SessionHost LS01.CRFB.Local -CollectionDescription “This Collection Serves purpose A, B and C” -ConnectionBroker LS01.CRFB.Local

Again, we receive a nice progress bar about the installation and configuration which looks like the screenshot below.


Figure 7

In addition, when the configuration finishes, we are provided with the following summary;


Figure 8:
Summary

When we refresh the Server Manager, we can see that the Collection is actually successfully installed and configured.


Figure 9:
Collections

In addition, the general information we provided in the command line is set.


Figure 10:
General Information

Note, that by default the group <domain>\domain users will be assigned to allow to connect to the created collection. You will obviously want to change that when dealing with a production environment.

Installing a Virtual machine-based deployment

The same steps can be used to install and configure the other RDS flavor, Virtual machine-based deployment. The command to create a Virtual machine-based deployment is New-RDVirtualDesktopDeployment and the corresponding shell is as follows

SYNTAX

New-RDVirtualDesktopDeployment [-ConnectionBroker] <string> [-WebAccessServer] <string> [-VirtualizationHost]  <string[]> [[-CreateVirtualSwitch]]  [<CommonParameters>]

If we would specify the same values for RD Connection Broker, RD WebAccess and RD Session Host (in this case RD Virtualization Host) this will result in a configuration comparable to the one you would get when running Quick Deployment using the GUI.

After the installation is complete the following command can be used to create a Collection for this deployment; New-RDVirtualDesktopCollection.

The syntax for this command is as follows;

SYNTAX
New-RDVirtualDesktopCollection [-CollectionName] <string> -PersonalUnmanaged -VirtualDesktopName <string[]> [-Description <string>] [-UserGroups <string[]>] [-ConnectionBroker <string>]  [-AutoAssignPersonalVirtualDesktopToUser] [-GrantAdministrativePrivilege] [-Force]  [<CommonParameters>]

And of course, many more parameters can be supplied in case we are doing a standard (non-quick) deployment.

Creating RemoteApps

The RemoteDesktop PowerShell module also has the ability to create, update and delete RemoteApps. There is a PowerShell command to retrieve RemoteApps and their properties from a specified Collection and RD Connection Broker. This cmdlet is Get-RDRemoteApp. For example to retrieve all RemoteApps the following command can be used.


Figure 11:
RemoteApps

The command to create a new RemoteApp is New-RDRemoteApp.

SYNTAX
Set-RDRemoteApp [-CollectionName] <string> -Alias <string> -VirtualDesktopName <string> [-DisplayName <string>] [-FilePath <string>] [-FileVirtualPath <string>] [-ShowInWebAccess <bool>] [-FolderName <string>] [-CommandLineSetting <CommandLineSettingValue> {DoNotAllow | Allow | Require}] [-RequiredCommandLine <string>] [-UserGroups <string[]>] [-IconPath <string>] [-IconIndex <string>] [-ConnectionBroker <string>] [<CommonParameters>]

In this example, we create a RemoteApp to deliver WordPad. We use the following command;

new-rdremoteapp -Alias Wordpad -DisplayName WordPad -FilePath “C:\Program Files\Windows NT\Accessories\wordpad.exe” -ShowInWebAccess 1 -collectionname MySessionCollection -ConnectionBroker LS01.CRFB.Local

Again, during the creation of the RemoteApp we are provided with a progress bar.


Figure 12:
Progress Bar

In addition, when the creation is finished to command output the details of the creation.


Figure 13

When we refresh the Server Manager console we see the RemoteApp successfully added.


Figure 14:
RemoteApps

The RemoteDesktop module also supplies cmdlets to update RemoteApps (Set-RDRemoteApp) and remove RemoteApps (Remove-RDRemoteApp).

When you create a new RemoteApp using the GUI wizard it would also show a list of available applications that can be added. The equivalent PowerShell Command for this action is Get-RDAvailableApp. Running this command while specifying the connection broker and collection can result in an output as follows:


Figure 15

Perform actions on multiple hosts

Besides a lot of Set-commands that we have been covering so far, there are also many Get-commands inside the Remote Desktop PowerShell module. These can be handy when you need to perform some actions on multiple RD Session Hosts.

The following command for example shows all the servers containing at least the RD Session Host role.


Figure 16

In this case, it’s only one server, but if there are more servers and we could write the output of this command to a variable, we would be able to loop through this set of RD Session Host Servers, and for example install a certain feature. We would be able to perform any action we want.

Conclusion

As stated in the introduction, Windows Server 2012 comes with an enormous amount of PowerShell cmdlets. In this article, we’ve only seen a few of them. There are many more and you can image the power behind these commands to install, configure and maintain your Remote Desktop Services environment on Windows Server 2012. In a future article I might dive deeper into the power of PowerShell related to RDS in Windows Server 2012.

If you would like to read the next part in this article series please go to Using PowerShell to control RDS in Windows Server 2012 (Part 2).

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top