Adding RD Gateway to your Quick Deployment of RDS in Windows Server 8

In previous blog posts I showed the two different ways of deploying RDS via Scenario Based Deployment (SDC) . Remember that we had the option to either select Quick Deployment or Standard Deployment. more info see here and here.

In this blog post, we’ll continue our build on the Quick Deployment that we did earlier. Remember that we experienced that rolling out the Quick Deployment Scenario using Quick Deployment is great for configuring a lab for testing or demo purposes. In those kinds of environments, you might also want to add the Remote Desktop Gateway (RDGW), so let’s take a look at how we can add this role using the new Server Manager.

We open up the Server Manager and browse to Remote Desktop Services -> Overview. We can simply right-click the Remote Desktop Gateway icon and choose “Add RDG Servers”.

We are then presented the wizard below where we are able to select the server(s) that we want to deploy the RDGW role on. Remember that you first need to add these servers to your Server Manager Console in order to see them. (Option 3. Add other servers to manage).

We can now specify Fully Qualified Domain Name (FQDN) that we want to publish the RDGW on. The wizard will generate a self-signed certificate based on the name that we specify here.

The confirm dialog sums up the details of the installation, and by hitting "add" the installation of the RDGW role will start.

The progress bar that follows, shows us steps in the installation and shows “Server Configured” upon completion.

That’s it. So again, we installed Server Roles remotely using the consolidated Server Manger with which we manage multiple servers and their roles remotely.

So, let’s take a look at what the wizard did for us. It won’t be a surprise that the wizard added the RDGW role to our target server and that we are also able to manage it remotely using the Server Manager.

Another entry that’s added to the server manager here is Network Policy and Access services which enabled you to manage NAP. As you might now, NAP (either locally en central) is a part of a RDGW solution (details see here: NAP & RDGW).

When we open up the Remote Desktop Gateway Manager, we see a familiar look.

Deploying the RDGW using the Quick Deployment also provides us with a default configuration inside RDGW Manager.

The wizard created a default RDCap named RDG_CAP_AllUsers with the following summary

If the user is a member of any of the following user groups:
LAB\Domain Users
If the client computer is a member of any of the following computer groups:
Not applicable (no computer group is specified)
If the user uses the following supported Windows authentication methods:
Password
Allow the user to connect to this RD Gateway server and disable device redirection for the following client devices:
Not applicable (device redirection is allowed for all client devices)
After the idle timeout is reached:
- Not applicable (no idle timeout)
After the session timeout is reached:
- Not applicable (no session timeout)

So it basically allows all domain users access to the RDGW by means of a password. Of course, this isn’t something you would deploy on a production environment. However, this makes setting up a RDS environment for demo of lab purposes, which is the main goal of the Quick Deployment, very easy.

Furthermore, the wizard also created a RDRap named RDG_AllDomainComputers wich basically allows domain users access to resources in the group LAB\domain computers (which means all computers in the domain). Again, this is not intended to use in a production environment but it’s an excellent way to setup RDGW for a lab very quickly.

We’re now able to connect to a RDSH server using the new RDGW server.

That concludes this blog post on adding an RDGW role to your Quick Deployment RDS Scenario.
In my next blog post I'll cover some of the new features of the RD Gateway role itself.

Take RDS management to a higher level with Windows Server 8

In a previous blog post, I discussed the Scenario Based Deployment of RDS in Windows Server 8, and more recently, discussed the new features of RD WebAccess in Windows Server 8. In this blog post, we’ll take a deeper look into what the new Server Manager has to offer when it comes to managing RDS Roles in Windows Server 8. I must say, I was quite surprised, in a positive way!

Let’s walk through the scenario. In a previous blog post I showed the steps to perform a Scenario Based Deployment of RDS using the standard scenario and spreading the different RDS roles over separate servers. This time we’ll do it differently and choose the Quick Scenario which deploys the RDS Roles (RDSH, RDWA and RDCB) on a single machine in order to create a RDS environment very quickly that you could i.e. use as a demo environment.

We start by launching the Add Roles and features wizard and choose Next.

We then select the Scenario Based Installation and choose next. 

As mentioned earlier we’ll go for the Quick Deployment in order to create a single server that contains all the roles that the RDS scenario is able to deploy. 

In this case, we want to publish applications and desktops on a RDS server, so we choose session virtualization deployment.

The next step is to select the server on which we want to deploy the roles. We’re reminded that the deployment will restart the server if necessary. Just a quick note: what I didn’t show you is that I pre-installed the RDSH role on this machine (using the Add Roles wizard) as this is a requirement for this type of Scenario Based Deployment where you run the wizard on the machine itself.

The deployment was successful! If you read my earlier blog post on Scenario Based Deployment, you’ll see a difference here. In that previous deployment, I got an error at the end of the wizard saying configuration failed: SetAllowTSConnections failed. I had configured a GPO that sets the SetAllowTSConnections to allow. In that post I assumed that the GPO caused the error at the end of this wizard and apparently, I was right. As a pre-installation action I removed the GPO setting, and set the SetAllowTSConnections back to default, and now no errors occur at the end of the installation.

