Some windows of a Remote Desktop Services (Terminal Services) RemoteApp application might not be displayed correctly in Windows Server 2008 R2

A new KB article was released yesterday regarding issues some Windows of RemoteApp Applications. This issue occurs because the remote desktop connection does not display the window correctly if The window ownership hierarchy is more than two levels deep or if the windows are remoted in reverse order.

Article ID: 2614136 - Last Review: December 14, 2011 - Revision: 1.0

Some windows of a Remote Desktop Services (Terminal Services) RemoteApp application might not be displayed correctly in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2614136/en-us?sd=rss&spid=14134

Consider the following scenario:

• You install the Remote Desktop Services role on a computer that is running Windows Server 2008 R2.
• You configure a Remote Desktop Services RemoteApp application on the computer. This RemoteApp application supports the Remote Applications Integrated Locally (RAIL) feature.
• You connect to the RemoteApp application from a client computer that is running Windows 7 or Windows Server 2008 R2.

In this scenario, some windows of the RemoteApp application are not displayed correctly. You find large blank or dirty areas at the expected locations of the pop-up windows. The frequency of this behavior varies.

New update to the RDS wiki: The Case of the Invisible RemoteApps

Amongst some others, I've have been working on some of the articles in the New RDS Wiki on TechNet. Recently a new article came out by Pankaj Pande related on (non)visibility of RemoteApp programs in RD WebAccess.

"...In our previous blog entry on Remote Desktop Services resources for IT Pros, we mentioned that we'd added a new wiki for Remote Desktop Services in WS08 R2.This wiki has been growing quickly, thanks to the efforts of some of our community. Most recently, we've released a new article on the TechNet Wiki entitled The case of invisible RemoteApp programs (a.k.a. No RemoteApp programs listed on RD Web Access site). This article discusses one of the error messages that you may get while trying to add one or more RemoteApp sources by using the Configuration tab on the RD Web Access page. It includes an analysis and troubleshooting tips using RD Web Access Tracing. The article also covers the permissions related to WMI and DCOM that you can check when you get these error messages. If you have your own tips, we encourage you to add them to our wiki and link them to the appropriate landing page..."source:
http://blogs.msdn.com/b/rds/archive/2011/12/07/new-update-to-the-rds-wiki-the-case-of-the-invisible-remoteapps.aspx

Using Powershell to install and configure RDS in 2008 R2

I came accros this great series of blog posts on TechNet by Microsoft Consultant Manoj Nair. It explains automating the installation and configuration of Remote Desktop Services in great detail with lots of examples.

Check the links below for particular subjects.


Introduction
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-introduction.aspx

Part I : Installing Remote Desktop Role Services
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-i-installing-remote-desktop-role-services.aspx

Part II : Configuring Remote Desktop Session Host Server using RDS Provider for PowerShell
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-ii-configuring-remote-desktop-session-host-server-using-rds-provider-for-powershell.aspx

Part III : Configuring Remote Desktop Connection Broker using PowerShell
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-iii-configuring-remote-desktop-connection-broker-using-powershell.aspx

Part IV : Configuring a RDS Farm using PowerShell
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-iv-configuring-a-rds-farm-using-powershell.aspx

Part V : Configuring a RD Gateway using PowerShell
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-v-configuring-a-rd-gateway-using-powershell.aspx

Part VI : Network Load Balancing RDS Farm Members using PowerShell
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-vi-network-load-balancing-rds-farm-members-using-powershell.aspx

Part VII : Using Best Practice Analyzer PowerShell Module of Remote Desktop Services
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-vii-using-best-practice-analyzer-powershell-module-of-remote-desktop-services.aspx

Part VIII : Next Steps
http://blogs.technet.com/b/manojnair/archive/2011/12/02/rds-powershell-tfm-part-viii-next-steps.aspx

My first article at VirtualizationAdmin.com

Today my first article at VirtualizationAdmin.com was published. You can read the introduction of the article below. Use the link to read the complete article!

Printing in Microsoft RDS environments and how it evolved in todays technology

"...As you might know RDS stands for Remote Desktop Services, previously known as Terminal Services and designed to have multiple user sessions hosted on a single server. Now it is called Session Virtualization. These sessions have grown out to becoming complete local desktop replacements. What activity is one of the most frequent user actions on a desktop? Exactly, printing!
Therefore, whether to allow printing from a session is not the question. The question is how to configure it in the most convenient way from the end-users perspective and easy to maintain from the administrators perspective. In this article, we’ll discuss printing in Microsoft RDS environments, what printing from a remote session was like in the past and how it evolved in today’s technology..."

Read the complete article here:
http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/printing-microsoft-rds-environments-how-evolved-todays-technology.html

Announcing the new TechNet Forum Assistant !

