Product Documentation

Profile Management 用例

Jun 04, 2018

可以实施 Citrix Profile Management 以管理各种情形下的用户配置文件,而无论通过何种方式向用户交付应用程序或将应用程序托管在何处。下面是各种情形的示例:

  • 具有已发布应用程序的 Citrix XenApp

  • 具有已发布桌面的 Citrix XenApp

  • 具有 通过流技术推送到隔离环境的应用程序的 Citrix XenApp

  • 通过 流技术推送到 XenDesktop 虚拟桌面的应用程序

  • XenDesktop 虚拟桌面上安装的应用程序

  • 通过 流技术推送到物理桌面的应用程序

  • 本地安装在 物理桌面上的应用程序

在这些情形中,Citrix 认为以下情形是最常见的用例:

  • 多个会话 - 用户将访问多个 XenApp 服务器接收器,并因此打开多个会话。但请注意,服务器上的应用程序隔离和通过流技术推送是服务器接收器的替代项。本主题中将更加详细地介绍此种情形。
  • “后写入内容有效”与漫游配置文件一致性问题 - 后写入到漫游配置文件会导致所有设置得以保存。因此,如果打开了多个会话并且进行了临时更改,漫游配置文件可能不会保留正确的数据。此外,由于网络、存储问题或其他问题,设置可能未正确写入到配置文件中。本主题中将更加详细地介绍此种情形。
  • 大型配置文件与登录速度 - 配置文件膨胀会使用户配置文件过大,导致出现存储和管理问题。通常情况下,登录过程中 Windows 会通过网络将用户的整个配置文件复制到本地用户设备。对于已经膨胀的配置文件,此操作会延长用户的登录时间。

多个会话

特别是在大型环境中,用户可能需要打开多个会话,以访问托管在不同 XenApp 服务器上的各种应用程序,而无论这些服务器是位于同一个场还是多个场。如有可能,Citrix 管理员应考虑应用程序隔离或通过流技术推送,以在相同的 XenApp 服务器上托管应用程序,从而允许用户从单台服务器、单一会话访问所有应用程序。但是,如果业务部门控制特定服务器,或者应用程序无法通过流技术推送,则可能无法执行此操作。

确定用户确实有必要从不同的 XenApp 服务器访问应用程序之后,应明确对配置文件产生的影响。

下图说明了以下示例,在此示例中,存在多个会话时应用程序设置可能会丢失。

例如,Mary 需要访问应用程序 A、应用程序 B 和应用程序 C,而且她分别路由到服务器 1、服务器 8 和服务器 12。登录到每个应用程序后,Mary 的 Terminal Services 漫游配置文件会加载到每台服务器,且文件夹会为每个会话进行重定向。Mary 登录到服务器 1 上的应用程序 A 时,更改了设置 1,并从该会话注销。然后她使用其他两个应用程序完成工作并从中注销。

注销后,Mary 在服务器 1 上的会话中所做的更改将被覆盖,因为保留的是最后关闭的会话中的设置,而非所做的临时更改。第二天 Mary 登录到应用程序 A 时,她很失望,因为系统未显示她所做的更改。

Profile Management 通常能够防止发生上述情形。Profile Management 只写回会话过程中更改的特定设置,所有其他未更改的设置保持不变。因此,唯一可能会发生冲突的情形是 Mary 在另一个会话中更改了设置 1。但是,用户可能会希望保留所做的最新更改,如果在此情形中使用了 Profile Management,则会保留最新更改。

“后写入内容有效”与漫游配置文件一致性问题

此情形与本主题中的第一种情形类似。“后写入内容有效”问题可能会有多种表现方式,并且随着所访问设备数量的增加,用户会愈加沮丧。

由于漫游配置文件会保留所有配置文件数据(已重定向的文件夹除外),因此,用户配置文件可能会变得非常庞大。这不但会导致用户由于必须下载配置文件而致使登录时间变长,而且在用户注销的写入阶段,特别是存在网络问题时,一致性方面的潜在问题也将增加。

Profile Management 可将特定数据排除在用户配置文件之外,使用户配置文件的大小能够保持最小。由于仅将差别写入配置文件,因此注销的写入阶段涉及的数据更少,写入速度更快。对于使用配置文件存储临时数据,但无法在应用程序终止时清理配置文件的应用程序而言,Profile Management 非常有用。