Lync Server 2013 中的移动性技术要求

  • 项目

 

上次修改的主题： 2014-07-24

Some information in this topic pertains to Cumulative Updates for Lync Server 2013: February 2013.

移动用户遇到各种需要特殊规划的移动应用程序方案。 例如，有人可能会在下班时通过 3G 网络连接开始使用移动应用程序，然后在到达工作时切换到公司Wi-Fi网络，然后在离开大楼时切换回 3G。 需要规划环境以支持此类网络转换，并保证用户体验一致。 本部分介绍为支持移动应用程序和自动发现移动资源而必须满足的基础结构要求。

注意

尽管移动应用程序也可以连接到其他 Lync Server 2013 服务，但将所有移动应用程序 Web 请求发送到同一外部 Web 完全限定域名 (FQDN 的要求) 仅适用于 Lync Server 2013 移动服务。 其他移动服务不需要此配置。

硬件负载均衡器中对 Cookie 相关性的要求大大降低，如果使用 Lync Mobile 与 Lync Server 2013 一起交付的 Lync Mobile，则可以替换传输控制协议 (TCP) 相关性。 仍可使用 Cookie 相关性，但 Web 服务不再需要它。

重要

所有移动服务流量都通过反向代理，无论源点位于何处（内部或外部）。 如果是单个反向代理或反向代理场，或者是提供反向代理函数的设备，则当内部流量通过接口流出并尝试在同一接口上立即流入时，可能会出现问题。 这通常会导致安全规则冲突（称为 TCP 数据包欺骗或只是欺骗）。 必须允许头发固定 (数据包或一系列数据包) 的出口和即时流入，以便移动性正常工作。 解决此问题的一种方法是使用独立于防火墙的反向代理， (应始终在防火墙中强制实施欺骗防护规则，以便安全) 。 发夹可能发生在反向代理的外部接口，而不是防火墙外部接口。 检测防火墙的欺骗行为，并放宽反向代理处的规则，从而允许移动性所需的发夹。
如果可能，请使用域名系统 (DNS) 主机或 CNAME 记录来定义发夹行为的反向代理 (而不是防火墙) 。

Lync Server 2013 支持 Lync 2010 移动版和 Lync 2013 移动客户端的移动服务。 这两个客户端都使用 Lync Server 2013 自动发现服务来查找其移动性入口点，但它们使用的移动服务不同。 Lync 2010 移动版使用称为 Mcx 的移动服务，该服务随 Lync Server 2010 累积更新一起引入：2011 年 11 月。 Lync 2013 移动客户端使用统一通信 Web API 或 UCWA 作为移动服务提供商。

内部和外部 DNS 配置

移动服务 Mcx (引入了 Lync Server 2010 的累积更新：2011 年 11 月，) 和 UCWA (在 Lync Server 2013 累积汇报中引入：2013 年 2 月) 以相同的方式使用 DNS。

使用自动发现时，移动设备使用 DNS 查找资源。 在 DNS 查找期间，首先尝试连接到与 lyncdiscoverinternal (内部 DNS 记录关联的 FQDN。<内部域名>) 。 如果无法使用内部 DNS 记录建立连接，则使用外部 DNS 记录 (lyncdiscover 尝试连接。<sipdomain>) 。 网络内部的移动设备连接到内部自动发现服务 URL，网络外部的移动设备连接到外部自动发现服务 URL。 外部自动发现请求通过反向代理。 Lync Server 2013 自动发现服务返回用户主池的所有 Web 服务 URL，包括移动服务 (Mcx 和 UCWA) URL。 但是，内部移动服务 URL 和外部移动服务 URL 都与外部 Web 服务 FQDN 相关联。 因此，无论移动设备是网络内部还是外部，设备始终通过反向代理在外部连接到 Lync Server 2013 移动服务。

注意

