Product Documentation

Which applications?

Apr 24, 2013

The applications in use in your deployment affect how you configure Profile management. However, in contrast to the other configuration decisions you make, there are no simple yes-or-no recommendations because the decisions you take depend on where the applications store persistent customizations, which can either be in the registry or in the file system.

Analyze and understand your users' applications thoroughly to establish where the applications store their settings and users' customizations. Use a tool such as Procmon to monitor application binaries. Google is another resource. For information on Procmon, see http://technet.microsoft.com/en-gb/sysinternals/bb896645.

Once you understand how the applications behave, use inclusions to define which files and settings are processed by Profile management, and use exclusions to define which aren't. By default, everything in a profile is processed except for files in AppData\Local. If your deployment includes DropBox or Google Chrome, or applications created with the one-click publish in Visual Studio, you might need to explicitly include the subfolders of AppData\Local.

Simple applications

Simple applications are those that are well behaved; they store personalization settings in the HKCU registry hive and personalization files within the profile. Simple applications require basic synchronization and this in turn requires you to include and exclude items using:

  • Relative paths (relative to %USERPROFILE%) in any of the following policies:
    • Directories to synchronize
    • Files to synchronize
    • Exclusion list - directories
    • Exclusion list - files
    • Folders to mirror
    Note: %USERPROFILE% is implied by Profile management. Do not add it explicitly to these policies.
  • Registry-relative paths (that is, relative to the HKCU root) in either of these policies:
    • Exclusion list
    • Inclusion list

For instructions on including and excluding items, see To include and exclude items.

Legacy applications

Legacy applications are badly behaved; they store their personalization files in custom folders outside the profile. The recommended solution is not to use Profile management with legacy applications but instead to use the Personal vDisk feature of XenDesktop.

Complex applications

Complex applications require special treatment. The application's files can cross-reference each other and must be treated as an inter-related group. Profile management supports two behaviors associated with complex applications: cookie management and folder mirroring.

Cookie management in Internet Explorer is a special case of basic synchronization in which both of the following policies are always specified:
  • Process Internet cookie files on logoff
  • Folders to mirror

For information on folder mirroring, more information on cookie management, and instructions on setting these policies, see To manage cookie folders and other transactional folders.

Cross-platform applications

Cross-platform applications are those that may be hosted on multiple platforms. For specific versions of Internet Explorer and Microsoft Office, Profile management supports the sharing of personalization settings across platforms, whether the settings are stored in the registry or as files in the profile. Recommended policy settings for cross-platform applications are documented at Cross-platform settings - Case study.

If you want to share other applications' settings across platforms, Citrix recommends using Profile Migrator from Sepago.

Java and Web Applications

Java applications can leave many small files in a profile, which can dramatically reduce profile load times. To prevent this, consider excluding AppData\Roaming\Sun\Java.

Summary of policies

The following table summarizes the policies you use to configure Profile management for different types of applications. The following terms are used in the table:

  • Relative. This is a relative path on a local volume, relative to %USERPROFILE% (which must not be specified). Examples: AppData\Local\Microsoft\Office\Access.qat, AppData\Roaming\Adobe\.
  • Absolute. This is an absolute path on a local volume. Examples: C:\BadApp\*.txt, C:\BadApp\Database\info.db.
  • Registry Relative. This refers to a path within the HKCU hive. Examples: Software\Policies, Software\Adobe.
  • Flag. Flags are used to enable or disable processing where no path information is required. Examples: Enabled, Disabled.
Policy Policy Type (Registry, Folder, or File) Wildcard Support? Application Type
Simple Legacy Complex
Directories to synchronize Folder   Relative Absolute  
Files to synchronize File Yes Relative Absolute  
Exclusion list - directories Folder   Relative Absolute  
Exclusion list - files File Yes Relative Absolute  
Inclusion list Registry   Registry relative    
Exclusion list Registry   Registry relative    
Folders to Mirror Folder     Absolute Relative
Process Internet cookie files on logoff       Flag

Wildcard processing in file names

Policies that refer to files (rather than folders or registry entries) support wildcards. For more information, see Using wildcards.

Inclusion and exclusion rules

Profile management uses rules to include and exclude files, folders, and registry keys from user profiles in the user store. These rules result in sensible and intuitive behavior; all items are included by default. From that starting point, you can configure top-level exceptions as exclusions, then configure deeper exceptions to the top-level exceptions as inclusions, and so on. For more information on the rules, including instructions on including and excluding items, see To include and exclude items.

Non-English folder names in profiles

For non-English systems that use Version 1 profiles, specify relative paths in inclusion and exclusion lists in the local language (for example, on a German system use Dokumenten not Documents). If you support multiple locales, add each included or excluded item in each language.

Next steps

Important: This topic describes the last of the questions that you must answer in order to configure your Profile management deployment. (The questions are listed in Decide on a configuration.) Once you have answered all of the questions and have configured the settings accordingly, you are ready to review the configuration and go live as described in Review, test, and activate Profile management. You can leave all other policies in their default setting. This includes some policies that you should not configure; for a list of these, see Policies not requiring configuration.