Application Personalization Workflow

www.ivanti.com | 801.208.1500

Application Personalization

Process

Ivanti User Workspace Manager - Environment Manager

Application Personalization Process – Environment Manager


Document Revision History

Date Author Revision Change Reference

8/2/2013 Landon Winburn 1.0 Initial draft

8/2/2013 Richard Thompson 1.0 Review

11/20/2013 James Ley 1.1 Added Identifying Applications section

11/20/2013 Greg Ford 1.1 Review

12/4/2013 James Ley 1.12 Update

12/16/2013 James Ley 2.0 Update

12/16/2013 Landon Winburn & Richard Thompson

2.0 Review

3/21/2017 Adam Crossett 3.0 Updated for architectural changes in EM 10.x

10/30/2017 Randy Barger 3.1 Review



Contents

Environment Manager ............................................................................................................................ 1

Document Revision History ................................................................................................................... 2

1. Overview .............................................................................................................................................. 4

2. Personalization of Applications ........................................................................................................ 4

2.1. Prerequisites ................................................................................................................................ 4

2.2. Identifying Applications ............................................................................................................... 4

Is it web-based?.................................................................................................................... 6

Is it a shared Office document or Access database? ..................................................... 6

Does it store settings in the user’s profile?....................................................................... 6

Do the application settings need to persist between non-persistent sessions? ......... 7

Verifying with a non-persistent profile ............................................................................... 7

3. Personalization Includes and Excludes .......................................................................................... 8

4. Global Includes & Excludes .............................................................................................................. 9

5. Personalization Discovery Methods .............................................................................................. 10

5.1. Automated Analysis via Data Collection ................................................................................ 12

Workflow .............................................................................................................................. 13

Collecting Data.................................................................................................................... 14

Review collected data in advanced mode ...................................................................... 14

Creating an Application Group from collected data ...................................................... 17

Initial Group Check and Explanation ............................................................................... 19

User Testing and Review .................................................................................................. 20

5.2. Manual via Registry and File Inspection ................................................................................ 22

Workflow .............................................................................................................................. 23

5.3. Manual Analysis via ProcMon ................................................................................................. 26

Workflow .............................................................................................................................. 26

6. Appendix A – Knowledge Base ...................................................................................................... 32

7. Appendix B – Items to Ignore in Data Collection ......................................................................... 33



1. Overview

The document has been designed to provide the reader guidance on the process to create custom

Application Personalization Configurations for common and bespoke applications.

Using this best-practice approach to Application Personalization will ensure that the environment is

optimized, scalable and manageable.

Only the Ivanti components applicable to this document are detailed and discussed. For full details

of the Ivanti DesktopNow Suite, consult the product documentation available at

https://community.ivanti.com/community/appsense.

2. Personalization of Applications

2.1. Prerequisites

The following are prerequisites for creating and importing personalized application configurations

for Ivanti Personalization Server.

Ivanti Environment Manager Console is installed

Ivanti Personalization Server is configured and enabled

Data Collection is enabled within Personalization Server

Ivanti Environment Manager agent is deployed to endpoints with an Environment Manager

configuration with Personalization Servers configured.

The administrator has credentials to connect to the Ivanti Personalization Server

In the context of these instructions administrator is defined as the person analyzing application

Personalization requirements and configuring Personalization Server accordingly.

The administrator will need to be added to the relevant Active Directory group to give them access

to the Ivanti Environment Manager / Personalization Server consoles.

2.2. Identifying Applications

The first step in personalizing applications is to identify what needs personalization.

Unfortunately, there is no automated and fool-proof way to achieve this. The most effective way of

doing this is for an Application Owner, Packager or someone that knows the application well to

provide key information about it and how the application may save user preferences.

https://community.ivanti.com/community/appsense



The diagram below provides a framework for the process to decide if an application is likely to

require Personalization.

Is it web-based?

Is it an Office document or Access database?

Does it store settings in the user's profile?

Do the application settings need to persist between sessions?

Do not Personalize

Do not Personalize

Do not Personalize

Yes

Yes

No

Yes

Do not PersonalizeNo

Personalize

Yes

No

No



Is it web-based? Many line-of-business applications are actually web sites accessed via a browser. If this is the case

it’s highly unlikely that any Personalization configuration work will be required, as user settings

may be stored server-side within the web application.

The application should be tested on one machine – ideally with a user making changes to

preferences that they would expect to persist – then tested on a second machine. If no issues are

