XenApp and XenDesktop

VDA 注册

简介

VDA 必须先向站点中的一个或多个 Controller 或 Cloud Connector 注册(建立连接),然后该 VDA 才可以使用。(在本地 XenApp 和 XenDesktop 部署中,VDA 在 Controller 中注册。在 XenApp and XenDesktop Service 部署中,VDA 在 Cloud Connector 中注册。)VDA 通过检查名为 ListofDDCs 的列表来查找 Controller 或 Connector。VDA 上的 ListOfDDCs 包含将该 VDA 指向站点中的 Controller 或 Cloud Connector 的 DNS 条目。为实现负载平衡,VDA 会自动在列表中的所有 Controller 或 Cloud Connector 之间分发连接。

为什么 VDA 注册如此重要?

  • 从安全角度而言,注册是一种敏感操作:您将在 Controller 或 Cloud Connector 与 VDA 之间建立连接。对于此类敏感操作,如果所有情况未达到良好状态,预期行为是拒绝连接。您将有效地建立两个单独的通信通道:VDA 至 Controller 或 Cloud Connector 和 Controller 或 Cloud Connector 至 VDA。连接使用 Kerberos,因此不允许存在时间同步和域成员身份问题。Kerberos 使用服务主体名称 (SPN),因此您不能使用负载平衡的 IP\主机名。
  • 添加和删除 Controller 或 Cloud Connector 后,如果 VDA 没有准确的 Controller 或 Cloud Connector 最新信息,VDA 可能会拒绝未列出的 Controller 或 Cloud Connector 代理的会话启动。无效的项会使虚拟桌面系统软件的启动发生延迟。VDA 不会接受来自未知的不可信 Controller 或 Cloud Connector 的连接。

除了 ListOfDDCs 之外,ListOfSIDs(安全 ID)也可以指示 ListOfDDCs 中的哪些计算机可信。ListOfSIDs 可用于降低 Active Directory 上的负载或避免来自受感染 DNS 服务器的潜在安全威胁。有关详细信息,请参阅 ListOfSIDs

如果 ListOfDDCs 指定多个 Controller 或 Cloud Connector,VDA 将尝试以随机顺序连接这些 Controller 或 Cloud Connector。在本地部署中,ListOfDDCs 还可以包含 Controller 组。VDA 将尝试连接组中的每个 Controller,然后转向 ListOfDDCs 中的其他项。

XenApp 和 XenDesktop 会在 VDA 安装期间自动测试与配置的 Controller 或 Cloud Connector 的连接。如果无法访问 Controller 或 Cloud Connector,会显示错误。如果您忽略无法访问 Controller 或 Cloud Connector 的警告(或者在 VDA 安装期间未指定地址时),系统会显示消息提醒您。

Controller 或 Cloud Connector 地址配置方法

管理员将选择 VDA 首次注册时使用的配置方法。(这称为首次注册。) 在首次注册期间,会在 VDA 上创建永久性缓存。在后续注册期间,除非检测到配置更改,否则 VDA 将从此本地缓存中检索 Controller 或 Cloud Connector 列表。

在后续注册期间检索该列表的最简单的方法是使用自动更新功能。默认情况下启用自动更新。有关详细信息,请参阅”自动更新“。

在 VDA 上配置 Controller 或 Cloud Connector 地址的方法有多种。

  • 基于策略(LGPO 或 GPO)
  • 基于注册表(手动、GPP、在 VDA 安装期间指定)
  • 基于 Active Directory OU(旧 OU 发现)
  • 基于 MCS (personality.ini)

首次注册方法在安装 VDA 时指定。(如果禁用自动更新,则在 VDA 安装期间选择的方法也将用于后续注册。)

下图显示了 VDA 安装向导的 Delivery Controller 页面。

VDA 安装 Controller

基于策略 (LGPO\GPO)

Citrix 建议 VDA 首次注册时使用 GPO。它的优先级最高。(尽管以前列出的自动更新的优先级最高,但仅在首次注册之后使用自动更新。)基于策略的注册具有使用组策略进行配置的集中优势。