Introducing the TechNet Forum Assistant
TechNet Forum Assistant
The TechNet Forum Assistant is a free Windows gadget, available in the Microsoft Download Centre. This gadget will help you better utilize the great information in TechNet Forums and community. By downloading, you have the support and expertise of Microsoft TechNet Forum Support Engineers directly right on your desktop. Receive support on your terms by downloading the TechNet Forum Assistant.

Ask Questions
The TechNet Forum Assistant enables you to ask questions directly to our dedicated TechNet Forum Support Engineers. With a click of your mouse, you can choose your favourite thread among the numerous topics available in the TechNet Forums.

Hot Topics & Resources
The TechNet Forum Assistant instantly directs you to the hottest questions and discussions, professional technique recommendations for development and free sample code from the All-In-One Code Framework. Searching through your forum threads has never been easier. With TechNet Forum Assistant you can search through your threads directly from your desktop.

Receive Personalized Updates
The TechNet Forum Assistant conveniently gathers forum threads which are of interest to you. By selecting your favourite forums, the Forum Assistant provides updates on the most recent threads, making your online support experience much more convenient and hassle free.

http://www.microsoft.com/download/en/details.aspx?id=27747

NEW: Remote Desktop Services TechNet wiki for Windows Server 2008 R2

The Microsoft RDS product team has been working on the Remote Desktop Services TechNet wiki for Windows Server 2008 R2 and would like to encourage you to use it and contribute information you think would be useful to other people deploying Remote Desktop Services.

Link:http://social.technet.microsoft.com/wiki/contents/articles/275.aspx#R

Source:http://blogs.msdn.com/b/rds/archive/2011/11/21/help-finding-remote-desktop-services-information-online.aspx

Looking for a specific GPO setting, corresponding registry key or corresponding .admx file?

When you work with Group Policy Objects (GPO’s) regularly, or even better, when you don’t work with GPO’s regularly, the following scenario’s will sound familiar.

- I know this GPO setting exists, I know it had the words “Delegating Saved Credentials” in it but where is that specific policy in the GPO tree?

- I have this GPO setting here, but what is the corresponding registry key?

- I have this GPO setting here, but what is the corresponding .admx file?

- I have this GPO setting here, but is a logoff required

Save yourself some time searching the net and bookmark the following page: (or this blog post J)
http://www.microsoft.com/download/en/details.aspx?id=25250

It contains several fully searchable Excel sheets, which contain GPO settings with columns like policy setting name, scope, admx file, registry key etc!

These sheets have been around for some time, but I thought it might be useful information to give it some extra attention.

There also is a online variant here: http://gps.cloudapp.net/

The taskbar may not show the application name correctly when using a Terminal Server RemoteApp

A new KB article was released by Microsoft yesterday related to the display of an incorrect name in the taskbar when using a Remote App. The workaround that Microsoft offers however seems a bit disappointing :-). But I’m sure they’ll fix this issue in a upcoming hotfix.

Article ID: 2642873 - Last Review: November 17, 2011 - Revision: 1.0

The taskbar may not show the application name correctly when using a Terminal Server RemoteApp

source: http://support.microsoft.com/kb/2642873/en-us?sd=rss&spid=14134

Resolving "Remote Desktop Disconnected" or "Unable to Connect to Remote Desktop (Terminal Server)"

Solutions for errors such as “Unable to RDP,” “Remote Desktop Disconnected,” or “Unable to Connect to Remote Desktop (Terminal server)” are frequently asked for on TechNet Forums. There are 4 commonly seen Symptoms to this error:

1. You may be limited in the number of users who can connect simultaneously to a Remote Desktop session or Remote Desktop Services session
2. You may have a Port assignment conflict
3. You may have an incorrectly configured Authentication and Encryption setting
4. You may have a corrupted Certificate

The corresponding KB is:
Article ID: 186645 - Last Review: December 22, 2010 - Revision: 3.0
Troubleshooting RDP Client connection problems
http://support.microsoft.com/kb/186645

For more details check this blog post by the Remote Desktop Services (Terminal Services) Team:
http://blogs.msdn.com/b/rds/archive/2011/01/10/how-to-resolve-the-issue-remote-desktop-disconnected-or-unable-to-connect-to-remote-desktop-terminal-server.aspx

Running RD Gateway on a different port then 443 (Windows Server 8)

If you have been working with the Remote Desktop Gateway (RDGW) or with the previous version, the Terminal Services Gateway (TSGW), you’ll probably know that running the RDGW on a different port then port 443 is not possible (or at least not supported).

Good news is coming for organizations that needed this functionality (and I have seen requests for this on Technet Forums on multiple occasions). Running RD gateway on a different port than port 443 will be possible on Windows Server 8! Even better, this setting is easily accessible from within the RD Gateway manager and can be changed within a few clicks.

In this blog post I’ll quickly show you how to configure this.

