PVS Image Management

There has been a bit of banter on the Twittersphere about how people manage and document their PVS images. It was suggested (by more than just me Smile) that RES Automation Manager could be utilised for this task. This post is not a best practice guide as to how to create, update or document your images, rather a use case on how and why we use/recommend RES Automation Manager. Heaven forbid, you might even decide to do away with Provisioning Services as a result. Either way RES Automation Manager will play very nicely with or without PVS but I couldn’t fit it into 140 characters!

Provisioning Services Private Image Management

Maintaining the gold or private mode PVS image can be a complex task for a number of reasons. Simplifying any of these potential hurdles can only be a good thing, right?

  1. A certain level of skill is required to both create and maintain images. There are numerous tasks that need to be completed and in some cases, performed in a particular order. As a result, this task is typically left or assigned to the senior administrators.
  2. Application upgrades can taint or stain the master image. Some applications require an uninstallation of the old version and installation of the new product MSI. I don’t need to tell you that uninstallers are not always reliable or clean everything out when run!
  3. How are changes to the gold image documented to ensure that they’re incorporated into all other PVS images? It is typical that there will be more than one image for deployment. For example, hardware differences will typically require separate images.
  4. Ad-hoc and emergency changes can wreak havoc with your PVS images. How quick and easy is it to push an update out to 100 XenApp servers streamed from a central image? If we make changes whilst the servers are running then they’ll be lost when the write cache is erased meaning we either have to reapply this change after every reboot or update our gold image pronto! This will get a lot more interesting if the servers are rebooted on a nightly basis and the write cache cleaned!

RES Automation Manager

If know me by now, you probably know that I’m going to say that RES Automation Manager is the answer to all your prayers! Now whilst it can certainly address the above “issues” (and I would recommend it in conjunction with Provisioning Services any day of the week) there are other processes and solutions that may address one or more of the above and deploying RES Automation Manager won’t automagically fix them. A good example of this is documentation. If your internal processes mandate that all changes are documented and you bypass this process, there is nothing to stop you bypassing this process even if Automation Manager is installed!

What RES Automation Manager Won’t Do

Thought I’d better get this bit out of the way before you get all the way to the end and are disappointed! RES Automation Manager is a Run Book Automation tool and not an imaging/deployment tool. This means that we cannot (directly) deploy an Operating System from RES Automation Manager. Fortunately for us there are many technologies out there that can, e.g. Windows Deployment Services/Microsoft Deployment Toolkit which BTW can by combined with RES Automation Manager – take a look at this White Paper. Why reinvent the wheel?!

What RES Automation Manager Will Do

So once we have our Operating System deployed and the RES Automation Manager agent installed (we can do this with WDS/MDT as mentioned earlier) what benefits will this give us? Well, at a simplistic level, RES Automation Manager can automate the entire server configuration and application deployment process. This process can also include installing XenApp and XenApp Prep as well as any other applications. This obviously takes some additional time but gives us a clean, repeatable process for deploying a XenApp server from scratch. It’s a strategic decision and not a tactical one!

Why is this important? Typically it comes down to issues #2 and #3 so let’s take them one at a time..

Issue #1

RES Automation Manager can reduce this complexity by removing Provisioning Services altogether. I’m not suggesting that you remove this from your infrastructure. Not even for one minute. However, if you don’t need to have a clean image after every reboot getting shot of PVS maybe an option? We have automated the complete server deployment and can typically provision a new server in a few hours from start to finish; Operating System, XenApp and applications. OK it’s a few hours of time, but there is no user interaction required. I’m guessing that it’s probably not that often that you need to add a new server within 30 minutes?

This benefits the typical IT department as these are now regular servers. They’re supported in the same way as other servers and they have a proper OS install etc. There are downsides too. Now we need to patch and maintain multiple OS instances and not just one master image. Isn’t this part of the reason you deployed Provisioning Services in the first place?

Issue #2

By having a repeatable process for building our XenApp server(s) from scratch we can avoid tainting our image. If we need to cut a new image then we can deploy a completely clean server and deploy the required applications as required. We don’t need to uninstall and reinstall or upgrade applications. I’m not advocating this as a best practice, but I know lots of admins that are a lot happier with this process. It doesn’t need to be performed for all updates, but you now have an option as to whether you update the master image or cut a new one. If you have not automated the entire deployment and configuration process, recreating a new image from scratch probably doesn’t make you feel warm and fluffy inside!

When you finally get run over by a bus (it’s going to happen one day as everyone keeps saying it) pretty much anyone with ounce of intelligence can deploy a new server or reverse engineer the Modules and Tasks in the Run Book to discover how things are tied together.

Issue #3

