Understanding the Lync Server 2010 Planning Tool

The Microsoft Lync Server 2010 Planning Tool helps design Lync Server 2010 deployments. A new feature of the Lync Server Planning Tool gives you the ability to design a virtualized server environment as well as physical deployments. There has been some confusion on the output generated by the Planning Tool. This article discusses some issues with the tool and how to interpret the data generated. It also highlights other tools to help with your designs.

Understanding the Lync Server 2010 Planning Tool

DAG 的成員是否可以跨不同的AD Domain ( 相同的Forest )

查詢確認後您可以參考下列TechNet官方文件中的DAG Member需求

Planning for High Availability and Site Resilience


其中提到如下圖內容所述：

從上述內容可知 Exchange 2010 DAG 中的成員都必需要在同一個 Domain,所以您若要在不同網域中各建置一台 Exchange 2010 DAG Member 是不被支援的.
但您可以在不同 AD Domain 建置不同的 Exchange 2010 DAG 群組,例如:在 A 網域中建立DAG-A-Domain ,在 B 網域則另外建立一個 DAG-B-Domain 的 DAG 來提供 A 與 B 網域的高可用性.
或者,您可以將 A Domain 分割成兩個不同的 AD Site ,而其中一個 AD Site 建立在 B Domain 的 Location,如此便可以做到 A Domain DAG 的異地備援機制.

The Exchange Server 2010 Setup On Hyper-V Fails With 2147504141 Error

當在 Hyper-V 上執行安裝 Exchange 2010 ,在執行安裝過程中會失敗,並且產生下列的錯誤訊息,錯誤訊息如下 :

"An error occurred with error code ‘2147504141′ and message ‘The property cannot be found in the cache.’"

解決方法:
1. Open the Hyper-V Manager console.
2. Locate and Right-click the virtual machine on which you want to install Exchange Server 2010, and then click Settings.
3. Click the Management section in the Settings tab, and then click Integration Services.
4. Click to clear the Time synchronization check box, and then click OK.
5. Reinstall Exchange Server 2010 on the virtual machine.

或者參考此連結 : Error message when the Exchange Server 2010 setup on a Hyper-V virtual machine fails:“2147504141”

Can’t Install Exchange 2010 SP1 with Error

當在更新 Exchange 2010 SP1 時,會產生下列錯誤訊息,而造成無法繼續更新 SP1,錯誤訊息如下:

Some controls aren't valid. Setup previously failed while performing the action "Install". You can't resume setup by performaing the action "BuildToBuildUpgrade".


解決方法:
1. 開啟 regedit 並且找到下列機碼位置 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\
2. 在所要安裝的 Exchange 角色機碼裡,找到名稱為 Action 的機碼 (以此例為 MailboxRole)
3. 為了確保安全在執行任何修改的動作前,請確實備份
4. 找到 Action 機碼後刪除

刪除上述機碼後再重新執行 Exchange SP1 更新即可順利進行更新

Enable presence status “Appear Offline”

透過 PowerShell 在 Lync Server 上,執行下列指令來啟用 Lync Client "Appear Offline" 的狀態

Set-CsClientPolicy -EnableAppearOffline $true

Get-CsClientPolicy

Lync Database Creation Error

安裝佈署 Lync Server 的 Monitoring Server role 時,安裝過程中,且在建立新增資料庫時,會發生如下的錯誤訊息,

Running script: C:\Windows\system32\cscript.exe //Nologo "C:\Program Files\Common Files\Microsoft
Lync Server 2010\DbSetup\RtcCdrDbSetup.wsf" /sqlserver:sql.schertz.local\lync
/serveracct:SCHERTZ\RTCComponentUniversalServices /dbpath:C:\CsData\MonitoringStore\
lync\dbpath /logpath:C:\CsData\MonitoringStore\lync\logpath /logsize:1024 /verbose
—————
Installed SQL Server 2005 Backward Compatibility version is 8.05.2312
Connecting to SQL Server on sql.schertz.local\lync
SqlMajorVersion : 10
SqlMinorVersion : 0
SqlBuildNo : 2531
SQL version is acceptable: 10.0.2531.0
Opened database LcsCDR

Db version unknown. Clean install required.
(Major upgrade of database required.)

Due to schema changes this database cannot be re-used. It must be dropped and a new one created.
To preserve data, you must use this product’s backup/export restore/import solution. Examine the product documentation for instructions.
—————
Exit code: ERROR_NEED_MAJOR_UPGRADE_USE_IMP_EXP (-50)
—————

解決方法:
■ 執行 Topology Builder 並且從 Topology Builder 移除 Monitoring Server Role ,移除後關閉 Topology Builder 套用更改後的設定
■ 連線 SQL server 在 SQL Management Studio 上尋找並且移除 LcsCDR and QoEMetrics 特定的 DB
■ 重新執行 Topology Builder ,並且重新選擇安裝 Monitoring Server Role ,此時安裝過程順利進行,之前 SQL ‘Db server unknown’ 的錯誤訊息也不在發生

SQL Server Error During Lync Install

在安裝 Lync Server 的過程中,會發生如下的錯誤訊息,也就是 ERROR_VALIDATE_BAD_SQL_VERSION

Error: Script failed (code "ERROR_VALIDATE_BAD_SQL_VERSION") when installing "CentralMgmtStore" on "N-HCLT-LYNCSQL.hclt.corp.hcl.in". For details, see the following log file: "C:\Users\hcltocs\AppData\Local\Temp\Create-CentralMgmtStore-N-HCLT-LYNCSQL.hclt.corp.hcl.in-[2010_10_18][14_11_55].log"

