Sunday, 1 June 2014

Exporting Registry and Folder Items from the Personalization Server Database

Update (03/06/2014): A third method for exporting settings has been added to the article below

AppSense are often described by competitors as locking you in to their technology because of their reliance on the Microsoft SQL Server platform. A data jail for lack of a better term. I've lost count of the number of times I've heard this from prospective customers and frankly this is not true.

Before I get into the detail we need to take a step back in time...

AppSense launched the Personalization Server back in 2008 when it released AppSense Environment Manager 8.0. The reasons for introducing this Microsoft IIS based service include the fact that a properly designed 3-tier solution will almost always be more scalable than a legacy 2-tier solution and having user settings stored within a database meant searching and reporting on the data was significantly quicker. It also meant that archives (or snapshots to some) could be taken easily on demand by simply called a stored procedure either from the AppSense Personalization Server GUI or through Microsoft SQL Server Management Studio.

Before the release of the Personalization Server, AppSense were however providing user personalization capabilities to a number of customers around the globe through the use of registry hiving and folder copy actions using Environment Manager 7.


Take a look at the following data sheet first captured in 2006 if you don't believe me:

http://web.archive.org/web/20060917112956/http://www.appsense.com/files/documentation/AppSense_Product_Feature_List_Environment_Manager_v6_0_SP1_US_1.pdf

Although AppSense could not make use of the extensive set of triggers that it does now it was able to hive out the various elements required to a network share at logoff and was able to hive these back in at logon. Implementing this in conjunction with volume shadow copy on a specific user share gave customers a pretty solid solution which co-incidentally is still in use by some of our largest customers.

Now I'll return to today...

The good news is that capability still exists today and in fact is recommended over Personalization Server in some instances. This technique is pretty remarkably similar to what majority of AppSense's competition do... with a few exceptions. Some rely on implementing their own shell to replace the standard Windows shell whilst others rely on managed shortcuts in order to do a level of application personalization. The fact that AppSense have been using this proven technique for significantly longer that majority of its competition means that it doing something right with technique.

So for new prospective customers that are looking to implement AppSense DesktopNow but are concerned because of the scaremongering done by their competition... fear not. You don't need to implement Microsoft SQL Server in order to gain significant value from the DesktopNow Suite. For the customers who are already using AppSense DesktopNow and would like to revert back from the Microsoft SQL database in favour of registry hiving and folder copies the process of getting out is fairly simple. There are two ways to get out:

The first is achieved through AppSense built tools called EMPRegUtil and EMPFileUtil both of which have export switches to export registry keys and files from the AppSense Personalization Server database.

The second is by reversing the process used to get data into the database. Simply take a copy of reg.exe and xcopy.exe. I prefer to name them something appropriate like <AppGroupName>-reg.exe and <AppGroupName>-xcopy.exe. Add these applications as user applications within the Personalization Server console. Then add these newly defined applications to the application group whitelisted within the Personalization Group that you wish to revert from Personalization Server. Now simply run these newly created helper applications using the export switches and copy the data to a folder that is not included in the Global or Application Groups folder inclusions list.

Each of these methods is documented below:

Using EMP Utilities to export Personalization Data

When I am writing export scripts I always start by importing a template that I've created that gets the users Personalization Group and saves this as a user environment variable called APPsGroup. This is quite important because the EMPFile and EMPReg utilities require the Personalization Group as one of their mandatory parameters and some customers split their Personalization Groups up for various reasons. Instead of creating a batch file for each group I create one and use my custom action to determine the group for me.


The custom template can be found here:

https://dl.dropboxusercontent.com/u/10535121/Process%20Stopped%20APPsGroup%20Snippet.xml

Now that you have all the pre-requisites in place a very simple batch file can do the rest. I've pre-created a batch file to export the registry keys defined within the inclusions list and all folders from the Microsoft Office 2013 Group on my Personalization Server

This batch file can be found here:

https://dl.dropboxusercontent.com/u/10535121/EXPORT.bat

A couple of things to note are that the batch file currently needs to be configured with the registry keys and folders to export. I plan on optimising this to get this information from the ProfileConfig.xml file similar to the method used for gathering the Personalization Group... I've just not done it yet.

Also, if you plan to change the file export to not export everything but instead gather specific folder structures you should check the database roots in Personalization Analysis first. Assuming that {CSIDL_PROFILE} will export everything because it is the only item listed in the applications include list is invalid. In this instance I would have needed three separate export actions configured to export the three folders highlighted below. Using the "*" symbol will ensure that all database roots including the file based registry and persistent.dat files will be exported. These may be handy if you are looking to import these into a different database.


Using Helper Application to export data

This approach is similar to the approach I described in my "Using AppSense Environment Manager to migrate user settings" post which can be found at the following URL -  http://uvarchitect.blogspot.co.uk/2013/01/using-appsense-environment-manager-to.html this method effectively uses helper applications to get the folders and registry keys out of the Personalization Server database.

The first step is to define your user applications on the Personalization Server and add these to the application group that you are going to be exporting data from.


Once that is done the applications need to exist on the endpoint. Simply copy the existing reg.exe and xcopy.exe executables and rename the copies to the same names used on the Personalization Server.

Again, a batch file will probably be your best bet here but you could also leverage an Environment Manager action to perform the export. In the screenshot below I have manually executed the following command:

Office2013-reg.exe EXPORT "HKCU\Software\Microsoft\Office" "Office.reg" which will create a file named Office.reg in the current directory containing the entire contents of my Microsoft Office 2013 Groups Office registry key.


The major limitation here is that you will need to perform the same operation for each of the registry keys and each time the Office2013-reg.exe or Office2013-xcopy.exe application launches it will cause the Office 2013 application to sync with the endpoint and this may cause an excessive number of transactions to and from the database particularly if you are trying to perform a mass export. If you try this with Persinfo.exe running in its toaster mode you will get a taste of what I mean:


I'd strongly suggest you implement include an application like Office2013-notepad.exe within the application group that you launch first to download the settings and then execute each of the export applications and then terminate the managed notepad.exe once all synchronisations are complete. In this instance you see the following within when persinfo.exe is run in toaster mode during the export:


The performance difference between a single sync and multiple syncs took the export from around 2 minutes to 15 seconds. The scripts I used to demonstrate this can be found here:


Now that these files are standard files you can simply import them by reversing the process using un-managed applications or through a simple logon script to merge these back into a local or roaming profile.

Using ImportData to export data to the local profile

A third and arguably the simplest method would be to use the AppSense Exchange tool created by Landon Winburn called ImportData.

This tool is a very simple tool that essentially assists customers migrate settings from a local or roaming profile into and out of the personalization server.

Once you have the tool downloaded and stored on a file server within your organisation that end users have access to simply make a few copies of the tool Assume you want to export the personalised settings for Microsoft Office 2010, Internet Explorer and SAP Gui you would simply need to create three copies of the executable as seen in the image below:



Once these three copies have been created simply add them as user applications within each of the respective application groups.



Now simply update your Environment Manager configuration to run the following command to export these settings from the Personalization Server back to the local profile:


Its as simple as that... 3 methods to easily get out of the supposed "AppSense Data Jail."