Workspace Manager – Virtual Engine Ltd

23rd May 2013

RES Workspace Manager Training Dates

Virtual Engine are pleased to announce that we’re running official RES Workspace Manager 2012 training courses in July 2013, in London. The following courses are available:

3 day RES Workspace Manager 2012 Bronze RWMBC-510 course (details) between July 15 – 17 2013
4 day RES Workspace Manager 2012 Silver/Gold RWMBC-510, 520 and 530 courses (details) from 15 – 18 July 2013.

If you would like to attend either of these training courses or require pricing information then please get in contact. Places are allocated on a first-come, first-served basis!

22nd May 2013

RES Workspace Manager 2012 Integration with Configuration Manager 2012 SP1 (SCCM)

This blog contains the ramblings of a man who has just installed System Center Configuration Manager 2012 SP1 in our RES Demo Showcase, to show how the integration works with RES Workspace Manager 2012.

The first thing I’d like to point out is why anyone would prefer to use Configuration Manager over RES Automation Manager is beyond me, but that’s probably left for another blog post. One thing I will say is that “simplicity” is not something I’d ever use to describe Configuration Manager! Enough of the drivel; lets get on with the real reason for this post.

Configuration Manager is used by many customers as a software delivery tool to deploy and install applications across their organisation. These applications can be targeted at devices or users and installed when required, i.e. when the user requests them or in a mandatory fashion; say when a new version of Microsoft Office is rolled out. Now this is all fine and dandy but there is no context awareness behind these deployment mechanisms. By context I mean Who they are, What type of device they are using, Where they are located and When they initiated the installation. Configuration Manager does now try and address this short coming by introducing the new “Applications” feature and “Rules”, but its limited in what it can do.

Those of you reading this blog post will hopefully already understand that RES Workspace Manager has been built around this ethos from before the dinosaurs (not quite, but you get my point). With that in mind you’d be correct in asking, “wouldn’t it be a great idea if RES Workspace Manager could integrate with Configuration Manager?” This would bring context awareness to application installs as well as delivering these applications “Just-In-Time,” i.e. when the user attempts to launch an application shortcut (if the application wasn’t already present). Well you might have guessed it by now, you can, and I’m going to show you how and what kind of things to look out for. I’m assuming you already know how to install and configure Configuration Manager (and its running ever so sweetly on your site servers consuming resources like there going out of fashion) so I’m not going to cover that bit!!

Configuration Manager “Applications”

One important point I’d like to mention here is that Workspace Manager does not yet support the new “Applications” feature in Configuration Manager 2012. When I say “support” I mean it will not work at all in Workspace Manager 2012 SR2. Whether that’s something RES will add at a later date I’m not entirely sure, but for the sake of this blog it doesn’t. That means you have to continue to create and use the old style “Packages” and “Programs” that everyone knew and loved in previous versions of Configuration Manager.

Configuration Manager “Advertisements”

Another important point that might be worth mentioning at this time, from my testing, it doesn’t seem you actually have to create the “Deployment” (aka “Advertisement” in older versions) for the Programs that will be integrated with RES Workspace Manager. From the testing I’ve been doing, what actually seems to happen is RES Workspace Manager creates a temporary collection and advertisement/deployment on the fly, and deletes these once the application has been deployed and installed. The collection is named after the device where you initiated the installation from and if you’re quick enough you can see these objects being created in Configuration Manager console.

Configuration Manager “Administrative User”

You need to supply RES Workspace Manager, with a user that’s been defined in Configuration Manage and has sufficient privileges to carry out certain tasks; namely manage collections and create deployments. Configuration Manager 2012 has various security roles predefined but from my testing the minimum role that can be used is the “Application Administrator”. So I’d create a new user in Active Directory, could be a service account, add them as an administrative user in Configuration Manager i.e. RESWM and assign them that role – if you not bothered about security, you can grant them the “Full Administrator” role Surprised smile .

The first thing we need to do is enable the integration in RES Workspace Manager; which is relatively straight forward and is split into two phases.

Phase 1

