Application Personalization Guidelines
Data files associated with an application should never be included. So any save as file types should be excluded for the application. For example, looking at Microsoft Word and without analysing the application I will immediately exclude .doc and .docx because I know these are data files created by the application which I never want to include within my application.
Next I want to exclude all folders that house temporary files (e.g. Auto save folders, temp folders, etc). I do this because these folders often contain files that are written to and removed regularly. Folders of this nature will, over time, cause the application to load slower as xml files are parsed and ultimately degrade the performance of the application.
I also want to exclude folder that contain large files. An example could be the Microsoft Office Building Blocks folders. Whilst this folder is important to users who make use of this feature not many users do. By including the folder the building blocks will be captured on first launch which will add several megabytes of data to the users profile which they may never need. Another example of this is managing the WebCache database which houses user web history. This database grows rapidly and has been known to exceed the default 30 Megabyte ASP.NET file size limit ultimately causing application synchronisations to fail.
I also want to review the registry keys that are captures and determine the size of these. Large keys should be excluded from personalization because the file based registry (FBR) method currently used by AppSense Environment Manager doesn't cope well with large files. In addition, personalizing registry keys that are read frequently (e.g. Recent files list) could cause performance issues with some applications. Persisting these lists are important for users so where possible reduce the number of items in the list, consider using a Windows Settings Group or alternatively consider using Environment Manager Policy to manage the recent files list.
Do whatever you can to keep the application profile as small as possible. This will improve performance and cause considerably fewer headaches over time.
Process Monitor Filter
Now that I've provided some guidance on what to include, the easiest method I have found to do this is by creating a good process monitor filter.
The first thing to do is stop the current capture by clicking on the icon which looks like a magnifying glass, highlighted below:
Once capturing is disabled click on the filter icon which looks like a funnel, highlighted below:
Start by creating the filters shown in the image below:
Note: Process Name should be the application you are analysing, in the example image I was analysing Lync.exe.
Once the filter has been created, enable capturing by clicking on the magnifying glass again and you will only see the actions from the executable listed in the Process Name filter for the 4 operations specified to the two paths included. Your log will immediately go from hundreds of thousands of lines down to thousands of lines.
You best option at this point is start a new text document and capture the unique paths each time adding these to the exclude filter.
In the example below I've added %USERPROFILE%\AppData\Local\Microsoft\Office\16.0\Lync to my text document so in turn I have added an exclude filter for paths starting with C:\Users\RichardThompson\AppData\Local\Microsoft\Office\16.0\Lync and just by adding that single key my log has dropped from 8,000 entries to 2,000 entries.
A copy of my baseline filter can be found here.
As with all guidance on my blog, this is not a definitive how to guide. Its intended to get users up and running as quickly and easily as possible. If you have any questions please contact me directly.