Implement New Voicemail Solutions with Exchange Unified Messaging

發行項
08/18/2016

溝通與共同作業

為移轉至整合訊息作規劃

Jeff Goodwin

綜覽：

語音信箱簡史
規劃移轉時的考慮事項
移轉策略
多站挑戰

要規畫抵達目的地的方式，必須先知道旅程的出發點，因此我想先快速介紹一下語音信箱系統 — 亦即它們的源起與架構。關於第一套語音信箱系統的發明者是誰，一直都是眾說紛紜。但是第一套上市的商用語音系統叫做 VMX (也就是 Voice Message Exchange 的縮寫)，倒是毫無疑問。

VMX 當初設計的目的是為了提供一種管道，與公司其他人透過語音彼此通訊，就跟現今使用的電子郵件一樣。這套系統具有類似傳送留言、轉寄留言和回覆留言等命令。當有留言時，就會通知使用者。通知的方法有好幾種，包括撥打電話 (以特定的電話號碼打給使用者) 和等候訊息燈 (使用者電話上的指示燈)。

隨著 VMX 越形普及，各公司也開始將它們的語音信箱系統網路化。這一點提供了全企業語音信箱解決方案，讓員工能夠將廣播訊息傳送到全公司的通訊清單。

不用說，要提供一種管道與語音信箱系統產生互動，必須建立按鍵式使用者介面 (TUI)。這幾年來 TUI 不斷變化，但是語音信箱卻沒有標準的介面。如果您的電話裝有語音信箱，也許很習慣聽到像「請按 1，進入語音信箱」這類的用語。但是隨著使用語音使用者介面 (VUI) 的語音導向語音信箱系統越來越普遍，TUI 本身的重要性也大不如前。不過，使用者對特定介面的戀棧也是不容低估的。

如今採用的企業語音信箱系統仰賴兩種不同的架構：分散式和集中式。在 [圖 1] 中，西雅圖、紐約和奧斯丁辦公室都是採用分散式語音信箱架構，其中語音信箱系統在這些站點上，都是共置在同一區。相反地，倫敦、巴黎和格拉斯哥辦公室則是採用集中式模型，其中 PBX 基礎結構已經網路化，而且所有的來電都是路由回倫敦的中央位置。兩種模型各有優缺點。但是請注意，即使是採用分散式模型，還是可以將語音信箱系統網路化，以便在各站點間傳遞留言。

[圖 1] 兩種常見的語音信箱架構模型 (按一下以放大影像)

公司可能選擇採用分散式模型的主要原因有三：因應當地所需、所用的異質 PBX 系統無法網路化，以及受到統一撥號計畫的限制。

有些公司要求採用語音信箱系統的原因，是希望本機 PBX 和語音信箱在發生網路故障的情況下仍能正常操作，以提供該站點完整的系統功能。另外，語音信箱系統仍然可以使用互動式語音回應 (IVR) 系統，而且外部來電者也仍然可以留言。這些動作對於使用者來說一點影響也沒有，工作也一如往常般進行。聽起來好像不陌生 — 因為許多公司選擇把執行 Microsoft® Exchange Server 的伺服器當地化，也是基於同樣的原因。也許貴公司會希望執行風險評估，來判定這種當地化存留能力是否有其必要。

當公司隨著併購而擴大時，遠端站點的 PBX 平台往往無法與基礎結構的其餘部分一起網路化。在這種情況下，公司可以選擇淘汰 PBX (這個做法的成本可能相當昂貴)，也可以選擇讓該站點原封不動，而將語音信箱平台網路化，讓語音訊息得以順利交換。另外還有協力廠商伺服器可以幫助您將異質的語音信箱系統網路化。

要將 PBX 網路化，必須採用統一撥號計畫 (或 UDP)。UDP 會告訴您，電話和語音信箱分機不能重疊。在 [圖 1] 中，您會注意到西雅圖、紐約和奧斯丁有重疊的分機範圍，這是因為美國境內的站點並沒有 UDP。您只要把分機範圍擴充到 7 或 10 位數，就可以建立 UDP，但這也會引起其他問題。

您可能必須改變每支電話的撥號範本、變更 PBX 上所有的使用者分機，以及變更任何與系統整合的應用程式。而員工要打電話給走道另一端的人，也得記住多達 7 或 10 位數號碼，這可能會使他們抓狂。

雖然這幾年來，這些基本功能和架構上的挑戰已經有所改進，但語音信箱的基本原理仍舊不變。交換留言、網路、通知方法、使用者介面和架構，都是在規劃移轉時必須謹記在心的重要因素。

