Citrix Virtual Apps and Desktops

VDA 注册

简介

注意:

在本地环境中,VDA 注册到 Delivery Controller。在 Citrix Cloud 服务环境中,VDA 注册到 Cloud Connector。在混合环境中,某些 VDA 注册到 Delivery Controller,而其他 VDA 注册到 Cloud Connector。

VDA 必须先向站点中的一个或多个 Controller 或 Cloud Connector 注册(建立连接),然后该 VDA 才可以使用。VDA 通过检查名为 ListofDDCs 的列表来查找控制器或连接器。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 中的其他项。

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

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 安装向导中的“Delivery 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 注册表位置包含这两个注册表项 ListOfDDCsFarmGUID,则 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 页面上,选择 Let Machine Creation Services do it(让 Machine Creation Services 完成)。

审查和建议

最佳做法:

  • 首次注册时使用组策略注册方法。
  • 使用自动更新(默认情况下启用)使 Controller 列表保持最新。
  • 在多区域部署中,首次配置时使用组策略(至少有两个 Controller 或 Cloud Connector)。将 VDA 指向其区域中的本地 Controller 或 Cloud Connector。使用自动更新使其保持最新。自动更新会自动优化卫星区域中 VDA 的 ListofDDCs
  • 在某个控制器不可用时,在 ListOfDDCs 注册表项中列出多个以空格分隔的控制器可防止出现注册问题。例如:

     DDC7x.xd.local DDC7xHA.xd.local
    
     32-bit: HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs
    
     HKEY_LOCAL_MACHINE \Software\Citrix\VirtualDesktopAgent\ListOfDDCs (REG_SZ)
     <!--NeedCopy-->
    
  • 请确保 ListofDDCs 下列出的所有值都映射到有效的完全限定域名,以防止出现启动注册延迟问题。

自动更新

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

使用 MCS 或 Citrix Provisioning 预配计算机时支持自动更新,但 Citrix Provisioning 服务器端缓存除外。服务器端缓存不是常见的情况,因为没有用于自动更新缓存的持久存储。

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

  • 通过包含设置“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 移至另一个站点时(例如,在灾难恢复期间),此过程很有用。

配置注意事项

查看常见的 VDA 注册配置。

查看 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)。

对于 XenDesktop 7.0 或更高版本,需要执行一个额外的步骤才能使用注册组功能。需要从 Citrix Studio 中禁用启用控制器自动更新策略。

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)。

使用不同的 Controller 进行注册和代理的示例

在 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 或 Cloud Connector 注册 VDA。未注册的 VDA 会导致无法充分利用原本可用的资源。VDA 无法注册的原因有多种,其中许多都可由管理员进行故障排除。Studio 在目录创建向导中,以及在您创建了交付组之后,提供故障排除信息。

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

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

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

  • 在创建了交付组之后发现问题: 创建了交付组之后,Studio 会显示与该组关联的计算机的详细信息。

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

有关 VDA 注册故障排除的详细信息

  • 有关功能级别的详细信息,请参阅 VDA 版本和功能级别

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

  • 还可以使用 Citrix Scout 运行状况检查对 VDA 注册和会话启动进行故障排除。有关详细信息,请参阅关于运行状况检查

VDA 注册