Profile Management 4.x

Profile Management 4.x
2015-03-16 20:51:57 UTC
© 2015 Citrix Systems, Inc. All rights reserved. Terms of Use | Trademarks | Privacy Statement
Contents
Profile Management 4.x .....................................................................................
6
Get Started........................................................................................
7
About Profiles ...............................................................................
9
Assigning Profiles ......................................................................
11
General Recommendations for Profiles .................................................
13
Profile Management Use Cases ...........................................................
14
Accessing Multiple Resources .............................................................
17
About Profile Management 4.x .................................................................
18
What's New in Profile Management 4.x..................................................
19
Existing Features of Profile Management ...............................................
21
How Profile Management Works..........................................................
22
Known Issues in Profile Management 4.x................................................
23
History of Changes ...............................................................................
25
Most Read Topics.................................................................................
26
System Requirements............................................................................
27
Plan.................................................................................................
30
Decide on a configuration .................................................................
31
Pilot? Production? .....................................................................
32
Migrate profiles? New profiles?......................................................
34
Persistent? Provisioned? Dedicated? Shared?......................................
35
Mobile? Static? .........................................................................
37
Which applications? ...................................................................
39
Reviewing, Testing, and Activating Profile Management .......................
43
Planning for Multiple Platforms ..........................................................
44
What Types of Profiles Should I Create? ...........................................
46
Sharing Citrix User Profiles on Multiple File Servers ..................................
47
Administering Profiles Within and Across OUs .........................................
49
Domain and Forest Support in Profile Management ...................................
51
High Availability and Disaster Recovery with Profile Management .................
52
2
3
Scenario 1 - Basic Setup of Geographically Adjacent User Stores and
Failover Clusters.......................................................................
53
Scenario 2 - Multiple folder targets and replication .............................
57
Scenario 3 - Disaster Recovery ......................................................
59
Scenario 4 - The Traveling User.....................................................
61
Scenario 5 - Load-Balancing User Stores...........................................
62
Planning Folder Redirection with Profile Management ...............................
64
Third-Party Directory, Authentication, and File Services ............................
65
Frequently Asked Questions About Using Profiles On Multiple Platforms ..........
66
Profiles on Multiple Platforms.......................................................
67
Migrating Profiles......................................................................
70
Troubleshoot ......................................................................................
71
Basic Troubleshooting Checklist ..........................................................
74
Profile Management Log Files.............................................................
75
Events Logged by Profile Management ..................................................
77
Log File Checklist ...........................................................................
83
Advanced Troubleshooting of Log Files .................................................
84
Specific Troubleshooting Information ...................................................
86
Collecting Diagnostic Information........................................................
92
Other Troubleshooting Steps..............................................................
94
Contacting Citrix Technical Support .....................................................
95
Secure..............................................................................................
96
Profile Streaming and Enterprise Antivirus Products..................................
98
Install and Set Up ................................................................................
100
Files Included in the Download ...........................................................
104
Creating the User Store....................................................................
105
Testing Profile Management with a Local GPO.........................................
107
To remove Profile management ..........................................................
109
Upgrade and Migrate ............................................................................
110
Upgrading Profile Management ...........................................................
113
Considerations When Upgrading .Ini Files...............................................
115
Frequenly Asked Questions About Upgrading...........................................
116
To migrate user profiles ...................................................................
118
Manage.............................................................................................
120
Configuration Precedence .................................................................
121
To choose a migration policy .............................................................
122
To specify a template profile.............................................................
123
To resolve conflicting profiles ............................................................
125
4
To enable Profile management...........................................................
126
About Profile Management .Ini Files.....................................................
127
Including and Excluding Items ............................................................
129
Default Inclusions and Exclusions ...................................................
132
To include and exclude items .......................................................
135
Using Wildcards........................................................................
138
Combining Inclusions and Exclusions ...............................................
139
To specify the path to the user store ...................................................
142
To define which groups' profiles are processed ........................................
144
To store certificates .......................................................................
145
To stream user profiles ....................................................................
146
To configure active write back ...........................................................
148
To configure Profile management for folder redirection.............................
149
To manage cookie folders and other transactional folders ..........................
150
To configure offline profiles ..............................................................
152
To configure cross-platform settings ....................................................
154
Cross-Platform Settings - Case Study ....................................................
157
Initial Configuration ..................................................................
158
Planning the New Site ................................................................
160
Executing the Plan ....................................................................
161
Other Considerations .................................................................
166
Integrate...........................................................................................
167
Profile Management and XenApp.........................................................
168
Profile Management and XenDesktop....................................................
169
Example Settings for XenDesktop...................................................
170
Profile Management and VDI-in-a-Box ...................................................
173
Profile Management and ShareFile.......................................................
174
Profile Manager and App-V ................................................................
176
Profile management and Provisioning Services ........................................
177
To retrieve log files from vDisk images ............................................
178
To preconfigure Profile management on provisioned images........................
180
Profile Management and Self-service Plug-in ..........................................
182
Profile Management and VMWare ........................................................
183
Profile Management and Microsoft Outlook ............................................
184
Using Windows Profiles With Citrix Password Manager ...............................
185
Reference .........................................................................................
189
Profile Management Policies ..............................................................
190
5
Profile Management Policy Descriptions and Defaults ................................
194
Profile Management Architecture ........................................................
195
Operating Systems and Applications Supported By Cross-Platform Settings.......
199
Logon Diagram ..............................................................................
201
Logoff Diagram ..............................................................................
203
Glossary............................................................................................
205
Profile Management 4.x
In This Section
These topics contain up-to-date information about installing, configuring, and administering
Profile management 4.x. These task-based topics help you set up the feature quickly and
easily. You are assumed to have some knowledge of the Citrix product with which Profile
management ships, and of Windows profiles in general.
Learn about the following important topics.
Getting Started
Learn about Windows profiles, decide whether Profile
management is right for you, and find out how to put it
into production.
About Version 4.x
Get an overview of how Profile management works and
answers to frequently asked questions about this
component. Review the new features and check known
issues.
System Requirements
Ensure your environment meets all the requirements
before you install Profile management.
Planning
Plan your deployment of Profile management. Get
answers to frequently asked questions about making
profiles work on multiple platforms.
Upgrades
Read important information about upgrades and get
answers to frequently asked questions on this subject.
Troubleshooting
Find solutions to implementation issues.
XenApp and XenDesktop
Review important information about XenApp and
XenDesktop deployments involving Profile
management.
The following additional documentation is designed to increase your productivity but is not
contained in eDocs.
6
Frequently asked questions about troubleshooting
CTX119038
Frequently asked questions about licensing
CTX119747
Answers from experts to many questions about Profile
management deployments
http://community.citrix.c
om/blogs
Getting Started with Profile Management
The topics in this section of eDocs introduce you to Windows profiles. If you are new to
Citrix Profile management, this section helps you decide whether this component is suitable
for your organization and, if so, how to evaluate it.
This section also tells you how to put Profile management into production and how to
troubleshoot problems with it.
Why do I need a profile solution?
To understand what profiles are and how they benefit users, read the topic called About
Profiles.
Why is Profile management right for me?
To work out if Profile management is a viable solution in your organization, read the
following topics:
•
General Recommendations for Profiles
•
Profile Management Use Cases
•
Accessing Multiple Resources
You may also want to review the new and existing features in this release.
How do I evaluate Profile management with
XenDesktop?
You can test Profile management with Citrix XenDesktop Quick Deploy. To get started with
this task, see Group computers into OUs.
How do I set up Profile management in production?
By answering a simple set of questions, you can configure Profile management to suit your
deployment's specific needs. This allows you to set up the software quickly in a
recommended configuration. To start configuring the software this way, read Decide on a
configuration.
7
Get Started
How do I troubleshoot Profile management problems?
For comprehensive troubleshooting information, see Troubleshooting Profile Management.
8
About Profiles
A Windows user profile is a collection of folders, files, registry settings, and configuration
settings that define the environment for a user who logs on with a particular user account.
These settings may be customizable by the user, depending on the administrative
configuration. Examples of settings that can be customized are:
•
Desktop settings such as wallpaper and screen saver
•
Shortcuts and Start menu setting
•
Internet Explorer Favorites and Home Page
•
Microsoft Outlook signature
•
Printers
Some user settings and data can be redirected by means of folder redirection. However, if
folder redirection is not used these settings are stored within the user profile.
Types of Profiles
Windows includes several types of profiles:
Profile Type
Storage
Location
Configuration
Location
Application
Save Changes?
Local
Local device
Local device
Local device
only
Yes
Roaming
Network
Active Directory
Any device
accessed
Yes
Mandatory
Network
Active Directory
Any device
accessed
No
Not Applicable
Not Applicable
(Mandatory
Roaming)
Temporary
Local device
No
only
A temporary profile is only assigned when a specific profile type cannot be assigned. With
the exception of mandatory profiles, a distinct profile typically exists for each user. In
addition, mandatory profiles do not allow users to save any customizations.
For Remote Desktop Services users, a specific roaming or mandatory profile can be assigned
to avoid issues that may occur if the same profile is assigned to a user within a Remote
Desktop Services session and a local session.
9
About Profiles
Version 1 and Version 2 Profiles
Profiles in Microsoft Windows XP and Windows Server 2003 are known as Version 1 profiles.
Those in Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2 are
known as Version 2 profiles. The folder structure (or namespace) of Version 1 profiles is
mostly interchangeable; the folders on Windows XP and Windows Server 2003 are almost
identical. Likewise, the structure of Version 2 profiles is mostly interchangeable.
However, the namespace is different between Version 1 and Version 2 profiles. This folder
structure was changed in the later operating systems to provide user-specific folders
isolated for user and application data. Version 1 profiles store data in the root folder,
Documents and Settings. Version 2 profiles store data in a more intuitively named folder
called Users. For example, the folder contents of AppData\Local in Windows Vista is the
same as the contents of Documents and Settings\<username>\Local Settings\Application
Data in Windows XP.
For more information about the differences between Version 1 and Version 2 profiles, seeht
tp://download.microsoft.com/download/3/b/a/3ba6d659-6e39-4cd7-b3a2-9c96482f5353/M
anaging%20Roaming%20User%20Data%20Deployment%20Guide.doc
10
Assigning Profiles
What methods can I use in Windows to assign profiles
to users?
This topic refers to the assignment of profiles in Microsoft Windows not Citrix Profile
management.
You can assign profiles to users in several ways:
•
Using their user account properties in Active Directory (AD)
•
Using Group Policy (GP)
•
Using the above methods to assign profiles specific to Remote Desktop Services
(formerly known as Terminal Services) sessions
Some of these methods are only available in specific operating systems:
•
Remote Desktop Services. To assign Remote Desktop Services profiles on Windows
Server 2008 R2, use the GPO setting Set path for Remote Desktop Services Roaming User
Profile, which is located in Computer Configuration\Administrative Templates\Windows
Component\Remote Desktop Services\Remote Desktop Session Host\Profiles. On earlier
server operating systems, use the setting Set path for TS Roaming Profiles, which is
located in Computer Configuration\Administrative Templates\Windows
Components\Terminal Services.
To configure profiles for individual users, you can also set Set path for TS Roaming
Profiles on the individual accounts in the User Account Properties pages in AD.
However, typically it is much better to make this assignment in GP.
You can use the setting Use mandatory profiles on the terminal server to force the use
of mandatory profiles.
•
Windows XP and Windows 7: Set roaming profiles on individual accounts using the User
Account Properties pages. Additionally, for Windows Server 2008 AD and Windows 7
devices, you can use the GPO setting Set roaming profile path for all users logging onto
this computer. This is located in Computer\Administrative Templates\System\User
Profiles.
What is the priority order for delivering profiles to
domain users if more than one method is used?
When Profile management is used to manage a user's profile, it takes precedence over any
other profile assignment method. A user whose profile data is not managed by Profile
management might be assigned a profile using multiple methods. The actual profile used is
based on the following precedence:
11
Assigning Profiles
1. Citrix user profile (that is, a profile created by Profile management)
2. Remote Desktop Services profile assigned by a GPO
3. Remote Desktop Services profile assigned by a User Property
4. Roaming profile assigned by a GPO (Windows Server 2008 AD and Windows 7 only)
5. Roaming profile assigned by a User Property
12
General Recommendations for Profiles
Where network-based profiles are employed, consider adopting Profile management in your
organization. You may be able to implement other solutions such as mandatory or roaming
profiles, and maintain them with standard knowledge of Microsoft Windows. However,
unless your deployment is very restricted (for example, a call center where user
customization is very limited so mandatory profiles are appropriate), Profile management
may be preferred.
Citrix recommends using folder redirection so that user-specific data is saved separately
from the profile.
13
Profile Management Use Cases
Citrix Profile management can be implemented to manage users' profiles in different
scenarios regardless of how applications are delivered to users or where they are housed.
The following are examples of these scenarios:
•
Citrix XenApp with published applications
•
Citrix XenApp with published desktops
•
Citrix XenApp with applications streamed into an isolation environment
•
Applications streamed to XenDesktop virtual desktops
•
Applications installed on XenDesktop virtual desktops
•
Applications streamed to physical desktops
•
Applications installed locally on physical desktops
Of these, Citrix sees the following as the most common use cases:
•
Multiple sessions. The user accesses multiple XenApp server silos and therefore has
multiple sessions open. Note however that application isolation and streaming on the
server are alternatives to server silos. This scenario is described in more detail in this
topic.
•
"Last write wins" and roaming profile consistency issues. Because the last write to
the roaming profile causes all settings to be saved, roaming profiles may not retain the
right data if multiple sessions are open and interim changes are made. In addition,
settings may not be written correctly to the profile as a result of network, storage
issues, or other problems. This scenario is described in more detail in this topic.
•
Large profiles and logon speed. Profile bloat can make user profiles unwieldy resulting
in storage and management issues. Typically, during logon Windows copies the user's
entire profile over the network to the local user device. For bloated profiles, this can
prolong the user's logon time.
Multiple Sessions
Especially in large environments, it may be necessary for users to open multiple sessions to
access different applications that are housed on different XenApp servers, whether in the
same farm or multiple farms. Where possible, Citrix administrators should consider
application isolation or streaming in order to house applications on the same XenApp server
to allow users to access all applications from a single server and thus a single session.
However, this may not be possible if a business unit controls specific servers or applications
cannot be streamed.
Once it has been determined that it is indeed necessary for users to access applications
from various XenApp servers, the impact on profiles should be ascertained.
14
Profile Management Use Cases
This diagram illustrates the example below, where application settings may be lost when
multiple sessions exist.
For example, Mary has the need to access AppA, AppB, and AppC and she is routed to
Server 1, Server 8, and Server 12 respectively. Upon logon to each application, her
Terminal Services roaming profile is loaded onto each server and folders are redirected for
each session. When she is logged onto AppA on Server1, Mary changes Setting1 and logs off
that session. She then completes her work in the other two applications and logs off.
At logoff, the change that Mary made within her session on Server 1 is overwritten because
the settings within the last closed session are retained, not the interim change. When Mary
logs onto AppA the next day, she is frustrated because the change she made is not visible.
Profile management can generally prevent this situation from occurring. Profile
management only writes back the specific settings that were changed during a session; all
other unchanged settings remain untouched. So the only potential conflict that would arise
is if Mary changed Setting1 within another session. However, the user would likely expect
that the most recent change was retained, which is the case, if Profile management is used
in this scenario.
"Last Write Wins" and Roaming Profile Consistency
Issues
This scenario is similar to the first one in this topic. "Last write wins" issues can present
themselves in a variety of ways, and user frustration can mount as the number of devices
accessed increases.
15
Profile Management Use Cases
Because the roaming profile retains all profile data, with the exception of folders that have
been redirected, the user profile can grow quite large. Not only does this add to the logon
time because the profile must be downloaded, the potential for inconsistency grows during
the write phase of the logoff, especially where network issues exist.
Profile management enables specific data to be excluded from the user profile, enabling
the user profile to be kept to a minimal size. Because only differences are written to the
profile, the write phase of the logoff involves less data and is faster. Profile management
can be beneficial for applications that use profiles for temporary data but do not clean
them up when the applications terminate.
16
Accessing Multiple Resources
Profiles become more complex as users access multiple resources. With profiles stored on a
network, Microsoft Windows uses the registry to store user settings. Profiles are copied
from the network to the local device at logon, and copied back to the network at logoff. On
a daily basis, users access multiple computers, switch between desktops and laptops, and
access virtual resources created with Citrix XenDesktop and Citrix XenApp.
This diagram illustrates how a single Citrix user profile follows a user who logs on to
multiple resources.
For example, a user has a local, physical desktop and from it accesses applications
published with XenApp. They also access a virtual desktop created with XenDesktop. The
user's settings will not be uniform across all of these resources unless the settings are
appropriately configured.
In addition, when they access a shared resource, the behavior of roaming profiles means
that the "last write wins". For example, an administrator enables a roaming profile and a
user changes the background color of the local desktop. The user then logs on to a
XenDesktop virtual desktop, logs off the local desktop, and logs off the virtual desktop.
Because both the local and virtual desktops were open at the same time and the last logoff
was from the virtual desktop, the settings from the virtual desktop session were the last
written to the profile, and the change to the background color is lost.
17
About Profile Management 4.x
Profile management is intended as a profile solution for XenApp servers, virtual desktops
created with XenDesktop, and physical desktops. You install Profile management on each
computer whose profiles you want to manage.
Active Directory Group Policy Objects allow you to control how Citrix user profiles behave.
Although many settings can be adjusted, in general you only need to configure a subset, as
described in these topics.
The best way of choosing the right set of policy selections to suit your deployment is to
answer the questions in the topic called Decide on a configuration.
Usage rights for this feature are described in the end-user license agreement (EULA).
For information on the terminology used in these topics, see Profile Management Glossary.
18
What's New in Profile Management 4.x
Version 4.1.5
This release includes the following issues fixed since Version 4.1.2 was released:
•
File downloads fail in Internet Explorer when Protected Mode and User Access Control
(UAC) are enabled. Additionally, Profile management sets write-only permissions on
HKEY_CURRENT_USER\Software\Policies. [#LA4764]
•
Attempts to download files using Versions 9, 10, and 11 of Microsoft Internet Explorer
fail if Protected Mode and UAC are enabled. [#LA4814]
Version 4.1.2
This version includes issues fixed since Version 4.1.1 was released. For the list of fixed
issues, see CTX134616.
Version 4.1.1
This version includes issues fixed since Version 4.1 was released. For the list of fixed issues,
see CTX133528.
Version 4.1
This version includes issues fixed since Version 4.0 was released. For the list of fixed issues,
see CTX124164. In addition, this version includes the following new key features:
19
•
Support for personal vDisk - This XenDesktop feature is a personalization solution for
pooled-static virtual desktops. If the feature is enabled, XenDesktop adjusts the Profile
management configuration so that profile data is written to and read from the personal
vDisk.
•
Group Policy enhancement - Profile management comes with an .admx file that
contains all of the same settings as the .adm file, which is still supplied. For more
information on .admx files, see your Group Policy documentation.
•
Simplified default inclusions and exclusions - The list of files and folders that are
included in and excluded from Profile management processing has been revised to
support some newer, commonly used applications. For example, the generic exclusions
for Local Settings or AppData\Local in previous versions are replaced with lower-level,
more specific exclusions by default.
What's New in Profile Management 4.x
Version 4.0
This version includes issues fixed since Version 3.0 was released. For the list of fixed issues,
see CTX124164. In addition, this version includes the following new key features:
•
Offline profiles - This feature is aimed at laptop and mobile device users who roam.
Citrix offline profiles have minimal configuration and reduce disruption when network
connections are lost by caching files locally until the network (and therefore the user
store) is available again. This feature works with domain-joined computers only.
•
Cross-platform settings - For several common applications, this feature allows you to
migrate users' profiles and to roam them when the users connect to the same
application running on multiple operating systems. Without this feature, if users
connect to an application that creates a Version 1 profile on one platform and a Version
2 profile on another, they would have to duplicate the application's settings. For
information on these profile types, see Version 1 and Version 2 Profiles.
With this feature, users avoid duplicate settings. Common files and registry settings are
identified, grouped together, and stored in the cross-platform settings store. When the
user switches platforms, Profile management fetches the common items for the
appropriate platform from this location (in addition to any platform-specific files and
settings from the user store) so the user gets the same experience on both platforms.
For a list of the applications and operating systems supported by this feature, see
Operating Systems and Applications Supported By Cross-Platform Settings.
20
•
Support for prelaunched applications - The Session Prelaunch feature in Citrix XenApp
enhances the launching of published applications by starting a session automatically
when a user logs on to a farm. No configuration of Profile management is required.
•
Localization - The English version of Profile management is supported on Traditional
Chinese, Korean, and Russian operating systems.
•
Diagnostics - The name of the computer is included in the log file name, which
facilitates troubleshooting.
•
Built-in variables - In some settings, you can use specific variables to describe the
profile version, the operating system, and its bitness.
Existing Features of Profile Management
Profile management 4.x includes the following major features from previous releases:
21
•
Support for folder redirection. This feature allows you to avoid duplicate items in
local profiles when folder redirection is used. In addition, Profile management can
mirror folders, allowing the correct processing of transactional folders. For example,
mirroring the Internet Explorer cookies folder means that index.dat is synchronized only
with the latest version of the cookies that it references, not earlier versions that are no
longer required. Without mirroring, multiple copies of the referenced files (cookies
from multiple sessions, for example) can cause profile bloat.
•
Deleting stale cookies. Profiles in some deployments can become bloated with stale
browser cookies when Web sites are revisited. A setting in the ADM file can be used to
delete the stale files.
•
Citrix streamed user profiles. This feature offers alternative options for speeding up
logons and logoffs by fetching parts of users' profiles from the user store only when they
are needed. One of the options is to use the cache entire profile feature, which
fetches all of the files but staggers their delivery in the background.
•
Active write back (formerly Active profile write back). To improve profile integrity if
sessions terminate abnormally, files that are modified on the local computer can be
backed up to the user store during a session, before logoff. This is particularly useful in
Citrix XenDesktop deployments, where a user might otherwise leave their session open
for a long period without local file changes in their profile being mirrored in the user
store.
•
Diagnostics. Profile management is integrated with Performance Monitor (Perfmon),
allowing you to measure several aspects of logon and logoff, a subset of data from the
log files, and streamed user profile performance. Perfmon counters are integrated with
Citrix EdgeSight. No configuration of Perfmon is required to use the counters, and you
do not need to be a full administrator on the computer used to manage Profile
management. You can also create trace logs with Citrix Diagnostic Facility in the event
of advanced troubleshooting initiated by Citrix Technical Support.
•
Localization. The Profile management software and documentation are localized into
French, German, Spanish, Japanese, and Simplified Chinese.
•
Profile migration. Allows you to migrate profiles to and from physical computers and
virtual ones. Depending on the configuration settings, Profile management can copy
existing roaming profiles and local Windows profiles to the user store. Existing
mandatory profiles can be used as the basis for Citrix user profiles when saved as a
template.
•
Consistent user settings. Solves the "last-write-wins" problem that occurs when the last
open session overwrites all of the profile data from previously closed sessions.
•
Easy integration. Profile management can be integrated easily into existing
deployments. No new infrastructure or changes to logon and logoff scripts are required.
How Profile Management Works
Profile management addresses user profile deficiencies in environments where simultaneous
domain logons by the same user introduce complexities and consistency issues to the
profile. For example, if a user starts sessions to two different virtual resources based on a
roaming profile, the profile of the session that terminates last overrides the profile of the
first session. This problem, known as "last write wins", discards any personalization settings
that the user makes in the first session.
You can tackle the problem by using separate profiles for each resource silo. However, this
results in increased administration overhead and storage capacity requirements. Another
drawback is that users will experience different settings depending on the resource silo
they access.
Profile management optimizes profiles in an easy and reliable way. At interim stages and at
logoff, registry changes, as well as files and folders in the profile, are saved to the user
store for each user. If, as is common, a file already exists, it is overwritten if it has an
earlier time stamp.
At logon, users' registry entries and files are copied from the user store. If a locally cached
profile exists, the two sets are synchronized. This makes all settings for all applications and
silos available during the session and it is no longer necessary to maintain a separate user
profile for each silo. Citrix streamed user profiles can further enhance logon times.
Profile management helps to safeguard application settings for mobile users who
experience network disruption (if the offline profiles features is configured) and users who
access resources from different operating systems (if the cross-platform settings feature is
configured).
Note: Profile management processes domain user logons not local accounts.
For a more detailed overview of Profile management, search the Profile management blog
at http://blogs.citrix.com/tag/user_profile_manager.
22
Known Issues in Profile Management 4.x
Version 4.1
The following known issues exist in this version:
There is an issue when Microsoft Windows Automated Installation Kit (WAIK) is used with
System Preparation Tool (Sysprep) to create a template profile for use with Profile
management. If you use WAIK to create an unattend.xml file in which CopyProfile is set to
true, Sysprep modifies the default profile in a way that makes it unusable as a template
profile. The workaround for this issue is to use alternative tools to prepare template
profiles. [0269480]
When used with the personal vDisk feature of XenDesktop, profile changes resulting from
installing Dropbox in one Profile management session are not retained in later sessions; the
Dropbox installer restarts in each new session. There is no workaround for this issue.
[#0269775]
Occasionally, a Citrix user profile can take up to five minutes to load if there is a delay
between the client impersonation thread and the session count thread. The Profile
management log file shows a long delay between these two threads:
•
2011-10-06;23:09:43.663;INFORMATION;domain;username;1;3992;ImpersonateClientSto
p: Successfully stopped client impersonation.
•
2011-10-06;23:14:15.568;INFORMATION;domain;username;1;3992;SessionCount:RealTim
eCount: Detected a Client OS, not using WTS calls.
Citrix continues to investigate the cause of this issue. [#0270130]
An intermittent issue can break folder redirection. This has been observed in a
medium-sized XenApp deployment, and may result from the blocking of inherited policies
by local profile folders and redirected folders. Folder redirection functions correctly for
approximately one week but then occasionally stops for the same period before functioning
correctly again. This issue is occasional but repeatable, and there is no workaround for it.
[#0273327]
An intermittent issue occurs on computers running Windows Server 2003 32-bit edition in
XenApp 6 environments. These computers sometimes stop processing logons. The cause of
this issue is unknown but you can identify it by the presence of ghost UserInit processes in
the session dump file. There is no workaround for this issue. [#0285271]
If your deployment includes personal vDisks (a XenDesktop feature), users may receive
temporary profiles if the default processing of these disks has not been correctly adjusted.
To workaround this issue, see To migrate user profiles. [#0284347]
The default setting of Local profile conflict handling does not work for virtual desktops
created with personal vDisks (a XenDesktop feature). If a Citrix user profile is present in the
user store and a local Windows user profile is also present on the desktop, the local profile
should be, but is not, processed by Profile management with the default setting (Not
Configured). To work around this issue, set the policy to Rename local profile. [#0285501]
23
Known Issues in Profile Management 4.x
Version 4.0
The following known issues exist in this version.
With the cross-platform settings feature configured, your Windows XP wallpaper should be
displayed when you roam from Windows XP to Windows 7, but instead the default Windows
7 desktop wallpaper is displayed when you first log on to that operating system. To work
around this issue, reset your wallpaper after you first log on to Windows 7. Subsequent
changes to the wallpaper are preserved and roamed when you next log on. [#27210]
With the cross-platform settings feature configured, the checkbox Prevent programs from
suggesting changes to my default search provider (a search setting) in Internet Explorer 8
can be selected on Windows XP but the selection is not displayed when you roam to
Windows 7. There is no workaround for this issue. [#33796]
If you upgrade Profile management on a computer when a user is logged on to it, the
upgrade fails and data in monitoring systems (for example, Perfmon counters) might
become unreliable. Always follow the documented upgrade procedure by ensuring all users
are logged off first. [#35098]
Occasionally, when a user logs off from a computer, a stale profile folder with a
domain-name suffix is created locally. This issue occurs even if Delete locally cached
profile is enabled. For example, the folder C:\Users\folder-name becomes
C:\Users\folder-name.domain-name. The issue may affect XenApp users and XenDesktop
users with persistent virtual desktops but not those with pooled desktops. To work around
the issue, delete all stale cached profiles from the system. [#47933]
Users may experience no wallpaper (a black background to their desktops) in two scenarios.
Each has a different workaround. In the first scenario, a stale profile results in the same
symptoms as issue #47933 but additionally no wallpaper is displayed. In this scenario, the
same workaround for that issue can be employed. In the second scenario, which occurs only
on Windows XP, there is no stale profile but users still experience no wallpaper because the
required image file is not processed by Profile management. To work around the issue in
this scenario, include the entry Application Data\Microsoft\*.BMP in the Files to synchronize
policy. [#47935]
If you misconfigure the Folders to mirror policy, the system may inadvertently delete user
data in the user store the second time this policy is applied. For example, if you add the
same path twice or add two subfolders of the same parent folder. To avoid this issue,
configure the policy according to the Profile management documentation. [#157322]
If the Path to user store policy contains a trailing space, the specified folder in the user
store has no owner (on the Security tab of the folder's Properties dialog box) and is
therefore unusable. To workaround this issue, remove the trailing space and run a
gpupdate. [#246793]
24
History of Changes to Profile
Management 4.x Documentation
This topic records the significant updates that have been made in this release of the Profile
management documentation. These include the addition of new information, the correction
of ambiguities, and so on. Minor updates (such as typographical corrections, the
reorganization of existing topics, or the addition of links to other documents) are not listed.
Tip: For a list of the most popular topics on administering Profile management, see Most
Read Topics for Profile Management.
Date
New or Updated Content
24 August 2011
Release of Version 4.0
8 September 2011
Profile Management and Self-service Plug-in
14 October 2011
Including and Excluding Items
30 November 2011
Profile Management Architecture
9 March 2012
Release of Version 4.1
15 May 2012
What's New in Profile Management 4.x
: Simplified default inclusions and exclusions
Known Issues in Profile Management 4.x: Description of #0270130
Profile Management and VDI-in-a-Box
6 August 2012
Server or workstation?
17 September 2012
Decide on a configuration: UPMConfigCheck
19 September 2012
Collecting Diagnostic Information: CDFControl
22 April 2013
Profile Management and ShareFile
Profile Manager and App-V
24 April 2013
25
Decide on a configuration
Most Read Topics for Profile
Management
These topics are those that are currently most read by users of Profile management:
26
•
Getting started
•
Use cases
•
General recommendations
•
System requirements
•
Deciding on a configuration
•
Installing and setting up
•
Creating the user store
•
Files included in the download
System Requirements for Profile
Management
Software Requirements
Systems running Profile management must be based on one of the following operating
systems as a minimum:
•
Desktops. Microsoft Windows XP Service Pack 3, Windows Vista Service Pack 1, or
Windows 7
•
Servers. Standard, Enterprise, and Datacenter Editions of: Windows Server 2003 Service
Pack 2 and Windows Server 2008 (including Windows Server 2008 R2)
Every user should have access to the user store, a network folder where profiles are stored
centrally. Alternatively, profiles can be stored in users' home drives if preferred. For more
information, see Profile Management Architecture.
Active Directory (AD) Group Policy Objects (GPOs) are used for configuration. AD forest
functional and domain functional levels of Windows Server 2003 native mode and above are
supported. For more information, see Domain and Forest Support in Profile Management.
Alternatively, local .ini files may be used for configuration settings, but in general the .ini
files should be used for testing purposes only. Note that settings in the .ini files are applied
for any setting not configured in the GPO, that is any Group Policy setting that is left in the
Not Configured state.
If you are planning to use AD to deploy the installer, upgrade any domain controllers
running the 64-bit edition of Windows Server 2003 Service Pack 1 to Service Pack 2 if you
use them to store the Profile management ADM file. You do not have to upgrade the 32-bit
edition.
If short file names (also known as 8.3 file names) are mandated in a Citrix product or
component you are using with Profile management, do not turn off support for short file
names in your Profile management deployment. Doing so may cause issues when files are
copied to and from the user store.
On computers running the Profile Management Service, store profiles on a single disk
mounted by drive letter. If a disk is mounted into a folder that is used to store a user's
profile (a typical example is C:\Users), it might be masked from the Service and not
processed.
Downloads
Profile management 4.x can be used with these Citrix products:
•
27
XenDesktop
System Requirements
•
XenApp
•
VDI-in-a-Box
To download Profile management
1. Navigate to the Citrix download pages.
2. Log on to My Account. Your account must be associated with the licensing entitlement
for the Citrix product that you have deployed. If your account is not associated with
your license entitlement, contact Citrix Customer Service.
3. In Find Downloads, select your product and select Components as the download type.
4. Download the latest version of Profile management.
Installations on Windows XP and Windows Server
2003
Important: In addition to meeting the other system requirements in this topic, ensure the
updates described in Microsoft Security Bulletin MS09-012 are installed on all computers
that will run Profile management. The updates are included in recent operating systems;
but they may have to be applied manually to others. The updates are critical for Windows
XP and Windows Server 2003 but should also be applied to any other supported operating
system. For information about the updates, see
http://technet.microsoft.com/en-us/security/bulletin/MS09-012.
If you do not apply the updates, Profile management installation ends prematurely and no
components are installed.
Diagnostics Feature
Before you can use Citrix Diagnostic Facility to capture trace logs, ensure it is available
with the Citrix product or component that is used on the device, virtual desktop, or Citrix
server whose profiles you want to monitor.
Application Streaming
If you use Citrix XenApp to stream applications to user devices, install the Citrix offline
plug-in (formerly called XenApp Plug-in for Streamed Apps) 1.3.1 or later on user devices.
Version 1.2 of this plug-in changed the location of per-user disk storage for streamed
application settings, resulting in user preferences being lost at logoff. With Version 1.3.1 or
later, these settings are stored in %LOCALAPPDATA%, and follow the user from device to
device without data loss. No configuration of Profile management is required with this later
version of the plug-in.
Although it is unsupported, if you must use XenApp Plugin for Streamed Apps 1.2 see
CTX120006 for a workaround to the data-loss issue.
28
System Requirements
Cross-Platform Settings
To use the cross-platform settings feature in this release, Microsoft Core XML Services
(MSXML) 6.0 Service Pack 1 or later must be installed on all computers running the Profile
Management Service. This component is part of Microsoft .NET Framework 3.5 and is
required in order to process definition files. For more information on MSXML 6.0 Service
Pack 1, including its system requirements, see http://www.microsoft.com/downloads/en/d
etails.aspx?FamilyID=d21c292c-368b-4ce1-9dab-3e9827b70604&displaylang=en.
Use this feature only with the supported set of operating systems and applications. For
more information, see Operating Systems and Applications Supported By Cross-Platform
Settings.
Migrating Existing Profiles to Citrix User Profiles
Migration from the following profile types to Citrix user profiles is supported:
•
Windows roaming profiles
•
Local profiles based on any of the following operating systems:
•
•
Windows XP
•
Windows Vista
•
Windows 7
•
Windows Server 2003
•
Windows Server 2008
•
Windows Server 2008 R2
Citrix user profiles created with User Profile Manager 2.0
Migration from the following profile types to Profile management 4.0 is unsupported:
•
Mandatory profiles.
Tip: If you want to use mandatory profiles as the basis for your Citrix user profiles,
first rename them and then configure them in Profile management as template
profiles. There is no direct way of converting a mandatory profile to a Citrix user
profile. For information on template profiles, see To specify a template profile.
•
Citrix user profiles created with a User Profile Manager Technical Preview release or
beta release
•
Third-party profiles (including sepagoPROFILEs)
You cannot upgrade from a 32-bit Citrix user profile to a 64-bit one.
29
Planning Your Profile Management
Deployment
The first stage in planning a Profile management deployment is to decide on a set of policy
settings that together form a configuration that is suitable for your environment and users.
As a guide to carrying out this important task, see Decide on a configuration.
Having decided on a configuration, and reviewed and tested it, a typical deployment then
consists of:
1. Creating the user store
2. Installing Profile management
3. Enabling Profile management
Planning a Pilot Study With an .Ini File
The following information is intended to assist you using one of the Profile management .ini
files during a pilot study or evaluation.
Important: If you intend to use one of the .ini files (for example,
UPMPolicyDefaults_V1Profile_en.ini) for evaluation purposes, rename the file (for
example, to UPMPolicyDefaults_V1Profile_en.old) before you switch to using Group Policy
(GP) in a production environment. Renaming the file allows you to be certain that only
production settings are applied, and that no settings you specified during your evaluation
are used.
If the file is not renamed, Profile management examines it for any settings not configured
in Group Policy and adopts any non-default settings it finds. So, to eliminate the risk of
unwanted settings being introduced, configure all settings you want to use in your
production environment using Group Policy, not the .ini file.
The .ini files contain the same policies as the .adm and .admx files, but the policies have
different names. If you are familiar with the names in GP and are planning a pilot study
with an .ini file, compare the names using the tables in Versions and Policies.
For more information on .ini file deployments, see Considerations When Upgrading .Ini Files
and Testing Profile Management with a Local GPO.
30
Decide on a configuration
To configure Profile management, the recommended approach is to answer these basic
questions about your environment:
1. Is this a pilot or a production deployment?
2. Do you plan to migrate existing profiles or create new ones?
3. Are the computers persistent and do users have dedicated access to them?
4. Do the computers spend significant time disconnected from the network?
5. Which applications are hosted on the computers?
Depending on the answer to each question, you configure Profile management differently as
explained in the remaining topics in this section of eDocs. You only need to configure the
policies that fit the answers to these questions; you can leave other policies in their default
setting. Some policies should not be configured; for a list of these, see Administering
Profile Management.
After you have answered each question and configured Profile management appropriately,
you should anticipate:
•
Reviewing and testing your configuration before putting it into production
•
Troubleshooting
UPMConfigCheck
UPMConfigCheck is a PowerShell script that examines a live Profile management
deployment and determines whether it is optimally configured. For more information on
this tool, see CTX132805.
Group computers into OUs
If your answers to the questions are the same for different sets of computers, consider
grouping them into an Active Directory Organizational Unit (OU) and configuring Profile
management using a single Group Policy Object (GPO) attached to that OU. If your answers
to these questions are different, consider grouping the computers into separate OUs.
Alternatively, where a domain supports WMI filtering, you can group all computers into the
same OU and use WMI filtering to select between appropriately configured GPOs.
31
Pilot? Production?
The aim of a pilot deployment is to be able to demonstrate a solution quickly and reliably,
and an important goal may be to reduce the number of components in the pilot. For Profile
management, two components are the user store and the selection of users whose profiles
are processed.
Policy: Path to user store
Setting up a user store for Citrix user profiles is exactly like setting up a profile store for
Windows roaming profiles.
For a pilot deployment, you can often ignore these considerations. The default value for
the Path to user store policy is the Windows folder in the user's home directory. This works
well for a single-platform pilot so long as only one operating system (and therefore only one
profile version) is deployed. For information on profile versions, see About Profiles. This
option assumes that enough storage is available in users' home directories and that no
file-server quotas are applied; Citrix does not recommend the use of file-server quotas with
profiles. The reasons for this are given in Sharing Citrix User Profiles on Multiple File
Servers.
For a production deployment, you must carefully consider security, load balancing, high
availability, and disaster recovery. Follow the recommendations in these topics for creating
and configuring the user store:
•
Profile Management Architecture
•
Creating the User Store
•
To specify the path to the user store
•
High Availability and Disaster Recovery with Profile Management
Policy: Processed groups
The complexity of production deployments means that you may need to phase the rollout of
Profile management, rather than release it to all users at the same time. You may also
need to tell users that they will receive different profile experiences when connecting to
different resources while the deployment is in the process of being rolled out.
For performance reasons, Profile management is licensed by an End-User License
Agreement (EULA) not built-in license checking. You may choose to manage license
allocation by assigning users to an Active Directory (AD) user group or using an existing AD
group if a suitable one exists.
In pilot deployments, use of Profile management is usually restricted by invitation to a
small group of users, possibly from several departments, where no single, representative AD
group can be used. In this case, leave the Processed groups policy unconfigured; Profile
32
Pilot? Production?
Management performs no checking on group membership and all users are processed.
For more information on this policy, see To define which groups' profiles are processed.
Important: In all cases you must ensure that the number of users processed by Profile
management does not exceed the limits set by the relevant EULA.
33
Migrate profiles? New profiles?
You can take advantage of a Profile management deployment to refresh your organization's
profiles, initially using a small, customized profile and rigidly controlling additions to it.
Alternatively, you may need to migrate existing profiles into the Profile management
environment and preserve the personalizations that have built up over many years. With
Citrix VDI-in-a-Box deployments, you will likely be migrating existing local profiles rather
than starting from scratch.
If you decide to migrate existing profiles, configure the Migration of existing profiles and
Local profile conflict handling policies.
The following diagram illustrates how to configure these policies based on your answer to
this question.
Policy: Template profile
If you decide to create an entirely new set of profiles, consider creating a template for this
purpose using the Template profile policy. For information, see To specify a template
profile. If you do not create a template, Profile management will give users the default
Windows profile, for example, from a VDI-in-a-Box master image. If no template is
required, leave this policy disabled.
The Template profile policy is similar to the Path to user store policy because it specifies
the location of a profile that can be used as the basis for creating a new user's profile when
they first log on to a computer managed by Profile management.
34
Persistent? Provisioned? Dedicated?
Shared?
The types of machines that create profiles affect your configuration decisions. The primary
factors are whether machines are persistent or provisioned, and whether they are shared by
multiple users or dedicated to just one user.
Persistent systems have some type of local storage, the contents of which can be expected
to persist when the system turns off. Persistent systems may employ storage technology
such as storage area networks (SANs) to provide local disk mimicking. In contrast,
provisioned systems are created "on the fly" from a base disk and some type of identity
disk. Local storage is usually mimicked by a RAM disk or network disk, the latter often
provided by a SAN with a highspeed link. The provisioning technology is generally
Provisioning Services or Machine Creation Services (or a third-party equivalent). Sometimes
provisioned systems have persistent local storage, which may be provided by Personal
vDisks; these are classed as persistent.
Together, these two factors define the following machine types:
•
Both persistent and dedicated - Examples are Desktop OS machines with a static
assignment and a Personal vDisk that are created with Machine Creation Services (in
XenDesktop), desktops with Personal vDisks that are created with VDI-in-a-Box, physical
workstations, and laptops
•
Both persistent and shared - Examples are Server OS machines that are created with
Machine Creation Services (in XenDesktop), and XenApp servers
•
Both provisioned and dedicated - Examples are Desktop OS machines with a static
assignment but without a Personal vDisk that are created with Provisioning Services (in
XenDesktop)
•
Both provisioned and shared - Examples are Desktop OS machines with a random
assignment that are created with Provisioning Services (in XenDesktop), desktops
without Personal vDisks that are created with VDI-in-a-Box, and XenApp servers
The following Profile management policy settings are suggested guidelines for the different
machine types. They work well in most cases, but you may want to deviate from these as
your deployment requires.
Note: In XenDesktop deployments, Delete locally cached profiles on logoff, Profile
streaming, and Always cache are enforced by the auto-configuration feature.
35
Policy
Both persistent
and dedicated
Both persistent
and shared
Both
provisioned
and dedicated
Both
provisioned
and shared
Delete locally
cached profiles
on logoff
Disabled
Enabled
Disabled (note
5)
Enabled
Persistent? Provisioned? Dedicated? Shared?
Profile
streaming
Disabled
Enabled
Enabled
Enabled
Always cache
Enabled (note
1)
Disabled (note
2)
Disabled (note
6)
Disabled
Active write
back
Disabled
Disabled (note
3)
Enabled
Enabled
Process logons of
local
administrators
Enabled
Disabled (note
4)
Enabled
Enabled (note
7)
Notes
1. Because Profile streaming is disabled for this machine type, the Always cache setting is
always ignored.
2. Disable Always cache. However, you can ensure that large files are loaded into profiles
as soon as possible after logon by enabling this policy and using it to define a file size
limit (in MB). Any file this size or larger is cached locally as soon as possible.
3. Disable Active write back except to save changes in profiles of users who roam between
XenApp servers. In this case, enable this policy.
4. Disable Process logons of local administrators except for Hosted Shared Desktops. In this
case, enable this policy.
5. Disable Delete locally cached profiles on logoff. This retains locally cached profiles.
Because the machines are reset at logoff but are assigned to individual users, logons are
faster if their profiles are cached.
6. Disable Always cache. However, you can ensure that large files are loaded into profiles
as soon as possible after logon by enabling this policy and using it to define a file size
limit (in MB). Any file this size or larger is cached locally as soon as possible.
7. Enable Process logons of local administrators except for profiles of users who roam
between XenApp servers. In this case, disable this policy.
36
Mobile? Static?
Are your machines permanently connected to the Active Directory domain? Laptops and
similar mobile devices probably are not. Similarly, some deployments may have fixed
machines with persistent local storage but the machines are separated from the data center
for significant periods of time (for example, a remote branch office that is linked to the
corporate headquarters by satellite communications). Another example is disaster recovery,
where infrastructure is being restored and power or communications are intermittent.
Typically, Profile management is resilient to short network outages (less than 24 hours) so
long as the user does not log off while the network is unavailable. In these circumstances,
you can optimize Profile management in several ways that significantly speed up the logon
process. This is the static case.
Where extended periods of disconnection are expected or users must be able to log off or
shut down their computers while disconnected from the corporate network, you cannot
optimize Profile management; when users reconnect, logons are slow while the entire
profile is fetched from the user store. This is the mobile case.
The mobile case
For extended periods of disconnection (and only intermittent periods of connection to the
Active Directory domain), enable the Offline profile support policy. This automatically
disables the effect of the following policies, controlling optimizations that are not
supported. The policies might not appear to be disabled in Group Policy but they have no
effect:
•
Profile streaming
•
Always cache
Note: If Offline profile support is enabled, Active write back is honored but can only work
when the computer is connected to the network.
Important: Do not enable Offline profile support with Citrix VDI-in-a-Box. This policy is
not suitable for this product because desktops created with it do not have persistent local
storage.
The static case
Policy: Offline profile support
For short periods of disconnection, disable the Offline profile support policy. This allows
the configuration of any of the following policies.
Policy: Streamed user profile groups
37
Mobile? Static?
Set the Streamed user profile groups policy to Unconfigured. Enabling this policy is
effective only if Profile streaming is also enabled. Streamed user profile groups is used to
limit the use of streamed profiles to specific Active Directory user groups. It is useful in
some scenarios when migrating from older versions of Profile management. For instructions
on setting this policy, see To stream user profiles.
For information on high availability and disaster recovery as it applies to this policy, see
Scenario 4 - The Traveling User.
Policy: Timeout for pending area lock files
Set the Timeout for pending area lock files policy to Unconfigured to apply the default
operation, which is a one-day timeout for the pending area lock. This is the only supported
value, so do not adjust this policy.
Policy: Active write back
For information on this policy, see Provisioned or Persistent?
38
Which applications?
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 within the profile or
outside it, and also in the registry or in the file system. You must balance the desire to let
Profile management process those customizations stored outside the profile (by configuring
items as included and excluded) with the need to keep the profiles small in order to
minimize logon times.
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,
seehttp://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.
•
39
Registry-relative paths (that is, relative to the HKCU root) in either of these policies:
•
Exclusion list
•
Inclusion list
Which applications?
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. Subject to certain limitations, Profile management supports
legacy applications through the combination of inclusions and exclusions. This requires you
to specify absolute paths in any of these policies:
•
Directories to synchronize
•
Files to synchronize
•
Exclusion list - directories
•
Exclusion list - files
•
Folders to mirror
The limitations are described in Combining Inclusions and Exclusions.
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.
40
Which applications?
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?
Directories to
synchronize
Folder
Files to
synchronize
Simple
Legacy
Complex
Relative
Absolute
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
Flag
Process
Internet
cookie files
on logoff
41
Application Type
Which applications?
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
Reviewing, Testing, and Activating 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 Administering Profile Management.
42
Reviewing, Testing, and Activating Profile
Management
This topic assumes that you have answered all of the questions about your deployment
listed in Decide on a configuration, and have configured Profile management policies
accordingly. You are now ready to review the configuration and go live.
Ask a colleague to review your policy settings. Then, test the configuration. This can be
done using .ini files. Once testing is complete, manually transfer the settings to a Group
Policy Object.
Policy: Enable Profile management
Until you enable this policy, Profile management is inactive.
43
Planning for Multiple Platforms
Why are user profiles on multiple platforms such a
challenge?
It is common for users to access multiple computing devices. The challenge with any type of
roaming profile results from the differences between systems on these devices. For
example, if I create a shortcut on my desktop to a local file that does not exist when I move
to a different device, I have a broken shortcut on my desktop.
A similar issue exists when roaming between a desktop operating system (OS) and a server
OS. Some settings may not be applicable on the server (such as power settings or video
settings). Furthermore, if applications are not installed similarly on each device, when I
roam other issues may emerge.
Some personalization settings (such as My Documents, Favorites, and other files that
function independently of OS or application version) are much easier to manage than
others. But even these settings may be difficult to roam when a document type is only
supported on one system. For example, a user has Microsoft Project installed on one
system, but on another device that file type is not recognized. This situation is exacerbated
if the same application is present on two systems but on one different add-ons are installed
and expected by a document.
How does changing the way an application is installed
cause issues?
Even though platforms are identically installed, if an application is configured differently on
each, errors may occur when the application starts. For example, a macro or add-on might
activate in Excel on one platform but not another.
The Start Menu
The Start menu contains links (LNK and LNK2 files). The user-specific part of the menu is
stored in the profile and can often be modified by users. Adding custom links (to
executables or documents) is not uncommon. In addition, links that are language-specific
result in multiple Start menu entries for the same application. Furthermore, links pointing
to documents might be invalid on other computers because the path to the document is
relative to another system, or it is a network path that is inaccessible.
By default, the content of the Start menu folder is not saved by Profile management
because links pointing to executables are often computer-dependent. However, in
situations where the systems are very similar, including the Start menu in your Profile
management configuration improves the consistency when users roam from desktop to
desktop. Alternatively, you can process the Start menu with folder redirection.
44
Planning for Multiple Platforms
Note: Unpredictable side effects can often result from what appears to be the most
innocuous of changes. For example, see the article Citrix User Profile Manager (UPM) and
the Broken Rootdrive on the Sepago blog.
Always test and verify the behavior of the Start menu across platforms.
The Quick Launch Toolbar
The Quick Launch toolbar contains links and is configurable by users. By default, the Quick
Launch toolbar is saved by Profile management. In some environments this might not be
desirable because the links may be computer-dependent.
To exclude the toolbar, add the following entries to the folder exclusion list:
45
•
Windows XP or Windows 2003: Application Data\Microsoft\Internet Explorer\Quick
Launch
•
Windows 7 or Windows 2008: AppData\Roaming\Microsoft\Internet Explorer\Quick
Launch
What Types of Profiles Should I Create?
Because of the difference in their structure, Citrix recommends creating separate Version 1
and Version 2 profiles for each user in any environment that contains multiple platforms.
Differences between the Windows Vista and Windows 7 profile namespace make it difficult
to share profiles across these platforms, and failures can also occur between Windows XP
and Windows Server 2003. For more information on Version 1 and Version 2 profiles, see
About Profiles.
The definition of multiple platforms here includes not just multiple operating systems
(including ones of different bitness) but also multiple application versions running on the
same operating system. The following examples illustrate the reasons for this
recommendation:
•
32-bit systems may contain registry keys that instruct the operating system to start
applications in locations specific to 32-bit operating systems. If the keys are used by a
Citrix user profile on a 64-bit system, the location might not exist on that system and
the application will fail to start.
•
Microsoft Office 2003, Office 2007, and Office 2010 store some Word settings in
different registry keys; even if these applications run on the same operating system,
you should create separate profiles for the three different versions of the Word
application.
Citrix recommends using Microsoft folder redirection with Citrix user profiles to help ensure
profile interoperability, but within an environment where Windows Vista or Windows 7 must
co-exist with Windows XP, it is even more important.
Tip: Depending on your organization’s data management policy, it is good practice to
delete profiles from the user store and the cross-platform settings store for user accounts
that have been removed from Active Directory.
46
Sharing Citrix User Profiles on Multiple
File Servers
The simplest implementation of Profile management is one in which the user store is on one
file server that covers all users in one geographical location. This topic describes a more
distributed environment involving multiple file servers. For information on highly
distributed environments, see High Availability and Disaster Recovery with Profile
Management.
Note: Disable server-side file quotas for the user store because filling the quota causes
data loss and requires the profile to be reset. It is better to limit the amount of personal
data held in profiles (for example, Documents, Music and Pictures) by using folder
redirection to a separate volume that does have server-side file quotas enabled.
The user store can be located across multiple file servers, which has benefits in large
deployments where many profiles must be shared across the network. Profile management
defines the user store with a single setting, Path to user store, so you define multiple file
servers by adding attributes to this setting. You can use any LDAP attributes that are
defined in the user schema in Active Directory. For information on this, see
http://msdn.microsoft.com/en-us/library/ms675090(VS.85).aspx.
Suppose your users are in schools located in different cities and the #l# attribute (lower
case L, for location) is configured to represent this. You have locations in London, Paris,
and Madrid. You configure the path to the user store as:
\\#l#.userstore.myschools.net\profile\#sAMAccountName#\%ProfileVer%\
For Paris, this is expanded to:
\\Paris.userstore.myschools.net\profile\JohnSmith\v1\
You then divide up your cities across the available servers, for example setting up
Paris.userstore.myschools.net in your DNS to point to Server1.
Before using any attribute in this way, check all of its values. They must only contain
characters that can be used as part of a server name. For example, values for #l# might
contain spaces or be too long.
If you can't use the #l# attribute, examine your AD user schema for other attributes such as
#company# or #department# that achieve a similar partitioning.
You can also create custom attributes. Use Active Directory Explorer, which is a sysinternals
tool, to find which attributes have been defined for any particular domain. Active Directory
Explorer is available at http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx.
Note: Do not use user environment variables such as %homeshare% to distinguish profiles
or servers. Profile management recognizes system environment variables but not user
environment variables. You can, however, use the related Active Directory property,
#homeDirectory#. So, if you want to store profiles on the same share as the users' HOME
directories, set the path to the user store as #homeDirectory#\profiles .
47
Sharing Citrix User Profiles on Multiple File Servers
The use of variables in the path to the user store is described in the following topics:
48
•
To specify the path to the user store
•
Administering Profiles Within and Across OUs
•
High Availability and Disaster Recovery with Profile Management
Administering Profiles Within and Across
OUs
Within OUs
You can control how Profile management administers profiles within an Organizational Unit
(OU). In Windows Server 2008 environments, use Windows Management Instrumentation
(WMI) filtering to restrict the .adm or .admx file to a subset of computers in the OU. WMI
filtering is a capability of Group Policy Management Console with Service Pack 1 (GPMC with
SP1). For more information on WMI filtering, see
http://technet.microsoft.com/en-us/library/cc779036(WS.10).aspx and
http://technet.microsoft.com/en-us/library/cc758471(WS.10).aspx. For more information
on GPMC with SP1, see http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=0a6
d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en.
The following methods let you manage computers with different OSs using a single Group
Policy Object (GPO) in a single OU. Each method is a different approach to defining the
path to the user store:
•
Hard-coded strings
•
Profile management variables
•
System environment variables
Hard-coded strings specify a location that contains computers of just one type. This allows
profiles from those computers to be uniquely identified by Profile management. For
example, if you have an OU containing only Windows 7 computers, you might specify
\server\profiles$\%USERNAME%.%USERDOMAIN%\Windows7 in Path to user store. In this
example, the Windows7 folder is hard-coded. Hard-coded strings do not require any setup
on the computers that run the Profile Management Service.
Profile management variables are the preferred method because they can be combined
flexibly to uniquely identify computers and do not require any setup. For example, if you
have an OU containing Version 1 and Version 2 profiles running on operating systems of
different bitness, you might specify
\\server\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_PROFILEVER!!CTX_OSBITNESS! in Path
to user store. In this example, the two Profile management variables might resolve to the
folders v1x86 (containing Version 1 profiles running on a 32-bit operating system) and v2x64
(containing Version 2 profiles running on a 64-bit operating system). For more information
on Profile management variables, see Profile Management Policies.
System environment variables require some configuration; they must be set up on each
computer that runs the Profile Management Service. Where Profile management variables
are not suitable, consider incorporating system environment variables into the path to the
user store as follows.
On each computer, set up a system environment variable called %ProfVer%. (User
environment variables are not supported.) Then, set the path to the user store as:
49
Administering Profiles Within and Across OUs
\\upmserver\upmshare\%username%.%userdomain%\%ProfVer%
For example, set the value for %ProfVer% to XP for your Windows XP 32-bit computers and
XPx64 for your Windows XP 64-bit computers. For Windows Server 2008 32-bit and 64-bit
computers, use 2k8 and 2k8x64 respectively. Setting these values manually on many
computers is time-consuming, but if you use Provisioning Services, you only have to add the
variable to your base image.
An example of how to script this is at:
http://forums.citrix.com/thread.jspa?threadID=241243&tstart=0
This sample script includes lines for Windows Server 2000, which is unsupported by Profile
management.
Tip: In Windows Server 2008 R2 and Windows Server 2012, you can speed up the creation
and application of environment variables using Group Policy; in Group Policy Management
Editor, click Computer Configuration > Preferences > Windows Settings > Environment,
and then Action > New > Environment Variable.
Across OUs
You can control how Profile management administers profiles across OUs. Depending on
your OU hierarchy and GPO inheritance, you can separate into one GPO a common set of
Profile management policies that apply to multiple OUs. For example, Path to user store
and Enable Profile management must be applied to all OUs, so you might store these
separately in a dedicated GPO, enabling only these policies there (and leaving them
unconfigured in all other GPOs).
You can also use a dedicated GPO to override inherited policies. For information on GPO
inheritance, see the Microsoft Web site.
50
Domain and Forest Support in Profile
Management
Domain and forest functional levels of Windows Server 2003 or later are supported by
Profile management. This includes a Windows Server 2008 domain controller running in
mixed mode at a domain or forest functional level of Windows Server 2003. Older operating
systems are unsupported.
The use of system environment variables can help to disambiguate usernames in multiple
domains. For information on this, see Administering Profiles Within and Across OUs.
51
High Availability and Disaster Recovery
with Profile Management
As a prerequisite, familiarize yourself with the structure of the user store and how to
create it by reading Profile Management Architecture and Creating the User Store.
These topics describe the supported scenarios for high availability and disaster recovery as
they apply to Citrix Profile management. It relates the scenarios to the relevant, underlying
Microsoft technologies and identifies what is supported:
•
Scenario 1: Basic setup of geographically adjacent user stores and failover clusters
•
Scenario 2: Multiple folder targets and replication
•
Scenario 3: Disaster recovery
•
Scenario 4: The traveling user
•
Scenario 5: Load-balancing user stores
Profile management assumes that it operates in an environment that is reliable. Principally,
this reliability applies to the availability of Active Directory (AD) and a networked user
store (NUS). When either of these is not available, Profile management cannot provide a
profile, and hands over responsibility to Windows, which generally provides a default
profile.
Comparison with Roaming Profiles
In disaster recovery and high availability scenarios, Citrix Profile management may be
affected by the same issues as affect Microsoft roaming profiles, and unless stated to the
contrary, Profile management does not resolve such issues.
In particular, note the following:
52
•
Profile management support is limited to the scenarios where roaming profiles are also
supported. For more information about this, see "Can I use DFS with Offline Files and
redirected My Documents folders?" at
http://technet.microsoft.com/en-us/library/hh341474(WS.10).aspx.
•
The cache option for offline files must be disabled on roaming user profile shares. The
same restriction applies to Profile management shares. For more information about
this, see http://support.microsoft.com/kb/287566.
•
A roaming profile is not loaded from a DFS share. The same restriction applies to Profile
management shares. For more information about this, see
http://support.microsoft.com/kb/830856.
Scenario 1 - Basic Setup of
Geographically Adjacent User Stores and
Failover Clusters
“I want my users to always use a geographically adjacent, preferred networked user store
(NUS) for their profiles.” Options 1 and 2 apply in this case.
“I want my NUS to be on a failover cluster, to give me high availability.” Option 2 applies in
this case.
The following graphic illustrates this scenario. Users in North America (NA) want to use the
NUS in New York rather than the NUS in Brisbane, to reduce latency and to minimize the
traffic sent over the intercontinental link to Australia or New Zealand (ANZ).
53
Scenario 1 - Basic Setup of Geographically Adjacent User Stores and Failover Clusters
Option 1 – DFS Namespaces
Background Reading
•
For an overview of the Microsoft DFS Namespaces technology, see
http://technet.microsoft.com/en-us/library/cc730736(WS.10).aspx.
•
For advice on load balancing user stores, see the Citrix blog at http://community.citrix.
com/display/ocb/2009/07/21/Profile+Management+-+Load+Balancing+User+Stores.
Implementing This Option
DFS Namespaces can resolve some of the issues presented in the blog article.
Let us set up a namespace for the NUS called \\MyCorp\Profiles; this is the namespace root.
We set up namespace servers in New York and Brisbane (and any of the other sites). Each
namespace server has folders corresponding to each Active Directory location, which in turn
have targets on a server in New York or Brisbane.
We might have the following locations configured in Active Directory (part of the user
records).
54
AD Location Attribute (#l#)
Geographic Location
Wagga Wagga
ANZ
Darwin
ANZ
Brisbane
ANZ
Auckland
ANZ
Seattle
NA
San Diego
NA
West Palm Beach
NA
Poughkeepsie, New York
NA
Scenario 1 - Basic Setup of Geographically Adjacent User Stores and Failover Clusters
The following graphic shows one way of setting this up using DFS Namespaces.
Once this is set up, we configure the Path to user store setting as:
\\MyCorp\Profiles\#l#
The profiles of users belonging to the eight sites will be distributed to just two servers,
meeting the geographical constraints required of the scenario.
55
Scenario 1 - Basic Setup of Geographically Adjacent User Stores and Failover Clusters
Alternatives
You can order namespace targets and use the ordering rules as follows. When DFS
Namespaces resolves which target to use, it is possible to specify that only targets in the
local site are chosen. This works well so long as you are sure that, for any given user, every
desktop and server is guaranteed to belong to the same site.
This technique fails if, say, a user normally based at Poughkeepsie visits Wagga Wagga.
Their laptop profile may come from Brisbane, but the profile used by their published
applications may come from New York.
The recommended technique, using AD attributes, ensures that the same DFS Namespace
choices are made for every session that the user initiates, because the #l# derives from the
user's AD configuration rather than from machine configurations.
Option 2 - DFS Namespaces with Failover Clustering
Background Reading
•
For a step-by-step guide to configuring a two-node file server failover cluster, see
http://technet.microsoft.com/en-us/library/cc731844(WS.10).aspx.
•
For information about choosing a namespace type, see
http://technet.microsoft.com/en-us/library/cc770287(WS.10).aspx.
Implementing This Option
Adding failover clustering allows you to provide basic high availability.
The key point in this option is to turn the file servers into failover clusters, so that folder
targets are hosted on a failover cluster rather than a single server.
If you require the namespace server itself to have high availability, you must choose a
standalone namespace, as domain-based namespaces do not support the use of failover
clusters as namespace servers. Folder targets may be hosted on failover clusters, regardless
of the type of namespace server.
Important: The state of file locks may not be preserved if a server in a failover cluster
fails. Profile management takes out file locks on the NUS at certain points during profile
processing, so it is possible that a failover at a critical point may result in profile
corruption.
56
Scenario 2 - Multiple folder targets and
replication
“If my local NUS is not available, I want my users to be able to get their profile data from a
backup location somewhere else on the corporate network. If they make changes, those
changes need to get back to their preferred NUS when it is available again.”
The basic requirement in this scenario is to provide alternative locations for profiles on the
network. The use case includes the partial failure of the network infrastructure or the
complete unavailability of a folder target such as a failover cluster.
Options you should consider are the use of multiple folder targets and the use of DFS
replication.
Option 1 - Referrals to multiple folder targets
Background reading
For information about tuning DFS namespaces, see
http://technet.microsoft.com/en-us/library/cc771083(WS.10).aspx.
About this option
A referral is an ordered list of targets that are tried in turn by a user device. It is designed
for scenarios where the targets are read-only, such as software libraries. There is no
linkage between targets, so using this technique with profiles may create multiple profiles
that cannot be synchronized.
However, it is possible to define both an ordering method and a target priority for targets
in referrals. Choosing a suitable ordering method appears to result in a consistent choice of
target by all user sessions. But in practice, even when all of a user's devices are within the
same site, intra-site routing problems can still result in different targets being chosen by
different sessions. This problem can be compounded when devices cache referrals.
Important: This option is not suitable for Profile management deployments and is
generally not supported. However, file replication has been used in some specialized
deployments in which only a single session can be guaranteed and Active write back is
disabled. For information on these special cases, contact Citrix Consulting.
57
Scenario 2 - Multiple folder targets and replication
Option 2 - Distributed file system replication
Background reading
•
For an overview of Distributed File System Replication (DFSR), see
http://technet.microsoft.com/en-us/library/cc771058(WS.10).aspx.
•
For a statement of support about replicated user profile data, see http://blogs.technet
.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-us
er-profile-data.aspx.
•
To understand why DFSR does not support distributed file locking, see http://blogs.tech
net.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-lockin
g-in-dfsr.aspx.
Implementing this option
DFS Replication provides folder synchronization across limited bandwidth network
connections. This appears to solve the problems in Option 1 because it synchronizes
multiple folder targets that a single namespace folder definition refers to. Indeed, when
folders are added as targets to a folder definition, they can be specified as belonging to a
replication group.
There are two forms of replication to consider:
•
One-way replication (also known as active-passive replication) is designed for backing
up critical data to a safe repository. This makes it suitable for maintaining a disaster
recovery site, for example. This can be made to work with Profile management so long
as the passive targets are disabled for referrals, and are only invoked when the disaster
recovery plan is activated.
•
Two-way replication (also known as active-active replication) is intended to provide
local read-write access to global shared data. Instantaneous replication is not
necessarily a requirement here. The shared data may be modified infrequently.
Important: Active-active DFSR is not supported.
A schedule defines the frequency with which data is replicated. A frequent schedule is
more intensive on both CPU and bandwidth, but will not guarantee instantaneous updates.
At various points in its operation, Profile management requires certain files to be locked in
the NUS to coordinate updates to the (shared) user store. Typically these updates take
place when a session starts and ends, and in the middle of a session if active write-back is
enabled. Since distributed file locking is not supported by DFS Replication, Profile
management can only select one target as an NUS. This effectively eliminates any value of
two-way replication (active-active replication), which is therefore not suitable for Profile
management and is not supported. One-way replication (active-passive replication) is
suitable for Profile management only as part of a disaster recovery system. Other uses are
not supported.
58
Scenario 3 - Disaster Recovery
“How do I set up a full disaster recovery site to handle Citrix user profiles?”
The key features required for disaster recovery (DR) are supported by Profile management:
•
DFS namespaces. Domain-based namespace servers are preferred in this scenario
because they allow the DR site to have its own namespace server. (A standalone
namespace server cannot be replicated, but it can be hosted on a failover cluster.)
•
Multiple folder targets and DFS Replication. For each NUS, you provide at least two
targets, but only enable one in normal operation. You set up one-way DFS Replication
to ensure that the disabled targets (at the DR sites) are kept up-to-date.
•
Failover clusters for hosting individual folder targets. This is optional. It might be
wasteful of resources on the DR site.
In this diagram, a domain-based namespace manages the NUS. (The diagram in Scenario 1
deliberately did not include namespaces.) This means that we can include a namespace
server in each site, including the DR site, and the servers all support the same view of the
namespace.
59
Scenario 3 - Disaster Recovery
If the DR plan is activated, the DR site's NUS is up-to-date with the changes replicated from
the master NUS. However, the namespace server still reflects the wrong view of the
namespace, so its configuration must be updated. For each folder, the folder target on the
master site must be disabled and the folder target on the DR site enabled.
After AD updates have propagated, the namespace server correctly locates the DR folder
targets and the DR site is ready to use by Profile management.
Note: The Path to user store setting refers to namespace folders, not real servers, so
there is no need to update the Profile management configuration.
In practice, one-way or two-way replication is possible because the DR site is not normally
used for profiles. Once the disaster is over, a connection from the DR site to the master site
ensures that changes made to the NUS during the disaster are replicated on the master site.
60
Scenario 4 - The Traveling User
“When my staff roam between different offices, I want their preferred NUS to change, so
that they’re still using a geographically adjacent NUS.”
The difficulty with this scenario is that a user's logon session may be aggregated from
multiple locations. They typically roam their desktop session from one site to another, but
many of their applications are hosted on backend servers that have no awareness of the
current location of the user's desktop.
Furthermore, the user may reconnect to disconnected sessions, probably hosted at their
home location, so if the sessions were for some reason forced to switch to an NUS in the
user's new location, their performance degrades.
For travelers who hot-desk, using the Profile streaming and Always cache settings is the
best option. With a fixed machine, they still log on quickly, using Citrix streamed user
profiles. Enabling Always cache loads the remainder of the profile in the background.
61
Scenario 5 - Load-Balancing User Stores
“I want to load-balance my users across several geographically adjacent networked user
stores (NUSs).”
Background Reading
•
For an overview of the Microsoft DFS Namespaces technology,
http://technet.microsoft.com/en-us/library/cc730736(WS.10).aspx.
•
For advice on load balancing user stores, see the Citrix blog at http://community.citrix.
com/display/ocb/2009/07/21/Profile+Management+-+Load+Balancing+User+Stores.
Unlike Scenario 1, this scenario has a single site that is large enough to require multiple
NUSs. Using DFS namespaces, we can improve on the solution in Scenario 1.
Scenario 1 (Option 1) used DFS Namespaces to map multiple sites to different folders on the
same server. You can use a similar technique to map subfolders of a namespace to folders
on different servers.
Ideally, you need an AD attribute that partitions user accounts into similarly sized chunks,
such as #department#. As in Scenario 1, #department# must always be defined and must be
guaranteed to contain a correct folder name.
62
Scenario 5 - Load-Balancing User Stores
As in Scenario 1, we set up a namespace for the NUS called \\MyCorp\Profiles. This diagram
shows how to set up the namespace.
Once this is set up, you configure the Path to user store setting as:
\\MyCorp\Profiles\#l#\#department#
With this configuration, the users in Wagga Wagga are distributed across two NUS servers,
both local.
63
Planning Folder Redirection with Profile
Management
Folder redirection is a feature of Microsoft Windows. Profile management works with folder
redirection and its use is encouraged. You can use it with Version 3.2, Version 3.2.2, and
Version 4.x. For the best experience, Citrix recommend using Version 4.1.1 or later.
Active Directory (AD) allows folders, such as Application Data or Documents, to be saved
(redirected) to a network location. The contents of the folders are stored in the redirected
location and not included within the user profile, which therefore reduces in size.
Depending on the version of AD, some folders can be redirected but not others. In addition,
configuring folder redirection allows users with mandatory profiles to save some settings,
files, and other data while still restricting profile usage.
As a general guideline, Citrix recommends enabling folder redirection for all user data that
is not accessed regularly within a session if network bandwidth permits.
AD in Windows Server 2008 allows you to redirect additional folders that are not available
with AD in Windows Server 2003.
Not all folders which can be redirected are accessible with AD. The folders that can be
redirected on a specific operating system are in the registry under
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.
Important Information About Folder Redirection
Note the following important points about using folder redirection with Profile managent:
64
•
To configure folder direction successfully, be aware of the differences in folder
structure between Version 1 and Version 2 profiles. For more information, see Version 1
and Version 2 Profiles.
•
Depending how you choose to set up folder redirection, you must configure Profile
management appropriately. For instructions, see To configure Profile management for
folder redirection.
•
For additional security considerations when using folder redirection, see Secure your
Profile management deployment and the article called Configuring Folder Redirection
on the Microsoft TechNet Web site, http://technet.microsoft.com.
•
Treat the user store differently to the share used for redirected folders. For important
information about this, see Profile Management Architecture.
•
Do not add redirected folders to exclusion lists.
Third-Party Directory, Authentication, and
File Services
This topic describes support for directory, authentication, and file services other than those
provided by Microsoft.
Directory Services
Important: Active Directory (AD) is critical to the operation of Profile management.
Other directory services are not supported. These include:
•
Novell eDirectory.
•
Windows 2000 server or earlier operating systems (OSs). Windows 2000 server supports
AD but not at the required level; for more information, see Domain and Forest Support
in Profile Management. Microsoft Windows NT 4.0 pre-dates AD.
•
Samba 4 or earlier.
Authentication Services
Other authentication services can co-exist with AD within a domain but are not supported
by Profile management because, like the Profile Management Service, they can interact
with winlogon.exe and cause problems with the user logon process. For example, the
authentication service from Novell allows users to access Novell resources, such as printers
and file shares, but is not supported.
File Services
Third-party file services can be used for the user store and folder redirection (if supported
by the Windows operating system being used). File servers must be of the type Server
Message Block (SMB) or Common Internet File System (CIFS) and must support the NTFS file
system. For these reasons, the following are supported:
•
Windows Server 2003 or later
•
Samba 3
Important: Because it requires authentication against the Novell directory, the Novell file
service is not supported.
65
Frequently Asked Questions About Using
Profiles On Multiple Platforms
This section contains questions and answers about using profiles in environments with
multiple Windows operating systems, or multiple versions or bitnesses of a single operating
system.
For answers to frequently asked questions about upgrades, see Frequently Asked Questions
About Upgrading Profile Management.
66
Profiles on Multiple Platforms
How can I be certain of avoiding compatibility issues
with my profiles?
This requires balancing the need to support heterogeneous environments with the need for
personalization settings to track users and their devices. Typically, the balance between
these two needs can only be determined by administrators and IT departments. This means
managing the dissimilar systems as well as you can by adjusting the user profiles so that,
when profiles roam, any issues are handled properly or to the extreme where settings are
completely ignored and not tracked at all. This is the basis of many third-party software
solutions.
To minimize troubleshooting, try and roam profiles across exactly the same device setup
(installed applications, OS version, and so on). In many scenarios in the modern world
however, that is not easily achieved, which makes for an imperfect user experience. For
example, a user should not need to replicate their Favorites or My Documents just because
they use multiple operating systems. Administrators can enhance the user experience in
this case by using Folder Redirection. The use of this Microsoft feature is also encouraged in
other scenarios.
Can I share profiles across different systems?
Citrix recommends having one base profile for each platform. This is not necessarily the
same as one profile per operating system. For more information on this recommendation,
see What Types of Profiles Should I Create? This minimizes the number of settings that may
not work well together or that do not apply to any given OS. For example, desktop power
settings are not applicable in a server scenario or one involving Remote Desktop Services
(formerly Terminal Services).
As you try to simplify and reduce the number of profiles and they are used on more than
one OS, there is greater risk of conflicting settings. This is further compounded when the
systems are not the same. For example, Microsoft Office add-ins may not exist on every
device. Fortunately, settings such as this one that are not applicable on a given device are
often ignored. Support issues arise when they are not ignored. Microsoft Excel fails to start
if an add-in is not present.
How does Profile management enable settings across
multiple versions or platforms?
Citrix provides the ability to roam common settings across multiple base profiles. Citrix
enables roaming of settings such as Microsoft Office, Internet Explorer, and wallpaper. The
ability to support these types of scenarios is limited by the degree to which applications
support the roaming of settings between platforms. The links in the next question cover
Microsoft's position and best practices.
67
Profiles on Multiple Platforms
How does Microsoft support roaming profiles across
platforms and versions?
For best practices for roaming profiles, see
http://technet.microsoft.com/en-us/library/cc784484.aspx.
For recommended strategies to roam Outlook, see
http://office.microsoft.com/en-us/ork2003/HA011402691033.aspx.
For Office installation recommendations, see
http://office.microsoft.com/en-us/ork2003/HA011402061033.aspx.
For Office 2007 toolbar settings, see http://support.microsoft.com/kb/926805/en-us.
Where the standard Microsoft Windows profile solutions do not fully address technical,
custom, or business requirements, Profile management represents a viable solution.
Is sharing a profile between x86 and x64 platforms
possible?
Sharing one profile between Windows x86 and x64 might generally work, but some issues
are possible.
There are several reasons for this. For example, one reason is that per-use file associations
are stored in HKCU\Software\Classes. If a non-administrator sets Firefox as their default
browser, the following is stored on a 32-bit system:
HKEY_CURRENT_USER\Software\Classes\FirefoxHTML\shell\open\command -> "C:\Program
Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "%1"
If a profile containing this path is used on Windows x64, the OS looks for a 64-bit version of
Firefox, but this does not exist. Instead, a 32-bit version is probably installed at C:\Program
Files (x86)\Mozilla Firefox. This results in the browser not starting.
The reverse is also true; a path is set on an x64 platform but is used on an x86 one.
I want to test how one profile behaves across multiple
platforms. Where do I start?
Testing and validating are key to experimenting with the use of one profile on more than
one platform. The recommended approach is to have one profile per platform, but if you
want to explore how a single profile behaves across multiple platforms, the following
information may be helpful.
Start by identifying what might cause issues by answering the next question, and use the
remaining questions in this topic for ideas for tackling and tracking the issues.
Items that will work across platforms:
68
Profiles on Multiple Platforms
•
My Documents and Favorites
•
Applications that store their configuration information (with defaults) completely
within the profile
Items that might not work:
•
Applications that store hard-coded data, path data, and so on
•
Settings specific to x64 or x86 platforms
•
Installations of applications that are not identical, such as Excel Add-ins that are not
present on all systems. These might cause all types of error conditions that vary by
application
Can I assign profiles based on the computer a user
logs on to?
Yes. Profile management can apply a profile based on the local desktop, XenApp, or
XenDesktop, or any combination of these.
With the correct Profile management setting enabled, a Remote Desktop Services (formerly
Terminal Services) profile is used only when a user has a Terminal Server or XenApp session.
This setting overrides any existing profile (except for a Citrix user profile) when the user
logs on through a Remote Desktop Services session.
On Windows XP, Profile management has a Group Policy (GP) setting that has an option to
assign a profile to a specified computer. Because it is based on GP, the profile is defined by
the OU to which the computer belongs.
For Windows 7, you can use a GPO computer setting to assign a profile based on the
computer a user logs on to. Again, because this is based on GP, the profile assignment
depends on the OU to which the GPO is applied.
Why are profile assignments based on computer
desirable?
It is very useful to assign a profile to the computer a user logs on to if a distinct user
experience is desired. For example, administrators may decide that profiles used with
Remote Desktop Services (formerly Terminal Server) sessions are kept separate from
profiles used with desktops.
69
Migrating Profiles
Does Profile management migrate Windows user
profiles to Citrix user profiles?
You can configure Profile management to automatically migrate existing roaming and local
profiles when users log on. You can also use a template profile or the default Windows
profile as the basis for new Citrix user profiles. You configure this behavior using the .ini
file or Group Policy Object (GPO).
For information about planning and setting up your Profile management migration, see
Migrate profiles? New profiles?. For details of the operations that the software takes when
migrating Windows user profiles to Citrix user profiles, see CTX119466.
Which profiles can be migrated to Citrix user profiles?
Profile management can migrate Windows local and roaming profiles. Mandatory profiles
(.man profiles) are ignored by Profile management but they can be used as templates for
Citrix user profiles. To ensure Profile management works correctly, deactivate the
assignment of mandatory profiles to all users.
To use your existing mandatory profile as a template, see To specify a template profile.
How do I use a template profile?
Profile management allows you to specify a template profile that is used as the basis for
the creation of new Citrix user profiles. Typically, a user who is assigned a profile for the
first time receives the Default User profile of the Windows device they log on to. This may
be acceptable, and it means any variation in different devices’ Default User profiles results
in differences in the base profile created for the user. This means you can regard the
template profile feature as a Global Default User profile.
For more information, see To specify a template profile.
70
Troubleshooting Profile Management
This topic describes the settings in Group Policy (GP) that control how Profile management
stores log data. In addition, the checklists and other troubleshooting advice in this section
of eDocs are designed to help you identify and solve issues. Note that, in many cases, issues
result from components other than Profile management or from a misconfiguration of the
environment.
Important: Only enable logging if you experience an issue in your Profile management
deployment and want to troubleshoot it. In addition, disable logging when the issue is
resolved and delete the log files, which may contain sensitive information.
UPMConfigCheck
UPMConfigCheck is a PowerShell script that examines a live Profile management
deployment and determines whether it is optimally configured. For more information on
this tool, see CTX132805.
Policy: Enable logging
This policy enables or disables logging. Only enable this policy if you are troubleshooting
Profile management.
If Enable logging is disabled, only errors are logged. If this policy is not configured in GP,
the value from the .ini file is used. If this policy is not configured in GP or the .ini file, only
errors are logged.
Policy: Log settings
This is a set of policies that you can use to focus on specific activities. Only set these
policies if you are troubleshooting, and set them all unless you are requested to do
otherwise by Citrix personnel.
If Log settings is not configured in GP, Profile management uses the settings from the .ini
file. If this policy is not configured in GP or the .ini file, errors and general information are
logged.
Policy: Maximum size of the log file
The default value for the maximum size of the Profile management log file is small. If you
have sufficient disk space, increase it to 5 or 10 MB, or more. If the log file grows beyond
the maximum size, an existing backup of the file (.bak) is deleted, the log file is renamed
to .bak, and a new log file is created. The log file is created in
%SystemRoot%\System32\Logfiles\UserProfileManager.
71
Troubleshoot
In XenDesktop deployments that use Machine Creation Services be aware of the persistent
folder that imposes a 15 MB limit on log files (not just Profile management ones). To allow
for this, store your log files on a system disk, where this limitation does not apply, or use
this policy to restrict the log file size to a maximum of 7 MB; Profile management can then
store, on the persistent folder, the current log file and the previous one as a .bak file.
If this policy is disabled, the default value of 1 MB is used. If this setting is not configured in
GP, the value from the .ini file is used. If this setting is not configured in GP or the .ini file,
the default value is used.
Policy: Path to log file
You can set an alternative path to which the log files are saved. The path can be to a local
drive or a remote, network-based one (a UNC path). Remote paths can be useful in large,
distributed environments but they can create significant network traffic, which may be
inappropriate for log files.
For profiles on virtual machines, you must consider whether drives on the desktops are
persistent because this affects logging. If a desktop has a persistent drive (for example, if it
was created with a personal vDisk using Citrix XenDesktop), set a local path to it; the log
files are preserved when the machine restarts. If a desktop does not have a persistent drive
(for example, it was created without a personal vDisk using XenDesktop), set a UNC path;
this allows you to retain the log files but the system account for the machines must have
write access to the UNC share. Use a local path for any laptops managed by the offline
profiles feature.
If a UNC path is used for log files, note the following:
•
Citrix recommends that an appropriate access control list is applied to the log file
folder to ensure that only authorized user or computer accounts can access the stored
files.
•
Duplicate log files remain locally. These can be left on the computer, but if you want to
remove them, first stop the Profile Management Service, delete the log file and the
configuration log file, and restart the computer.
Some logon and logoff processing is done in the context of the user using impersonation.
Citrix recommends that you grant write permissions on the log folder for the users group so
that Profile management can write to the log files during impersonation.
Examples:
•
D:\LogFiles\ProfileManagement
•
\\servername\LogFiles\ProfileManagement
If Path to log file is not configured in GP, the value from the .ini file is used. If this policy is
not configured in GP or the .ini file, the default location
%SystemRoot%\System32\Logfiles\UserProfileManager is used.
For the special case of XenDesktop Machine Creation Services, a local, persistent folder is
mapped to the C drive at C:\Program Files\Citrix\PvsVM\Service\PersistedData. This is a
good location to store up to 15 MB of log data, but, if you use it, note the limit on Maximum
size of the log file, which is described above.
72
Troubleshoot
73
Basic Troubleshooting Checklist
As a first step in troubleshooting any issue that you or your users experience, follow these
steps:
1. If a Profile management .ini file is in use, check its configuration on the affected
computer.
2. Check the settings in Group Policy (GP) against the recommended configurations that
are described in Decide on a configuration.
To deactivate any Profile management policy that you enter as lists (for example,
exclusion lists and inclusion lists), set the policy to Disabled. Do not set the policy to
Not Configured.
3. Check the HKLM\Software\Policies registry entry on the affected computer to see if
there are any stale policies due to GP tattooing issues, and delete them. Tattoing
occurs when policies are deleted from GP but remain in the registry.
4. Check the file UPMSettings.ini, which contains all of the Profile management settings
that have been applied for each user. This file is located in the root folder of each
Citrix user profile in the user store.
74
Profile Management Log Files
The event log is used primarily for the purpose of error reporting. Only errors are written to
it. All other warning and informational messages, in addition to errors, are written to the
Profile management log file. This is the file %SystemRoot%\system32\LogFiles\UserProfileMa
nager\<domainname>#<computername>_pm.log, where <domainname> is the computer's domain and <compu
If the domain cannot be contacted, the log file is called UserProfileManager.log.
In addition, a configuration log file, <domainname>#<computername>_pm_config.log,
captures the GPO and .ini file settings even if logging is turned off. This file is also stored in
%SystemRoot%\system32\LogFiles\UserProfileManager, and if the domain cannot be
contacted it is called UserProfileManager_pm_config.
The rest of this topic describes the contents of <domainname>#<computername>_pm.log.
Log Entry Types
•
Common warnings. All common warnings.
•
Common information. All common information.
•
File system notifications. One log entry is created each time a processed file or folder
is changed.
•
File system actions. File system operations performed by Profile management.
•
Registry actions. Registry actions performed by Profile management.
•
Registry differences at logoff. All registry keys in the hive HKCU that have been
changed in a session.
Important: This setting produces large amounts of output in the log file.
75
•
Active Directory actions. Each time Profile management queries the Active Directory,
an entry is written to the log file.
•
Policy values. When the Profile management service starts or a policy refresh occurs,
policy values are written to the log file.
•
Logon. The series of actions during logon are written to the log file.
•
Logoff. The series of actions during logoff are written to the log file.
•
Personalized user information. Where applicable, user and domain names are logged
to dedicated columns of the log file.
Profile Management Log Files
Log File Format
Each line in the log file has several fields, separated by semicolons.
76
Field
Description
Date
Date of the log entry
Time
Time of the log entry (including
milliseconds)
Severity
Either INFORMATION, WARNING, or ERROR
Domain
The domain of the user (where applicable)
User name
The name of the user (where applicable)
Session ID
The session ID (where applicable)
Thread ID
The ID of the thread that created this line
Function and description
The name of the Profile management
function executing at the time, and the log
message
Events Logged by Profile Management
The following events are logged by Profile management and can be used by Citrix EdgeSight
or third-party monitoring and reporting tools. View the events in Windows Event Viewer.
Select the Applications node in the left pane; the Source of the events in the right pane is
Citrix Profile management.
In this table, causes and suggested actions for resolution are included for each event. Long
event descriptions are truncated with elipsis (…)
77
Event
ID
Description
Cause
Action
6
The Citrix Profile
management
service has
started.
The Citrix Profile
management service has
started. This may be the
result of an automatic start,
a manual start, or a restart.
If the start or restart was
not planned, check the
event log for errors and
take any corrective action
indicated, including Profile
management
troubleshooting
procedures.
7
The Citrix Profile
management
service has
stopped.
The Citrix Profile
management service has
stopped. This may be the
result of a manual stop or as
part of shutdown processing.
If the service stop was not
planned, check the event
log for errors and take any
corrective action indicated,
including Profile
management
troubleshooting
procedures.
8
The profile for
user <user name>
has been modified
by a later version
of Citrix Profile
management and
can no longer be
used by this
version…
The Citrix Profile
management service on this
machine has detected that a
later version of Profile
management has modified
the user's profile in the user
store. To prevent possible
data loss, earlier versions of
Profile management revert
to using a temporary profile.
Upgrade this computer (and
all other computers sharing
the same user store and
using earlier versions of
Profile management) to use
the latest version.
Events Logged by Profile Management
9
78
The logon hook
detection
encountered a
problem…
The Citrix Profile
management service
detected a problem while
setting up logon
notification. The Citrix
Profile management service
requires either that:
•
The installation path
contains no spaces
•
8.3 filename support is
enabled on the volume
where the service is
installed
Reinstall Citrix Profile
management to a path with
no spaces or enable 8.3
filename support on the
volume where Profile
management is installed.
10
User <user name>
path to the user
store is…
A valid Citrix user profile
has been found at the
location indicated.
None. This message is for
information only.
11
spsMain:
CreateNamedPipe
failed with…
(This event is no longer
used.)
None.
12
StartMonitoringPro
file: A problem
was detected in
the Windows
change journal
management
during logon…
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will not
process this folder. A
Windows user profile will be
used instead.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
13
StopMonitoringPro
file: A problem
was detected in
the Windows
change journal
management
during logoff…
The Citrix Profile
Management Service was
unable to stop monitoring
the profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
management, preventing
the Service from monitoring
changes. Citrix Profile
management will not
process this folder. File and
registry changes will not be
synchronized for the user.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
Events Logged by Profile Management
79
14
CJIncreaseSizeIfNe
cessary:
Creating/resizing
the change journal
failed…
The Citrix Profile
management service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected while
attempting to create or
resize the NTFS change
journal on a volume,
preventing the service from
monitoring changes. Citrix
Profile Management will not
process this folder. A
Windows user profile will be
used instead.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
15
CJInitializeForMon
itoring: Unable to
query the
journal…
The Citrix Profile
management service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected while querying
the NTFS change journal on
a volume, preventing the
service from monitoring
changes. Citrix Profile
Management will not process
this folder. A Windows user
profile will be used instead.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
16
CJInitializeForMon
itoring: Initial MFT
scan finished with
errors.
The Citrix Profile
management service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected while
performing an initial scan of
the NTFS change journal on
a volume, preventing the
service from monitoring
changes. Citrix Profile
Management will not process
this folder. A Windows user
profile will be used instead.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
Events Logged by Profile Management
80
17
CJInitializeForMon
itoring: Processing
FS changes since
service start
failed.
The Citrix Profile
management service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected while
performing an update scan
of the NTFS change journal
on a volume. This error does
not prevent the service from
monitoring changes. Citrix
Profile management will
process this directory as
normal.
Although this error does not
prevent the operation of
Profile management, check
for errors anyway. Ensure
that change journal
processing is configured
and operational for all
volumes managed by Profile
management. Ensure that
the computer has adequate
system resources. Check
the event log for errors and
take any corrective action
indicated, including Profile
management
troubleshooting
procedures.
18
CJProcessAvailabl
eRecords: Internal
Error…
A failure occurred in the
Citrix Profile management
service while monitoring the
profile or a folder
configured for extended
synchronization. A problem
was detected while
performing an update scan
of the NTFS change journal
on a volume, preventing the
service from monitoring
recent changes. Citrix
Profile management will not
complete processing on this
folder. Back up critical data
manually.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
19
USNChangeMonitor
: Initialization of
change journal
failed…
A failure occurred in the
Citrix Profile management
service while monitoring the
profile or a folder
configured for extended
synchronization. A problem
was detected while
preparing the initial scan of
the NTFS change journal on
a volume, preventing the
service from monitoring
changes. Citrix Profile
management will not
complete processing on this
directory. Back up critical
data manually.
The Citrix Profile
Management Service was
unable to monitor the
profile or a folder
configured for extended
synchronization. A problem
was detected in the
Windows change journal
event management,
preventing the Service from
monitoring changes. Citrix
Profile Management will
not process this folder. A
Windows user profile will
be used instead.
Events Logged by Profile Management
81
20
CADUser::Init:
Determining the
DNS domain and
ADsPath failed…
A problem occurred while
querying Active Directory for
information about the
logged-on user. Citrix Profile
management will not
process this folder. A
Windows user profile will be
used instead.
Ensure that the computer
has a functioning network
path to a domain
controller. Ensure that the
computer has adequate
system resources. Check
the event log for errors and
take any corrective action
indicated, including Profile
management
troubleshooting
procedures.
21
Determining the
DNS domain and
ADsPath failed…
This issue can be caused by
a limit on memory
allocation, as described in
the Microsoft TechNet
article 263693.
The resolution for this issue
is described in the Citrix
Knowledge Center article
CTX124953.
22
File access was
slow. User <user
name>
experienced a
delay while file
<file name> was
fetched from the
user store.
The user tried to access the
file but Profile management
detected a delay in this
operation. The user received
a warning message. This
may be due to antivirus
software preventing access
to the file in the user store.
Consult the Profile
management
documentation for
troubleshooting and
configuration advice on
enterprise antivirus
products.
23
File access may be
denied. User <user
name>
experienced a
long delay while
file <file name>
was fetched from
the user store.
The user tried to access the
file but Profile management
detected such a significant
delay in this operation that
access may be denied. The
user received an error
message. This may be due to
antivirus software
preventing access to the file
in the user store.
Consult the Profile
management
documentation for
troubleshooting and
configuration advice on
enterprise antivirus
products.
24
RevertToSelf
failed with error
code <error code
number> and
Profile
management was
shut down.
Some logon and logoff
processing is performed
using impersonation. The
RevertToSelf function is
normally invoked when
impersonation is complete.
On this occasion, the
function could not be called
so, for security reasons,
Profile management
software was shut down.
The user received an error
message.
If you suspect a security
breach, follow your
organization’s procedures
to address it, and then
restart Profile
management.
Events Logged by Profile Management
25
The profile for
user <user name>
is managed by
Citrix Profile
management, but
the user store
<user store name>
could not be
reached…
The Citrix Profile
Management Service on this
computer could not reach
the specified user store.
This is normally because of a
network issue or because
the server hosting the user
store is unavailable.
Ensure the server hosting
the user store is available
and the network between
this computer and the
server is operational.
26
The default
profile location
<location name> is
invalid. Profiles in
this location
cannot be
monitored
correctly…
Profiles on this computer
must be located on a disk
mounted on a drive letter
(for example, C:).
Move the profiles on this
computer to a disk
mounted on a drive letter,
and restart Profile
management.
27
The profile folder
for user <user
name> is not
present under the
default profile
location <location
name>…
In the registry, the location
of this user's profile and of
the default profile do not
match. This can occur, for
example, if profiles are
moved between different
volumes on the machine
running the Profile
Management Service.
Ensure this user's profile is
located under the default
folder location, using
appropriate tools if
necessary so that the
profile data in the file
system matches the
profile's registry settings.
28
An error occurred
while trying to
reset security
permissions on the
registry hive for
user <user name>.
It is likely that there are
permission issues with the
registry in the default or
template profile used to
create this Citrix user
profile.
If appropriate, reset the
security permissions on the
user's registry hive in the
Profile management user
store using a third-party
utility such as SetAcl.
29
A template profile
path is configured
but no profile was
found…
The specified folder cannot
be used in the Template
profile setting because it
does not contain the file
NTUSER.DAT. This issue
commonly occurs when the
full path of the NTUSER.DAT
file is configured instead of
the folder containing
NTUSER.DAT.
Check that you have
configured a valid path to
the folder containing the
template profile. Check
that the path contains
NTUSER.DAT, that this is a
valid file, and that access
rights are set correctly on
the folder to allow read
access to all files.
Note that the Template
profile setting does not
support expansion of Active
Directory attributes, system
environment variables, or
the %USERNAME% and
%USERDOMAIN% variables.
82
Log File Checklist
After working through the basic troubleshooting checklist, examine the Profile management
log file as follows.
1. Make sure that logging is activated. Set the correct policies for this using the
instructions in Troubleshooting Profile Management.
2. Check the log file for errors. Locate these by searching for the word ERROR.
3. Check the log file for warnings. Locate these by searching for the word WARNING.
4. Run the command gpupdate /force on the computer on which the error occurs, and
check the log file again. Review which settings are active and from where the
configuration has been read (either Group Policy or an .ini file).
5. Check the path to the user store is correct.
6. Check all information from Active Directory was read correctly.
7. Check the time stamps. Is there an action that took too long?
If the log file does not help you identify the issue, see Other Troubleshooting Steps.
83
Advanced Troubleshooting of Log Files
If no logging at all is taking place, try the troubleshooting approach used in the following
example. It is designed to help you work out which configuration settings are being read,
establish where they are being read from (when multiple ADM files are present), and check
that the log file correctly tracks changes made to profiles. The strategy creates a small test
OU to which a test user logs on, allowing you to create profile modifications that you then
track in the log file and Resultant Set of Policies (RSoP) report.
The deployment in this example has XenApp servers running on Windows Server 2003 with
users connecting to their published resources using the Plug-in for Hosted Apps for
Windows. The deployment uses OU-based GPOs. INI file-based configuration is not used.
Caution: Editing the Registry incorrectly can cause serious problems that may require you
to reinstall your operating system. Citrix cannot guarantee that problems resulting from
the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
Be sure to back up the registry before you edit it.
1. Remove from the production environment one of the XenApp servers that hosts the
Citrix user profiles, and add it to a new OU containing just this server.
2. Remove and reinstall Profile management on the server. When reinstalling, check that
short file names (also known as 8.3 file names) are activated as follows:
•
If the following registry entry is set to 1 (DWORD value), set it to 0 and reinstall
Profile management:
HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8Dot3NameCreation.
This enables support for short file names.
If the entry is not set to 1, reinstall Profile management to a location where each
subfolder name is eight characters or less, for example c:\prof-man
3. Log on as a domain administrator to the server.
•
4. Examine the local policy and remove the ADM file at this level.
5. Delete any links to GPOs assigned to your new OU.
6. On the server, delete the key and all subkeys from Registry Editor:
HKLM\Software\Policies\Citrix\UserProfileManager\
7. Remove all Profile management .ini files.
8. Using My Computer > Properties > Advanced, delete all profiles except those you want
to test. Research any errors that appear.
9. So that you can check the Profile management log file when logging on as a user, give
the Authenticated Users group full control of the file. This is C:\Windows\System32\LogF
iles\UserProfileManager\<domainname>#<computername>_pm.log (where <domainname> is the compute
name). If the domain cannot be contacted, the log file is UserProfileManager.log.
10. Create a new GPO that contains only the following settings, and link it to your new OU.
Ensure the GPO is assigned to the Authenticated Users group. Enable these settings:
84
Advanced Troubleshooting of Log Files
a. Enable Profile management.
b. Path to user store.
c. Enable logging.
d. Log settings. Scroll to select all settings in this section of the ADM file.
e. Migration of existing profiles. Select Roaming and local profiles.
f. Local profile conflict handling. Select Rename local profile.
g. Delete locally cached profiles on logoff.
Disable the setting Process logons of local administrators. This helps when
troubleshooting because, if Profile management is misconfigured and prevents user
logons, you will still be able to log on as an administrator.
11. Control how the GPO link is applied to the OU by right-clicking the OU and selecting
Block Inheritance.
12. Create a new domain test user who has never logged on and who is not a member of
any group that is a local administrator on the server.
13. Publish a full desktop to this user and make sure the user is in the Remote Desktop
Users group.
14. If the domain has multiple domain controllers (DCs), force AD replication between all
the DCs in the same site as the server.
15. Log on to the server as domain Administrator, delete the log file, restart the Citrix
Profile Management service, and run gpupdate /force.
16. Check the registry and make sure the only values in
HKLM\Software\Policies\Citrix\UserProfileManager\ are the ones for your new GPO.
17. Log out as Administrator.
18. Using the Plug-in for Hosted Apps, log on to the published full desktop as the new
domain test user.
19. Make some setting changes to Internet Explorer, and create a blank test file in your My
Docs folder.
20. Create a shortcut to the Profile management log file. Open it and examine the entries.
Research any items that may require attention.
21. Log out and then back in as domain Administrator.
22. Generate an RSoP report for the test user and the server.
If the report does not contain what you expect, research any items that require attention.
85
Specific Troubleshooting Information
Slow Logons
For information about known issues with slow logons and workarounds, see CTX101705.
Installation on Windows XP or Windows Server 2003
Fails
Profile management installation ends prematurely and no components are installed on the
target computers.
This situation may occur if the required Microsoft MSI update is not present on the
computers. It is especially likely to occur on new Windows XP and Windows Server 2003
systems where no Windows patches have been applied, and on existing systems running
these operating systems where automatic updates are disabled.
To correct this issue, apply the updates described in Microsoft Security Bulletin MS09-012,
and then install Profile management. For information about the updates, see
http://www.microsoft.com/technet/security/bulletin/MS09-012.mspx.
Checking That Profiles Are Being Streamed
If you have enabled streamed user profiles and want to verify that this feature is being
applied to a user's profile:
1. Check the following type of entry in the Profile management log file:
2010-03-16;16:16:35.369;INFORMATION;;;;1140;ReadPolicy: Configuration value read from policy: PSEnab
The last item should be set to PSEnabled=<1> if the feature is enabled.
2. Check the following entry for the user in the Profile management log file:
2010-03-16;20:17:30.401;INFORMATION;<domain name>;<user name>;2;2364;ProcessLogon: User logging
If streamed user profiles are not being applied, the item reads ProcessLogon: User
logging on with Streamed Profile support disabled.
86
Specific Troubleshooting Information
Problems With Streamed User Profiles and Antivirus
Products
If you use enterprise antivirus products and encounter issues such as logons hanging or
taking a very long time, consult the troubleshooting information in Profile Streaming and
Enterprise Antivirus Products.
Determining Which Policies Are In Force
Use UPMSettings.ini (located in the root folder of each Citrix user profile in the user store)
to determine the Profile management policies that are being applied. Examining this file
may be more convenient than using the Resultant Set of Policy (RSoP) especially if you use
a mixture of GPOs and .ini file settings to determine policies.
Use UPMFRSettings.ini (also located in the root folder) to determine which profile folders
are not processed because they are on an exclusion list.
Excluding Corrupt Profile Data
If a user profile is corrupt and you are confident the problem lies with a particular file or
folder, exclude it from the synchronization process by adding it to the exclusion list.
Cleaning Connections to Registry Entries
In some scenarios (not just those involving Profile management), connections to registry
profile data are preserved after users log off. This may result in slow logoffs or incomplete
termination of user sessions. The User Profile Hive Cleanup (UPHClean) tool from Microsoft
can help resolve these scenarios. For more information on this tool, see http://www.micros
oft.com/downloadS/details.aspx?FamilyID=1b286e6d-8912-4e18-b570-42470e2f3582&display
lang=en.
Deleting Local Profiles
Tip: Microsoft Delprof.exe and Sepago Delprof2 are tools that help you delete user
profiles.
Deleting Locked, Cached Profiles
If you use VMWare software to create virtual desktops, but users' cached profiles are locked
and cannot be deleted, see Profile Management and VMWare for troubleshooting
information.
87
Specific Troubleshooting Information
Identifying Where Profiles Are Stored
Diagnosing profile issues can involve locating where the files in a user's profiles are stored.
This procedure provides a quick way to check this.
1. In Event Viewer, click Application in the left pane.
2. Under Source in the right pane, locate the Citrix Profile Management event of interest
and double-click it.
3. The path to the user store associated with the event is displayed as a link on the
General tab.
4. Follow the link to browse the user store if you want to explore the files.
Checking Servers
To determine whether a server is processing a user's logons and logoffs correctly, check the
file called PmCompatibility.ini in the user's profile in the user store. The file is located in
the profile's root folder. The last entry in the file is the name of the server from which the
user last logged off. For example, if the server runs Profile management 4.0, the entry
would be:
[LastUpdateServerName]
4.0=<computer name>
Rolling Back to Version 2.1
You can roll back to a Version 2.1 deployment if Version 4.x has been deployed too early.
See Managing Multiple Versions of Profile Management for the reasons this might happen.
Run the following PowerShell command on the file server that hosts the user store. This
deletes the file PmCompatibility.ini in each profile in the user store:
Get-ChildItem LocalPathToUserStore -include pmcompatibility.ini -recurse | foreach ($_) {remove-item $_.fu
After the command has completed, users can log on to computers running Version 2.1 and
receive their profile from the user store.
Profile Management Running on VMware Creates
Multiple Profiles
Replicated VMware folders are created in user profiles. The replicates have incremented
folder names (000, 001, 002, and so on). For more information about this issue and how to
resolve it, see CTX122501.
88
Specific Troubleshooting Information
Long Logon Times With Novell eDirectory
When users log on to an environment involving Citrix products and Novell eDirectory
(formerly known as Novell Directory Services), long logon times may be experienced and
errors written to the event log. Sessions may hang or freeze for up to 30 seconds at the
Applying your personal settings stage. For more information about this issue and how to
resolve it, see CTX118595.
Excluded Folders in User Store
Excluded folders appear in the user store. This is expected and no corrective action is
required; folders on an exclusion list are created in the user store but their contents are
not synchronized.
Missing Information In Log File
Activating debug mode does not automatically enable full logging. In Log settings, verify
that you have selected all of the checkboxes for the events you want to log.
Tip: You may have to scroll down to enable the last checkboxes on the list.
GPO Settings Inoperative
You change a GPO setting but it is not operative on the computer running the Citrix Profile
Management Service. This might be because GP does not refresh immediately but instead is
based on events or intervals specified in your deployment. If you want to refresh GP
immediately, run gpupdate on the computer.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
Users Receive New or Temporary Profiles
In some circumstances, when they log on Windows XP users receive a new profile instead of
their cached profile. For more information about this issue and a workaround for it, see
CTX118226.
Users may also receive a temporary profile if a local profile is present after the copy in the
user store is removed. This situation can arise if the user store is cleared but local profiles
are not deleted at logoff. Profile management treats such partial removal of profiles as a
network, share, or permissions error, and provides the user with a temporary profile. For
this reason, partial removal is not recommended. To workaround this issue, log on to the
affected computer and delete the profile manually.
If your deployment includes personal vDisks (a XenDesktop feature), users may receive
temporary profiles if the default processing of these disks has not been correctly adjusted.
For information on this, see To migrate user profiles.
89
Specific Troubleshooting Information
Profile Data Lost When XenDesktop Sessions Become
Unresponsive
In a XenDesktop deployment, disconnecting from a Remote Desktop Protocol (RDP) session
can cause a virtual desktop running Windows XP to become unresponsive or to restart. This
impacts Profile management because it causes profile data to be lost when the session
ends. The issue is fixed in Citrix Virtual Desktop Agent Version 3.1.3242 and later.
Users Cannot Log On (Event ID 1000, Source Userenv)
Users are unable to log on to a Citrix environment and receive the following error message:
“Windows did not load your roaming profile and is attempting to log you on with your local
profile... Contact your network administrator.” This appears in the Application event log on
Windows as Event ID 1000, with source Userenv.
For more information about and workarounds for this issue, see CTX105618.
Printing
In Citrix XenDesktop environments, a user can select a default printer but in some cases the
selection is not retained between logons. This has been observed when a XenDesktop policy
is used to set printers on pooled virtual desktops based on a Citrix Provisioning Services
vDisk in Standard Image mode. This issue does not originate with Profile management even
though the Profile management log file shows that the registry entry for the printer is
copied at logoff (which is expected) but NTUSER.dat for the user does not contain the entry
(which is not expected). The issue in fact originates with the way XenDesktop uses the
DefaultPmFlags registry setting. For more information on this, see CTX119066.
In some cases, unexpected printers are added to profiles and, after users remove them, the
printers reappear at the next logon. For more information, see
http://forums.citrix.com/thread.jspa?threadID=283076&tstart=0.
Problems With Application Settings on Multiple
Platforms
You may experience problems where application settings do not roam correctly across
multiple platfoms.Typical these result from:
90
•
Settings that are not applicable from one system to another (for example, hardware
specific settings that are not on every system).
•
Applications that are installed differently on different systems (for example, an
application that is installed on a C: drive on one system but on D: on another, an
application that is installed in C:\Program Files on one system but in C:\Program Files
(x86) on another, or an Excel add-in installed on one system but not another).
•
Applications that store setting information outside of the profile (for example,
information stored in the local machine's settings or outside the user profile).
Specific Troubleshooting Information
•
Language-specific configuration settings stored in the registry. Profile management
automatically translates language-specific folder names in Version 1 profiles but not in
the registry.
In most instances, these issues can be minimized by better standardization of the systems
that cause the issues. However, often the issues result from inherent incompatibilities (with
multiple platforms) of the OS or the respective application. If the problematic settings are
not critical, excluding them from the profile might resolve the issue.
Profiles Owned by Unknown Accounts
On rare occasions, a profile can appear to belong to an unknown account. On the Advanced
tab of the System Properties dialog box for a computer, Account Unknown is displayed when
you click Settings in User Profiles. This is accompanied by an event log entry, "Profile
notification of event Create for component <application ID> failed, error code is ???." In the
registry, the application ID points to the SHACCT Profile Notification Handler, a Microsoft
component.
To confirm that this occurs in your environment, log on as a user whose data is not
processed by Profile management, and check for these symptoms.
This is not an issue with Profile management but may be the result of Active Directory
interacting badly with virtual machine snapshots. The operation of Citrix user profiles is
unaffected; users can log on and off, and their profile changes are preserved.
91
Collecting Diagnostic Information
This topic guides you through the steps involved in collecting information that can help
diagnose problems with the operation of Profile management. Before following these
instructions, make sure you can reproduce the problem. For more information on the
policies described in this topic, see Troubleshooting Profile Management.
1. Open the Profile Management Group Policy Object (GPO) in the Group Policy
Management Editor, or open the .ini file in Notepad if you are not using GPO to manage
logging. For information on the .ini file including its location, see Files Included in the
Download.
2. Configure the following settings under the Profile Management\Log settings folder:
•
Set Enable logging to Enabled.
•
Select all of the events in Log settings.
In Maximum size of the log file, set the maximum size of the Profile management
log file in bytes.
3. Run gpupdate /force on the server or desktop, and ideally restart the Profile
Management Service. You must restart it if you are using an .ini file.
•
4. If requested by Citrix Technical Support, collect a diagnostic trace log (available in
Profile management 3.x or later) using the instructions in Other Troubleshooting Steps.
5. Reproduce the problem and collect the log files, including the .log.bak file.
6. Optionally, or if requested, collect the Resultant Set of Policy (RSoP) report,
application event logs, USERENV log, UPMSettings.ini, UPMFRSettings.ini, and
PmCompatibility.ini. The .ini files are located in the root folder of each Citrix user
profile in the user store.
Note that data collection can become complex if Citrix Provisioning Services is part of your
deployment and the problem occurs when profiles are being initialized. In this scenario, you
must make the above configuration updates in the .ini file (and unconfigure the above GPO
log settings) or preferably follow the instructions in To preconfigure Profile management on
provisioned images.
To obtain diagnostic information with CDFControl
CDFControl is an event tracing controller and consumer that captures Citrix Diagnostic
Facility (CDF) trace messages from various Citrix tracing providers, including those in
Profile management. Only use CDFControl if you are asked to do so by Citrix Technical
Support. For information on this tool, see CTX111961.
92
Collecting Diagnostic Information
To produce a session dump file
You can save Profile mangement's internal data state to a dump file. This is helpful when
you can isolate an issue to a specific point in a session but there is no associated entry in
the log file.
1. Create a file called $$upm_log$$.txt in the root of the drive on which the affected user
profile is located (typically C:). Profile management dumps its internal data state to
the file UserProfileManagerInternalData.log in the log file folder and deletes the file
$$upm_log$$.txt.
To set Microsoft NT Symbolic Debugger as your
default Windows postmortem debugging tool
For information about setting NT Symbolic Debugger (NTSD) as your default Windows
postmortem debugging tool, see CTX105888.
93
Other Troubleshooting Steps
Once you have followed the steps in the basic troubleshooting checklist to try and correct
an issue, and eliminated the Profile management log file as a source of useful information,
use this checklist to troubleshoot further.
•
Check the Resultant Set of Policies (RSoP) from the computer you are analyzing and
ensure all GPOs are applied as expected.
•
Check that you have the latest version of Profile management installed. Examine the
version information of UserProfileManager.exe by right-clicking the file in Windows
Explorer and clicking Properties > Version. The latest version is available from the
MyCitrix Web site; select your Citrix product and download Profile management from
the Software Downloads section.
Tip: You can hotfix your deployment of Profile management 2.1.1 or later by
upgrading to the latest version. After upgrading, you can, if desired, enable any later
feature.
•
Check the support forum at http://support.citrix.com/forums/forum.jspa?forumID=185.
Someone else may already have encountered the problem and solved it.
•
Enable user environment debug logging (available only on Windows XP and Windows
Server 2003; there is no equivalent on Windows 7 or Windows Server 2008). Instructions
on this are provided at http://support.microsoft.com/kb/221833/. The user
environment debug log contains a lot of information about the logon process.
Analyze the output file. Help with analysis is available at
http://technet.microsoft.com/en-us/library/cc786775.aspx.
•
94
Try to reproduce the issue you are observing on a clean computer with the same
operating system as the affected computer. If possible, install the software products
that are present on the affected computer one by one, and see if the issue is
reproduced after each installation.
Contacting Citrix Technical Support
If you have checked the log file and the other troubleshooting advice in this section, and
believe the problem you experience is due to Profile management, contact Technical
Support. Always include the following files and as much other information as possible:
•
All Profile management log files (in
%SystemRoot%\System32\Logfiles\UserProfileManager). Ensure that you have all of the
log settings activated.
Log files from the affected machine should contain at least the following information:
•
Start of the service (including the version and build number of Profile management)
•
Reading of the configuration by the service
•
One full logon process of the affected user
•
The activity the user performed when the issue occurred
•
One full logoff process for the affected user
Tip: Ensure that you have increased the maximum size of the log file. For information
on this, see Policy: Maximum size of the log file.
95
•
The Resultant Set of Policy (RSoP) for the machine and affected user.
•
Details of the operating system, language, and version installed on the affected system.
•
Details of Citrix products and versions installed on the system.
•
PmCompatibility.ini and UPMSettings.ini. These files are located in the root folder of
each Citrix user profile in the user store.
•
If available, the Userenv debug file. For more information on this Microsoft tool, see
http://support.microsoft.com/kb/221833.
•
If available, the session dump file. For more information on this Citrix tool, see To
produce a session dump file.
Secure your Profile management
deployment
This topic contains recommended best practice for securing Profile management. In
general, secure the servers on which the user store is located to prevent unwanted access
to Citrix user profile data.
Recommendations on creating secure user stores are available in the article called Security
Recommendations for Roaming User Profiles Shared Folders on the Microsoft TechNet Web
site. These are minimum recommendations that ensure a high level of security for basic
operation. Additionally, when configuring access to the user store include the
Administrators group, which is required in order to modify or remove a Citrix user profile.
Permissions
Citrix tests and recommends the following permissions for the user store and the
cross-platform settings store:
•
Share Permissions: Full control of the user store root folder
•
The following NTFS permissions, as currently recommended by Microsoft:
Group or User Name
Permission
Apply To
Creator Owner
Full Control
Subfolders and files only
<The group of accounts
under Profile management
control>
List Folder / Read Data
and Create Folders /
Append Data
This folder only
Local System
Full Control
This folder, subfolders and
files
Assuming inheritance is not disabled, these permissions allow the accounts to access the
stores, create subfolders for users' profiles, and perform the necessary read and write
operations.
Beyond this minimum, you can also simplify administration by creating a group of
administrators with full control of subfolders and files only. This makes deleting profiles (a
common troubleshooting task) easier for members of that group.
If you use a template profile, users need read access to it.
ACLs
If you use the cross-platform settings feature, set ACLs on the folder that stores the
definition files as follows: read access for authenticated users, and read-write access for
administrators.
96
Secure
Windows roaming profiles automatically removes administrator privileges from the folders
containing profile data on the network. Profile management does not automatically remove
these privileges from folders in the user store but, depending on your organization’s
security policies, you can do so manually.
Note: If an application modifies the access control list (ACL) of a file in the user's profile,
Profile management does not replicate those changes in the user store. This is consistent
with the behavior of Windows roaming profiles.
97
Profile Streaming and Enterprise Antivirus
Products
The streamed user profiles feature of Citrix Profile management makes use of advanced
NTFS features to simulate the presence of files missing from users' profiles. In that respect,
the feature is very similar to a class of products known as Hierarchical Storage Managers
(HSMs), which are typically used to archive infrequently used files on to slow mass-storage
devices such as magnetic tape or rewritable optical storage. When such files are required,
HSM drivers intercept the first file request, suspend the process making the request, fetch
the file from the archive storage, and then allow the file request to continue. Given this
similarity, the streamed user profiles driver, upmjit.sys, is in fact defined as an HSM driver.
In such an environment, it is very important to configure antivirus products to be aware of
HSM drivers, and the streamed user profiles driver is no different. In order to defend
against the most sophisticated threats, antivirus products must perform some of their
functions at the device driver level and, like HSM drivers, they work by intercepting file
requests, suspending the originating process, scanning the file, and resuming.
It is relatively easy to misconfigure an antivirus program to interrupt an HSM such as the
streamed user profiles driver, preventing it from fetching files from the user store, and
causing the logon to hang.
Fortunately, enterprise antivirus products are usually written with the possibility of
sophisticated storage products, such as HSMs, in mind and can be configured to delay their
scanning until the HSM has done its work. Note that home antivirus products are generally
less sophisticated in this respect, so the use of home and SoHo (small office/home office)
antivirus products is not supported with streamed user profiles.
To configure your antivirus product for use with streamed user profiles, look for one of the
following product features. Feature names are indicative only:
•
Trusted process list. This identifies HSMs to the antivirus product, which allows the
HSM to complete the file retrieval process. The antivirus product scans the file when it
is first accessed by a non-trusted process.
•
Do not scan on open or status-check operations. This configures the antivirus product
to only scan a file when data is accessed (for example, when a file is executed or
created). Other types of file access (for example, when a file is opened or its status
checked) are ignored by the antivirus product. HSMs generally activate in response to
file-open and file-status-check operations, so disabling virus scans on these operations
eliminates potential conflicts.
Citrix tests streamed user profiles with versions of the leading enterprise antivirus products
to ensure that they are compatible with Profile management. These versions include:
98
•
McAfee Virus Scan Enterprise 8.7
•
Symantec Endpoint Protection 11.0
•
Trend Micro OfficeScan 10
Profile Streaming and Enterprise Antivirus Products
Earlier versions of these products are not tested.
If you are using an enterprise antivirus product from other vendors, ensure that it is
HSM-aware, that is, it can be configured to allow HSM operations to complete before
performing scans.
Some antivirus products allow administrators to choose to only scan-on-read or
scan-on-write. This choice balances performance against security. The streamed user
profiles feature is unaffected by the choice.
Troubleshooting
If you encounter issues, such as logons hanging or taking a very long time, there may be a
misconfiguration between Profile management and your enterprise antivirus product. Try
the following procedures, in this order:
1. Check that you have the latest version of Profile management. Your issue may already
have been found and fixed.
2. Add the Profile management service (UserProfileManager.exe) to the list of trusted
processes for your enterprise antivirus product.
3. Turn off virus checking on HSM operations such as open, create, restore, or status
check. Only perform virus checks on read or write operations.
4. Turn off other sophisticated virus checking features. For example, antivirus products
may perform a quick scan of the first few blocks of a file to determine the actual file
type. These checks match the file contents with the declared file type but can interfere
with HSM operations.
5. Turn off the Windows search-indexing service, at least for the folders where profiles
are stored on local drives. This service causes unnecessary HSM retrievals, and has been
observed to provoke contention between streamed user profiles and enterprise
antivirus products.
If none of these steps work, turn off streamed user profiles (by disabling the Profile
streaming setting). If this works, re-enable the feature and disable your enterprise antivirus
product. If this also works, gather Profile management diagnostics for the non-working case
and contact Citrix Technical Support. They will need to know the exact version of
enterprise antivirus product.
To continue using Profile management, do not forget to re-enable the enterprise antivirus
and turn off streamed user profiles. Other features of Profile management continue to
function in this configuration; only the streaming of profiles is disabled.
99
Installing and Setting Up Profile
Management
About Profile Management Installations
Deploying Profile management consists of installing an .msi file and either an .adm or
.admx file. For information on upgrades rather than installations, see Upgrading Profile
Management and Migrating Profiles.
Install the Profile management .msi file on each computer whose user profiles you want to
manage. Typically, you install the .msi file on computers using a distribution tool, an
imaging solution, streaming technology, or Citrix Merchandising Server. You can also install
it directly on any computer using one of the installers in the download package. Unattended
installations are supported.
Install the .adm or .admx file by adding it to Group Policy (GP).
Installing the .msi file and the .adm or .admx file alone does not enable Profile
management. You must enable it separately (using the procedure To enable Profile
management) after performing all other setup tasks.
Citrix recommends that the same version of Profile management is installed on all user
devices and the same version's .adm or .admx file is added to each Group Policy Object on
all domain controllers. This prevents corruption of profile data, which may result when
different user store structures (from different versions) exist.
To install the .msi file
This procedure installs Profile management on a single computer.
If you perform the installation on Windows XP or Windows Server 2003 and have disabled
support for short file names (also known as 8.3 file names), each folder in the installation
location must conform with the short file naming convention, for example
C:\Citrix\ProfMgr. This issue does not occur on other supported operating systems.
1. Log on to the computer with administrator privileges.
2. Locate and run the appropriate installer from the download package. The installation
wizard appears.
3. Follow the on-screen instructions in the wizard.
4. Restart the computer.
100
Install and Set Up
To install the .msi file from the command line
Important: In an earlier version of Profile management, the following keys were removed
from the registry exclusion list in the supplied .ini file:
•
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy
•
HKEY_CURRENT_USER\Software\Policies
•
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
If you use these exclusions in Group Policy and set OVERWRITEINIFILES=yes in this
procedure, ensure you add all three of the keys or none of them (but not a subset) to the
registry exclusion list. (The OVERWRITEINIFILES option is primarily intended for
deployments using Group Policy rather than an .ini file, or for either deployment type in
which configuration settings can be discarded and the default .ini files re-installed.) The
option overwrites all of the changes you made throughout the .ini file including the keys.
Citrix recommends running the installer without this option and then manually removing
the key settings in the .ini file. Alternatively, if you use this option, ensure you add the
exclusions as described. For more information on preserving exclusions during
installation, see the Sepago blog at http://www.sepago.de/sepago-backstage/blogs/.
1. At a command line, run the following command:
msiexec /i <path to the MSI file> /quiet [/norestart]
[INSTALLDIR=<installation directory>]
[OVERWRITEINIFILES=yes] [INSTALLPOLICYINIFILES=no]
This command performs the installation without displaying a user interface and then
performs a restart.
If UAC is enabled, run the msiexec command with elevated rights, for example from an
elevated command prompt.
Optionally, you can suppress the restart using the /norestart option, but, depending
on the operating system, Profile management will not function until the computer has
restarted. For example, you do not need to restart Windows Vista workstations.
INSTALLDIR can be user specified.
For information on the OVERWRITEINIFILES=yes option, see Considerations When
Upgrading .Ini Files.
Setting INSTALLPOLICYINIFILES to no prevents the installation of Profile
management .ini files. If you have used the .ini files with a previous version of the
software and want to continue to use the settings contained in them with this version,
after installation transfer each setting manually to the equivalent Profile management
policy in Group Policy Editor.
If UAC is enabled, run the msiexec command with elevated rights, for example from an
elevated command prompt.
2. If you are upgrading, a dialog box may advise you that some files are in use. You are
given the option to close the application or continue without closing. Select the option
to close the application.
101
Install and Set Up
Installing the .msi file with Citrix Receiver Updater
You can use Receiver Updater and Merchandising Server, which are both components of the
Citrix Delivery Center solution, to distribute Profile management MSI packages. No
configuration of Profile management is required to do this. For instructions on deploying
components this way, see the Citrix Receiver Updater documentation.
To add the .adm or .admx file
Use this procedure if no earlier version of the Profile management .adm file is present in
Group Policy. If you are upgrading an .adm file, see Upgrading Profile Management.
In production environments, configure Profile management with Group Policy. For each OU
containing the computers you want to manage, create and link a Group Policy Object
(GPO), and then add the Profile management .adm or .admx file to the GPO.
To configure Citrix user profiles, you can use any computer that runs Windows Group Policy
Management Console. The computer does not have to be a domain controller. Domain
controllers only store the .adm or .admx file.
Note: For small pilot projects and evaluations where no separate test deployment of
Active Directory (AD) is available, you can also use the installed .ini files instead of the
.adm or .admx file. If, after successful testing, you move from .ini files to an AD
deployment, be sure to add to the .adm or .admx file any required inclusions and
exclusions in addition to the minimum defaults that are documented in Default Inclusions
and Exclusions.
1. On the domain controller, do one of the following:
•
Import the .adm file. The file is located in the GPO folder in the download package.
Copy the .admx file from the GPO folder in the download package to the
C:Windows\PolicyDefinitions folder and copy the .adml file to the
C:Windows\PolicyDefinitions\<localized folder>. For example, on English operating
systems, <localized folder> is en-US.
2. On the computer you want to use to configure Profile management, open Active
Directory Users and Computers.
•
3. Identify the OUs containing the computers that Profile management will be installed
on. For information on how to configure Profile management to work in your existing
OU structure, see Administering Profiles Within and Across OUs.
4. In Group Policy Management, create a GPO and link it to each OU.
Note: If you apply security filtering to the GPO, do so using either the Authenticated
Users group or a computer group. Do not use a security group that only contains
individual users.
5. Edit the GPO in Group Policy Editor:
a. Expand Computer Configuration and right-click Administrative Templates under the
GPO.
b. Click Add/Remove Templates and click Add.
102
Install and Set Up
c. Browse to the .adm or .admx file that you imported or copied earlier and click
Open.
d. Click Close. This creates a Citrix folder and a Profile Management subfolder that
stores the settings from the .adm or .admx file.
103
Files Included in the Download
The following files are included in this release.
File Name
Description
profilemgt4.1.0_x86.msi
Installer for 32-bit systems
profilemgt4.1.0_x64.msi
Installer for 64-bit systems
ADM\ctxprofile4.1.0.adm
.Adm file used in Group Policy
ADM\ctxprofile4.1.0.admx
.Admx file used in Group Policy
ADM\ctxprofile4.1.0.adml
.Adml file used with .admx file in
Group Policy
welcome.html
List of documentation resources
CrossPlatform\*.xml
Definition files for supported
applications
In addition to DLLs and other files, you may need to be aware of the following files, which
are created by the installer in the install location (by default, C:\Program Files\Citrix\User
Profile Manager).
104
File Name
Description
UPMPolicyDefaults_V1Profile_en.ini
Profile management .ini file for English
Windows XP and Windows 2003
UPMPolicyDefaults_V2Profile_all.ini
Profile management .ini file for Windows
Vista, Windows 7 and Windows Server 2008
UserProfileManager.exe
Windows service carrying out functions on
computers managed by Profile
management
Creating the User Store
This topic helps you create the user store in a way that best suits your organization. In
addition to reviewing the information here, be sure to configure the path to the user store
as efficiently as possible (for example, by the sensible use of variables). For advice and
examples on that subject, see To specify the path to the user store.
Any Server Message Block (SMB) or Common Internet File System (CIFS) file share can be
used for the user store, but best practice is to ensure that the share:
•
Can be accessed by the accounts used with Citrix user profiles
•
Is large enough to store profile data
•
Is robust in case of disk or network failure
This diagram illustrates an example user store in relation to storage for redirected folder
items, the cross-platform settings store (on a separate file server), and Windows 7 virtual
desktops published with XenDesktop and running Microsoft Office. User devices that access
the virtual desktops are also shown for reference.
105
Creating the User Store
Recommendations on creating secure user stores are available in the article called Security
Recommendations for Roaming User Profiles Shared Folders on the Microsoft TechNet Web
site. These are minimum recommendations that ensure a high level of security for basic
operation. Additionally, when configuring access to the user store include the
Administrators group, which is required in order to modify or remove a Citrix user profile.
If your deployment includes multiple platforms, review the information on Version 1 and
Version 2 profile types in What Types of Profiles Should I Create?.The structure of the user
store is described in Profile Management Architecture.
Note: If an application modifies the access control list (ACL) of a file in the user's profile,
Profile management does not replicate those changes in the user store. This is consistent
with the behavior of Windows roaming profiles.
106
Testing Profile Management with a Local
GPO
Before deploying Profile management in a production environment, Citrix recommends
using a test environment. You can create this setup on a local machine with the supplied
.ini files, but a fully supported and easier means of transferring settings to the domain GPO
is based on a local installation and configuration of the ADM file on a device. Test logon and
logoff behaviors and make adjustments to the local GPO until satisfactory results are
obtained. You can perform tests safely this way if the device is a member of a production
OU because local policies are invoked where OU and domain policies do not exist or are not
configured. When using local policies, ensure no Profile management GPOs are used
anywhere else (for example, in the domain or sites).
In addition, where an administrator does not have access to or control of domain GPOs for
the configuration of the Profile management ADM file, local GPOs can be used as a
long-term solution. However, this introduces complexities into the environment, such as
ensuring that the Profile management ADM file is installed and correctly configured on each
device and the inability of domain users to maintain settings when accessing multiple
devices.
Important: For these reasons Citrix does not recommend the use of local GPOs as a
long-term, enterprise solution.
If you are testing on Windows 2008 domain controllers, consider using a Windows
Management Instrumentation (WMI) filter to temporarily restrict your configuration to just
one machine in an OU.
Testing the User Experience
Minimizing differences in the end user experience when accessing resources from various
devices is the ultimate goal when implementing a profile solution. Before Profile
management, the contents of users' registry and files might vary depending on the physical
device, profile configuration, and operating system. For this reason, Profile management
should be configured to address the differences between system installations on computers
the users will roam between.
You should therefore check user access to resources in ways that mimic your production
environment. These may include:
107
•
A client device with locally installed applications
•
A virtual desktop created with Citrix XenDesktop and including streamed or locally
installed applications
•
A Citrix XenApp application, either published on or streamed from a XenApp server
•
A Terminal Services client
Testing Profile Management with a Local GPO
Testing Operating System Variations
Users may access applications from different operating systems, and the variation between
them may create conflicting settings within a single user profile. You should understand the
differences between Version 1 and Version 2 profiles and how they affect your deployment,
since the variations are key to any profile solution. For more information on Version 1 and
Version 2 profiles, see About Profiles.
108
To remove Profile management
This procedure removes Profile management from a single computer. You must be an
administrator of the computer.
1. To avoid data loss, ensure all users are logged off.
2. From the list of installed programs in Add or Remove Programs (on Windows XP) or
Programs and Features (on Windows Vista and Windows 7), select Profile management
and click Remove (Windows XP) or Uninstall (Windows 7 and Windows Vista).
3. Click Yes.
4. Restart the computer.
You can also remove Profile management in unattended mode.
109
Upgrading Profile Management and
Migrating Profiles
This section of eDocs contains procedures for upgrading Profile management software and
information about transitioning your existing Windows user profiles to Citrix user profiles.
For example, you can easily upgrade from Version 3.x to Version 4.x using those
procedures.
Before upgrading, understand which Profile managament features and settings are available
in the release you are upgrading from and to. To review this information, see Profile
Management Policies. To facilitate upgrades from .ini files to Group Policy, that topic also
maps the setting names in the .ini file to those in the .adm and .admx files.
Do not configure Profile management (either in Group Policy or with the .ini file) while
upgrading. Separate these two tasks by upgrading your deployment first and then
configuring settings as required, ideally by answering the questions in Decide on a
configuration.
Tip: You can hotfix your deployment of Profile management 2.1.1 or later by upgrading to
the latest version. After upgrading, you can, if desired, enable any later feature.
Mixed Deployments
For deployments in which different versions of Profile management coexist, you should:
•
Minimize the time that a mixed deployment exists
•
Add the latest version's .adm or .admx file to each Group Policy Object on all domain
controllers, ensuring all new features are disabled and allowing time for the new
policies to propagate
•
Upgrade all computers to the latest version of Profile management before enabling any
policy
Mixed deployments that contain Versions 4.x and 3.2 are supported. However, treat such
deployments as a temporary state that exists during migration from the earlier version to
the later one.
Important: Deployments that contain Version 4.x with Version 2.1.1 or any earlier
version, including Citrix Technical Preview or beta releases, are unsupported. However, if
you cannot upgrade, and those versions must coexist in your deployment, you may find
the rest of this topic helpful.
110
Upgrade and Migrate
Mixed Deployments Involving Profile Management
2.1.1 or Earlier
The rest of this topic contains information on the coexistence of Profile management 2.1.1
or earlier, and Profile management 3.x or 4.x. It tells you how to migrate from one version
to the other. In this topic, the terms Version 2 and Version 4 are used as shorthand for
these versions.
Isolate each version in a separate OU and maintain separate user stores for the computers
running each version. Alternatively, if a single user store serves computers running both
versions, ensure all Version 4 settings are disabled until all the computers have been
upgraded to Version 4. After you enable any Version 4 setting in a "mixed" user store, users
can still log on to a computer that runs Version 2, but they receive a temporary Windows
user profile (not their network, Citrix user profile) and changes they make to that profile
are not saved. This is why you should consider mixed deployments to be temporary, and
minimize the time they exist before completing the upgrade.
Using separate OUs and user stores can be inconvenient. To avoid these constraints, you can
use one of the following two strategies. You configure each group in the appropriate version
of Profile management using the Processed groups setting. Strategy 2 is more work than
Strategy 1 because, with the former, you keep updating the Version 4 processed user groups
and maintain two sets of applications and desktops (but you can automate by exporting
application definitions from XenApp). The advantage is that you can take your time over
the migration.
Note: As an alternative to the following strategies, with Windows Server 2008 Active
Directory you can use WMI filtering to apply a GPO to a subset of computers in an OU, and
determine which version of Profile management is installed. This allows you to
automatically adjust which policy is applied, to match the version.
Strategy 1: One-off Migration
This scenario assumes that some downtime is acceptable. All computers are migrated at the
same time.
The migration strategy is:
1. Replace the Version 2 ADM file with the Version 4 file. The latter is compatible with the
earlier version, so Version 2 computers continue to operate normally.
2. Ensure all of the Version 4 settings are disabled. Do not rely on the default Not
enabled.
3. Start upgrading all the computers from Version 2 to Version 4. Fit this in with your
normal maintenance and update schedules. With one exception, Version 4 acts as
Version 2 until you enable any Version 4 setting.
The exception is as follows. It is rare but more likely to occur if this upgrade step is
staggered over a long time. If a user accesses their Citrix user profile from multiple
servers, multiple Version 4 sessions are created. For example, they first use a
workstation to access a virtual desktop on one server and then a laptop to access a
published application on another. Profile management must use the pending area for
111
Upgrade and Migrate
the second, laptop session. At this point, the entire OU is treated as a Version 4
deployment (albeit one without any configured Version 4 features) and
PmCompatibility.ini is updated to reflect this.
4. Optionally, set your Version 4 processed users group to include only the members of a
small pilot group. Wait for the AD Group Policy changes to propagate throughout the
network (for example, over a weekend). You do not need to prevent access for any
other users while this is happening. Back up the profiles of the pilot group. Then let the
pilot group test Profile management.
5. When you are happy with the pilot group results, ensure that you have backed up the
other users' profiles.
6. Use the next scheduled maintenance period to add the remaining users to the Version 4
processed users group. Allow sufficient time for the AD Group Policy changes to
propagate, and let the remaining users log on.
Strategy 2: Phased Migration
This scenario assumes that you cannot move all your machines or your users to the new
version in one go, so you select subsets of users that you migrate in batches. It suits
deployments with several datacenters or geographically distributed users.
The migration strategy is:
1. Replace the Version 2 ADM file with the Version 4 file. The latter is compatible with the
earlier version, so Version 2 computers continue to operate normally.
2. Ensure all of the Version 4 settings are disabled. Do not rely on the default Not
enabled.
3. Upgrade a few computers (the first batch) to Version 4. Alternatively, install Version 4
on new computers. By default, your Version 4 processed users group contains an empty
group, so no user is processed as a Version 4 user. Be aware of the exception described
in Strategy 1, which may also apply when you upgrade computers in a phased migration.
4. Publish new applications (using XenApp) or virtual desktops (using XenApp or
XenDesktop) from your Version 4 computers. These applications and desktops are
identical to the ones previously published from your Version 2 computers, except for
their names, which identify them as for use by Version 4 users.
5. The selected users in this batch log on to the applications or desktops (for example,
using Web Interface). They choose the new applications. (Use Web Interface to enforce
this, based on user name or group membership). As a result, their sessions run on the
Version 4 computers but they are processed with Version 2 settings.
6. Ensure that you have backed up all users' profiles.
7. Move the users out of the Version 2 processed users group and into the Version 4 group.
Wait for the AD Group Policy changes to propagate to the Version 4 computers. Next
time they log on, the users' sessions are processed with Version 4 settings.
8. Upgrade the next batch of computers and migrate the next batch of users, as above.
112
Upgrading Profile Management
This topic describes the process for upgrading your entire Profile management deployment
using Active Directory.
Important: It is important that you follow the order of the steps in this upgrade process.
Upgrade the software on all computers only after adding the new .adm or .admx file to
Group Policy. If you upgrade it beforehand, log files may be stored in two locations (one
containing log files for the old version and the other for the new version). This
consideration particularly affects XenDesktop deployments.
It is also important to perform upgrades during a scheduled maintenance period or at a
time when Active Directory replication allows the changes to propagate through your
deployment; typically this can take 24 hours.
The upgrade process involves:
1. Doing one of the following:
•
Creating a new Group Policy Object (GPO) and adding the new .adm or .admx file
to the new GPO, then reapplying the previous settings to the new GPO.
•
Upgrading an existing .adm or .admx file using the procedure in this topic.
2. Upgrading the .msi file on all computers using the procedure in this topic.
3. Applying the GPO.
To upgrade an existing .adm file
If any earlier version of the Profile management .adm file already exists in Group Policy,
you can upgrade it using this procedure. All policy settings in the earlier version are
preserved when you upgrade. For more information on this, see A new .adm or .admx file is
released with a new version of the software. What do I do? in Frequently Asked Questions
About Upgrading Profile Management.
1. On the domain controller, do one of the following:
•
Import the .adm file. The file is located in the GPO folder in the download package.
Copy the .admx file from the GPO folder in the download package to the
C:Windows\PolicyDefinitions folder and copy the .adml file to the
C:Windows\PolicyDefinitions\<localized folder>. For example, on English operating
systems, <localized folder> is en-US.
2. On the computer you use to configure Profile management, open Active Directory Users
and Computers.
•
3. In the Group Policy Object Editor, right-click Administrative Templates and select
Add/Remove Templates.
113
Upgrading Profile Management
4. Select the existing version of the Profile management .adm file (for example,
ctxprofile4.0.0), click Remove and then Close. The Administrative Templates\Citrix
folder is deleted.
5. Right-click Administrative Templates and select Add/Remove Templates a second time.
6. Click Add, browse to the location of the new version of the .adm or .admx file, select
it, and click Close. The new file is imported but the old settings are retained.
To upgrade the .msi file
Citrix recommends that the same version of Profile management is installed on all user
devices and the same version's .adm or .admx file is added to each Group Policy Object on
all domain controllers. This prevents corruption of profile data, which may result when
different user store structures (from different versions) exist.
For this reason, Citrix recommends upgrading all computers to the latest version of Profile
Management before enabling any new setting. To check whether a setting is new in the
version you are using, see Profile Management Policies.
1. Ensure all users are logged off the computers.
2. Install this version of Profile management over the existing version by running the .msi
file on each computer. For more information, see Installing and Setting Up Profile
Management.
114
Considerations When Upgrading .Ini Files
If you edited the .ini file in an earlier version of Profile management and upgrade to this
version, the software detects that the file was edited and, by default, does not overwrite
it. If you want to preserve your .ini file settings but also make use of the new settings in
this version, you must do one of the following:
115
•
Manually add the new settings from this version's .ini file to your edited .ini file
•
Save a copy of the earlier version's .ini file, use the OVERWRITEINIFILES=yes
command-line option to force an overwrite of the file during the upgrade, and add your
saved settings to the upgraded .ini file
Frequently Asked Questions About
Upgrading Profile Management
This topic contains questions and answers about upgrading to Citrix Profile management
4.x.
For answers to frequently asked questions about other subjects, see Frequently Asked
Questions About Using Profiles On Multiple Platforms.
For more information on upgrading Profile management and how different versions coexist,
see http://community.citrix.com/display/ocb/2011/02/18/Case+Study+-+XD+upgrade+from
+UPM+2.x+to+3.x.
What important information should I review before
upgrading to Version 4.x?
Do not upgrade from versions earlier than Version 2.x. Upgrading from Version 2.1.1 is
recommended because it has logic to detect when it is used with newer versions, and
operates appropriately.
What is the upgrade procedure?
Follow one of the procedures in Upgrading Profile Management and Migrating Profiles.
What are the recommendations for testing Profile
management?
Test Profile management 4.x before rolling out the software in a production environment.
Your pilot should use a separate Organizational Unit (OU), and should not use the same
accounts as users in the production environment. It should at least use a different user
store.
For upgrades from Version 2.x, note that Version 4.x marks profiles in the user store with
Version 4.x tags because it uses a schema newer than that used in Version 2.0. Version
2.1.1 can detect the new schema but cannot process it, so it tries to load a temporary
profile to avoid overwriting Version 4.x profiles. This is not desirable in a production
environment, so you are recommended to use a different user store for testing Version 4.x.
116
Frequenly Asked Questions About Upgrading
A new .adm file is released with a new version of the
software. What do I do?
The .adm files are designed so you can replace ones from earlier releases; the existing
settings are preserved. You can replace the files in the same Group Policy Object (GPO).
You do not have to create a new GPO, but if you prefer to do so see the instructions in
Upgrading Profile Management.
For upgrades from Version 2.x, you must not enable any of the new features in Profile
management 4.x while the upgrade is in progress. Version 4.x has a different schema, which
would be corrupted if Version 2.x wrote to it. A compatibility check was therefore
introduced in Profile management 2.1.1 to help avoid this corruption in the event that this
version runs in an environment that also includes a later version.
During the upgrade process, ensure that Profile management is not running. Some machines
have the old configuration and others have the new one, which can lead to inconsistencies
or temporary profiles being assigned.
When all upgrades are completed and no Profile management 2.x systems are present, it is
safe to enable the desired version 4.x features in the GPO. Do this during a scheduled
maintenance period, and allow time (typically 24 hours) for the Active Directory (AD)
changes to propagate.
How do I roll back Profile management if I upgraded
incorrectly?
This topic describes rolling back from Version 4.x to any earlier version.
Important: Rolling back to an earlier version has not been officially tested and can be
difficult.
The most important step is to revert the schema, which must be done for every user's
profile while all users are logged off (during a scheduled downtime).
Each user's profile in the user store contains a file in the root directory called
PmCompatibility.ini, which must be deleted. After all of these files are deleted, you can
revert to the earlier version and restart the deployment with that version's .adm file.
If the PmCompatibility.ini files are not deleted, the earlier version checks, finds that
Version 4.x systems also use the user store, and gives the users a temporary profile. Any
users who find they have been given a temporary profile must alert their support desk, who
can tell them to log off. The support desk can then manually delete the .ini file from the
user store.
117
To migrate user profiles
This topic contains instructions on turning Citrix user profiles into Windows roaming
profiles. It also describes how to remove Citrix user profiles from personal vDisks (a Citrix
XenDesktop feature) so Profile management can process them.
For more information on migration strategies, see Upgrading Profile Management and
Migrating Profiles.
To migrate to roaming profiles
You can migrate Citrix user profiles to Windows roaming profiles at any time. This involves
moving profile data to a network location where the roaming profiles will be stored. After
migration, Profile management takes no part in processing user logons or application
settings.
1. Ensure all users are logged off.
2. Remove the Profile Management Service from all of the computers that are managed by
the software.
3. In the user store, move the contents of \UPM_Profile to your roaming profile location.
You do not have to move the contents of the cross-platform settings store.
4. In addition, for Version 1 profiles only, remove the _upm_var suffix from all subfolders
of \UPM_Profile.
Note: You may find that scripting simplifies this step.
To migrate from personal vDisks
If you use the Personal vDisk feature in XenDesktop, by default user profiles are stored on
the Personal vDisk's P: drive not the virtual desktop's C: drive. If instead you want Citrix
Profile management (not the Personal vDisk) to process the profiles, you adjust this default
when installing the Virtual Desktop Agent by modifying the Registry on the master image
used for a new catalog. In this scenario, because the catalog is new, no users have logged
on, so no profiles are stored on the P: drive.
Important: An alternative scenario occurs if you enable Profile management on machines
in existing catalogs with Personal vDisks. Because the catalog is already in use, logons will
already have taken place and profiles will be present on the P: drive (and will remain
there after you modify the Registry). You must therefore adjust the default differently.
Issues that indicate the presence of profiles on P: drives while Profile management is
enabled include users having to reset their wallpaper, having to reconfigure their
applications, or receiving temporary profiles.
Follow these instructions to adjust the default in this alternative scenario.
118
To migrate user profiles
1. Schedule a maintenance downtime for the virtual machines whose profiles you want to
migrate.
2. Create a startup script (or edit your existing script) and include a command to run
Delprof.exe, a profile deletion tool for Windows XP from Microsoft, or Delprof2.exe, a
similar tool for later operating systems from Sepago. Follow the run command by a
shutdown command:
\\<share name>\delprof.exe /q /i
shutdown /s /t 0
3. On the master image, change the following Registry setting from 1 to 0:
Caution: Editing the Registry incorrectly can cause serious problems that may require
you to reinstall your operating system. Citrix cannot guarantee that problems
resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor
at your own risk. Be sure to back up the registry before you edit it.
HKLM\Software\Citrix\personal vDisk\Config\EnableUserProfileRedirection
4. Update the master image's inventory using the instructions in To update master images
that use personal vDisks.
5. During the scheduled downtime, distribute the master image to the virtual machines,
and ensure they restart. At that point, the script runs, deletes the profiles from the P:
drives, and shuts down the machines.
6. When all of the machines are shutdown, delete the startup script (or the line you added
to your existing script).
7. Start all of the machines or let users log on. From this point, profiles are stored on the
virtual desktops' C: drives.
Note: To migrate profiles in the reverse direction so they are managed by the personal
vDisk (not Profile management), follow these instructions but change the Registry setting
of EnableUserProfileRedirection from 0 to 1. This loads the profiles on to the personal
vDisk's P: drive.
119
Administering Profile Management
This section contains procedures for configuring policies in the .adm or .admx file.
If you have not already done so, determine which policy settings you need to adjust by
answering the questions in Decide on a configuration.
Important: The following policy generally does not require configuration. Unless
instructed to by Citrix personel, leave it in its default settings.
Policy: Number of retries when accessing locked files
It is most unlikely that you will need to enable this policy.
During logoff, if there are any locked files, the Profile Management Service tries the
specified number of times to access the files and copy them back to the user store. But
typically the Service only needs to read (not write to) the files for the copy operation to
succeed. If any locked files exist, the Service does not delete the local profile and instead
leaves it "stale" (as long as the appropriate policy was enabled).
Citrix recommend that you do not enable this policy.
120
Configuration Precedence
You can configure Profile management using Group Policies and .ini files. Configuration
settings are applied as follows:
1. Settings defined by Group Policies take precedence. The .ini file will only be queried if
a policy setting is set to Not Configured.
Note: If you apply a Group Policy Object selectively to sites and domains within an
Organizational Unit, a further precedence applies. This is documented at
http://technet.microsoft.com/en-us/library/cc785665(WS.10).aspx. In addition, note
that domain and OU Group Policies take precedence over local policies.
2. Where a setting is not defined by a policy, Profile management tries to read the setting
from the .ini file.
3. If a setting is not configured by a group policy or in the .ini file, the default setting is
used.
There may be situations where you want to configure the same setting differently in Group
Policy and the .ini file, for example when you want to activate default logging with a Group
Policy setting but activate verbose logging using the .ini file on a computer that you use for
troubleshooting.
121
To choose a migration policy
When a user first logs on after Profile management is enabled, no Citrix user profile for
them exists but you can migrate their existing Windows user profile "on the fly" during
logon. Decide which existing profile (roaming, local, or both) is copied and used in all
further processing.
For more information on planning a migration strategy, see Migrate profiles? New profiles?.
In addition, review the system requirements for migrating existing profiles in System
Requirements for Profile Management.
1. Under Profile Management, open the Profile handling folder.
2. Double-click the Migration of existing profiles policy.
3. Select Enabled.
4. Select one of the following options from the drop-down list:
•
Local. Use this setting if you are migrating local profiles.
•
Local and Roaming. Use this setting if you are migrating local and roaming profiles
(including Remote Desktop Services profiles, formerly known as Terminal Services
profiles).
Roaming. Use this setting if you are migrating roaming profiles or Remote Desktop
Services profiles.
If Migration of existing profiles is not configured here, the value from the .ini file is used. If
this setting is not configured here or in the .ini file, existing local and roaming profiles are
migrated. If this setting is disabled, no profile is migrated. If this setting is disabled and no
Citrix user profile exists in the user store, the existing Windows mechanism for creating
new profiles is used as in a setup without Profile management.
•
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
122
To specify a template profile
By default, new Citrix user profiles are created from the default user profile on the
computer where a user first logs on. Profile management can alternatively use a centrally
stored template when creating new profiles. The template can be a standard roaming,
local, or mandatory profile that resides on any network file share.
Typically, a user who is assigned a profile created for the first time receives the Default
User profile of the Windows device they log on to. This may acceptable, and it means any
variation in different devices' Default User profiles results in differences in the base profile
created for the user. This means you can regard your selection of a template profile as a
Global Default User profile.
As prerequisites:
•
Ensure the template profile does not contain any user-specific data
•
Ensure users have read access to the template profile
•
To convert a mandatory profile to a template profile, rename the file NTUSER.MAN to
NTUSER.DAT
For information on creating template profiles by customizing existing Microsoft profiles, see
http://support.microsoft.com/kb/959753and http://support.microsoft.com/kb/973289.
1. Under Profile Management, open the Profile handling folder.
2. Double-click theTemplate profile policy.
3. Select Enabled.
4. In Path to the template profile, enter the location of the profile you want to use as a
template. This is the full path to the folder containing the NTUSER.DAT registry file and
any other folders and files required for the template.
Important: If the path consists only of NTUSER.DAT, ensure that you do not include
the file name in the path. For example, with the file
\\myservername\myprofiles\template\ntuser.dat, set the location as
\\myservername\myprofiles\template.
Use absolute paths, which can be UNC paths or paths on the local machine. You can use
the latter, for example, to specify a template profile permanently on a Citrix
Provisioning Services image. Relative paths are not supported.
Note that this policy does not support expansion of Active Directory attributes, system
environment variables, or the %USERNAME% and %USERDOMAIN% variables.
5. Optionally, select a check box to override any existing Windows user profiles. If a user
has no Citrix user profile, but a local or roaming Windows user profile exists, by default
the local profile is used (and migrated to the user store, if this is not disabled). This can
be changed by enabling the checkbox Template profile overrides local profile or
Template profile overrides roaming profile.
123
To specify a template profile
If Template profile is not configured here, the value from the .ini file is used. If this setting
is not configured here or in the .ini file, no template is used.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
124
To resolve conflicting profiles
Conflicts between local Windows user profiles and Citrix user profiles (in the user store) can
occur when you add Profile management to an existing deployment. In this scenario, you
must determine how the data in the local Windows profile is managed.
1. Under Profile Management, open the Profile handling folder.
2. Double-click the Local profile conflict handling policy.
3. Select Enabled.
4. Select one of the following options from the drop-down list:
•
Use local profile. Profile management processes the local Windows user profile but
does not change it in any way.
•
Delete local profile. Profile management deletes the local Windows user profile and
then imports the Citrix user profile from the user store.
Rename local profile. Profile management renames the local Windows user profile
(for backup purposes) and then imports the Citrix user profile from the user store.
If Local profile conflict handling is not configured here, the value from the .ini file is used.
If this setting is not configured here or in the .ini file, existing local profiles are used.
•
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
125
To enable Profile management
By default, to facilitate deployment, Profile management does not process logons or
logoffs. Enable Profile management only after carrying out all other setup tasks and testing
how Citrix user profiles perform in your environment.
1. Under Profile Management, double-click the Enable Profile management policy.
2. Select Enabled.
If this setting is not configured here, the value from the .ini file is used. If this setting is not
configured here or in the .ini file, Profile management does not process Windows user
profiles in any way.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
126
About Profile Management .Ini Files
Default Configuration
Profile management comes with a default configuration stored in .ini files. The .ini files
must be located in the installation folder so that the Profile Management Service can
recognize them. The default configuration is suitable for most environments. It processes
the profiles of all users in all groups.
To find the .ini file used by each operating system, see Files Included in the Download. If
you are not sure which file is used, examine the log file and search for the text Reading
from policy defaults file.
If you are configuring a non-English version of Windows XP and Windows Server 2003, you
must create an appropriate language version of the .ini file using
UPMPolicyDefaults_V1Profile_en.ini. Rename a copy of this file to reflect your language (for
example, UPMPolicyDefaults_V1Profile_es.ini for Spanish) and localize the folder names.
Use these file names:
•
For French operating systems, UPMPolicyDefaults_V1Profile_fr.ini
•
For German operating systems, UPMPolicyDefaults_V1Profile_de.ini
•
For Spanish operating systems, UPMPolicyDefaults_V1Profile_es.ini
•
For Japanese operating systems, UPMPolicyDefaults_V1Profile_ja.ini
•
For Simplified Chinese operating systems, UPMPolicyDefaults_V1Profile_zh-CN.ini
The operating system language uses the appropriate version of the file, so if that version is
not present Profile management might not work as expected.
The same .ini file is used for all languages on Windows Vista and Windows Server 2008.
Modifying .Ini Files
If you add entries to an .ini file, ensure the variables and values have the correct format.
Flags (on/off indicators) must be of this form:
<variable>=<value>
A value of 1 enables a setting and any other value or no value disables it. For example, the
following entry enables the ServiceActive setting:
ServiceActive=1
Any of the following entries disable the setting:
ServiceActive=ON
ServiceActive=OFF
127
About Profile Management .Ini Files
ServiceActive=TRUE
ServiceActive=FALSE
ServiceActive=
List entries must be of this form:
<value>=
Do not append 1 after the equals sign. For example, the following entries specify files to be
synchronized:
[SyncFileList]
Local Settings\Application Data\Microsoft\Office\*.qat=
Local Settings\Application Data\Microsoft\Wallpaper1.bmp=
Changes to Group Policy settings take effect when a manual or automatic policy refresh
occurs on the target computers. Changes to the .ini file take effect when you issue the
command gpupdate /force, which is recommended, or when you restart the Profile
Management Service on the target computers.
128
Including and Excluding Items
This topic describes the process that Profile management uses to include and exclude items
from users' profiles. You need to understand this process if you decide to modify the default
inclusion or exclusion lists to improve the logon and logoff experience of your users. To help
you determine whether this is required, see Which applications?
For example, you might include Microsoft Word because it is a highly customizable and
frequently used application that should present the same experience to roaming users
however it is accessed. Conversely, you might exclude an enterprise application because it
is infrequently used by some groups so its profile data does not need to be downloaded at
each logon and logoff.
By default, all files and folders in local profiles are synchronized with the user store. You
can specify files and folders that you do not want to synchronize by adding them to an
exclusion list. If you exclude a folder, you can specify subfolders of it that you do want to
synchronize by adding them to an inclusion list.
You can include and exclude:
•
Files and folders contained inside profiles.
•
Files and folders that store personalization settings outside profiles.
•
Registry entries in the HKCU hive that store personalization settings. Entries in the
HKLM hive are not processed by default and cannot be configured to do so.
Before Including and Excluding Items
Before tuning the contents of your users' profiles, consider using the set of built-in Windows
Performance Monitoring (Perfmon) counters. These provide insights into the behavior of
your profiles. Available counters include measurements of the profile size and the time
taken to create a Citrix user profile on the local computer.
You may need to decide whether to cache profiles locally (on the computers that run
Profile management). Factors that affect the decision include the Citrix products in your
deployment, the available space on the local computers, and the number of users in the
deployment. For more information on this decision, see Server or workstation?
Files and Folders
All included and excluded folder names are language specific. However, folder names in the
user store are in a format independent of the operating system language.
You can synchronize files or folders on disks that are treated as local by the operating
system. You cannot synchronize files or folders on network mapped drives.
129
Including and Excluding Items
The Registry
For existing users, the entire HKCU hive is copied to the user store. For new users, the hive
of their Microsoft local, roaming, default, or template profile is copied. Inclusions are
added and exclusions are removed from the hive when changes are made to the user store.
Changes to registry key values are not preserved. This is by design and supports the typical
use case in which an administrator provides users with a template profile containing a
registry value that should not be changed (for example, in order to standardize the
functioning of a particular application). If you have a template profile that contains
unwanted keys, use a tool such as Profile Nurse from Sepago to eliminate them from the
user store.
About Exclusions
Exclusions are processed at logoff not logon. They do not delete data from the user store
but prevent new data from being written to it.
Other than the default exclusions, typically you do not need to exclude any items when you
first roll out Profile management. Later, as you track application performance and gather
feedback from users, you may need to exclude items if settings from multiple applications
clash or if a user's NTUSER.DAT file grows very large as a result of collecting unneeded
settings.
Do not add redirected folders as exclusions.
Important: Citrix recommends that you exclude the folder AppData\Local and
AppData\LocalLow from synchronization. If you do not, a very large amount of data may
be transferred over the network and users may experience logon delays. These folders
are not synchronized by standard Windows roaming profiles. In the default configuration,
the exclusion lists contain these folders.
Inclusion and Exclusion Rules
The following rules are used when Profile management includes and excludes files, folders,
and registry keys:
1. All items are included by default
2. If the same path is configured as both an inclusion and an exclusion, the inclusion takes
precedence
3. An inclusion takes precedence over an exclusion in the same folder
4. An inclusion takes precedence over an exclusion higher up in the folder hierarchy
5. An exclusion takes precedence over an inclusion higher up in the folder hierarchy
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.
130
Including and Excluding Items
131
Default Inclusions and Exclusions
This topic describes the default items that Profile management includes in and excludes
from its processing. Depending on the applications in your deployment, additional
(non-default) items may be required. To help you determine which additional items you
need to include or exclude, see Which applications?
Important: If you use Group Policy rather than .ini files (or you are rolling out a Group
Policy deployment after a successful test with .ini files), note that, unlike the installed
.ini file, no items are included or excluded by default in the .adm or .admx file. This
means you must add the default items manually to the file. These are shown in the tables
in this topic. Note the following:
•
Use Profile Management Policies to map setting names in the .ini file and the .adm file
•
When pasting inclusions and exclusions from the .ini file, remove the trailing = (equals
sign) from each item
•
Do not add an initial backslash to inclusions and exclusions
Registry Inclusion List
Default Value
Notes
<empty>
All entries in the HKCU hive are included
by default.
All entries in the HKCU hive are included by default.
Registry Exclusion List
Default Value
<empty>
No entries in the HKCU hive are excluded by default.
Folder Inclusion List
Default Value
<empty>
All folders in the profile are included by default.
Folder Exclusion List
Folders in this table are excluded from synchronization.
132
Default Inclusions and Exclusions
Default Value
Windows XP and Windows Server 2003
Local Settings\Temporary Internet Files
Local Settings\Application Data\Microsoft\CD Burning
Local Settings\Application Data\Google\Chrome\User Data\Default\Cache
Application Data\Sun\Java\Deployment\cache
Application Data\Sun\Java\Deployment\log
Application Data\Sun\Java\Deployment\tmp
Local Settings\Application Data\Microsoft\Outlook
Local Settings\Application Data\Microsoft\OneNote
Local Settings\Temp
Windows Vista, Windows 7, and Windows Server 2008
$Recycle.Bin
AppData\LocalLow
AppData\Local\Microsoft\Windows\Temporary Internet Files
AppData\Local\Microsoft\Windows\Burn
AppData\Local\Microsoft\Windows Live
AppData\Local\Microsoft\Windows Live Contacts
AppData\Local\Microsoft\Terminal Server Client
AppData\Local\Microsoft\Messenger
AppData\Local\Microsoft\OneNote
AppData\Local\Microsoft\Outlook
AppData\Local\Windows Live
AppData\Local\Temp
AppData\Local\Sun
AppData\Local\Google\Chrome\User Data\Default\Cache
AppData\Local\Google\Chrome\User Data\Default\Cached Theme Images
AppData\Roaming\Microsoft\Windows\Start Menu
AppData\Roaming\Sun\Java\Deployment\cache
AppData\Roaming\Sun\Java\Deployment\log
AppData\Roaming\Sun\Java\Deployment\tmp
File Inclusion List
Default Value
<empty>
133
Default Inclusions and Exclusions
All files in the profile are included by default.
File Exclusion List
Default Value
<empty>
No files in the profile are excluded by default.
134
To include and exclude items
As a prerequisite, ensure that you understand how inclusions and exclusions work. For
information on this, see Including and Excluding Items. For information on the default
included and excluded items, see Default Inclusions and Exclusions.
If you are configuring the behavior of items that are stored outside of a user profile (for
example, as a result of legacy applications), read Combining Inclusions and Exclusions.
To include items
Tip: If desired, you can include specific top-level folders. In a collaborative environment,
this has the advantage of signaling critical folders to other administrators.
1. Under Profile Management > Registry, double-click the Inclusion list policy.
2. Select Enabled.
3. Add any profile-related registry keys in the HKCU hive that you want to be processed
during logoff. Example: Software\Adobe.
4. Under Profile Management > File system > Synchronization, double-click the Directories
to synchronize policy.
5. Select Enabled.
6. Add any folders that you want Profile management to process but that are located
outside the user profile or in excluded folders.
Profile management synchronizes each user's entire profile between the system it is
installed on and the user store. It is not necessary to include subfolders of the user
profile by adding them to this list. Paths on this list can be absolute or relative.
Relative paths are interpreted as being relative to the user profile. Examples:
•
Desktop\exclude\include. Ensures that the subfolder called include is synchronized
even if the folder called Desktop\exclude is not.
C:\MyApp\data. Ensures that the folder called data is synchronized even though the
folder called C:\MyApp is not (because it is not part of the profile).
7. Under Profile Management > File system > Synchronization, double-click the Files to
synchronize policy.
•
8. Select Enabled.
9. Add any files that you want Profile management to process but that are located outside
the user profile or in excluded folders.
Profile management synchronizes each user's entire profile between the system it is
installed on and the user store. It is not necessary to include files in the user profile by
adding them to this list.
135
To include and exclude items
This setting can be used to include files outside the user profile in the synchronization
process. In addition, it allows for the inclusion of files below excluded folders. Paths on
this list can be absolute or relative. Relative paths are interpreted as being relative to
the user profile. Wildcards can be used but are only allowed for file names. Wildcards
cannot be nested and are applied recursively. Examples:
•
AppData\Local\Microsoft\Office\Access.qat. Specifies a file below a folder that is
excluded in the default configuration.
•
C:\MyApp\myapp.cnf. Specifies the file myapp.cnf in the folder C:\MyApp\.
AppData\Local\MyApp\*.cfg. Specifies all files with the extension .cfg in the profile
folder AppData\Local\MyApp and its subfolders.
If Inclusion list is not configured here, the value from the .ini file is used. If this setting is
not configured here or in the .ini file, all of the HKCU hive is processed.
•
If Directories to synchronize is not configured here, the value from the .ini file is used. If
this setting is not configured here or in the .ini file, only non-excluded folders in the user
profile are synchronized. Disabling this setting has the same effect as enabling it and
configuring an empty list.
If Files to synchronize is not configured here, the value from the .ini file is used. If this
setting is not configured here or in the .ini file, only non-excluded files in the user profile
are synchronized. Disabling this setting has the same effect as enabling it and configuring
an empty list.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
136
To include and exclude items
To exclude items
1. Under Profile Management > Registry, click the Exclusion list policy.
2. Select Enabled.
3. Click Show and add any registry keys in the HKCU hive that you do not want to be
processed during logoff. Example: Software\Policies.
4. Under Profile Management > File system, double-click the Exclusion list - directories
policy.
5. Select Enabled.
6. Add any folders that you do not want Profile management to process. Folder names can
be specified as absolute paths or as paths relative to the user profile (%USERPROFILE%).
Use that variable to locate the profile but do not enter the variable itself in this policy.
Omit initial backslashes from paths.
Examples:
•
Desktop. Does not process the Desktop folder in the user profile.
•
MyApp\tmp. Does not process the folder %USERPROFILE%\MyApp\tmp.
7. Under Profile Management > File system, double-click the Exclusion list - files policy.
8. Select Enabled.
9. Add any files that you do not want Profile management to process. File names can be
specified as absolute paths or as paths relative to the user profile (%USERPROFILE%).
Use that variable to locate the profile but do not enter the variable itself in this policy.
Wildcards are allowed and are applied recursively.
Examples:
•
*.tmp ignores all temp files in %USERPROFILE%.
appData\roaming\MyUnwantedApp*.tmp ignores all files with the extension .tmp in
%USERPROFILE% for the specified application.
If Exclusion list is disabled, no registry keys are excluded. If this setting is not configured
here, the value from the .ini file is used. If this setting is not configured here or in the .ini
file, no registry keys are excluded.
•
If Exclusion list - directories is disabled, no folders are excluded. If this setting is not
configured here, the value from the .ini file is used. If this setting is not configured here or
in the .ini file, no folders are excluded.
If Exclusion list - files is disabled, no files are excluded. If this setting is not configured
here, the value from the .ini file is used. If this setting is not configured here or in the .ini
file, no files are excluded.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
137
Using Wildcards
You can use DOS-style wildcard characters, such as ? (question mark) and * (asterisk), in
policies that refer to files (for example, file inclusion and exclusion lists). The ? (question
mark) matches a single character. The * (asterisk) matches zero or more characters.
Wildcards work recursively. Ensure you specify a valid path when using wildcards.
Policies that support wildcards do not support any other type of processing, such as the use
of environment variables or Active Directory attributes. You cannot use wildcards in policies
that refer to folders or registry entries.
Examples
The wildcard <path name>\h*.txt matches house.txt, h.txt, and house.txt.txt, but does not
match ah.txt.
The wildcard <path name>\a?c.txt matches abc.txt, but does not match ac.txt.
The wildcard <path name>\a?c*d.txt matches abcd.txt and abccd.txt, but does not match
acd.txt.
138
Combining Inclusions and Exclusions
With the release of the Personal vDisk feature of XenDesktop, the ability to synchronize and
exclude folders outside a user's profile folder (referred to as extended synchronization) has
been removed. Personal vDisk lets you store files and folders outside the profile, and is
recommended by Citrix instead of extended synchronization. For information on Personal
vDisk, see the XenDesktop documentation. Including and excluding files and folders inside
the profile is still supported. For information on this feature, see Including and Excluding
Items.
If you are using a version of Profile management earlier than Version 4.1, you can combine
inclusions and exclusions to ensure that no extraneous items are processed by Profile
management. Although this sounds like a good way of improving the efficiency of profile
synchronization for any deployment, in practice you only need to combine inclusion lists
and exclusion lists in some situations, in particular with legacy applications.
Combining inclusions and exclusions is not intended to manage multi-user access to these
files or folders (for example, it is not designed to support an application that is not
multiuser aware) and is not intended to be a file and folder synchronization mechanism (for
example, one that allows you to synchronize the entire contents of C:\Docs across
machines).
To combine inclusions and exclusions you:
•
Add to an inclusion list a subfolder of a folder that is on an exclusion list
•
Add to an exclusion list a subfolder of a folder that is on an inclusion list
No other configuration is required.
Note: Inclusions take precedence over exclusions, so if the same folder appears in both
lists it is included.
Supported Scenarios
The supported scenarios are all based on a single-user with exclusive access to a
workstation environment, but a native workstation environment is also supported where the
license permits. Typically, these involve XenDesktop deployments without personal vDisks
and a version of Profile management earlier than Version 4.1.
Scenario 1: Legacy Applications
Your Windows XP users have an application called MyApp that creates and stores many
supporting files in the C:\Application Data\MyApp folder. A subfolder called Stuff contains
temporary data that does not need to be synchronized.
You add C:\Application Data\MyApp to the inclusion list and add C:\Application
Data\MyApp\Stuff folder to the exclusion list. At logoff, the files in the Stuff folder remain
on the user device and are not transferred to the user store. If you configure local profiles
139
Combining Inclusions and Exclusions
not to be cached, this temporary data is deleted at logoff along with the cached profile.
Important: You must use absolute paths in this scenario because the legacy application
stores its data outside users' profiles. A well behaved application would store the files
inside the profiles, for example in C:\Documents and Settings\<user>\Application Data.
Scenario 2: Persistent Virtual Desktops
This scenario covers dedicated and pooled-static virtual desktops created with XenDesktop.
It also covers a domain workstation, not shared with any other user.
Combining inclusions and exclusions allows one or more folders outside the user's profile to
be synchronized. For example, assume we have an application App1 which stores its
personalization in two folders C:\App1 and C:\App1Blobs.
Prior to a user logging on and creating their profile you must configure Profile management
so that all the folders are synchronized. Inclusion and exclusion combinations do not
support the addition of further folders after logon, once the user's profile has been created.
It is essential to pilot the application before deploying it to a production environment.
Once inclusion and exclusion combinations have been configured as described above, the
user can log on and create (or migrate) their profile. The use of pre-installed applications
(for example, using a standard image with all applications already installed) are supported,
as are applications that are installed by the user after the profile has been created.
Scenario 3: Non-Persistent Virtual Desktops
This scenario is very similar to Scenario 2, and covers pooled-random virtual desktops
created with XenDesktop. In this supported configuration, the application will have been
installed as part of a shared image, but will not have been run, so that personalization
takes place on the first use of the application.
Unsupported Scenarios
In addition to any deployment involving Profile management 4.1, other scenarios - those
typically involving shared access by multiple users to a workstation, or simultaneous access
by multiple users to a server - are not supported. Specific examples of unsupported
scenarios include:
•
Domain workstations, including domain-joined XenDesktop workstations, shared by
multiple users. Fast User Switching disabled.
•
Domain servers, concurrently shared with other users, whether Remote Desktop
Services and XenApp environments.
•
Domain workstations. Fast User Switching enabled.
These unsupported scenarios all involve a folder or folders being shared by multiple users,
which gives rise to privacy and security issues, as well as profile bloat.
140
Combining Inclusions and Exclusions
More Information
The scenarios described in this topic may be further constrained by any End User License
Agreements (EULAs) that apply to the Citrix products in your deployment.
141
To specify the path to the user store
Before specifying the path to the user store, refer to Profile Management Architecture and,
if relavant to your deployment, understand the effect of:
•
Storing multilingual profiles.
•
Combining inclusions and exclusions. For information on this, see Combining Inclusions
and Exclusions.
1. Under Profile Management, double-click the Path to user store policy.
2. Select Enabled and enter the path to the directory (the user store) in which the user
settings (registry changes and synchronized files) are saved.
The path can be:
•
A relative path. This must be relative to the home directory, which is typically
configured as the #homeDirectory# attribute for a user in Active Directory (AD).
•
A UNC path. This typically specifies a server share or a DFS namespace.
•
Disabled or unconfigured. In this case, a value of #homeDirectory#\Windows is
assumed.
The following types of variables can be used for this setting:
•
System environment variables enclosed in percent signs (for example, %ProfVer%). Note
that system environment variables generally require additional setup. For information
on this, see Administering Profiles Within and Across OUs.
•
Attributes of the AD user object enclosed in hashes (for example, #sAMAccountName#).
•
Profile management variables. These require Version 4.0 or later. For more
information, see Profile Management Variables.
User environment variables cannot be used, except for %username% and %userdomain%. You
can also create custom AD attributes to fully define organizational variables such as
location or users. Attributes are case-sensitive.
Examples:
•
\\server\share\#sAMAccountName# stores the user settings to the UNC path
\\server\share\JohnSmith (if #sAMAccountName# resolves to JohnSmith for the current
user)
•
\\server\profiles$\%USERNAME%.%USERDOMAIN%\!CTX_PROFILEVER!!CTX_OSBITNESS!
might expand to \\server\profiles$\JohnSmith.Finance\v2x64
Important: Whichever attributes or variables you use, check that this setting expands to
the folder one level higher than the folder containing NTUSER.DAT. For example, if this
142
To specify the path to the user store
file is contained in \\server\profiles$\JohnSmith.Finance\v2x64\UPM_Profile, set the path
to the user store as \\server\profiles$\JohnSmith.Finance\v2x64 (not the \UPM_Profile
subfolder).
This diagram illustrates the components of a typical path to the user store that incorporates
AD attributes, environment variables, and Profile management variables.
For more information on using variables when specifying the path to the user store, see the
following topics:
•
Sharing Citrix User Profiles on Multiple File Servers
•
Administering Profiles Within and Across OUs
•
High Availability and Disaster Recovery with Profile Management
For information on managing system environment variables in Windows XP, see
http://support.microsoft.com/kb/310519.
If Path to user store is disabled, the user settings are saved in the Windows subdirectory of
the home directory.
If this setting is not configured here, the setting from the .ini file is used. If this setting is
not configured here or in the .ini file, the Windows directory on the home drive is used.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
143
To define which groups' profiles are
processed
You can define the users whose profiles are processed. If you do not define any groups, all
Windows user profiles are processed. You can use both computer local groups and domain
groups (local, global and universal). Specify domain groups in the format <DOMAIN
NAME>\<GROUP NAME>.
1. Under Profile Management, double-click the Processed groups policy.
2. Select Enabled.
3. Click Show.
4. Add the groups containing the users whose profiles you want Profile management to
process.
If this setting is configured here, Profile management processes only members of these user
groups. If this setting is disabled, Profile management processes all authenticated domain
users.
If this setting is not configured here, the value from the .ini file is used. If this setting is not
configured here or in the .ini file, members of all user groups are processed.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
144
To store certificates
Follow this procedure to save personal certificates that have been imported into the
certificate store during a session. By default, certificates are automatically synchronized.
1. Add the path Application Data\Microsoft\SystemCertificates\My to the Directories to
synchronize setting. The operating system language determines the Application Data
folder in this location. If a policy is used to configure multi-language systems, add each
language's location to the list.
Example
On an English system, the path is Application Data\Microsoft\SystemCertificates\My. On a
German system it is Anwendungsdaten\Microsoft\SystemCertificates\My.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
145
To stream user profiles
With the Citrix streamed user profiles feature, files and folders contained in a profile are
fetched from the user store to the local computer only when they are accessed by users
after they have logged on. Registry entries, items that you have included from outside the
profile, and any files in the pending area are exceptions. They are fetched immediately.
For more information on the pending area, see Pending Area.
Streaming is not required and does not work with the personal vDisk feature of Citrix
XenDesktop. Even if you follow these steps, the Profile streaming setting is disabled
automatically.
1. Under Profile Management, double-click Streamed user profiles.
2. Double-click Profile streaming.
3. Select Enabled and click OK.
4. Optionally, to enhance the streaming experience for users, double-click Always cache,
select Enabled, and do one of the following:
•
To save network bandwidth by imposing a lower limit on the size of files or folders
that are streamed, set a limit in megabytes. Any files and folders that exceed the
limit are fetched as soon as possible after logon.
To turn on the cache entire profile feature, set the limit to zero. After logon, this
fetches all files in the user store as a background system task, without any
feedback to users.
5. Click OK.
•
6. Optionally, double-click Timeout for pending area lock files, select Enabled, and enter
a timeout period (days) that frees up files so they are written back to the user store
from the pending area in the event that the user store remains locked when a server
becomes unresponsive. Use this setting to prevent bloat in the pending area and to
ensure the user store always contains the most up-to-date files.
7. Click OK.
8. Optionally, if you want only a subset of user profiles in the OU to be streamed,
double-click Streamed user profile groups, select Enabled, and enter a list of groups.
The profiles of users in all other groups will not be streamed.
9. Click OK.
If Profile streaming is not configured here, the value from the .ini file is used. If this setting
is not configured here or in the .ini file, it is disabled.
If Always cache is not configured here, the value from the .ini file is used. If this setting is
not configured here or in the .ini file, it is disabled.
146
To stream user profiles
If Timeout for pending area lock files is not configured here, the value from the .ini file is
used. If this setting is not configured here or in the .ini file, the default value of one day is
used.
If Streamed user profile groups is disabled, all user groups are processed. If this setting is
not configured here, the value from the .ini file is used. If this setting is not configured
here or in the .ini file, all users are processed.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
147
To configure active write back
To ensure profile integrity, files and folders (but not registry entries) that are modified on
the local computer can be backed up to the user store in the middle of a session, before
logoff.
This feature is not intended to support users opening multiple active sessions. However, if a
user starts a second session (started at a second computer, for example) modifications
made to a file in the first session will be available in the second if it was started before
logging off the first.
1. Under Profile Management, double-click Active write back.
2. Select Enabled and click OK.
If Active write back is not configured here, the value from the .ini file is used. If this
setting is not configured here or in the .ini file, it is enabled.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
148
To configure Profile management for
folder redirection
Folder redirection is a feature of Microsoft Windows and can be used in Version 3.2, Version
3.2.2, and Version 4.x. For the best experience, Citrix recommend using Version 4.1.1 or
later. For information on how this feature works with Profile management, see Planning
Folder Redirection with Profile Management.
If, while configuring folder redirection, you select the Group Policy (GP) option Move the
contents of <folder name> to the new location, by default Profile management does not
delete the folder after its contents are moved. This results in two identically named items
in the local profile, the folder itself and a shortcut to the folder. Because they appear side
by side, these duplicates can confuse users.
To prevent the confusion in these circumstances, enable the setting Delete Redirected
Folders as described in this procedure. If the setting is enabled, the folder is deleted from
the local profile when the user next logs on. This setting is only required for Profile
management versions earlier than 4.1.1.
Important information about folder redirection
•
Only follow the procedure in this topic if the Move the contents of <folder name> to the
new location option in GP is selected. If it is unselected (for example, you may be
performing server moves or maintenance and don't want Group Policy to move files), do
not follow the procedure.
•
Do not add redirected folders to exclusion lists.
1. Under Profile Management > Advanced Settings, double-click the Delete Redirected
Folders policy.
2. Select Enabled.
If Delete Redirected Folders is configured here, the folder is deleted from the local profile
when the user next logs on. If this setting is not configured here, the value from the .ini file
is used. If this setting is not configured here or in the .ini file, the folder is not deleted
from the local profile.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
149
To manage cookie folders and other
transactional folders
This topic applies to Profile management 3.1 and later.
The two procedures, mirroring folders and deleting stale cookies, are related. If you
manage the Internet Explorer Cookies folder, use both procedures. This ensures
transactional integrity while also reducing profile bloat involving Index.dat and browser
cookies.
Mirroring can also be applied more widely because it can help solve similar issues involving
any transactional folder (also known as a referential folder), that is a folder containing
interdependent files, where one file references others. Mirroring folders allows Profile
management to process a transactional folder and its contents as a single entity, thereby
avoiding profile bloat.
For example, consider how Index.dat references cookies while a user browses the Internet.
If a user has two Internet Explorer sessions, each on a different server, and they visit
different sites in each session, cookies from each site are added to the appropriate server.
When the user logs off from the first session (or in the middle of a session, if the active
write back feature is configured), the cookies from the second session should replace those
from the first session. However, instead they are merged, and the references to the cookies
in Index.dat become out of date. Further browsing in new sessions results in repeated
merging and a bloated cookie folder.
Mirroring the cookie folder solves the issue by overwriting the cookies with those from the
last session each time the user logs off so Index.dat stays up to date.
The cookie folder can become bloated not only when multiple sessions are involved but also
when Web sites are revisited and stale cookies build up. The second procedure in this topic
solves the latter issue by removing the stale cookies from all profiles.
To mirror folders
Use this procedure for any transactional folders not just those that store cookies.
Caution: Mirroring transactional folders can mean that the "last write wins"; files that are
modified in more than one session are overwritten by the last update. This might result in
the loss of users' profile changes.
1. Under Profile Management > File system > Synchronization, double-click the Folders to
mirror policy.
2. Select Enabled.
3. Add the list of folders, relative to the root folder in the user store, that you want to
mirror. This policy works recursively, so do not add subfolders to the list. For example,
add AppData\Roaming\Microsoft\Windows\Cookies but not
150
To manage cookie folders and other transactional folders
AppData\Roaming\Microsoft\Windows\Cookies\Low as well.
If Folders to mirror is not configured here, the value from the .ini file is used. If this setting
is not configured here or in the .ini file, no folders are mirrored.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
To delete stale cookies
1. Under Profile Management > Advanced Settings, double-click the Process Internet
cookie files on logoff policy.
2. Select Enabled.
3. Click OK.
If Process Internet cookie files on logoff is not configured here, the value from the .ini file
is used. If this setting is not configured here or in the .ini file, no processing of Index.dat
takes place.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
Be aware that enabling Process Internet cookie files on logoff increases logoff times.
Nevertheless, in order to maintain the integrity of the cookie folder, the supported
configuration is to set both Folders to mirror and Process Internet cookie files on logoff, as
the following best practice demonstrates:
To process cookie folders
1. Under Profile Management > File system > Synchronization, double-click the Folders to
mirror policy.
2. Select Enabled.
3. Add the list of folders, relative to the root folder in the user store, that you want to
mirror. Add the folder Cookies for Version 1 profiles and
AppData\Roaming\Microsoft\Windows\Cookies for Version 2 profiles.
4. Under Profile Management > Advanced Settings, double-click the Process Internet
cookie files on logoff policy. This step deletes the stale cookies referenced by
Index.dat.
5. Select Enabled.
6. Click OK.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
151
To configure offline profiles
Citrix offline profiles are intended for laptop users or mobile-device users who roam with
intermittent access to a network. This feature allows profiles to synchronize with the user
store at the earliest possible opportunity. When a network disconnection occurs, profiles
remain intact on the laptop or device even after restarting or hibernating. As mobile users
work, their profiles are updated locally and are eventually synchronized with the user store
when the network connection is re-established.
This feature works only with domain-joined computers (including ones running Citrix
XenClient) and is not intended for use with servers or desktop computers, whose network
connections tend to be permanent.
Typically, you don't enable both offline profiles and streamed user profiles. For this reason,
offline profiles takes precedence over and disables streamed user profiles and the Delete
locally cached profiles on logoff setting. This ensures users always have a complete profile
on their laptop or mobile device when they first log on.
You can configure offline profiles in these ways:
•
Using Group Policy. This gives you centralized administrative control of the feature but
you must create a separate OU containing the laptops or devices that will use offline
profiles.
•
Using .ini files. This is an easier option if you prefer not to create a special OU just for
laptops and mobile devices, but it effectively hands control of this feature to individual
device owners. This option requires a once-only configuration of each laptop or mobile
device.
If Offline profile support is not configured using Group Policy, the value from the .ini file is
used. If this setting is not configured in Group Policy or in the .ini file, offline profiles are
disabled.
152
To configure offline profiles
Using Group Policy
1. Create an OU containing all computers managed by Profile management, including the
laptops and mobile devices that will be using offline profiles, your XenApp servers, and
your virtual desktops.
2. Create a child OU containing only the laptops and mobile devices.
3. In Group Policy Management, create a baseline Group Policy Object (GPO) that enforces
your site-wide policies, and link it to both OUs.
4. Configure the baseline GPO with the Profile management settings common to all
computers.
5. Create a second, offline GPO and link it to the child OU.
6. Configure the offline GPO as follows:
a. Under Profile Management, double-click Offline profile support.
b. Select Enabled and click OK.
c. Configure any other settings that you want to apply only to laptops and mobile
devices.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
Using .Ini Files
As a prerequisite, ensure that Offline profile support is unconfigured (the default) in both
the baseline and offline GPO. If these settings are configured, the .ini file setting is
overridden.
1. On each laptop or mobile device, locate the .ini file that was created by the Profile
management installer. To locate the .ini file, see Files Included in the Download.
2. Uncomment this line (by removing the semi-colon from it):
;OfflineSupport=
3. Save the .ini file.
For your changes to take effect, run the gpupdate /force command from the
command prompt as documented at
http://technet.microsoft.com/en-us/library/bb490983.aspx.
153
To configure cross-platform settings
Important: Note the following important information for this feature:
•
Cross-platform settings in Profile management work with a set of supported operating
systems (OSs) and applications. Only configure this feature in a production environment
if your organization uses one or more of these.
•
Microsoft Office settings do not roam between versions of that application. For more
information, see Operating Systems and Applications Supported By Cross-Platform
Settings.
•
This feature is suitable for registry and application settings, but not for files or folders,
or objects typically used with folder redirection (for example, browser favorites, and
desktop and Start menu settings).
•
If you use this feature to migrate user profiles between systems with different profile
versions, disable it after the migration has been completed for all users. There is some
performance impact, primarily to logoffs, when using this feature so it is best to leave
it disabled unless you support roaming between profile versions.
This topic contains an example of the steps you can take to configure cross-platform
settings. For a more detailed case study, see Cross-Platform Settings - Case Study.
Tip: Citrix recommends restricting this feature to a small, test set of users before putting
it into production. Use the Cross-platform settings user groups option to achieve this. If
this setting is configured, the cross-platform settings feature of Profile management
processes only members of these user groups. If this setting is disabled, the feature
processes all of the users specified by the Processed groups setting. If Cross-platform
settings user groups is not configured in Group Policy or the .ini file, all user groups are
processed.
1. For the settings that are common to all platforms, create a common Group Policy
Object (common GPO), link it to the Profile management .adm or .admx file, and
configure the settings as required. This is best practice because it minimizes duplicate
settings that can make any later troubleshooting awkward. Depending on your
requirements, all Profile management settings work on multiple platforms except Path
to user store, which you must configure separately for each platform due to the
different user store structures of Version 1 and Version 2 profiles. In the common GPO,
leave this setting unconfigured.
2. Create separate OUs for your different platforms (for example, if you are migrating
from Windows XP to Windows 7, create separate OUs for these operating systems), and
set Path to user store appropriately in each OU.
3. Locate the definition (.xml) files for the supported applications whose personalizations
you want to work across the platforms. These files are located in the CrossPlatform
folder in the download package.
4. Copy the .xml files to a suitable location on your network.
154
To configure cross-platform settings
5. Edit the common GPO in Group Policy Management Editor. Under Profile Management
open the Cross-platform settings folder and configure these settings:
•
Cross-platform settings user groups. Restricts the users who experience
cross-platform settings. This setting is optional. It is useful when testing this
feature or rolling it out in stages.
•
Path to cross-platform definitions. Identifies the network location of the definition
files that you copied from the download package. This must be a UNC path. Users
must have read access to this location, and administrators must have write access
to it. The location must be a Server Message Block (SMB) or Common Internet File
System (CIFS) file share.
Path to cross-platform settings store. This is the common area of the user store
where profile data shared by multiple platforms is located. Users must have write
access to this area. The path can be an absolute UNC path or a path relative to the
home directory. You can use the same variables as for Path to user store.
6. Specify a base platform by ensuring Source for creating cross-platform settings is set to
Enabled in that platform's OU. This setting migrates data from the base platform's
profiles to the cross-platform settings store. In the other platforms' OUs, set this policy
to Disabled or Unconfigured. Each platform's own set of profiles are stored in a separate
OU. This means you must decide which platform's profile data to use to seed the
cross-platform settings store. This is referred to as the base platform. If the
cross-platform settings store contains a definition file with no data, or the cached data
in a single-platform profile is newer than the definition's data in the store, Profile
management migrates the data from the single-platform profile to the store unless you
disable this setting.
•
Important: If Source for creating cross-platform settings is enabled in multiple OUs,
the platform that the first user logs on to becomes the base profile.
7. Set Enable cross-platform settings to Enabled. By default, to facilitate deployment,
cross-platform settings is disabled until you turn on this setting.
8. Run a Group Policy update.
9. If you are migrating profiles across platforms but not supporting roaming of them, when
the migration is complete, set Enable cross-platform settings to Disabled .
If Path to cross-platform definitions is not configured here, the value from the .ini file is
used. If this setting is not configured here or in the .ini file, no cross-platform settings are
applied.
If Path to cross-platform settings store is disabled, the default path Windows\PM_CP is
used. If this setting is not configured here, the value from the .ini file is used. If this setting
is not configured here or in the .ini file, the default path is used.
If Enable cross-platform settings is not configured here, the value from the .ini file is used.
If this setting is not configured here or in the .ini file, no cross-platform settings are
applied.
155
To configure cross-platform settings
Example: Roaming Microsoft Office Settings Between
Windows Server 2003 and Windows 7
This example describes the major steps involved in allowing users' application settings to
roam between operating systems that create Version 1 and Version 2 profiles. Microsoft
Office 2007 is the example application, and roaming takes places between Citrix XenApp 5
on Windows Server 2003, which creates Version 1 profiles, and Windows 7, which creates
Version 2 profiles. Both OSs are 32-bit.
1. Users are accustomed to accessing Office 2007 and Internet Explorer 8 as published
applications on XenApp servers, and change several settings in these applications (for
example, they modify their email signature in Office and choose a new home page in
Internet Explorer).
2. At a future date, virtual desktops (created with Citrix XenDesktop) are created but not
yet released to users. The desktops run Windows 7 and are preconfigured with Office
2007 and Internet Explorer 8.
3. The users will expect their settings to be the same on their new desktops. To achieve
this, you configure the cross-platform settings feature according to the procedure in
this topic. This includes enabling Source for creating cross-platform settings in the OU
for Windows Server 2003.
4. When users next run the published versions of the applications (not the new, virtual
desktops), their settings are copied to the cross-platform settings store.
5. The new desktops are then released to users. When they log on and run the local
versions of Office and Internet Explorer, the Version 1 settings from the earlier
Windows Server 2003 session are used; users' modified email signatures and home pages
are available on the new Version 2 OS.
6. Users browse in Internet Explorer from their virtual desktop, and decide to change their
home page again.
7. Users log off and leave work. They don't have access to their virtual desktop at home,
but they can run the published version of Internet Explorer 8 remotely.They find their
most recent home page, created on Windows 7 in the previous step, has been
preserved.
156
Cross-Platform Settings - Case Study
The primary use case for the cross-platform settings feature is the migration from Windows
XP and Windows Server 2003 to Windows 7 and Windows Server 2008. It is likely that this is
accompanied by a move from Microsoft Office 2003 or Office 2007 to Office 2010. Given the
typical investment in Windows 2003 systems, a significant coexistence phase is expected, so
the feature is expected to support both migration and sustained coexistence.
This case study starts with an existing Windows XP and Windows 2003 environment running
Office 2007 and adds Windows 7 pooled, provisioned virtual desktops.
The case study consists of:
157
•
Initial Configuration
•
Planning the New Site
•
Executing the Plan
•
Other Considerations
Initial Configuration
The following graphic illustrates the environment configuration in this case study.
Windows XP machines are configured to use Office 2007 published on Citrix XenApp 5.
The domain includes Windows 2003 domain controllers running Active Directory at Windows
2003 level. All of the machines belong to an OU called 2k3_Farm and the Profile
management 3.x ADM file is added to a GPO called 2k3_Farm_PO. The following policies are
configured.
Policy
Value
Path to user store
\\FileServ1\Profiles\#sAMAccountName#\%ProfVer%
Profile streaming
Enabled
Active write back
Enabled
A machine logon script, which sets the system environment variable %ProfVer%, runs on all
of the machines in the OU.
158
Initial Configuration
Machine Type
%ProfVer%
XenApp server on Windows 2003
Win2003
Windows XP desktops
WinXP
So, for example, user john.smith has his profile at \\FileServ1\Profiles\john.smith\WinXP for
the Windows XP desktop and at \\FileServ1\Profiles\john.smith\Win2003 for the XenApp
servers. Note that separate profiles are maintained for desktops and servers. The
administrator is aware that issues exist when profiles roam between workstation and server
operating systems and is being cautious.
Folder redirection is set up using Group Policy in User Configuration > Windows Settings >
Folder Redirection.
However, we wish to redirect the Favorites folder (which isn’t supported by standard .adm
files in Windows 2003 domains). We can use a variety of techniques. For information on
this, see http://www.brianmadden.com/forums/t/26108.aspx and elsewhere.
159
Policy
Value
Favorites
\\FileServ1\Redirected\%USERNAME%\Favorites
My Documents
\\FileServ1\Redirected\%USERNAME%\Documents
Planning the New Site
The network administrators have decided to set up a new domain for the new environment,
based on Windows Server 2008 R2 domain controllers and Active Directory 2008. Ultimately,
a new XenApp farm is planned, based on Windows 2008 R2 running XenApp 6, but for now,
the new domain is used only for the Windows 7 XenDesktop site.
The site is based on a shared Windows 7 base image hosted in a XenServer environment and
accessed by Windows terminals. Office 2007 is included in the base image.
Because users from both domains are expected to make use of the new domain, a two-way
trust is set up between OldDomain and NewDomain, both of which must belong to the same
AD forest.
The following graphic illustrates the configuration of the new XenDesktop site.
160
Executing the Plan
Phase 1: Configure the New File Servers
You set up file servers in NewDomain for managing cross-platform settings (\\FileServ3) and
for storing profiles for 2k8_Farm (\\FileServ2).
In this case, we choose to set up separate file servers for the profiles and for the
cross-platform settings. This is not strictly necessary, but it is an easy way of making the
cross-platform settings server available; the profile server might be designed differently,
using DFS namespaces for example, and so take longer to implement.
In both cases, the server shares should be set up according to the security
recommendations for roaming user profiles on shared folders. For information on this, see
http://technet.microsoft.com/en-us/library/cc757013(WS.10).aspx.
Phase 2: Upgrade the Machines in 2k3_Farm to Profile
Management 4.x
For instructions on this, see Upgrading Profile Management.
Phase 3: Choose Which Definition Files to Deploy
A number of configuration files (called definition files) are supplied for Microsoft Office,
Internet Explorer and Windows wallpaper.
Important: Do not update these files unless instructed to by Citrix personnel.
Choose the configuration files that are relevant to your deployment, and copy only these
files to \\FileServ3\CrossPlatform\Definitions. In this example, copy just Office 2007.xml.
Phase 4: Configure the Machines in 2k3_Farm for
Profile Management 4.x
Once the upgrade is complete, make the following configuration changes to (partially)
enable the cross-platform settings feature. Note that, at this stage, only
\\FileServ3\CrossPlatform needs to be available.
Policy
161
Value
Notes
Executing the Plan
Path to user
store
\\FileServ1\Profiles\#sAMAccountName#\%ProfVer%
No change. This
path is only used
by OldDomain
users, so there is
no need to
change it to
support
NewDomain
users.
Enable
cross-platform
settings
Enabled
Cross-platform
settings user
groups
Disabled
All user groups
are processed.
Path to
cross-platform
definitions
\\FileServ3\CrossPlatform\Definitions
This is where the
definition files
are located.
Path to
cross-platform
settings store
\\FileServ3\CrossPlatform\Store\%USERNAME%.%USERDOMAIN%
The
cross-platform
settings store is
shared by users of
both domains, so
both
%USERNAME% and
%USERDOMAIN%
must be specified
in the path.
Source for
creating
cross-platform
settings
Enabled
This ensures that
cross-platform
settings from
OldDomain are
used to initialize
the
cross-platform
settings store,
before giving
users access to
NewDomain
resources.
No changes are required to the machine logon script.
No changes are required to the folder redirection policy.
The OU 2k3_Farm can now be left to run. As users log on, Profile management copies the
settings identified in the definition file Office 2007.xml to the cross-platform settings store.
162
Executing the Plan
Phase 5: Prepare the machines in 2k8_Farm
Now that the file servers are set up in 2k8_Farm, it is time to build the XenDesktop site.
Install Profile management 4.x when the Windows 7 XenDesktop virtual desktops are
running. Here is a suitable configuration.
163
Policy
Value
Notes
Path to user
store
\\FileServ2\Profiles\%USERNAME%.%USERDOMAIN%\%ProfVer%
As this file share
is used by users
from both
domains, it is
important also to
include domain
information.
Active write
back
Disabled
Enable
cross-platform
settings
Enabled
Cross-platform
settings user
groups
Disabled
All user groups
are processed.
Path to
cross-platform
definitions
\\FileServ3\CrossPlatform\Definitions
This is where the
definition files
are located. This
setting must
match the setting
in 2k3_Farm.
Path to
cross-platform
settings store
\\FileServ3\CrossPlatform\Store\%USERNAME%.%USERDOMAIN%
The
cross-platform
settings store is
shared by users of
both domains, so
both
%USERNAME% and
%USERDOMAIN%
must be specified
in the path. This
setting must
match the setting
in 2k3_Farm.
Executing the Plan
Source for
creating
cross-platform
settings
Disabled
This prevents
settings from
NewDomain being
used for the
initial setup of
the profile data
in the
cross-platform
settings store. It
ensures that
settings from
OldDomain take
precedence.
A machine logon script, which sets the system environment variable %ProfVer%, runs on all
machines in the OU.
Machine Type
%ProfVer%
Notes
XenApp server on Windows
2003
Win2008x64
This is not needed yet, but
it will be when your
planned 64-bit servers
become available. See
Other Considerations for
more information.
Windows 7 desktops
Win7
If both 32- and 64-bit
versions of Windows 7 are
deployed, it is
recommended that they
have separate profiles, so
%ProfVer% should be
configured differently on
each platform.
So the OldDomain user john.smith has his profile at \\FileServ2\Profiles\
john.smith.OldDomain\Win7 for the Windows 7 desktop and at \\FileServ2\Profiles\
john.smith.OldDomain\Win2008x64 for the XenApp servers.
And a NewDomain user william.brown has his profile at \\FileServ2\Profiles\
william.brown.NewDomain\Win7 for the Windows 7 desktop and at
\\FileServ2\Profiles\william.brown.NewDomain\Win2008x64 for the XenApp servers.
Again, you set up folder redirection using Group Policy. Because the domain is based on
Windows Server 2008 R2, set folder redirection from<Group Policy Object Name> > User
Configuration > Policies > Windows Settings > Folder Redirection.
Policy
Value
Favorites
\\FileServ2\Redirected\%USERNAME%.%USERDOMAIN%\Favorites
My Documents
\\FileServ2\Redirected\%USERNAME%.%USERDOMAIN%\Document
s
Note that %USERDOMAIN% has been added to the folder redirection path. This is not
necessary because this policy only applies to NewDomain users, but it may be useful if in
the future, you decide to migrate OldDomain users to the same server. For now, OldDomain
users continue to use the Folder Redirection policy from OldDomain which redirects their
folders to \\FileServ1.
164
Executing the Plan
Phase 6: Live Testing
You perform testing in two stages:
1. You test that the profile data for users from NewDomain operates correctly. These
users have no data set up in the cross-platform settings store. As the policy Source for
creating cross-platform settings is set to disabled, their profile changes do not
propagate to OldDomain.
2. You test with a small number of users from OldDomain. When they first log on, the
cross-platform settings data is copied to their profile. For later logons, changes from
either domain are copied to the other. Note that if a user from OldDomain logs on to
NewDomain and no profile data is present (because the user has not used their profile
in OldDomain since OldDomain was upgraded to Profile management 4.x), the
cross-platform settings store is not updated. With the configuration described in this
topic, a user must log on to OldDomain before their settings roam between the
domains. This ensures that user settings (possibly created over many years) are not
overwritten by default settings from NewDomain.
165
Other Considerations
As configured in this case study, Profile management does not use the settings from
NewDomain to initialize the cross-platform settings store. Only settings from OldDomain can
be used to initialize the store. This is acceptable until NewDomain contains more than one
type of profile (such as Windows 7 32-bit and Windows 7 64-bit). Alternatively, users from
NewDomain may need to access resources in OldDomain. In these cases, you must enable
the policy Source for creating cross-platform settings on further types of machine
appropriately.
Caution: If Source for creating cross-platform settings is set incorrectly, it is entirely
possible that a new profile will obliterate an existing profile with many accumulated and
treasured settings. To avoid this, Citrix recommends that this policy is set on only one
platform type at a time. This is generally the older (more mature) platform, where
settings that users most likely want to keep have accumulated.
In this case study, separate domains are used to illustrate a number of points. Additionally,
the cross-platform settings feature can manage the roaming of settings between two OUs,
or even between machines of different types in a single OU. In this case, you might have to
set the policy Source for creating cross-platform settings differently for the different
machine types. This can be achieved in a number of ways:
166
•
Use the setting CPMigrationsFromBaseProfileToCPStore in an .ini file to set the policy
differently on each machine type. Do not set the policy Source for creating
cross-platform settings.
•
Use Windows Management Instrumentation (WMI) filtering to manage different GPOs on
the same OU. You can configure the common settings in a GPO that applies to all
machines in the OU, but only add the policy Source for creating cross-platform settings
to additional GPOs and filter using a WMI query.
Integrating Profile Management with Citrix
Products
This section contains information for Citrix administrators deploying Profile management
with other Citrix products or components. Use this information in addition to, not instead
of, the other topics in the Profile management documentation. For example, for solutions
to common issues with Profile management in such deployments see Troubleshooting Profile
Management.
This section also contains information about how some third-party products interact with
Profile management or profiles in general.
167
Profile Management and XenApp
Use of this version of Profile management on XenApp servers is subject to the Profile
management end-user license agreement (EULA). You can also install Profile management
on local desktops, allowing users to share their local profile with published resources.
Profile management works in XenApp environments that employ Remote Desktop Services
(formerly known as Terminal Services). In these environments, you must set up an OU for
each supported operating system. For more information, see the article "Using User Profiles
in Windows Server 2003" on the Microsoft TechNet Web site at
http://technet.microsoft.com.
In farms that contain different versions of XenApp or that run different operating systems,
Citrix recommends using a separate OU for each server that runs each version or operating
system.
Important: Including and excluding folders that are shared by multiple users (for
example, folders containing shared application data published with XenApp) is not
supported. For more information, see Combining Inclusions and Exclusions.
Streamed Applications
Profile management can be used in environments where applications are streamed to either
user devices directly or streamed to XenApp servers and, from there, published to users.
Client-side application virtualization technology in XenApp is based on application
streaming which automatically isolates the application. The application streaming feature
enables applications to be delivered to XenApp servers and client devices, and run in a
protected virtual environment. There are many reasons to isolate the applications that are
being streamed to users, such as the ability to control how applications interact on the user
device to prevent application conflicts. For example, isolation of user settings is required if
different versions of the same application are present; Microsoft Office 2003 may be
installed locally and Office 2007 may be streamed to users' devices. Failure to isolate user
settings creates conflicts, and might severely affect the functionality of both applications
(local and streamed).
For requirements relating to the use of Profile management with streamed applications, see
System Requirements for Profile Management.
168
Profile Management and XenDesktop
Use of this version of Profile management with XenDesktop is subject to the Profile
management end-user license agreement (EULA). Subject to the terms in the EULA, you can
also use Profile management with XenApp in a XenDesktop environment. For more
information, see Profile Management and XenApp. If that environment also uses
Provisionsing Services, see Profile management and Provisioning Services.
If you upgrade Profile management in a XenDesktop deployment, consider the effect on the
log file locations as described in Upgrading Profile Management.
For XenDesktop in Quick Deploy setups, see the recommendations in Decide on a
configuration.
Do not install the Profile Management Service on XenDesktop servers. Install it on the
virtual images (for example, vDisks created with Citrix Provisioning Services) that you use to
create virtual desktops. The Profile Management Service starts before Group Policy is
applied if Profile management has not been configured correctly on the images before they
are rolled out. To avoid this, perform the configuration using the documented procedures
before you put the images into a production environment. If you are using vDisks, follow the
best practice described in Profile Caching on vDisks.
Important: Including and excluding folders that are shared by multiple users (for
example, folders containing data that can be shared by multiple virtual desktops) is not
supported. For more information, see Combining Inclusions and Exclusions.
Profiles on Personal vDisks
If you use the personal vDisk feature of XenDesktop, note that by default Citrix user profiles
are stored on virtual desktops' personal vDisks, typically the P: drives, not the C: drives.
However, Profile management expects to find the profiles on the C: drives. To correct this,
you must modify the Registry on the master image while installing or upgrading the Virtual
Desktop Agent. In addition, it is good practice to increase the default allocation of disk
space for applications on the master image. For instructions on these modifications, see
Managing XenDesktop 5.6.
In addition, note that using this feature results in the settings Delete locally cached profiles
on logoff and Profile streaming being disabled automatically. Even if they are enabled in
Group Policy or the .ini file, the settings are treated as disabled.
Do not delete the copy of a profile in the user store while a copy remains on the personal
vDisk. Doing so creates a Profile management error, and causes a temporary profile to be
used for logons to the virtual desktop. For more information on this, see Users Receive New
or Temporary Profiles in Specific Troubleshooting Information. Partial deletion of profiles
(from the user store but not a persistent drive such as a personal vDisk) is not
recommended.
169
Example Settings for XenDesktop
This topic lists Profile management policy settings used in a typical XenDesktop
deployment. Windows 7 virtual desktops are created with Citrix Provisioning Services and
are shared by multiple users. In this example, the desktops, which are created from a
pooled-random catalog and are deleted at logoff, are intended for use on static
workstations (not mobile laptops) and personal vDisks are not used.
Where no policy is listed, no selection or entry was made in Group Policy, and the default
setting applies.
Note the following:
•
Path to user store - You can incorporate Profile management variables into the path to
the user store. This example uses !CTX_OSNAME! and !CTX_OSBITNESS!, which expand
to Win7 and x86 respectively when the path is interpreted. The AD attribute
#sAMAccountName# is also used to specify user names.
•
Delete locally cached profiles on logoff - Disabling this policy is safe because the
desktops do not include personal vDisks and get deleted when users log off. Preserving
locally cached profiles is therefore unnecessary. (If the desktops were not discarded at
logoff, this policy should be enabled.)
•
Profile streaming - Enabling this setting improves logon times in this deployment.
•
Active write back - This policy is enabled because the pooled desktops in this
deployment are only temporarily allocated to users, who might therefore make changes
to their profile but might forget (or not bother) to close their desktop session. With this
setting enabled, local file changes in the profile are mirrored in the user store before
logoff.
•
Process logons of local administrators - Enabling this setting is recommended for
XenDesktop deployments, in which most users will be local administrators.
•
Processed groups - All domain users' profiles are managed by Profile management.
•
Exclusion list - directories (file system) and Exclusion list (registry) - These settings
prevent the listed temporary or cached files, and the listed registry entries, from being
processed. These files and entries are commonly stored in user profiles.
•
Directories to synchronize and Files to synchronize - Knowledge of where users'
application data is stored helped define these settings.
Important: XenDesktop deployments vary, so the Profile management policy settings you
decide on will probably be different to those in this example. To plan your settings,
follow the advice in Decide on a configuration.
Citrix/Profile Management
Enable Profile management
Enabled
170
Example Settings for XenDesktop
Processed groups
MyDomainName\Domain Users
Path to user store
\\MyServer.MyDomain\MyUserStore\#sAMAccountName#\!CTX_OSNAME!_!CTX_OSBITNESS!
Active write back
Enabled
Process logons of local administrators
Enabled
Citrix/Profile Management/Profile handling
Delete locally cached profiles on logoff
Disabled
Citrix/Profile Management/Advanced settings
Process Internet cookie files on logoff
Enabled
Citrix/Profile Management/File system
Exclusion list - directories
$Recycle.Bin
AppData\Local\Microsoft\Windows\Temporary Internet Files
AppData\Local\Microsoft\Outlook
AppData\Local\Temp
AppData\LocalLow
AppData\Roaming\Microsoft\Windows\Start Menu
AppData\Roaming\Sun\Java\Deployment\cache
AppData\Roaming\Sun\Java\Deployment\log
AppData\Roaming\Sun\Java\Deployment\tmp
Citrix/Profile Management/File system/Synchronization
Directories to synchronize
AppData\Microsoft\Windows\Start Menu\Programs\Dazzle Apps
171
Example Settings for XenDesktop
Folders to mirror
AppData\Roaming\Microsoft\Windows\Cookies
Citrix/Profile Management/Streamed user profiles
Profile streaming
Enabled
172
Profile Management and VDI-in-a-Box
You can use Profile management on desktops created with Citrix VDI-in-a-Box. For more
information on this, see Configuring User Profile Management with VDI-in-a-Box.
Use of this version of Profile management with VDI-in-a-Box is subject to the Profile
management end-user license agreement (EULA). Subject to the terms in the EULA, you can
also use Profile management with XenApp in a VDI-in-a-Box environment. For more
information, see Profile Management and XenApp.
Do not install the Profile Management Service on VDI-in-a-Box servers. Install it on the
published images that you use to create virtual desktops. The Profile Management Service
starts before Group Policy is applied if Profile management has not been configured
correctly on the images before they are rolled out. To avoid this, perform the configuration
using the documented procedures before you put the images into a production
environment.
173
Profile Management and ShareFile
The information in this topic applies to the use of Profile management in Citrix ShareFile
deployments. Some of it may also be useful for other Internet-based file-sharing systems.
ShareFile is only supported in On-Demand mode. You can use ShareFile Sync for Windows
2.1.x with Profile management 4.1.2 and later. Other versions are not supported.
Installation and removal
Some care is needed when installing or removing the components because both use a
common driver:
•
Install ShareFile Sync for Windows before Profile management. When installing the
latter, accept the prompt (if displayed) to replace the driver.
•
When removing Profile management but not ShareFile Sync for Windows, Profile
management does not remove the driver that is still required by ShareFile.
•
After removing ShareFile Sync for Windows, reinstall Profile management.
Exclusions
ShareFile stores configuration data locally in the \AppData\Roaming\ShareFile folder. For
users with Citrix user profiles, this data must roam with the user profile so that the
user-specific ShareFile configuration is persisted. Since this ShareFile folder is part of the
profile, no Profile management configuration is required; the configuration data roams by
default.
However, user data that is managed by ShareFile is contained in the ShareFile folder that is
in the root of the profile (%USERPROFILE%\ShareFile). This data must not roam with the
profile because it is managed by, and synchronizes with, the ShareFile server. You must
therefore add this folder as a Profile management exclusion. For instructions on setting
exclusions, see To include and exclude items.
Personal vDisks
If you create virtual desktops with Personal vDisks (using Citrix XenDesktop), configure
ShareFile with the location of the user data on the vDisks. This ensures that file
synchronization can take place between the desktops and the ShareFile server. By default,
Personal vDisks are mapped as P: drives on the desktops so the data might be located in
P:\Users\<user name>. In this case, you would set the location using the LocalSyncFolder
policy in ShareFile.
Important: To prevent unnecessary synchronizations, which can adversely affect the
performance of Profile management and Personal vDisks, Citrix recommends using the
174
Profile Management and ShareFile
Folder-ID setting on folders that contain large files unless they need to be synchronized
on the virtual desktop. This is a ShareFile setting.
175
Profile Manager and App-V
You can use Profile management 5.x in the same environment as Microsoft Application
Virtualization 5.0 (App-V 5.0).
You must exclude the following items using Profile management exclusions:
•
Profile Management\File system\Exclusion list\directories:
•
AppData\Roaming\Microsoft\AppV\Client\Catalog
AppData\Local\Microsoft\AppV
Profile Management\Registry\Exclusion list:
•
•
•
Software\Microsoft\AppV\Client\Integration
Software\Microsoft\AppV\Client\Publishing
If you don't exclude these items, App-V applications work the first time users access them
but they fail, with an error, on subsequent logons. For instructions on setting exclusions,
see To include and exclude items.
•
If the UserLogonRefresh setting is enabled in App-V, disable the Profile streaming policy in
Profile management.
For an example of how to sequence an App-V application, see
http://support.microsoft.com/kb/2830069.
176
Profile management and Provisioning
Services
This topic contains advice on maintaining Citrix user profiles on virtual disks (vDisks)
created with Citrix Provisioning Services. Before following this advice, you should
understand how your vDisk configuration affects your Profile management configuration as
described in Provisioned or Persistent?
Supported modes
You can use Profile management on vDisks running in Standard Image and Private Image
modes but not Difference Disk Image mode.
Locating the cache file
In most Provisioning Services setups, when a vDisk is restarted changes to it are discarded,
and the Profile management cache file is recreated (because the Change Journal ID is
updated). You must therefore adjust the default location of the cache file so that it
persists. The default location is C:\Program Files\Citrix\User Profile Manager. Ensure that
the file stores references from the Private image only, and choose a location where the
effect of network delays is minimized.
Alternatively, if you configure Provisioning Services to persist vDisk changes after a restart,
do not adjust the default location for the Profile management cache file.
To remove non-essential, locally cached profiles from
the Master Target Device
To prevent any non-essential, locally cached profiles being stored, ensure these are
removed from vDisks running in Standard Image mode before taking the Master Target
Device image, but do not remove the currently logged-on local administrator's profile. A
good way of achieving this is as follows. During this procedure, error messages may be
displayed.
1. Right-click Computer.
2. Select Properties.
3. Click Advanced system settings.
4. On the Advanced tab, click Settings in User Profiles.
5. Highlight each profile you want to remove and click Delete.
177
To retrieve log files from vDisk images
This topic provides guidance on using log files that reside on shared (vDisk) images created
with Citrix Provisioning Services. Profile management saves the files at logoff, but, if you
use vDisk images, you should take account of the fact that base images can be reset, which
results in log files being deleted. You therefore need to take some action in order to
retrieve the files. The action you take depends on whether the log files are being deleted
at logon or logoff.
Use of vDisk images is common in XenDesktop deployments, so the guidance in this topic
uses that product as an example.
To retrieve a log file that is deleted at logoff
If entire profiles or parts of them are not saved back to the user store on the network, the
log file will also not be saved there.
If the Provisioning Services write-cache is stored on the computer running Provisioning
Services, this issue should not arise and the log file should be saved back to the user store.
If the write-cache is stored locally, in this procedure you may have to log on from the same
device as the user. However, even this may fail if the write-cache is stored locally in RAM.
If the write cache is not on the computer running Provisioning Services, you may have to
create a copy of the vDisk image, assign it to the new virtual machine, and change the
write-cache on the image so it is stored on that computer.
1. In XenDesktop, create a new desktop group, add one virtual machine to it, and point it
to your vDisk image.
2. Grant access to the virtual machine to one test user and the administrator.
3. Modify the desktop group's idle pool count to 1 for all times of the day (to stop power
management turning the machine off), and set its logoff behavior to Do nothing (to
prevent the machine restarting and resetting the image).
4. Log on as the test user to the virtual desktop and then log off from it.
5. Log on as administrator from the XenCenter or VMware console, and retrieve the log
file.
Consult the XenDesktop documentation for more information on creating desktop groups
and modifying their properties.
To retrieve a log file that is deleted at logon
If a profile is current in the user store on the network but does not load correctly when the
user logs on, log file entries will be lost.
178
To retrieve log files from vDisk images
1. Map a drive to \\<vmhostname>\C$ and, before the user logs off the session, locate the
log file.
The log file will not be complete (some entries will be missing) but if the problem you are
troubleshooting is at logon, it may provide enough information for you to isolate the cause
of the issue.
To relocate Provisioning Services log files
Using Standard Image mode, the Provisioning Services event log files are lost when the
system shuts down. For instructions on changing the default location of the files to prevent
this, see CTX115601.
179
To preconfigure Profile management on
provisioned images
Using provisioning software such as Citrix Provisioning Services, Citrix XenServer, or VMware
ESX you can build images that have Profile management pre-installed. When doing so, you
will likely capture some Group Policy settings in the registry while you set up the image (for
example, while it is in Private Image mode with Provisioning Services). The settings will still
be present when you deploy the image (for example, when you switch back to Standard
Image mode with Provisioning Services). Ideally, those settings should be sensible defaults
for the provisioned virtual machine when it starts running and the user logs on. At a
minimum, you should ensure you have sensible defaults for certain policies, as described in
Persistent? Provisioned? Dedicated? Shared?.
The defaults are used if the image does not immediately get a gpupdate before the Citrix
Profile Management Service starts, so it is best to make sure they are sensible defaults for
the majority of cases. Use this procedure to preconfigure these and other settings you want
to preserve in the image.
Note: If you use Provisioning Services, Citrix recommends that you preconfigure images
with the Profile management .ini file first and that you transfer the settings to the .adm
or .admx file only once your testing proves successful.
1. If you use an .adm or .admx file, change the desired settings using the file in the
appropriate GPO. If you use an .ini file, omit this step; you will make the changes in a
later step.
2. Make the same changes to the log level.
3. Do one of the following:
•
Switch the image to Private Image mode (Citrix Provisioning Services) and start the
operating system on it.
•
Start the operating system (Citrix XenServer or VMware ESX).
4. Log on using an Administrator account (not any test user account you may have set up),
and run gpupdate /force. This step ensures the registry is correctly configured.
5. If using an .ini file, change the desired settings in the file.
6. Stop the Profile Management Service.
7. Delete the Profile management cache file from the installation directory. Typically, this
is UserProfileManager_<drive letter>.cache, where <drive letter> is any monitored drive
letter, typically C. The file is located in C:\Program Files\Citrix\User Profile Manager.
8. To avoid confusion with the new log files that will be created, delete the old Profile
management log file and the configuration log file. These have file names that use the
name of the old image. They are redundant because the updated image has new files
(with the name of the new image).
180
To preconfigure Profile management on provisioned images
9. Do one of the following:
•
Switch the image back to Standard Image mode (Citrix Provisioning Services).
Save the updated image (Citrix XenServer or VMware ESX).
10. Start the operating system on the image.
•
181
Profile Management and Self-service
Plug-in
By default, Profile management excludes the Windows Start menu folder. This means that
Self-service Plug-in users cannot see their subscribed applications in the Start menu. You
must adjust this default behavior by removing the following folder from the Exclusion list directories policy, and, when using GPOs for configuration, it is best practice to delete the
Profile management .ini file. These actions ensure that the Start menu folder containing
subscribed applications (and any user-created subfolders) are processed by Profile
management:
•
Windows 7 and Windows Vista: %APPDATA%\Microsoft\Windows\Start Menu
•
Windows XP: %USERPROFILE%\Start Menu
Note: If you are using the Profile management .ini file rather than Group Policy, remove
these entries from the default exclusion list in that file.
182
Profile Management and VMWare
This topic applies to Citrix user profiles on virtual machines created with VMware software
such as VMware ESX. It addresses an issue where local profile caches become locked.
If you have set up Profile management to delete cached local profiles when users log off
from their virtual machines created with VMware (in your XenDesktop or XenApp
deployment, say) but the profiles are not deleted, you can use this workaround to
overcome the issue.
This issue has been shown to occur when roaming profiles are used on virtual machines
created with VMware ESX 3.5 and the Profile management setting Delete locally cached
profiles on logoff is enabled.
The issue occurs because the Shared Folders option in VMware Tools adds a file to the
profiles, and the file is locked by a running process thereby preventing profiles being
deleted at logoff. The file is C:\Documents and Settings\userid\Application
Data\VMware\hgfs.dat.
If you have verbose logging enabled in Profile management, the log file may detect this
problem with an entry such as:
2009-06-03;11:44:31.456;ERROR;PCNAME;JohnSmith4;3;3640;DeleteDirectory: Deleting the
directory <C:\Documents and Settings\<user name>\Local Settings\Application
Data\VMware> failed with: The directory is not empty.
To work around this issue in a XenApp deployment on Windows Server 2008:
1. Log on as Administrator to the XenApp server.
2. In XenApp deployments, log off all users from the server.
3. In Control Panel, go to Add/Remove Programs.
4. Locate VMware Tools and choose the Change option.
5. Change Shared Folders to This feature will not be available.
6. Click Next > Modify > Finish.
7. Restart the server.
8. Clean up the half-deleted profiles. Use My Computer > Properties > Advanced > User
Profiles, select the profiles and delete them. Windows informs you of any errors trying
to delete the profiles.
Note: A separate issue in environments running Profile management on VMware can
result in the creation of multiple sequential profiles. For information about this issue and
how to resolve it, see CTX122501.
183
Profile Management and Microsoft
Outlook
This topic describes best practice for integrating Microsoft Outlook with roaming profiles.
Read the following article before integration:
http://office.microsoft.com/en-gb/help/HA011402691033.aspx.
It is good practice to ensure that users store Outlook data on a server rather than on a
network share or locally.
With roaming profiles, files and folders in the location defined by the environment variable
%UserProfile% (on the local computer) roam with users, with the exception of one folder,
%UserProfile%\Local Settings. This exception affects Outlook users because a Microsoft
recommendation means that, by default, some Outlook data (for example, .ost, .pst, and
.pab files) is created in this non-roaming folder.
Important: Files in this location are typically large and hinder the performance of
roaming profiles.
The following practices can reduce troubleshooting of roaming profiles with Outlook and
encourage good email management by users and administrators:
184
•
If possible, use an ADM template for Microsoft Office that prohibits the use of .pst files.
•
If users need more space, increase storage on your Microsoft Exchange servers rather
than a network share.
•
Define and enforce an email retention policy for the entire company (one that involves
a company-wide email storage server) rather than granting exceptions for .pst files to
individual users or increasing their personal storage capacity. The policy should also
discourage reliance on .pst files by allowing users easily to request email restores to
their inbox.
•
If .pst files cannot be prohibited, do not configure Profile management or roaming
profiles on your Exchange servers.
Using Windows Profiles With Citrix
Password Manager
This topic applies to Password Manager 4.5 and 4.6. It describes the use of various Windows
profile options and how best to integrate Password Manager with these profiles. The
profiles covered in the topic are local profiles, roaming profiles, and mandatory profiles or
hybrid profiles.
This topic does not contain any information specific to Profile management.
Local Profiles
Local profiles are stored on the local server to which the user has logged on. Password
Manager saves registry information in the HKCU\Software\Citrix\MetaFrame Password
Manager hive of the User Registry located at:
%SystemDrive%\Documents and Settings\%username%\NTUSER.DAT.
Password Manager also saves files in:
%SystemDrive%\Documents and Settings\%username%\Application
Data\Citrix\MetaFrame Password Manager.
On Windows Vista, Password Manager uses:
%APPDATA%\Roaming\Citrix\MetaFrame Password Manager
Important: It is critical that Password Manager has Full Control Access to the following
files:
185
File Name
Description
%username%.mmf
User's credential information file with
pointers to aelist.ini.
entlist.ini
Application definition file created at
enterprise level in the synchronization
point or Active Directory.
aelist.ini
Application definition file created by
merging user's local application definition
file (applist.ini) and the enterprise
application definitions (entlist.ini).
Using Windows Profiles With Citrix Password Manager
Roaming Profiles
Roaming profiles are saved on a network share and synchronized to a local server copy each
time the user logs on. Characteristics of a successful roaming profile deployment include
high-speed network connectivity such as a SAN (System Area Network) or NAS (Network Area
Storage). Other common deployments include clustering solutions where the profiles are
stored on high-availability servers.
Two issues affect roaming and mandatory profile deployments:
•
A single roaming profile can only be used with one file synchronization point. When
multiple synchronization points are used, data in the Memory Mapped File (MMF) may
become corrupted.
•
When roaming profiles are used with multiple concurrent sessions, they share the same
backend MMF. This means that all active sessions share some common session data such
as retry lock counters, last used data counters, and event log entries.
Mandatory Profiles or Hybrid Profiles
Mandatory profiles are by definition user read-only profiles. Password Manager needs write
permission to the profile folder under Application Data. With mandatory profiles, a user
may make changes but the changes are not saved back to the profile at logoff. For
Password Manager to work correctly with mandatory profiles, the Application Data Folder
must be redirected.
With Password Manager, the registry changes are written each time the user logs on.
Credential information is synchronized with the synchronization point but the changes are
not saved back to the profile.
Beginning with Windows 2000, Microsoft provides a mechanism for redirecting the
Application Data folder. However, using Windows NT4 domains requires logon scripts
capable of modifying the location of the Application Data folder. You can achieve this using
tools such as Kix or VBScript to define a writeable location for the Application Data folder.
The following example uses Kix to redirect the Application Data folder during user logon:
Important: This sample script is for informational purposes only and should not be used in
your environment without first testing it.
$LogonServer = "%LOGONSERVER%"
$HKCU = "HKEY_CURRENT_USER"
$ShellFolders_Key =
"$HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders"
$UserShellFolders_Key =
"$HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User
Shell Folders"
$UserProfFolder =
"$LogonServer\profiles\@userID"
$UserAppData =
186
Using Windows Profiles With Citrix Password Manager
"$LogonServer\profiles\@userID\Application Data"
$UserDesktop =
"$LogonServer\profiles\@userID\Desktop"
$UserFavorites =
"$LogonServer\profiles\@userID\Favorites"
$UserPersonal = "X:\My Documents"
$UserRecent =
"$LogonServer\profiles\@userID\Recent"
if (exist("$UserAppData") = 0)
shell '%ComSpec% /c md "$UserAppData"'
endif
if (exist("$UserDesktop") = 0)
shell '%ComSpec% /c md "$UserDesktop"'
endif
if (exist("$UserRecent") = 0)
shell '%ComSpec% /c md "$UserRecent"'
endif
if (exist("$UserFavorites") = 0)
shell '%ComSpec% /c md "$UserFavorites"'
endif
The hybrid profile is another solution for the mandatory profile issue. When the user logs
on, the mandatory profile loads and a custom application loads and unloads user registry
hives based on applications available to the user. As with mandatory profiles, the user can
modify those parts of the registry during a session. The difference compared with
mandatory profiles is that changes are saved when the user logs off and are reloaded when
they log on again.
If a hybrid profile is used, the HKEY_CURRENT_USER\Software\Citrix\MetaFrame Password
registry keys must be imported and exported as part of the logon and logoff process.
Folder Redirection
Folder redirection is implemented using Group Policy Objects and Active Directory. It uses
Group Policies to define a location for folders that are part of the user profile.
Four folders can be redirected:
•
My Documents
•
Application Data
•
Desktop
•
Start Menu
Two modes of redirection can be configured using Group Policies: basic redirection and
advanced redirection. Both are supported by Password Manager. In Windows 2000, you must
reference the share that stores application data using the username variable, (for example
\\servername\sharename\%username%).
Folder redirection is global for the user and it affects all of their applications. This means
all applications that use the Application Data folder must support it.
187
Using Windows Profiles With Citrix Password Manager
Read the following Microsoft articles to learn more about folder redirection:
HOW TO: Dynamically Create Secure Redirected Folders By Using Folder Redirections
Folder Redirection Feature in Windows
Enabling the Administrator to Have Access to Redirected Folders
Best Practices
188
•
Redirect the Application Data folders where possible. This improves network
performance, eliminating the need to copy the data in those folders each time users log
on.
•
When troubleshooting Password Manager Agent, always verify that the logged-on user
has Full Control permission on their Application Data folder.
Profile Management Reference Section
This section of eDocs contains reference and architectural information about Profile
management. You may occasionally need to consult the topics here when configuring or
troubleshooting the software.
189
Profile Management Policies
This topic describes some important aspects of the policies in the .adm and .admx files, the
templates used to configure Profile management.
For reference information on each policy, including its default setting, see Profile
Management Policy Descriptions and Defaults. For instructions on setting a policy, see the
relevant topic in the Manage section of eDocs.
Modifying Policies
To deactivate any Profile management policy that you enter as lists (for example, exclusion
lists and inclusion lists), set the policy to Disabled. Do not set the policy to Not Configured.
For your changes to take effect, run the gpupdate /force command from the command
prompt as documented at http://technet.microsoft.com/en-us/library/bb490983.aspx.
Profile Management Variables
In Profile management 4.0 or later, the following variables are available for use in some
policies (in both Group Policy and the .ini files):
•
!CTX_PROFILEVER! expands to v1 or v2 depending on the profile version.
•
!CTX_OSBITNESS! expands to x86 or x64 depending on the bitness of the operating
system.
•
!CTX_OSNAME! expands to the short name as follows depending on the operating
system. In addition, the long name is written to the log files when the Profile
Management Service starts:
Long Name
Short Name
Windows 7
Win7
Windows Server 2008 R2
Win2008
Windows Server 2008
Win2008
Windows Vista
WinVista
Windows XP
WinXP
Windows Server 2003 R2
Win2003
Windows Server 2003
Win2003
Where a policy supports the use of Profile management variables, this is noted in the
policy's description. Use of the variables in other policies is not supported.
190
Profile Management Policies
Versions and Policies
As an aid to migration, the following tables show the policies that are available in different
versions of Profile management, the location of each policy in the .adm (or .admx) file and
the .ini file, and the feature each policy is designed for (or whether it is part of the base
configuration of all deployments). The location in the .adm or .admx file is relative to the
folder Citrix > Profile Management.
As a further aid, the tables also relate policies to the configuration decisions that you make
when planning your Profile management deployment. For more information on these, see
Decisions You Need to Make. Where no decision is shown, do not set the policy unless asked
to by Citrix Technical Support.
To simplify upgrades, in Profile management 4.x all policies in the .adm or .admx file are
set to Not Configured by default.
Policies Available from Version 4.x
Policy in .Adm or
.Admx File
Location in .Adm
or .Admx File
Location in .Ini File
Feature
Configuration
Decision
Cross-platform
settings user
groups
\Cross-platform
settings
CPUserGroupList
Cross-platform
settings
One or More
Platforms
Offline profiles
Mobile or Static
Improved
Troubleshooting
Enable
cross-platform
settings
CPEnabled
Source for
creating
cross-platform
settings
CPMigrationFromBaseProfileToCPStore
Path to
cross-platform
definitions
CPSchemaPath
Path to
cross-platform
settings store
CPPath
Offline profile
support
OfflineSupport
Log off user if a
\Advanced
LogoffRatherThanTempProfile
problem is
Settings
encountered
Policies Available from Version 3.x
Policy in
.Adm or
.Admx File
191
Location in .Adm or
.Admx File
Location in .Ini File
Feature
Configuration
Decision
Profile Management Policies
Active write
back
PSMidSessionWriteBack
Active profile
write back
(in Version
4.0, renamed
Active write
back)
Provisioned or
Persistent
Folder
mirroring
Applications
DeleteRedirectedFolders
Support for
folder
redirection
Mobile or Static
PSAlwaysCache
Streamed
user profiles
Folders to
mirror
(available
from Version
3.1)
\File
system\Synchronization
MirrorFoldersList
Process
Internet
cookie files
on logoff
(available
from Version
3.1)
\Advanced settings
ProcessCookieFiles
Delete
Redirected
Folders
(available in
Versions 3.2,
3.2.2, and
4.0)
Always cache
\Streamed user profiles
Profile
streaming
PSEnabled
Timeout for
pending area
lock files
PSPendingLockTimeout
Streamed
PSUserGroupsList
user profile
groups
Policies Available from Version 2.x
Policy in .Adm or
.Admx File
192
Location in .Adm or
.Admx File
Location in .Ini File
Feature
Configuration
Decision
Profile Management Policies
Path to user
store
Processed
groups
Local profile
conflict handling
PathToUserStore
Base
Pilot or
Production
ProcessedGroups
\Profile handling
LocalProfileConflictHandling
Migration of
existing profiles
MigrateWindowsProfilesToUserStore
Template profile
TemplateProfilePath,
New or Migrated
Environment
TemplateProfileOverridesRoamingProfile,
TemplateProfileOverridesLocalProfile,
Delete locally
cached profiles
on logoff
DeleteCachedProfilesOnLogoff
Directory of the
MFT cache file
\Advanced settings
USNDBPath
Provisioned or
Persistent
Directories to
synchronize
\File
system\Synchronization
SyncDirList
Applications
Exclusion list
\Registry
ExclusionListRegistry
Files to
synchronize
\File
system\Synchronization
SyncFileList
Inclusion list
\Registry
InclusionListRegistry
Exclusion list directories
\File system
SyncExclusionListDir
Exclusion list files
SyncExclusionListFiles
Number of
retries when
accessing locked
files
\Advanced settings
LoadRetries
Process logons of
local
administrators
ProcessAdmins
Enable Profile
management
Enable logging
ServiceActive
\Log settings
LoggingEnabled
Log settings
LogLevel...
Maximum size of
the log file
MaxLogSize
Path to log
file(available
from Version
2.1)
PathToLogFile
193
Review and Go
Live
Logging
Troubleshooting
upm-reference-adm-settings-defaults-sou
Due to technical difficulties, we are unable to display this topic. Citrix is currently fixing
this problem. In the meantime, you can view this topic online:
http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/user-profile-manager-sou/u
pm-reference-adm-settings-defaults-sou.html
194
Profile Management Architecture
This topic describes the folder structure of the user store and cross-platform settings store.
The user store is the central location for Citrix user profiles. The cross-platform settings
store is a separate location.
Important Information About Profile Management
Stores
The structures of the user store and cross-platform settings store are described here for
information purposes and to assist with localizing and troubleshooting. Follow these
important recommendations, which are designed to minimize problems with profile data
and maintain security:
•
Do not change the structure of either store.
•
Do not write files and folders directly to any part of a store. The user store is different
in this respect from any redirected folders.
•
Keep the user store separate from any redirected folders. You can keep them on
disjoint shares of the same file server or DFS namespace, for example
\\server1\profiles\%username% and \\server1\folders\%username%. This technique also
makes it much easier to support Version 1 and Version 2 profiles together, and to
support a single set of redirected folders shared by both profile versions.
•
Users do not need to see the user store, so do not map a drive letter to it.
•
Do not impose quotas on the user store. If you need to restrict profile size, consider
excluding items rather than using a quota.
Folder Structure of the User Store
The user store defaults to the WINDOWS folder in the user’s home directory. This simplifies
pilot installations, but for production systems, you should configure the user store to be a
network share or (for best scalability) a DFS namespace. Supported configurations for
enterprise-ready user stores are described in High Availability and Disaster Recovery with
Profile Management.
Recommendations on creating secure user stores are available in the article called Security
Recommendations for Roaming User Profiles Shared Folders on the Microsoft TechNet Web
site. These are minimum recommendations that ensure a high level of security for basic
operation. Additionally, when configuring access to the user store include the
Administrators group, which is required in order to modify or remove a Citrix user profile.
The folder structure of the user store at the root level is shown in this table.
Folder
195
Notes
Profile Management Architecture
\
The root of a profile in the user store.
\UPM_Profile
This contains files and folders from the profile.
\UPM_Drive_C
This folder contains any included items from outside the
profile (in this case from drive C).
\Pending
This folder contains the lock file, any pending files, and
the stamp file if the streaming feature is in use.
Some examples are shown in this table.
Example Folder Name
Notes
\UPM_Drive_C\MyProgData
The synchronized content of
C:\MyProgData.
\UPM_Profile\Data
The synchronized content of the Data
folder in the user profile.
\UPM_Profile\AppData_upm_var
The synchronized content of the
de-localized Application Data folder in the
user profile.
Pending Area
The user store includes the pending area. This is a holding area used by the streamed user
profiles and active write back features. All files are synchronized from the pending area to
the user store after a user logs off from their last session. New sessions download files from
both the user store and the pending area, so the user always experiences an up-to-date
profile.
In the event that a server becomes unresponsive, a timeout can be set that releases files in
the pending area back to the user store (if configured as part of the streamed user profiles
feature).
Folder Structure of the User Store When Multiple
Platforms Are Used
When using the cross-platform settings feature, multiple platforms are involved. This means
you must define platform-specific folders to separate the profiles for each platform.
Typically, you do this using Profile management variables in the Path to user store policy
(for example, using %USERNAME%\!CTX_OSNAME!!CTX_OSBITNESS! in the path).
The cross-platform settings store holds the settings for supported applications after the
cross-platform settings feature is configured. You specify the name and location of the
store during configuration (using the Path to cross-platform settings store policy). The store
holds the subset of the user's settings that roam between operating systems.
For example, you may want to roam settings between Windows XP and Windows 7. The
platform-specific folders contain the user settings that are unique to Windows XP and
Windows 7; the cross-platform settings store contains the subset of the settings that roam
between these operating systems. At logon, this subset is copied into, and remains part of,
the platform-specific folders. At logoff, any changes to the subset are extracted and placed
back into the cross-platform settings store.
196
Profile Management Architecture
Each platform-specific folder contains standard subfolders (for example, UPM_Profile). For
information on these, see Folder Structure of the User Store. In addition, the
UPM_CPS_Metadata subfolder is present. This system-created folder contains temporary
settings that are shared across operating systems.
Naming Conventions
To distinguish between Version 1 and Version 2 profile folder types, the following suffix is
appended to Version 1 profile folders in the user store.
Folder Suffix
Notes
_upm_var
The localized folder name with the
_upm_var suffix is used when profiles are
imported into the user store at logoff.
When profiles are exported at logon, the
suffix is removed.
Paths anywhere in the local file system (even outside the user profile) are supported.
Absolute paths outside the user profile are stored by replacing the drive letter with
UPM_Drive_<Drive letter>. UPM_Drive_A to UPM_Drive_Z are supported. Example:
UPM_Drive_D.
The User Store and AD Forests
Citrix user profiles cannot be managed across forests. They can be managed across domains
in the same forest allowing multiple users with the same logon name to access the same
resources in the forest. This involves uniquely identifying profiles with the %USERDOMAIN%
and %USERNAME% variables in the path to the user store.
However, in this case you must use variables to disambiguate identical logon names when
setting the path to the user store. To do this, append the domain name variable to the
path. You must also set permissions on the user store and enable Profile management's
Processed Groups setting using Active Directory's Universal Groups.
You can use a manually defined system variable such as %ProfVer% to set the operating
system version, or a Profile management variable to set the operating system name,
bitness, or the profile version. For examples of user store paths in AD forests, see To
specify the path to the user store.
Localizing the User Store
The following table provides an overview of how Profile management localizes and
de-localizes folders when profile data is moved to and from the user store. Only folder
names are localized and de-localized. For example, Start menu entries and registry settings
are not translated into the correct language by Profile management.
V1 English Folder
197
User Store Folder
Full Path Relative to the User
Profile
Profile Management Architecture
198
Accessibility
Accessibility_upm_var
\Start
Menu\Programs\Accessories\
Accessories
Accessories_upm_var
\Start Menu\Programs\
Administrative Tools
AdminTools_upm_var
\Start Menu\Programs\
Application Data
AppData_upm_var
\Local Settings\
Cookies
Cookies_upm_var
\
Desktop
Desktop_upm_var
\
Entertainment
Entertainment_upm_var
\Start
Menu\Programs\Accessories\
Favorites
Favorites_upm_var
\
History
History_upm_var
\Local Settings\
Links
Links_upm_var
\Favorites\
Local Settings
LocalSettings_upm_var
\
My Documents
MyDocuments_upm_var
\
My Music
MyMusic_upm_var
\My Documents\
My Pictures
MyPictures_upm_var
\My Documents\
My Videos
MyVideos_upm_var
\My Documents\
NetHood
NetHood_upm_var
\
PrintHood
PrintHood_upm_var
\
Programs
Programs_upm_var
\Start Menu\
Recent
Recent_upm_vars
\
Start Menu
StartMenu_upm_var
\
Templates
Templates_upm_var
\
Temporary Internet
Files
TemporaryInternetFiles_upm_
var
\Local Settings\
SendTo
SendTo_upm_var
\
Startup
Startup_upm_var
\Start Menu\Programs\
System Tools
SystemTools_upm_var
\Start
Menu\Programs\Accessories\
Operating Systems and Applications
Supported By Cross-Platform Settings
This topic describes the applications and operating systems (OSs) supported by the
cross-platform settings feature in this release of Profile management.
About Definition Files
Definition files contain common personalizations for selected Windows applications. Each
file and the definitions within it allow users to connect to the same application on multiple
OSs, presenting essentially identical profiles on each platform. For example, users might
access two instances of Microsoft Office: one that is installed on a Windows 7 virtual
desktop and the other that is published with Citrix XenApp on Windows Server 2003;
whichever instance is accessed, users' experience of Office is consistent.
Preconfigured definition files are a key aspect of the cross-platform settings feature. There
is a definition file for each supported application. Definition files are in an XML format.
Important: Without a thorough analysis of an application's behavior across all OSs and a
full understanding of this feature's operation, editing of definition files can result in
unexpected changes to users' profiles that can be difficult to troubleshoot. For this
reason, Citrix does not support the editing of the supplied definition files or the creation
of new ones. In addition, note that some application settings cannot be duplicated across
OSs due to the nature of Windows user profiles.
In addition note that, although this feature is suitable for registry and application settings,
it is not suitable for files or folders, or objects typically used with folder redirection (for
example, browser favorites, and desktop and Start menu settings).
Supported Operating Systems
You can roam profiles between any of the supported client OSs, and between any of the
supported server OSs.
The following are supported (x86 and x64 versions as applicable):
•
Client OSs. Windows XP, Windows 7, and Windows Vista.
•
Server OSs. Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.
Supported Citrix Products
The following Citrix products are supported by the cross-platform settings feature:
•
199
XenApp 5 Feature Pack for Windows Server 2003 or later
Operating Systems and Applications Supported By Cross-Platform Settings
•
XenDesktop 4 or later
Supported Applications
The following definition files are available in this release. The XML file name indicates the
supported application and versions.
•
Internet Explorer 7 Plus.xml. This file supports the roaming of Versions 7, 8, and 9 of
Internet Explorer (except favorites) across platforms. The roaming of favorites and
feeds is not supported.
•
Office 2007.xml.
•
Office 2010.xml.
•
Wallpaper.xml. This file supports the roaming of desktop wallpaper across platforms.
The roaming of themes across platforms is not supported.
Important: Use the definition files for each application only in the above supported
scenarios. For example, Internet Explorer 7 Plus.xml roams settings between multiple
versions of that browser, but you cannot use Office 2007.xml or Office 2010.xml to roam
settings between versions of Office.
200
Logon Diagram
This diagram helps you work out the details of your user profile migration strategy. It also
explains these aspects of performance:
•
When you migrate a profile, two network copies can take place, which slows down the
logon process. For example, the operation “Copy default profile to local Pm profile and
to user store” first involves a full profile copy from the roaming profile store to the
local computer and then a second full profile copy from the local computer to the user
store.
•
When a cached profile is used, no copying of profile data across the network takes
place.
Read the diagram from the bottom to the top. Check the desired operations in the boxes at
the bottom (for example, “Copy default profile to local Pm profile and to user store”) and
track a path back to identify the required migration settings.
201
Logon Diagram
202
Logoff Diagram
This diagram describes the logic used to copy or merge profile data at logoff.
203
Logoff Diagram
204
Profile Management Glossary
This topic contains terms and definitions used in the Profile management software and
documentation. To understand other concepts relating to Windows user profiles, visit the
Microsoft Web site.
Term
Definition
Base platform
See cross-platform settings store.
Base profile
The base profile is defined by a UNC path to a profile in
the user store. If the cross-platform settings feature is
used, registry settings and files that can be shared across
platforms form a subset of the base profile. This subset is
copied to the cross-platform settings store, and, from
there, they are added to the profile used as the target for
migration or roaming.
Although the cross-platform settings store contains a
subset of the base profile, this (and the target profile) are
always stored as complete profiles and can, if necessary,
be used as standard Windows roaming or local profiles.
Note however that if the streamed user profiles feature is
used, the base profile may temporarily be incomplete;
some files may exist in the pending area until the user logs
off.
See roam for considerations when defining base profiles in
roaming scenarios.
205
Cache
The terms cache and synchronize refer to the act of
downloading files from the user store, or uploading to it.
The term fetch is more specific and refers to how the
streamed user profiles feature downloads, any time after
logon when the user needs them, a subset of files from the
user store.
Citrix user profile
This term refers to profiles that users receive when Profile
management is installed and enabled. Citrix user profiles
are different from local, roaming, or Microsoft mandatory
profiles.
Computer
As used in these Profile Management topics, the general
term computer can refer to any machine on which the
Citrix Profile Management Service is installed. This can be
a user device, virtual desktop (possibly provisioned from a
XenDesktop virtual machine), or a XenApp server that hosts
published applications.
Cross-platform definition
file
This is an .xml file supplied with Profile management that
contains the information needed to make the
cross-platform settings feature work. There is one file per
supported application.
Glossary
Cross-platform settings
store
This location, which is separate from the user store, holds
the settings for supported applications once the
cross-platform settings feature is configured. You must
choose which platform's profile data is used to seed the
cross-platform settings store. This is the base platform.
Fetch
See cache.
Legacy application
A legacy application is a badly behaved one because it
stores settings in a non-standard location. This includes
systems that store temporary application data in user
profiles and, by doing so, create profile bloat.
Migrate
Migration is the planned, one-way movement of profiles
from one platform to another (for example, from Windows
XP to Windows 7).
Profile bloat
Windows user profiles can increase in size when temporary
files are not deleted. This causes slow logons and is
referred to as profile bloat.
Roam
Roaming is the use of different base profiles from multiple
computers or sessions (for example, one base profile for a
computer running Windows 2008 R2 and a second one for
Windows 7). Users roam when they connect back and forth
between computers or sessions that have different base
profiles.
Depending on how you configure your Organizational Units
(OUs), a base profile can be shared across platforms. For
example, the same profile can be used by both Windows
2008 R2 and Windows 7 OUs; in this case users do not roam
because the same base profile is shared. Base profiles can
only be shared by operating systems with the same profile
version (Version 1 or Version 2 profiles). This means users
always roam when both Version 1 and Version 2 profiles are
active.
Synchronize
See cache.
User store
The user store is the central, network location for Citrix
user profiles. See also cross-platform settings store.
vDisk, personal vDisk
A vDisk is a virtual disk created from a master image by
Citrix Provisioning Services.
A personal vDisk is a disk used by Citrix XenDesktop to
store profiles, user-installed and departmental
applications, and user data. Personal vDisks are separate
from the disks used for the operating system, registry, and
base applications.
Version 1 profile, Version
2 profile
206
Profiles in Microsoft Windows XP and Windows Server 2003
are known as Version 1 profiles. Those in Windows Vista,
Windows 7, Windows Server 2008, and Windows Server
2008 R2 are known as Version 2 profiles. Version 1 and
Version 2 profiles have different namespaces. This affects
some aspects of their configuration.
Download PDF
Similar pages