In this Wiki, we will deploy a (Remote Desktop Services) Session Based Desktop Deployment on Windows Server 2012 using PowerShell. We will perform the installation of the three roles that are part of the Scenario Based Deployment (RD Session Host, RD Connection Broker and RD WebAccess) and we will create the first Session Collection. All by using the new "RemoteDesktop" PowerShell module.

(More Wiki's on the RemoteDesktop PowerShell module in Windows Server 2012: )
Getting 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 wiki, 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

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 taken.

At first, the desired setup is being validated.

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

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

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.

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

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.

Creating a new Session Collection


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 the first Collection. That takes us to our next step, installing a new collection using PowerShell. The following command will do so: New-RDSessionCollection.


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.

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

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

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

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.