When you installed the RD Gateway via the new Server Manager (either remotely or locally) the RD Gateway Manager Manager will be available. When you open up the manager it looks quite a lot like the RDGW Manager in Windows Server 2008 R2.

However, when we open up the properties of the RDGW server we’ll notice a new tab there called Transport Settings.

On this tab we have several options. We can change the IP address that the RD Gateway listens on. By default this is "All Unassigned", but we now have the ability to easily set this to a single specific IP-address that exists on the server. Useful when your RD Gateway server has multiple IP-addresses and you want to narrow this down to a single one.

New here is the ability to change the port that RD Gateway server listens on. So let’s test this functionality and change that to a different port. We’ll choose and set port 999 for now.

We get a warning that listener rules will be modified in the Windows Firewall and, of course, all active sessions will be disconnected, as the RD Gateway server will be restarted.

When we run a netstat we see that the RDGW is now running on 999 instead of 443.

Now let’s try to connect to the a RD Session Host using the new RD Gateway port. We open up a mstsc, enter the hostname of the RDSH and the necessary credentials. On the advanced tab using the settings button we configure the RD Gateway settings as show below.

We save the settings and try to connect. We get the error below:

“A valid gateway server address must be specified”. Why do we get this error? We tried to connect using a Remote Desktop Client supporting RDP 7.0 and apparently Remote Desktop Protocol version 7.0 does not support this.

So we open up a Windows 8 client, run mstsc and try the same configuration. This time successfully!

We’re now able to save the RD Gateway properties of the client and start a new session, and thus connect using a RD Gateway server on port 999.

Once connected we open up the connection details of the session where secure connection on port 999 is now displayed:

Conclusion: RD Gateway running on Windows Server 8 will support changing the port that the gateway listens on. A pre-requisite for this to work is using a Remote Desktop Client that supports Remote Desktop Protocol 8.0

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.

Cannot activate an RD Licensing server by using Windows PowerShell in Windows Server 2008 R2

Apparently, when you try to activate a RD license server or install Remote Desktop Services client access licenses (RDS CALs) automatically by using Windows PowerShell you can receive an error caused by the fact that the logic in the PowerShell command, to process the input string, is incorrect. Microsoft released a hotfix for this issue. For details see below.

Article ID: 2618115

Last Review: October 12, 2011
Revision: 1.0
You cannot activate an RD Licensing server or install RDS CALs automatically by using Windows PowerShell in Windows Server 2008 R2

Consider the following scenario:You install the Remote Desktop Licensing (RD Licensing) role service on a computer that is running Windows Server 2008 R2.
You try to activate the license server or install Remote Desktop Services client access licenses (RDS CALs) automatically by using Windows PowerShell.
You select Telephone or Web Browser in the Connection method list.

In this scenario, you cannot activate the RD Licensing server or install RD CALs. Additionally, you receive the following error message:

Set-Item : Cannot bind parameter 'LSID'. Cannot validate argument "<string>". Error: ""
At line:1 char:9
+ Set-Item <<<< .\ActivationStatus -Value 1 -ConnectionMethod PW
+ CategoryInfo : InvalidData: (RDS:\LicenseServer\ActivationStatus:String) [Set-Item], ParameterBindingException
+ FullyQualifiedErrorId : ArgumentError,Microsoft.PowerShell.Commands.SetItemCommand

Source: http://support.microsoft.com/kb/2618115/en-us?sd=rss&spid=14134

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!

Aggregate of common issues seen with Remote Desktop Services updates to revision 3.0

The "aggregate of common issues list" for with Remote Desktop Services in 2008 R2 has been updated to revision 3.0 yesterday.

Source http://support.microsoft.com/kb/2601888

"...This article summarizes the available hotfixes and updatestfix for issues that can occur in Remote Desktop Services (Terminal Services) for Windows Server 2008 R2 environments. For Windows Server 2008 Terminal Services updates, please see 2312539 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;2312539) .

NOTE: This list is an aggregate of common issues seen with Remote Desktop Services (Terminal Services) in Windows Server 2008 R2. Do not proactively install the following patches unless needed. If you believe that you are experiencing an issue listed below, install just the hotfix for that specific issue. If the specific hotfix is listed for your issue we recommend that you evaluate these hotfixes and updates to determine if they apply to specific Windows version and ServicePack level.

The hotfixes and updates are arranged by component areas within Remote Desktop Services 2008 R2 environment and could apply to Windows XP, Windows Vista and Windows 7 Remote Desktop Clients..."

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!

Received the MVP Award for Remote Desktop Services today !

I'm honored to have received the Microsoft MVP Award for Remote Desktop Services (RDS) today !!

Great news. Thanks Microsoft for this award!

More info on MVP here: http://blogs.msdn.com/b/mvpawardprogram/archive/2011/10/01/congratulations-new-and-renewed-mvp-awardees-for-this-quarter.aspx

