A few weeks ago (or maybe more), I was having some discussions with Richard Thompson around the fact that I'd covered a subject on my blog that he had already done lots of documentation on. I did mention at this time that I would instead concentrate on my document regarding PersInfo, one of the most useful tools available for the AppSense administrators out there. Unfortunately, he promptly sent me a link to a post he'd already done on PersInfo - a good read and covering most of the stuff I'd intended to! So instead of discussing the ins and outs of the tool like Richard already has done (it was also covered by Mark Schill), I will concentrate more on how you can use PersInfo to silently gather logs on Personalization activity to help you address issues a user may report.
If you're familiar with it or you've read either Richard or Mark's articles, you will know how much value PersInfo can bring. Being able to view the realtime activity of Personalization Server is invaluable when you are having problems. You can download PersInfo from the AppSense Exchange and it really should ship as a standard part of the software, in my opinion, or at the very least as part of the Environment Manager Tools. It is, unfortunately, unsupported by AppSense, but whenever it has thrown an error I wasn't familiar with it always turns out to be a mistake on my part. For instance, if the .Net Framework isn't installed it won't run, and if your license has expired, you may get an error saying "User Virtualization Agent is not installed". Apart from these sorts of things, it seems to run without any issues.
 |
| PersInfo doing its stuff |
Having said that, the first thing you will notice about PersInfo is that it is intrusive (and it's meant to be, obviously). Normally you would run this when testing or when you know there is a problem, and the constant pop-ups allow you to see exactly what is going on. But recently, I ran into a case where users were having Personalization issues, but because of time-zone differences, I wasn't able to troubleshoot it in realtime. So I was left with a requirement to gather PersInfo logs in the background without popping up the activity balloons, so that the user wasn't disturbed by the application.
Naturally, if you dig through the PersInfo context menu settings, you will see that there are various configurable settings you can change
 |
| The PersInfo preferences menu |
What I wanted to do was disable the application framing and all of the alerts, whilst at the same time writing the logs to a network location and preserving them for analysis. So I changed the settings to those below
 |
| PersInfo preferences modified to save logs silently |
Naturally, I was hoping that these settings mapped directly to Registry keys, because then I would be able to use AppSense Environment Manager to deploy them to the users as they launched their session. Thankfully, they write quite predictably to HKEY_CURRENT_USER\Software\AppSense\PersInfo. Don't you just love it when settings are that easy to prognosticate? :-)
 |
| PersInfo Registry values |
In case you didn't know, you can simply export a Registry key directly from regedit.exe and then import it into AppSense Environment Manager for processing. First of all export the Registry key in the normal fashion by right-clicking the target key and choosing Export. This will create a file with the familiar .reg extension.
 |
| PersInfo registry export file |
Now, we can open Environment Manager and set these values up as Registry Actions. First, however, we need to ensure that PersInfo is started every time the user logs in. We can easily achieve this with an Execute Action in the Logon trigger, provided naturally that we've downloaded and extracted PersInfo to a place the user can access!
 |
| An EM Execute Action to launch PersInfo at user logon |
Now, we can add a Process Started Action for persinfo.exe to apply the required Registry entries. You could put this in the Logon trigger after the Execute Action, but by using the Process Started trigger we can make sure the Registry entries are there even if the PersInfo application is closed or crashes and needs to be relaunched mid-session in some way.
 |
| Process Started trigger node for PersInfo |
You import a Registry file by using Actions | Registry | Import A Registry File. This will open up a window from which you can use the Import File button to select the .reg file you exported earlier.
 |
| The EM Registry Import window |
This window is a little unintuitive as you only check the boxes if you want to delete the Registry keys, rather than Set them. It would be nice in a later version if this allowed you to maybe select Set or Delete from a drop-down box instead. So in this case, to Set the values, simply leave the boxes unchecked and click OK.
Now you will see that the relevant Registry Actions (both for creating the keys and the values too) have been imported into your configuration.
Now, naturally, is the time to save and deploy your configuration. Once this is done, we can log on to the endpoint and see if PersInfo is running silently and writing logs to the required location. Indeed it is - we can see the little green icon at the bottom, and read our logs from the network location. Excellent!
 |
| PersInfo running in silent mode |
Now obviously there are caveats to this - especially the fact that running PersInfo in this way means there will be an extra process running for every user. If you didn't want that, you could simply provide a shortcut to PersInfo for the user to run as directed, and then import the Registry settings as required at Process Start. There's also the possible issue you could eat up lots of disk space if you run this constantly, so some sort of management of the log files is probably required - deleting logs over a certain age would be a good idea.
But anyway, I found this to be a good way to maintain visibility of any possible Personalization issues - hope some of you may find it useful!
Bootnote
Can I just say a quick thankyou to the people who emailed or Tweeted messages of support whilst my missus was in hospital with sepsis last week? It wasn't a very pleasant experience and I am glad to be back to the normality of technical stuff :-) Thanks again.