RES Workspace Manager Registry Import Bug

[UPDATE 01/08/2011 – RES have released a fixpack for RES Workspace Manager 2011 SR1 that resolves the issues highlighted in this post. I don’t have any word on whether this fix will be rolled into the next Service Release of RES PowerFuse 2010 (SR5?). I hope so as we can then remove this post. In the meantime, please contact RES Software support to obtain this fix (assuming you’re running WM 2011 SR1!)]

An issue has been discovered in RES Workspace Manager 2011 and earlier versions (e.g. PowerFuse) when importing .REG files. Ironically, this was discovered when converting existing Group Policy Objects via the Virtual Engine Toolkit (VET). RES Workspace Manager does not implement the removal/deletion of registry keys or values correctly. It has been reported to RES Software and they have acknowledged there is an issue. It is not an issue with the Virtual Engine Toolkit but a problem with any .REG file, i.e. one’s migrated from log on scripts etc. [UPDATE – for clarification purposes, a support ticket had been raised prior to this post and RES are working on a fix.]

The following snippet from a REG file (some entries removed for clarity) should toggle the removal of NoInternetIcon and NoNetHood values and also toggle the removal of the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key.

Windows Registry Editor Version 5.00;
Created by the Virtual Engine Toolkit v0.9.7.0;
Creation date: 05-30-2011 17:04:08



What actually happens is RES Workspace Manager sets the two DWORD vales to 1 and doesn’t even import the \Software\Policies\Microsoft\Windows\NetCache\AssignedOfflineFolders key as shown below. This results in complete unexpected behaviour and might impact any Proof of Concept or pilot deployments.

Hopefully this issue will get resolved promptly but in the meantime, please be vigil!


Add computers to a local group using RES Automation Manager

One of the many built in tasks that are provided in RES Automation Manager is the ablility to add users or groups to a local group on a server or desktop. The task does what it says on the tin but one unknown fact (well to me at least until I tried it) is you can also add computers to a local group too using the same task. A very simple example of this would be when using Remote Desktop Services and the Remote Desktop Connection Broker. In this example each Remote Desktop Session Host that is participating in the farm needs to be added to a local group on the Remote Desktop Connection Broker called “Session Broker Computers”.

To add a computer to the local group you simply need to add a dollar ($) after the computer name in the “User(s) and/or group(s) to add” field as you can see in the screen shot below.

It’s as simple as that!!


Updating your XenApp farm using RES Automation Manager

When publishing an application across multiple servers in a XenApp farm one of the key elements to a trouble free environment is having consistency across the farm.  RES Automation manager can help with getting this right.

So, you have your software package imported into Automation Manager and you deploy to each XenApp server in turn.  Here I will go through a method of updating that software and running maintenance automatically with no outage and (most importantly) an easy life for everyone.

First we should set out exactly what we need to do.  There are several stages to this process:

  1. Disable access to the XenApp server
  2. Ensure users are not logged on.
  3. Switching to install mode.
  4. Check version and run Installation.
  5. Switching to execute mode.
  6. Enable logon to the server.

These stages can easily be broken down into 3 Automation Manager Modules; let’s take a look at how to get them setup.

Module 1
Disable logons, wait for the server to be free from users and switch to install mode.
We have three tasks to run here:

Task 1 – Disable logons
Click Add to create the first task of the module.  Select Remote terminal server logins (Change) from the configuration folder and select :
Disable remote logins

Make sure you name the task appropriately and you’re done.

Task 2 – Wait for the server to be free from users
Best practice when installing software on a XenApp server suggests that you should not have any user sessions on that server.  Therefore we need to wait for users to leave.  Now I’m not all that interested in sitting in front of the Access Management Console hitting refresh every 5 minutes until everyone is off, so let’s get AM to do that for us!

We need to make use of the PowerShell capabilities for this, so click Add and select Windows PowerShell Script (Execute) from the advanced folder.  One of the recent improvements to AM is the ability to input a script directly into the task, this helps keep the whole process in a single place.  You can also easily save the script as a resource and point the task to it (good if you have a single script being reused in multiple tasks).

On the settings tab select “Use Windows PowerShell script from “Script” tab” to enable the Script tab, or point the task to the .ps1 file if you have already saved it as a resource.

By default, the PowerShell scripts that you run using this Task need to be digitally signed.  Select Override execution policy for this Task to temporarily lower the PowerShell execution policy to “Unrestricted” and use an unsigned PowerShell script.  After execution of the Task, the PowerShell security will be reverted to the previous security level.

Next you will need to set the timeout.  Since you want the script to run until all users are logged off you need to set this to the maximum allowed, this being 300 minutes.  It would be nice if there was the option to disable the timeout if required, but there isn’t at the moment so 5 hours will have to do for now.