Scenario Based Deployment of RDS in Windows Server 8

Last week I posted a blog about the Remote Desktop Client on Windows 8, in which I promised to write a follow up post on Remote Desktop Services in Windows Server 8. So here it is. In this blog post, I will focus on the new Scenario Based Deployment of Remote Desktop Services, which is new in Windows Server 8.

The following servers are running within my lab.local environment (all Windows Server 8 developer edition x64).

hostname	roles
RDSH-WIN8-001	Desired role on this machine will be Remote Desktop Session Host (RDSH)
RDGWWA-WIN8	Desired roles on this machine will be Remote Desktop Gateway and Remote Desktop Web Access*
RDCB-WIN8	Desired role on this machine will be Remote Desktop Connection Broker

* it’s not possible at this point to install  the RDGW using the scenario based deployment. It has to be installed separately.

When we logon to a Windows Server 8 for the first time we’re presented with the new Server Manager Dashboard, which looks pretty smooth.

Before we can start our Scenario Based Deployment the Server Manager needs to know what servers you want to manage, and thus install roles on. If you forget this step you won’t be able to select other servers later on in the wizard than the local host that you are running the wizard on. So don’t forget this step! We select Add other servers to manager (option 3) and are presented with the following dialog.We can browse the Active Directory to add servers. Since we know that all the servers that we want to join to this scenario start with “RD” we filter on this text, add the three servers in question, and click finish.

Note that the Server Manager Dashboard now shows the servers we can manage from Server Manager. (See below)

We’re now ready to start our Scenario Based Deployment of RDS.

Since we are going to be installing roles we choose (option 2) add roles.
We are presented with the screen below which is the improved Add Roles and Features Wizard. New in this wizard is that the destination server is show in the upper-right corner. This is because we also have the ability to use this GUI to install roles on remote servers.

We click Next to start the wizard and we’re presented with the screen below.

This brings us to the topic of this blog, the Scenario Based Installation. As explained earlier, this installation type is only available for Remote Desktop Services. (At least in the Developer preview edition). We obviously select Scenario-based Installation and click Next.

Here we have two options. We can choose either a Standard or Quick Deployment. The Quick Deployment option can be used for a single server deployment of Session Virtualization and/or Virtual Desktop Infrastructure. In this case, we want to deploy RDS over multiple servers so we’re going to stick with the Standard deployment. Also note that the previous screens showed the destination server in the upper-right corner. Because we selected a scenario-based installation in the previous dialog we (might) setup RDS over multiple servers which we select later on so the destination server reverts back to No Servers Selected.

In the Select deployment Scenario dialog we again have two options, a VDI or RDS deployment. As you might have guessed we will choose Session Virtualization deployment here (which is RDS).

This dialog sums up the different roles that the wizard is able to deploy including links to additional information per role. Notice that the Remote Desktop Gateway (RDGW) is not part of this Scenario Based deployment. We click next.

The Select RD Connection Broker dialog is used to select the servers that we want to install the RCCB role on. We select the RDCB-WIN8 server and click Next.

On the Select RD Web Access dialog, we have to option to select servers that we want to install the RDWA role on. Note that we have the option to install RD Web Access on the same server as the RD Connection Broker. We choose RDGWWA-WIN8 as the server and click Next.

The Select RD Session Host Servers dialog is used to select the servers that we want to install the RDSH role on. We select the RDSH-WIN8 server and click Next.

The last step of the deployment is the Confirmation dialog. This shows a summary of the different roles that we will be deploying and the machines that we’re deploying these roles on. Note the warning that the server that we install the Remote Desktop Session Host role on needs to be restarted afterwards. (Which is not new compared to Window Server 2008 (R2). We confirm the restart the of RDSH servers by selecting the option and click Deploy.

Using the progress dialog that is now shown we can follow the progress of the scenario based deployment.

As we can see later on, the wizard reboots the RDSH server as promised.

I was surprised to see the next dialog that shows a failure.

Apparently, the wizard wants to enable Remote Connections to the all servers using SetAllowTSConnections method. I’m guessing that this refers to this; http://msdn.microsoft.com/en-us/library/Aa383644. I had configured to allow Remote Access to de machines via a GPO setting prior to running this wizard so perhaps the failure is shown because Remote Access is already allowed. What does surprise me is the fact that the wizard also wants to configure Remote Access on the RDWA and RDCB besides the enabling this in the RDSH.

Anyhow, the server manager now has an additional tab Remote Desktop Services. I’ve checked the servers separately and they have the roles installed exactly as expected. Where needed, the prerequisites (like i.e. IIS for RD WebAccess) have also been installed.

This makes the scenario based deployment of Remote Desktop Services complete and successful! The next step will be to further explore the configuration of the separate RDS roles. I’ll devote another post on this subject soon!

To be continued…