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 !

My new article on virtualizationadmin.com "Remote Desktop Server farms explained (Part 2)"

My new article titled "Remote Desktop Server farms explained (Part 2)" on virtualizationadmin.com got published yesterday.

"...Introduction
This article continues where we left off in Part 1. In Part 1, we walked through the different types of load balancing solutions which can be used in order to distribute users over multiple servers in a Remote Desktop Services farm. We mentioned that there are four types of load balancing solutions. There is RR DNS, software (e.g. NLB), hardware and the RD Connection Broker. On multiple occasions in the article, we mentioned that the first three types could also be combined with the RD Connection Broker. In this second part, we will see why and how the RD Connection Broker serves a central role..."

Read the complete article here: http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/remote-desktop-server-farms-explained-part2.html

You can find the part 1 of the this article here: http://www.virtualizationadmin.com/articles-tutorials/vdi-articles/general/remote-desktop-server-farms-explained-part1.html

Test lab guides for RDS in Windows Server 8 Beta

Microsoft released several test lab guides to get you started with setting up Remote Desktop Services on Windows Server 8 Beta in a lab environment. If you used the labs you can give feedback on the lab pages by rating it and adding a comment.

Test Lab Guide: Remote Desktop Services Session Virtualization Quick Start
This topic contains instructions for setting up a test lab based on the Test Lab Guide: Base Configuration and deploying Remote Desktop Services Session Virtualization Quick Start deployment using two server computers and one client computers. The resulting Session Virtualization Quick Start deployment test lab demonstrates how to successfully deploy a Session Virtualization Quick Start deployment.
http://technet.microsoft.com/en-us/library/hh831754.aspx

Test Lab Guide: Remote Desktop Services Session Virtualization standard deployment
This paper contains instructions for setting up a test lab based on the Test Lab Guide: Base Configuration and deploying Session Virtualization using two server computers and one client computer. The resulting Session Virtualization standard deployment test lab demonstrates how to successfully install and configure a Session Virtualization standard deployment.
http://technet.microsoft.com/en-us/library/hh831610.aspx

Test Lab Guide: Remote Desktop Services Publishing
This paper contains instructions for setting up a test lab based on the Test Lab Guide: Demonstrate Remote Desktop Services Session Virtualization Standard Deployment and publishing and managing resources using four server computers and one client computer. The resulting centralized resource publishing test lab demonstrates how to successfully install and configure resource publishing.
http://technet.microsoft.com/en-us/library/hh831442.aspx

RDS in WIN8 Feature highlight no. 7 SSL configuration made easy.

RDS in WIN8 Feature highlight no. 7  SSL configuration made easy.

If you ever had to set up or configure certificates for a Remote Desktop Services environment based on Windows Server 2008 (R2), you’ve probably dealt with having to setup certificates in many different places on many different machines running the various RDS roles. With Windows Server 8 (Beta) SSL certificate management has been made much easier for the administrator.

If you open up the server manager en browse to “Remote Desktop Services” from the left pane and select “Collections” you have the ability to choose “Edit Deployment Properties”.

A dialog will appear in which we select “Certificates”. Using this dialog we can actually setup the SSL certificate for the Redirector, publishing and RD Web Access all from the same console!