Start the RES Workspace Manager console, under the Setup menu select Microsoft System Center…
Select the check box Enable Microsoft System Center ConfigMgr Integration.
You will need to enter the the Configuration Manager server that has the Management Point role installed, i.e. Primary Site server and check the Autodetect management server on client. This can be useful if you have a large Configuration Manager implementation and multiple Site Servers etc.
The credentials you supply will need to have sufficient privileges to the Configuration Manager environment – as I’ve pointed out previously.
When you click the Test Now… button for the first time, the version will automatically be enumerated for you and set accordingly.
The next step in the process is to click the Test Now… button again. If successful you should be presented with a list of your defined Packages. As you can see from the screen shot below my list is not particularly exhaustive. This test also gives you the first indication that RES Workspace Management does not work with the new Applications feature as they aren’t listed.
At this stage remember to click the Save Settings from the menu bar to commit your changes.

This concludes the first phase. We’re now in a position to use these Packages to install applications with the RES Workspace Manager integration; either at a global level or behind the configuration of an application – which is where I’d see it as most useful and what I’ve described below.

Phase 2

Within the RES Workspace Manager console edit the managed application where you’re going to add the Configuration Manager integration; in my example I’m going to use WinRAR.
From the Configuration tab add the Microsoft ConfigMgr action (shown below).
You’ll see the Edit software distribution dialogue displayed.
The first thing you probably want to do here is select the Program you’re going to deploy/install when this application is launched. You do this by clicking (…) in the Program field. What’s actually occurring here is: the Management Server that was defined in Phase 1 is being contacted to retrieve a list of Packages and Programs. The result should look something like this; hopefully your list contains more than my paltry set of programs.
Simply select the program you want to deploy and click OK. In my example I’m using WinRAR Archiver.
You’ll need to fill in the rest of the fields as shown below (obviously changing WinRAR to something that matches you application!).
I probably need to explain some of my choices I’ve made here to avoid any confusion.
Finally make sure the Hide application if executable was not found is unchecked in the application Settings tab (shown below). Obviously the user needs to see the shortcut to actually invoke the application deployment and installation.

Now that you have finished with the RES Workspace Manager setup give yourself a good pat on the back and keep your fingers crossed that Configuration Manager continues to play ball! In theory we’re now in a good position to login and launch our application from the shortcut, RES Workspace Manager will determine if the application executable is present and if not it will instruct the Configuration Manager client (CcmExec.exe) to contact the Management Point too deploy and install the application from the Distribution Point. When this magic occurs (as you can see from the screen shot) you’re presented with a very informative message box from RES Workspace Manager, just above the system tray, letting you know that something is happening.

At this point you’re at the mercy of Configuration Manager which can potentially take a while to deploy and install the application. It goes without saying that should this part be successful, the application will launch. You might have noticed from the screenshot above that there weren’t any Configuration Manager notifications and that’s simply because I supressed the notifications. Within the program definition in Configuration Manager (as you can see below) simply check the Suppress program notifications checkbox. In your environment you might want these turned on, I just don’t like too many system tray notifications popping out at the users.

There are a couple of places in RES Workspace Manager that you can look to see when a Configuration Manager task was invoked and the outcome for troubleshooting purposes or just because you’re nosey! The first place too take a look at is the Log tab under the Setup menu select Microsoft System Center…

This gives a good overview of each task invoked. You can also use the Diagnostics > Event Logs to view the outcome per user session as seen here:

Now if for any reason the installation fails you’ll probably need to go and have a chat with the Configuration Manager “guru” (maybe that lucky person is you?) and look at the myriad of Configuration Manager logs to see why it failed.

Some Takeaways (Indian Please :D)

Using RES Workspace Manager with Configuration Manager allows you to bring Context Awareness to your application deployments and install them Just-in-Time;
Have a friendly word with your Configuration Manager “guru” before you begin, so he understands why you’re doing this and how it can benefit them too;
You’ll need the Configuration Manager server details that have the Management Point role installed;
Make sure you have the details or created an account that has correct Security Role defined in Configuration Manager;
RES Workspace Manager 2012 SR2 can’t presently integrate with the new Applications feature in Configuration Manager 2012;
You don’t need to create Deployments/Advertisements or Collections beforehand in Configuration Manager for the integration to work with RES Workspace Manager;