要指定此方法,请完成以下两个步骤:

  • 在 VDA 安装向导中的 Delivery Controller 页面上,选择以后(高级)。该向导会多次提醒您指定 Controller 地址,即使您在 VDA 安装期间不指定它们也是如此。(因为 VDA 注册如此重要!)
  • 可以在“Virtual Delivery Agent Settings > Controllers”设置中通过 Citrix 策略启用或禁用基于策略的 VDA 注册。(如果安全性是您的首要任务,请使用 Virtual Delivery Agent Settings > Controller SIDs 设置。)

此设置存储在 HKLM\Software\Policies\Citrix\VirtualDesktopAgent (ListOfDDCs) 下。

基于注册表

要指定此方法,请完成以下步骤之一:

  • 在 VDA 安装向导中的 Delivery Controller 页面上,选择手动操作。然后输入所安装 Controller 的 FQDN,并单击添加。如果您已安装更多 Controller,请添加其地址。
  • 对于命令行 VDA 安装,请使用 /controllers 选项并指定所安装 Controller 或 Cloud Connector 的 FQDN。

此信息通常存储在注册表项 HKLM\Software\Citrix\VirtualDesktopAgentHKLM\Software\Wow6432Node\Citrix\VirtualDesktopAgent 下的注册表值 ListOfDDCs 中。

还可以手动配置此注册表项或使用组策略首选项 (GPP)。此方法可能优于基于策略的方法(例如,如果您要对不同的 Controller 或 Cloud Connector 进行有条件的处理,如:对名称以 XDW-001- 开头的计算机使用 XDC-001)。

更新 ListOfDDCs 注册表项,该注册表项用于列出站点中所有 Controller 或 Cloud Connector 的 FQDN。(此注册表项相当于 Active Directory 站点 OU。)

HKEY_LOCAL_MACHINE\Software\Citrix\\VirtualDesktopAgent\ListOfDDCs (REG_SZ)

如果注册表位置 HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent 包括 ListOfDDCs 和 FarmGUID 两个注册表项,则 ListOfDDCs 用于 Controller 或 Cloud Connector 发现。如果在 VDA 安装期间指定站点 OU,则存在 FarmGUID。(这可能用于旧部署中。)

(可选)更新 ListOfSIDs 注册表项(有关详细信息,请参阅 ListOfSIDs):

HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfSIDs (REG_SZ)

谨记:

如果您还通过 Citrix 策略启用基于策略的 VDA 注册,则该配置会覆盖您在 VDA 安装期间指定的设置,因为该方法的优先级更高。

基于 Active Directory OU(旧)

支持此方法主要是为了向后兼容,建议不要使用此方法。如果您仍在使用此方法,Citrix 建议改为其他方法。

要指定此方法,请完成以下两个步骤:

  • 在 VDA 安装向导中的 Delivery Controller 页面上,选择从 Active Directory 中选择位置
  • 使用 Set-ADControllerDiscovery.ps1 脚本(在每个 Controller 上都可用)。此外,在每个 VDA 上配置 FarmGuid 注册表项以指向正确的 OU。可以使用组策略配置此设置。

有关详细信息,请参阅基于 Active Directory OU 的发现

基于 MCS

如果您计划只使用 MCS 来预配 VM,可以指示 MCS 设置 Controller 或 Cloud Connector 列表。此功能与自动更新兼容:在首次预配期间(创建计算机目录时),MCS 将 Controller 或 Cloud Connector 列表填入 Personality.ini 文件中。自动更新会使该列表保持最新。

建议不要将此方法用于大型环境中。在下列情况下,可以使用此方法:

  • 小型环境
  • 不会在站点之间移动 VDA
  • 只使用 MCS 预配 VM
  • 您不想使用组策略

要指定此方法,请执行以下操作:

  • 在 VDA 安装向导中的 Delivery Controller 页面上,选择让 Machine Creation Services 自动创建

建议

最佳做法:

  • 首次注册时使用组策略注册方法。
  • 使用自动更新(默认情况下启用)使 Controller 列表保持最新。
  • 在多区域部署中,首次配置时使用组策略(至少有两个 Controller 或 Cloud Connector)。将 VDA 指向其区域中的本地 Controller 或 Cloud Connector。使用自动更新使其保持最新。自动更新会自动优化卫星区域中 VDA 的 ListOfDDCs。

