AppSense user personalization is one of the more powerful parts of the AppSense suite. It allows a user’s customizations (desktop and application) to move with the user to their pc, laptop, or virtual desktop. The AppSense Environment Manager handles this function. We are stepping up a production AppSense environment and I ran into a conflict between the production and lab AppSense environments. In this blog post we’ll look at Auditing and Sites in the AppSense consoles to control where the user’s custom settings go.
In the AppSense Management Console, you can activate auditing for each Deployment Group.
Each section, which obviously governs a different aspect of the AppSense suite, contains many events that report on the various functions/actions of AppSense. Here’s the Environment Manager list of events:
Toggling the check boxes allows you to view events in the console (surprisingly, under the Events section).
You can modify how this information is logged in the Environment Manager console.
When you’re looking at the Policy Configuration and click on the Auditing button you’ll get the following:
These settings govern how the events appear on the local device that has the installed agent. Here, you can choose which log the events are written to , whether to make them anonymous, and even the log format. You can also pick which events locally logged on the client device.
NOTE: Auditing should only be used for troubleshooting. Leaving this on will impact the performance of AppSense.
Now that you are logging these events you can see if your configuration is recording them. In my situation, I was seeing these events, but when I ran the Personalization Analysis I did not get any user or application data. I found that when I connected to our lab personalization server which was setup first, I could see the data I was expecting. This was due to the Default Users and Default Sites settings present in the lab personalization server configuration and that this original configuration was imported into the new environment. This required us to change the configuration in both the old and new configuration to explicitly list with servers or Group Policy OU they resided in.
In my new configuration I created a new Site and named it Migration. I added my new EM server and also added a Computer OU membership that included all my servers I wanted to discover applications from.
To make sure the old configuration did not continue to gather data from my servers, I added a new site (called Migration for consistency sake), added my new EM server, and added the same computer OU membership to it.
Now when I run Personalization Analysis on my production Personalization groups, I can see user and application data.