I’ve tried to be as factually correct as possible but I confess that I’m no Configuration Manager “guru.” Please do leave a comment if I’ve got something horribly wrong and I hope you’ve found this blog post useful.

Enjoy!!

Nathan

4th October 2012

RES Workspace Manager – JETCMD Example Use Case

We recently announced the release of our new free Job Execution Tool (JET). If you haven’t had chance to read the announcement yet you can find it here. In this post, I’m going to detail one of the various use cases for JETCMD. This should give you an idea why we developed it in the first place and how powerful it can be.

My use case is going to focus around using JETCMD in conjunction with RES Workspace Manager to invoke a RES Automation Manager job at logoff time. The purposes of this job is to delete the locally cached user’s profile from the machine which the user has just logged off from. With the constant debate raging on whether we should be using mandatory or local (temporary) profiles, we now have a way of deleting local profiles at log off without fudging HKLM settings in the registry (perhaps another blog post?!). Regardless of how or why we should or shouldn’t be doing this, your immediate reaction at this point might be that RES Workspace Manager already integrates with RES Automation Manager! You would be correct, however we have the following restrictions:

The integration only allows job scheduling at user login or when launching a managed application; not at logoff ;
Run Books can’t be invoked – only Projects and Modules;
You cannot dynamically pass job parameters at runtime, i.e. they are embedded into the Automation Task in RES Workspace Manager.

So how can JETCMD help us? As you’ve probably guessed JETCMD will allow us to both invoke the appropriate RES Automation Manager job at log off and pass the required parameter(s) to delete the relevant profile. The following are the outline steps involved to accomplish this task:

Create a Module, Project or Run Book in the RES Automation Manager console that will be invoked by JETCMD (making note of the job GUID);
As JETCMD is part of the free Virtual Engine Toolkit (VET) you’ll need to download from here and install it;
Add the JETCMD.exe as a “Custom Resource” within RES Workspace Manager. Note: JETCMD.EXE can found in the “%ProgramFiles%\Virtual Engine\JETCMD” or “%ProgramFiles(x86)%\Virtual Engine\JETCMD”, depending whether it was installed on a 32 or 64-bit system;
Optionally create “Environment Variables” within RES Workspace Manager, which will hold various command line parameters to pass to JETCMD such as TYPE, JOBGUID, USER and PASSWORD. Using this method makes the task you create in RES Workspace Manager extremely powerful and flexible;
Create the “Execute Command” in RES Workspace Manager that runs JETCMD at logoff. Ultimately this will invoke and schedule the target RES Automation Manager job.

Now lets cover each step in slightly more detail:

STEP 1

I’m not going to cover how you create a Module, Project or Run Book in the RES Automation Manager console in detail. Rather, I am assuming that you have already created one that you would like to be invoked by JETCMD (and have noted down the relevant job GUID!). For the sake of my use case, I’m using a great tool called DelProf2 from Helge Klein (@HelgeKlein) within a RES Automation Manager module. I’ve used the following “Command (Execute)” task.

What you see above might look a little cryptic so I’ll briefly explain:

The $Workspace{E2EBA027-FA6B-42AB-9358-C7656E99822E} reference is just a resource link that points to the DELPROF2.EXE that has been added as a resource within the RES Automation Manager console. When the RES Automation Manager task executes it will download the executable and run it;
The /U switch will be passed to DELPROF2 and signifies that we would like it to run unattended, i.e. with no confirmation;
To only delete a particular user profile, the /id switch is used to include only profile directories whose name matches this pattern;
Used in conjunction with the /id switch, the $[UserName] is the RES Automation Manager parameter used to hold the user’s name of the profile I wish to delete (refer to JET_PARAMNAME in Step 5 for more details).

STEP 2

Nothing really to explain here other than download and install VET on your machine – simples! Smile .

STEP 3

Before we carry on with this step lets quickly describe what a “Custom Resource” is. This is an abstract from the RES Workspace Manager Administration Guide:

To import JETCMD as a custom resource, just follow these steps:

In the RES Workspace Manager console, click on “Administration” in the navigation pane;
Click on the “Custom Resources” node in the same left hand pane;
Right click in the right hand pane, select “New” and browse to the location of the JETCMD.exe;
The JETCMD.exe should now appear as a “Custom Resource” in the RES Workspace Manager console as shown below:

STEP 4

Now while I did say this step was optional, I would highly recommend using “Environment Variables” to hold the parameters that JETCMD will use. This allows more visibility of these values and the potential to change them dynamically depending in the ACL’s used behind the “Environment Variables“. For example, utilising environment variables will allow you change the target RES Automation Manager job based on location or security group without having to create additional tasks!

In the RES Workspace Manager console, click on “Composition” in the navigation pane;
Click on the “Environment Variables” node in the same left hand pane;
Right click in the right hand pane, select “New”;
Give the “Environment Variable” a suitable Name, Administrative Note and Value and change the ACLs etc. accordingly. In my instance I’ll accept the defaults;
I’m going to create 6 “Environment Variables” to make managing my “Execute Command” as simple and flexible as possible, as you can see below;

JET_TYPE = RES Automation Job type to invoke i.e. Module, Project or RunBook;
JET_JOBGUID = The Module, Project or Run Book GUID that can be found in RES Automation Manager console;
JET_RESAMUSER = The RES Automation Manager console user to authenticate as;
JET_RESAMPWD = The password for the user as specified in JET_RESAMUSER;
JET_PARAMNAME = Parameter name(s) that’s specified with the RES Automation Manager job;
JET_PARAMVALUE = Parameter value(s) that’s used in-conjunction with JET_PARAMNAME (Refer to $[UserName] in Step 1).

STEP 5

The last step involves creating an “Execute Command” in the RES Workspace Manager console that will be executed upon logoff time.

In the RES Workspace Manager console, click on “Composition” from the left hand pane;
Click on the “Execute Command” node in the same left hand pane;
Right click in the right hand pane, select “New”;
Adjust the “Execute Command” options so “Run Hidden” and “Run Task At Logoff” are selected as shown below:
The next most import factor here is obviously the command line specified. As I’m using “Environment Variables” my command line looks like this. [code]%RESCUSTOMRESOURCES%\JETCMD.EXE /type:%JET_TYPE% /jobguid:%JET_JOBGUID% /agent:LOCAL /user:%JET_RESAMUSER% /password:%JET_RESAMPWD% /encrypted /paramname:%JET_PARAMNAME% /paramvalue:%JET_PARAMVALUE%[/code]You’ll notice I’m also using the %RESCUSTOMRESOURCES% “Environment variable” – which is used internally by RES Workspace Manager to resolve the location of the “Custom Resources” folder.

And there you have it, a common use case for JETCMD with RES Workspace Manager. I hope by now you can see how flexible and powerful JETCMD can be Smile .

We’d love to hear you comments!!.

Nathan.

24th August 2012

Move Machine Based Context Menus to Per User (Part II)

In Part I of this two part blog post, I described how you go about denying access to the machine based content menus, this blog post will describe how you now can target these same context menus to specific users or groups i.e. moving them to per user based.

Before we go on another further, you’ll need to retrieve those .REG files we modified and saved in Part I – you know the ones where we replaced HKEY_CLASSES_ROOT with HKEY_CURRENT_USER\Software\Classes.

So as you might have guessed to target the context menus are specific users or groups we simply need to inject this .REG file or its values for those users or groups. This can be achieved by various means or methods such as:

Login Scripts (BAT, VBS, PowerShell);
Group Policy custom ADM or ADMX’s;
Group Policy Preferences;
User Environment Manager (RES Workspace Manager or AppSense Environment Manager to name a couple).

I’m not going to detail how you would go about doing this for options 1 – 3 as there are numerous articles on the internet to aid with that process. What I will say is that you get a lot more flexibility using option 4 with regards to who, what and when these context menus are applied for users or groups. In most of my environments we tend to use RES Workspace Manager, so I’m going to cover what needs to be done to target the context menus at users and groups.

As a simple overview this is how I configured RES Workspace Manager to achieve this:

Create a Location and Device (PowerZone), that determines if the application is installed that these context menus are associated with;
Create a Global User Registry setting that adds the required registry keys and values by importing modified .REG, and changing the ACL to target the specific users or groups and the PowerZone created in step 1;
Create a Global User Registry settings that removes the registry keys and values set in step 2, the ACL can be set to “All Users” but more importantly the order of execution for this setting must be HIGHER than that of step 2.