Once you’re done here you’ll need to click the script tab and add the script.

The Script

The script checks the session count on the XenApp server every 5 minutes.  If any user accounts are disconnected, it will log them off.  The script will loop until there are zero sessions or the timeout is reached.  This is key to allowing a RES AM job that waits for a condition to occur before moving on, since the AM native conditions will only be evaluated once at the start of the job.

Although you will not be able to view the output of the script while it is running, it is kept in the job history to help with diagnosis.

Script File (Zip)

Task 3 – Switch to install mode
The final Task in this Module will switch the XenApp server to install mode.  Using the Command (Execute) task from the advanced folder we will use the following command:

Change user /install

Make sure you tick Use Windows command interpreter.

This command is not strictly required anymore, XenApp is intelligent enough to recognise an install process and switch to install mode automatically, but since AM uses the system account and since you won’t always want to just run an msi or an exe it’s better to set it and be sure.

At this point your XenApp server is ready to accept whatever installs and modifications you need to apply.  You could use this set of tasks and finish with an email notification telling you the server is ready to manually have other modules run against it.  However, we are looking for a fully automated process.

Module 2
Check version and run Installation, configuration etc.

Module 2 is the set of tasks you want to run against the box.   Here I am going to use an MSI that I built using a combination of VSS and WixBuild to demonstrate a fully automated software update process.

To start with, I save the MSI as a resource.  The resource type should be “stored in datastore”, this way AM assigns a GUID to the resource, and I will explain why you need this GUID later.

Next I need to add a new Module and create the task, in my case this was a Windows Installer package task from the Provisioning folder.  On the settings tab click the Browse button next to the Filename field and select the resource, configure any other settings (such as Properties or Transforms on the Parameters tab) and click OK.

Note:  With MSI Installs I would always recommend using the Log tab to set the required level of logging and click “Remember as Default”.  This way you will have the installer log files available in the job history should you ever need to diagnose an issue.

Once you have added all the required tasks (including any reboots needed) you are almost ready, just one final module to create.

Module 3
Switch to execute mode and enable logon to the server

This is the final module.  All you need now is for the XenApp server to be made available.  For this you will need a module with 2 tasks (as in Module 1) with the following:

Task 1 – Command (Execute), but this time we will run “change user /execute”

Task 2 – Remote terminal server logins (Change).  This time we are going to Enable remote logins.

Run Book

Run Books are used to create a chain of jobs; each job can be run on a different agent in the same run book.

Add a Run Book, then on the Jobs tab add Module 1 (Disable logons, wait for the server to be free from users and switch to install mode), select the XenApp server as the agent and Click OK.  Repeat this for Module 2 (Check version and run Installation) and 3 (Switch to execute mode and enable logon to the server).

Once these are added the jobs can be cloned and the Agent name changed so that you have Modules 1, 2 and 3 running on each XenApp server in turn or use Teams and split the job to schedule the upgrades/updates in batches.

Schedule and New versions

This Run book can then be scheduled to run at an appropriate time using Job scheduling.

Once the schedule is in place all you need to do to update the Citrix farm is open up the resource files that Module 2 points to and update them.  Since AM has assigned a GUID to the resources the new files will automatically be associated with the task.  Next time the Job runs each Citrix server will disable logins, wait for each user to log off (or log off disconnected sessions) run the new MSI to update the software and re-enable itself.

You meanwhile, can sit back and relax.

If you want to avoid running the Modules during every schedule (as there may not have been an update to the software) then you can use a combination of evaluators and conditions to ensure that the specified tasks/modules do or do not run as required. Make sure the first task is an Installed programs query (found in the System state folder), configure an evaluator that checks for the latest version number and sets a parameter to “True” or “False”.  Once this is in you then set a condition on each individual task to run dependant on the evaluator.  Using this method you can quickly build up a single Run book that runs all your regular Citrix maintenance.


Guest Blogger: Dan Beeson

It’s my pleasure to introduce Dan Beeson who will be a guest blogger on the Virtual Engine blog. Dan is one of a handful of techies in the UK to be rewarded with the RES Software Valuable Professional (RSVP) title. Needless to say this is something that is rewarded and not something you can buy (not that I’ve asked!). He currently works for a law firm in London and has vast experience deploying and managing desktops.

Dan has been using RES Automation Manager for many years and also has recent experience with Service Orchestration in a production environment. As Service Orchestration is “new in 2011” there are not many people who are in a position in the UK to deploy it to its full potential. Therefore, there will hopefully be some great blog posts in the coming months.

Nathan and I would also like to take this opportunity to personally thank Dan for a) taking the opportunity to help the community and b) for taking the time to do this. We both know how much time and effort is needed to write good blog posts, hence the lack of recent activity.