encountered, then no Personalization configuration will be required.

Rare exceptions include sites with browser add-ins that store application settings or cached data

locally.

Click Once style applications are an interesting combination of local executable binaries and web-

based calling/download. Though these are technically locally executed applications and able to be

personalized, the vast majority of Click Once web apps leverage centrally-located settings storage

(like other web apps) and thus will not require a personalization effort.

Is it a shared Office document or Access database? Many line-of-business applications are actually Microsoft Access databases, either hosted by the

Access Runtime (where the database has a built-in GUI) or hosted by the full version of Access.

If an application is an Access database, it’s highly unlikely that any Personalization configuration

work will be required. The same applies for other types of Office documents treated as internal

business applications.

The application should be tested on one machine – ideally with a user making changes to

preferences that they would expect to persist – then tested on a second machine. If no issues are

encountered, then no Personalization configuration will be required.

Does it store settings in the user’s profile?

Some applications are stateless; storing user-specific application settings on a server rather than

with the user’s local Windows profile.

Several methods can be used to determine whether an application is writing to the registry and file

system paths within a user profile, including:

Ivanti Data Collection

Manual profile inspection

Process Monitor Analysis



Do the application settings need to persist between non-persistent sessions?

In some cases, applications will store user-specific application settings in the user’s profile and

could be configured for Personalization, however, it may not always be necessary – or desirable –

to capture and manage this data. Relevant situations include the following:

Applications that store minor or unimportant preferences (e.g. Window position)

Applications that store session-specific temporary data

Applications whose default/pre-configured settings can be overridden by users, with

undesirable effects

The decision whether to personalize an application – based on the points above – can

only be made by someone with application-specific knowledge or by testing the application with a

non-persistent profile to see if the desired settings persist.

Verifying with a non-persistent profile

The first requirement in verifying if an application needs personalization is to setup a

machine with a non-persistent profile. This can be an RDS / XenApp Server with a

mandatory or temporary profile, a non-persistent virtual desktop, or a physical desktop with a temporary profile.

Please see Support.Ivanti.com for information on setting up mandatory and temporary profiles.

1. Logon the identified endpoint with a non-persistent profile and have a knowledgeable

user of the application in question logon and setup the application as they normally

would.

2. Once configured log off the endpoint.

3. Upon logoff, the local profile will be removed and any settings stored in that local

Windows profile deleted.

4. Have the user log back on to the endpoint once more and see if the application has retained its settings.

5. If the application has retained its settings then the settings must be stored outside the

user profile, perhaps in a backend database or maybe in the cloud.

If this is the case, then this application will not need to be personalized.

6. If the application lost its settings, then you will need to personalize the application.

The following sections of this document describe the process to personalize an application

with Ivanti.



Note

Once identified as requiring personalization by the above process and the following sections of this document have been completed so the application is managed by Ivanti, then the above testing steps should be completed once again to ensure the application settings persist as expected.

In addition to the above steps ensure Environment Manager Personalization is enabled on the endpoint and the application in question has been added to the whitelist within the Personalization Server console.

3. Personalization Includes and Excludes

Personalization relies upon a set of includes and excludes for a given set of applications. These

includes and excludes come in the form of registry and file locations. These items, coupled with a

set of applications, together form an application personalization group that defines what locations

should be “captured” for which applications.

By default, the Global Application Settings list of includes and excludes will apply to every

application personalization group that is created. These defaults serve two purposes;

To set the baseline for what areas of the filesystem and registry are personalized

To allow for rapid prototyping of application personalization via simple executable inclusions

Note

Remember, Windows Settings Groups do not obey the Global Includes and Excludes list. WSG’s are specifically targeted locations, in which everything will be captured.

When it comes to rule supersedence and conflict, EM respects a “more specific rule wins” logic.

As an example: The area HKCU\Software is in the global includes.

If HKCU\Software\VendorName was added to an application group’s Registry Exclude list, the

VendorName key would NOT be captured, while the rest of HKCU\Software would be.

The process works in reverse as well:

If the *.MDB file type is excluded Globally, a File Include of

{CSIDL_APPDATA}\Vendor\Needed_File.mdb would “win” and that specific file WOULD be

captured.

These rules apply to both Registry and File\Folder Includes and Excludes



4. Global Includes & Excludes

Personalization for applications respects the Global Application Settings dialog. These settings

specify what paths, locations and file (types) are included and excluded from application