規劃移轉

整合通訊會對公司整體產生巨大的變動 — 從使用者與語音信箱互動的方式，到設計架構的方式，到系統管理員處理管理工作的方式都是。當您移轉到整合通訊系統時，必須一一解決這些差異。接下來是在規劃移轉時必須列入考量的事項清單。

訊息網路功能任何從舊式語音信箱平台轉換至 Exchange 整合通訊的公司，都必須經過一段共存期。如果貴公司已經部署訊息網路功能 (一種使不同語音信箱系統交互操作的系統)，只要將整合通訊系統新增至現有系統的清單就行了。所以，只要是在多個據點擁有不同語音信箱或 PBX 系統的公司，我都建議它們使用訊息網路功能。

基礎結構在設計整合通訊的基礎結構時，必須對網路需求、電話語音整合、伺服器安置等作出決策。如果您對基本部署策略還不熟悉，請先閱讀我之前所寫的文章＜透過 Exchange Server 2007 部署整合通訊＞(請參閱 technet.microsoft.com/magazine/cc137737)。

自動語音應答許多系統都包含多重自動語音應答 — 例如，白天、晚上和不同部門各有不同的自動語音應答。您必須與貴公司的電訊小組，共同製作舊式語音信箱系統上的自動語音應答。

訊息等候指示也許您不希望借助訊息等候指示器，但是您的使用者可能會需要這項功能，所以不要低估使用者戀棧紅燈通知的程度。所幸已有幾家公司針對 Exchange Server 開發出訊息指示器應用程式。

傳真支援許多舊式語音信箱平台都支援輸入傳真。Exchange 整合通訊也支援輸入傳真功能，因此您可能會希望在新部署中支援這項功能。

互動式語音回應有些舊式語音信箱平台支援的互動式語音回應 (IVR) 應用程式 Exchange 整合通訊並無法複寫。在找到適合的替代方案之前，應讓這些系統保持現狀。

系統管理 Exchange 整合通訊必須仰賴 Active Directory® 和 Exchange Mailbox Server role。您必須規劃整合通訊部署會對系統管理、系統需求等產生什麼影響。

使用者介面當新 UI 推出時，您必須為使用者提供訓練。Exchange 整合通訊採用的介面，非常類似大多數的行動電話提供者，因此對於大部分使用者來說，這個介面應該很直覺化。它也使用語音辨識，因此使用者不必使用按鍵。在 Exchange Server 中，這稱為 Outlook® Voice Access。

教育訓練整合通訊徹底改變了使用者通訊和使用語音信箱的方式。除了 UI 以外，您還必須訓練使用者，教導他們最佳作法，並且展示更具效率的新方法，讓他們能夠通訊。例如，使用者可能不知道如何在電子郵件收件匣中與語音信箱互動，或是如何設定一些進階的整合通訊設定。

務實的移轉策略

無可否認，將大型組織移轉到整合通訊解決方案，是一項深具挑戰的任務。不過，根據我在整合通訊工作 10 年來的經驗，即使最複雜、具有最特定需求的組織，也能夠成功移轉。

無論您處理的是單站還是多站的公司，只要根據這五大基本步驟來建置移轉策略，就能獲益無窮。

規劃和設計您的解決方案。
安裝和設定 Unified Messaging Server role。
移轉試驗小組。
根據試驗小組的意見來修訂設計。
移轉使用者。

當然，多站公司所面臨的挑戰，的確是單站案例所沒有的。我會在「多站挑戰」資訊看板中分別討論這些挑戰。

規劃和設計解決方案是移轉程序當中最重要的一個步驟。我建議您針對這個專案，指派一個整合通訊小組。這個小組應該涵蓋公司各個不同部門的代表，各自具備電訊、Active Directory、Exchange、網路、安全性、教育訓練和專案管理方面的專才。另外還要取得貴公司現有 PBX、語音信箱和電子郵件基礎結構的詳細架構圖。

設計確定之後，即可安裝和設定 Unified Messaging Server role。不要害怕將 United Messaging Server 與現有舊式語音信箱系統並行安裝，只要確實遵守記錄的最佳作法就行了。

現在，您已準備好試用 Unified Messaging Server。請指定並移轉一小組試驗使用者到新系統，大概介於 25 到 50 名使用者即可。請慎重選擇這些使用者，建立一個囊括各種不同使用者群組的試驗小組，包括 IT 和電訊人員、部門經理和業務人員等等。有了各方人員的幫助，應該較能判斷設計是否正中目標、有什麼特定的需求應該列入考量，以使用者可能需要什麼樣的訓練等等。