Rest assured that there are many things in the pipeline. In the meantime, Dan will hopefully be filling in the gaps!

Thanks, Iain

Office 2003, 2007, 2010 and 2008 R2 Templates Released

The merged Microsoft Office 2003, Office 2007 and Office 2010 template files have been uploaded to the Virtual Engine website and are available for download in the Templates section. Each .ZIP file contains all the office templates for each product edition, e.g. Standard, Small Business and Professional etc, making it easy for you to configure settings for multiple Office products in a single policy within the RES Workspace Manager management console.


In addition, all the standard Windows 2008 R2 Service Pack 1 administrative templates have been merged into a single file and is also available in the same place (as the Office templates). Using this template enables you configure all the standard Group Policy Administrative Template settings in a single Registry Policy within the RES Workspace Manager management console too. It takes a little while to expand the file due to the number of settings (it is all 156 ADMX files merged into 1!), but does mean that the console looks less cluttered. Here is what it looks like:


All these files were put together with the Virtual Engine Toolkit (VET) so if they don’t meet your individual requirements you can always download the tool and “roll your own”. Note: a new BETA 3 version will be released in the near future that fixes a few reported bugs and sports a couple of new features too..

Enjoy! Iain

Finding the RES Workspace Manager Run Once GUIDS

Following on from the initial post on the Run Once Per Computer and Run Once Per Computer, Per User  GUID locations for the .ONCE files, it’s probably wise to let you know how to correlate the GUIDs used with their corresponding configuration items. There is no exposure to the GUIDs directly within the RES Workspace Manager GUI so to find these GUIDs we have to dig into the client database cache (there is a RES KB article but I can’t find it in the portal due to the search engine!).

All RES Workspace Manager agents download and cache a complete copy of the configuration database tables in the %RESPFDIR%\Data\DBCache\Objects folder as .XML files. In here are lots of files correlating to the configuration database tables within the database. The key to this process is to know what files you’re looking for! Here is a list of which files correspond to which object in the database that we’re interested in:

.XML File Object
apps.xml Applications (Notifications)
inst_mail.xml Email Templates
pl_reg.xml Registry Settings/Policies
pl_task.xml External Tasks

Armed with this information we can crack open the relevant file (pl_tasks.xml in this instance) with your favourite text/XML editor and perform a search for the “<runoncefile>” string to locate the relevant GUID.


To delete the .ONCE file for the “Per User Computer” external task, we need to delete the 132DBDF_34930_105A_TASK.ONE file from the %RESPFDIR%\Data (as it’s a related to the computer and not the user!) directory.

Note: @RESGuru has also pointed out that you can locate the relevant .ONCE files by exporting the item in question to a Building Block and then inspect the resulting .XML file. Thanks, Iain

RES Workspace Manager Run Once Per Computer, Per User

We all know that RES Workspace Manager stores the flag that determines if a Run Once task has completed for a given user in the \PWRMENU folder (at least by default). These files are named with the .ONCE file extension and given a (seemingly random) GUID, i.e. <SeeminglyRandomGUID>_task.once.

Unfortunately, there is no simple way of determining which .ONCE file relates to which task but that’s a post for another day! To force a task to rerun for a given user all we need to do is delete the relevant .ONCE file and the task will magically rerun. This avoids the necessity to check the “Clear History” checkbox and force it to run again for all users.

What about the Run Once Per User, Per Computer and Run Once Per Computer options? Logically they don’t live in the user’s \PWRMENU folder as they’re not a per user setting. So where do they live? After a discussion with RES Support it was discovered they live in the %RESPFDIR%\Data directory. Once you’ve determined which file relates to which task you can just delete it!

Here is an example of a Run Once Per Computer and Run Once Per Computer, Per User external tasks:


The 132DBDF_34930_105A_task.once file is a Per Computer external task. The 132DBDF_34981_1381_<domain>_<username>_task.once files are the Per Computer, Per User tasks for the LAB\Administrator and LAB\LOCAL01 user accounts.

Easy when you know how! Iain

Workspace Manager, Aero Basic Theme and Mandatory Profiles

For those of you that have attempted to deploy RES Workspace Manager 2011 (or RES PowerFuse 2010) on Windows 7 and wanted to use Mandatory Profiles with the Windows Aero Basic experience, you might have come across this issue. If you utilise the standard .Default user profile as your starting point for the Mandatory profile, you may discover that users do not have the Aero theme enabled as expected. The user experience either on traditional physical or hosted virtual desktops may look something like this:


Note: This typically happens if you enable the “Disable Active Setup (skip first-time shell init)” option in Composition > Desktop > Lockdown and Behaviour section of the RES Workspace Manager management console. This presumably because by the time User Settings are loaded by RES Workspace Manager, the Themes service has already processed the required registry keys loading the (mandatory) profile.

