Product Documentation

向 Controller 注册 VDA

Jul 24, 2017

简介

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

为什么 VDA 注册如此重要? 

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

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

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

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

Controller 地址配置方法

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

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

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

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

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

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

localized image

基于策略 (LGPO\GPO)

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

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

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

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

在自动更新部分中示例的最后一步中,我们将 Controller B 移至另一个站点。自动更新会为 Controller B 以前所在站点中的 VDA 更新缓存。Controller B 现在所在站点的管理员只是创建/更新策略设置以添加 Controller B 的 FQDN。

基于注册表

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

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

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

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

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

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

如果注册表位置 HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent 包括 ListOfDDCs 和 FarmGUID 两个注册表项,则 ListOfDDCs 用于 Controller 发现。如果在 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 列表。此功能适用于自动更新:在首次置备期间(创建计算机目录时),MCS 将 Controller 列表填入 Personality.ini 文件中。自动更新会使该列表保持最新。

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

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

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

  • 在 VDA 安装向导中的 Delivery Controller 页面上,选择 Let Machine Creation Services do it(让 Machine Creation Services 完成)。

建议

最佳做法:

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

自动更新

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

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

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

  • 通过包含该设置的 Citrix 策略启用或禁用:Virtual Delivery Agent 设置 > 启用控制器自动更新。默认情况下启用此设置。

工作原理:

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

例如:

  • 某个部署包含三个 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 负载。

localized image

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

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

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

自动更新优先级例外情况

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

配置注意事项

Controller 地址

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

负载平衡

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

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

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

有关详细信息,请参阅:

Kerberos 简介:https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/

使用 Kerberos 进行双向身份验证:https://msdn.microsoft.com/en-us/library/ms677600 

自动更新替代 CNAME

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

Controller 组

在有些情况下,您可能希望按组处理 Controller,一个组作为首选组,其他组用于在该组中所有 Controller 发生故障时进行故障转移。请记住,Controller 是随机从列表中选择的,因此,分组可以有助于实施优先使用。

使用括号指定 Controller 组。例如,有四个 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)。

localized image

VDA 注册问题故障排除

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

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

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

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

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

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

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

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

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

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