Wednesday, 4 September 2013

Personalizing Desktop aka Shell Settings

Talking about Desktop Settings within AppSense DesktopNow always leads to a long drawn out debate on what to do with these.

There are several options for these and each option has pro's and con's. This post will describe what desktop settings are, the options available as well as the pro's and con's of each and I'll finish with a conclusion on what I think is the best option is.

Desktop Settings are typically Windows Shell settings most of which directly impact the look and feel of the users desktop. Most often customers are more worried about applications and getting application Personalization right assuming the desktop will sort itself out but then will be haunted by that decision because the very first thing a user notices before they've even launched Microsoft Outlook, Lotus Notes or Internet Explorer is that their wallpaper of their family pet or the children is missing and that their Windows taskbar has reset itself to the default icons. For this reason is it really important to spend some time and effort thinking about desktop settings before you start worrying about applications. 

As I described in the introduction there are several options for managing Desktop Settings, including but not limited to:
  • Using the Desktop Settings menu within Personalization Server
  • Using Registry Hiving and Folder Copy actions within Environment Manager Policy
  • Using a standalone tool - EMP_P2V
  • A hybrid approach
Desktop Settings menu within Personalization Server

The Desktop Settings menu within Personalization Server has been around since the initial release of Personalization Server back in 2008. When the product was released this was simply a list of registry keys that could be added to a list which was imported into the workstation first and then the shell was refreshed allowing the changes to all be reflected within the users session. 

Over the years Desktop Settings has grown from this simple list through a simple checkbox approach and has now arrived at a slightly more granular menu driven list where administrators can define different roaming plans for each setting. 

There are three roaming plans that can be set for each setting, namely:
  • Shared - settings with this roaming plan are shared across all platforms
  • Separate - settings with this roaming plan are separated by operating system family. This effectively means that Windows XP and Windows Server 2003 share desktop settings and Windows 7 and Windows Server 2008 R2 share desktop settings. 
  • Off - settings with this roaming plan are not managed.
And there-in lies the biggest con with this approach. Windows 7 and Windows Server 2008R2 are effectively treated as the same operating system. Whilst this may not be a bad thing for some settings like the keyboard layout or the mouse settings it is disastrous for others like the visual style settings, desktop wallpaper, etc. Worse still when a customer is deploying Windows 7 32 Bit desktops alongside Windows Server 2008R2 Remote Desktop Services infrastructure and attempting to manage things like the taskbar or start menu where users are able to pin applications that don't exist in the same path on the two platforms. 

Using the Desktop Settings menu does work well when you are looking to manage only a single desktop platform, for example if you had purchased Environment Manager purely to manage your Virtual Desktop Infrastructure that is all running the same operating system with the same base applications installed on each image. However its 2013 and users are accessing more platforms now than they ever have and expecting to be able to roam more seamlessly because technologies like iCloud have enabled them to do this between their tablet and their mobile phones. 

Another problem with Desktop Settings is that this is treated as an individual application within Personalization Server. When you roll back Desktop Settings you roll back all of the users settings within that application. There is no simple way to roll back start menu settings leaving the taskbar settings in tact. 

Lastly, it is single threaded so if I was to compare the speed to desktop settings vs registry hiving for the same number of actions I'm confident that registry hiving will win every time. 

On a positive note... it is a personalised application so can leverage the offline mode capabilities introduced with Personalization Server. 

That brings us on to the next approach...

Registry Hiving and Folder Copy Actions

As I discussed in a previous post of mine, registry hiving has been around since the release of Environment Manager 7, which if memory serves me correctly, was released sometime in 2006. The technique is proven and has been used in companies ranging in size from a couple hundred users up to large multi-national organisations spanning over one hundred thousand users. 

Admittedly configuring Desktop Settings using registry hiving and folder copy actions is significantly more time consuming because you need to identify the registry keys and folders you require, then create actions to copy these out and then the reverse to copy them back in. In order to simplify this I've leveraged a template created by a colleague of mine, Landon Winburn, and modified this to make it work in my own hybrid environment. You can download a copy of this configuration here:

When looking at my configuration pay particular attention to the following nodes:


Here I give you two options for managing Desktop Settings using hiving. 

The first shares the settings by operating system platform in much the same way to how Desktop Settings within Personalization Server handles Desktop Settings. 

The second separates each operating system platform into individual folders based on the operating system and cpu architecture of that platform.


Similar to the logon trigger, I give you two options for managing Desktop Settings using hiving and folder copies. 

Another problem with this approach is that you are effectively managing the users profile in two places... you have the Desktop Settings (Windows Shell) that is managed using files and folders on a share accessible to the user as well as the Applications that are managed using Personalization Server and are stored in a Microsoft SQL database somewhere in the datacenter. I will describe an approach that I call the Hybrid approach further on in this document that will leverage the technique discussed in this section with the technique described in the next section to create what I would consider the best approach. As I said, the data is stored on a file share so you are likely to experience issues if the end users machine is offline (particularly in the case of laptops) so you will most likely want to adopt an approach where you sync the data from the network to a local cache and back up when the device is online. Microsoft Offline Files could be used to keep the hiving share available offline but managing and maintaining this had caught many a top class admin out over the years. If you choose to adopt this approach you will want to read Helge Klein's Offline Files Survival Guide for more information on Microsoft Offline Files:

Yet another problem you have with this approach is that because the data is not stored within a database performing rollbacks relies on underlying storage technology like volume shadow copy (or previous versions) on the file share in order to roll back settings. That said, you can roll back some settings without impacting other because each hive out action creates a separate file each of which can be modified or deleted individually without impacting others. Another option is that you could configure the logoff process to take a copy of the folder at each logoff saving 3 or 5 versions of the folder. 

From a sheer performance perspective there is no better solution, registry hiving will beat any other approach I describe in the article almost every single time. In addition, its fully supported by AppSense and will be for the foreseeable future and you cannot suffer from database bloat because you're not using the database at all. 

Using a Standalone Tool

To address the above-mentioned limitations Oliver Oehlenberg (Another AppSense colleague and author on created a tool to assist. This standalone tool works just like any other standard application that you would personalize with one notable exception. Any registry keys and folders that you want the tool to capture must be added to the applications registry and folder exclusions list and not the inclusions list as you would with a regular application. 

In the example below Windows 7 Libraries have been configured to be managed using EMP_P2V:

In order to use the tool you need to perform the following:

Once you have downloaded this you need to distribute this to every endpoint within your organisation. It ships as a standard executable so any software distribution toolset could be used to distribute this alternatively... use an Environment Manager Policy Configuration to copy the executable to the endpoint. 

Next, make copies of the executable based on your requirements... if all desktop settings for a given platform are to be managed as a single entity you create a single executable. If you plan on breaking settings up similar to how they are within the Personalization Server desktop settings menu you will need 15 or more copies of the executable.

Now you need to configure each application within the Personalization Server so that the application knows which folders and registry keys to manage. 

Once you've done all of the above you need to configure your Environment Manager policy configuration to execute the managed applications at logon with the import switch and again at logoff with the export switch. 

The cons of using the tool are that it is unsupported by AppSense. So if you run into an issue when using this tool or AppSense Support deem this tool to be the cause of an issue you could face a tough decision. The next con is that the tool is not signed by AppSense so several large multi national organisations are understandably unwilling to import the application into their desktop builds. Customers that have implemented the tool have also experience a level of database bloat because of the file based registry method implemented by AppSense. The result of this is degraded performance, excessive database growth often leading to a poor user experience. Lastly, the application has caused performance degradation in some cases extending the logon time slightly over the hiving approach described previous. 

The pros of the tool are that it is extremely flexible. It can be triggered from any of the triggers available within the Environment Manager Policy configuration and not only logon and logoff like the standard desktop settings tool. It can be as granular as the customer likes to the point where you could manage each file and registry key individually if desired although... I would NOT recommend doing this. 

It also means all of your Desktop Settings exist within the database... so you have a single place to go to manage the user profile.

The tool is fully documented and ready to go... download it from myAppSense by clicking on the following link:

Hybrid Approach

The hybrid approach is a mixture of the the hiving approach described previously and the EMP_P2V approach... although it doesn't rely on EMP_P2V. 

Using this approach the customer could leverage hiving and folder copies to ensure desktop settings are hived out to a local folder on the system drive. Once the hiving is complete launch EMP_P2V with the local folder specified as the inclusion path. This will cause the registry hives and folders that exist within this folder to be copied to the database.

If you didn't want to use EMP_P2V you could use the same approach described within my previous migration blog post and use a helper application like XCopy in order to copy the folders into the database. 

The beauty of this approach is that you have the best of all worlds... a proven, resilient solution that has been around since 2006 exporting and importing registry files into the users registry along with a simple  file copy to import the data into the database. 

Management is done in a single place because roll backs, etc are all done within the database. 

Database bloat is no longer an issue because all you are doing is importing files that don't suffer from the FBR bloat that I described above. Again, the approach can be as granular as you require because you could separate your registry hives into as many individual actions as you require.

Performance should, in theory, be better than Desktop Settings because it can make use of more than 1 thread to perform the downloads and import whereas Desktop Settings is single threaded. This means that Desktop Settings performs one operation at a time from the top to the bottom until it is complete. In addition, the application is managed as a standard Personalized application so users would get the benefit of being able to use offline mode which should give massive network bandwidth savings over hiving to a network share. 


So as you can see there are many different ways to skin a cat... each method has its merits. 

I personally use the straight hiving on my own desktop because this is the outright winner from a speed perspective however it is a fat client that is permanently connected to my file server over a 1Gbps network connection. If I wasn't permanently connected to the network I would almost certainly leverage the hybrid approach in conjunction with Personalization Servers offline mode capabilities. 

Either way... hopefully this post has given you some ideas on the importance of Desktop Settings and some ideas on how to tackle this.