Step 1

To create this PowerZone use the “File or folder exists” rule for RES Workspace Manager 2012 or “File version” rule for RES Workspace Manager 2011 and below, that will check for the installation folder or file in the directory. My example here is using RES Workspace Manager 2012 to determine if WinRAR is installed.

Step 2

This registry setting will only get applied when both the user is part of the ACL and where the application is installed on the computer they are using; why apply these settings if the application isn’t installed!. These settings are applied at a Global level to ensure they are there, should the application be required to be started from the context menu and not just when the managed application is started.

Step 3

This step is import because should the user have access revoked to the application we need to make sure that context menu is removed from the users local cached profile. Make sure the order of execution for this setting is HIGHER than that of step 2, otherwise it will remove these settings after step 2 has applied, therefore removing the context menu for users or groups that have been granted access.

That’s all there is too it – any questions just post a comment.

Enjoy!

Nathan

5th March 2012

RES Workspace Manager VDX Options Explained

When delivering RES Workspace Manager training there can be some confusion over some of the settings available when integrating it with RES Virtual Desktop Extender (VDX). The purpose of this post is to attempt to clarify what option does what!

This is the global option that will enable or disable the RES Workspace Manager and VDX integration, i.e. the ability to run applications as a “Workspace Extension”. Note: If this option is disabled and the RES VDX Engine is installed, there is potentially nothing from stopping this running, just you won’t get the RES WM integration, i.e. licensing etc.
If this option is enabled then the VDX Engine process will be started. By disabling this option you will effectively be turning on the legacy RES Subscriber/Workspace Extender functionality only.
If you have the VDX Engine installed, then this option will enforce the VDX settings to take preference over the RES Subscriber/Workspace Extender, e.g. options 7 – 13 and the Z-ordering improvements. Don’t disable this option if deploying RES VDX!
Depending on the setting chosen the following taskbar behaviour will occur:
1. Autodetect: The behaviour as defined in the Display Settings section will be honoured, i.e. the configuration of the remote session display.
2. Yes: The taskbar of the local session will always be hidden regardless of the remote session display configuration.
3. No: The taskbar of the local session will never be hidden. Note: with the RES Subscriber/VDX Shell, the taskbar is hidden by default.
Depending on the setting chosen, the following client application pass-through behaviour will occur:
1. Autodetect: If running client application window will be obscured by the remote session, it will automatically be displayed in the remote session.
2. Yes: All running client applications will be automatically displayed in the remote session.
3. No: No existing client applications/processes will be displayed in the remote session when it’s first started. Note: this does not prevent reverse seamless applications from being launched from the remote session!
If selected, when a user logs off a remote session, all locally running client applications will be closed (or attempted to be closed!) before the remote session is ended.
Enable this option if you which users to be able to access the system tray icon and enumerate the applications present in the user’s local client Start Menu.
Enable this option if you which users to be able to access the system tray icon and enumerate the applications present in the user’s local client Desktop.
Enable this option if you which users to be able to access the system tray icon and enumerate the applications present in the local client System Tray.
Client applications can be excluded from the VDX seamless window integration by entering the process name, i.e. pnagent.exe.
1. Multiple processes should be separated with semicolons.
2. Processes can still be launched, but will not be displayed in the taskbar the remote session and Z-ordering will not be implemented.
If you wish client applications to be unavailable via the System Tray integration, enter the process(es) here.
1. Multiple processes should be separated with semicolons.
2. If a client process is excluded, it will not be displayed in System Tray Start Menu or Desktop folders.
Allows you to override the default VDX pop-up balloon title (a).
Allows you to override the default VDX pop-up balloon text (b).
1. This text is also displayed at the top of the VDX system tray Client Start Menu/Desktop window (c).

Display Settings

The following information has been taken from the RES VDX User Guide and is used when configuring the Local Client Taskbar integration in option #4 above:

VDX supports several display scenarios. Each scenario may require specific settings. For an overview of these settings, see Setting up the Behavior of the RES VDX Engine (on page 10). Some examples of supported scenarios are:

A single display