The resolution to this is to enable the Aero theme when utilising the Mandatory profile and export the HKCU\Software\Microsoft\Windows\CurrentVersion\Themes and the HKCU\Software\Microsoft\Windows\CurrentVersion\ThemeManager registry keys. These can then be merged into the existing NTUSER.MAN registry hive to enable the Aero theme by default (see the Updating Mandatory Profiles post for further information on how to do this).

When you update the Mandatory profile with the Themes/ThemeManager settings you’ll end up with something like this:


Note: This process is also applicable for Windows 2008/R2 RDS servers with the Desktop Experience feature installed.

Easy when you know how! Iain

Updating Mandatory Profiles

[UPDATE 17/01/2012 – The process detailed in this post has been simplied in the Updating Mandatory Profiles Part 2 post]

In a RES Workspace Manager environment it’s is typical (although not required) to store Mandatory profiles within the RES Workspace Manager Custom Resources. By doing this, we remove any reliance on the network, avoid the typical profile error messages when logging on to laptops offline and reduce the network load on RDS/XenApp servers. Every once in a while there will be the need to update the NTUSER.MAN file with additional settings, e.g. the ActiveSetup keys when software is added to the RDS/XenApp servers.

In this example we will update the Mandatory profile with the ActiveSetup keys from our desktop image. We accomplish this by logging on to the desktop with our standard Mandatory profile (the Workspace Composer should not active at this point!). All being well, the ActiveSetup components should run on log in, populating the ActiveSetup registry keys.

After ActiveSetup has run we can launch REGEDIT from within the user session and export the required key(s) to a .REG file that we can import into the Mandatory profile later. To do this, navigate to HKCU\Software\Microsoft\ActiveSetup\InstalledComponents registry key and export to a .REG file.


In our example I’ve saved the file as ActiveSetup.REG. If we edit this file with Notepad we can see all the references point to HKEY_CURRENT_USER. Before we load the NTUSER.MAN registry hive, we need replace the HKEY_CURRENT_USER references with the hive name that we will mount it as with in REGEDIT. In our example, we’ll replace all references with HKEY_USERS\MANDATORY using Notepad’s “Find & Replace” functionality.


Once updated, we can save the ActiveSetup.REG file and launch REGEDIT once again. The Mandatory profile NTUSER.MAN hive can be loaded by clicking the HKEY_USERS hive and then clicking the File > Load Hive menu option.


Navigate to the Mandatory profile NTUSER.MAN file and when prompted for the Key Name we need to enter the same key we used in the File and Replace option earlier. In our instance, this needs to be MANDATORY, hence the HKEY_USERS\MANDATORY reference.


Once the hive is loaded we can import our modified ActiveSetup.REG file into the NTUSER.MAN hive. Once the import is complete you can confirm that the settings have been imported into the correct location:


Be sure to unload the registry hive by clicking the HKEY_USERS\MANDATORY key and then clicking File > Unload Hive. When prompted to save the changes make sure to click Yes. When you log off and back on again the ActiveSetup components should not run again. Note: if you install additional software on to the desktop image and it utilises ActiveSetup, you will need to perform this process again (unless you utilise the RES Workspace Manager “Disable Active Setup (skips first-time shell init)” option).

Good luck! Iain

Migrating GPOs to RES Workspace Manager (Part 6)

Taking the Merging ADM files (Migrating GPOs to RES Workspace Manager – Part 5) blog post to the extreme, here is a demonstration of merging all the default Windows 7/2008 group policy ADMX files. By default there are 148 separate ADMX files that make up the “default” GPO settings available within the Group Policy Management Console (on Windows 7). If we needed to recreate these in RES Workspace Manager we would need 148 separate Registry Policy objects . Each Registry Policy object within the RES Workspace Management Console can only be based on a single ADMX file. Believe me, this is not pretty. Note: It’s not recommended that you do this and this example is for demonstration purposes only. Only merge the ADMX files that contain the options you need to set!

What follows is how we can create one (albeit very big) ADMX/L file that can be uploaded into RES Workspace Manager.

  1. Open the Virtual Engine Toolkit.
  2. Select the “Merge ADMXs” tab.
  3. Drag’n’drop all the ADMX files in the default “C:\Windows\PolicyDefinitions\” folder (when run on a Windows Vista or later computer) into the top window.
  4. Specify the output location directory.
  5. Specify the output filename (the ADMX and ADML file extensions will automagically be added).
  6. Click the green “Toolkit” button (and wait!).


On my laptop this took approximately 30 seconds and resulted in a combined 4.27MB “Win7_Defaults.ADMX/L” files. Load this into the RES Workspace Manager Management Console (it takes a little while!) and it looks like this:


Simple! And there’s more to follow…