Error: An error occurred: "Microsoft.Rtc.Common.Data.SqlConnectionException" "Cannot open database "xds" requested by the login. The login failed.
Login failed for user 'HCLTECH\hcltocs'."

而發生上述的問題,主要是Lync Server 後端的 SQL Server 有相對應的版本,也就是安裝時選擇的後端 SQL Server 版本目前不支援 Lync Server,而目前 Lync Server 支援的 SQL Server 版本如下,提供給各位參考.

*Standard or Enterprise Edition of SQL Server 2005 with Service Pack 3
*Standard or Enterprise Edition of SQL Server 2008 with Service Pack 1

Windows NLB 或 Hardware NLB Solution 的差異或建議為何 ?

首先您必需先瞭解 Network Load Balance 的 Affinity Type 的差異。

下列列出各種 NLB Affinity Type 的說明：
Existing Cookies ：
此種 affinity 的方法是使用Client/Server Session間所傳遞的Cookie資訊來進行 LOAD BALANCE 。

此種方法只適用於使用 HTTP 的通訊協定而不適用於任何 RPC 的通訊協定用戶端。

OWA 使用表單型驗證所以很適合使用此種 affinity 方法或使用 Application Cookies 的 Affinity 方法。

Load Balancer Cookies:
此種 Affinity 方法很類似於 Existing Cookies 。 Load Balancer Cookies是由負載平衡器來產生 Cookies 而非依賴由 Client/Server Session 間所傳遞的 Cookie 資訊來進行負載平衡。

此種方法與Existing Cookies相同僅適用於HTTP通訊協定的負載平衡，不過與Existing Cookies不同的是用戶端還必需支援 Load balancer-generated cookies。

Exchange ActiveSync，Outlook Anywhere，及部份的 Exchange Web Services 並不支援此種負載平衡方法。

OWA，Exchange Control Panel 及 Remote Windows PowerShell 則適合使用此種 Affinity 方法。

Source IP ：
Source IP 是目前最常見使用最廣泛的 Affinity 方法。

負載平衡器會記錄用戶端的來源 IP 以及目地伺服器端的 IP，所有來自相同 Source IP 的 Traffic 在指定時間內都會被導向至相同的目地端伺服器上。

使用此種方法會有兩種主要的缺點：
一 是若用戶端會經常變更 IP Address 則會導致 Affinity 中斷 ( 失敗 ) ，會造成用戶端可能必需被要求重新進行驗證。

如果您的環境中的用戶端會頻繁的變更 IP Address( 例如：手機用戶或行動裝置用戶在不同的無線 AP 區域移動 ) ，則不適用於此種 Affinity 方法。

二 是若您環境中的用戶端會共同使用相同的 Source IP( 例如都是透過 NAT 轉換進行存取 ) 則會造成平衡負載失敗。

因為所有的用戶端都使用相同的 Source IP 時會導致平衡負載器無法平均的分配用戶端流量到目的地端伺服器上，而會導致所有的用戶端流量都往同一個目的地伺服器造成負載不平衡。

SSL Session ID ：
當用戶端開始進行 SSL 加密程序時會產生 SSL Session ID 。

使用 SSL Session ID 有兩個好處：
一 是相較於 Source IP Address 的 Affinity 方法， SSL Session ID 可以辨別出使用相同 Source IP 的用戶端。

二 是使用 SSL Session ID 並不需要進行 SSL 流量的解密。

SSL Session ID 並無法適用於所有的用戶端存取。例如，微軟的 IE8 在處理每一個瀏灠器處理程序時會建立一個新的 SSL Session ，這將導致使用此 Affinity 方法的用戶端負載失敗。

接著您可以參考 Exchange Server 2010 用戶端存取的 Load Balance 的建議


有關於 Network Load-Balance foe Client Access Server 您可以參考下列兩篇 TechNet 的文章內容的描述：
Understanding Load Balancing in Exchange 2010
Load Balancing Requirements of Exchange Protocols

下表為您整理列出負載平衡器的比較：


從上表中可以得知，使用 Software 的 NLB 有下述缺點：
O 無法與 Windows Failover Cluster 一起使用 ，亦即若您的客戶是三合一角色並啟用 DAG 的 HA 機制時將無法使用 Windows NLB 。

O 不支援 Service Health Check 功能 。

由於 Software NLB 只會檢查網路層連線的可用性而無法檢查應用層服務的可用性所以如果在 NLB 中的 CAS Server 的 IIS Service Failed 時，負載平衡器還是會持續將用戶端流量往此 CAS Server 傳送這將會造成用戶端存取及負載平衡的失敗。

O 在我們的測試結果我們不建議您將超過八台 Exchange Server 的 CAS/HUB 架構在 Windows NLB 中，因為這會造成效能使用上的問題。

O 僅支援使用 Source IP 的 Affinity 方法。

結論 : 在一個要求高可用性及高可靠度的使用環境中，我們會建議您優先使用硬體式的 NLB 解決方案。

設定DC為Time Server

設定網域環境中一台DC為Time Server,首先先確定在DC上目前Time Server的指向.



如果Time Server未指向正確的Server,請參考下列指令來完成Time Server的指向設定.



完成上述Time Server的指向設定,接著再做最後一次確認,確認無誤後即可完成.



小叮嚀:
• 確認 W32Time 服務已設定自動啟動.
• 確認防火牆設定允許 UDP 123 封包穿透.