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

Migrating GPOs to RES PowerFuse (Part 3)

So far in our ambition to migrate existing Group Policy Objects into RES PowerFuse we have detailed the shortcomings of doing so (Part 1) and discovered that all the registry settings for the User Container settings (“Administrative Templates” only) in a GPO are stored in the SYSVOL share as a REGISTRY.POL file (Part 2). Now we need to transpose the settings contained within the .POL file into a .REG file that is useable by RES PowerFuse.

Unfortunately, the .POL file format is a binary format that is not the same as the text-based .REG file format. There appears to be no easy way to view the contents of these files. The binary format is documented on the MSDN web site if you feel inclined to have a look. When we open a .POL file with notepad this is what we get:


Therefore, before we can import this into RES PowerFuse we need to convert it to a text-based .REG file. After many hours scouring the internet, only a handful of solutions seem to be available.

There do appear to be some commercial registry utilities, i.e. Registry Workshop, that permit the loading/viewing of .POL files. The evaluation version of Registry Workshop does not allow exporting so it is unclear as to whether a .POL file can be exported as a .REG file that we can use with RES PowerFuse. In addition, we’re after a solution that doesn’t cost any money.

An alternative is the REGVIEW.EXE utility in the Windows 2003 Server Resource Kit. This does allow us to view the contents of the REGISTRY.POL file. Running the utility displays the contents of a .POL in text format like this:


Unfortunately, this utility does not allow us to convert the REGISTRY.POL to a useful format, e.g. CSV. To utilise this tool we will have to redirect the output to a .TXT file, e.g. REGVIEW REGISTRY.POL > OUTPUT.TXT. Once in a plain text format we would then have to run another tool or script to convert the output to .REG. This is going to require some development time to implement.

To be continued…

RES Automation Manager 2011 Release Date

According to the new look RES Software web site, RES Automation Manager 2011 (formerly RES Wisdom) product will ship on the 1st November 2010. I can reveal that the RES Wisdom 2011 Release Candidate has already been rebranded as RES Automation Manager 2011. More details/information on the new features will published once the final product is available from the RES Software web site.

RES Software have Rebranded

RES 2010 Logo

Today, RES Software’s web site has a new look and feel. In addition the RES PowerFuse and RES Wisdom products have also been rebranded. Here are the highlights:

  • RES PowerFuse will be now known as RES Workspace Manager.
  • RES Workspace Manager will no longer be licensed as different Editions, rather each module will be licensed separately (Yay!).
  • RES Workspace Manager Modules:
    • Composition & Personalization
    • Advanced Administration
    • Security & Performance
  • RES Wisdom will be known as RES Automation Manager.
  • RES Automation Manager Modules:
    • Task Automation
    • Resource Provisioning
    • Service Orchestration
  • The RES Dynamic Desktop Studio will be available as the new bundle of all technologies.
  • RES Subscriber/Workspace Extender will be known as Virtual Desktop Extender (VDX) and available as a standalone product from January 2011.

Overall – exciting times!

Decoding the PWRMENU.INI Colours

Setting the desktop foreground and background colours is something that trips most of us up when we’re first picking up RES PowerFuse. The default PWRMENU.INI file contains default colours that are created at install that apply to all users. If these colours are changed via the Composition > Desktop > Background node in the RES PowerFuse Management Console, then the template PWRMENU.INI file is updated. Any time a change is made to the desktop colours, it won’t affect users that have already launched a RES PowerFuse session as the user’s PWRMENU.INI file won’t get updated (with the default settings). For an explanation and work around this, see RES Knowledgebase Article Q200186.

This however, is not what this post is about. Typically when uploading a custom background image we normally wish the background colour to match the background colour in our .BMP file (remember only the RES PowerFuse Shell supports .JPEGs). This is certainly true if we’re not stretching the image to fill the screen. If it’s not changed you’ll see the default blue background applied before the background image is applied and/or borders around the background image.

Unfortunately for us, when selecting the colours using the RES PowerFuse Management Console it is not necessarily intuitive or easy to pick the right colour that matches your uploaded .BMP file. We have to specify a custom colour, enter the RGB values, save the changes to make sure the default PWRMENU.INI is updated, open the default PWRMENU.INI file, note the colour “number” specified next to the DesktopColor property and then create a Home Directory Maintenance Task to update this value for existing users (as per the aforementioned KB article). Not particularly quick nor intuitive. Note: If you’re after a tool to pick up colours then you can use ColorPic and it freeware.

We’ll take Virtual Engine as an example. Internally there is a colour that is known as VE-Blue (or Virtual Engine Blue). This is the standard shade of blue used in email communication, on business cards and the on web site etc. The RGB (Red, Green and Blue) representations of this are; 4 (Red), 73 (Green) and 157 (Blue) or 04499D in hex. Is there an alternative process available to set the background colour used by RES PowerFuse without jumping through all the hoops listed above?

