Replacing the default XenServer WSS Certificate

Something a little bit different from the normal RES related posts this time. During the deployment of the Demo Showcase platform we needed to replace the SSL certificate used by the XenServer Web Self Service (WSS) servers. Reviewing the WSS documentation revealed very little about how to achieve this. As you can see the user and installation guides offer very little guidance!


Much to my surprise, I couldn’t locate a web resource that details how to do this, i.e. generate the required ssl.crt and ssl.key files. There are lots of snippets of information but no simple post that details the requirements nor the steps to perform. This is my attempt to rectify this situation!


Before you begin there is the assumption that you have the following prepared/installed:

  1. The required SSL certificate has been exported into .PFX format (and you know the private key password!);
  2. You have OpenSSL is installed;
  3. WinSCP (or other SCP client) is installed.

Converting the Certificate to a .CRT and .KEY Pair

The WSS appliance expects the certificate and private key to be provided as two separate files rather one as contained in the .PFX (or .PEM) file. We can generate the correct files by utilising the OpenSSL tools. The secret to this part is to ensure that the generated .KEY file is not encoded with a password. If there is, you’ll receive an error when attempting to start the web service on the WSS appliance.

To export the certificate (.CRT) component from the .PFX file run the following OpenSSL command: openssl pkcs12 -in <ssl-certificate.pfx> -clcerts -nokeys -out <ssl.crt>

To export the private key (.KEY) without a password, run the following OpenSSL command: openssl pkcs12 -in <ssl-certificate.pfx> -nodes -nocerts -out <ssl.key>

Transferring the Certificate Files to the WSS Appliance

Once you have the required .CRT/.KEY file pair, you’ll need to copy them to the Web Self Service appliance. This is a fairly straightforward process but requires enabling the SSH daemon on the appliance first. To do this you’ll need to connect to the WSS appliance console via XenCenter. Once you’ve logged onto the console, issue the following command: service sshd start

You’ll also want to stop the Web Self Service process by running the following command: service webss stop

After the SSH service has started and WSS services are stopped, you can now copy the .CRT and .KEY files to the /root/sse/conf directory via WinSCP (or your tool of choice). Note: you might want to rename the original .CRT and .KEY files before copying the replacements in!

Restart the WSS services by executing: service webss start

All being well, you should receive no errors and when browsing to the WSS homepage you should not be warned about the SSL certificate! Here’s an example using a certificate with the Common Name set as the default sse-https-server.


Simples! I hope someone finds this useful one day! Iain

RES Automation Manager 2012 Global Variables

Unfortunately, this post is a mixture of both good and bad news. In my humble opinion, I feel that RES have missed a trick with their implementation of Global Variables in RES Automation Manager (AM) 2012 and here’s why.

In all the furore surrounding the RES AM 2012 release, Global Variables are supposed to herald the completion of multi-tenancy implementations. For example, multiple departments and/or customers can be co-located on the same database and share the platform without any visibility or potentially any knowledge of who else is utilising the infrastructure. If you’re after an introduction into the RES AM Global Variables I suggest you take a look at Rob Aarts’s article on RESguru or watch Grant Tiller’s demonstration on REStutorials.

Resources and Global Variables

It was my assumption (obviously incorrectly) that we would be able to use Global Variables with file server resources. In a multi-tenant implementation, I wouldn’t necessarily want all administrators uploading file resources to the database and bloating the tables with BLOBS. When we add files stored on a file share to the RES Automation Database, the UNC path is stored along with the entry in the database. This isn’t necessarily a problem, assuming that all RES Automation Manager agents can resolve this path. Unfortunately, in a multi-tenant environment this may not be the case.

Enter Global Variables. Wouldn’t it be a great idea if we could use a Global Variable in the UNC path of a file resource?! As long as we make sure that folder structure is the same for each “customer” site we could set the Global Variable to the customer’s file server at the Team or if needed, Agent level. Even within a single organisation, Global Variables would enable us to use local file servers without having to implement DFS-R etc.

Being RES Consultancy Partners we could also use this process when designing our Building Blocks. For example, we could upload the required resources for a XenApp build to a file server, import the RES Automation Building Blocks and change the Global Variable(s) to point to the customer’s file server instead. No longer would we need to either perform a mass “find and replace” within the Building Block files or upload 5GB of data into a database. Happy days Smile.

