How to Personalize Microsoft Office 2010 with AppSense

How to Personalize Microsoft Office 2010 with AppSense

Microsoft Office 2010 can be personalised with AppSense Environment Manager. AppSense have a “Best Practice” guide which is available from The guys did a good job with it and we used it as a baseline. Most of the information here is reflected in the guide but, and please don’t drag me over the coals, we do some of the %appdata% folder includes\excludes differently, and I’ll explain why.

I will assume you are au fait with creating Application Definitions and Application Groups and you already know your way around EM. So let us start with the basics.

Start off by creating some new User Applications for each of the following executables in the Office suite. Then add these executables to a new, appropriately named, Application Group e.g. “Microsoft Office 2010”

When adding these executable definitions, the regular expression for “Version Reg Ex” should be ^14.* if we are personalizing Office 2010. Adjust this value as necessary for other versions of Office.


Ok, so we should have a new application group called something like “Microsoft Office 2010” with the above exe’s assigned to this group. Now lets add some registryand file includes and excludes for our Application Group.

Registry Includes:-

Registry Excludes:- (thanks Landon for the revised info)

File Includes:-

*The items in red will need some explaining why I do this differently to best practice*

File Excludes:- (thanks Landon for the revised info)

These includes and excludes will pretty much get you going. They are not exclusive and I have seen some other good keys\folders defined by other bloggers. We do have other excludes but they are unique to our environment and reflect how tightly we personalize specific data for Microsoft Office.

Ok, let me address the items in red…

Office 2010 applications, by default, will save any AutoRecovered documents, after an application crash, to the users %appdata% folder. These are:-

When the app crashes and saves an autorecovered version of the users file, this file will be copied up to your personalization server when you next exit the application. I have seen some AppSense profiles grow horrendously if we do not exclude these file locations.*

Unfortunately, we cannot just simply exclude these locations from personalization for the application group without having an effect on other office components. For example, {CSIDL_APPDATA}\Microsoft\Word has a subfolder called STARTUP and {CSIDL_APPDATA}\Microsoft\Excel has a subfolder called XLSTART – both of these folders are the default file locations for Macro enabled documents used on app start-up. Adobe also likes to put PDF toolbar items into these folders. Also, things like the auto list library are stored in {CSIDL_APPDATA}\Microsoft\Word folder so consideration needs to be made on how to get these items in and out of personalization if, like us, you decide to exclude it.

*Also, consider playing with Group Policy to change the Auto Recover location if things start getting sticky.

I live in a goldfish bowl so this applies well in our environment. Test, test, test to see how it will affect your users and I definitely recommend, if you don’t already, do some personalization analysis using the data collection option on your test personalization group to see exactly what is being saved in those locations and reg keys.

Again, this config reflects how we do things in our organisation and may not be applicable, in its entirety, to yours. Please comment if you have some other useful tips for Office 2010 personalization. The AppSense user community is growing strong and I am a firm believer in sharing knowledge to eek the best out of the product and maximize its use in our organisations.

How to Personalize Microsoft Office 2010 with AppSense

How to Personalize Microsoft Office 2010 with AppSense

Rate this post