In the user’s PWRMENU.INI configuration file the colours are not specified in the standard hex/web format, they’re represented as a decimal number. Using the “Programmer” view available in the standard Windows 7 Calculator we can convert 04499D (hex) into decimal (280989). We now have the decimal representation that can be put straight in to the Home Directory maintenance task. Knowing this information we update the default PWRMENU.INI file and create a Home Directory Maintenance Task that updates this for all existing users… Ah – when testing this we end up with a nice brown, muddy background. Not what was expected!

After a little bit of reverse engineering, it turns out that the number is reversed and actually stored as a BGR (Blue, Green and Red) value. In our example we need to convert 9D4904 (hex) to its decimal value, i.e. 10307844. Putting this value in our Home Directory Maintenance Task and the default PWRMENU.INI file works first time and is an exact match. If you happen to have lots of different coloured backgrounds for various departments in your environment, this little bit of knowledge might save you 30 minutes and a lot of frustration one day..

Staging RES PowerFuse 2010 Agent Deployment

Disclaimer: This is definitely something that  is not supported or endorsed by RES Software in any way shape or form. If you can avoid doing this then do not use it. Use at your own risk!

In large RES PowerFuse deployments where RES PowerFuse agents are located over a WAN link, deploying RES PowerFuse can place an unwanted strain on those WAN links during initial deployment. When the RES PowerFuse agent is first installed, it connects to the database and downloads the cache. Until this is complete (and if the Workspace Composer is enabled) a user is unable to log in.

In instances like this it is ideal to have database instances located on the local sites but this is not always possible due to licensing issues etc. If this is the case, then having 100+ agents download 50MB+ leads to a lot of unwanted bandwidth being consumed! This guide will help you stage the deployment so that the agents only download the deltas from our “database snapshot” that is deployed as and when we install RES PowerFuse.

To accomplish this, we need to think about the database structure and how the agent caches its information. The RES PowerFuse 2010 database contains GUIDs for each of the configuration database tables and a master GUID. Whenever anything is updated within the Management Console, the master GUID is updated and this update is cascaded to all corresponding configuration tables that have changed, updating their GUIDs in turn. When an agent connects it checks the master GUID and if different from its own master GUID, compares the GUIDs on each table and downloads the differences. The agent stores its cache and state information in a few places:

  • The local state of the database cache is maintained in the registry (HKLM\Software\RES\PowerFuse\UpdateGUIDs). These values are the GUIDs that the agent uses when connecting to the database. If any database configuration table GUID is different from what is stored here, an update is performed and the GUID changed to match the GUID in the central database.
  • The cached database tables are stored in XML format in the ‘%RESPFDIR%\Data\DBCache\Objects’ directory.
  • All other supporting resources are located within the ‘%RESPFDIR%\Data\DBCache\Resources’ directory and ‘%RESPFDIR%\Data\DBCache\IconCache’ directories.

Now, in theory all we need to do to pre-stage the agent cache is make sure that the UpdateGUIDs in the registry match what is in the \Objects, \Resources and \IconCache folders when the agent service is started. To capture our pre-staged “snapshot” we need to perform the following actions:

  1. Stop the RES PowerFuse agent service.
  2. Copy the \Objects, \Resources and \IconCache folders somewhere safe.
  3. Copy all the UpdateGUIDs from HKLM\Software\RES\PowerFuse\UpdateGUIDs (probably an export to a .REG file)

Herein lies the key to this operation. When we deploy the agent, the RES PowerFuse agent service is going to automatically start and proceed to populate the local cache and update the UpdateGUIDs in the registry. We do not want this to happen until we’re ready. Therefore, this is the process that we need to achieve:

  1. Install the RES PowerFuse agent unattended in the supported fashion, i.e. with Wisdom, ensuring that the agent service does not start.
  2. Copy our “snapshot” files to the \Objects, \Resources and \IconCache folders. How we do this depends on your deployment methodology. Typically the “snapshot” files would be captured as a RES Wisdom Resource Package, but it doesn’t really matter.
  3. Set the HKLM\Software\RES\PowerFuse\UpdateGUIDs registry values to our point-in-time ““snapshot” to match what is representative of the “snapshot cache” folders. Again, this can be achieved quite simply with a RES Wisdom “Apply Registry Settings” task, but could also be achieved via a batch file calling REG.EXE.
  4. Start the agent service (a reboot is still required for the kernel mode drivers to start). If we just reboot the service state is left as “Automatic” and will start after just a reboot.
  5. The agent will check the database and only download the deltas from the point-in-time “snapshot” hopefully saving a whole load of bandwidth!