By virtue of automating the entire configuration and deployment process with RES Automation Manager, you have actually documented every step in the process. RES Automation Manager includes the ability to create an Instant Report of any or all Run Books, Projects and/or Modules. These reports are very detailed (small example here) and typically run to 1,000+ pages. For us consultants, this feature alone is worth its weight in gold. Did I mention that it’s available in RES Workspace Manager too? Winking smile

Issue #4

Finding out when and by whom the changes were made. Whether they be changes made to the gold image or Ad-Hoc emergency it doesn’t matter the audit trail of the changes is vitally important especially with change management processes. Well would be surprised to hear that RES Automation Manager has an in-built Audit Trail which allows you to view all actions performed in RES Automation Manager – how handy is that when a witch hunt is on (Oh that never happens now does it!?).

Issue #5

As usual I’ve saved the best until last and you didn’t see number 5 coming! The “pièce de résistance” if you like. This might get a bit confusing so strap yourselves in ready…

Emergency changes to running PVS instances are pain. Depending on your configuration after a reboot changes may be lost and depending on your requirements, you may reboot nightly or even weekly. If there is a configuration change that needs to be made then ultimately we need to update the master image. We can implement the change on the running instances, but it will be lost at some point when the write cache is cleared. Until the master image is updated we will need to implement the change, potentially after every reboot.

Because RES Automation Manager is a Run Book Automation tool we can implement this change across all running instances within minutes. “WAIT!”, I hear you cry, “These changes will be lost after a reboot!” Correct. But now we have achieved two things; documented the change and can automate the update to the master image at some point in the future.

Why did I say at “some point in the future?” Fortunately for us there is a hidden gem within RES Automation Manager called Snapshot Intelligence. With a name like that it better be good right!?

As the RES Automation Manager database has a record of all jobs that have executed on a given agent it can detect a snapshot. Whether this is a virtual snapshot or a backup restoration, it makes no odds. In our PVS world, if RES Automation Manager jobs have been run on a machine and the PVS instance is reset back to our master image state (write cache cleared), RES Automation Manager will detect this as a snapshot. You with me so far..?!

Once a snapshot is detected, RES Automation Manager can automatically reapply the job history (I’ll pause whilst you take this in and wait for the penny to drop!).

So if we automate all the emergency or ad-hoc updates with Automation Manager we can automatically reapply these after every reboot? Yes. No need to update the master image for every change? Yes.

In fact it gets better than that. When we update our master image we can run the exact same job history (automatically if you wish) to update the gold image. If you want to cut a new image from scratch we’ve got that covered too. Above all, if everything is automated with RES Automation Manager it’s automatically documented too. Needless to say, you get all the usual audit logging and change history.

Summary

So, in summary, using RES Automation Manager in combination with Citrix Provisioning Services has huge benefits, but there’s obviously a cost associated. Would I recommend it? Absolutely! For all of the above reasons. Is it worth it? Unfortunately, I can’t tell you that as only you know your environment.

Can RES Automation Manager replace Provisioning Services? Not entirely as you’ll still need WDS/MDT (or equivalent) to deploy the OS. It also depends on your reasons for deploying PVS in the first place. If it’s for near instant deployment, remove local disks, reduce the storage footprint or a clean image on every reboot, you’ll probably be using it for a long while yet. If your reasons are purely for “single image” management then you could potentially replace PVS in favour of a “traditional” deployment. Would I recommend this? It depends!

I know we’ve been focused on Provisioning Services in this article but RES Automation Manager will help you with the rest of your infrastructure automation. Desktops, laptops, servers; Exchange and Active Directory etc. You may have XenDesktop, Quest vWorkspace or VMware View for your virtual desktops. The same principal applies and you may even be using PVS in combination with these. Anyway, I don’t need to preach to the converted!

I will say that it should be a strategic decision to deploy RES Automation Manager. Don’t underestimate the amount of time it takes to automate and test. But I guess you already spend a lot of time testing your images?

You can find some video overviews/introductions on RES Automation Manager on Citrix TV and RES Tutorials. If you don’t want to take the time to download, install and configure RES Automation Manager but want to take a quick look, you can always request access to the RES Showcase. Some background and example videos on the Showcase platform can be also found here.

I’ll get off my soapbox now and crawl back to whence I came! Please feel free to comment and I’d love to hear your thoughts. Iain

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!

image

  1. 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.
  2. 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.
  3. 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!
  4. 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.
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Allows you to override the default VDX pop-up balloon title (a).
  13. 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).

image

SNAGHTML6c0f49e

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

RES Automation Manager 2012 Global Variables

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

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

Resources and Global Variables

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

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

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

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

image

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

Resources, Global and Environment Variables

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

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

image

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

image

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

image

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

image

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

