RPC 用戶端存取跨站台連線變更
英文原文已於 2012 年 5 月 30 日星期三發佈
差不多兩年前，我在 TechEd North America 2010 舉辦了一場名叫高可用性設計重點 (可能為英文網頁) 的研討會。會中提到了一些我們正在研擬的變更，是有關 MAPI 連線在信箱移動和跨網站資料庫發生 *over 事件後應該如何進行的問題。可惜，由於必須引進的變更過於複雜，加上會趕不及在 Service Pack 1 推出前完成測試，因此我那篇報告過後不久，我們便決議刪掉這項功能了。雖然我很努力推動這項工作，可是到了 Service Pack 2，我們還是沒法完成這些變更。
很無奈地，並非所有的功能刪減都能像手術那樣切得一乾二淨，事實上有一小部分的程式碼變更，還殘留在 SP1 中。舉例來說，您可能有注意到 Set-DatabaseAvailabilityGroup Cmdlet 就有一個叫做 AllowCrossSiteRPCClientAccess 的屬性。如果您高興也可以把這個布林屬性開開關關，但它完全不會對產品有任何作用 (我懂…我們的心情，就像這張圖片這樣)：
跨站台 RPC 用戶端存取連線行為 (RTM、SP1、SP2 一直到 SP2-RU2)
先不說題外話了。首先，我們先談談幾個基本要點。
在 Exchange 2010 中，用戶端連線和存取信箱相關資料的方式有一項重大的改變。和舊版不同，現在用戶端要存取信箱資料時，不再直接連到信箱伺服器角色上的資訊儲存庫，而是先連到用戶端存取伺服器 (CAS) 角色上的一組服務，然後該 CAS 角色中的這些服務再使用信箱伺服器的 MAPI/RPC 代替連線的使用者存取信箱。您可以將它想像成一個抽象層。
基本上，它只是簡單做了一項小小的變更，讓所有信箱相關的 MAPI 連線都通過用戶端存取伺服器角色上的 RPC 用戶端存取服務。為促進此抽象層的效能，這些變更必須讓資料庫物件不再是信箱伺服器的子系物件。於是信箱資料庫中新增了一個屬性：RPCClientAccessServer，它的作用是定義出要用以存取特定資料庫的 legacyExchangeDN。此屬性會採用 FQDN 做為它的值。為確保能具有高度可用性和 CAS 失敗時的高度容錯能力，此值必須是某個已配置負載平衡的 CAS 陣列之 FQDN。這個已實現負載平衡的 FQDN，就是我們稱為「RPC 用戶端存取伺服器陣列」的東西。
如需詳細資訊，請參閱 Brian Day 的文章＜CAS 陣列物件大解謎＞第 1 部分和第 2 部分。
Outlook 典型使用經驗
在單一資料中心 (或單一 Active Directory 站台) 的情況下，所有版本的 Outlook 在行為模式上都是一致的。Outlook 設定檔的 RPC 端點就等於 RPC 用戶端存取伺服器陣列 (或者是某個特定的 CAS - 如果出自什麼緣故，您沒有建立陣列的話。話說回來，您應該要先行建立，如果您不知為什麼的話，我再說一遍，去唸 Brian 的文章吧)。每當 DAG 中發生失敗時 (資料庫失敗、伺服器失敗等)，由於 RPC 端點沒有變化，於是 Outlook 會繼續連線至同一個 RPC 用戶端存取伺服器陣列。而每當 CAS 陣列內發生失敗時 (CAS 失敗、負載平衡失敗等)，也因為 RPC 端點沒有變化，Outlook 會繼續嘗試連線至該 RPC 用戶端存取伺服器陣列。
在資料中心轉換的案例中，Outlook 所有版本的行為模式，只要您有照著我們的指南進行，也會是一致的。為什麼呢？因為在資料中心轉換期間，您會將主要資料中心 RPC 用戶端存取伺服器陣列 DNS 入口的 IP 位置，改為指向備用資料中心的 RPC 用戶端存取伺服器陣列。自動探索會持續將主要資料中心 RPC 用戶端存取伺服器陣列分派為 RPC 端點。現有的 Outlook 用戶端不需要任何重新設定，用戶端上的 DNS 快取一旦更新完成，用戶端即會直接連線至現在位於備用資料中心的端點。若想完全搞懂這方法可行的原因，您得先把握住這個觀念：無論是用戶端或 CAS，它們都不會真的去管 CAS 所在的那個站台，它們只是單純地接受現在可以連線而且用戶端目前連線的 CAS 有能力存取信箱這個事實。
跨站台資料庫的 *over 行為
為能充分理解此情況，請務必先清楚這一點：當您設定了多站台的 DAG 時，某特定資料庫的 RPCClientAccessServer 屬性一般來說都會與位於相同 AD 站台中的 RPC 用戶端存取伺服器陣列相關，而其為啟動喜好設定編號最小的信箱資料庫複本。舉例來說：
圖 1：橫跨兩個 Active Directory 站台的資料庫可用性群組
當資料庫複本在備用資料中心上啟用時，使用者會持續運用 AD 站台的 RPC 用戶端存取伺服器陣列，在該處啟動喜好設定編號啟動喜好設定編號值最小的信箱資料庫，就會被拿來當做其連線端點。
圖 2：已在備用 Active Directory 站台上啟動 MDB1 資料庫
如果查看來源 RPC 用戶端存取伺服器陣列上的 RPC 用戶端存取記錄檔，您會看見：
2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",
當 AD 站台中的 RPC 用戶端存取伺服器陣列 (啟動喜好設定編號值最小的信箱資料庫所在地) 變成使用者無法存取時，Outlook 用戶端將無法連線到其位於另一個資料中心內的信箱。換言之，就是發生了資料中心中斷的事件，而必須採取資料中心轉換的程序。
簡單來看，就是說無論資料庫的 RPCClientAccessServer 屬性值為何，Outlook 都一律會連線到已設定好的 RPC 端點 (假如可以連到的話)。
系統有可能自動變更 RPCClientAccessServer 的值嗎？
系統會變更資料庫上 RPCClientAccessServer 值唯一的情況，就是當管理員變更了已啟動之資料庫複本上的 ActivationPreference 編號，讓它變成數字最小的一個時 (代表它現在變成是偏好的複本)。如圖 3 所示：
圖 3：已在備用 Active Directory 站台上啟動 MDB1 資料庫，且 RPCClientAccessServer 屬性已變更時
但是，擁有現存 Outlook 設定檔的 Outlook 用戶端還是會持續使用舊的 RPC 端點，而不是使用新的 RPC 端點 (即便自動探索有偵測到變更)。這是由於舊的 RPC 端點並未將 ecWrongServer 回應傳回給用戶端。RPC 端點接受連線後，Outlook 便會忽略自動探索的回應，因為它認為已經有一個正常運作的連線了。當舊的 RPC 端點變成無法存取時，Outlook 2007/2010 才會更新其設定 (另一方面，Outlook 2003 則不會這麼做，因為它沒有自動探索)。其他時候若想強迫 Outlook 採用新的 RPC 端點，就得強制執行設定檔修復。
要是管理員在某次跨站台資料庫的 *over 事件後，手動更新了 RPCClientAccessServer 值，會發生什麼樣的情況？
回來看圖 2，假如在 MBX-C 上的信箱資料庫複本 (其 ActivationPreference 值大於 1) 啟動後，管理員手動更新了 MDB1 的 RPCClientAccessServer 值，將它指向 cas-sec.contoso.com 的話，只要舊的 RPC 端點仍然可用，擁有現存設定檔的 Outlook 用戶端就會持續使用舊的 RPC 端點，而非新的 RPC 端點 (修復設定檔可修正此問題)。RPCClientAccessServer 值變更之後才建立的 Outlook 設定檔，則會使用新的 RPC 端點。
在 Active Directory 站台間移動信箱
在 Exchange 2010 之前，當您要跨伺服器移動信箱時，Outlook RPC 端點會更新，變成指向託管信箱所在之資料庫的信箱伺服器 (或叢集化的信箱伺服器執行個體)。信箱移動完成後，Outlook 用戶端使用者會收到提示，出現 [Microsoft Exchange 管理員已進行了一項變更，您必須先結束再重新啟動 Outlook] 對話方塊。重新啟動 Outlook 之後，用戶端才會連線到新的 RPC 端點。
在 Exchange 2010 中，您也許曾經注意到，當您要在各個 AD 站台間移動信箱時，使用者並不會收到此對話方塊。此外，您也可能發現使用者也沒有更新他們的 RPC 端點，以反映出與信箱目前所在之 AD 站台內的信箱資料庫相關聯的 RPC 用戶端存取伺服器陣列。這是由於舊的 RPC 端點並未將 ecWrongServer 回應傳回給用戶端。RPC 端點接受連線後，Outlook 便會忽略了自動探索的回報，因為它認為已經有一個正常運作的連線了。當舊的 RPC 端點變成無法存取時，Outlook 才會更新其設定 (另一方面，Outlook 2003 則不會這麼做，因為它沒有自動探索)。其他時候若想強迫 Outlook 採用新的 RPC 端點，就得強制執行設定檔修復。
現在您該懂我上面那張可愛貓貓圖的意思了吧？
SP2 RU3…以及更遙遠的未來
我從未放棄解決這些問題的希望。我們有些人已心力交瘁，但 RPC 用戶端存取開發小組、Exchange 服務小組以及我本人，願不厭其煩地盡一切努力，直到這兩項必要的變更確實植入產品為止。首先要修好當信箱單純在不同 AD 站台的資料庫之間移動時的 Outlook 設定檔問題；其次是當跨站台資料庫的 *over 導致 Outlook 採用並非目前已啟動之資料庫所在處最理想的 CAS 選擇。
信箱移動
依預設，一旦您安裝了 SP2 RU3 後若要在 AD 站台間移動信箱時，所有版本的 Outlook 都會收到重新啟動的提示，並且會更新 Outlook 設定檔的 RPC 端點。
如果查看來源 RPC 用戶端存取陣列上的 RPC 用戶端存取記錄檔，您會看見：
2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:
請注意，其中的 RPC 作業 (ROP) 是 WrongServer (也稱為 ecWrongServer)。這會強迫 Outlook 用戶端執行一次設定檔探索，並依目錄中找到的新資訊更新設定檔。更新設定檔並待用戶端重新啟動之後，用戶端就會建立與新 RPC 端點的連線了。
您可能會問到，還有什麼其他情況會出現 [Microsoft Exchange 管理員已進行了一項變更，您必須先結束再重新啟動 Outlook] 的對話方塊？
- 當您在 New-MoveRequest 上指定了 DoNotPreserveMailboxSignature 屬性時。
- 當來源和目標信箱資料庫的公用資料夾存放區階層不同時。
- 當您從舊版 Exchange 將信箱移動到 Exchange 2010 時。
跨站台資料庫 *over 事件
跨站台資料庫 *over 事件的行為取決於 DAG 屬性 AllowCrossSiteRPCClientAccess 的值。若您將 AllowCrossSiteRPCClientAccess 屬性值設為 $true，那麼我在上一段中描述的行為就會是預設行為。於備用資料中心上啟用資料庫時，使用者會持續運用 AD 站台中的 RPC 用戶端存取伺服器陣列，在該處啟動喜好設定編號值最小的信箱資料庫，會拿來當做其連線端點。
若 AllowCrossSiteRPCClientAccess 屬性值設為 $false (該屬性的預設值為 $false)，則 Outlook 設定檔的 RPC 端點將會更新成和資料庫啟動及裝載處相同之 AD 站台內的 RPC 用戶端存取伺服器陣列。請注意，RPCClientAccessServer 屬性並不會更新，因為偏好的站台是由它來定義。
圖 4：已在備用 Active Directory 站台上啟動 MDB1 資料庫，且 Outlook 設定檔已自動更新時
如果查看來源 RPC 用戶端存取伺服器陣列上的 RPC 用戶端存取記錄檔，您會看見：
2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:
就像移動信箱的案例一樣，WrongServer ROP 會強迫 Outlook 用戶端執行一次設定檔探索，並依目錄中所找到的新資訊更新設定檔。更新設定檔並待用戶端重新啟動之後，用戶端就會建立與新 RPC 端點的連線了。
結論
瞭了吧！只要有了 SP2 RU3 (或更新版本)，您就可以確保當信箱在 AD 站台間移動時，它們的設定檔也會正確更新。此外，在跨站台 *-over 的情況下，您也可以自訂是否要允許跨站台的 RPC 連線，或是強制 Outlook 用戶端採用和已啟動且裝載的資料庫相同之 AD 站台上的 RPC 用戶端存取伺服器陣列 (也就是預設的行為)。講到這裡，我們應該可以拿這張圖做個了結：
Ross Smith IV
首席專案經理
Exchange 客戶經驗部
這是翻譯後的部落格文章。英文原文請參閱 RPC Client Access Cross-Site Connectivity Changes