自动更新

默认情况下启用自动更新(在 XenApp 和 XenDesktop 7.6 中引入)。这是使 VDA 注册保持最新的最有效方法。尽管首次注册时不使用自动更新,但在首次注册时,自动更新软件会下载 ListOfDDCs 并将其存储在 VDA 上的永久性缓存中。对每个 VDA 都会执行此操作。(此缓存中还保存计算机策略信息,这样可以确保在重新启动后保留策略设置。)

使用 MCS 或 PVS 预配计算机时支持自动更新,但 PVS 服务器端缓存除外(这不是常见场景,因为自动更新缓存没有对应的静态存储)。

要指定此方法,请执行以下操作:

  • 通过包含设置“Virtual Delivery Agent Settings > Enable auto update of Controllers”的 Citrix 策略启用或禁用自动更新。默认情况下,启用此设置。

工作原理:

  • 每次 VDA 重新注册时(例如,重新启动计算机后),都会更新缓存。此外,每个 Controller 或 Cloud Connector 每 90 分钟检查一次站点数据库。如果自上次检查后添加或删除了 Controller 或 Cloud Connector,或者如果发生了影响 VDA 注册的策略更改,Controller 或 Cloud Connector 会向其注册的 VDA 发送更新列表,并更新缓存。VDA 接受来自其最新缓存列表中所有 Controller 或 Cloud Connector 的连接。
  • 如果 VDA 接收的列表不包括其注册的 Controller 或 Cloud Connector(即,已从站点中删除该 Controller 或 Cloud Connector),VDA 将从 ListOfDDCs 中选择 Controller 或 Cloud Connector 并重新注册。

例如:

  • 某个部署包含三个 Controller: A、B 和 C。VDA 向 Controller B 注册(该 Controller 在 VDA 安装期间指定)。
  • 之后,将 D 和 E 两个 Controller 添加到站点中。在 90 分钟内,VDA 收到更新的列表,然后接受来自 Controller A、B、C、D 和 E 的连接。(在重新启动 VDA 之前,负载不会平均分布到所有 Controller。)
  • 再之后,Controller B 移至另一个站点。在 90 分钟内,原始站点中的 VDA 收到更新的列表,因为自上次检查后 Controller 已发生更改。最初已向 Controller B 注册的 VDA(该 Controller 已不在列表中)将从当前列表(A、C、D 和 E)中选择 Controller 并重新注册。

在一个多区域部署中,卫星区域中的自动更新会先自动缓存所有本地 Controller。主要区域中的所有 Controller 都缓存在备份组中。如果卫星区域中无本地 Controller 可用,将尝试向主要区域中的 Controller 注册。

如下例所示,缓存文件包含主机名和安全 ID 列表 (ListOfSIDs)。VDA 不会查询 SID,这会降低 Active Directory 负载。

VDA 注册缓存文件

可以使用 WMI 调用来检索缓存文件。但是,它存储在只有 SYSTEM 帐户可读的位置中。提供此信息只是供参考。请勿修改此文件。如果修改此文件或文件夹,会导致配置不受支持。

Get-WmiObject -Namespace “Root\Citrix\DesktopInformation” -Class “Citrix_VirtualDesktopInfo” -Property “PersistentDataLocation”

如果出于安全原因(不同于降低 Active Directory 负载)需要手动配置 ListOfSIDs,不能使用自动更新功能。有关详细信息,请参阅 ListOfSIDs

自动更新优先级例外情况

尽管通常情况下,在所有 VDA 注册方法中自动更新的优先级最高,它会覆盖其他方法的设置,仍有一个例外情况。缓存中的 NonAutoListOfDDCs 元素指定 VDA 首次配置方法。自动更新会监视此信息。如果首次注册方法更改,则注册过程会跳过自动更新,并使用配置的优先级次高的方法。将 VDA 移至另一个站点时(例如,在灾难恢复期间),这很有用。

配置注意事项

Controller 或 Cloud Connector 地址