personalization as a whole.

Note that these settings can be overridden by more specific includes or excludes at the application

group level.

Because of the default Includes, if an application is personalized without any application-group

level rules it will pull any registry values written to HKCU\Software with the exception of anything

written to a key in the excludes such as HKCU\Software\Policies.

The same holds true for files as by default anything written into the user’s profile (not just

%APPDATA%) would be captured with the exception of anything in the excludes.

Note

Because of the stated Global includes for registry and file / folders it is very important that ALL Application Groups EXCLUDE the HKCU\Software, {CSIDL_PROFILE} & {CSIDL_COMMON_APPDATA} paths from each and every Application Group before defining any INCLUDE paths.



The Global Application Settings list has no bearing on the locations monitored by the Data

Collection process. These locations are specified separately in the Data Collection Settings dialog.

The collected-to-date data in the database can be purged from this dialog as well, recovering

database space.

5. Personalization Discovery Methods

There are many methodologies and processes that can be used to analyze a system and identify

application setting locations. The purpose of all of these is to try and isolate as concise a list as

possible of the location in the registry and on the filesystem where a given application, or set of

applications, stores personalized user and application settings.

As always, it is important to make the distinction that Ivanti personalization is designed to capture

settings and not data. Documents, Programs, Spreadsheets and the like should not be stored in

personalization for data-bloat and security reasons. The information targeted should be the

settings that retain an applications look & feel, in addition to functional settings that direct an

application on what server to connect to (for example), or what font to use.

Ivanti maintains a small repository of Application Personalization templates in the Knowledge Base

(See appendix A), beyond the included Out of Box templates shipped with the product.



These templates have been reviewed by Ivanti support and are fully supported. They can be

downloaded directly from the Knowledge Base and then imported into the Personalization

Console.

Prior to executing the processes outlined in this document, it is strongly recommended to find and

consult with an application owner, vendor, or SME. Often these people and groups are able to

provide the locations where settings for an application are stored – without needing to analyze the

application. Frequently many hours or days of discovery and testing can be avoided by contacting a

party with a deep technical knowledge of the product.

When consulting with third parties for application information, there are three critical properties of

an Application (suite) that will be needed to build an Application Personalization Group

1. Executable names – All the exe names of the main and child processes of the application

suite

2. Registry locations – The locations in the Registry where the application stores user specific

information

3. File locations – The areas on disk where the application stores settings for a specific user

(typically under the user profile or AppData)

The workflows below are all supported methodologies for identifying these settings. Though all

three are valid, for the purposes of this document and in the interest of providing the most scalable

process, Automated Data Collection will be focused on as the primary use case.

Note that across these discovery methods child process of managed applications are always

personalized by default. Some child processes may not be suitable for personalization and should

be evaluated at the time. If there is need to exclude a certain process from being personalized

when called as a child of a personalized application, it should be added to the Application

Exclusions list, found under the Manage Ribbon.



Note that this list is pre-populated with processes known to Ivanti to be frequently called as child-

processes and when such, to cause potential issues.

5.1. Automated Analysis via Data Collection

Summary

Data Collection, as of EM 8.6, is an integral part of the Personalization console and server

and does not require any additional tools. Data Collection is enabled, monitored and acted

upon entirely from the Environment Manager Personalization Console.

Data Collection is run in the background by the EM agents on a testing pool of users,

automatically collecting and organizing data on application setting location storage for all

applications run within the session.

Benefits

A highly automated solution which scales well to on-boarding large numbers of

applications within an environment.

Output of this tool is easily and directly converted into Application Personalization Groups

Drawbacks

Application settings stored outside of the included areas of the profile will be missed



Workflow

Enabling Data Collection

Ivanti Data Collection will not gather any data until enabled within the Personalization Server

Configuration.

1. Launch the Environment Manager Console and select the Personalization ribbon.

2. Within User Personalization create a ‘Data Collection’ Personalization Group.

This isn’t essential but it’s an advisable approach to ensure that the ‘data collection’ group is

isolated from any other groups.

3. Add a membership rule specific to your testing or packaging environment.

“UAT Users” is the AD group example used here, but any membership rule can be used.

4. Once the ‘Data Collection’ Personalization Group is created enable Data Collection by selecting

the check box, a warning is displayed stating that enabling this feature could cause a

significant increase in system utilization; click Yes.

This setting must be set prior to user logon in order for data collection to take place for a

session.



