Thursday, 24 January 2013

AppSense Personalization Server Best Practices

I'm often asked to provide customers, partners and employees alike with a list of best practices that should be followed when implemented AppSense Personalization Server.

Here are my best practices:
You cannot do enough application analysis

Application analysis and testing is key to a successful Personalization implementation. I cannot stress the importance of the test phase of an implementation. The more people who can use real applications that your users will use in the ways that your users will use them the better. 

On this point there are several great resources out there to help with the application analysis process. My personal favorites are:
  • Configuration Assistant (included with the AppSense Management Suite) (See note below)
  • Process Monitor 
  • FileRecent and RegRecent
Note: Configuration assistant writes passive data into two separate tables within the Personalization Database. This means you can use tools like Configuration Assistant Template Creator to analyze the data and create an XML snippet for an application. Fantastic tool written by Landon Winburn within the AppSense Professional Services Team.

Always Group Applications

This has been a controversial topic for some time. Some people argue that grouping applications can lead to profile bloat and increase the complexity associated with managing an AppSense Personalization Server Environment. Whilst the first statement regarding profile bloat is true, it is only true if you don't set your includes and excludes correctly.

Think of it like this... You have a Personalized application called MyCoreBusinessApp.exe and this has been working like a dream for years. The company who wrote MyCoreBusinessApp.exe have recently released a new version of the application which uses the same registry keys as the existing application but comes with a new executable called MyNewCoreBusinessApp.exe. Perhaps you want the two to be completely independent applications but in my experience customers simply want to install the new application and get on with it. With the grouped approach it is simple... add a new executable to Personalization Server and add this to the same group as MyCoreBusinessApp.exe. 

Grouping also makes getting settings into the virtual cache a lot easier. I'll be writing a follow up post on a few methods you can use to get settings from a roaming profile into the AppSense Virtual Cache. 

Includes and Excludes really matter

I've previously posted about the importance of the includes and excludes list here but I will say it again. A very restrictive configuration will cost you more up front to implement because it will take longer and require more application analysis but it will definitely be worth the investment. 

If you're looking for a fairly safe starting point I'd look to start with the following:

Global Registry 


Global Folders


On top of this I then add the following to each and every application group I create:

Registry Exclude


Folder Exclude


The above configuration will ensure the Application Group only contains the settings that actually matter to an application keeping the group as small as possible. 

Using Conditions with care

One of the beauties about AppSense Environment Manager is its flexibility but this is also one of its downfalls. All conditions within Personalization Server will have a cost but some are more than others. In my experience you will want to avoid the following where possible:
  • Computer Group
  • Computer Name
A few other condition related tips:
  • Avoid using site membership rules if you can. If you need to think about using the GPO method and using Environment Manager Policies conditions to determine the machines site membership.
  • Where conditions are required keep these as simple as possible (i.e. Membership of a single group)
Sites List

Two things on the sites list: 

First, it is processed alphabetically so make sure you factor this in when adding servers and virtual servers to the sites list.

Second, if you've implemented load balancing in say a 10,000 user estate don't add the virtual server followed by the physical server. Assume the virtual server fails overnight and the users all arrive on site in the morning and all try logon... they'll hit the virtual server, which is unavailable, failover to the first server and all use that until it eventually fails as well. If you don't trust your load balancers i'd recommend adding a DNS Round robin to the bottom of the virtual server list.

Access Rights

A mistake i've seen at least 3 times in the past few years is that customers typically have a dedicated AppSense Engineer during the build / test phase but then once things are stable this person moves on to do something else. The problem here is that the first engineer who runs the SCU will be added to the Administrators role within Personalization Server. If this user moves on from the organization and you need to get into the database it involves editing tables within SQL to repair access. 

Always add a group or at least a number of named accounts to the list so you have a way in. 

ConfigPoll

AppSense have kindly changed this for us already to default to 86,400 seconds. If you haven't already done so... double check that the configpoll is set to this within the global settings. 

Remember though... any changes to the Personalization Server are immediate. The console accesses the backend database on the fly so changing configpoll from 900 seconds to 3 seconds for example would take affect after the next config poll or at user logon. 

CAUTION: The above was an example change only, don't EVER change the configpoll to 3 seconds.

FileTypeExclusions  

Another interesting global setting. Almost all customers I go to still have the default values in here but when you start digging into the users virtual caches you start seeing Microsoft Office documents or other random files. As you're analysing a new application for Personalization find out what its common file types are and add them to the filetypeexclusions list. This will prevent documents, etc being written to the virtual cache and instead to the "real" filesystem. 

Thats all I have for now. I will update this post from time to time as I think of more important best practice suggestions.