无论使用哪种方法指定 Controller 或 Cloud Connector,Citrix 都建议使用 FQDN 地址。IP 地址并不视为可信配置,因为与 DNS 记录相比,IP 更容易受影响。如果手动填充 ListOfSIDs,可以在 ListOfDDCs 中使用 IP。但是,仍建议使用 FQDN。

负载平衡

如前所述,VDA 会自动在 ListOfDDCs 中的所有 Controller 或 Cloud Connector 之间分发连接。Citrix 代理协议 (CBP) 中内置了故障转移和负载平衡功能。如果在配置中指定多个 Controller 或 Cloud Connector,需要时,注册会自动在这些 Controller 或 Cloud Connector 之间进行故障转移。由于自动更新功能,会自动为所有 VDA 进行故障转移。

出于安全原因,不能使用网络负载平衡器(例如 Citrix ADC)。VDA 注册使用 Kerberos 双向身份验证,在这种验证中,客户端 (VDA) 必须向服务 (Controller) 证明其身份。但是,Controller 或 Cloud Connector 必须向 VDA 证明其身份。这意味着 VDA 和 Controller 或 Cloud Connector 同时用作服务器和客户端。如本文开头所述,有两种通信通道:VDA 到 Controller 或 Cloud Connector 和 Controller 或Cloud Connector 到 VDA。

此过程中的组件称为服务主体名称 (SPN),它作为属性存储在 Active Directory 计算机对象中。VDA 连接到 Controller 或 Cloud Connector 时,它必须指定要与“谁”通信。此地址为 SPN。如果使用负载平衡的 IP,则 Kerberos 双向身份验证会正确识别该 IP 不属于预期的 Controller 或 Cloud Connector。

有关详细信息,请参阅:

自动更新替代 CNAME

自动更新功能替代了 XenApp 和 XenDesktop 7.x 之前版本中的 CNAME(DNS 别名)功能。从 XenApp 和 XenDesktop 7 开始,禁用 CNAME 功能。使用自动更新替代 CNAME。(如果必须使用 CNAME,请参阅 CTX137960。为了持续使用 DNS 别名,请勿同时使用自动更新和 CNAME。)

Controller/Cloud Connector 组

您可能希望分组处理 Controller 或 Cloud Connector。分组后,如果所有 Controller/Cloud Connector 都出现故障,则首选一个组,另一个组用于故障转移。请注意,Controller 或 Cloud Connector 是随机从列表中选择的,因此,分组可以有助于实施优先使用。

使用括号指定 Controller/Cloud Connector 组。例如,有四个 Controller(两个主要,两个备份),分组方式可以如下:

(XDC-001.cdz.lan XDC-002.cdz.lan) (XDC-003.cdz.lan XDC-004.cdz.lan)。

在此示例中,先处理第一个组(001 和 002)中的 Controller。如果它们都发生故障,则处理第二个组中的 Controller(003 和 004)。

ListOfSIDs

VDA 可以访问以进行注册的 Controller 列表是 ListOfDDCs。VDA 还必须知道信任哪些 Controller;VDA 不会自动信任 ListOfDDCs 中的 Controller。ListOfSIDs(安全 ID)用于标识可信 Controller。VDA 将只向可信 Controller 尝试注册。

在大多数环境中,会自动基于 ListOfDDCs 生成 ListOfSIDs。可以使用 CDF 跟踪来读取 ListOfSIDs。

通常,无需手动修改 ListOfSIDs。存在几种例外情况。由于有了较新的技术,前两种例外情况已不存在。

  • Controller 使用单独的角色: 在 XenApp 和 XenDesktop 7.7 中引入区域之前,仅当一部分 Controller 用于注册时手动配置 ListOfSIDs。例如,如果使用 XDC-001 和 XDC-002 作为 XML Broker,使用 XDC-003 和 XDC-004 进行 VDA 注册,则在 ListOfSIDs 中指定所有 Controller,在 ListOfDDCs 中指定 XDC-003 和 XDC-004。这不是典型配置也不是建议的配置,不应在较新的环境中使用。而是改用区域。
  • 降低 Active Directory 负载: 在 XenApp 和 XenDesktop 7.6 中引入自动更新功能之前,使用 ListOfSIDs 来降低域控制器上的负载。通过预填充 ListOfSIDs,可以跳过从 DNS 名称到 SID 的解析。但是,有了自动更新功能后,不再需要执行此操作,因为此永久性缓存中包含 SID。Citrix 建议使自动更新功能保持启用状态。
  • 安全性: 在一些受到高度保护的环境中,手动配置了可信 Controller 的 SID 以避免来自受感染 DNS 服务器的潜在安全威胁。但是,如果禁用了该策略,则必须禁用自动更新功能。否则,将使用永久性缓存中的配置。

