行動的技術需求

網站需求

您的拓撲必須符合下列需求，才能支援 Mobility Service 和自動探索服務：

• 前端集區內部 Web FQDN 必須與 前端集區 外部 Web FQDN 區別。

• 內部 Web FQDN 必須只解析為公司網路內部，並且可以從公司網路內部存取。

• 外部網站 FQDN (內部及外部使用者要求皆需定址的 Mobility Service URL 除外) 都必須解析至網際網路，並僅能從網路存取。

• 針對在公司網路內部的使用者，Mobility Service URL 必須定址至外部 Web FQDN。此需求適用於 Mobility Service，並且只套用至這個 URL。

• 針對在公司網路外部的使用者，要求必須傳送至前端集區或 Director 的外部 Web FQDN。

• 如果您有裂腦 (split-brain) DNS 環境，且行動裝置用戶端將以無線方式連線，則您需要以公用 IP 位址，在內部 DNS 中設定外部 Web FQDN。

DNS 需求

您的拓撲必須符合在以下章節落描述的 DNS 需求，以支援 Mobility Service 和自動探索服務。

自動探索和推播通知需求

如果您支援自動探索，則需要為每個 SIP 網域建立下列 DNS 記錄：

• 內部 DNS 記錄，以支援從組織網路內部連線的行動使用者

• 外部 (或公用) DNS 記錄，以支援從網際網路連線的行動使用者

• 支援推播通知的外部或公用 DNS 記錄

內部自動探索 URL 應該不能從您的網路外部定址。外部自動探索 URL 應該不能從您的網路內部定址。不過，如果您無法達到這個外部 URL 的需求，行動用戶端的功能應該不會受影響，因為一定都會先嘗試內部 URL。

DNS 記錄可以是 CNAME 記錄或 A (主機) 記錄。

您需要建立下列內部 DNS 記錄：

內部 DNS 記錄

記錄類型	主機名稱	解析為
A (主機)	lyncweb.contoso.com (外部 Web 服務 URL 範例)	舉例來說，位在內部 DNS 並解為至外部 Web 服務 URL 之外部 IP 位置的記錄。 https://lyncweb.contoso.com

及以下其他內部 DNS 記錄之一：

記錄類型	主機名稱	解析為
CNAME	lyncdiscoverinternal.<sipdomain>	Director 集區 (如果您有的話) 或前端集區 (如果您沒有 Director 的話) 的內部 Web 服務 FQDN
A (主機)	lyncdiscoverinternal.<sipdomain>	如果您有 Director，則為 Director 集區的內部 Web 服務 IP 位址 (如果使用負載平衡器，則為虛擬 IP (VIP) 位址)；如果您沒有 Director，則為前端集區的內部 Web 服務 IP 位址

您必須建立下列其中一個外部 DNS 記錄：

外部 DNS 記錄

記錄類型	主機名稱	解析為
CNAME	lyncdiscover.<sipdomain>	如果您有 Director，則為 Director 集區 的外部 Web 服務 FQDN；如果您沒有 Director，則為前端集區的外部 Web 服務 FQDN
A (主機)	lyncdiscover.<sipdomain>	反向 Proxy 的外部或公用 IP 位址

附註：
外部流量會通過反向 Proxy。

附註：
行動裝置用戶端不支援來自不同網域的多個 Secure Sockets Layer (SSL) 憑證。因此，不支援透過 HTTPS 將 CNAME 重新導向至不同的網域。例如，不支援透過 HTTPS 將 lyncdiscover.contoso.com 的 DNS CNAME 記錄重新導向至 director.contoso.net 的位址。在這樣的拓撲中，行動裝置用戶端需要使用 HTTP 來進行第一個要求，以透過 HTTP 來解析 CNAME 重新導向。後續的要求則會使用 HTTPS。若要支援此案例，您需要以連接埠 80 的 Web 發行規則來設定反向 Proxy (HTTP)。如需詳細資訊，請參閱＜設定行動的反向 Proxy＞中的＜建立連接埠 80 的網頁發行規則＞。 支援透過 HTTPS 將 CNAME 重新導向至相同網域。在此情況下，目的地網域的憑證包含來源網域。

記錄類型	定義	解析為
SRV	_sipfederationtls._tcp.<SIP 網域名稱> 以裝載 Access Edge Service 記錄	舉例來說，_sipfedrationtls._tcp.contoso.com 搭配已定義的 TCP 5061 連接埠傳送至 sip.contoso.com 重要事項： SRV 記錄必須在相同的 SIP 網域中指向 A

連接埠和防火牆需求

Mobility Service 需要下列兩個 Web 服務接聽連接埠在 前端伺服器 或 Standard Edition 伺服器上。您可以在部署程序期間，使用 Set-CsWebServer Cmdlet 來手動設定這些連接埠。如需詳細資訊，請參閱＜設定行動的內部伺服器連接埠＞。

您也必須為 TCP 5061 建立一個允許規則，以與推播通知的線上提供者同盟。詳細資訊請參閱 參考架構。

• 連接埠 5086，可用來接聽來自公司網路內部的行動要求。這是 Mobility Service 內部程序使用的 SIP 連接埠。

