New article: Prevent those unwanted applications from running in RDS

My new article titled "Prevent those unwanted applications from running in RDS" on virtualizationadmin.com just got published. The article is about using Applocker on Remote Desktop Services.

“…Introduction

These days Desktop Virtualization is a hot topic. Many service providers, system integrators and other companies provide some way of Desktop Virtualization to their end-users. This can be done by providing a set of Remote Applications (RemoteApps) or full desktops on Virtual Desktop Infrastructure (VDI) or Remote Desktop Service (RDS) environment or even a mix of these technologies. When it comes to publishing a full desktop (whether it is VDI (Desktop Virtualization) of RDS (Session Virtualization) you would want to have a method to allow users to only run applications that you authorized them to. Although this is absolutely important for both VDI and RDS scenarios you can imagine that enforcing such a policy is especially important in a RDS environment as you are sharing servers with multiple users..”

Read the complete article here:
http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/prevent-unwanted-applications-running-rds.html

RemoteApps in Windows 8 taskmanager

RemoteApps that are launched from a Windows 8 client are nicely grouped in TaskManager under a “Remote Desktop Connection” section. Looks great!

Setting the default RemoteApp connection URL on your clients using GPO

Before Windows Server 8 beta (soon to be Windows Server 2012) there was an option in the control panel of the user called Remote App and Desktop Connections. Using this Control Panel option the user was able to set the URL needed to build the connection to the RD WebAccess to be able to have the RemoteApps available. Remember that in this Feature highlight blog post I wrote that Window Server 8 beta added a new option so that users would also be able to enter their corporate e-mail address in stead of the connection URL, which is of course much more user friendly.

Windows Server 8 Beta also comes with a new GPO setting to set the default connection URL so that the user would not have to configure anything at all!

The setting is inside a new container called “RemoteApp and Desktop Connections”

And is called “Specify default connection URL”

If you enable this setting you are able to set the default connection URL. The details of the setting are shown below.

Setting: Specify default connection URL
Supported on: At least Windows 8 Consumer Preview
Comment: This policy setting specifies the default connection URL for RemoteApp and Desktop Connections. The default connection URL is a specific connection that can only be configured by using Group Policy. In addition to the capabilities that are common to all connections, the default connection URL allows document file types to be associated with RemoteApp programs.

The default connection URL must be configured in the form of http://contoso.com/rdweb/Feed/webfeed.aspx.

If you enable this policy setting, the specified URL is configured as the default connection URL for the user and replaces any existing connection URL. The user cannot change the default connection URL. The user's default logon credentials are used when setting up the default connection URL.

If you disable or do not configure this policy setting, the user has no default connection URL.

Note: RemoteApp programs that are installed through RemoteApp and Desktop Connections from an untrusted server can compromise the security of a user's account.

RD Connection Broker HA and the RDP properties on the client.

In some earlier posts I discussed the new High Availability (HA) feature of the RD Connection Broker (RDCB) in Windows Server 2012 (formally known as Windows Server 8).

1. RDS in WIN8 Feature highlight no. 1 Better High Availability of the RD Connection Broker
2. How to configure High Availability for RD Connection Broker on Windows 8
3. RD Connection Broker HA – SQL Permissions

In the blog post regarding the configuration of HA (no. 2 in de above list) I ended the blog with the comment that we would now be able to connect to the environment by using MSTSC and entering the DNS farm name as the destination host to connect to. Having read that you’re probably wondering how this works. Because we’re launching an RDP connection using MSTSC with the destination set to the DNS farm name that points to the brokers. Would that not result in launching an RDP session to the RDCB server and not to the RDSH server(s) behind it? Yes it would!

If, after completing the step in blog post no. 2, I would launch MSTSC and enter the DNS farm name as the destination host (as shown below):

That would result in the error below. Why? Because we’re actually launching an RDP session to one of the RDCB servers, and of course that’s denied for our end user.

What we need to do is configure some properties in an .RDP file so that it has knowledge of the fact that we’re trying to connect through a HA Connection Broker.

These are the properties that need to be added:

full address:s:FARM.LAB.LOCAL
workspace id:s:FARM.LAB.LOCAL
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Wortell_sLab_Ses
alternate full address:s:FARM.LAB.LOCAL

If we try that as our end user, the connection bar would still show the RDCB DNS farm name, but we’re now logged in on the RDSH server.

This also get’s automatically configured for your RemoteApps. RemoteApps integrated on the client are stored inside RDP files in the following location:

C:\Users\<username>\AppData\Roaming\Microsoft\Workspaces\<Workspace-ID>\Resource

Editing such a .RDP file in notepad would (amongst some other properties that I left out here) results in:

full address:s:FARM.LAB.LOCAL
alternate shell:s:||calc
remoteapplicationprogram:s:||calc
gatewayhostname:s:rdgw.lab.local
remoteapplicationname:s:Calculator
remoteapplicationcmdline:s:
workspace id:s:FARM.LAB.LOCAL
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Wortell_sLab_Ses
alternate full address:s:FARM.LAB.LOCAL

RD WebAccess also automatically points to the RD Connection Broker farm

So that’s how to configure your .RDP files if you want to connect through a HA RD Connection Broker!

Good luck testing this. If you have any questions, let me know!

Windows Server 8 Settings Spreadsheet

The Group Policy Team created a new Blog Post today about the availability Windows Server 8 GPO settings spreadsheet! The sheet contains settings for Windows Server “8” Beta, Windows 8 Consumer Preview and all earlier versions of Windows.

“…The latest Group Policy settings reference spreadsheet that covers the available administrative template settings and security settings for Windows Server “8” Beta, Windows 8 Consumer Preview and all earlier versions of Windows is now available in the download center here:

http://download.microsoft.com/download/8/F/B/8FBD2E85-8852-45EC-8465-92756EBD9365/WindowsServer8BetaandWindows8ConsumerPreviewGroupPolicySettings.xlsx

To see the description of what is contained in this latest version before downloading, go here:http://www.microsoft.com/download/en/details.aspx?id=25250…”

Source: http://blogs.technet.com/b/grouppolicy/archive/2012/04/16/windows-server-8-settings-spreadsheet.aspx

RD Connection Broker HA – SQL Permissions

I've received some questions via e-mail on one of my previous posts on how set up High Availability on the Connection Broker in Windows Server 8 (Beta)

http://microsoftplatform.blogspot.com/2012/04/how-to-configure-high-availability-for.html

The questions were related to preparing the correct (SQL) permissions to be able to enable High Availability using the Server Manager wizard. In this blog post I’ll dive a little deeper in the SQL permissions part. But before we get started, since we’re dealing with beta product and since there is no official Microsoft documentation on this exact configuration yet, this blog post contains my personal thoughts on what I think the configuration should be.

The prerequisite that refers to the SQL permissions is explained by the setup as: “A Microsoft SQL Server with write permissions granted to all RD Connection Broker servers that will be part of the deployment.” But what exactly does that mean?

When you would not prepare any SQL permissions except opening port 1433 for your RD Connection Broker, you will receive the following error in the wizard:

“The database specified in the database connection string is not available from the RD Connection Broker server <servername>…”



Assuming that, 1. you did install the SQL Native Client on the RD Connection Broker and 2. traffic on port 1433 to the SQL Server is possible, you will see a log entry generated on the SQL Server that looks something like this:



The wizard to configure HA is trying to connect to the SQL Server using the computer account of broker.

So, basically what we need to do is create a group in Active Directory, and place all RD Connection Broker computer objects in there.



Then we add this group as a SQL Login in SQL Server manager.



If we then try the wizard again, it will try start to configure HA. However, without any further preparations, the following error will be raised



The wizard is unable to create a database.Why? Because we didn’t assign the AD group any roles or permissions. We open up SQL Server manager again, open the group and specify the role dbcreator.



When try the wizard again, it will succeed.



The database is created and exists in the folder we specified.



Note that when we add a second (or any new) RD Connection Broker to the HA setup, that new server also needs permissions to the database. If those permissions are not in place you will receive the following error in the wizard:



And the SQL Server log will raise the following events:



We open up SQL Server Manager again, open up the properties of the group we created select server mappings, select our database and we (although datareader and datawriter will probably also be enough) give our group owner permissions on our database.



This will allow us to successfully add new RD Connection Brokers to out HA environment, as long as they are a member of the created group.

Bottom-line:

• create a new AD group that contains your RDCB servers participating in the HA
  
• Give that group dbcreator permissions to be able to create the database during the wizard
  
• Give that group owner permissions (or at least dbwriter and dbreader) on the newly create database to ensure all RDCB servers are able to contact the database.

A final FYI to be aware of, if you created a database before starting the RDCB HA wizard the wizard will delete this database and create a new one during the setup.

RD Gateway in Windows Server 8 supports UDP

Remote Desktop Services in Windows Server 8 (Beta) supports the UDP protocol. The UDP transport protocol provides a better experience for users that connect to a RDS session on a server running Windows Server 8. TCP as well as UDP protocols can now be used for the RDP session.

The Remote Desktop Gateway (RD Gateway) in Windows Server 8 extends this UDP functionality by supporting it in the gateway. If the client or endpoint does not support UDP, RD Gateway will automaticially switch back and thus the selection process of the best possible transport protocol is completely transparent to the end-user as long as the it has been enabled in the RD Gateway and the client and RDP endpoint support a UDP connection. The client has to be equipped with Remote Desktop Client 8 to support UDP.

To configure the RD Gateway to use UDP when possible, open the RD Gateway manager and then select the "Transport Settings" tab. Here you have the option to enable UDP support. Of course, the UDP settings can also be configured using GPO's. E.g. there is a setting "Turn off UDP On Client" to configure it on the the client and setting "Connections - Turn Off UDP On Server" to force it to turn of on the RDSH server.

Expired passwords in RD WebAccess on Windows Server 8 revisited.

In one of my previous blog posts (http://microsoftplatform.blogspot.com/2012/03/rds-in-win8-feature-highlight-no_12.html )I showed that Windows Server 8 (Beta) now also has a functionality to have a user reset his password using RD WebAccess.

In that blog post, I wrote that I was wondering whether the final release of Windows Server 8 would contain a link to that password reset page on the logon page itself to guide the user to the password reset page. I’ve done some editing, and it seems that it’s extremely easy to add this functionality yourself. This the line of text I added containing a link:

However, the real intention of this new password reset functionality seems to be the ability to have a user change his expired password. See the screenshot below. Notice that a notification text is added saying that the password has expired with a link to the password reset page! Great feature!

RemoteApp improvements in Windows Server 8

There have been numerous improvements regarding the way end-users experience RemoteApps in Windows Server 8. In this blog post, I’ll discuss some of the improvements that might at first seem very small but will definitely help end users to adopt Remote Apps even more.

With Windows 7, new features were introduced, such as grouping of applications, pinning, tabbed windows, overlay icons etc. However, RemoteApps didn’t allow full compatibility with these newly introduced features. Windows Server 8 (Beta) crosses the bridge and has the capability to allow compatibility with these features!

Users can now also pin RemoteApp applications to the client taskbar just like they were locally installed applications.

Users can now easily spot the difference between RemoteApps and workspaces by a unique icon. This identifier is in the form of an icon overlay in the form of the Remote Desktop logo.

Users can now see a change in the status of an application as icon overlays is now also supported for Remote Apps.

And users can now also see the difference between multiple instances of an application by being able to see tabs in the RemoteApp preview.

It's good to see that these features made it to the Windows Server 8 (Beta) release, it definitely makes Remote Apps more user-friendly!

Connecting Vasco Identitykey 3.4 to Quest vWorkspace 7.5 Web Access

Quest vWorkspace (http://www.quest.com/vworkspace) can be connected to a radius server in order to accomplish two-factor authentication (2FA) . New in version 7.5 of vWorkspace is that 2FA can now also be enforced on the farm, where before version 7.5 you could only enforce 2FA on vWorkspace Web Access.

I've been setting up 2FA on vWorkspace 7.5 in a new environment this week using Vasco Identikey version 3.4. If you ever have to set up this configuration, beware of the following issue;

After setting up Identikey 3.4, importing some digipass GO tokens using .dpx files and assigning a digipass to a testuser, we're ready to configure the connection between vWorkspace and Identykey.

We setup a new client in Identkey Web Manager containing the IP address of the vWorkspace server and a shared secret. We configure the Two Factor in vWorkspace as follows.

Upon testing this in our environment I ran into a "Incorrect username or password" error while logging on to the Web Access server. Vasco Identitkey did not log anything. After some debugging, checking firewalls and running a radius client simulator I did not get any further. The TCP port 1812 was open and reachable and the client simulator even worked from the Web Access server itself!

After setting up additonal tracing on the Identikey server this error came up:

[ValidationTask::getNASLocationFromPacket] > No NAS-IP or NAS-Identifier attribute found.
[ValidationTask::routePacket] > Rejecting RADIUS request due to missing NAS Location
Which traced back to this Vasco Article:
http://www.vasco.com/Images/KB_120079.pdf
And thisfixed it instantly!

According to Vasco is seems that:

"...IDENTIKEY Server, VACMAN Middleware 3.0 and DIGIPASS Plug-In for IAS are compliant with RFC 2865, which states that a RADIUS Access Request must contain a NAS-IP-Address or NAS-Identifier attribute. Check KB article 120026 for a detailed description: https://www.vasco.com/support/kbase.html?tech=214

Because some important third party products are not compliant with RFC 2865, VASCO has included in IDENTIKEY Server the hidden possibility to accept a RADIUS Access Request without the NAS-IP-Address or NAS-Identifier attribute.."

Credits also go to the Quest Support team for assisting on this case!

Windows are displayed incorrectly when you connect to a RemoteApp program from a computer that is running Windows 7 or Windows Server 2008 R2

Microsoft released a new hotfix today regarding the incorrect display of windows when using a Remote App on Windows Server 2008 R2.

Article ID: 2682814 - Last Review: April 11, 2012 - Revision: 1.0
Windows are displayed incorrectly when you connect to a RemoteApp program from a computer that is running Windows 7 or Windows Server 2008 R2

Consider the following scenario:

• You install the Remote Desktop Session Host role service on a computer that is running Windows Server 2008 R2.
• You publish a RemoteApp program on the computer. The RemoteApp program is IME-unaware.
• You connect to the RemoteApp program from a client computer that is running Windows 7 or Windows Server 2008 R2. You enable a multibyte character Input Method Editor (IME), such as the Japanese IME or the Chinese IME, on the client computer.

In this scenario, the composition window of the RemoteApp program is displayed behind the main window of the program.

Note Most non-unicode applications (such as Notepad.exe and Wordpad.exe) are IME-unaware.

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

RemoteApps has a dependency upon explorer.exe

A new Fast Publish KB article has been released yesterday regarding using Remote Apps on clients where the default shell (explorer.exe) has been replaced with an alternative shell.

Article ID: 2695453 - Last Review: April 5, 2012 - Revision: 1.0
RemoteApps has a dependency upon explorer.exe

"...You can customize Windows client systems to the point of replacing the default shell (explorer.exe), and using an alternative shell. If you choose to replace explorer.exe, you will be missing essential windows functionality, however it may still be possible that you will still be able to successfully launch a remote desktop connection to another Windows system.

However, if you are trying to launch a ’RemtoeApps’ and run an application from your server on a windows client that does not have explorer.exe running as the system shell, that connection will time out and fail. This is because the RemoteApps connection has dependencies upon explorer.exe, including but not limited to the system tray for notifications, the language bar for switching languages, tabs for multiple tab applications, and icons and icon overlays..."

How to configure High Availability for RD Connection Broker on Windows 8

In a previous blog post (Better HA on de RDCB) I wrote a quick feature highlight of the new High Availability options for RD Connection Broker on Windows Server 8 (Beta). I promised to write a more detailed blog post on how to actually set this up. So here it is!

The process for setting up a highly available (HA) RD Connection Broker has changed and improved a lot in Windows Server 8 (Beta). As also seen in my previous blog post on this, a wizard has been added to the new server manager to guide you through the process of setting up the HA and adding new RD Connection Broker servers.

Prerequisites
Before we start to configuration, I’ll quickly sum up the prerequisites. At this point we assume that there is a RD Connection Broker already in place (e.g. during the setup of a quick deployment). The prerequisites for High Availibility for the RD Connection Broker are:

• A Microsoft SQL Server with write permissions granted to all RD Connection Broker servers that will be part of the deployment

• The Microsoft SQL Server Native Client is installed on all RD Connection Broker servers that will be part of the deployment

• Static IP addresses have been assigned to all RD Connection Broker servers that will be part of the deployment

• DNS resource records with a single DNS name have been created for all RD Connection Broker servers that will be part of the deployment

Step 1. Preparing the Broker for HA

Before adding a second server with the RD Connection Broker role we need to prepare the current RD Connection Broker for HA. Which means that during this process, the wizard will create a central database on a central MS SQL Server instance and will transfer the configuration to this database.

We open the Server Manager on the machine that is currently holding the RD Connection Broker Role and we navigate to “Remote Desktop Services” and then “Overview”. We right-click the RD Connection Broker and choose “Configure RD Connection Broker for HA”.

On the "before you begin" screen the previously discussed prerequisites are summed again, we press “Next”. On the “Configure High Availability” screen we enter the details of the HA setup.

We need to specify the following parameters:

Database connection string
The wizard will use this string to create the database. Pay close attention to the format of the string. Copy the string below and change only replace the <name of SQL server> and <name of database> values.

DRIVER=SQL Server Native Client 10.0;SERVER=<name of SQL server>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;Database=<name of database>

Folder to store databasefile
Here we need to specify the folder on the SQL Server where we want the databases to be stored. For demo purposes I placed in C:\RCDB, but in most environments you will probably use an existing HA SQL environment and enter the desired values. Note that we specify the location for the .mdf as well as the .ldf file, so no separation there. However, you should be able to change that in using SQL Server manager after the installation.

DNS Resource Record name
Here we specify the DNS name that we want this HA RD Connection broker farm be accessible on.  For this demo I used rdcb.lab.local

We click “Next” and click “Configure” on the confirmation page. Shortly after that we get the confirm that the configuration has succeeded.

 A database is created on the SQL Server we specified.

Remember that this was just step 1. We now have prepared the current RD Connection Broker for HA purposes.


Step 2. Adding a RD Connection Broker

As the next step we will add a new RD Connection Broker to the HA setup we just created.

We go back to the server manager and we now have the option available “Add Connection Broker Server”.

After clicking next on the prerequisites page we are presented with the screen below. We select the server that we want to add as a RD Connection Broker and click next. (Please remember that before we are able to add a server here that server must be added to the Server Manager to be able for it to configure it).

We click “Add” on the confirm dialog and the wizard will remotely install the RD Connection Broker on the server we selected and add it to HA environment.

And that’s it!

We are now able to remotely connect to the DNS farm name (rdcb.lab.local) we created by using mstsc. An initial connection (as seen here) will be hosted by one of the active RD Connection Broker servers and we get be redirected to one of the RD Session Host Servers in the Session Collection! (And of course this also works in conjunction with the RD Gateway and RD Web Access).


Conclusion
Windows Server 8 (Beta) supports a true active-active HA solutions for the RD Connection Broker  Big improvement !