Resources, Global Variables and Credentials

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

image

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

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

Many thanks for reading. Iain

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:

image

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:

SNAGHTML5e06dce

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:

image

 

image

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:

SNAGHTML6001c74

image

 

image

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:

image

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

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

Thanks, Iain

Internet Explorer Personalisation with RES Workspace Manager

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

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

Enjoy ! Additional comments and recommendations are more then welcome!

Thanks,

Simon

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:

  1. Obviously you’ll need to have downloaded (it’s free) and installed VET.
  2. Once installed, simply launch the Profile Update Utility.
  3. Select your mandatory profile by clicking the “Browse” button (step 1).
  4. Check the “Merge HKEY_CURRENT_USER ActiveSetup keys” checkbox (step 2).
  5. 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.

  1. Update Original Profile: Overwrites the source (Step 1) profile.
  2. Backup Profile: Copies the source profile (in Step 1) to a .bak file and then updates the original.
  3. 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

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

Active Setup – Stubpath Command Lines

I spend a lot time working with mandatory profiles and RES Workspace Manager, especially when using Citrix XenApp or Remote Desktop Services. One of the key elements to creating a slick mandatory profile is to ensure the Active Setup keys are added to the mandatory profile or you will forever see the annoying “Personaliz(s)ing Settings” message. We have covered how to do this in a previous post here by using our great free tool the Virtual Engine Profile Update Utility (PuU).

image

While you can merge these Active Setup Keys to stop the message box appearing; this isn’t actually where the story ends. Behind some Active Setup Components there is a command line (Stubpath) that needs to run once per user i.e. for new users logging on for the first time (for a great explanation of Active Setup, check out Helge Klein’s write up here). The drawback of just merging these keys will be that the command line (Stubpath) will not run for any user. This could have undesirable results as mentioned in the RES Blog post here and Andrew Morgan’s Blog post here.

So the purpose of this blog is really for informational purposes above anything else and to detail the most common Active Setup components containing Stubpaths, by OS. Should you need this information, it’s here for reference. For example, if you disable the ActiveSetup option within RES Workspace Manager or merge the ActiveSetup keys using the Profile Update Utility (PuU), you may have to reinstate a particular action if it causes issues (like Andy’s issue). The command line (Stubpath) is highlighted in yellow and can be used to remedy the situation if necessary:

UPDATE : Windows 8 Consumer Preview (Subject to Change) – Yes ActiveSetup is still here!

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA840-CC51-11CF-AAFA-00AA00B6015C}
Microsoft Windows (MailNews)
"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /FirstLogon

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U %SystemRoot%\System32\shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Web Platform Customizations
C:\Windows\System32\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\System32\Rundll32.exe C:\Windows\System32\mscories.dll,Install

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

>{ABB824FE-FBBE-464D-9AAA-FAFED848BF41}
IE History
C:\Windows\System32\ie4uinit.exe -UpgradeOldHistoryEntries

Windows XP

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA842-CC51-11CF-AAFA-00AA00B6015B}
NetMeeting 3.01
rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\msnetmtg.inf,NetMtg.Install.PerUser.NT

{5945c046-1e7d-11d1-bc44-00c04fd912be}
Windows Messenger 4.7
rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\msmsgs.inf,BLC.QuietInstall.PerUser

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
rundll32.exe advpack.dll,LaunchINFSection C:\WINDOWS\INF\wmp11.inf,PerUserStub

{7790769C-0471-11d2-AF11-00C04FA35D02}
Address Book 6
"%ProgramFiles%\Outlook Express\setup50.exe" /APP:WAB /CALLER:WINNT /user /install

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install

<{12d0ed0d-0ee0-4f90-8827-78cefb8f4988}
Internet Explorer Version Update
C:\WINDOWS\system32\ieudinit.exe

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
C:\WINDOWS\inf\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\WINDOWS\system32\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}MICROS
Browser Customizations
RunDLL32 IEDKCS32.DLL,BrandIE4 SIGNUP

>{881dd1c5-3dcf-431b-b061-f3f88e8be88a}
Outlook Express
%systemroot%\system32\shmgrate.exe OCInstallUserConfigOE

Windows 7 32bit

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA840-CC51-11CF-AAFA-00AA00B6015C}
Microsoft Windows (MailNews)
"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /FirstLogon /Shortcuts /RegBrowsers /ResetMUI

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Web Platform Customizations
C:\Windows\System32\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP

Windows 2008 R2 SP1 with Desktop Experience Installed

{2C7339CF-2B09-4501-B3F3-F3508C9228ED}
Themes Setup
%SystemRoot%\system32\regsvr32.exe /s /n /i:/UserInstall %SystemRoot%\system32\themeui.dll

