AppSense Personalization Best Practices – Grouping
AppSense Personalization has two types of grouping:
- Personalization Groups
- Application Groups
When we start to build a new AppSense Personalization environment, we always create a Personalization group for each step in the release cycle:
In most cases these groups are based on computer OU membership, and they reflect the same configuration as the Deployment Groups from the Management console.
Before those personalization groups, we add a group called “Unmanaged Users”. Users that are in this group typically are system accounts, service accounts, administrators and others that do not need any personalization.
The pre-configured group “Default Users” should not be used. In the odd situation that a user would land into this group, we made a mistake. That is why we disable all functionality from this group. This will trigger the user to call the helpdesk since none of his personalization data is kept (which should never happen).
Out of experience we think that it is best to ALWAYS group your applications in Personalization server. The main advantages are:
- It is easier to differentiate in the steps of your release management.
- If an application is depending on a secondary application and this was not seen in the initial analysis, it is easy to add. This is also valid for application upgrades where new executable(s) are introduced.
- Application groups allow you to manage all applications from a folder. As an example you could configure to manage “C:\Program Files\Microsoft Office”, which will personalize every executable that runs from that folder.
We give following naming convention to Application Groups:
We added the # sign between each version that is valid for this configuration. In the above example you will have noticed that Adobe Reader had an application group for older versions and a second application group starting at version 9 till 11.