Note

The warning “Enabling this feature could cause a significant increase in system utilization” is the reason Data Collection should not be enabled for all users.

Collecting Data

Once Data Collection has been enabled, ask a test user who conforms to the Personalization Group

membership rule to log on to a computer with the Ivanti agents installed and use their applications

– this will begin data collection for that user.

It’s important that this is performed on a clean machine with a non-persistent profile (such as a

temporary or mandatory) as this will ensure that all of the critical settings are identified. Using a

persistent or existing machine may not identify registry keys or files/folder that may have been set

previously.

When any application is executed Personalization Server will begin to gather data on how that

application behaves, including:

Where the application writes registry data

Where the application writes file data

If reads or writes are completed

When the application closes this data is sent back to the Personalization Server.

Note

It is important to remember that this data is simply a record on what happened and where, not the actual settings themselves. No settings are virtualized. All settings persist in the users Windows profile.

Review collected data in advanced mode

Once a user has provided information to the server and database by running their application in the

normal way, the data stored in the database can be analyzed by an administrator and seamlessly

converted into an Application Personalization Group.

From the “Application Personalization” Tab of the Personalization Group where Data Collection is

enabled, click on “New from Data Collection”



All executables run under the user’s context will be shown in this dialog. Note that this will include,

largely, applications that are irrelivent to the targeted application. In this example, FileZilla was run, so

the filezilla.exe application is selected.

Check the manual configuration checkbox as shown and click “Configure”.

The dialog showing the file and registry actions of filezilla.exe is opened. At first there will be quite a

lot of bad data here, most of which can be filtered out by checking off the “Hide paths which are rarely

personalized” option.



While uncommon, some applications may write information into locations which are excluded when

this box is checked. As such, if no data is shown with the box checked, uncheck it and reanalyze before

moving on to a more in depth method.

Note below that for filezilla.exe, there were no registry actions run that are relevant to the process.

However, several areas on the user profile were altered.



Creating an Application Group from collected data

As seen here, several locations received writes. Looking at the “Occurrences” column, it can be seen

that the {CSIDL_APPDATA}\FileZilla location received far and away the most reads and writes. Because

of this, it is a safe assumption that the application is storing its configuration settings in this location.

Most applications will store their settings in a directory titled for their vendor or name. Few

applications will store important settings in generic locations such as the cookies folder.

Check off the folder shown here and click OK. This will add that directory as a folder Include for this

application group.

At this point, a dialog appears asking for the application and application group names. The first field is

the name of this application specifically (FileZilla in this case, as there is only one application in the

group). The second field is the name of the Application Group, and should be named according to

some standard for ease of identification later on – even if that standard is simply “[App Name] Group”.



After clicking OK, the Application Group will be created and added to the Library of Application Groups

on the left-hand side of the interface. The group will also be assigned automatically to the group from

which it was created.



Initial Group Check and Explanation

With the Application Group created, the includes and excludes can be inspected to be sure they meet

match expectations.

Shown above is the single executable that is part of this group, filezilla.exe. It’s important to note that

even though there is only one executable used in this instance, an Application Group is still

recommended to be used as it permits the easy addition of additional executables to the group later

on – all of which will have access to the user’s settings for that application.

Looking at the Folder Includes, the AppData location added during the wizard is present in the

Includes section.

Note

Notice that {CSIDL_PROFILE} and {CSIDL_COMMON_APPDATA} are added as excludes, along with HKEY_CURRENT_USER\Software, even though we did not specify them in Data Collection. Data Collection created these automatically as part of Ivanti best practice in order to counterman the Global Includes detailed in Appendix A.



Looking at the Registry section, as expected there are no Includes listed as none were found nor

selected in the wizard. As with the Folders section, the Data Collection wizard has added an Exclude

here in order to cancel out the global include of the same registry location.

User Testing and Review

With the Application Group created and inspected, it can be assigned to a fresh deployment group –

preferably one without Data Collection Enabled. A user should log into this session and run the

application as they normally would, configuring it to their liking and closing it and logging off when

they are done.

Note

It is not strictly required to use a new deployment group for this phase – the Data Collection group can be used. A new deployment group was used here to provide the concise example possible.

Moving to a second machine, or to a fresh-logon on a machine leveraging non-persistent profiles, the

test user should re-run the application and verify if their settings from the previous session have been

correctly imported.

The exact information captured in the profile can be viewed within the personalization console.