11 thoughts on “How to Personalize Microsoft Office 2010 with AppSense”

  1. Landon Winburn

    Two issues here. First, the excludes for the resiliency keys should have \Document Recovery removed and should end at \Resiliency.

    Second, the issues in red can be resolved by adding the proper file type exclusions in global settings:


    1. Hi Landon, thanks for the comment. Your opening statement “Two issues here” is a little harsh.

      The registry excludes for the Office Resiliency key follow AppSense best practice as per the Best Practice guide I mention in the blog. Please expand on your reasoning if you think this is incorrect.

      Your second “Issue” presumes, that by excluding office file extensions globally, that the user never wants to include any office documents within personalization. This may be the case for a lot of environments because, if unmanaged, your database can quickly grow horrendously, but certainly isn’t applicable for ALL environments. In my particular example i pointed out that the user may have an office macro in the Word STARTUP folder or the XLSTART folder. They may want to include this macro in the personalization database instead of copying it in on a process start trigger – horses for courses.

      I do agree with some of your global excludes though like msi’s for example! That would be painful if we kept those in the DB 🙂

  2. Landon Winburn

    Sorry man, didn’t mean to come across harsh. As for the resiliency keys, see

    As for the file type exclusions, all one has to do is do a file/save and save a doc to an included folder and the file would wind up personalized. These file types are the typical ones we have to remove from the database when we do health checks and find application caches that are larger than a MB or two and have used the proper technique of personalization using the exclude all concept.


    1. Landon Winburn

      One more… You should change your folder exclusions to {CSIDL_PROFILE} and {CSIDL_COMMON_APPDATA} and then remove {CSIDL_APPDATA}. The reason for this is to cancel out the global includes and to ensure only your includes are being personalized. As it stands with your current config, anything written to the profile outside of %appdata% would be captured.


    2. No worries mate. Interesting KB regarding white space growth in the users fbr. I think it would be nice to update the best practice guide on Office personalization with this information. Ill update this blog retrospectively too, thanks.

      Personally, I am not sure how many users would save a document to %appdata%\Microsoft\Office area of disk but appreciate crazy things can happen in M$ software especially if Group Policy isn’t setup to consider default file locations for app crashes etc. Including the file type exclusions for “Global Settings” in the Best Practice guide would be good too if we decide to take this approach.

      So, in hindsight, it wouldn’t hurt to exclude these file types from Personalization as you mention. A workaround would be to copy the Office Startup Macros in at logon or on process start trigger.

      Regarding the folder excludes, again..good stuff, the Best Practice guide looks like it needs updating for sure:) Interesting that you say we could end up catching data oustide of %appdata% for the app. I have seen data captured for office as %systemdrive%\Users\%username%\… as well as the normal appdata format. Could this be the reason?

      Thanks for the info, its really useful.

      1. Landon Winburn

        Absolutely the reason. If you have a global include of {CSIDL_PROFILE}, pvc.dll is being told to gather up ALL files being written by the given application into the entire profile minus the items that have been explicitly excluded. This is the reactive approach to personalization where you find issues after the profile has been bloated and then exclude the items.

        The better option is to use the exclude-all concept. To do this you first exclude {CSIDL_PROFILE}, {CSIDL_COMMON_APPDATA}, and HKCU\Software on every application you personalize (preferably using application groups even if its a single app but that’s for another blog :)) which will nullify the global includes. If you didn’t add any includes for this application NOTHING will be personalized. From here you add the items you actually want to be captured. My template creator makes this really easy…

        The reason your seeing non-wanted settings in the cache is you still have the door open via the global {CSIDL_PROFILE} and {CSIDL_COMMON_APPDATA} entry points. The only folder that’s using the exclude all concept there is the {CSIDL_APPDATA} folder but once you add the exclude for {CSIDL_PROFILE} the appdata exclusion is no longer needed as its a subfolder.


        1. Landon, Excellent information here, thank you!

          One question (because you seem the man who would know this)…Would I still be capturing “%SystemDrive%\Users\%username%\appdata\Roaming\Microsoft\” if I excluded {CSIDL_PROFILE}, {CSIDL_COMMON_APPDATA} for the application? I want to know why PVC.DLL is picking up this relative path to the %systemdrive% variable instead of the {CSIDL_APPDATA} when personalizing office.. we see this on quite a few users. Any thoughts (sorry its off topic slightly)?

          Note for Users: Microsoft Technet article Constant special item ID list (CSIDL) values is a good place to head for more information on Windows 7 recognized environment variables.

          1. Landon Winburn

            This app will translate the CSIDL names on the box you run it on.


            In personalization analysis change the folder display to RAW and the view to flat file view. This will get you the CSIDL name that it came in on. Chances are in came in on {CSDIL_PROFILE} but it may have come in before you added the {CSIDL_APPDATA} exclusion as this should have blocked that folder. In any case, exclude profile and you’ll be good.


          2. Thanks for that link Landon,

            Even in RAW view mode the root folder is %systemdrive% (see screenshot below) Any ideas whats causing this?


  3. Hi,

    I have some troubles with Excel addins.

    I would like to exclude “Open” registry values.
    I would like to conserve the registry key “Options” and exclude all “Open” registry value.


    Can you tell me if there is a possibility to do this with Appsense ?



    1. Hey Dias,

      All child objects of an included registry key are included unless explicitly excluded (as you have found out).

      In this scenario you have two options:-

      1. Exclude the full key “[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\14\Excel\Options]” and then explicitly INCLUDE the option values that you need to keep.

      2. Create a node action at logoff using application masquerading or the /appsensespecial switch to overwrite those specific OPEN, OPEN1, OPEN2 etc registry values.

      I’m not going to re-write a tutorial on application masquerading here. James Rankin has done a great job over here:-

      Obviously care has to be taken with this approach. Option 1 would be my preferred choice – Keep It Simple 🙂

Leave a Comment

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.


This site uses Akismet to reduce spam. Learn how your comment data is processed.