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 页面。
基于策略 (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\VirtualDesktopAgent 或 HKLM\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 负载。
可以使用 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。
有关详细信息，请参阅：
- Kerberos 简介：https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
- 使用 Kerberos 的双向身份验证：https://docs.microsoft.com/en-us/windows/win32/ad/mutual-authentication-using-kerberos?redirectedfrom=MSDN
自动更新替代 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 注册期间搜索 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。