{44BBA840-CC51-11CF-AAFA-00AA00B6015C}
Microsoft Windows (MailNews)
"%ProgramFiles%\Windows Mail\WinMail.exe" OCInstallUserConfigOE
"%ProgramFiles(x86)%\Windows Mail\WinMail.exe" OCInstallUserConfigOE

{6BF52A52-394A-11d3-B153-00C04F79FAA6}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /FirstLogon /Shortcuts /RegBrowsers /ResetMUI

{89820200-ECBD-11cf-8B85-00AA005B4340}
Windows Desktop Update
regsvr32.exe /s /n /i:U shell32.dll

{89820200-ECBD-11cf-8B85-00AA005B4383}
Web Platform Customizations
C:\Windows\System32\ie4uinit.exe -BaseSettings
C:\Windows\SysWOW64\ie4uinit.exe -BaseSettings

{89B4C1CD-B018-4511-B0A1-5476DBF70820}
DOTNETFRAMEWORKS
C:\Windows\system32\Rundll32.exe C:\Windows\system32\mscories.dll,Install
C:\Windows\SysWOW64\Rundll32.exe C:\Windows\SysWOW64\mscories.dll,Install

{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}
Applying Enhanced Security Configuration (Admin)
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iesetup.dll",IEHardenAdmin
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll",IEHardenAdmin

{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}
Applying Enhanced Security Configuration (User)
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iesetup.dll",IEHardenUser
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iesetup.dll",IEHardenUser

>{22d6f312-b0f6-11d0-94ab-0080c74c7e95}
Microsoft Windows Media Player
%SystemRoot%\system32\unregmp2.exe /ShowWMP

>{26923b43-4d38-484f-9b9e-de460746276c}
Internet Explorer
C:\Windows\System32\ie4uinit.exe -UserIconConfig
C:\Windows\SysWOW64\ie4uinit.exe -UserIconConfig

>{60B49E34-C7CC-11D0-8953-00A0C90347FF}
Browser Customizations
"C:\Windows\System32\rundll32.exe" "C:\Windows\System32\iedkcs32.dll",BrandIEActiveSetup SIGNUP
"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\iedkcs32.dll",BrandIEActiveSetup SIGNUP

Should anyone wish to expand on what each Active Setup Component does please feel free to leave a comment I’ll update the blog accordingly; some are more obvious than others Winking smile.

Enjoy

Nathan

RES AM Passing Values Between Scripts

You don’t need to be told how great RES Automation Manager, but there are some things that we can only achieve via scripts; be it VBscript or PowerShell. In my example, it is scripting XenDesktop and XenServer for the demo showcase platform (more on this at a later date). There is currently no way to automate these products without using scripts. Unfortunately (for me) it’s always been problematic to pass values in and out of scripts to other modules. We can certainly pass a value into a script, but then we can’t return it to be used elsewhere.

My problem required creating an AD user (not via the built in task) in one script and then passing the username/password into another script. To overcome this particular issue, I started down the route of temporarily writing the information to the registry so that it could be read by the other script later in the Project. This is where I stumbled across a little gem hidden in RES Automation Manager. I don’t know whether it’s intentional and/or undocumented, but it certainly works!

I attempted to use a Parameter using the built-in @[REGISTRY] Function. In essence this instructs the RES Automation Manager agent to populate the Parameter with the contents of the registry key. This bit is simple to understand and you probably already knew this. However, what I didn’t realise is that this Parameter is updated/re-evaluated at every task within a Module. I assumed that it would only be evaluated when the Module is invoked by the RES AM agent. I’m certainly glad that this is not the case as we can now write values to the registry and AM will automatically pass the updated value to the next Task(s).

Here is an example building block that contains a single module with a single registry-based, emtpy Parameter value. The first script writes the current date to temporary location in the registry (just so happens to be where RES Automation Manager is reading the Parameter value from). The second script receives its Parameter value from RES AM (not directly from the registry within the script), adds a day (in US format!) and writes it back to the registry. The final task displays a pop-up message with tomorrows date from the RES AM Parameter.

What this does prove is that the Parameter is re-evaluated before each task is executed and therefore passed through all tasks. Never in this example module do we enter the date. Here is the status of the parameter before and after each task.

Task 1 – BEFORE: <Empty>, AFTER: <Empty> (We write today’s date to the registry, but it’s not re-evaluated until the next task)
Task 2 – BEFORE: <Current Date>, AFTER: <Current Date> (We write tomorrow’s date to the registry, but it’s not re-evaluated until the next task)
Task 3 – BEFORE: <Tomorrow’s Date>, AFTER: <Tomorrow’s Date>

I’m sure you can think of more ingenious ways of using this functionality. Enjoy! Iain