RDMS on Windows Server 2012: The Where, the Why and the How..

By now I’m sure you’re familiar with the Remote Desktop Management Services (RDMS) as part of the new Server Manager in Windows Server 2012. The RDMS combines most of the functions we used to have in separate MMC snap ins in previous versions of Windows Server. RDMS is now the central management interface for all your deployments (both Session-Based as well as Virtual machine-Based).

If you’d like to read more about the actual deployment processes and RDMS configuration, the links that conclude this post might help.

In this post we’ll dive a little deeper to see where this RDMS data is (initially) stored, under what conditions you can successfully access the RDMS and what errors you may run into.

Let assume we would like to set up the following deployment:

Hostname	Roles
AD01	Active Directory Domain Services
RDS01	RD Connection Broker
RDS02	RD Session Host RD Web Access

For more information on this type of deployment also see this TechNet Wiki; Deploying the RDS Quick Start deployment type in Windows Server 2012 (for Session Virtualization)

Let’s assume that we perform the Scenario Based Deployment (Remote Desktop Services Deployment) using the Server manager console on the RDS01 and deploy the roles according to the table above. Note that as a prerequisite we added the RDS02 as a “to be managed server” to the Server Manager on this RDS01.

During the installation process a Windows Internal Database is created on the server that we selected ad the initial RD Connection Broker server. The corresponding .mdf and .ldf of this database are placed in C:\Windows\rdcbDb

When the deployment succeeds, we can open the RDMS (as part of the Server Manager) on the RDS01.

By selecting the Remote Desktop Services Link as shown above we can obviously manage our RDS environment as the screenshot below shows, nothing new there.

Now what would happen if we would open up the Server Manager on the RDS02 (now containing the RD Web Access and RD Session Host roles). We would also see the Remote Desktop Services link, since at least 1 RDS role is installed on the RDS02, however if we click we’re presented with the following error.

“There are no RD Connection Broker servers in the server pool.”

If we’d want to manage the environment using the RDMS on this server we have to add the server running the RD Connection Broker role to the Server Manager by using the “Add other servers to manage” option.

If we would try to open the RDMS console on a server where the RD Connection broker is added as a server to be managed, but at least 1 server that is also part of the deployment is not added, we get a little different error.

“The following servers in this deployment are not part of the server pool”

Conclusion: we need to add all servers to the Server Manager that are part of the deployment in order to be able to use to RDMS on that server to manage that deployment.

In some scenarios you might perform the RDS deployment on some sort of central management server to perform al RDMS related tasks (and maybe also other administrative tasks) on that server. This is possible, but do note though that the RDMS database is still placed on the first RD Connection Broker part of that deployment. The exception here is when you configure RD Connection Broker High Availability (HA) as part of your post-installation configuration. After successfully performing the HA the RDMS database is placed on a centrally running SQL Server instance. To configure HA also see Installing and configuring RD Connection Broker High Availibilty in Windows Server 2012 .

Also note that although the name is RD Connection Broker HA, in a sense we’re also doing HA on the RDMS since the database does not only contain RD Connection Broker information, but all RDMS information.

Also note that from 1 server you can only manage 1 deployment at the same time. However, you can dynamically switch deployments. If you added more RD Connection Brokers from multiple deployments to a single RDMS console, you can use the option called “Connect to Another deployment” to switch between deployments.

That will show you what deployment you’re currently connected to and what other deployment(s) you can currently switch to.

Additional links to TechNet Wiki’s that describe working with the RDMS in more detail:

Scenario Based Deployment of RDS in Windows Server 2012
Distribution of Remote Apps and desktops in Windows Server 2012
Deploying and configuring RD Gateway in Windows Server 2012 Deploying and configuring RD WebAccess in Windows Server 2012

New Article: Remote Apps and the Metro RDP client

My new article titled “Remote Apps and the Metro RDP client" on virtualizationadmin.com just got published. The article is about the integration of RemoteApps running on Windows Server 2012 (8 Beta) launched from a Windows 8 client.

“…Introduction

Remote applications that run seamlessly on a client desktop have been around for some time now. With Windows Server 8 Beta, Microsoft has put in a good effort to make the RemoteApps on the Windows 8 desktop interact and integrate better than before. In this article, we will look at the integration of RemoteApps running on Windows Server 8 Beta launched from a Windows 8 client...”

Read the complete article here:
http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/remote-apps-and-the-metro-rdp-client.html

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!