當您收到試驗小組的意見反應之後，必須修訂設計來解決在測試當中發現的任何問題。更確切的說，請再次看看我在「考慮事項」一節所討論的項目，並確定您已為貴公司妥善解決這些要點。請注意，此處最常做的變更通常跟教育訓練有關。

最後一步是移轉使用者。關於如何將系統完整移轉到執行環境，有許多不同意見和策略。主要的兩個方法論分別是漸進式移轉和閃電切換 (flash-cut)。

如果您選擇以漸進方式，花幾個禮拜或幾個月的時間來移轉使用者社群，您會在舊式和整合通訊使用者之間建立語音信箱孤島，阻礙使用者透過語音信箱轉寄留言。而且如果您的設計沒有包含訊息網路解決方案的話，將會中斷一些業務通訊。如果真要這麼做，我建議您務必在最初的設計中，納入訊息網路解決方案。

閃電切換移轉是在單一階段移動所有的使用者。通常公司都選在週末執行這類移轉作業，因為這樣才有時間測試系統、進行設定變更，以及在遇到嚴重封鎖程式時取消移轉。

無論選用哪種方法，請確實訓練支援工程師應答您從試驗小組收集到的常見問題。同時您也應該確保支援工程師熟練執行重要的工作，包括啟用使用者、確認使用者已啟用，以及變更密碼。

逐步解說移轉

在觀看我逐步講解範例移轉程序的同時，請記住，成功移轉至整合通訊的主要目標，是在盡量不干擾使用者 (包括內外部) 的情況下，將使用者的語音信箱，從舊式語音信箱平台移至整合通訊。

[圖 2] 詳述了一家公司的架構，該公司並不打算變更這個混合式的 Exchange 架構。美國辦公室把主要資料中心設在西雅圖，奧斯丁所有的 IT 應用程式都是由西雅圖提供服務，而紐約辦公室則負責當地化的 Exchange 服務。由於 PBX 基礎結構不同的關係，位於美國的語音信箱都是分散式的。從技術上來說，PBX 基礎結構並不能網路化來提供集中式語音信箱。相較之下，歐洲辦公室在倫敦設有一個集中式資料中心，歐洲地區所有的 IT 和電訊應用程式，都是從那個中央資料中心提供服務。

[圖 2] 移轉前的範例架構 (按一下以放大影像)

整個語音信箱基礎結構都是以 Octel (現在稱為 Avaya) 平台為基礎。所有語音信箱系統都已使用 Octel Analog Networking (OAN) 加以網路化，這是專利網路通訊協定，使用類比電話線和長途電話來傳送網路化語音信箱訊息。這個架構允許在各站點間進行全公司的語音通訊。

多站挑戰

多站公司在部署整合通訊時，必須面臨許多挑戰。所幸，您可以從其他公司的經驗了解其中一些挑戰。我無法在本文一一討論每項挑戰，但是我可以說明我與不同公司合作時最常遇到的挑戰。

「我是採用集中式 Exchange Server 架構和混合式電話語音環境。」

要設計分散式環境很簡單，只要安置一部 Unified Messaging Server，然後把它與每個站點的本機 PBX 整合起來就成了。但如果您的環境是集中式甚或混合式的時候，該怎麼辦呢？您得先問問自己，您的站點是否需要具備本機整合通訊存留能力。如果具備本機整合通訊存留能力，即使據點遺失與集中式 Exchange 伺服器的連線，仍舊可以繼續提供自動語音應答功能，並允許外部來電者 (很有可能是客戶) 留言。所以答案很可能要看該據點有多重要，以及解決方案有多方便管理而定。

如果您的站點需要本機存留能力，不妨在該站點設立遠端 Unified Messaging Server。如果不一定需要本機存留能力，則可以在當地站點安裝 SIP 閘道。Exchange 整合通訊很有彈性，您不一定要將 PBX 基礎結構網路化，而且也不一定要採用統一撥號計畫。

「我正在進行 Exchange 架構升級。」

許多客戶在升級 Exchange 基礎結構時，都很猶豫是否要開始整合通訊移轉。我的建議是，如果您已經決定移往整合通訊，就在升級 Exchange 伺服器時放手移轉吧。只要遵循升級計畫，專案應該不至於會增加多少複雜度。

「我有許多少於 10 人的小站點，而且當中有些站點沒有 PBX。」

