March 2011 – Virtual Engine Ltd

25th March 2011

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

25th March 2011

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

16th March 2011

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

11th March 2011

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

9th March 2011

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

7th March 2011

Automation Manager Dispatcher Discovery and WoL

RES Automation Manager agents are configured to auto discover an available Dispatcher by default, but this will cause issues when the Dispatchers are located on another LAN segment or VLAN. In addition, the Wake on LAN (WoL) packets won’t generally be forwarded by switches/routers by default either. Therefore, how do we resolve this little conundrum?

Now I’m not a network engineer. I can configure basic switch ports and VLANs on HP/Cisco switches, but I couldn’t tell you how BGP works its magic to keep the internet running. I know what it does, but I’ve no idea how it does it. When requesting network infrastructure changes to support the Dispatcher discovery process and WoL on a customer’s site, the network engineer typically wants to know exactly what needs configuring. By simply saying, “enable Multicast for discovery and Broadcast for WoL throughout the network” generally puts a network engineers in a panic and they break out in a cold sweat! So what are these “exact requirements” that network engineers speak of?

Dispatcher Discovery

The RES Automation Manager dispatcher discovery process utilises Multicast. In its simplest form, there are devices on the network that subscribe/listen to a multicast address. When packets are sent to this multicast address, they are forwarded to devices that are actively listening or are members of the group. This process eliminates broadcast storms on the network that could otherwise exist by being selective about whom receives the packets.

In RES AM terminology, when a Dispatcher comes online it will attempt to register to receive UDP packets on the 224.1.1.150 Multicast address on UDP/3163. When a RES AM Agent comes online, it broadcasts via UDP on port 3163 to the multicast group, address 224.1.1.150. Hopefully the dispatchers receive the request, and one responds. Therefore, when speaking to network administrators, you need to ensure that IGMP/PIM is enabled on all network equipment that RES AM Dispatchers and Agents are connected to and that the Multicast 224.1.1.150 address is permitted.

WoL

The WoL process works completely differently in that the “magic packet” needs to be broadcast on the LAN segment that the targeted machine is connected to. In RES Wisdom 2009 (and prior) global broadcast packets to 255.255.255.255 needed to be permitted from all RES Wisdom Dispatchers to all LAN segments that client machines were connected to. Needless to say that this is inefficient and network admins are generally reluctant to enable it.

In RES Automation Manager 2011 we’ve got a shiny new Global Option available to us:

This option will use Subnet Directed Broadcasts (SDB) for all WoL packets. The last network hop will broadcast on the targeted subnet without flooding network (unlike the global broadcast address). Like the Discovery process this requires Layer 3 network switches to be implemented and SDB enabled. Note: care needs to be taken when implementing as this could enable DDoS attacks. Remember to limit the origin of the SDB packets to only RES Automation Manager Dispatchers from UDP/3163 (by default) to the subnets that each Dispatcher needs to broadcast to.

If anyone knows the specific Cisco/HP terminology that needs to be used to avoid ambiguity then please let me know and I’ll update the post. Thanks, Iain