请务必了解部署可以包含多个不同的命名空间，供内部和外部使用。 SIP 域名可能不同于内部部署域名。 例如，SIP 域可能 contoso.com，而内部部署可能 contoso.net。 登录到 Lync Server 的用户将使用 SIP 域名，例如 john@contoso.com。 将拓扑生成器中定义的外部 Web 服务 (寻址为 外部 Web 服务) 时，域名和 SIP 域名将保持一致，如 DNS 中定义的那样。 将拓扑生成器中定义 (的 内部 Web 服务作为内部 Web 服务) 寻址时，内部 Web 服务的默认名称将是前端服务器、前端池、Director 或 Director 池的 FQDN。 可以选择重写内部 Web 服务名称。 应使用内部域名 (而不是内部 Web 服务的 SIP 域名) ，并定义 DNS 主机 A (，或者，对于 IPv6，AAAA) 记录来反映重写名称。 例如，默认的内部 Web 服务 FQDN 可能 pool01.contoso.net。 可能 webpool.contoso.net 重写内部 Web 服务 FQDN。 以这种方式定义 Web 服务有助于确保观察服务的内部和外部区域性，而不是使用这些服务的用户的本地性。
但是，由于 Web 服务是在拓扑生成器中定义的，并且可以重写内部 Web 服务名称，只要生成的 Web 服务名称、验证它的证书以及定义它的 DNS 记录是一致的，因此可以使用所需的任何域名（包括 SIP 域名）定义内部 Web 服务。 最终，IP 地址的名称解析由 DNS 主机记录和一致命名空间决定。
对于本主题和示例，内部域名用于说明拓扑和 DNS 定义。

下图演示了使用内部和外部 DNS 配置时移动服务和自动发现服务的移动应用程序 Web 请求流。

使用自动发现出行服务流

cdb96424-96f2-4abf-88d7-1d32d1010ffd

注意

此图演示了通用 Web 服务。 名为 Mobility 的虚拟目录描绘了移动服务 Mcx 和/或 UCWA。 如果尚未为 Lync Server 2013：2013 年 2 月应用累积汇报，则可能在内部和外部 Web 服务上定义了虚拟目录 Ucwa，也可能没有定义虚拟目录 Ucwa。 你将有一个虚拟目录自动发现，你可能有一个虚拟目录 Mcx。
无论部署的移动服务技术如何，自动发现和发现服务的工作方式都是相同的。

若要支持来自公司网络内部和外部的移动用户，内部和外部 Web FQDN 必须满足某些先决条件。 此外，可能需要满足其他要求，具体取决于选择实现的功能：

  • 新的 DNS、CNAME 或 A (主机（如果 IPv6、AAAA) 记录）用于自动发现。

  • 新防火墙规则（如果希望通过 Wi-Fi 网络支持推送通知）。

  • 内部服务器证书和反向代理证书上的使用者替代名称，用于自动发现。

  • 前端服务器硬件负载均衡器配置更改源相关性。

拓扑必须满足以下要求才能支持移动服务和自动发现服务：

  • 前端池内部 Web FQDN 必须与前端池外部 Web FQDN 不同。

  • 内部 Web FQDN 只能解析为可从公司网络内部访问。

  • 外部 Web FQDN 只能解析为可从 Internet 访问。

  • 对于公司网络内的用户，必须将移动服务 URL 地址到外部 Web FQDN。 此要求适用于移动服务，仅适用于此 URL。

  • 对于公司网络外部的用户，请求必须转到前端池或 Director 的外部 Web FQDN。

如果支持自动发现，则需要为每个 SIP 域创建以下 DNS 记录：

  • 一条内部 DNS 记录，用于支持从组织网络内部进行连接的移动用户。

  • 用于支持从 Internet 连接的移动用户的外部或公共 DNS 记录。

内部自动发现 URL 不应从网络外部寻址。 不应从网络内部寻址外部自动发现 URL。 但是，如果无法满足外部 URL 的此要求，移动客户端在功能上可能不会受到影响，因为始终先尝试内部 URL。