In this scenario, both the local desktop and the remote desktop are run on the same display. The remote desktop is the visible desktop, showing both remote applications and local applications. The local taskbar is obscured if the remote session is maximized. With the remote session at a smaller size, the client taskbar is shown twice, once in its original position on the client and once integrated in the remote session.

A dual display setup with the remote desktop spanning both displays

In this scenario, both the local desktop and the remote desktop span both displays. The remote desktop is the visible desktop, showing both remote applications and local applications. The local taskbar is obscured if the remote session is maximized on the first monitor or if both sessions are maximized.

A dual display setup with the local desktop running on the primary display and the remote desktop running on the secondary display

Both taskbars are displayed.

A dual display setup with one remote desktop running on the primary display and another remote desktop running on the secondary display

Both remote desktop taskbars are displayed. Client windows can be moved from desktop to desktop.

I hope this helps clarify things for someone! Iain

20th February 2012

RES Workspace Manager Migration Settings

Following on from the Application Upgrades in RES Workspace Manager post, I thought I would put pen to paper to put to bed the confusion surrounding the whole “Migration settings” for RES Workspace Manager 2011 User Preferences/Settings. In fact, RES Workspace Manager allows for two separate types of User Settings migration; the migration of user settings stored in a previous location and migration of User Settings when switching between Zero-Profiling modes (from RES Workspace Manager 2011 SR2 onwards). There is often the miscomprehension that the migration options will automagically migrate user settings between defined applications, i.e. Word 2003 to Word 2007. This is categorically not the case (and will be a future post!). So what are the differences between the two options?

User Settings Storage Migration

This option available under the Composition > User Settings within the RES Workspace Manager console allows you to migrate stored User Settings from a previous location and looks just a little bit like this:

When would we enable this option? You will use this option when you want to move or copy settings stored in a prior location to an alternative location. Historically, RES PowerFuse always required that you stored the user’s User Settings in their home drive location. Although hidden, this could quite often cause confusion and had serious consequences if hard quotas were in place.

Starting with RES Workspace Manager 2011, this is no longer the case. User Settings still have to reside within an assigned drive letter location, but this no longer has to be the same location as the user’s home directory. This very option enables you to migrate existing user settings from a previous location to another drive. Nothing more, nothing less (and no migration of settings defined behind a Word 2003 application to Word 2007!). Here’s an example:

User home directories are mapped to H: and you previously stored the User Settings in the \PWRMENU subfolder (may or may not be mapped via Active Directory).
You wish to store User Settings in the X:\UserSettings folder that will be hidden by RES Workspace Manager (how and where you map X: are up to you!).
Configuring the migration settings as above will move all the User Settings from H:\PWRMENU to X:\UserSettings, but only if they exist.
All new captured User Settings will be put into X:\UserSettings.

Zero-Profile Migration

The second User Settings migration option allows you to migrate existing User Settings captured with one Zero-Profile mode to the other, i.e. migrate UPR/UPF files to/from UPR2/UPF2 files. You may or may not know this, but the way in which RES Workspace Manager stores User Settings depends on the configured Zero-Profile mode. If an application is configured to “Capture” then the settings are stored in the traditional format, e.g. .UPR and .UPF files. If you happen to configure an application in “Tracking” mode then you’ll end up with .UPR2 and .UPF2 files. I am informed that this is due to the fact that tracked settings are appended to the resulting file (and compressed) as they’re changed etc.

By default, if you switch from one Zero-Profile mode to another, RES Workspace Manager will suddenly be looking for User Settings files that don’t exist. Worse still, if you happened to have had the other mode configured for a while, changed it and then reverted, you may place some old Users Settings back into the user’s profile!

The migration setting on the User Settings tab behind an application is designed to help avoid this situation and migrate the captured User Settings to/from UPR/UPR2 (and UPF/UPF2) files.

The settings above have the following definitions:

Ignore – RES Workspace Manager will ignore the other file type (if present) and start capturing in the configured mode.
Remove – RES Workspace Manager will delete the User Settings stored (if present) in the alternative format.
Apply and Remove – RES Workspace Manager will migrate the stored User Settings (if present) and then delete the alternative format.