Now let’s go back to the new server manager, we’ll notice some great new options and management features there! We now have a graphical overview of the RDS environment showing us that we have a RDWA, RDCB and RDSH role.

We can even add or remove roles from within this interface! I.e. adding a new RDSH server is done my right-clicking on the RD Session Host icon and choosing Add RDSH server.

We can also add the role RD Gateway which is not part of the Scenario Based Deployment itself.

When we drill down one-step, notice that we now have something new there that is called Collections, and underneath the first collection called QuickSessionCollection which the Scenario Based Deployment wizard created for us. (click the image to expand)

  

When we look into that QuickSessionCollection we see; the properties of the RDSH servers (groups, resources), the RemoteApp Programs, the host servers and the active connections on this SessionCollection. Normally you’d had to gather this information in different places, it’s now nicely gathered and consolidated in the Server Manager, which is a big improvement!

From this console we can i.e. choose Edit Properties.

This brings us to the properties page of the collection where we can set security groups, timeout settings, redirection settings etc. Before, you would edit or view these properties on the RDP-tcp properties screen.

We can also manage our Remote Apps from this console! As you can see, I added two RemoteApps (calculator and wordpad).

When we choose the properties of a RemoteApp, we can edit the settings that we previously had to do in the RemoteApp Manager. Again, all from within the Server Manager!

Notice that we can now enter a folder name! If you read my previous blog post you’ll remember that inside the new Remote App .aspx files I noticed that there was new code regarding to folder management of your Remote Apps. I promised to further take a look at that later, so here it is! We enter the folder name “Accessories” here, refresh the RD WebAccess page, and Voila!

This is definitely a big improvement of RD WebAccess. I’ve seen people asking for this feature in TechNet Forums and blog posts quite a lot.

Conclusion so far:Microsoft has done great work with the new Server Manager. It definitely makes managing your RDS environment a whole lot better. I really like the fact the all RDS roles, settings and even Remote Apps can now be managed through a consolidated interface in the Server Manager.

I will drill down in the Server Manager some more and start using it some more by adding additional RDSH servers and more RemoteApps to get a good feeling on how it will perform and what working with the new Server Manager will be like. But so far, it looks very promising!

Remote Desktop Web Access in Windows Server 8

In an earlier blog post I showed and discussed the Scenario Based Deployment of Remote Desktop Services. (see here: Scenario Based Deployment). Remote Desktop WebAccess (RDWA) is part of this deployment. In this blog post I will discuss the changes to this role a bit further and show you what RDWA looks like in Windows Server 8 (at least inside the developers preview).

When you install the Remote Desktop WebAccess (RD WebAccess) role, either via de Scenario Based Deployment or manually using the Server Manager, the RD WebAccess page becomes available under https://hostname/rdweb (no difference there, compared to Windows Server 2008 (R2). When we browse this URL, the login screen actually looks pretty much the same.



We can see that the RD WebAccess page in the Developers Preview still needs some work done, as it still states “Windows Server 2008 R2” in the lower-left corner. :-)

When we logon, we are presented with the screen below. Again, not very different compared to Windows Server 2008 R2. A difference that we do see however is “Current folder: /” Is that what we think (and hope) it is? It seems that in upcoming releases, we will actually be able to put RD WebAccess RemoteApps Programs inside (sub)folders! That’s great! I have seen lots of requests and questions on about this on TechNet forum!



When we look at the source of default.aspx quickly, it seems my thoughts a confirmed! We already see declarations of strings containing errors and messages of a folder hierarchy structure.

const string L_BadFolderErrorTitle_Text = "Folder does not exist. Redirecting...";
const string L_BadFolderErrorBody_Text = "You have attempted to load a folder that does not exist. In a moment, you will be redirected to the top-level folder.";

Also, note that we’re missing a tab here called “Configuration”. Am I perhaps not logged on as an Administrator? Yes, I am. So why is it not showing? It simply isn’t there yet. When we look at the content of the folder that RD WebAccess uses (that is still C:\Windows\Web\RDWeb\Pages) we see the following content:



Which is different compared to Windows Server 2008 R2 as we can see below.



We’re missing config.aspx. This configuration is moves to the Server Manager. I'll talk about that more in an upcoming blog post!

There is another new file in the en-US folder called RDWAstrings.xml. When we open this up we’re presented with, as the name suggests, strings that we can modify. A snippet of the code is shown below.

<string id="ControlUpgradeVistaBody_2">.<br/><br/></string>
<string id="SearchingForApps">Searching for available RemoteApp programs... </string>
<string id="CurrentFolder">Current folder: </string>
<string id="ParentFolder">Up</string>

So yes, we can already change the name of the root-folder using the CurrentFolder string :-)



In my next blog post I will discuss the new functionality that has moved from the "Configuration" tab in the RD WebAccess page to the Server Manager. Stay tuned!