As you’ve probably guessed, this doesn’t work. DOH! When we attempt to insert the Global Variable by right-clicking the file path we’re not given the option:


Manually entering the Global Variable placeholder, e.g. ^[GlobalVariable] doesn’t work either. There is, however, a workaround.

Resources, Global and Environment Variables

Now that we know we can’t use Global Variables at the resource level, I do know that we can use Environment Variables. If we just so happen to use an environment variable and that environment variable just so happens to be set to a Global Variable’s value, it just might work…

Firstly we need to pick a variable to use and in this example I’ll use ’RESAMRESOURCES’ as it’s unlikely to clash with any other environment variables. We define the Global Variable and set the value to our file server’s share (you can always override this at a Team/Agent level or when importing Building Blocks where needed):


Next, when adding a file resource we can browse the target file and override the UNC path and enter an environment variable. In this example I’ll use the %RESAMRESOURCES% to point to the required file server.


All that’s left to do is assign the environment variable before any module that we want to use this resource. Fortunately, RES Automation Manager has a task to do just this. In my example I’ve created a job-based environment variable. We could always set this as a persistent machine-based variable via AM too.


Once we’re done, our completed module will look a lot like this. Note: the job-based environment needs to be set before we execute a task that references the file server resources, in our case, the Unattended Installation of Foxit Reader task.


When we export our Module as a Building Block we now have a fully portable module that can be imported into any environment without storing the resource(s) in the database! All we need to do know is use Global Variables to define the credentials used to connect to the file server..

Resources, Global Variables and Credentials

This is where the house of cards falls down around us.. We’ve managed to trick RES AM into using file resources with Global Variables. However, as the RES Automation Manager service runs under the Local System account, it has no access to file resources located on file servers. To overcome this issue, we need to embed the credentials in with the resources. Again, you would assume that you could use the Credentials type of Global Variables to achieve this.


I’ve tried unsuccessfully to get this work, even my manually specifying the ^[GlobalVariable] placeholder. Perhaps I’m the only one, but what about password changes? If we embed the credentials with the resource, using a Global Variable for this would make perfect sense. Currently, we don’t change the password associated with the RES Automation Manager resources as this requires us to update each individual resource. If they were based on a Global Variable we’d have a simple way to update the password, maintain security and pass an audit with flying colours!

I can only assume that this is either technically difficult to implement or is an oversight. As a result, we’re still left have to either do a mass “find and replace” in our Building Block files when implementing RES Automation Manager at customer sites or uploading large binaries into the database. Other than this, I think Global Variables are a brilliant edition and hopefully they will be coming to RES Workspace Manager too Smile with tongue out.

Many thanks for reading. Iain

VET v1.1 Released!

Virtual Engine are pleased to announce the general availability of version 1.1 of the Virtual Engine Toolkit (VET). The latest Windows installer and documentation is available for download now on the Virtual Engine web site.

We’ve put together a short overview video demonstrating each new feature. In the “What’s New” video we cover the following features:

  • Conversion of Group Policy Objects to RES Workspace Manager building blocks;
  • Conversion of Active Directory published printers and site definitions to RES Workspace Manager building blocks;
  • Direct import into the RES Workspace Manager console;
  • Multiple profile updates with the Profile Update Utility (PuU);
  • Ad-hoc registry changes in the Profile Update Utility (PuU).

For more videos on the Virtual Engine Toolkit, please check out our YouTube channel.

HP Thinpros and Windows 2008 R2 Remote Desktop Services (RDS)

I’ve been sitting on this blog for a while; so I thought it was about time I published it! Just recently we’ve been working with a client that was going through a desktop transformation process from Windows XP to HP thin client’s using a shared desktop on Windows 2008 R2 Remote Desktop Services (RDS). I’m not going to expand on why they chose Microsoft RDS over Citrix XenApp 6.x or why they chose Linux-based thin clients over Windows Embedded clients. Let’s just say that money did come into the equation.

What I’m going to cover in this post are the issues I’ve encountered whilst using the HP t5565 Linux-based thin clients with Microsoft’s RDS.

Remote Desktop Services Connection Broker