如果 IPv6、AAAA) 记录，则 DNS 记录可以是 CNAME 记录或 A (主机。

注意

移动设备客户端不支持多个安全套接字层 (来自不同域的 SSL) 证书。 因此，HTTPS 不支持 CNAME 重定向到不同的域。 例如，HTTPS 不支持重定向到 director.contoso.net 地址的 lyncdiscover.contoso.com 的 DNS CNAME 记录。 在此类拓扑中，移动设备客户端需要对第一个请求使用 HTTP，以便通过 HTTP 解析 CNAME 重定向。 然后，后续请求使用 HTTPS。 若要支持此方案，需要使用端口 80 (HTTP) 的 Web 发布规则配置反向代理。 有关详细信息，请参阅“为端口 80 创建 Web 发布规则”，在 Lync Server 2013 中为移动性配置反向代理。
HTTPS 支持 CNAME 重定向到同一域。 在这种情况下，目标域的证书涵盖源域。

有关方案所需的 DNS 记录的详细信息，请参阅 DNS 摘要 - Lync Server 2013 中的自动发现。

端口和防火墙要求

如果支持推送通知并希望 Apple 移动设备通过Wi-Fi网络接收推送通知，则还需要在企业Wi-Fi网络上打开端口 5223。 端口 5223 是 Apple Push Notification Service (APNS) 使用的出站 TCP 端口。 移动设备启动连接。 有关详细信息，请参阅 http://support.apple.com/kb/TS1629 。

警告

使用 Lync 2013 移动版客户端的 Apple 设备不需要推送通知。

请注意，如果用户位于 Survivable Branch Appliance (SBA) ，则需要以下端口：

  • UcwaSipExternalListeningPort 需要端口 5088

  • UcwaSipPrimaryListeningPort 需要端口 5089

有关自动发现端口和协议要求的其他详细信息和指南，请参阅 端口摘要 - Lync Server 2013 中的自动发现。

证书要求

如果支持 Lync 移动客户端的自动发现，则需要修改证书上的使用者替代名称列表，以支持来自移动客户端的安全连接。 需要为运行自动发现服务的每个前端服务器和目录请求和分配新证书，并添加本部分中所述的主题备用名称条目。 建议的方法也是修改反向代理证书上的使用者替代名称列表。 需要为组织中的每个 SIP 域添加使用者替代名称条目。

使用内部证书颁发机构重新颁发证书通常是一个简单的过程，但将多个使用者替代名称条目添加到反向代理使用的公共证书可能非常昂贵。 如果有许多 SIP 域，因此添加使用者替代名称的成本非常高，可以配置反向代理以使用 HTTP 通过端口 80 发出初始自动发现服务请求，而不是使用 HTTPS 的端口 443 (默认配置) 。 然后，请求重定向到 Director 或前端池上的端口 8080。 在端口 80 上发布初始自动发现服务请求时，无需更改反向代理的证书，因为请求使用 HTTP 而不是 HTTPS。 支持此方法，但我们不建议这样做。

Internet Information Services (IIS) 要求

建议使用 IIS 7.5、IIS 8.0 或 IIS 8.5 实现移动性。 移动服务安装程序在 ASP.NET 中设置标志以提高性能。 默认情况下，IIS 7.5 安装在 Windows Server 2008 R2 上，IIS 8.0 安装在 Windows Server 2012 上，IIS 8.5 安装在 Windows Server 2012 R2 上。 移动服务安装程序会自动更改 ASP.NET 设置。

硬件负载平衡器要求

在支持前端池的硬件负载均衡器上，必须为源配置用于 Web 服务流量的外部 Web 服务虚拟 IP (VIP) 。 源相关性有助于确保从单个客户端的多个连接发送到一台服务器以保持会话状态。 有关相关性要求的详细信息，请参阅 Lync Server 2013 的负载均衡要求。

如果计划仅通过内部Wi-Fi网络支持 Lync 移动客户端，则应为源配置内部 Web 服务 VIPS，如外部 Web 服务 VIP 所述。 在这种情况下，应对硬件负载均衡器上的内部 Web 服务 VIP 使用source_addr (或 TCP) 相关性。 有关详细信息，请参阅 Lync Server 2013 的负载均衡要求。

反向代理要求

如果支持 Lync 移动客户端的自动发现，则需要更新当前发布规则，如下所示：

  • 如果决定更新反向代理证书上的使用者替代名称列表，并将 HTTPS 用于初始自动发现服务请求，则必须更新 lyncdiscover 的 Web 发布规则。<sipdomain>. 通常，这会与前端池上外部 Web 服务 URL 的发布规则结合使用。

  • 如果决定对初始自动发现服务请求使用 HTTP，以便无需更新反向代理证书上的使用者替代名称列表，则必须为端口 HTTP/TCP 80 创建新的 Web 发布规则（如果尚不存在）。 如果 HTTP/TCP 80 的规则已存在，则可以更新该规则以包含 lyncdiscover。<sipdomain> 条目。