Right click on the test personalization group and select “Personalization Analysis”



Click “Display” then click on the bar for the user who is performing the testing. There will be a bar

graph showing the total size consumed by that user’s Application Group – in this instance, the FileZilla

Group;

Right Click on the bar and select “Edit Application File List” – this will show a tree or flat file structure

breakdown of what was captured for this application group, for this user. The files in this structure can

be exported to the local machine (that is running the Personalization Console) and examined.



When examining the files and folders in this location that were captured, look specifically for temp,

tmp and log type files. These are very rarely personalized as they tend to contain instance-specific

data irrelevant to personalization. Additionally, they frequently grow quite large which can pose a

profile-bloat issue.

Also look for large files. The typical size for a user’s ENTIRE profile should be under 15MB. Typically,

this means that any single file collected by an application over 1MB should be considered suspect. This

is not a hard and fast rule, but a guideline to serve as the basis for determining which files should be

looked at with a critical eye as to whether they should be personalized or not.

IIS has a default maximum file single file size of 30MB. This is far over the average profile size, but not

only is a file of this size too large for sustainable database growth, but it will actually cause failures of

personalization when IIS cannot transmit the file correctly.

If the majority of files in the personalized folder where user application settings are stored are not

relevant to personalizing the application for a user, then consider removing the folder include added

in the previous step, and instead adding specific file includes for only the relevant settings files.

5.2. Manual via Registry and File Inspection

Summary

Regedit and Windows Explorer can be used to look for application data and settings in

commonly used locations on the system.

Benefits

A simple, fast method, relying on a basic level of systems-engineering knowledge

Can identify application settings written outside of the user’s profile and HKCU hive

Drawbacks

Some applications store settings and data outside of locations that are typically manually

inspected, increasing time required to discover settings

If Data Collection has missed a setting, it is unlikely that this method will find it



Workflow

If desired, the filesystem and registry can always be manually inspected in order to find the locations

where an application is storing its user configuration data.

Again using FileZilla as an example, a quick inspection of the user profile’s Roaming AppData directory

yields a directory named for the product. Obviously, the same directory discovered by Data Collection.

Knowing this folder is needed as an include, the name of the executable needs to be found.

Loading task manager, it is usually very easy to locate the running executable. As seen here, FileZilla is

identifiable by both executable name and Description

With a folder location to include, and an application to hook, the Application Group in the

personalization server can be created. Start by creating a new Application Group and naming it

“FileZilla Group”



Select the new (blank) application group, select the Applications tab, right click in the “Single

Applications” space and select Add Application > Select Application.

Select New… > By Name (Advanced).

Fill out the dialog shown with the application and executable name discovered in Task Manager, as

show below, and click OK when complete.

A new application will be created in the Database. Select this application and click OK. The application

will now be added to the Application Group.



Move on to the Registry tab. Even though there are no registry includes required for this application,

the default Excludes still need to be added manually, in order to counteract the Global Includes.

Add HKEY_CURRENT_USER\Software as a Registry Exclude.

Moving on to the Folders tab, the discovered directory in the user’s profile needs to be added as an

Include and the default Globally included directories need to be added as Excludes.

Create an include for {CSIDL_APPDATA}\FileZilla

The CSIDL variables are the Best Practice way of referencing common platform locations.

In this case, {CSIDL_APPDATA} references C:\Users\%username%\AppData\Roaming

Create excludes for {CSIDL_PROFILE}, {CSIDL_COMMON_FAVORITES}, {CSIDL_FAVORITES}and

{CSIDL_COMMON_APPDATA}



Again, the addition of these excludes needs to be done manually when building Application Groups

from scratch, but is done automatically when creating them via Data Collection.

The same testing and analysis procedure as used for Data Collection should be leveraged here, in

order to measure success and identify any missed inclusions.

5.3. Manual Analysis via ProcMon

Summary

ProcMon is a free Sysinternals tool from Microsoft. It’s a process analysis tool that reveals

all reads and writes coming from any running process as well as any child-processes

spawned by a run executable.

Benefits

An extremely granular analysis of an application’s actions during execution that will reveal

any application behaviour not immediately visible via system inspection or data collection

Requires no database or infrastructure setup, run on demand.

Drawbacks

Application analysis with ProcMon is a fairly manual process with a reasonably steep

learning curve. It does not scale well and is best suited to a mid to high level administrator

with local administrative access to an isolated, single user test machine.

Workflow

