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 页面。
基于策略 (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。可以使用组策略配置此设置。
基于 MCS
如果使用 MCS 预配 VM，MCS 会设置 Controller 或 Cloud Connector 列表。此功能可进行自动更新。创建目录时，MCS 会在初始预配期间将 Controller 或 Cloud Connector 列表注入到 Personality.ini 文件中。自动更新会使该列表保持最新状态。
要指定此方法，请在 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 负载。
可以使用 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 或更高版本，需要执行一个额外的步骤才能使用注册组功能。需要从 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)。
在 VDA 注册期间搜索 Controller
当 VDA 尝试注册时，Broker 代理首先在本地域中执行 DNS 查找，以确保可以访问指定的 Controller。
如果初始查找找不到 Controller，Broker 代理可以在 AD 中启动回退自上而下查询。该查询将搜索所有域，并经常重复。如果 Controller 地址无效（例如，管理员在安装 VDA 时输入了不正确的 FQDN），该查询的活动可能会导致域控制器上的分布式拒绝服务 (DDoS) 条件。
下面的注册表项控制在初始搜索期间找不到 Controller 时 Broker 代理是否使用回退自上而下查询。
HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent
- 名称：
DisableDdcWildcardNameLookup - 类型：
DWORD - 值：
0（默认值）或任何非零值
设置为 0 时，启用回退搜索。如果 Controller 的初始搜索失败，则启动回退自上而下搜索。这是默认行为。但是，如果设置为任何非零值，则会禁用回退搜索。如果 Controller 的初始搜索失败，Broker 代理将停止查找。
使用只读域控制器在 VDA 注册期间进行 LDAP 绑定排序
当 VDA 注册到只读域控制器 (RODC) 时，Broker 代理必须选择要忽略的一个或多个轻型目录访问协议 (LDAP) 绑定。要做出此选择，Broker 代理需要合适的注册表项。
如果未提供注册表项或者注册表项字段为空，则向 RODC 注册 VDA 需要更长的时间，因为需要执行原始 LDAP 绑定顺序。
要修改 LDAP 绑定顺序，已将注册表项 ListofIgnoredBindings 添加到 HKEY_LOCAL_MACHINE\Software\Policies\Citrix\VirtualDesktopAgent。使用 ListofIgnoredBindings 允许您在必要时修改 LDAP 绑定顺序，从而加快 RODC 的 VDA 注册速度。
- 名称：
ListofIgnoredBindings - 类型：
REG_SZ - 值：
DefaultPath、DomainPath、PDCPath
该值是绑定路径选项的列表，每个选项由逗号分隔。注册表项将忽略其未识别为有效的值。
VDA 注册问题故障排除
如前所述，必须向要在启动代理会话时考虑使用的 Delivery Controller 或 Cloud Connector 注册 VDA。未注册的 VDA 会导致无法充分利用原本可用的资源。VDA 无法注册的原因有多种，其中许多都可由管理员进行故障排除。Studio 在目录创建向导中，以及在您创建了交付组之后，提供故障排除信息。
-
在计算机目录创建期间发现问题： 在目录创建向导中，添加现有计算机之后，计算机帐户名称列表会指示每台计算机是否都适合添加到该目录。将鼠标悬停在每个计算机旁边的图标上，以显示有关该计算机的有用消息。
如果该消息确定存在一台有问题的计算机，您可以删除该计算机（使用删除按钮），也可以添加计算机。例如，如果一条消息指示未获取有关某台计算机的信息（可能因为该计算机始终未注册），您可能会选择添加计算机。
目录的功能级别控制哪些产品功能可用于目录中的计算机。要使用新产品版本中引入的功能，可能需要使用新 VDA。通过设置功能级别，该版本（及更高版本，如果功能级别未更改）中引入的所有功能均可用于目录中的计算机。但是，具有早期 VDA 版本的目录中的计算机将无法注册。
-
在创建了交付组之后发现问题： 创建了交付组之后，Studio 会显示与该组关联的计算机的详细信息。
交付组的详细信息窗格中指示应该注册但未注册的计算机数。即，可能存在一台或多台已开启且不是处于维护模式但当前未向 Controller 注册的计算机。查看“应注册、但未注册的”计算机时，请查看“详细信息”窗格中的故障排除选项卡，了解可能的原因以及建议的更正措施。
有关 VDA 注册故障排除的详细信息
-
有关功能级别的详细信息，请参阅 VDA 版本和功能级别。
-
有关 VDA 注册故障排除的详细信息，请参阅 CTX136668。
-
还可以使用 Citrix Scout 运行状况检查对 VDA 注册和会话启动进行故障排除。有关详细信息，请参阅关于运行状况检查。