因此,除非有特殊原因,否则请勿修改 ListOfSIDs。

如果必须修改 ListOfSIDs,请在 HKLM\Software\Citrix\VirtualDesktopAgent 下面创建名为 ListOfSIDs (REG_SZ) 的注册表项。值为可信 SID 列表,如果有多个,用空格分隔开。

在以下示例中,一个 Controller 用于 VDA 注册 (ListOfDDCs),两个 Controller 用于代理 (List OfSIDs)。

VDA 注册

在 VDA 注册期间搜索 Controller

当 VDA 尝试注册时,Broker 代理首先在本地域中执行 DNS 查找,以确保可以访问指定的 Controller。

如果初始查找找不到 Controller,Broker 代理可以在 AD 中启动回退自上而下查询。该查询将搜索所有域,并经常重复。如果 Controller 地址无效(例如,管理员在安装 VDA 时输入了不正确的 FQDN),该查询的活动可能会导致域控制器上的分布式拒绝服务 (DDoS) 条件。

下面的注册表项控制在初始搜索期间找不到 Controller 时 Broker 代理是否使用回退自上而下查询。

HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent

  • 名称:DisableDdcWildcardNameLookup
  • 类型: DWORD
  • 值:1(默认值)或 0

如果设置为 1,则将禁用回退搜索。如果 Controller 的初始搜索失败,Broker 代理将停止查找。此为默认设置。 如果设置为 0,则启用回退搜索。如果 Controller 的初始搜索失败,则启动回退自上而下搜索。

VDA 注册问题故障排除

如前所述,必须向要在启动代理会话时考虑使用的 Delivery Controller 注册 VDA。未注册的 VDA 会导致无法充分利用原本可用的资源。VDA 无法注册的原因有多种,其中许多都可由管理员进行故障排除。Studio 在目录创建向导中,以及在您创建了交付组之后,提供故障排除信息。

在计算机目录创建期间发现问题:

在目录创建向导中,添加现有计算机之后,计算机帐户名称列表会指示每台计算机是否都适合添加到该目录。将鼠标悬停在每个计算机旁边的图标上,以显示有关该计算机的有用消息。

如果该消息确定存在一台有问题的计算机,您可以删除该计算机(使用删除按钮),也可以添加计算机。例如,如果一条消息指示未获取有关某台计算机的信息(可能因为它始终未向 Delivery Controller 注册),您可能会选择添加计算机。

目录的功能级别控制哪些产品功能可用于目录中的计算机。要使用新产品版本中采用的功能,可能需要使用新的 VDA。通过设置功能级别,该版本(及更高版本,如果功能级别未更改)中采用的所有功能均可用于目录中的计算机。但是,具有早期 VDA 版本的目录中的计算机将无法注册。

在创建了交付组之后发现问题:

创建了交付组之后,Studio 会显示与该组关联的计算机的详细信息。交付组的详细信息窗格中指示预期注册但未注册的计算机数。即,可能存在一台或多台已开启且不是处于维护模式但当前未向 Controller 注册的计算机。查看“未注册、但应注册的”计算机时,请查看详细信息窗格中的故障排除选项卡,了解可能的原因以及建议的更正措施。

有关功能级别的详细信息,请参阅创建计算机目录中的 VDA 版本和功能级别部分。

有关 VDA 注册故障排除的详细信息,请参阅 CTX136668

还可以使用 Citrix Health Assistant 对 VDA 注册和会话启动进行故障排除。有关详细信息,请参阅 CTX207624