PuTTY is a common windows SSH and Telnet client and will be used for this example. While not

particularly guilty of storing its settings in strange locations outside the profile, because it’s parent

registry key is a largely unknown person’s name, it may be missed when running Data Collection or

in a manual Registry inspection.



The SysInternals utilities, of which ProcMon is a part, can be downloaded directly from Microsoft;

https://technet.microsoft.com/en-us/sysinternals/bb842062

Running ProcMon.exe as a user with elevated permissions is highly recommended. When ProcMon

is launched on the endpoint to be inspected, it will start immediately into capture mode. This

should be turned OFF as quickly as possible after launch in order to prevent hanging the system;

After Pausing capture, clear the existing results with the Erasure icon, as shown above.

On an average machine, ProcMon will capture over 1,000 events per second while running. This

creates quite a bit of data to sift through when using the default filters. Because Personalization

only deals in file and registry locations, the filter can be significantly changed in order to only target

those action types, and only for the application in question.

Click the Filters button;

In the Dialog that appears, there are a number of defaults – all of which should be removed with

the remove button.

A small number of new rules should be created in order to target this application, which is known

to be putty.exe. Configure the filters as shown below, using the drop-down menus, and clicking

“Add” after each one;

https://technet.microsoft.com/en-us/sysinternals/bb842062



Here we’ve specified the following

The Process Name whose actions to include is putty.exe

Include both File System and Registry Event Classes

Include only Write Category events, which will filter out any erroneous calls made by the

application

Click Apply, then OK. When ready, click the Capture button (that was used to pause initially) and

the event captured count at the bottom of the application will start to increment.

Once ProcMon is running the capture, immediately run the application in question (putty.exe) and

manipulate it as a user typically would. This should trigger a capture of any writes the application is



trying to make. Once actions in the application are complete, close the application and halt the

ProcMon capture by clicking the Capture button again.

In creating this example, over 400,000 events were generated by the PC, with about 250 matching

the filters set forth above. Chief among these, we can see numerous reads and writes to the

current user’s registry hive:

It appears that PuTTY is writing its data into an HKCU registry key under

Software\SimonTatham\PuTTY. A quick look at Regedit confirms that this is indeed the location

where saved sessions are stored;

The location HKCU\Software\SimonTatham\PuTTY can now be added as a Registry include for a

new Putty application group, following the same process as for the manual creation of the FileZilla

group above.

While not the case with PuTTY, many single-executable applications call child applications as part of

their normal operation. These child processes may make file and registry calls of their own, to

potentially different locations, making tracking down all the processes and locations for a complex

application challenging.



ProcMon can be leveraged again in this instance, this time as a tool to reveal all the child processes

created by a given application’s main executable. For a few reasons, a small freeware application

called Console2 will be used as an example here.

First, remove all existing filter rules in ProcMon filters, and create two new ones, as shown below;

With these filters in place, ProcMon capture is turned on and a Console2 launch and some actions

are captured.

As shown here explorer.exe (the windows shell) issues a process create for Console2.exe, which is

our main executable. Looking here, it’s seen that it is little more than a wrapper for the windows

command interpreter, cmd.exe and conhost.exe.

Taking it a few steps further, we can see that from this command prompt notepad.exe was

launched. Further after that, via a Common Dialog exploit launch, Notepad.exe was used to create

a child process, Regedit.



While this is a slightly convoluted example, it’s useful as a demonstration of the child/parent

process relationship and provides an executable list for further analysis.



6. Appendix A – Knowledge Base

If issues are encountered, please consult the Ivanti Support Knowledge Base for additional

information and best practice guidance.

The Knowledge Base is available at https://support.Ivanti.com

Be aware that in order to see all available KB articles and hotfixes, you will need to be logged in

with a valid support account, provided to all enterprise customers.

https://support.appsense.com/



7. Appendix B – Items to Ignore in Data Collection

The below table contains common areas that will appear in Data Collection results. It is very

uncommon for applications to actually store application data in these locations and they should be

discounted and not included in third party Application Personalization configuration.

Registry Keys to Ignore

HKCU\software\microsoft\windows\current version\explorer

HKCU\software\microsoft\windows\current version\shell extensions

HKCU\software\microsoft\internet explorer

HKCU\software\microsoft\windows\current version\internet settings

HKCU\software\microsoft\windows nt\current version\windows

Application Personalization Workflow

Documents

Transcript of Application Personalization Workflow