All this is fairly straight forward once you know the in’s and out’s (and still no migration of settings defined behind a Word 2003 application to Word 2007 regardless of the configured Zero-Profile mode!). You can manually move User Settings from one application to another and this might be a future post or even make it into the Virtual Engine Toolkit.

As always, I hope this helps clarify things for somebody, some day! Iain

13th February 2012

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

1st February 2012

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.

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.
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.
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.
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.
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!

Thanks,

Simon

17th January 2012

Updating Mandatory Profiles Part 2

Having seen that our original Updating Mandatory Profiles post is quite popular, I thought I’d follow it up with an update. The process described in the first post is quite labourious and error prone. I’d like to make people aware of how quick and easy the Profile Update Utility (PuU) makes updating a mandatory profile with ActiveSetup keys.

Here’s the new process:

Obviously you’ll need to have downloaded (it’s free) and installed VET.
Once installed, simply launch the Profile Update Utility.
Select your mandatory profile by clicking the “Browse” button (step 1).
Check the “Merge HKEY_CURRENT_USER ActiveSetup keys” checkbox (step 2).
Click the “Go” button (step 3).

It doesn’t get much simpler than that! Note: This will merge the ActiveSetup keys from the currently logged on user. Therefore, you need to perform this action on a machine that you’ll be using the mandatory profile on.

The “Output Options” at the bottom of the PuU windows could probably do with some explaination as there is sometimes some confustion.

Update Original Profile: Overwrites the source (Step 1) profile.
Backup Profile: Copies the source profile (in Step 1) to a .bak file and then updates the original.
Create New Profile: Copies the source profile (in Step 1), renames the original (in Step 1) to a .bak file and then updates the new copy.

Which option you use is up to you depending on how you manage the lifecycle of your mandatory profiles.

Enjoy – Iain

11th January 2012

The case of the missing Office 2007 Quick Access Toolbars

Recently I’ve been involved with one of our customers who is migrating from RES PowerFuse 2008 and roaming profiles on XenApp to RES Workspace Manager 2011 (WM) utilising Zero Profile Technology (ZPT) and a mandatory profile.

One of the issues they had on the new environment was the Office 2007 Quick Access Toolbars (QAT) weren’t being captured by WM using the built-in templates provided which capture the locations set out below:

Windows XP and Windows Server 2003 (v1 profiles):
%USERPROFILE%\Local Settings\Application Data\Microsoft\Office

Vista, Windows 7 and Windows Server 2008 (v2 profiles):
%USERPROFILE%\Appdata\Local\Microsoft\Office

So everything appeared to be configured correctly; but still the QAT files weren’t being captured or worse still weren’t being saved in those locations.

Upon further investigation the QAT files where actually being saved in ‘%APPDATA%\Microsoft\Office’ which seemed very odd to me as I was sure one of the problems that people found when using roaming profiles with Office 2007 was the QAT didn’t roam!. This led me into thinking that maybe Microsoft had at some point released a hotfix that did in fact allow the QAT files to roam. So lets turn to the interweb and see what that brings up, and low and behold, Microsoft did just that and released a hotfix http://support.microsoft.com/kb/958062 (included in Office 2007 SP2). Setting the registry key as described in the Microsoft article forces the QAT files to be saved in the users profile which would then allow them to roam.

Once I had this vital information I quickly found that this particular customer had uncovered this fix and had implemented it using RES PowerFuse 2008 (clever boys/gals!!). Because we had copied and upgraded the RES PowerFuse 2008 datastore to WM 2011, this user registry setting was being applied to the new environment. To resolve the problem we simply removed that registry setting and let the power of the templates supplied with RES WM 2011 do their thing and capture the QAT files in the default location.

NOTE: One thing I will add about the supplied templates is they don’t capture the QAT files for Outlook 2007 i.e. Olkaddritem.qat, Olkapptitem.qat, Olkdistitem.qat, Olklogitem.qat, Olkmailitem.qat, Olkpostitem.qat and Olktaskitem.qat.

To resolve this issue you can add file filter ‘%LOCALAPPDATA%\Microsoft\Office\Olk*.qat’ to the capture settings for Outlook 2007. Hopefully this will get rolled into the default Office 2007 application templates by RES in a future release.

Hope this helps.

Nathan