The only real “gotcha” in this entire process is ensuring that the agent service does not start when the agent is installed, e.g. in Step #1 above. As the agent does not support the public properties to accomplish this we need to do it via a .MST file. To save you a whole load of time and pain we’ve kindly left one here for you called “RPF-NoServiceStartAfterInstall”.

Our example deployment command for Step #1 might look a little like this: MSIEXEC.EXE /i RES-PowerFuse-2010-SR2.msi TRANSFORMS=RPF-NoServiceStartAfterInstall.mst DBTYPE=MSSQL DBSERVER=<DatabaseServer> DBNAME=<DatabaseName> DBUSER=<DatabaseUser> DBPASSWORD=<DatabasePassword> /norestart /qn

Please remember; test and test again!

Migrating GPOs to RES PowerFuse (Part 2)

In Part 1 we covered the basics of Group Policy Objects (GPOs), how they are implemented and the shortcomings of implementing Policy objects as User Registry Policies within RES PowerFuse. In our quest to work out how to migrate existing GPOs in to RES PowerFuse we’ll take a deeper dive in to how GPOs are stored and how we can get the existing settings out and allow us to import them into RES PowerFuse.

GPOs are stored within the SYSVOL share on Domain Controllers within the Active Directory infrastructure. The following information is from Group Policy Storage page from Microsoft.com.

Group Policy objects also store Group Policy information in a folder structure called the Group Policy template that is located in the System Volume folder of domain controllers (Sysvol) in the \Policies sub-folder. The Group Policy template is the container where Security Settings, Administrative Template-based policy settings, applications available for Software Installation, and script files are stored.

When you modify a GPO, the directory name given to the Group Policy template is the GUID of the GPO that you modified. For example, assume that you modified a GPO associated with a domain called Seattle. The resulting Group Policy template folder would be named as follows (the GUID is an example):


Registry.pol Files

All settings defined within the “Administrative Templates” section of a GPO are saved into the SYSVOL location indicated above as a REGISTRY.POL file either under the \User or \Machine subfolder depending on whether they are User-based or Machine-based policies. Here is the quote from the MS page:

The Administrative Templates snap-in extension of Group Policy saves information in the Group Policy template in Unicode files referred to as Registry.pol files; they are stored in the Group Policy template. These files contain the customized registry settings that you specify (by using the Group Policy Object Editor) to be applied to the Computer (HKEY_LOCAL_MACHINE) or User (HKEY_CURRENT_USER) portion of the registry.

Two Registry.pol files are created and stored in the Group Policy template, one for Computer Configuration, which is stored in the \Machine subdirectory, and one for User Configuration, which is stored in the \User subdirectory.

When you use the Administrative Templates extension of the Group Policy Object Editor to define customized registry settings, two Registry.pol files are created and stored in the Group Policy template. One Registry.pol file is for Computer Configuration-related registry settings and is stored in the \Machine sub-directory, and the other is for User Configuration settings and is stored in the \User sub-directory.

This means that all the User-based “Administrative Temples” settings within a GPO are stored within a single REGISTRY.POL file under the \User folder in the SYSVOL share. Therefore, if we can import the REGISTRY.POL file into RES PowerFuse we have a simple way of migrating an existing GPO, in its entirety. The custom extension information won’t be imported, e.g. software installation policies etc, but you’re probably using RES Wisdom for this anyway! There will be no need to manually import the ADM/ADMX templates and manually recreate all the individual settings for everything defined under the “Administrative Templates” section. Simples!

To be continued…

RES PowerFuse Workspaces White Paper

Hot off the Virtual Engine press is the “RES PowerFuse Workspaces” White Paper. The White Paper can be downloaded from the Virtual Engine website here. As always, positive and negative feedback is welcomed.

When delivering RES PowerFuse training, this subject is something that some delegates can find confusing. As RES PowerFuse Workspace Containers have many uses, getting in a real twist is incredibly easy to do. This White Paper walks you through all of the RES PowerFuse Workspace Container uses based on a fictitious company providing a practical example of what to do and what not to do.

A big thanks to Max Ranzau AKA RESGuru for his assistance in getting this document completed. Enjoy!

Disable Active Setup

RESGuru has updated the RG01F – Getting rid of the first-time login stuff technote article with the new RES PowerFuse 2010 SR2 feature; “Disable Active Setup (Skips First Time Shell Init)”. My experience with this is that it works for v2 profiles, but not v1, e.g. Windows XP and Windows Server 2003.

During a RES PowerFuse 2010 SR2 PoC , we had deployed mandatory profiles for both Windows XP desktops and Windows Server 2003 with Citrix Presentation Server 4.0. Checking the aforementioned checkbox did not have the expected behaviour, i.e. we assumed that it would stop the Active Setup components from running. Needless to say – it didn’t and we were back to square one. After a call to support it appears that this only works on Windows 2008/R2 and Windows 7, i.e. v2 profiles.

Whether this is a bug or a “feature” I’m not sure.