Lets start with the BIG one; they do not support the Remote Desktop Connection Broker (RDCB) or should I really say the open source rdesktop doesn’t! Now when I mean they it’s not supported, it can imply that it will work fine (but please don’t ask the vendor to help if any issues arise). In this case it simply doesn’t work. When the RDCB tries to either load balance or reconnect a disconnected session you will face a situation where you enter your login credentials then the session seems to just drop. If you are lucky your load balancer or round-robin DNS will direct you to the correct server, but this is just the laws of probability in action.

I should point out that this point will probably be an issue for any thin clients that are Linux-based and and utilising the rdesktop client. I have heard rumours that FreeRDP does work with the RDCB but I’ve not tried that myself so can’t confirm this; though this forum post does suggest it will work.

Bitmap Caching

Using “Bitmap Caching” in the rdesktop settings causes the screen to freeze randomly; so you have to way up the pros and cons of leaving it turned on. The benefits of enabling the bitmap cache is to minimise the amount of data transferred between the RDP client and server. However, this introduces the screen freezes. As a result, I went with disabling the bitmap caching to improve the user experience – the client had a well connected network so latency etc. was not an issue.

Other Issues

  1. Drawing shapes in Office 2003 will cause the screen to freeze and the system will become unresponsive – Resolved with this forum post.
  2. Using a second monitor to extend the primary display doesn’t work i.e. only show the taskbar on the primary display. What happens is screen spanning occurs therefore the taskbar is split across both monitors and the “Ctrl+Alt+Del” dialogue appears slap bang in the middle of where the monitors join – Resolved with this forum post (though I haven’t had time to test this myself).

I think the moral of this story is to try before you buy and then try some more! If you want to use the RDS Connection Broker then go for a Windows Embedded thin client, if indeed you want to use a thin client. Taking this approach may save you a lot of headaches going forward.


Scheduled RES Software Courses Q1 2012

Virtual Engine are proud to announce the availablility of official RES Workspace Manager 2011 and RES Automation Manager 2011 scheduled courses for Q1 2012, in London.

Both courses will be held in March on the following dates:

  • RES Workspace Manager: 05/03/2012 – 08/03/2012;
  • RES Automation Manager: 12/03/2012 – 14/03/2012.

For further information on pricing and availability please contact us.

What’s New in VET v1.1

With the public release of the Virtual Engine Toolkit (VET) v1.1 just around the corner, we’ve put together a short overview video demonstrating each new feature. In the “What’s New” video we cover the following features:

  • Conversion of Group Policy Objects to RES Workspace Manager building blocks;
  • Conversion of Active Directory published printers and site definitions to RES Workspace Manager building blocks;
  • Direct import into the RES Workspace Manager console;
  • Multiple profile updates with the Profile Update Utility (PuU);
  • Ad-hoc registry changes in the Profile Update Utility (PuU).

For more videos on the Virtual Engine Toolkit, please check out our YouTube channel here.

Application Upgrades in RES Workspace Manager

Upgrading applications that store user personalisation settings in different places for different versions of the application can be problematic and we at Virtual Engine run into this time and time again. The most obvious example is Microsoft Office migrations but this isn’t the only example. Due to the latest upgrade cycles, the typical problem we come across is migrating from Office 2003/2007 running on Windows XP to Office 2010 running on top of Windows 7. Why is this so problematic?

Best practise within RES Workspace Manager mandates that application settings should be captured at the application level to improve logon performance etc. For example, we normally configure Microsoft Word to capture user personalisation settings behind the application like so:


In addition we probably have our applications to to be hidden (I’ll come back to this later) when they’re not detected on a machine, i.e. we won’t show the Word 2003 icon if Word 2010 is installed (and vice versa). The different application versions are installed into different paths and we don’t want both application icons appearing and confusing our users. Therefore, all the various Office applications are configured with the ‘Hide application if executable was not found‘ option.

This is fine for the individual application settings, but what about Office-wide settings, i.e. the stuff stored in ‘HKCU\Software\Microsoft\Office\Common‘ or ‘HKCU\Software\Microsoft\Office\11.0\Common‘? Normally we capture these all encompassing settings as a global User Setting, a la:


It’s all fairly straight forward thus far and so why the blog post? Well, this is where the fun starts. We have all our Office 2003 applications configured and we introduce the Office 2010 applications into Workspace Manager and configure the user personalisation capture settings as defined above, probably like this:




Are you with me so far? Good!

The first time that an Office 2010 application is run it will attempt to migrate/upgrade the existing user settings (if they exist) and write them into the Office 2010 specific locations, i.e. ‘HKCU\Software\Microsoft\Office\14.0‘. Now, think about this for a second as we have a BIG problem… We have moved the user from a v1 profile (on Windows XP) to a v2 profile (on Windows 7) which means a clean slate and no existing user settings. “WAIT,” I hear you cry, “RES WM will layer the user settings back in!”

Unfortunately, you’re wrong! RES Workspace Manager will only layer the application settings back in for an individual application if it’s detected on the system. Remember, we’ve elected to ‘Hide the application if executable was not found’ and therefore, they’re not loaded. When we start an Office 2010 application there is seemingly nothing to migrate. DOH! We’re safe with the global Office-wide settings though, as they are configured at the global level (loaded at logon) and not dependent on any application detection.

So how do we at Virtual Engine get around this little conundrum? Simple; linked user settings!

I don’t know why but this solution seems to confuse a lot of people. It’s actually an elegant solution and should be (in my humble opinion) adopted as a standard/best practice :=). Essentially we configure dummy applications that have the various user personalisation settings configured for each version of the application that we’re interested in. For example, we create a ‘Microsoft Word’ application that is hidden but will capture the user settings for all the individual Office Word versions, e.g. in our example Microsoft Word 2003 and Microsoft Word 2010 like so:





Each of the individual applications are configured as before, but their user personalisation settings are linked to our dummy Word application. Fortunately, this means that both the Word 2003 and Word 2010 settings will be layered onto the Windows 7 machine if either Microsoft Word 2003 or Microsoft Word 2010 is detected. When a user launches Word 2010, the previous settings will be available, upgraded and then captured in the same way. Here is how we now configure Microsoft Word 2003 as an example:


There is a small down-side to this approach. We’ll be collecting two sets of roughly the same settings for a short period. However, it’s a small price to pay compared to losing everyone’s settings and once the migration is complete, the user settings definition previous Word version, 2003 in our instance, can be removed from the dummy application. If you ever need to upgrade to the next version of Office you’ll also be covered with this solution. Hopefully, it’s fairly obviously that this approach can be used for application other than the Microsoft Office suite too.

We would like to hear how other people tackle this problem as well as update this post if someone has a more elegant solution/idea. Please leave your comments below and thanks for persevering.

Thanks, Iain

Internet Explorer Personalisation with RES Workspace Manager

Looking at user settings, below are some recommendations for managing Internet Explorer with RES Workspace Manager. These are not RES “best practices” but tips and tricks picked up in the field after a number of deployments.

  1. Configure IE User Settings at a global level (or as an ‘auto launched’ application) so that they get applied to the user’s session at log on. There are lots of applications that rely on these settings and if they’re loaded in the background, they may not be available when needed and cause confusion.
  2. Do not use “Zero Profile” mode User Tracking for Internet Explorer. I’ve seen lots of deployments with this enabled and it generates very large User Settings (UPR2 and UPF2) files as IE touches lots of files and registry keys when running. This will certainly result in slower log on/off times and is not required – use the built-in User Settings template.
  3. Keep user Favo(u)rites, Cookies and History User Settings separate from the IE application User Settings, i.e. define two User Settings. This is contrary to the default User Settings template supplied by RES, however, but this allows users to reset the general settings for IE without affecting the their personal Cookies, Favo(u)rites and History. image
  4. We have found that when using the default User Settings template supplied by RES it doesn’t capture any typed URL history in Internet Explorer. To resolve this issue just add the registry key : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TypedURLs to the IE application User Settings.
  5. If you have multiple managed instances of Internet Explorer, i.e. shortcuts to URLs that point to IEXPLORE.EXE make sure you link the settings back to the “master” IE application. Creating “snapshots” of the same keys and files/folders can cause major inconsistencies to the user’s environment as RES Workspace Manager loads different settings depending on which shortcut is used.

Enjoy ! Additional comments and recommendations are more then welcome!