對於在站內有 PBX 的小型站點來說，只要在當地據點直接安裝 SIP 閘道就行了。如果站內沒有 PBX 的站點，可以採用電話語音技術，將電話轉接到中央 PBX，以便把來電路由到整合通訊系統。簡單的說，您可以用低廉的成本，將整合通訊服務部署到公司內的小型遠端站點。

要特別注意的是，這些小型站點其實可以作為移轉作業的絕佳測試台。一般常見的移轉策略，是從網路的邊緣開始移向核心。您可以先移轉較小的站點，然後再與整合通訊小組進行事後檢討，看看哪些方面順利，哪些方面不太順利。再把這些經驗運用到下一次的移轉。

整合通訊小組已經決定從網路邊緣往核心移轉。所有據點將遵循 Exchange 伺服器架構的最佳作法來安置 Unified Messaging Server。小組會針對每一個站點建置自己的計劃文件，謹記「考慮事項」一節所討論的項目。在安裝和設定伺服器、訓練使用者，以及規劃移轉策略時，都會用到這份文件。

小組打算在每一個站點，將使用者閃電切換到整合通訊系統，並保留舊式平台來支援 IVR 應用程式，而且在找到替代方案之前，都會使用這個應用程式。小組決定在移轉過後 30 天，再移往下一個據點。這段等候時間的目的，是要讓每一個站點適應新平台之後，再移動更多使用者，並且增加更多支援工程師支援電話。

公司決定先移轉奧斯丁據點。由於奧斯丁的電子郵件是由西雅圖提供服務，因此小組將 Unified Messaging Server role 安裝在西雅圖，然後在奧斯丁安裝 SIP 閘道，藉此提供 PBX 整合。由於舊式語音信箱平台已經網路化，因此小組必須安裝 Message Networking Server，以滿足整合通訊平台網路化的需求。就這樣，小組讓使用者接受新系統的訓練，而且移轉過程也非常順利，因此接下來決定移轉紐約。

紐約據點具有自己的 Mailbox 和 Hub Transport Server，因此最好的作法是在那裡安裝 Unified Messaging Server。小組於是遵循移轉計畫文件來安裝伺服器。他們把伺服器新增到 Message Networking Server 的節點清單中，以便涵蓋在語音信箱網路中。就這樣，小組讓使用者接受訓練，並且順利移轉到整合通訊。

西雅圖據點已經有一部從奧斯丁移轉階段部署的 Unified Messaging Server。小組判定該伺服器包含足夠的語音信箱連接埠，可以支援西雅圖和奧斯丁兩個據點。就這樣，小組讓西雅圖的使用者接受訓練，並且移轉到整合通訊。

相較之下，歐洲的架構設計就簡單許多。PBX 基礎結構已經網路化，並且採用集中式 Exchange。Unified Messaging Server 是部署在倫敦，而且每一個站點都要移轉，從規模最小的站點開始。[圖 3] 說明最終的架構。

[圖 3] 移轉後的範例架構 (按一下以放大影像)

遵循計畫的重要性

我常被要求解決許多失敗的整合通訊移轉，這些要求我解決的公司當中，有許多並沒有遵守其中一或多項重要規則。

首先，一定要記得它不只是語音信箱系統，而是關鍵性的應用程式，而且也應該被視為關鍵性的應用程式。使用者是仰賴語音信箱技術來交換資訊，所以要記住這是商務應用程式，而且在規劃移轉時，務必將我在本文所討論的所有考慮事項全部列入考量。

您必須邀請電訊小組參與整合通訊的移轉程序，因為電訊小組最了解整合至企業基礎結構的電話語音應用程式。

移轉至整合通訊時，請規劃企業解決方案。雖然剛開始可能只會實作一個站點，但還是要以大局為重。比方說，實作單一站點而沒有提供訊息網路功能給其他站點的話，會影響使用者之間的通訊。當然了，這是一項龐大的工作，因此一定要請教專家，設計一套將所有 IT 應用程式都列入考量的架構。

最後，別低估了教育訓練的重要性。整合通訊會徹底改變使用者通訊以及與語音信箱互動的方式。對您來說很簡單的事，對別人來說並不見得如此。如果要盡可能讓轉換順暢，一定要接受良好的教育訓練。

Jeff Goodwin 是 VIA 小組的資深技術人員，精通 Exchange 與整合通訊設計和部署。您可以透過電子郵件與他連絡：jgoodwin@theviagroup.com。

目錄

其他資源