• 連接埠 5087，可用來接聽來自網際網路的行動要求。這是 Mobility Service 外部程序使用的 SIP 連接埠。

如果您支援推入通知，並且想要讓 Apple 行動裝置透過 Wi-Fi 網路來接收推播通知，即需要在企業 Wi-Fi 網路上開啟連接埠 5223。 連接埠 5223 是 Apple Push Notification Service (APNS) 使用的輸出 TCP 連接埠。行動裝置或通知服務可以初始化連線，但需要企業 WiFi 網路上有可用的輸出埠。詳細資料請檢閱 http://support.apple.com/kb/TS1629 和 http://developer.apple.com/library/ios/#technotes/tn2265/_index.html

憑證需求

如果您支援 Lync 行動用戶端的自動探索，則需要修改憑證上的主體替代名稱清單，以支援從行動用戶端進行安全連線。您必須針對每個執行自動探索服務的前端伺服器和 Director，要求及指派新的憑證，新增本節說明的主體替代名稱項目。建議的方法是也為反向 Proxy 修改憑證上的主體替代名稱清單。您需要針對組織中的每個 SIP 網域，新增主體替代名稱項目。

使用內部憑證授權單位重新發出憑證通常是很簡單的程序，但是新增多個主體替代名稱項目至反向 Proxy 所使用的公用憑證會很昂貴。如果您有很多 SIP 網域，新增主體替代名稱會非常昂貴，您可以設定反向 Proxy，透過使用 HTTP 的連接埠 80 來發行初始自動探索服務要求，而不要透過使用 HTTPS 的連接埠 443 (預設值)。然後要求會重新導向至 Director 或前端集區上的連接埠 8080。當您在連接埠 80 上發行初始自動探索服務要求時，不需要變更反向 Proxy 的憑證，因為要求是使用 HTTP，而不是 HTTPS。此方法受支援，但不建議使用。

附註：
如需有關使用連接埠 80 來進行初始要求的詳細資訊，請參閱＜規劃外部使用者＞文件中，＜自動探索服務需求＞的＜使用連接埠 80 的初始自動探索程序＞。

附註：
如果 Lync Server 2010 基礎結構使用從內部憑證授權單位 (CA) 發出的內部憑證，而且您計劃要支援行動裝置以無線方式連線，則來自內部 CA 的根憑證鏈必須安裝在行動裝置上，否則您就必須變更為 Lync Server 基礎結構上的公用憑證。

本節說明下列憑證需要的主體替代名稱：

• Edge Server 或 Edge Server 集區

• Director 或 Director 集區

• 前端伺服器 或 前端集區

• 反向 Proxy

Director 集區憑證需求

附註：
或者，您可以將 SAN=*.<sipdomain> 僅用於自動探索 (lyncdiscover 及 lyncdicoverinternal) 記錄。

前端集區憑證需求

附註：
或者，您可以將 SAN=*.<sipdomain> 僅用於自動探索 (lyncdiscover 及 lyncdicoverinternal) 記錄。

反向 Proxy (公用 CA) 憑證需求

附註：
您要將此憑證指派給反向 Proxy 上的 SSL 接聽程式。

Internet Information Services (IIS) 需求

建議您使用 IIS 7.5 以用於行動性。Mobility Service 安裝程式會設定一些 ASP.NET 旗標來增進效能。依預設，IIS 7.5 會安裝在 Windows Server 2008 R2 上，而且 Mobility Service 安裝程式會自動變更 ASP.NET 設定。如果您在 Windows Server 2008 上使用 IIS 7.0，則需要手動變更這些設定。如需詳細資訊，請參閱＜安裝 Mobility Service 與自動探索服務＞。

硬體負載平衡器需求

如果您的環境包含前端集區，則必須設定用於 Web 服務流量之硬體負載平衡器上的外部 Web 服務虛擬 IP (VIP)，以獲得 Cookie 型持續性。Cookie 型持續性可確保來自單一用戶端的多個連線會傳送到一部伺服器，以維護工作階段狀態。Cookie 必須符合特定需求。如需 Cookie 需求的詳細資訊，請參閱＜負載平衡需求＞。

如果您計劃只透過內部 Wi-Fi 網路來支援 Lync 行動用戶端，則應該要像外部 Web 服務所描述的那樣，針對 Cookie 型持續性來設定內部 Web 服務 VIP。在此情況下，您不應將 source_addr 持續性用於硬體負載平衡器上的內部 Web 服務 VIP。如需詳細資訊，請參閱＜負載平衡需求＞。

反向 Proxy 需求

如果您支援 Lync 行動用戶端的自動探索，則需要建立新的 Web 發行規則，如下所示：

• 如果您決定更新反向 Proxy 憑證上的主體替代名稱清單，並為初始自動探索服務要求使用 HTTPS，您需要為 lyncdiscover 建立一個新的網頁發佈規則。<sipdomain>。您也必須確保 前端集區 上的外部 Web 服務存在網頁發佈規則。

• 如果您決定使用 HTTP 來進行初始自動探索服務要求，這樣就不需要為反向 Proxy 憑證更新主體替代名稱清單，則您需要為連接埠 80 (HTTP) 建立新的 Web 發行規則。