7 月 2008 7 月 2008
IIS: 實地操作 IIS 7.0
Internet Information Services 7.0 的發行不僅立下新標準，提供意義重大的改進，所帶來的新功能更整合了 Web 環境。一同來探索最重要的增進功能，並獲得測試、分段處理，以及將 Web 應用程式移轉至 IIS 7.0 的深度指南。 Fergus Strachan
溝通與共同作業: 為移轉至整合訊息作規劃
只要備有具體完善的計畫，就能夠在不干擾使用者的情況下，輕鬆地從舊式語音信箱系統移往整合通訊平台。下面正是您在公司內部規劃移轉、測試新系統和實作整合通訊時，必須瞭解的一切細節。 Jeff Goodwin
溝通與共同作業: 語音如何發揮 OCS 2007 的功力
Microsoft Office Communication Server 為企業語音電話帶來了重大的變更。一同來逐層分析語音電話的撥打方式、了解來電路由到不同端點的方式，以及探索交談在 OCS 通訊中的重要性。 Rajesh Ramanathan
溝通與共同作業: 透過 Groove 和 SharePoint 建立強大的連線
Microsoft Office Groove 與 SharePoint Server 兩者都提供強大的共同作業功能。一同來比較兩者之間的差異，以及彼此互補的方式，並且找出整合 Groove 與 SharePoint 的方式，以提供一套簡單且靈活的共同作業解決方案，來支援不同地點的使用者。 Alan Maddison
Windows 系統管理: Windows Server 2008 Enterprise 容錯移轉叢集簡介
多年來使用者不斷抱怨 Windows Server 中的叢集太過複雜。隨著 Windows Server 2008 的發行，叢集也跟著改頭換面。一同來探索全新容錯移轉叢集中一些最重大的改進，並了解這項全新的實作如何使得叢集更容易設定和維護。 Chuck Timon
Columns
編輯的話: 告別印刷: | 讀者來信: 讀者有話直說: | 工具箱: 適合 IT 專家的新產品:
Exchange 佇列問題與解答: 負載平衡、Edge Transport 和其他: 您有 Exchange 方面的問題？在本期文章中，我們回答了有關使用 Exchange 與 SharePoint、處理待命連續複寫、在 Windows Server 2008 上安裝 Exchange 2007 信箱伺服器以及其他問題。Henrik Walther | 公用程式焦點: Microsoft SharedView: 設法與其他城市的人員儘速開始共同作業嗎？不妨參考一下免費的公用程式 Microsoft SharedView，它可讓您克服地理限制，輕鬆地與小型群組成員共用文件和畫面。Greg Steen | Sharepoint 內幕: 整合 Office 應用程式: 一同來了解 Microsoft Office 應用程式如何與 SharePoint 整合和通訊，並探索以相同的原則將非 Microsoft 應用程式與 SharePoint 整合的方法。Pav Cherny
Windows PowerShell: 投遞箱: Don Jones 將在本文探討篩選函數、管線、自訂物件，並且告訴您乒乓球還私藏了了解 Windows PowerShell 的秘密。Don Jones | 嗨，Scripting Guy！: 快感: 本文 Scripting Guy 將討論充滿刺激的指令碼，並且告訴您如何使用指令碼來存取 Windows Vista 和 Windows Server 2008 中的新開機設定資料儲存區。Microsoft Scripting Guys | 桌面檔案: 從網路啟動 Windows: 一同來探索遠端安裝服務 (RIS) 及其他 Microsoft 所用的 PXE 相關技術的歷史。Wes Miller
安全性監控: 密碼與信用卡 - 第一篇: 一系列三篇連載文章中的第一篇，探討安全性相關建議與常見作法往往已經過時，而且實際上會妨礙安全性工作。Jesper M. Johansson | 現場筆記: 確保選舉精確度: 一同來探討目前美國選舉系統的弱點，看看如何利用密碼編譯，建立完全驗證的選舉結果。Josh Benaloh | Windows 機密文件: 空間佔用回顧: Microsoft Bob 比您所想的還要普及。Raymond Chen 講述 Microsoft Bob 如何進入數百萬的家庭中。Raymond Chen


IIS
實地操作 IIS 7.0
Fergus Strachan
綜覽：
  • 在 Web 伺服陣列環境內部署 IIS 7.0
  • 安全性和效能提升
  • 將 ASP.NET Web 應用程式從 IIS 6.0 移轉至 IIS 7.0
  • 將 PHP Web 應用程式移轉至 IIS 7.0

目錄
預備，起，測試
我的測試設定
對 IT 系統管理員的重要改進
IIS 架構
整合和傳統模式
模組與功能
Web 應用程式移轉
總結
Microsoft 的 IIS 小組說 Internet Information Services (IIS) 7.0 是 IIS 有史以來最重大的發行。這個版本不僅立下新標準，提供意義重大的改進，
所帶來的新功能更整合了 Web 環境。內含在 Windows Server® 2008 和 Windows Vista® SP1 中的 IIS 7.0，讓 Microsoft.com 發揮強大威力，而且好幾家虛擬主機公司也已開始提供 IIS 7.0 主機給想要將現有的 Web 應用程式移植到新網頁伺服器平台的網頁設計者和開發人員。
在本文中，我將探索對 IT 專業人員來說最重大的 IIS 7.0 增強功能，接著我會深入探討移轉 ASP.NET 和 PHP Web 應用程式。不過首先，我想要簡述一下構成基本生產環境的測試實驗室。
這項工作很重要，在將 IIS 7.0 部署到實際執行伺服器之前，您必須花時間在實驗室的環境內進行充分測試，以確保您的 Web 應用程式能夠在新網頁伺服器上正常執行。

預備，起，測試
我的測試實驗室包括了執行 Windows Server 2003 和 IIS 6.0 的系統，上面主控著 ASP.NET 應用程式，另外也包括了執行 Ubuntu 7.10 Linux 發佈和 Apache HTTP Server 2.2 的伺服器，上面則主控以 PHP 為主的 Web 應用程式。我最終的目標是要將 Windows Server 2008 部署在開發用和生產系統上，然後轉移複雜的 Web 應用程式，將 IIS 6.0 和 Apache 執行個體取代為 IIS 7.0。
我有兩個重要的 Web 應用程式：DotNetNuke 4.7 和 osCommerce 3.0a4。DotNetNuke 是以 ASP.NET 2.0 和 Microsoft® SQL Server® 為基礎的 Web 應用程式架構。另外一個應用程式 osCommerce 是以 PHP 和 MySQL 為基礎建置而成，它是全功能電子商務解決方案的最新 Alpha 版本。現在就讓我們把這些進階應用程式放到 IIS 7.0 上吧！
我想要先釐清我的用意並不是要比較軟體版本、產品或平台。不過，我想指明 Windows Server 2008 和 IIS 7.0 的標準化確實有不少優點。換句話說，這麼做不但可降低系統管理的複雜度，而且還可以將執行網頁伺服器的總數減至最少。
[圖 1] 提供我用於本文的測試實驗室概觀。如果您想要在自己的測試環境內遵循我講解的步驟，可以到 TechNet Magazine 網站的「程式碼下載」區段，從附隨的資料中找到必要的軟體元件，以及詳盡的逐步安裝指示。
[圖 1] 首展 IIS 7.0 的測試環境 (按一下以放大影像)
請注意，大約在我快寫完本文的同時，Microsoft 也發行了一項命令列工具 (MSDeploy.exe) 支援客戶部署、同步處理和移轉 Web 應用程式至 IIS 6.0 和 7.0。我建議您試試這項工具。詳細資料可在 Microsoft Web 程式開發小組部落格上找到，網址是 go.microsoft.com/fwlink/?LinkId=118272。

我的測試設定
在撰寫本文的同時，Windows Server 2008 仍舊處於搶鮮版階段，因此我並沒有置換網域控制站或資料庫伺服器上的 Windows Server 2003。隨著 Windows Server 2008 的正式發行，您應該考慮一併移轉 Active Directory® 基礎結構。而將 SQL Server® 2005 和 MySQL 資料庫移轉到 SQL Server 2008 同樣超出了本文討論的範圍。
我主要是把 SQL Server 2008 部署在開發用伺服器上，因為跟安裝 SQL Server 2005 含 Service Pack 2 比起來，這比較不費力。DotNetNuke 可搭配 SQL Server 2008 資料庫順利執行。在 Windows Server 2008 上安裝 MySQL 5.0 也很直接了當，沒什麼複雜性可言。
雖然 Server Core 上可用 IIS 7.0，但基於測試的特定需求，我並沒有使用 Server Core 安裝。因為我的開發用伺服器是主要的測試系統，因此需要完整安裝。再說，Server Core 上也不能使用 Microsoft .NET Framework。
PHP 在 Server Core 上可順利執行，但是我的目標是要整合 ASP.NET 和 PHP 應用程式，因此我完全不考慮 Server Core。除非 Server Core 支援 .NET Framework，否則您必須得執行完整安裝才能支援 ASP.NET 應用程式。如需安裝測試環境的詳細逐步指南，請參閱附隨資料中的 01_install_testlab.htm 檔案。
我選擇執行 Windows Server 2008 的全新安裝 (而不是升級現有伺服器)。另外，透過全新安裝，實作開發用移轉案例也比較容易，像 [圖 2] 就是這樣的一個案例。基本的策略是要讓現有的 Web 伺服陣列繼續執行，直到所有相關 Web 應用程式元件在開發用伺服器上都成功通過測試且順利移到新 IIS 7.0 Web 伺服陣列為止。
[圖 2] 分階段切換到 IIS 7.0 (按一下以放大影像)
您可以根據環境的複雜程度，全部一次或採漸進方式移動所有現有的 Web 應用程式。對於每個 Web 應用程式或網站，在新 Web 伺服陣列上執行最後的接受度測試後，您就可以變更相關的 DNS 記錄，將瀏覽器導向新 IIS 7.0 Web 伺服陣列來進行切換。這可盡量減少停機時間和服務中斷。

對 IT 系統管理員的重大改進
《MSDN® Magazine》中有一篇 Mike Volodarsky 所著的精闢文章，名為＜深入探索 Windows Vista 的 Web 伺服器＞(網址是 msdn2.microsoft.com/magazine/cc163453.aspx)，可讓您快速了解 IIS 7.0 中所提供的各種改進。
另外一項不錯的參考來源是 Microsoft.com 小組的部落格文章，標題為＜狗食裡面美味的一小口＞ (網址是 go.microsoft.com/fwlink/?LinkId=117436)。這篇文章概述了小組成員的 IIS 7.0 的初體驗。簡單的說，他們把最重要的改進排名如下：
  1. 簡化的安裝。
  2. 極佳的相容性。
  3. 擺脫 Metabase。
  4. 透過在 UNC 共用上放置 applicationHost.config 檔案進行集中化設定。
  5. 透過應用程式目錄中的 web.config 檔案進行委派設定。
  6. 改進的管理工具。
  7. 失敗要求追蹤。
  8. 無需 URLScan 即可篩選要求。
  9. 透過 UNC 共用簡化內容同步處理可用性。
  10. 動態內容的輸出快取。
簡化的安裝肯定也在我的名單上。在 Microsoft.com 小組的部落格文章裡面，他們會示範如何以單行的命令列部署 IIS 7.0 的所有功能 (或者，只部署您要的功能)。我很興奮地以 [圖 3] 所示的命令列，將這套方法也併入我的測試實驗室設定指示。
不可否認地，這行命令的確很長 (如果您想要複製這行命令，我建議您從 TechNet Magazine 網站複製然後貼上，而不要手動輸入)。雖然這個命令把所有可用的模組都放到 IIS 7.0 電腦上，卻不包括 PHP。IIS 7.0 並沒有包含 PHP，而 Windows® 封裝管理員 (pkgmgr.exe) 其實對於透過網際網路下載和安裝 Debian 套件的概念很陌生。所以請輸入 Windows 自動化安裝套件 (AIK)。
[圖 3] 以單行命令列部署 IIS 7.0 功能
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
透過 AIK，您可以建立一張內含 IIS 7.0 和 PHP 5 的 Windows Server 2008 自訂安裝 DVD。您還可以包括 MySQL、Web 應用程式檔案，還有部署所需的其他任何元件。所有元件都可以作為 Windows Server 2008 安裝程式的一部分，讓您在所有網頁伺服器上套用一致的自訂內容，完全不用命令列或編輯設定檔。
您甚至可以建立自訂 DVD 進行完全自動化安裝。AIK 包括了建立 AutoUnattend.xml 檔案的說明文件和工具，您可以把它們放到 DVD 的根資料夾中。附隨資料中的 Custom Image Deployment.htm 檔案有提供相關逐步指示。
許多系統管理員也同意相容性是一項重大的改進。其實我預期 DotNetNuke 和 osCommerce 會碰到一些相容性問題，但轉移至 IIS 7.0 卻是相當輕鬆，儘管這兩種 Web 應用程式都包含進階功能，例如表單驗證和搜尋引擎式 URL。
對於 DotNetNuke，我是一直等到在 64 位元平台上透過 UNC 內容共用移到複雜的 Web 伺服陣列案例後才開始遇到問題。不過，問題不大。終歸一句，改進的相容性表示要讓 Web 應用程式在 IIS 7.0 上執行，所需的時間更短。
如果您的 Web 應用程式剛好遇到相容性問題，內建的診斷和追蹤支援很快會成為您愛不釋手的新功能之一。詳細的診斷資訊深具意義，而建議的解決方案路徑也非常有用，而且頗具成效。
[圖 4] 顯示您以整合模式在 IIS 7.0 上執行 DotNetNuke 4.7 時取得的診斷資訊。在本例中有三個選項 (顯示在「您可以試的事」一節)。對 DotNetNuke 開發人員來說，最佳選擇可能是變更應用程式來支援整合模式。而忽略錯誤可能不是什麼好主意。我喜歡第三個選擇，將 Web 應用程式切換到傳統 .NET AppPool 來啟用傳統模式，因為我想在 IIS 7.0 中執行未修改的 DotNetNuke 4.7。
[圖 4] 執行在整合模式中的 DotNetNuke 的診斷資訊 (按一下以放大影像)

IIS 架構
您可能會好奇這些整合和傳統模式到底是什麼，還有它們為什麼會左右 ASP.NET 應用程式 (DotNetNuke)，卻對 PHP 應用程式 (osCommerce) 一點影響也沒有。為了更清楚瞭解這一點，您必須先看看 IIS 7.0 的架構。之前的版本把 ASP.NET 執行階段整合至核心網頁伺服器，主要是透過 ISAPI 擴充程式 (aspnet_isapi.dll)。而另一方面，IIS 7.0 則容許 ASP.NET 模組直接透過一個稱為 ManageEngine 的全域層級 HTTP 模組插入核心網頁伺服器，這個模組會將 ASP.NET 支援 DLL (webengine.dll) 載入 IIS 7.0 要求處理管線內。
原生模組使用 IIS 網頁伺服器核心 API 來註冊管線內特定的事件，例如 BeginRequest、AuthenticateRequest、AuthorizeRequest 和 ExecuteRequestHandler。ManagedEngine 也提供將 ASP.NET 模組整合至要求管線所需的支援。藉著這個新架構，IIS 7.0 可以在要求處理期間的任何階段叫用原生和 ASP.NET 模組，而不管要求的內容類型為何。
讓我們舉 ASP.NET 使用者驗證為例。在 IIS 6.0 中，以 ASP.NET 為主的 HTTP 模組可以註冊 OnAuthenticate 事件 (例如 FormsAuthentication.OnAuthenticate 和 WindowsAuthentication.OnAuthenticate)，在目前 HttpContext 中設定使用者的識別。這在 ASP.NET 執行階段中頗具成效，但是您無法使用這段 ASP.NET 程式碼來保護透過以 PHP 為主的 Web 應用程式公開的資源。
根據 IIS 6.0 的指令碼對應設定，它會將 ASP.NET 內容類型的要求轉寄到 aspnet_isapi.dll，但是它並不會將 PHP 內容類型的要求轉寄到 ASP.NET 的 ISAPI 擴充程式。畢竟，ASP.NET 並不會處理 PHP 程式碼，但是這也表示如果要求 PHP 頁面的話，ASP.NET 驗證程式碼也不會執行。因此，對於 IIS 6.0，您必須複製驗證邏輯，因為 PHP 應用程式必須實作它們自己的驗證機制。
IIS 7.0 採用一種事件導向的處理模型，這種模型支援在要求管線中混用個別的模組。除了其他元件之外，IIS 7.0 還附隨了 Managed WindowsAuthentication 和 FormsAuthentication 模組，這些模組在要求管線引發 AuthenticateRequest 事件時會發出 OnAuthenticate 事件。您現在可以讓原生模組，例如 RequestFilteringModule 或 IpRestrictionModule，來處理 BeginRequest 事件，藉此儘早拒絕重要的要求，然後在發生 AuthenticateRequest 事件時執行自訂 ASP.NET 驗證程式碼，並在發生 ExecuteRequestHandler 事件時讓 FastCgiModule 執行 PHP 指令碼引擎 (php-cgi.exe) 來處理 PHP 頁面。
有了這樣的整合架構，網頁開發人員就不必再複製程式碼來實作一般的商務邏輯。您可以使用自訂 ASP.NET 驗證程式碼來保護所有的 IIS 資源，包括 PHP 應用程式在內。而且您可以透過 ASP.NET 模組執行其他前置和後置處理工作，諸如重寫 URL、自訂追蹤和記錄錯誤等。

整合和傳統模式
這套新架構所引起的副作用是，現有的 ASP.NET 應用程式可能需要變更程式碼和設定，這應該由應用程式開發人員執行，以確保這些變更不會導致模組在要求管線內產生衝突。但是如果您無法馬上移植現有的 Web 應用程式，您可以在工作者處理序用來執行 Web 應用程式的應用程式集區內啟用傳統模式。IIS 7.0 並不會將 ManagedEngine 載入傳統模式的工作者處理序中，這也暗示了在這種情況下，要求管理無法解析或叫用 ASP.NET 模組。IIS 7.0 反而會啟動幾個以 IsapiModule (aspnet_isapi.dll) 為基礎的 ISAPI 處理常式，來處理類似於 IIS 6.0 的 ASP.NET 內容類型。若您在 applicationHost.config 檔案 (預設可以在 %WinDir%\System32\InetSrv\Config 資料夾中找到) 中分析一下 system.webServer 中的處理常式區段，就不難看出這點。
以 string aspx 為例進行搜尋，就會發現有個指向 PageHandlerFactory-Integrated (根據 preCondition="integratedMode" 設定載入整合模式的應用程式集區工作者處理序) 的項目，以及其他指向 PageHandlerFactory-ISAPI-2.0 和 PageHandlerFactory-ISAPI-2.0-64 (根據 preCondition="classicMode" 設定載入傳統模式的應用程式集區工作者處理序) 的項目。
因為管線模式是在應用程式集區層級設定的，所以 IIS 7.0 可同時在整合和傳統模式內執行 Web 應用程式。而且工作者處理序其實只需在不同的應用程式集區中執行，它們還是可以裝載在同部伺服器上。
請記住，整合模式和傳統模式只會左右 IIS 7.0 將 ASP.NET 整合至要求管線的方式。這些管線模式並不會直接影響 PHP 應用程式。FastCgiModule 和所有其他原生模組在整合模式和傳統模式中，不需具備管線模式的先決條件，就可以載入。FastCGI 是在 IIS 7.0 上執行 PHP 指令碼引擎所偏用的介面。若不想使用 FastCGI，您也可以透過 CGL 建立 PHP 指令碼引擎的處理常式對應，或者您可以使用 IsapiModule 搭配 PHP-ISAPI (php4isapi.dll)。
不過，我個人認為現在 FastCGI 既然提供大幅改進的效能和穩定性，這些 IIS 6.0 式的設定替代方案其實很過時。CGI 的速度較緩慢的原因是因為 IIS 必須為每項 HTTP 要求初始化一個新的 CGI 處理序，而 FastCGI 則是重複使用 CGI 處理序來處理多項要求。ISAPI 需要有執行緒安全的 PHP 組建，表示負荷會比只執行非執行緒安裝的 PHP 還要高。
或許更為重要的是，並非所有 PHP 延伸模組在執行緒安全版本都可用，而且搭配 ISAPI 執行非執行緒安全延伸模組並不是個好主意，因為它可能會在伺服器上導致穩定性問題。另一方面，FastCGI 則是像 CGI 一樣的單一並行環境。用來執行非執行緒安全 PHP 的 FastCGI 是既穩定又快速，而且很顯然是在 IIS 7.0 上與 PHP 5 搭配使用的上上策。如果您還沒準備好轉移至 IIS 7.0 的話，它也可以在 IIS 6.0 上使用。

模組與功能
IIS 7.0 功能是高度模組化的架構 — 或者，套句 IIS 開發人員的用語，是元件化的功能集。這對於想要盡可能縮減記憶體使用量和 IIS 7.0 攻擊面的 Web 管理員，真是一大福音。透過啟用不同的模組，甚或是以自訂模組取代標準模組，您便能在網頁伺服器上全權掌控 IIS 7.0 功能。
若要在整合或傳統模式中執行 ASP.NET，以及在相同的伺服器上執行 PHP 應用程式，您必須至少安裝網頁伺服器角色和核心模組，藉以支援要求處理、伺服器設定、ASP.NET、ISAPI 和 CGI (內含在 FastCGI 模組中)。這可透過下列命令列來完成：
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
我一般偏好在開發用伺服器上以所有可用的選項安裝 IIS 7.0，以確保所有元件和系統管理工具都可以使用，藉此讓我的 Web 應用程式能迅速地順利執行。我的策略是確定事情一切 OK 後，藉著解除安裝角色服務和停用模組來縮小設定的範圍。當 Web 應用程式開始行為不軌時，我就把剛剛移除的角色服務或模組新增回去。
您也可以選擇使用封裝管理員 (pkgmgr.exe) 或是 IIS 7.0 命令列工具 (appcmd.exe)，或者直接編輯 applicationHost.config 檔案中的 globalModules 區段，但是我發現圖形化工具其實非常方便。請記住，有些模組 (像是 RequestFilteringModule 和 StaticCompressionModule) 即使不是執行 Web 應用程式必備的項目 (嚴格說起來)，它們還是相當管用。如果您解除安裝某應用程式集區所需的模組，您會在存取 Web 應用程式時收到 HTTP 錯誤，如 [圖 5] 所示。
[圖 5] ASP.NET 應用程式因為遺漏 IsapiModule 而不能在傳統模式中執行 (按一下以放大影像)
備註：最佳的作法是，確定所有 IIS 7.0 伺服器上安裝和啟用的是同一組模組。若要確認已安裝的元件，請前往 HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\，然後檢查登錄機碼。若 NetFxEnvironment 或 CGI 的登錄機碼的 REG_DWORD 值為 0000 0001，表示相對應的元件已安裝。

Web 應用程式移轉
理論講得天花亂墜，該是捲起袖子動手把一些 Web 應用程式移到 IIS 7.0 的時候了。前面有提到，我的開發用伺服器會執行 IIS 7.0 與所有可用的元件，還有以 FastCGI 註冊的非執行緒安全 PHP 5。開始前，我需要先問幾個基本問題：
  • Web 應用程式需要有資料庫管理系統，例如 SQL Server 或 MySQL 嗎？
  • 我需要安裝或設定其他元件，例如 ODBC 連線、COM 物件或 SSL 憑證嗎？
  • Web 應用程式需要有特殊的服務帳戶，以及對檔案共用和其他資源須提升本機或遠端存取權限嗎？
  • 對於 IIS 7.0 上沒有提供的平台特定功能有任何依存性，例如需要依存 Apache 模組來重寫 URL (mod_rewrite) 嗎？
問這些問題可幫助您讓 Web 應用程式更快在 IIS 7.0 上順利執行。舉例來說，如果您試著從使用 mod_rewrite 的 Apache 2.2 移轉 PHP 應用程式 (假設是為了方便使用搜尋引擎，或避免頻寬透過內嵌連結影像被劫奪)，除非在 IIS 7.0 上實作相容的自訂 URL 重寫解決方案，否則將會問題連連。所幸，osCommerce 在 IIS 7.0 上並不需要 mod_rewrite 功能，但是有些搜尋引擎最佳化套件可能需要這項功能。
既然在開發用伺服器上已決定並安裝了必要的附加元件，我也準備好讓 Web 應用程式正常執行。同樣地，我還有幾個想要自問的問題：
  • 我有什麼最簡單的設定可用來支援 Web 應用程式？
  • 目前生產環境內採用的是什麼設定？
  • 我可以最佳化新平台上的 Web 應用程式設定嗎？
  • 要 Web 應用程式在預期的設定內正常運作至少要有哪些角色服務和模組？
要確定 Web 應用程式能正常運作，最快的方法就是以最簡單的設定進行。如果一切看起來都很順利，就可以開始套用類似現有生產環境的設定，並將生產資料匯入到測試資料庫中。不用說，有些問題可能只會在進階設定下浮現。
您可能也會注意到在測試實驗室中鏡像生產設定時，有機會可以做些改進。把 applicationHost.config 檔案放在 UNC 共用上，是集中設定多部網頁伺服器的好作法。若要透過備援和內容同步處理來提高容錯，可考慮實作分散式檔案系統 (DFS) 複寫，這是 Windows Server 2003 R2 和 Windows Server 2008 上提供的一種以狀態為主的多重主機複寫引擎。您也可以把 Web 應用程式的內容檔案放到 UNC 共用上，盡可能降低 Web 前端的儲存需求。
其他可能的最佳化還包括安全性或動態快取。我沒有在測試實驗室裡面處理安全性和效能最佳化，因為這已經超出本文討論範圍。為了避免安裝其他伺服器，我也沒有設定 DFS。隨附資料裡面的逐步指示提供了一個簡化的範例，說明如何在 UNC 共用上主控 applicationHost.config 檔案和網頁內容。而 [圖 6] 則圖解了如何使用 DFS 來實作 UNC 架構的 Web 伺服陣列。
[圖 6] 使用 applicationHost.config 檔案和 UNC 共用上的網頁內容部署的 Web 伺服陣列 (按一下以放大影像)

總結
IIS 7.0 是令人刮目相看的網頁伺服器平台。它在重新設計核心架構的同時，也與 IIS 6.0 保持近百分之百的回溯相容性。它應該不用修改就能執行大部分現有的 ASP.NET Web 應用程式。但是架構化變更的範圍之廣，您無法假定不會遇到相容性問題。
無論您是將 ASP.NET 或 PHP Web 應用程式移轉至 IIS 7.0，最好是採取分階段方式，並把重點放在妥善規劃、準備、測試，以及記錄程式碼和設定變更上。
IIS 7.0 值得您投入這樣的心力。它在安全性、效能、設定性和彈性各方面都有許多改進。若要一一討論可能要寫上一整本書才行。以 UNC 共用為基礎的集中化設定和內容共用，透過應用程式目錄裡面的 web.config 檔案進行委派設定，改進的管理工具，詳盡的診斷資訊和失敗要求追蹤，以及動態輸出快取，在在都是贏得 Web 管理員芳心的必勝之道。
能夠在要求處理管線內混和原生與 Managed 模組，使 ASP.NET 開發人員受益匪淺。而透過 IIS 7.0 上的 FastCGI 所帶來的效能和穩定性提升，對 PHP 應用程式開發人員來說，更是一大福音。
另外還有一個重要的東西可幫助 IT 專業人員成功使用 IIS 7.0：Microsoft IIS 社群入口網站 (www.iis.net)。它包含了您所需的全部資訊，包括關於新架構的詳實文章，給 C++ 和 ASP.NET 開發人員的原始程式碼，示範如何建立 IIS 7.0 模組，以及讓 PHP 應用程式順利執行的逐步指示。您肯定會想要瞧瞧這個網站。這是解答您 IIS 相關問題的好地方。

Fergus Strachan 是 Maestra Ltd London 的創辦人兼董事，這是一家專事 IT 基礎結構設計和專案管理支援的顧問公司，為國際性銀行和英國境內的教育機構提供服務。他主要是編寫 Microsoft 伺服器技術的相關文章，並且是《Integrating ISA Server 2006 with Microsoft Exchange 2007》一書的作者。他也是《Microsoft Exchange Server 2003 Resource Kit》的作者之一。

© 2008 Microsoft Corporation and CMP Media, LLC.著作權所有，並保留一切權利。未經許可，不得部分或全部重製。


溝通與共同作業
為移轉至整合訊息作規劃
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 年來的經驗，即使最複雜、具有最特定需求的組織，也能夠成功移轉。
無論您處理的是單站還是多站的公司，只要根據這五大基本步驟來建置移轉策略，就能獲益無窮。
  1. 規劃和設計您的解決方案。
  2. 安裝和設定 Unified Messaging Server role。
  3. 移轉試驗小組。
  4. 根據試驗小組的意見來修訂設計。
  5. 移轉使用者。
當然，多站公司所面臨的挑戰，的確是單站案例所沒有的。我會在「多站挑戰」資訊看板中分別討論這些挑戰。
規劃和設計解決方案是移轉程序當中最重要的一個步驟。我建議您針對這個專案，指派一個整合通訊小組。這個小組應該涵蓋公司各個不同部門的代表，各自具備電訊、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。


溝通與共同作業
語音如何發揮 OCS 2007 的功力
Rajesh Ramanathan
綜覽：
  • 在 OCS 2007 中打電話
  • 通話如何獲得保全
  • OCS 中的多樣式交談
  • 與 Exchange UM 整合以利用語音信箱

目錄
基本語音電話
使用電話號碼
保護通話安全
周遊 NAT 和防火牆
路由電話號碼
輸入路由
品質報告和疑難排解
整體回顧
多樣式行為和交談
語音信箱
總結
Microsoft Office Communication Server (OCS) 2007 這一系列的第一篇說明了 OCS 如何以 Live Communication Server (LCS) 2005 的優點為基礎建置而成，
以提供增強的企業級立即訊息 (IM) 與目前狀態功能，另外也介紹了進階的媒體和電話功能 (請參閱 2008 年 2 月份《TechNet Magazine》，網址是 technet.microsoft.com/magazine/cc194409)。本文則更加深入地探索 VoIP 這一面。我將解釋如何在 OCS 系統中進行簡單的語音通話，並且分層討論技術，以便在新增每個元件的同時加入相對應的功能。
如前文所述，您可以設定讓 OCS 以各種不同的設定，提供電話語音功能給使用者。
企業語音 這是完整的整合通訊解決方案，可在不需 PBX 的情況下，將 OCS 搭配 Microsoft® 中繼伺服器使用。而系統中的語音信箱功能，則由 Exchange 整合通訊 (UM) 提供。在本文中，我把擁有這項服務的使用者稱為「UC 使用者」，並以「UC 端點」一詞代表這個設定的用戶端。
與 PBX 整合的企業語音 這項設定不但可讓使用者享受整合通訊的好處，同時也能在桌面上保有現有的 PBX 電話。它容許 OCS 與 PBX 平行設定，以便讓來電同時在 Office Communicator 和 PBX 端點響鈴。PBX 仍舊控制來電路由，也仍舊提供語音信箱服務。
遠端呼叫控制 這項功能把 PBX 電話當作主要電話使用，並且允許透過 Office Communicator 用戶端來控制電話。

基本語音電話
本文我將側重在企業語音使用者的運作方式。簡單的語音電話是在 OCS 系統中，使用 SIP INVITE 機制設定而成 (如 RFC 3261 中所述)。OCS 伺服器所扮演的代理角色，與在用戶端 (或端點) 之間轉送郵件的郵件管理員很像。新的 SIP INVITE 是由用戶端在每次建立即時工作階段 (例如通話或立即訊息工作階段) 時發出。如果 INVITE 受到認可並有答覆 (也就是說，遠端端點傳送 200 OK 回應)，便會建立通話 (見 [圖 1])。
[圖 1] INVITE 格式和 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
在 [圖 2] 中，Alice 從 Office Communicator (OC) 2007 選擇 Communicator 電話來呼叫 Bob，於是 OC 2007 發出 INVITE 給 Bob 的 SIP 統一資源識別元或 URI (sip:bob@example.com)。INVITE 會攜帶媒體端點的音訊工作階段描述元 (稱做 SDP，工作階段描述通訊協定的縮寫)，讓 Alice 在此處接收音訊。OCS 會將 INVITE 分支到 Bob 已註冊的 SIP 端點 (例如，Communicator Phone Edition 和 Communicator 桌上型電腦)。INVITE 包含 sip:alice@example.com 的寄件者標頭，Bob 的用戶端端點會用它在反向名稱對應 (RNL) 尋找要在來電通知中顯示的名稱 (Alice)。
[圖 2] 將電話路由到多個端點 (按一下以放大影像)
每個端點都會顯示可全域路由的使用者代理程式 URI (Globally Routable User Agent URI，GRUU)。GRUU 可專門識別 SIP 端點，而且它是在註冊程序期間向 OCS 伺服器取得的。GRUU 位址有助於路由 SIP 訊息，比方說，當端點一接聽來電，便馬上使用 GRUU 位址，直接在端點間運送其他通話中作業的後續 SIP 信號。
[圖 3] 則繼續進行這個過程，其中 Bob 是從 Communicator 桌上型電腦接聽。Bob 的 OC 會傳送 200 OK 訊息，表示他可在哪裡接收音訊。OCS Proxy 一偵測到其中一個端點已經接聽，就會取消對其他 Communicator Phone Edition 端點所進行的通話。一旦 200 OK 回應抵達 Alice 的 Communicator 端點，兩邊的 Communicator 端點便有充分的資訊 (IP 連接埠、加密參數等) 可以啟動媒體。
[圖 3] 從端點接聽 (按一下以放大影像)

使用電話號碼
到目前為止，我們看到了使用者按一下 Communicator 電話來建立邀請函。如果使用者選擇或輸入電話號碼的話，整個程序將稍有不同。
  • 用戶端會先將電話號碼正規化，並將它表示成 TEL URI，以描述電話號碼所識別的資源 (如 RFC 3966 所述)。
  • 由於 OCS 伺服器只識別 SIP URI，因此用戶端會加入網域尾碼和 user=phone 標記，將 TEL URI 轉換成相對應的 SIP URI。
  • 如果號碼對應到內部使用者，OCS 便會直接路由邀請函。如果號碼是外部的，則邀請函會路由到最近的 SIP-PSTN 閘道。
有些打到公用交換電話網路 (PSTN) 號碼的電話，要求在接聽電話之前先設定媒體路徑，以便播放遠端通告或收集其他數字來完成通話。在這種情況下，PSTN 閘道會連同音訊 SDP，傳送 183 工作階段進度指示器。Communicator 會在遠端使用者接聽電話之前，使用這項資訊來設定具有一個目的地端點的雙向媒體路徑。
媒體路徑完全設定妥當之後，Communicator 就會啟用複頻式訊號或 DTMF (電話信號音) 鍵盤，好讓使用者輸入遠端系統所需的其他任何數字。使用者所輸入的任何 DTMF 數字，都會在媒體路徑中作為 RFC 2833 封包傳送。PSTN 閘道會負責在 PSTN 端產生適當的 DTMF 信號音。
請注意，若是 Bob 已在行動電話啟用同時響鈴的話，OCS Proxy 會將電話路由到閘道，並同時在 Bob 的其他 Communicator 端點響鈴。在這個案例當中，OCS Proxy 會指出 183 工作階段進度回應中有使用分叉，而這種情況會使得 Communicator 透過 PSTN 閘道，建立一個專門負責接收的媒體通道。

保護通話安全
OC 所設定的語音電話，其中一項重要功能就是它預設會使用安全即時傳輸通訊協定 (Secure Real-Time Transport Protocol，SRTP) 加密媒體，如 RFC3711 中所述。SRTP 為 RTP 流量提供了機密性、訊息驗證，以及重新執行保護。在通話設定期間，用戶端會彼此交涉安全性功能，並交換加密金鑰，這是 INVITE 機制的一部分。
OC 的預設加密設定是「選擇性」的，這一點可讓兩個 OC 端點設定加密的媒體通道。系統管理員可以配合組織的循規需要，調整這項設定。比方說，可以將它調整得嚴密一點，以強制加密所有電話，或者完全關閉。

周遊 NAT 和防火牆
OCS 系統中的用戶端是使用互動式連線建立 (ICE) 技術，為網路位址轉譯裝置和防火牆背後的使用者，提供媒體連線能力，而不需要對現有的 NAT 元件進行任何變更。ICE 技術目前是由網際網路工程任務推動小組 (Internet Engineering Task Force，IETF) 負責標準化。每一個用戶端都知道音訊/視訊 (A/V) Edge Server，這部伺服器是透過 Inband 佈建機制提供用戶端服務，並且在登入期間維護 A/V Edge 的驗證連結。
在進行通話之前，用戶端會在 A/V Edge Server (用於媒體轉送) 可能的連線位置 (位址和連接埠，也稱為候選位置) 上、在 NAT 上，或是在主用戶端上配置資源。當送出工作階段初始通訊協定 (SIP) INVITE 時，它也會在 INVITE 附帶這項連線資訊。200 OK 回應會攜帶類似的對等候選位置資訊。等到每一個端點都有一份對等候選位置清單之後，就會有一套詳盡的排名和檢查機制，從兩個對等之間，選擇保證媒體能夠成功的最佳路徑。

路由電話號碼
路由電話號碼為基本通話機制添加了一些複雜度，原因如下：
  • 公司可能有在內部部署有利快速撥號的其他撥號計畫。
  • 號碼可能是以非標準格式儲存 (例如，使用者可能在 Microsoft Office Outlook® 中儲存七位數的字串)。
  • 可能有不同的原則對應到不同的輸出號碼。例如，可能會封鎖特定的使用者撥打國際號碼。
OCS 系統要求電話號碼必須具備 RFC 3966 TEL URI 格式，才能正確路由。不具這種格式的號碼，會在用戶端發出 INVITE 之前先行轉換。[圖 4] 中的圖表，說明了這項作業在 OCS 系統內的運作方式。
[圖 4] 路由電話號碼 (按一下以放大影像)
用戶端可以使用的號碼，可能是來自不同的來源。預先正規化的號碼是來自通訊錄服務 (ABS)，它可以用系統管理員定義的正規化規則，將號碼轉換成正規化的 E 164 格式。一旦用戶端發出 SIP INVITE 到正規化的號碼時，OCS 便會套用轉譯程序，將號碼對應到任何內部使用者。
  • 步驟 1 顯示輸入系統的號碼是專屬號碼 (在 E 164 編號計畫之後加以正規化)，或是含有可識別位置的電話內容。這些號碼都會當作 SIP INVITE 的一部分，傳送到伺服器。OCS 會將 INVITE 路由到轉譯程序。
  • 轉譯程序 (步驟 2) 會使用伺服器端 RNL，將電話號碼對應到 UC 端點。這項轉譯作業可為該號碼識別出一條通往輸出路由或 UC 使用者的路由；如果號碼無法正確轉譯的話，可能會放棄通話，並產生 4xx 碼。
  • 如果號碼是轉譯成非 UC 或外部號碼，則在套用與來電者相關的號碼原則之後，會將它傳送到輸出路由元件，此元件會將 INVITE 重新導向適當的 SIP-PSTN 閘道，以供進一步處理 (步驟 3A)。輸出路由會負責平衡閘道間的通話負載，或是在必要時，容錯移轉到替代閘道。如果禁止存取特定號碼，輸出路由程序可能會放棄或拒絕通話，並傳回 SIP 403 回應碼。請注意，輸出路由只適用於來電者是 UC 使用者的情況。如果來電者並非 UC 使用者，OCS 會嘗試使用針對該 URI 設定的閘道的靜態路由。
  • 如果號碼轉譯成 UC 使用者的號碼，則會將 INVITE 路由到該使用者的 SIP URI (步驟 3B)。輸出路由是 OCS 的一項功能，只適用於 UC 使用者，以及目標是 SIP URI 的所有通話。如您所見，輸出路由會為 UC 使用者套用響鈴逾時、來電轉接和語音信箱轉接的規則。
要注意的是，正規化程序所得出的號碼，可能會因用戶端的位置而有所不同。系統管理員可以設定位置設定檔，並且指派特定位置專用的號碼轉換規則 (例如，四位數撥號在該位置將如何運作)。每一個 UC 使用者都有指派一個位置設定檔，而系統中所有的用戶端都會使用 Inband 佈建，下載它們自己位置設定檔專用的規則。接下來我就要探討輸入路由的細節。

輸入路由
輸入路由規則會指定當系統內有註冊用戶端或者沒有註冊用戶端的情況下，打給使用者的電話該如何路由。輸入路由元件也會把以目前狀態為基礎的規則套用到來電，比方說，如果使用者將目前狀態設定為「請勿打擾」，就可以把來電傳送到語音信箱。輸入路由可感知目前狀態容器層級，並且會自動拒絕封鎖容器內的使用者的來電。[圖 5] 顯示 OCS 輸入路由元件所支援的選項摘要。
[圖 5] 輸入路由功能
功能 | 註解
來電轉接鈴聲長度 | 預設為 20 秒。使用者最多可將它改為 60 秒。過了這段逾時期間，來電便會轉到未接聽來電目的地。
將未接聽的電話路由到語音信箱 | 如果使用者有啟用語音信箱，則為預設值。來電是根據輸入路由規則加以路由。
若來電者在電話進入語音信箱之前掛斷，則產生未接來電通知 | 通知 Exchange UM 有這類未接來電。
來電封鎖 | 拒絕受到封鎖之來電者的來電 (只能封鎖具備 SIP 身分識別之使用者的來電)。
請勿打擾 | 將來電路由到語音信箱。如果使用者採用這個模式，就不會同時在目的地響鈴。
允許插播清單 | 如果來電者位於 [小組] 容器內，即使使用者是設為 [請勿打擾]，也會接受來電。
同時響鈴 | 設定來電同時在 PSTN 電話號碼，還有 Communicator 和 Communicator Phone Edition 用戶端響鈴。
立即來電轉接 | 立即將來電轉接給另一名使用者、PSTN 電話號碼或語音信箱。
來電轉接未接聽 | 將未接聽的來電轉接給另一名使用者、PSTN 電話號碼或語音信箱。
工作時間 | 使用 Outlook 行事曆上設定的工作時間，來啟動使用者的來電轉接設定。
輸入路由規則會作為屬於使用者自我佈建資訊一部分的 XML 結構描述，上載到伺服器。[圖 6] 顯示輸入路由的運作方式。撥打給 OCS 系統內的使用者，預設會向使用者響鈴 (顯示為「我」)。如果沒有在鈴響時間內接聽來電，未接聽的來電預設會傳送到語音信箱。使用者可以選擇修改預設設定，方法是選擇直接立即轉接到電話號碼、另一個人或是語音信箱。
[圖 6] 路由來電 (在工作時間內) (按一下以放大影像)
立即轉接到另一個人或電話號碼的任何來電，都會使那個人或那個號碼的輸入路由規則生效。使用者也可以將未接聽的來電，轉接設定為另一個號碼或人員。
如果使用者勾選轉接規則中的 [僅在我的 Outlook 工作時間內套用 (Apply only during my Outlook Working Hours)] 選項，便會在工作時間內套用 [圖 6] 所示的規則，而且會在這些時間之外，套用預設的註冊端點響鈴行為。請注意，公司必須先部署 Microsoft Exchange Server 2007 和 Outlook 2007 用戶端之後，才能套用這個行為，因為 Communicator 會使用 Exchange 2007 可用性 Web 服務的工作時間資訊，並且運用 Outlook 2007 自動探索支援，以取得伺服器的位置。

品質報告和疑難排解
雖然 OCS 2007 系統中的用戶端是採用 RTAudio (較新一代的音訊轉碼器，可容忍不完美的網路狀況，例如抖動、封包遺失等)，但是為了讓系統管理員找出並修正可能的作用點，仍舊有監視的必要。OCS 2007 系統中的用戶端會報告每一通來電的品質，並且在每一通來電結束時，將詳盡的統計資料，包括頻寬、虧損、抖動、平均意見指標 (使用者主觀的測量標準) 使用的裝置等等，提供給中央體驗品質 (QoE) 伺服器。這是透過將 SIP SERVICE 要求內的承載傳送到 QoE 伺服器來完成，而伺服器的位址是使用 Inband 佈建機制編排的。
請注意，所有用戶端端點會個別向 QoE 伺服器報告通話品質。如果來電因信號發生錯誤而斷話，用戶端也會依此向 OCS 報告，為用戶端產生的所有錯誤提供儲存機制。

整體回顧
我們已經逐一講解設定通話的幾個層面 (包括輸入號碼、輸入和輸出路由，以及連線能力檢查)，接下來讓我們回顧一下整體程序。[圖 7] 概述從使用者打出電話開始發生的事情。OCS 系統內的用戶端在設定電話方面扮演著舉足輕重的角色，而且它們也負責管理整個電話設定程序。OCS 會參與初始的來電路由，而 Edge Server 會幫助用戶端找出最佳的媒體路由。現在讓我們來看看接下來所發生的事 — 交談。
[圖 7] 端對端通話流程 (按一下以放大影像)

多樣式行為和交談
交談的概念是 OCS 系統的核心，交談是兩個或兩個以上的人之間進行的多樣式工作階段，而且同時可以包括聲音、視訊和 IM，以及成品，例如在工作階段期間的檔案傳輸、Outlook 中的電子郵件，或是儲存在 Microsoft Office OneNote® 中的記事。
交談有好幾個層面可能會對 OCS 用戶端系統的設計產生影響：
  • 交談中所包括的所有樣式，都是使用相同的視窗。如果在音訊交談中加入立即訊息，它也會結合到相同的視窗。
  • 交談可以跨裝置進行。使用者可以選擇在 Communicator Phone Edition 上使用音訊，但在 Communicator 桌上型電腦上使用 IM。
  • 所有模式的規模都會擴大成會議：如果發生規模擴大的情況，交談的所有樣式都必須一起擴大規模，無論樣式目前所在的裝置為何都一樣。比方說，如果在 Communicator Phone Edition 上能夠使用音訊模式，而在 Communicator 桌上型電腦上的同一個交談能夠使用 IM 模式，那麼擴大規模成會議，可以確保音訊和 IM 的參與者，就是該交談的參與者。
  • 交談會記錄下來，個別的工作階段則不會。通話記錄內含關於交談的完整資訊，包括在交談期間內所記錄的筆記相關細節、交換的立即訊息，以及音訊維持的時間等等。這可讓使用者在 Outlook　開啟通話記錄時，方便統一檢視整個交談。
  • 交談可以從交談記錄繼續進行。OCS 用戶端是使用交談識別碼 (可跨越裝置和應用程式，專門識別交談的號碼)，將交談繫結在一起。如果新交談是從舊交談的歷程記錄開始，則會有一套精巧的機制來計算交談的差異。相同的交談識別碼也會在 Outlook 儲存成電子郵件的識別碼。
交談識別碼會以自訂屬性 Ms-Conversation-Id，作為 SIP INVITE 的一部分傳播。[圖 8] 所示的交易，是先加入聲音，再加入 IM。請注意，多樣式交談結束時，儲存在 Outlook 中的歷程記錄具有相同的交談識別碼。
[圖 8] 多樣式交談和交談識別碼 (按一下以放大影像)

Exchange UM 是 OCS 2007 的語音信箱系統。OCS 只會將有啟用 UC 的使用者的來電，路由到 Exchange UM。OCS 提供幾項與 Exchange UM 整合的功能：
  • Communicator 電話 UI 的 [來電語音信箱] 選項 (見 [圖 9]) 可讓使用者在無需輸入 PIN 的情況下，管理 UM 信箱、變更留言等，因為他已經通過驗證了。
  • Communicator UI 中的等候訊息指示器 (見 [圖 10]) 可讓使用者在 Outlook 中開啟語音信箱資料夾，而 Communicator Phone Edition 中的指示器，則可讓使用者直接從電話播放語音訊息。
  • 來電可從 Communicator 的 UI 轉接到語音信箱。
  • 被拒絕的來電會自動路由到語音信箱。
  • Outlook 中語音信箱項目的 [在電話上播放]，會直接在 Office Communicator 用戶端響鈴。
[圖 9] Communicator 中的 [來電語音信箱] 選項
[圖 10] Communicator 中的訊息等候指示器
OC 接收語音信箱通知所採用的機制，與 Communicator Phone Edition 的不同。OC 會在 Outlook 中的 [語音信箱] 搜尋資料夾上註冊新的郵件通知，並且在這個資料夾中報告新郵件。Communicator 也使用 [未接交談] 和 [通話記錄]。

總結
我在本文說明了語音電話在 OCS 2007 中的運作方式，OCS 2007 是以運用數個 RFC 的 SIP 為基礎建置而成。用戶端端點在 OCS 中管理通話方面扮演著重要的角色。所有的語音通話預設都會經過安全加密。OCS 提供具彈性的元件，允許它們在整個系統中操控號碼和管理流程。
交談是 OCS 中的核心概念，包括聲音、IM 和視訊。OCS 與 Exchange UM 整合，並允許 Communicator 端點接收語音信箱的通知，以及透過 Outlook 或直接從伺服器存取語音信箱。

Rajesh Ramanathan 在通訊領域工作已長達 14 年之久，並且投身設計語音通訊協定、使用者體驗和 Office Communicator 2007 的語音和會議功能。他目前在 Microsoft 的 Office Communicator 小組擔任專案主管一職。您可以透過電子郵件與 Rajesh 聯絡：rajeshra@microsoft.com。


溝通與共同作業
透過 Groove 和 SharePoint 建立強大的連線
Alan Maddison
綜覽：
  • 建立 SharePoint 文件庫
  • 建立 Groove 工作區
  • 同步處理 Groove 與 SharePoint
  • 允許存取工作區

目錄
Groove 與 SharePoint 並用
快速入門
設定核准控制
建立 Groove 工作區
同步處理 Groove 與 SharePoint
允許存取工作區
結語
IT 專業人員常常對 Microsoft Office Groove 2007 (Groove) 與 Microsoft Office SharePoint Server 2007 (SharePoint) 之間明顯的類似性感到好奇，
而且不確定各自適用於哪種情況。乍看之下，兩種產品的確相當類似，因為它們都提供共同作業的功能。不過，只要深入探勘各自的架構，就可以看出其間的差別。
SharePoint® 提供穩固且可調整的內容管理架構和共同作業工具組，並支援結構化工作流程。相較之下，Groove™ 則是允許在完全沒有或是只有一點點 IT 負荷的情況下，快速部署工作區的共同作業工具組。Groove 支援文件共同作業、往來討論和行事曆功能，從而提供理想的架構，達成動態、安全及隨機操作的共同作業。簡而言之，大多數使用者最後都會自然而然以不同的方式來使用這些產品。
另外，Groove 2007 還添加了內建支援，方便您使用 SharePoint 檔案工具來整合 SharePoint。這項工具不但可以同步處理 Groove 工作區與 SharePoint 文件庫，同時內建的整合功能也方便您充分運用兩項產品。結合 Groove 富於彈性和動態的本質，與 SharePoint 的精密和威力，將為許多人帶來顯著的利益。
Groove 與 SharePoint 並用
當今的 IT 產業要求組織與其合作夥伴和廠商之間必須更加密切的合作。但是，使用像 SharePoint 等產品實作的強大共同作業解決方案，多半傾向於把重點放在內部小組，以及讓資訊廣泛用於整個組織內部的需要上。在這種情況下，從系統管理和安全性的觀點看來，提供存取權給組織外部的使用者，往往具備重大的挑戰。面臨這樣的挑戰，讓使用者得以透過臨機操作向外聯繫外部合作夥伴，遂成為主要的目標。
而結合 Groove 與 SharePoint 正可以提供這樣的解決方案。SharePoint 提供內部組織共同合作、內容搜尋和工作流程架構，而加入 Groove 則可讓公司擴展這些功能，輕鬆進行組織間相互的共同作業。透過 Groove，使用者可以快速跨越公司的界限，設定共同作業工作區。另外，對 192 位元進階加密標準 (AES) 對稱金鑰的支援，也確保共同作業能夠安全進行。事實上，Groove 安全性是內建的，而且永遠處於開啟狀態，因此使用者無需煩惱設定的問題。
Groove 的安全性架構為這些工作區及當中的內容 (無論儲存在本機或是在網路傳輸期間)，都提供了高層的保護。SharePoint 檔案工具可讓這項資訊與 SharePoint 文件庫雙向同步，以確保該資訊能夠集中使用，以方便內部存取。讓我們舉一個具體的例子來看看這個程序的運作方式。
快速入門
各組織常常在日常的商業活動中，與許多公司共同作業。通常這不僅包括外部組織，也包括不定期合作的各部門 (例如財務、企業溝通和法律部門) 的個人。因此這些組織不但需要建立共同作業的臨機操作內部小組，也必須讓那些未參與共同作業程序但又必須存取最終成品的人，使用這個共同作業的產品。而使用 SharePoint 和 Groove，可以輕易達成這些目標。
如果您還沒有要與 Groove 工作區同步處理的 SharePoint 文件庫，第一步是先建立一個文件庫。方法是連接到 SharePoint，然後選取 [檢視所有內容 (View All Content)] 連結。待頁面載入之後，請選取 [建立 (Create)]，然後從 [文件庫 (Libraries)] 一欄選取 [文件庫 (Document Library)]，如 [圖 1] 所示。
[圖 1] 建立 SharePoint 文件庫 (按一下以放大影像)
在新增文件庫頁面上有好幾個需要設定的項目 -- 文件庫的名稱和描述、是否要在 [快速連結] 區段中包含文件庫、是否要啟用版本控制，以及直接在文件庫中建立的新文件的預設格式。[文件版本歷程記錄 (Document Version History)] 預設並不會選取，如果版本控制適用於您的環境，您應該啟用這項功能。另外，您也應該考慮使用 SharePoint 提供的一些進階功能，將它們作為 Groove 和 SharePoint 實作的一部分。此增強功能包括：
  • 版本歷程記錄
  • 核准控制
  • 簽出程序
  • 工作流程控制
  • 文件保留原則
  • 稽核
  • Really Simple Syndication (RSS)
透過 SharePoint 提供的這些附加功能，在與 Groove 搭配使用時，能提供無比的價值。在我的範例中，此附加功能 — 尤其是核准控制 — 確實成效不俗。例如，假設小組成員在 Groove 內共同編擬一份文件。當最後的草稿準備好複閱時，可以將它與 SharePoint 同步處理，然後依照核准程序辦理。

設定核准控制
若要設定這項功能，請從文件庫選取 [設定] 功能表，然後選取設定項目，讓您檢視所有的設定和自訂選項。若要設定核准，請在 [權限與管理] 區段中選取 [工作流程] 設定連結，帶出 [新增工作流程] 頁面。接下來是選取工作流程範本 (在我們的範例中是核准範本)，然後為該工作流程輸入名稱。接下來您必須決定是要使用現有的工作清單，還是建立新的工作清單。新工作清單所提供的機密性較佳，但這一點在我們的範例中並不重要，所以直接選取預設值即可。
選好工作清單之後，您必須決定要怎麼開始核准程序。讓我們採用手動程序，允許任何通過驗證且具有正確權限的使用者開始進行程序。其他選項則可讓您根據版本控制 (如果在文件庫上有啟用的話)，或是每次新增文件或變更現有文件時，將此程序自動化。
當您按 [下一步] 接受這些設定選項之後，必須輸入一些最終的設定資訊。第一個選項是設定要如何指派工作。由於核准程序中的參與人員可能不只一個，因此您可以連續指派核准者，也就是等其中一人核准某個項目之後，再移往下一人；您也可以平行指派核准者，也就是任何人都可以隨時核准。接下來必須決定是否要允許核准者指派工作給其他人，以及他們是否可以在工作完成前要求進行變更。
下一步是選擇實際的核准者，然後決定何時應該完成工作。最後再決定何時要完成工作流程。預設的選項是，工作流程會在所有工作全部執行之後完成。在最後一個設定選項中，您要指定核准狀態是否要在工作流程一完成後就馬上更新。按了 [確定] 按鈕之後，便會建立核准程序，您也可以開始進行核准文件的程序。

建立 Groove 工作區
建好 SharePoint 文件庫之後，下一步就是建立 Groove 工作區。不過您必須先確定您有 Groove 帳戶，而且至少具備一個身分識別才行。身分識別是在 Groove 內表示狀態和通訊的基本條件。每一個 Groove 帳戶都可以和多個身分識別建立關聯，而每一個身分識別皆與一個專屬的連絡檔案相關聯，因此您可以針對您所用的每一個身分識別，自訂連絡資訊。您也可以匯出 Groove 帳戶及相關聯的身分識別，以便用於多部電腦上。
建好帳戶和身分識別之後，請按兩下系統匣中的 [Groove] 圖示，開啟 [Groove] 啟動列。接著再按一下 [新增工作區] 選項，為工作區輸入適當的名稱，然後選取 [標準] 工作區類型。Groove 標準工作區可使工作區成員的目前狀態、警示和角色指派等工作更具效率。按一下 [確定] 之後，Groove 便會建立工作區，並且開啟它。[圖 2] 所顯示的是有幾個檔案新增到檔案工具的新工作區。到目前為止，工作區都可以正常運作，而且您也可以設定警示或者隨意新增任何工具，來完成設定作業。
[圖 2] 新 Groove 工作區 (按一下以放大影像)
警示可以在工具、工作區或個別檔案層級設定。警示的四個等級是無、中度、高度和自動。設定中度會標示出新內容，而設定高度或自動則會播放檔案。您也可以設定警示，在使用者進入特定工作區時收到通知。若要設定警示，請從 [選項] 功能表選取 [設定警示]。個別檔案上的警示，是在檔案本身的內容上設定；請以滑鼠右鍵按一下工作區內的一個檔案，然後選取 [內容]。
除了用於文件共同作業的檔案工具，以及用於往來討論的討論工具 (屬於預設標準工作區的一部分) 之外，其他還有許多工具，包括行事曆、表單、問題追蹤、會議、繪圖本，當然還有 SharePoint 檔案工具。每一種工具都能夠提供其他有用的共同作業功能。若要新增工具，請選取工作區右下方的 [將工具新增至這個工作區] 按鈕，然後選取您要新增的工具，如 [圖 3] 所示。您也可以輕易地隨時刪除工具。
[圖 3] 新增工具到 Groove 工作區 (按一下以放大影像)

同步處理 Groove 與 SharePoint
新增 SharePoint 檔案工具之後，您必須設定內含您想要同步處理之文件庫的 SharePoint 網站的 URL。方法是在工作區畫面的下方選取 [SharePoint 檔案] 索引標籤，然後直接在 Groove 工作區按一下 [設定] 按鈕，如 [圖 4] 所示。
[圖 4] 設定 SharePoint 檔案工具 (按一下以放大影像)
輸入 URL 之後，您就可以看到該 SharePoint 網站上所有可用的文件庫了。如 [圖 5] 所示，接下來就是選取您要使用的文件庫。Groove 會進行連線，然後開始自動同步處理。也就是說，目前在 SharePoint 文件庫中的所有文件都會下載到 Groove 工作區，然後透過 Groove 工作區供大家使用。[圖 6] 顯示了一個範例。
[圖 5] 設定 URL 之後，您就可以在 Groove 中使用 SharePoint 文件庫了 (按一下以放大影像)
[圖 6] 同步處理 Groove 與 SharePoint (按一下以放大影像)
文件在 Groove 中是顯示成未閱讀，因為它們才剛剛下載而已。請注意，與 SharePoint 同步處理的所有檔案，都可以使用 SharePoint 簽入/簽出功能。另外，當您簽出檔案時，任何其他使用者都無法在您編輯文件時進行變更。
另外也請特別注意，SharePoint 檔案工具有提供雙向同步處理，因此如果您是透過 Groove 將檔案新增到 SharePoint 檔案工具，它們也會與 SharePoint 文件庫同步處理。雖然預設的同步處理是設定為自動進行，您還是可以按一下 [立即同步 (Synchronize Now)] 按鈕，手動起始同步處理。這時候，畫面會出現所有需要同步處理之檔案的變更，以及相關動作的摘要，您可以從 SharePoint 取得，或者傳送至 SharePoint，如 [圖 7] 所示。
[圖 7] 手動同步處理之後，畫面會出現變更摘要 (按一下以放大影像)
請注意，部署為 Groove 標準工作區一部分的檔案工具，與 SharePoint 檔案工具是不一樣的。Groove 檔案工具並不會與 SharePoint 同步處理，而且可以根據您的需要加以移除。然而，正因為這個工具不會與 SharePoint 同步處理，因此它可以作為一個存放位置，存放小組在專案期間需要存取的暫時檔案。存放在此處的檔案仍然會在工作區成員之間同步處理。

允許存取工作區
待基本的共同作業基礎結構全部部署妥當之後，就可以允許使用者存取工作區了。不過，您必須先邀請他們，這一點可以透過電子郵件或 Groove 立即訊息進行。要不然，也可以利用 Groove 將邀請函匯出到檔案。這個檔案的副檔名是 .grv，預設是與 Groove 應用程式相關聯，不過之後可以透過其他方式來傳送，例如放到網站上，允許收件者下載邀請函。
Groove 立即訊息包括安全性檢查，可確保只有收件者能夠閱讀邀請函。當您透過電子郵件邀請或是使用邀請檔案時，請務必勾選 [需要接受確認]，以便確認加入您工作區的人確實是您邀請的人。這一點可為工作區添加一層安全性。另外還要注意的是，您可以取消擱置中的邀請。
當您邀請使用者到工作區時，必須為每一個收件者選擇一個角色。角色包括管理員、參與者和訪客，而參與者是預設會指派的角色。每一個角色在工作區當中都有特定的權限，而根據一般原則，您應該將管理員角色只指派給那些在工作區裡面真的需要所有權限 (例如刪除工具) 的人。工作區建立者預設會取得管理員角色，而指派的角色隨時都可以變更。
假設本文中的專案需要臨機操作，那麼最後一項工作便是在一切完成之後，刪除 Groove 工作區。當您確定把工作區與 SharePoint 文件庫同步處理之後，請開啟工作區，前往 [檔案] 功能表，然後選取 [刪除工作區]。接下來則是選擇要 [從這部電腦 (From This Computer)] 刪除，還是刪除 [所有成員 (For All Members)] 的選項 (每一個使用者在他的電腦上都有工作區的複本，而且除非您刪除所有成員的工作區，否則它會無限期的存在)。
專案最高潮之處莫過於有機會運用 Groove 和 SharePoint 的互補本質。一旦文件完成最後的同步處理之後，您便能使用 SharePoint 中的資訊管理原則設定。更具體地說，您可以啟用資料到期，讓您自動管理封存資料。
啟用到期功能可讓您指定一段保留資料的時間。保留期結束之後，SharePoint 便可以自動刪除資料，或者開始進行工作流程程序。這項功能提供了一種途徑，讓您將 Groove 資料併入貴公司資訊週期管理原則。您可以隨時設定資料保留原則。如果您在最初設定文件庫時沒有設定資料保留原則，也可以在現在設定。
若要啟用到期功能，請從文件庫內部選取 [設定] 功能表，然後選取文件庫設定功能表項目。接著可以在頁面的 [權限與管理] 區段中檢視 [資訊管理原則設定] 功能表選項。一旦按下 [資訊管理原則設定] 連結之後，就可以指定您所定義的新自訂原則，或者選擇啟用文件庫，使用在網站層級定義的原則。
請注意，如果您選擇定義自訂原則，就必須輸入一些設定資訊。因此，在我的範例中，您必須啟用到期功能，然後選擇保留期間，以及當保留期限到期時所要執行的動作。
Groove 是豐富的共同作業用戶端，專為臨機操作共同作業提供動態、直觀和安全的架構。Groove 藉由豐富的工具組，提供了輕量且具適應能力的共同作業平台，能夠輕鬆應用在組織內部或是不同的組織之間。
如果 SharePoint already 已為貴公司提供穩固且強大的內容管理架構和共同作業工具組，那麼將它與 Groove 的結合，更是一套陣容堅強的解決方案。這兩種產品極為互補，因此兩者搭配使用時，能為共同作業的小組提升顯著的產能。

Alan Maddison 在 Strategic Business Systems 擔任資深顧問，這家公司是 Brocade 的分公司。


Windows 系統管理
Windows Server 2008 Enterprise 容錯移轉叢集簡介
Chuck Timon
綜覽：
  • 容錯移轉叢集管理嵌入式管理單元
  • 新功能和增強功能
  • 備份及還原功能
  • 從 Windows Server 2003 移轉

目錄
全新管理介面
改良的設定程序
內嵌驗證程序
全新仲裁模型
安全性增強功能
擴充網路功能
提升與存放裝置互動時的可靠性
內建修復程序
全新備份及還原功能
自 Windows Server 2003 伺服器叢集移轉
自叢集首度在 Windows NT 4.0 企業版問世以來，使用者就不斷抱怨設定太難，要維護更是難上加難。要管理叢集，
系統管理員不光得要對叢集本身有所了解 — 他們還必須對儲存技術，還有叢集服務會如何與各種儲存解決方案互動等有深切的認識。許多公司都難尋具備完整技能讓高可用性解決方案正常執行，及維護它的千里馬。
叢集多年來不斷改善，但是隨著 Microsoft 開始開發 Windows Server® 2008，發現它仍有很多地方需要改進。有鑑於此，工作小組企圖以簡單為主要目標來重新設計叢集。在 Windows Server 2008 中，Microsoft® Cluster Services (MSCS) 經過徹底改頭換面，而現在改稱為容錯移轉叢集。
當然這不代表簡單是全新的容錯移轉叢集實作所帶來的唯一好處。這幾年來，因為公司對叢集解決方案的冀望提供了寶貴的意見，使得 Microsoft 學到了不少教訓。全新的容錯移轉叢集功能解決了許多使用者報告的首要問題，也參入一些令人雀躍的新功能，使它成為非常吸引人的產品。所以在本文中，我想要介紹您可以在 Windows Server 2008 容錯移轉叢集裡面找到的一些新酷功能。

全新管理介面
安裝容錯移轉叢集之後，便可以在 [系統管理工具] 中，或是透過執行 Cluadmin.msc 來存取容錯移轉叢集管理介面。[容錯移轉叢集管理] 嵌入式管理單元跟 Windows Server 2008 中其他的管理介面一樣，都是 Microsoft Management Console (MMC) 3.0。對於叢集老手來說，第一次開啟 [容錯移轉叢集管理] 嵌入式管理單元感覺可能有點像被放逐異國，而且手邊連地圖也沒有。
新介面分成三個不同的窗格，如 [圖 1] 所示。左窗格列出貴公司內所有的 Windows Server 2008 容錯移轉叢集。中間窗格提供您在左窗格內選定之任何一部分的叢集設定的詳細資訊，而右窗格則顯示您可以執行的動作。
[圖 1] [容錯移轉叢集管理] 嵌入式管理單元 (按一下以放大影像)
假設您在左窗格選定 [存放裝置]。中間窗格接著會詳細列出叢集內提供了哪個存放裝置，以及目前有哪個存放裝置可用 (如果有的話)。如您在 [圖 1] 所見，該叢集包含了一個支援見證磁碟的存放裝置，針對檔案伺服器提供的存放裝置，以及一些可用的存放裝置。右窗格列出相關的動作，例如新增更多存放裝置。請注意，[容錯移轉叢集管理] 嵌入式管理單元無法用來管理舊版的 Microsoft Clustering Services。

改良的設定程序
設定容錯移轉叢集相當簡單。許多設定、重新設定和維護叢集的動作都有精靈可用。拜這些精靈所賜，系統管理員不用再煩惱資源是否設定正確，或是它們是否會以正確的順序連線。
[圖 2] 顯示「高可用性精靈」。在這個特定的範例中，設定的是檔案伺服器。您在左邊可以看到精靈引導系統管理員逐步完成的步驟清單。程序一完成，便會顯示摘要頁面，之後可檢視報告。
[圖 2] 高可用性精靈 (按一下以放大影像)

內嵌驗證程序
在舊版的 Windows Server 中，硬體設定在 Windows Server Catalog 上必須列為 [叢集解決方案]，才能被視為支援的叢集解決方案。這包括多網站叢集，此類叢集是另外列在 [地理位置四散 (Geographically Dispersed)] 類別下。若要列在目錄中，硬體廠商必須執行一組 Windows 硬體裝置品質實驗室 (WHQL) 測試，並將結果提交給 Microsoft。這對廠商來說是成本高昂的提案，而且 Windows Server Catalog 資料庫也很難維護。
在 Windows Server 2008 中，容錯移轉叢集包含一個內建的驗證程序。此程序是由分成四大類別的一系列測試組成，如 [圖 3] 所示。
[圖 3] 容錯移轉叢集驗證測試類別 (按一下以放大影像)
您可以看到展開的 [網路] 類別顯示執行的測試，每個類別都包含一系列測試。[存放裝置] 類別也許是四個類別裡面最重要的，當中包含的測試可確保儲存解決方案遵守針對 Windows Server 2008 容錯移轉叢集設立的新需求。
具體地說，硬體廠商現在必須使用以 Microsoft Storport 驅動程式為基礎的驅動程式，而且他們必須支援 SCSI-3 持續保留。另外，使用多重路徑軟體裝置特定模組時，也必須依照 Microsoft Multi-Path Input\Output 標準。
隨著融入驗證程序，支援模型也有所變更。所有硬體都必須具備 Windows Server 2008 標誌，而且必須通過所有驗證測試。唯一的例外是具有兩個完全不同儲存機盒 — 每個網站各一個 — 及 Exchange Server 2007 叢集連續複寫實作的多網站叢集，這種叢集並不使用任何共用存放裝置。

全新仲裁模型
Windows Server 2008 容錯移轉叢集中的仲裁模型也有所變更。在舊版的系統中，當系統管理員聽到仲裁一詞，會聯想到存放叢集設定和一些複寫檔案的共用磁碟。這是叢集當中的單一失敗點。如果仲裁磁碟失敗，叢集服務便會終止，而且也會遺失高可用性。
Windows Server 2003 伺服器叢集提供了第二種仲裁類型，稱為多數節點組合仲裁。這類的仲裁一般是實作在多網站叢集中，而且不需要任何共用存放裝置。多數節點組合仲裁包括一個檔案共用，它位在每個叢集節點的系統磁碟上。此仲裁類型的連線是透過伺服器訊息區 (SMB) 連線的方式進行。同樣地，要讓叢集能夠正常運作，大多數的節點都必須參與。
之後，隨著 Exchange Server 2007 叢集連續複寫 (CCR) 的推出，Windows Server 2003 伺服器叢集也加入了檔案共用見證 (FSW) 功能。這容許單一 Exchange 2007 CCR 叢集節點 (或是任何多網站叢集) 只要達成大多數的 FSW 的連線就可以繼續提供服務。
在 Windows Server 2008 容錯移轉叢集中，仲裁的概念現在真正的意思是共識。現在只要有足夠的票數把叢集帶入服務，就可以達成仲裁 (或共識)。根據仲裁設定而定，有好幾種方法可以獲得足夠的投票數。Windows Server 2008 容錯移轉叢集裡提供四種仲裁模式，如 [圖 4] 所示。在列出的四種模式當中，只有前兩種 ([節點多數] 和 [節點與磁碟多數]) 在建立叢集程序期間能夠自動選取。應該採用的邏輯如下：
  • 如果叢集內設定了奇數節點，則選擇 [節點多數] 模式。
  • 如果叢集內設定了偶數節點，而且已連接且可存取共用存放裝置，則選擇 [節點與磁碟多數]。
[圖 4] 設定叢集仲裁精靈中的仲裁模式 (按一下以放大影像)
若要從可用的存放裝置選取見證磁碟，請選取第一個大小至少為 500 MB 且設定 NTFS 磁碟分割的磁碟。其餘的仲裁節點只能透過執行「設定叢集仲裁精靈」手動選取。[節點與磁碟多數] 選項一般是用在多網站叢集設定或是 Exchange 2007 CCR 叢集中。最後一個選項 [沒有多數：只有磁碟] 模式相當於舊版叢集中的共用仲裁模型。它是單一失敗點，而且一般來說不應該使用。
要幫助達成共識，叢集裡面只有兩種見證資源可以設定，那就是實體磁碟和檔案共用。
見證磁碟是叢集服務可以帶上線的一個存放裝置。這個磁碟是隨著叢集網路名稱和相關 IP 位址資源一起放在 [叢集核心資源群組] 中。設定見證磁碟時，磁碟上會放置一個 [叢集] 資料夾，也會放置叢集設定 (叢集 Hive 或複本) 的完整複本。
在理想的情況下，FSW 這種網路共用位在不屬於叢集一部分之網路的伺服器。對 FSW 會建立 SMB 連線，而 FSW 會保有一份見證記錄檔的複本，當中包含叢集設定的版本控制資訊。
叢集當中只能設定一個見證資源。如果叢集只要再多一票就能達成仲裁的話，這項資源會提供這額外的一票。換句話說，若是叢集再多一票 (也就是一個節點) 就能達成共識的話，就會將見證資源帶上線，以利達成仲裁。如果叢集要達成仲裁需要不只一票，就會留下見證資源，而叢集會保持在休眠狀態，等候其他叢集節點加入。

安全性增強功能
容錯移轉叢集包含幾項安全性增強新功能。其中最重要的可能是移除了叢集服務帳戶 (CSA) 的需求。在舊版的 Microsoft Cluster Service 中，設定程序期間需要有網域使用者帳戶。這個帳戶是用來啟動叢集服務，它在叢集的每個節點上除了會被加入本機 Administrators 群組外，也獲有必要的本機使用者權限好讓叢集服務正常運作。因為是網域使用者帳戶，CSA 也受到可能套用到叢集節點的幾項網域層級原則的約束。這些原則可能會導致叢集服務失敗，而對高可用性產生負面的影響。
叢集服務現在是在本機系統帳戶下執行，它在本機叢集節點上具有一組特定的權限，容它正常運作。叢集的安全性內容已轉換成叢集名稱物件 (CNO)，這是當叢集初次建立時，預設會在 Active Directory® 的 [電腦] 容器內建立的電腦物件。一旦成功建立叢集，而且 CNO 也存在於 Active Directory 中後，用來安裝和設定叢集的使用者帳戶就無用武之地。
Active Directory 中在 [電腦] 容器內建立的其他電腦物件都與容錯移轉叢集相關。這些物件稱為虛擬電腦物件 (VCO)，相當於在叢集當中作為用戶端存取點 (CAP) 一部分而建立的叢集網路名稱資源。負責在叢集中建立所有 VCO 的 CNO 會加入到 Active Directory 中該物件的系統存取控制清單 (SACL) (見 [圖 5])。
[圖 5] Active Directory 中 VCO 上的安全性 (按一下以放大影像)
CNO 也負責同步處理它所建立的所有 VCO 的網域密碼。完成這個程序是為了遵守設定的密碼替換網域原則。此外，由於 CNO 負責建立叢集中與 VCO 相關的所有電腦物件，因此 CNO (電腦帳戶) 必須具備網域層級權限，才能在建立 VCO 的容器 (預設是 [電腦] 容器) 上建立電腦物件。
另外一項變更是，現在的預設驗證方法是使用 Kerberos。Active Directory 中有電腦帳戶，便可利用這項安全性增強功能。但若應用程式無法使用 Kerberos 進行驗證，但需要存取叢集資源的話，叢集也可以使用 NT LAN Manager (NTLM) 進行驗證。
直接處理叢集程序的叢集節點之間的通訊也安全得多。在預設的情況下，所有內部叢集通訊都會經過簽署。您可使用 cluster.exe Common Language Interface 來變更這個叢集屬性，以加密節點之間的所有通訊，藉此多提供一層安全性。

擴充網路功能
容錯移轉叢集裡面的網路新功能，在設計高可用性和嚴重損毀修復解決方案方面提供更高的彈性。同時，這些網路增強功能在叢集中的各節點間還提供更可靠的連線能力。
客戶要求最殷切的功能莫過於希望能夠在不同的網路上尋找叢集節點。這點現在可以辦到。叢集網路驅動程式已經徹底重寫，若每個節點都連接到至少兩個完全不同的路由網路，它可在叢集內的節點間提供可靠性及容錯能力高的通訊。
叢集網路驅動程式會根據叢集啟動程序期間提供的連線資訊，建構它自己的內部路由表。其中包括本機連線資訊，也包括在叢集設定資料庫 (叢集登錄 Hive) 裡面提供的資訊。
叢集驗證程序有一部分包括網路連線探索程序。能夠在不同的路由網路上尋找叢集節點，降低了多網站叢集的網路需求。這讓組織部署起來更為簡單，成本也較低。它也使得在容錯移轉中使用 iSCSI 存放裝置成為更為吸引人的儲存解決方案。
叢集節點也可以透過 DHCP (動態主機設定通訊協定) 取得 IP 位址資訊。如果網路系統管理員可以接受在他們環境內的伺服器上使用動態位址，便可減輕他們的負擔。
叢集節點的網路介面設定可判斷哪個網路將使用靜態 IP 位址，而哪個網路將使用動態 IP 位址。即使叢集中 IP 位址資源是從 DHCP 伺服器取得的，您還是可以在 [容錯移轉叢集管理] 嵌入式管理單元裡面將它變更為靜態 IP 位址。
過去，所有的叢集通訊都是使用使用者資料包通訊協定 (UDP) 廣播，有時候會使用多點傳送。多點傳送功能已被移除，而叢集通訊現在是使用 UDP 單點傳送 (連接埠 3343 仍舊是 Microsoft 叢集常用的連接埠)。許多網路系統管理員將很樂見廣播被淘汰。然而，叢集當中真正的報酬其實跟叢集服務內部本身的新訊息程序有密切的關係 (不過這已經超出本文討論範圍)。雖然使用 UDP 作為傳輸機制，但內部叢集通訊現在卻擁有較可靠的 TCP 通訊。

提升與存放裝置互動時的可靠性
容錯移轉叢集與存放裝置互動的方式可說是大相逕庭。叢集磁碟驅動程式 (clusdisk.sys) 已經過徹底重寫，現在是真正的隨插即用 (PnP) 驅動程式。另外，它與存放裝置互動的方式也已改變。
在 Windows Server 2003 中，叢集磁碟驅動程式是直通存放裝置。但在 Windows Server 2008 中，叢集磁碟驅動程式會與磁碟分割管理員 (partmgr.sys) 驅動程式通訊以便與存放裝置進行互動。[圖 6] 中圖解說明了這兩種方法。
[圖 6] Windows Server 2008 中的存放堆疊有何變更 (按一下以放大影像)
磁碟分割管理員主要是負責保護叢集磁碟資源。當第一次對應到叢集節點時，共用存放區匯流排上的所有磁碟都會自動處於離線狀態。這讓存放裝置可以早在叢集建立之前，同時對應到叢集中的所有節點。現在不用一次只能啟動一個節點，在上面準備磁碟，然後關閉節點，啟動另一個節點，確認磁碟設定之類的。
不過還是要進行存放裝置測試，這些測試是作為叢集驗證程序的一部分執行，而且磁碟必須要初始化。這可在驗證程序執行之前，於叢集的其中一個節點上完成。一旦將存放裝置新增至叢集後，磁碟便會在 [磁碟管理] 介面中顯示 [已保留] 狀態，而且會一直保持在保護狀態。
另外一項變更是與 SCSI 命令有關。在 Windows Server 2003 中，SCSI-2 Reserve\Release 命令是與叢集磁碟驅動程式搭配使用，以寫入磁碟本身的磁區。而在 Windows Server 2008 中，SCSI-3 PR (持續保留) 命令是必要的。叢集節點必須先註冊之後，才能在存放裝置上放置保留區，而叢集節點會定期使用 Registration Defense Protocol 防護它們的保留區。
驗證程序中的其中一項存放裝置測試會驗證這項功能。如果儲存解決方案不支援 SCSI-3 (PR) 命令，表示它在容錯移轉叢集也不受支援。
許多公司在連接到存放裝置時，都使用多重路徑軟體以備援。這種作法不但受到支援，甚至還被諭為最佳作法。不過，協力廠商多重路徑軟體解決方案或裝置特定模組都必須使用 Microsoft Multi-Path Input\Output 標準重寫，在容錯移轉叢集中才能受到支援。這表示無論路徑是否處於作用狀態，所有 SCSI-3 PR 命令都會同時傳送所有存放裝置的路徑。驗證程序也會驗證這項功能。
其他儲存方面的改進還包括改良的檢查磁碟 (chkdsk.exe) 程序、內建磁碟修復功能 (之前是屬於「叢集伺服器修復公用程式」(Cluster Server Recovery Utility) 的一部分)，以及自我修復磁碟。在容錯移轉叢集中，識別叢集磁碟資源時會同時用到磁碟簽章和 LUN 識別碼。如果其中之一有所變更，便會更新叢集設定。也就是說，這可減少單純因為在實體磁碟資源上的屬性變更而引起的錯誤，進而達成更高的高可用性。

內建修復程序
之前提到的磁碟修復很明顯地是其中一項內建修復功能。而另一項則是 Active Directory 修復功能。若代表 CNO 的電腦物件遭到刪除，您將無法再建立與叢集 CAP 相關的電腦物件。然而，您會碰到的第一個問題很可能是發生在高度可用的應用程式或使用者因無法取得安全性權杖而不能存取叢集外部資源的情況下。
從已刪除的 CNO 復原包括兩個步驟。首先，您必須要求網域系統管理員將刪除的電腦物件從 Active Directory 中的 DeletedObject 容器復原。接下來，在還原並重新啟用物件之後，在 [容錯移轉管理] 嵌入式管理單元中執行 [修復 Active Directory 物件] 程序。
在 Windows Server 2003 伺服器叢集中，位於 %systemroot%\cluster 子目錄中的叢集設定檔有可能會損毀，而需要加以置換。在容錯移轉叢集中，自我修復功能可以幫上忙。若叢集服務在某節點上啟動，而且設定資料庫遭到損毀，便會使用包含在 HKLM\System\CCS\Services\ClusSvc\Parameters 登錄機碼中的資訊載入最精簡的設定範本。該節點會嘗試加入已經成形的叢集，而且如果嘗試成功的話，便會將叢集登錄 Hive 的全新複本推入節點。如果節點無法加入叢集，將會終止叢集服務。

全新備份及還原功能
容錯移轉叢集有自己的磁碟區陰影複製服務寫入器。這在備份和還原叢集資料庫和位於實體磁碟資源上的資料時，扮演著關鍵的角色。備份叢集設定相當簡單明瞭。只要系統狀態是屬於備份的一部分，即可還原叢集設定。但是要注意，叢集應當只有在有仲裁時才備份。這樣可保證備份的是最新的叢集設定。
叢集還原有兩種完全不同的類型：授權及未經授權。未經授權還原是使用 Windows Server Backup 或協力廠商備份應用程式從選定的備份執行還原。另一方面，叢集節點的授權還原只能使用 Windows Server Backup CLI (wbadmin.exe) 來完成。
授權還原基本上是在執行備份時，把叢集設定帶「回到過去」。若要完成授權還原，除了要執行還原的節點以外，在其他所有節點上都會停止叢集服務。還原一經完成，並且還原的節點上也啟動叢集服務後，叢集的還原設定便會變成明確的新叢集設定。接著，當重新啟動叢集當中其餘節點上的叢集服務時，便會在加入程序期間發送還原的設定。
這麼做在某些案例中可省下不少的時間和金錢。假設您擁有一個列印叢集，上面主控了多個列印多工緩衝處理器資源，各自支援 1,500 台印表機，而您不小心刪除了其中一個列印多工緩衝處理器資源。現在有一大堆使用者都不能列印。與其手動將所有這些印表機新增回叢集設定，直接執行叢集設定的授權還原可能快多了。這當然也要看您是否有完善的備份及還原策略而定。

自 Windows Server 2003 伺服器叢集移轉
基於 Windows Server 2008 容錯移轉叢集裡面所有這些架構變更，因此並不支援從 Windows Server 2003 進行就地或輪流升級。當從 Windows Server 2000 叢集升級到 Windows Server 2003 時，許多公司都會有系統地收回叢集裡面的每個節點，進行作業系統的全新安裝，然後將節點新增回叢集中。這種方法並不能用來移轉至 Windows Server 2008，因為 Windows Server 2003 和 Windows Server 2008 叢集節點無法屬於同個叢集的一部分。
所幸，它提供了一個精靈式的移轉程序來幫助移轉。但是移轉至 Windows Server 2008 容錯移轉叢集還是需要一些規劃。基本的移轉案例有三種：
  • 使用相同的伺服器和存放裝置。
  • 使用相同的伺服器，但搭配新存放裝置。
  • 使用新伺服器和新存放裝置。
無論是哪一種案例，都必須確定硬體已經過 Windows Server 2008 Logo Program 的認證，且已執行容錯移轉叢集驗證程序，並且通過了所有測試。這些步驟一完成後，便可前進到移轉程序。
並非 Windows Server 2003 伺服器叢集中的所有資源都可以移轉。您可以移轉網路名稱、IP 位址、實體磁碟、檔案共用、分散式檔案共用 (DFS) 根目錄、DHCP，以及 WINS。您也可以在有限的範圍內移轉一般服務、一般應用程式，以及一般指令碼資源。
另一方面，像 Microsoft Exchange 和 SQL Server® 這類的應用程式，在移轉到容錯移轉叢集時有自己的一套程序。印表機可以使用 [列印管理] 嵌入式管理單元 (這會隨列印伺服器角色一同安裝) 先匯出印表機，然後匯入到新設定的高可用列印伺服器，藉此移轉至 Windows Server 2008。協力廠商資源類型並無法移轉。
移轉程序並不會移轉任何資料。它牽涉的是將叢集組態設定從 Windows Server 2003 移轉到 Windows Server 2008。
在移轉程序完成時，所有已移轉的資源最先會處於離線狀態。這是因為可能需要執行其他必要的步驟。因此，在將叢集帶入服務之前，先檢閱移轉後報告來查看還需要哪些額外的步驟 (如果是移轉到新存放裝置，則不包括資料移轉) 是很重要的。舉個例來說，若要移轉 DHCP 伺服器，就必須將 DHCP 伺服器角色安裝在叢集裡面的所有節點上。如果是移轉 WINS 伺服器，則必須在叢集裡面的所有節點上安裝 WINS 伺服器功能。

Chuck Timon 在 Microsoft 擔任支援高階工程師，支援叢集和設定技術。他寫過 Windows Server 2008 容錯移轉叢集的訓練教材，現在正投身 Hyper-V 訓練。


編輯的話 告別印刷
Joshua Hoffman

印刷已死。或是，你們當中有很多人都這麼認為。在資訊無限的時代，資訊可以隨時隨地在任何裝置以任何形式呈現出來，那麼到底還有什麼地方保有用膠水裝訂成冊的紙本呢？難道印刷的時代已經過去了嗎？難道雜誌和報紙都該被發配到史密森尼博物館大廳，等著哪天我們去感受一下古早年代必須扛著厚實的樹木和墨水的懷舊氣氛嗎？
這麼說是不是有點危言聳聽呢？沒錯。不過我敢說您一定認為我完全不同意這個說法 (這可不只是為了我的工作安全著想；就算沒有了這份工作，我還是可以在 Microsoft 待下去)。其實不然，即使印刷文字稍嫌單純 (或許正因為它如此單純吧)，我仍然相信它能夠提供您相當深刻而豐富的體驗。當我要坐下來閱讀一篇長文時，我寧可選擇那篇文章是握在我的手上，而不是呈現在電腦螢幕上。對我來說，印刷本就是比電腦更有吸引力。這種觀點會不會太落伍了呢？也許吧，不過，根據我們新出爐的讀者問卷顯示，有九成的讀者也是這麼想的。
別急，我不是要您逃避現實。我很期盼現實，也很愛科技，但是一本刊物 (就像我們所出版的) 可以 (而且也應該) 涵蓋所有的體驗，它可以用不同的形式存在 — 例如，線上、離線，還有本尊。當然嘍，如果要我閱讀一篇 Mark Russinovich 所寫的又長又深奧的科技文章，我肯定會把它印出來再看。不過，我也很想親耳聽聽 Mark 本人的演講，親眼看看 Mark 本人解說他所討論的科技。
這種想法已經逐漸成為《TechNet Magazine》的指導原則了。雖然我們對每月交給印刷業者的出版刊物引以為傲，但是所有印刷出版的內容，也都會在 .com 線上發佈。在不久的將來，各位還會看到更多內容利用我們在網際網路上使用的專屬平台加以呈現。比方說，上一期我們就以 Don Jones 及其《Windows PowerShell》專欄，揭開螢幕錄製影片系列的序幕。所以現在您就可以看到 Don 逐步解說當月專欄主題的影片了。另外，我們網站也將推出新的《永續型運算》專欄，專門討論 IT 的環境影響，以及我們這些 IT 專家該怎麼做，才能成為一位負責的國際公民。
還是那句老話，只要我們繼續以《TechNet Magazine》建造豐富的媒體體驗，您的意見永遠都是我們重要的參考依據。來信請寄：tnmag@microsoft.com。
—Joshua Hoffman

感謝下列 Microsoft 技術專家： Ed Banti、Avronil Bhattacharjee、Nino Bilic、Mai-lan Tomsen Bukovec、Eric Charran、Elden Christensen、Trina Gorman、Scott Landry、Michael Murgolo、Sanjeev Nair、Hugh Pyle、Amritansh Raghav、Jez Sadler 以及 Jim Truher。


讀者來信 讀者有話直說

Active Directory 網域服務
2008 年 3 月號的《TechNet Magazine》我是百讀不厭，到目前為止大概看了不下 12 遍吧！尤其對於 Gil Kirkpatrick 所寫的＜Active Directory 網域服務中的新功能＞一文更是愛不釋手。Gil 在這篇文章中提到一個名叫 Microsoft® 稽核收集服務的產品。這個產品上市了嗎？它是獨立的應用程式嗎？
— Erasmo M.

Microsoft 稽核收集服務 (ACS) 是 System Center Operations Manager (SCOM) 的一部分，而這套管理軟體的前身是 Microsoft Operations Manager (MOM)。它並不是獨立產品，只是 SCOM 的一部分。
—Gil Kirkpatrick (NetPro 技術長暨《TechNet Magazine》作者

簽章
在 2008 年 4 月號《TechNet Magazine》的 Windows PowerShell 專欄＜請在此簽名＞technet.microsoft.com/magazine/cc434702) 的第二段當中，作者 Don Jones 說道：「簽章正是我要討論的技術名詞，不過這個用語本身並不能完全闡述它在本文中的用途。與合約或信用卡帳單不同，簽署指令碼並不表示您核准或授權它。」
我也認為簽署合約或信用卡帳單，並不表示您核准或授權那些項目。這個動作只有在較廣泛的環境層面才有意義。舉個例說，我年輕時都在我父親的管理站簽信用卡帳單 — 這種交易所欠下的債務根本不會有人來收帳。
但如果是在「妥善設定」的 Active Directory® 網路實作，簽章就是授權讓指令碼運作的幕後推手了。簽章的存在，表示簽署的人願意對他所簽署的事情負責，而且簽章的存在可能會引發更進一步的動作 — 例如，信用卡公司開立帳單，或者網路確認指令碼並非假冒。
請繼續加油 —《TechNet Magazine》對我們來說很有幫助。
—Jeremy P.

謝謝您的意見，Jeremy。看到我們讀者這麼關心《TechNet Magazine》的內容，真的很開心。

SharePoint Services
在什麼情況下，執行中的 Windows® SharePoint® Services (WSS) (而不是 Microsoft Office SharePoint Server)，對於透過網站介面/URL 存取它的使用者來說，是必須另外具備的 CAL 授權呢？
—Douglas M.

關於這個主題，有幾篇文章可以參考。下面就是一些有用的連結：msmvps.com/blogs/cgross/archive/2005/04/02/40723；microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx 和 windowsserver/sharepoint/bb684457。
—Pav Cherny (《SharePoint 內幕》和《TechNet Magazine》的專欄作家)

關於《SharePoint 內幕》的點子
我最近在 2008 年 5 月號的《TechNet Magazine》讀到一篇 SharePoint 專欄 (technet.microsoft.com/magazine/cc462809)。您在裡面希望讀者對於幾個主題提出建議。我覺得您可以撰寫一篇關於整合 SharePoint 和 Project/Project Server 的文章。
—Phil H.

Project/Project Server 的確是個很棒的點子！未來我們的專欄一定會考慮採用這個主題。感謝您寶貴的意見。

其他關於《SharePoint 內幕》的點子
您可以在網路上找到許多關於使用標準 SharePoint UI 或 SharePoint Designer 來自訂網站的文章，但卻鮮少能夠找到關於網站定義的文章 (就算有，內容也相當基本，對於現實世界的問題根本沒什麼幫助)。許多人才剛開始探索這個領域，因此那些基本指南只能幫助他們採用 SharePoint。尤其我們公司還曾經為了下列主題頭痛不已：
  1. 在網站定義中將自訂權限設定為清單。
  2. 網站定義中的自訂清單項目表單。
  3. 網站定義中的網頁組件連線。
  4. 要如何累加傳遞網站定義。
—Adam C.

謝謝您的意見。這正是我們在繼續開發這個內容時所需要的讀者意見。


工具箱 適合 IT 專家的新產品
Greg Steen

自動化管理工作
Automise 2
automise.com/automise.aspx
不加思索就能執行的例行工作很枯燥、費力而且容易出錯。自動化這一類的工作不僅是達成成功管理的關鍵，也可以提高工作滿意度。除了使用單調的批次檔案和自訂 VBScript 來自動化工作，還有一些適用於 Windows® 的巨集類公用程式，有幾個公用程式甚至會強迫您學習某種自訂指令碼語言。不過另外還有一個選擇：VSoft Technologies 推出的 Automise 2，它可讓您透過拖放及自訂樣式 GUI 來產生自動化例行工作。
此應用程式的介面很像簡單的程式設計 IDE，同時提供熟悉的選項。您可以使用工具箱將項目拖曳到設計工具介面，還有偵錯控制項可讓您逐步編寫程式碼，另外也提供不同專案、輸出執行記錄、歷程記錄及屬性視窗的檢視。不過就 Automise 而言，您的「程式碼」其實是以視覺化方式顯示自動化工作的工作流程。
Automise 的工具箱是由動作組成，這些動作分別會執行自動化程序中的單一步驟。應用程式包含 380 個動作，涵蓋了全範圍的可能操作，從建立 .zip 檔案到重新啟動 IIS 都包括在內。
設計工作時，您可以依階層方式建構這些動作的結構，藉此涵蓋您定期執行的許多系統管理程序。此外，您可以利用流程控制動作來連接您的動作，例如 try/catch 區塊、例外狀況引發、if-then-else 陳述式、迴圈、切換、延遲及非同步動作群組。
每個自動化專案也可以包含其他專案，好讓您區分主要的控制項流程與子工作。另外還有一些動作可操作字串和 XML 資料、設定變數、等待作業程序和命令，以及其他動作。有了這些控制項選項流程，再複雜的作業也能達到自動化的目標。
Automise 可讓您建立、執行、編輯和刪除排程工作。這表示您也可以使用 Automise 來管理現有的作業程序。因為篇幅有限，我無法列出所有動作，不過有一些動作值得一提：在全域組件快取 (GAC) 中登錄 DLL 的動作、重建 SQL Server® 索引、執行 chkdsk、編輯登錄、備份事件記錄檔、編輯 Active Directory® 使用者、掛接磁碟區、建立還原點，以及建立虛擬目錄。如果內建動作無法滿足您的需求，Automise 也提供自訂指令碼、命令以及臨機操作 SQL 執行動作。
總而言之，您可以隨心所欲地使用這個便利工具。如果您只是想找一個工具來自動化自己的 Windows 工作站，而非自動化網路基礎結構，不妨試試看 Automise Lite，Automise Lite 刪減了一些功能，不過仍然足以應付大部分進階使用者的需求。
價格： 單一使用者授權 $195 美元起 (直接售價)。
使用 Automise 2 以視覺化方式自動化工作 (按一下以放大影像)

即時監控記錄檔
BareTailPro
baremetalsoft.com/baretailpro
記錄檔啊，記錄檔，無所不在！不過真正麻煩的其實是使用記錄檔。應用程式產生交易記錄檔，這麼做的確很棒。但是除了使用記錄檔彙總工具以外，您要如何確實得知即時發生的事情？有一個解決方案就是 Bare Metal Software 經過千錘百鍊的 BareTailPro。雖然自 2006 年起就未更新，但這個簡單的公用程式依舊是強化的舊主控台 *nix 命令 'tail -f' 的 Windows 類比版本。
藉由單純的 GUI，您可以同時檢視任何大小的多個記錄檔，即時寫入這些記錄檔的作業都能一目了然。若要切換檔案，只要按一下索引標籤即可。還有一個很不錯的功能，就是每個索引標籤顯示一個圖示來傳達各個記錄檔的狀態，指出檔案是否正被寫入中，或「結尾」已經停止。
雖然大部分的應用程式都會寫入記錄檔，但是寫入記錄檔的方式往往大不相同。還好，BareTailPro 可以讀取 Unicode、UTF-8、ANSI 和 ASCII 檔案，也可以處理以 CR/LF 組合、單一 LF 和 Null 結尾的行數。您可以輕鬆地設定換行和定位擴充來取得特定記錄檔類型的最佳檢視。此外，您可以設定字型大小、類型、間距和行高以利閱讀記錄檔。
另一項很棒的功能就是應用程式的可設定醒目提示，您可以在記錄檔檢視上套用此功能。您可以以文字字串為基礎，設定數目不限的前景/背景色彩標示規則。比方說，您可以用紅色醒目提示錯誤部分，用黃色提出警告，也可以選擇醒目提示所有包含特定 IP 位址或主機參考的行。您可以檢視粗體或斜體的行，還可以選擇忽略文字字串的大小寫。
即使使用文字醒目提示，但繁雜的記錄檔仍會妨礙您的結尾檢視，使您很難鎖定要尋找的事件。BareTailPro 提供另一項輔助功能。規則運算式和文字搜尋功能可讓您快速精簡記錄檔檢視，將關心的列執行個體獨立成容易管理的子集。BareTailPro 使用的規則運算式語法是由 Java、Perl 及 PHP 使用的標準標記的子集所構成。假使您不熟悉其用法，產品網站有提供快速參考。
公用程式以表格格式顯示篩選後的結果，加入幾個有用的欄，例如時間戳記、行號，以及您在原始行來源定義的擷取群組結果。在篩選檢視中，這些欄也會經過排序。
取得我要的結果所用「神奇」規則運算式語法，我是永遠記不得。因此我真的很感謝此工具的模式儲存功能。它可讓您命名、編輯和儲存要重複使用的模式。當您在篩選檢視中取得重要列之後，BareTailPro 也讓您以訂製格式匯出結果到檔案或剪貼簿，以便設定每個結果欄的寬度、對齊、前置詞和後置詞。
更棒的是，這個小公用程式是包含在一個小型的可執行檔中，因此它不僅便於攜帶，而且對環境的影響也很小。請注意，若您只要檢視記錄檔，而不需要規則運算式篩選功能、儲存搜尋模式和匯出搜尋及篩選結果，您可能只要使用名為 BareTail 的免費版本就行了。
價格： 個別授權為 $35 美元起。
使用 BareTailPro 監控您的網路 (按一下以放大影像)

清查您的系統
Total Network Inventory
softinventive.com
為了達到成功的系統管理，快速存取有關整個環境中的電腦詳細資訊是關鍵的一環。這些資訊的試算表和廠商名單很難有效追蹤或保持完整性，而且很快會失去時效性。
若能使用動態工具在您需要時提供這些資訊，並收集安裝者、安裝項目以及執行的硬體類型等資訊，將會很有幫助。這類工具也提供一種很棒的方法來監控使用者在電腦上外加了哪些東西 (當然，前提是您的群組原則尚未限制安裝權限，或根據特定軟體套件的安裝針對您應有的授權數目記錄提供快速記錄)。符合此需求的一項工具就是 Softinventive Lab 推出的 Total Network Inventory。
安裝 Total Network Inventory 之後，您可以使用掃描 (Scan) 精靈來啟動清查程序，它會引導您進行網路中的節點探索。您可以選擇經由指定的 IP 位址或 [網路上的芳鄰] 電腦瀏覽來執行立即掃描，也可以使用登入指令檔掃描，好讓您在電腦登入網域時收集資訊。
Total Network Inventory 依賴 Windows Management Instrumentation (WMI) — IPC$\ADMIN$ 或 RPC/DCOM — 和典型的本機帳戶共用來執行掃描。因此您必須在系統管理員帳戶的身份下執行它。
一旦完成掃描，您就可以瀏覽電腦或搜尋特定電腦來清查其中的資產。Total Network Inventory 會將收集的清查資訊分組成三大領域：硬體、軟體和其他資訊。硬體部分包含有關處理器、主機板、晶片組、記憶體、視訊子系統、儲存體 (包含實體和邏輯裝置)、網路介面卡類型和設定、週邊設備，以及安裝在系統中的其他裝置的詳細資料。
軟體部分會提供 OS 資訊，包含產品金鑰、序號、系統目錄及已安裝的 Service Pack。還有關於 Hotfix (加上各自的知識庫文章編號) 和可能安裝的防毒與資料庫應用程式的詳細資料。接著您會取得一份已安裝程式的清單 (並附上 Program Files 目錄的檢視，好讓您查看標準 [新增/移除程式] 清單中可能隱藏的應用程式)，還有自動執行應用程式的清單。
最後，「其他資訊」部分會摘要系統環境的詳細資料，例如使用者和系統變數、共用資源、執行中處理序、安裝的服務以及本機使用者帳戶。
Total Network Inventory 確實能為您提供執行資產稽核、授權檢查、升級計算及效能評估的所需資訊。這項工具最棒的部分是報表產生器 (Report Builder) 元件。此功能提供您多份條理分明的詳細報表，從快速參考到稽核文件記錄，一應俱全。而且報表可以是彙總內容，也可以只針對單一電腦。有一項功能我覺得特別實用，那就是 [軟體和授權會計 (Software and Licenses Accounting)] 索引標籤檢視。它會顯示環境中安裝的各個軟體類型的彙總計數，以確保您遵循廠商合約。
價格： 25 個節點授權 $95 美元起。
掃描 (Scan) 精靈引導使用者進行網路節點探索 (按一下以放大影像)

書評
Mastering Microsoft Exchange Server 2007
sybex.com
無論您是否樂見，電子郵件都是營運順暢的組織的核心元件 (不過我承認有時我的確希望強制使用者先上一堂有效撰寫郵件的課程，然後才能使用電子郵件)。多年來，整合語音通訊、行事曆、資源排程、標準用戶端存取和郵件篩選 (用於垃圾郵件、病毒等等) 的需求已昭然若揭。這也正是 Microsoft® Exchange Server 2007 派上用場的時候。
最新版的 Exchange 以一套可擴充的健全解決方案緊密整合了所有這些元件。但是有了這麼多特性與功能，系統管理員、架構設計師和支援人員需要一些好的參考書來協助他們規劃、部署、管理及維護這個動態的電子郵件通訊解決方案。
在上一期的《工具箱》專欄中，我介紹了《Microsoft Exchange Server 2007 Administrator's Companion》一書。另一本值得一讀的參考資源就是 Barry Gerber 與 Jim McBee 合著的《Mastering Microsoft Exchange Server 2007》(Sybex，2007 年)。這本書的內容清楚易懂，可引導您了解整個 Exchange Server 生命週期。
本書的前三章是稱為＜認識與規劃 (Understanding and Planning)＞的章節，涵蓋了 Exchange Server 2007 的基本元件和實作需求。如果您熟悉舊版 Exchange，一定很高興看到在章節中也提到了不再受重視或實作的功能。而且大家也一定很感謝其中描述了構成 Exchange Server 2007 部署的各種伺服器角色和元件。如此複雜的伺服器部署當然需要一些事前考量，而且您應特別注意成長規劃、磁碟空間需求及 Active Directory 整合等章節。
下一節進入實際安裝部分，討論了全新安裝以及從 Exchange Server 2000 或 Exchange Server 2003 升級這兩種情況 (您無法直接從 Exchange Server 5.5 升級)。在此您也可以更清楚了解各部 Exchange 伺服器所能扮演的各種角色，包括 Edge Transport、Client Access、Hub Transport、Mailbox、Unified Messaging 和 Management Tools。
書中接著討論到延展性，示範如何監控效能、新增更多信箱儲存空間等等。在此，您可以探索很酷的全新本機連續複寫功能，它可讓您保持郵件儲存區的最新本機備份。萬一主要資料庫發生什麼意外，您可以迅速切換到備份，而無須從其他可用性較低和版本較舊的備份還原。
本書的下一節提供 Exchange Server 2007 部署中各種管理工作及工具的詳盡概觀。其中包括 Exchange 管理命令介面 (以 Windows PowerShell™ 為主) 和 Exchange 管理主控台 GUI (它也依賴 Windows PowerShell 引擎) 等工具。在本節中，您學會如何管理信箱、通訊清單和使用者帳戶。您也會讀到郵件記錄管理，以及管理郵件分類、日誌功能和傳輸規則。
第四節提供有關可用性和可靠性的深度資訊。現今的企業已經逐漸依賴電子郵件通訊，因此本節很值得一看。
在此您會學到負載平衡、伺服器備援、儲存區備援、網路備援和叢集的基本知識。您可簡單了解排程維護、執行備份和嚴重損壞修復案例的最佳作法 – 基本上，您需要知道的就是即使在發生問題時，也要維持公司電子郵件通訊系統的運作。
本書接下來的兩個章節討論到用戶端存取，包括 Microsoft Office Outlook® 2007、Outlook Web Access、IMAP 和 POP3。最後，本書結尾的章節對於 Exchange 系統管理員來說實在太重要了，它是關於安全性和稽核，示範基本的安全性作法與預防措施，還有供您使用的各種稽核工具。總之，這本深度剖析的參考書能加速您的學習，讓 Exchange 部署步上正軌。
價格： $49.99 美元 (直接售價)。

Greg Steen 是一位技術專家和企業家，為人十分熱心。他總是四處探尋新的工具，協助 IT 專家更輕鬆地進行操作、品管及開發。


公用程式焦點 Microsoft SharedView
Greg Steen

我常跟地球另一端的組員一起工作，因此常碰到一種情況，就是如果每個人都能在相同桌面上檢視及互動，那麼我們就能夠更有效率的表達和溝通意見。
假如您的業務小組外出工作，需要趕快聚一聚分享一下資訊、確認報價，並避免工作重複。想像一下，如果每個小組成員都能在幾乎同時的情況下檢視及編輯同一份 Microsoft® Office Excel® 試算表或 Word 文件，而非使用電子郵件傳送很快就無法同步的「流動文件」，這樣會提高多少生產力呀。現在有一個輕量型的共同作業工具剛好能提供這些功能 — Microsoft SharedView 1.0。
Microsoft SharedView 可讓您最多與 15 個人一起同時共用會議主持人的桌面，就好像您正在看著同一個桌面一樣。乍聽之下您可能覺得如果 15 個人同時控制同一個桌面，絕對只會導致一團亂，但實際上桌面控制是從一個成員傳遞給另一個成員。
當您負責控制時，您可以看到共同作業者的滑鼠動作 (每個人都有個人化指標)，好讓他們指出文件或應用程式上的項目。可惜，SharedView 並未整合語音功能，不過您可以在共用桌面的同時，使用 Windows Live™ Messenger 的音訊用戶端或是您喜愛的 Voice over IP (VoIP) 用戶端來進行會議。
Microsoft SharedView 可讓您同時共用會議桌面 (按一下以放大影像)
SharedView 的安裝方法很簡單，而且即使使用者在技術方面不怎麼精通，用戶端也可以很快憑藉直覺來安裝和執行 SharedView。使用您的 Windows Live 帳戶登入之後，就可以按幾下來啟動 SharedView 工作階段。加入工作階段同樣也很簡單；只要輸入您要連接的工作階段名稱 (通常是主持人的 Live ID) 和密碼就行了。邀請函是經由電子郵件來傳送，或是將產生的邀請內文貼至 IM 用戶端。
SharedView 內的其他選項包括啟用或停用遠端複製和貼上 (可讓工作階段使用者從本機工作站加入文字到主持人的電腦)；直接啟用 Word 中的追蹤變更，以便檢視與會者如何變更共用文件；還有明確的封鎖清單以阻止特定的 Windows Live ID 加入。此應用程式也包含很酷的講義功能，可讓您提供補充檔案給工作階段與會者；在每個工作階段中，您最多可以提供 25 個檔案或總計 200MB 的檔案。
此外，您可以向與會者輸入廣播訊息，這些訊息會顯示在連線工作階段的上方。如果您願意的話，還可以選擇共用所有內容，要是您想要在進行會議時保留一些隱私，您可以從主機電腦迅速且輕鬆地啟動及停止共用視窗。總之，若您想找快速又簡便的共同作業工具，Microsoft SharedView 能滿足您的需求。
若要開始，請直接到 TechNet Magazine 網站的「程式碼下載」區段下載 Microsoft SharedView，網址為 technetmagazine.com。

Greg Steen 是一位技術專家和企業家，為人十分熱心。他總是四處探尋新的工具，協助 IT 專家更輕鬆地進行操作、品管及開發。


SharePoint 內幕 整合 Office 應用程式
Pav Cherny

目錄
Office 應用程式整合
擴充 SharePoint UI
使用 Office OpenDocuments 控制項
與 SharePoint 通訊
實作自訂 OpenControl 解決方案
總結
Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 與 2007 Microsoft Office System 中的桌面應用程式之間的完美整合，使得文件、試算表、行事曆、連絡人資訊等方面的共同作業更具效率。事實上，整合程度之密切，
您可以稱 2007 Office System 為統一辦公解決方案平台。
這對於把焦點放在 Microsoft® Office 技術上以提升資訊工作者產能的公司來說，無疑是一大福音。然而，擁有多樣 Office 應用程式組合的公司卻無法享受同等級的現成互通性。2007 Office System 雖提供必要的整合功能，但其介面和元件的記載鮮少，而且無法在所有情況下運作。這使得協力廠商難以將 SharePoint® 技術整合到他們的應用程式，對他們的客戶來說，更難提供資訊工作者統一的體驗。
在本專欄中，我將向您說明 Office 應用程式如何與 SharePoint 整合和通訊，以及如何依照相同的原則將非 Microsoft 應用程式與 SharePoint 相整合。不過首先，我將簡短討論一下達成完美整合所用的伺服器組態設定、用戶端元件，以及通訊協定。
這些細節都釐清之後，我會著手整合不具內建 SharePoint 支援的應用程式。這麼做的時候，我會一改往常把重點放在實作 IFilter 元件來擴充搜尋功能，以及在 SharePoint 伺服器上新增自訂圖示的作法，將層次往上提升。擴充搜尋並以適當的圖示傳回結果並不能達成完整的應用程式整合，使用者可能還想從 SharePoint 使用者介面內部直接開啟這些文件。
此時事情就比較複雜。您需要有一個用戶端元件，只在工作站上有部署 Office 的時候可用。但即使您已部署 Office，可能還是會發現這個元件運作起來並不穩定，視 SharePoint 網站拓樸和設定而定。
為了解決這個問題，我建立了一個自訂解決方案，讓您不需要部署 Office，就能整合任何應用程式，例如記事本、Adobe Reader 或 Autodesk AutoCAD。這套自訂解決方案也闡明了在某些情況下，為什麼根據標準 Office 元件進行應用程式整合會失敗。您可以在本專欄隨附的資料 (可自網站上的「程式碼下載」區段取得) 中，找到這套解決方案，以及部署和設定的逐步指示。

Office 應用程式整合
從使用者的觀點來看，SharePoint 功能表運作的方式似乎跟 Windows® [開始] 功能表很像。在文件庫中建立新文件很簡單：只要依序按一下 [新增]、[新增文件]，Microsoft Office Word 2007 便會啟動。編輯現有的文件也很直接了當。將滑鼠停駐在文件上，開啟 [編輯控制項方塊 (ECB)] 下拉式功能表，然後在 Word 中按一下 [編輯]。您可能很難想像，您是從網頁透過 JavaScript 開啟 Word 2007；從本機執行應用程式，但文件其實位於遙遠的 SQL Server® 資料庫中，網頁伺服器是存在資料存取路徑內，如 [圖 1] 所示。
[圖 1] 在 SharePoint 中使用 Word 文件 (按一下以放大影像)
儘管複雜，使用者在裝有 2007 Office System 的 Windows 工作站上的體驗仍舊相當順暢。在 SharePoint 文件庫中使用文件就跟使用本機檔案或網路共用上的檔案沒什麼兩樣。
不過，如果是不含 Office 2003 或 2007 Office System 的 Windows 工作站，UI 會稍有不同。按一下 [新增文件] 或 Word 中的 [編輯] 只會顯示一個對話方塊，告訴您 Windows SharePoint Services 相容的應用程式無法使用。
這種情形不難預料，要提供讓 Office 使用者滿足的體驗，必須搭配幾項要素。SharePoint 必須知曉文件庫當中所維護的內容類型，以便在 [新增] 和 [ECB] 功能表中呈現所要的命令。為了回應在這些命令上進行的滑鼠點按動作，JavaScript 程式碼必須執行以啟動相關聯的應用程式，將路徑傳送給文件。這個部分跟工作站設定息息相關，因為 JavaScript 程式碼是在本機執行。再者，相關聯的應用程式必須與 SharePoint 通訊，才能讀取，甚至可能寫入檔案。如果您想要將應用程式與 SharePoing 整合，這些都是您必須統合的要素。
另一方面，SharePoint 與資料庫伺服器之間的通訊並不會影響應用程式，也不會左右網頁伺服器上的索引處理程序，以加速搜尋作業。有鑑於此，我將不在本文中進一步討論這些層面，但是建議您查閱 Microsoft 知識庫文章＜如何註冊 Microsoft 篩選器套件與 Windows SharePoint Services 3.0＞ 裡面記載的 Microsoft 篩選器套件，網址是 support.microsoft.com/kb/946338。現在讓我們把注意力放在新增命令、實作必要用戶端元件，以及加速應用程式通訊等作業。

擴充 SharePoint UI
擴充 SharePoint 使用者介面和功能有眾多的選項可用。您可以變更網站的設計，自訂 ASP.NET 網頁，開發網頁組件，或是變更內含在 WSS 和 MOSS 的 JavaScript 程式碼以直接啟動應用程式。
您也可以在文字編輯器內開啟 Ows.js 檔案 (您可以在 SharePoint 前端伺服器上的 COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 資料夾中找到這個檔案)，以及變更 createNewDocumentWithProgIDCore、editDocumentWithProgIDNoUI 和 DispDocItem 函數運作的方式。但是有一個比較妥當的方法，讓您不需要以不受支援的方式變更 WSS 程式碼基底：使用內容類型和文件類型對應。
在敝作＜透過自訂內容類型將資料管理標準化＞中 (請參閱 2008 年 2 月號《TechNet Magazine》，網址是 technet.microsoft.com/magazine/cc194408.aspx)，我說明了如何建立全域和網站特定內容類型，來管理 SharePoint 文件庫與清單中的文件和其他內容。您也可以參閱本文隨附資料中的工作表 Text Content Type.pdf，當中有說明如何針對 .text 檔案建立新內容類型，以及建立此內容類型與文件庫的關聯。結果就跟您可以針對 Word 文件選取 [文件] 命令一樣，您也可以從 [新增] 功能表選取 [文字內容] 命令 (見 [圖 2])。
[圖 2] SharePoint UI 中的自訂內容類型 (按一下以放大影像)
ECB 功能表也同樣可擴充。您可能預期 ECB 功能表也應該能夠感知內容類型，但目前的 WSS 版本並不是依這種方式來實作此功能表。您反而必須在 Docicon.xml 註冊您的文件類型，您可以在每部 SharePoint 前端伺服器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml 資料夾中找到這個檔案。
比方說，透過將下列文件類型對應加入 Docicon.xml 的 <ByExtension> 區段，您可以使 SharePoint 顯示 [在記事本中編輯] 命令 (詳細指示，請參閱 Text Content Type.pdf 檔案)。
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Key 參數可識別副檔名，Value 參數定義著要顯示在使用者介面中的文件圖示，EditText 參數定義著 SharePoint 附加到 [在...中編輯] 命令的字串，而 OpenControl 參數可指定用戶端 COM 元件的 ProgID。這是 SharePoint JavaScript 函數傳送到 ActiveXObject 呼叫以產生 COM 物件的 ProgID (詳細資訊，請參閱 Ows.js)，這個物件可以是應用程式本身，或是根據相關檔案類型啟動應用程式的協助程式控制項。
SharePoint 產品和技術網站

  • SharePoint 產品和技術網站
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services Developer Center
  • Microsoft SharePoint 產品和技術小組部落格
您應該要注意，稱為 SharePoint.OpenDocuments 的 OpenControl 指的是隨最新 Office 版本 (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll) 一同發行的 ActiveX® 控制項。如果您的工作站上存在這個檔案，而且指定的文件圖示 (Value 參數) 也位於 SharePoint 伺服器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images 資料夾內的話，您可能已經完成大部分必要的整合工作。
Windows SharePoint Services 3.0 SDK 包含一些關於隨 2007 Office System 一同發行的用戶端 API 的資訊，包括 OpenDocuments 控制項。請參閱「用戶端 API 參考資料」一節，網址是 msdn2.microsoft.com/ms440037。

使用 Office OpenDocuments 控制項
OpenDocuments 控制項解決了最不可少的應用程式整合需要，但是它要求安裝 Office 2003 或 2007 Office System，而且它的功能有限。[新增] 功能表上的命令不一定都可用，而且它們有時候會顯示可能會誤導使用者通知的內容。
如 [圖 3] 所示，OpenDocuments 控制會通知使用者必要的應用程式安裝不正確，或是無法開啟範本檔案，但其實不然。「在...中編輯」功能也有問題。您會常看到顯示在 [圖 3] 前景中的第二則錯誤訊息。這是我最津津樂道的，因為連 SharePoint 專家也會被它誤導，不過我稍後會詳細說明這點。
[圖 3] OpenDocuments 控制項的誤導錯誤訊息 (按一下以放大影像)
儘管如此，OpenDocuments 控制項在所有工作站上都裝有最新版的 Office 的環境內還是相當有用。此外，您還可以在 [新增] 功能表上隱藏內容類型 (顯示 [文件庫設定]，按一下 [變更新增按鈕順序與預設內容類型]，然後取消勾選上述所有內容類型的 [可見] 核取方塊)，如此一來，使用者就不會遇到第一則錯誤訊息。您也可以簡化網站拓樸，以避免產生網頁導向分工編寫及版本管理 (WebDAV) 通訊問題，這可消除第二則錯誤訊息。

與 SharePoint 通訊
到目前為止，我設法擴充了 SharePoint UI，或許也利用了 OpenDocuments 控制項啟動應用程式，但是我的應用程式仍舊需要一種途徑與 SharePoint 通訊以存取資料。不用說，SharePoint 支援多種方法讓您這麼做，例如 Microsoft Office FrontPage® Server Extensions、WSS 遠端程序呼叫 (RPC)、WebDAV 和 Web 服務。事實上，視您要如何存取文件而定，例如透過 Web 資料夾、對應的網路磁碟機，或是 SharePoing UI，Office 應用程式 (例如 Word 2007) 可能會使用當中任一或所有的通訊方法。
SharePoint 用戶端/伺服器通訊方法各自都依靠 HTTP 作為基礎通訊協定。舉例來說，FrontPage 和 WSS RPC 全都使用在 ISAPI 擴充程式導向的 HTTP POST 和 HTTP GET 要求，這個擴充程式是位於 SharePoint 伺服器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI 資料夾及其子資料夾內。
其中一個最重要的 ISAPI 擴充程式是 Owssvr.dll，除了其他項目之外，它還會實作與清單和文件庫搭配運作的功能。[圖 4] 顯示 Word 2007 中的 SharePoint [另存新檔] 對話方塊 (左邊)，以及透過 URL 要求 http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx 直接開啟的瀏覽器 (右邊)。兩種案例之間的相似性顯而易見。
[圖 4] Word 2007 中與 Internet Explorer 中的 SharePoint [另存新檔] 對話方塊 (按一下以放大影像)
其他重要的 ISAPI 擴充程式還有 Author.dll，它會實作 FrontPage 和 WSS RPC 以進行用戶端編輯作業，例如上載、重新命名和刪除文件；Admin.dll 可用於管理網站和執行其他各種系統管理工作；以及 Shtml.dll 可用來支援 HTML 表單提交。
一般來說，若不能存取原始程式碼，要在現有應用程式 (例如記事本或 Adobe Reader) 中加入 FrontPage 和 WSS RPC 支援是不可能的。但是您可以透過 Windows 中內含的網頁用戶端功能，提供必要的通訊設備。
SharePoint 也透過 Httpext.dll 支援 WebDAV，這個檔案位於 %WINDIR%\System32\Inetsrv\ 資料夾內，但我們還是把話題放在用戶端上。執行 Windows Server® 2008 或 Windows Vista® 的電腦預設都會安裝網頁用戶端功能。在控制台中的 [系統管理工具] 內，您可以在 [服務] 小程式裡面找到相對應的 WebClient 服務。在 Windows XP 和 Windows Server 2003 上，您必須明確地安裝網頁用戶端。無論是哪一種情況，都請確定 WebClient 服務已啟動，而且 [啟動類型] 是設為 [自動]。
[圖 5] 描述的是網頁用戶端的架構。WebClient 服務是在服務控制管理員於 Svchost.exe 主機處理序中載入的使用者模式 DLL 中 (Webclnt.dll) 實作。Webclnt.dll 提供網路提供者介面以進行非 I/O 作業 (例如驗證使用者以存取 WebDAV，將 SharePoint 網站掛接成網路磁碟，將 SharePoint 網站、清單和文件庫列舉成網路資源，以及中斷掛接的磁碟)。
[圖 5] WebDAV 用戶端重新導向器架構 (按一下以放大影像)
為了執行這項工作，Webclnt.dll 會與提供實際重新導向器功能的核心模式檔案系統驅動程式通訊。WebDAV 用戶端重新導向器驅動程式 (Mrxdav.sys) 是以 Redirected Drive Buffering Subsystem (RDBSS) 為基礎，這個子系統會與 I/O 管理員和其他核心元件整合，以便提供遠端檔案系統的服務。Mrxdav.sys 會實作 WebDAV 通訊設備以支援對 SharePoint 網站和文件庫的檔案系統層級存取。
能夠透過網路重新導向器存取 SharePoint 網站和文件庫，使用者應用程式中就不用 FrontPage 和 WSS RPC 支援。您可以將網路磁碟機對應到文件庫 (例如 net use x:http://wss/doclib/Shared%20Documents)，而且您可以透過 UNC 路徑存取 SharePoint 資源。
URL http://wss/doclib/Shared%20Documents 會對應到 \\wss\doclib\Shared%20Documents。因此，您可以選擇是否要在應用程式中開啟文件。比方說，您可以使用 HTTP 路徑 http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt 或是 UNC 路徑 \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt，在記事本中開啟文件。
不幸的是，網頁用戶端功能有幾項限制。您無法存取自訂屬性或是使用自訂 TCP 連接埠的 Web 應用程式。若是使用者不能存取階層中的上層網站，隨 Windows Vista 一同發行的網頁用戶端也會失敗，如 WebDAV Access.pdf (請參閱附隨資料) 所示。
路徑 http://sharepoint/HR/Administration/Shared%20Documents/ 包含一個非現有的根網站 (也就是 http://sharepoint)，但是若不能存取根目錄，網頁用戶端便無法判斷網頁伺服器的功能。網頁伺服器會拒絕網頁用戶端的 OPTIONS 要求，並產生狀態碼 401，表示存取未經授權，因此網頁用戶端會繼續提示輸入使用者認證，如 [圖 6] 所示，即使使用者對網站集合 sharepoint/HR 及當中所有網站具備系統管理存取權也一樣。
[圖 6] 不成功的 WebDAV 存取 (按一下以放大影像)
當使用 OpenDocuments 控制項時，如果網頁用戶端無法開啟文件，您會收到 [圖 3] 中所示的錯誤訊息。應用程式可以使用，而文件類型對應也正確。無法透過 WebDAV 重新導向器存取的其實是文件。

實作自訂 OpenControl 解決方案
一般而言，要解決網頁用戶端的缺點，您有兩個選擇。您可以等 Microsoft 提供新版的網頁用戶端，或者您可以實作自訂的 OpenControl 解決方案來解決目前的狀況。實作自訂 OpenControl 並不是一項簡單的工作，但這麼做工作站上就不用安裝 Office，除了 [在...中編輯] 命令之外，它還可讓您有意義地處理 [新增] 命令，而且它也容許您處理網頁用戶端失敗時的情況。
如果這些是您所關注的問題之一，不妨看看隨附資料中所含的 AppStart 原始程式碼。當中說明了如何在 SharePoint JavaScript 程式碼可以呼叫的 Microsoft .NET Framework 組件中公開 OpenControl COM 介面。AppStart 原始程式碼也示範了檢查檔案存取性，以及不能透過 WebDAV 直接存取時，經由 HTTP 將檔案下載到本機電腦的可行方法。最後，AppStart 原始程式碼還回應 [新增] 命令，它將內容類型相關的範本下載至本機電腦，讓使用者可以開始使用文件。工作表 Text Content Type.pdf 和 Adobe Reader Support.pdf 則概述了如何部署此 OpenControl 解決方案。
[圖 7] 中所示的圖表顯示了 AppStart 架構。我的自訂 OpenControl 元件 (叫做 Biblioso.dll) 公開兩個一模一樣的 COM 介面，SharePoint JavaScript 會呼叫這些介面來建立新文件或開啟現有文件以利編輯 (Biblioso.AppStart.2 和 Biblioso.AppStart.3)。
[圖 7] AppStart 架構 (按一下以放大影像)
若文件處於開啟狀態以供編輯，且檔案是直接透過 WebDAV 存取時，Biblioso.dll 會確認檔案確實存在，並循著文件的路徑啟動相關的應用程式。如果檔案不可存取，Biblioso.dll 便會啟動跨處理序 COM 伺服器，此伺服器接著會載入 OpenDocsUtility.dll 以透過 HTTP 下載檔案，並循著下載文件的路徑啟動應用程式。
跨處理序 COM 伺服器可讓解決方案與 Internet Explorer® 處理序分隔，因為這個處理序會限制以保護模式下載至 Temporary Internet 資料夾。使用者必須能夠在沒有保護模式的限制下下載檔案，而作為應用程式代理人的跨處理序 COM 伺服器提供了這種可能性。
.NET 中並不支援開發跨處理序 COM 伺服器，因此我針對這個可執行檔切換到 C/C++。我只以 C++ 實作了最精簡的 [另存新檔] 對話方塊。為了讓解決方案盡可能直接明瞭，並且降低開發負荷，我將實際的下載程式碼放在 .NET 組件中 (OpenDocsUtility.dll)，然後透過其他 COM 介面呼叫這個組件。
為了使部署作業更具效率，我在解決方案中加入了一個安裝程式專案。另外，安裝程式常式還會註冊所有 COM 元件，並將應用程式特定設定寫入 HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart。最重要的參數是 AllowedApps 和 AllowedFileTypes。AppStart 解決方案只能與您在這些參數中明確指定的那些應用程式和檔案類型搭配運作。
安裝程式常式也會針對跨處理序 COM 伺服器建立提升權限原則，這樣一來，Internet Explorer 處理序中的 Biblioso.dll 就可以啟動 AppBrokerEngine.exe 而不會觸發安全性警告。如果您有興趣進一步了解 Internet Explorer 保護模式，以及如何在應用程式開發中處理保護模式，我強烈建議您閱讀 Marc Silbey 和 Peter Brundrett 合著的＜了解和使用保護模式 Internet Explorer＞(英文)，網址是 msdn2.microsoft.com/bb250462。
當分析 AppStart 元件時，記住這套解決方案是為了示範可能的用途而開發的，它還不適合用於生產環境。除了原始程式碼註解之外，我們並沒有足夠的時間將程式碼最佳化，以及徹底測試解決方案，或是記錄各項功能。
您應自行承擔使用此解決方案的風險。如果您有興趣研究原始程式碼來建立您自己的解決方案，可從 Biblioso 程式碼專案中的 AppStart.cs 開始著手。這個檔案會實作 OpenControl COM 介面和進入點，供 JavaScript 從 Ows.js 呼叫。
總結
WSS 3.0 和 MOSS 2007 提供了廣泛的應用程式整合功能，讓使用者在 SharePoint 文件庫和清單中使用文件和其他項目時擁有順暢的體驗。2007 Office System 中的桌面應用程式鮮明地展示了這種可能性，而且非 Office 應用程式也可以達成相同等級的整合性和使用性。
應用程式整合架構的核心是 COM 元件，SharePoint JavaScript 函數正是使用它循著文件路徑來啟動應用程式。2007 Office System 提供當中幾個 COM 元件，針對特定 Office 應用程式需求來最佳化，不過您也可以重複使用 Office OpenDocuments 控制項來整合非 Microsoft 應用程式。OpenDocuments 控制項能滿足最基本的需要。對於比較進階的應用程式整合需求，您可以實作自訂控制項。
將應用程式與 SharePoint 完全整合不僅需要安裝 IFilter 元件和文件圖示來擴充搜尋和顯示功能而已，還必須在 SharePoint 伺服器上建立自訂內容類型和文件類型對應，以便在 SharePoint 使用者介面中提供適當的 [新增] 和 [在...中編輯] 命令。這些命令會呼叫 JavaScript 函數，這些函數會叫用透過 OpenControl 元件公開的方法。工作站上也必須提供 OpenControl 元件。
另外一個重要的要素是網頁用戶端，在 Windows Vista 上預設會包含並安裝網頁用戶端。網頁用戶端會實作 WebDAV 重新導向器和遠端檔案系統驅動程式，讓任何應用程式都能夠存取類似於網路上的檔案共用的 SharePoint 清單和文件庫內的資源。雖然隨 Windows Vista 一同發行的網頁用戶端有其缺點，但它在應用程式整合中還是扮演著舉足輕重的角色。
WebDAV 支援也消弭了在非 Windows 工作站上執行的應用程式與 SharePoint 之間的落差。這些作業系統上一般都沒有提供 COM 和 ActiveX 控制項技術，因此您無法使用 OpenControl 元件自動啟動應用程式，但大多數作業系統都包含 WebDAV 重新導向器，至少可以讓使用者直接存取文件庫中的文件，而不用將檔案下載到本機工作站。
WSS 3.0 和 MOSS 2007 都是 2007 Office System 成就的基石，而以 Office 為基礎的協力廠商應用程式的使用者也都可透過相同的方式從 SharePoint 中受益。整合功能所達的範圍遠遠超越 Office。藉著充分利用 SharePoint，您能夠建置一套統一辦公解決方案平台，為 Office 和協力廠商軟體提供相同的使用者體驗，藉此促進資訊工作者的產能。

Pav Cherny 是 IT 專家兼作者，專攻 Microsoft 共同作業與整合通訊技術。他的出版品包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。同時 Pav 也是專營管理文件與本土化服務之 Biblioso Corporation 的總裁。

© 2008 Microsoft Corporation and CMP Media, LLC.著作權所有，並保留一切權利。未經許可，不得部分或全部重製


Windows PowerShell 投遞箱
Don Jones

目錄
扮演指令程式
篩選函數
實際設想
實際的應用程式
挪出時間玩耍
在我教授的最近一場 Windows PowerShell 課堂中，我發現有些學生不太能夠意會命令介面的管線。我承認管線並不是很直觀的概念，因此視覺學習者很難發揮想像力。當我開始談到
篩選函數的概念時，因為它是直接在管線裡面運作，所以更是亂成一團，光從一些臉部表情就能看出好幾個人似懂非懂。
為了推他們一把，我隔天準備了一只箱子、一些名牌貼紙和一些乒乓球 (嘿，誰說 Windows PowerShell® 都很沉悶的)。我決定使用下列命令列做些示範：
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

扮演指令程式
使用名牌貼紙 — 就是在同學會以及類似的討厭聚會中，被迫戴上的「大家好，我叫…」貼紙 — 我為每一個學生分別指派一個指令程式名稱。我先解釋乒乓球代表 Windows® 處理物件 (更具體的說，是 System.Diagnostics.Process 型別的物件)，然後要求學生告訴我，哪一個指令程式名稱聽起來比較可能會產生處理物件。
他們張望著彼此的名牌，勉強猜出 Get-Process 這個明顯的選擇。這也是為什麼我這麼喜歡 Windows PowerShell 中所用的指令程式名稱的主要原因之一：它們通常都很明顯易懂。
所以扮演 Get-Process 的學生拿了所有的乒乓球，把它們全都丟到紙箱中。紙箱是代表命令介面的管線，而這名學生所做的動作，差不多就是指令程式所做的。指令程式會產生一或多個物件，然後把它們傾印到管線中。
接下來就由管線中的下一個指令程式接手。在本例中，代表 Where-Object 指令程式的學生拿起所有的乒乓球一一檢查，看看這些乒乓球的 VM 屬性是否大於 1,000。在命令介面中，「VM」是指虛擬記憶體，而且為了這次練習，我在每個乒乓球上以馬克筆寫了不同數量的虛擬記憶體。
VM 值大於或等於 1,000 的乒乓球 (也稱為處理序) 全部放回紙箱 (有時候稱為管線)，而 VM 值比較小的則被丟到垃圾筒裡面，一去不復返 (沒啦，我把它們全部救起來，準備在以後的課堂上使用)。
接下來，扮演 Sort-Object 的學生逐一檢視整箱的乒乓球，然後根據它們的 VM 屬性把它們一一排好。我自認這部分的練習考慮不夠周到 — 因為要讓乒乓球不到處滾動實在需要一點技巧！看來下一堂課我得使用乒乓球隔間，不然就是使用蛋裝盒。
最後，飾演 Export-CSV 的學生拿起球，把資訊寫出到 CSV 檔案。在真人演繹的課堂上，這位扮演指令程式的學生，把處理序的屬性寫在假扮 CSV 檔案的簡報用紙板上。

篩選函數
講解完簡單的管線之後，我們決定探討稍微複雜的篩選函數。我提出的篩選函數和命令列如 [圖 1] 所示。
[圖 1] 範例篩選函數和命令列
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
首先，我想迅速討論一下篩選函數應該具備什麼作用。這個函數包含三個指令碼區塊，分別名為 BEGIN、PROCESS 和 END。
當它用在管線時，會先執行 BEGIN 指令碼區塊。這個指令碼可能會進行任何設定工作，例如開啟資料庫連接。
接下來，PROCESS 指令碼區塊會針對每個輸送到函數的物件各執行一次。在 PROCESS 指令碼區塊內，$_ 變數會自動填入目前的管線物件。所以，如果輸送 10 個物件，PROCESS 指令碼區塊便會執行 10 次。
最後，當所有輸送進去的物件全部執行完畢後，便開始執行 END 指令碼區塊，並且進行所有必要的清理工作，像是關閉資料庫連接。
在這些指令碼區塊中，所有使用 Write-Output 寫入的東西都會留在管線中，供下一個指令程式使用。而沒有使用 Write-Output 寫入的東西則全部捨棄。
由於我們是以 Get-Process 命令開頭，因此扮演這個命令的學生便把所有的乒乓球撿拾起來 (我們只不過稍微休息片刻，球便在整間教室被丟得到處都是 — 想也知道)，全部丟到管線箱裡面。她的工作結束之後，就由扮演「Do-Something」篩選函數的學生接手。
他先執行他的 BEGIN 指令碼區塊。因為是空的，所以不費吹灰之力。接著他拿起所有的管線物件 (乒乓球)，一次查看一個。這就有點好玩了，因為算算總共有一打的球，全都要放在大腿上 — 您得在場才能體會。
總之，他一次拿起一個處理物件，然後執行他的 PROCESS 指令碼區塊。那個指令碼區塊幫他建立了一個全新的自訂物件 (我特別使用黃色乒乓球，因為這在當地的運動用品店都買得到)。他在這些新的乒乓球上，除了寫上目前正在查看的處理物件名稱外，也寫上目前的日期和時間。
接著這些新的自訂物件會寫入管線中，因此他把黃色的乒乓球放入紙箱，而把原始的處理物件乒乓球丟掉。紙箱中的每一個處理物件乒乓球都要進行這項作業，總共約 12 次。大功告成之後，所有的白色乒乓球便全部換成黃色的自訂物件乒乓球。最後再執行 END 指令碼區塊，這也是空的，所以沒花什麼時間。
總結部分是由 Format-Table 學生負責。她拿起紙箱中所有的東西 (目前為止全都是黃色「自訂」物件)，開始以每個球上所寫的兩個屬性來建構資料表。最後得出一份寫在簡報用紙板上、內含兩個資料行 (TimeStamp 和 ProcessName) 的資料表，約有 12 個資料列。

實際設想
這項練習讓課堂裡面的每個人徹底瞭解了管線和篩選函數。以乒乓球代表物件這一招的確很成功，因為命令介面有點抽象，所以非常適合。
每個人都看得到指令程式如何操控這些物件、如何將結果放到管線中，還有下一個指令程式又是如何取得這些結果，然後進一步操控物件。連續事件在篩選函數的成效更是顯而易見，這都要拜 PROCESS 指令碼區塊一次處理一個輸入物件的方法所賜。
這也讓大家看到建立新自訂物件以及將新物件放入管線的方式。另外，與簡單文字相較之下，此舉也彰顯了產生自訂物件的優點 — 因為其他指令程式都可以取用新的自訂物件 (例如 Format-Table)，為資料的運用和呈現提供了很大的彈性。

實際的應用程式
學生最常提出的問題是，如何將我們剛剛示範的管線和篩選函數，應用到實際的應用程式。這對我來說不難回答，因為我最近才剛為幾場研討會製作了幾個範例 (您可以自己下載範例，網址是 scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples)。
其中一個範例的目的，是列出幾部電腦上 Windows Management Instrumentation (WMI) 中的 Win32_UserAccount 類別的幾個屬性。假設電腦名稱是列在 C:\Computers.txt 中，這個簡單的命令就可以一手包辦：
Gwmi win32_useraccount –comp (gc c:\computers.txt)
但問題是 Win32_UserAccount 類別並不包含可以告訴您每個執行個體是來自哪個電腦的屬性，因此您所得到的只是混入許多電腦帳戶的無用清單。我的解決方法是建立一個包含來源電腦名稱的新自訂物件，並且選取我感興趣的類別屬性。這個自訂物件的程式碼如 [圖 2] 所示。
[圖 2] 使用自訂物件收集電腦名稱以及選取屬性
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
最後一行命令列會將所有電腦名稱全部傳遞到篩選函數，此函數會產生自訂物件。接下來，我把 PasswordRequired 屬性不是 False 的使用者全部篩選掉 (目的是要產生一份問題帳戶的稽核報告)，只保留 Computer 和 Name 屬性，所以最終報告所列的是，因為沒有過期密碼而需要留意的電腦名稱和帳戶名稱。篩選函數能製作出這樣的多電腦報告，是因為可以把來源電腦名稱加到輸出當中，同時能把屬性精簡成我只想查看的屬性。
雖然還有其他類似的方法可以完成這樣的工作，但是這個方法可能是最簡單明瞭的了。它另外也闡明了重要的概念和技巧。

挪出時間玩耍
即使您已經摸熟管線，但還是有些教訓要謹記在心。利用實體物件來思考可幫助您理清目的。
所以下次您再想不透某個 Windows PowerShell 概念時，不妨將電腦暫撇一邊，以日常物件作為例子，重複同樣的工作。我誠懇的建議您，為了這個用途，還是保留一小袋乒乓球吧 (如果找得到的話，也可以用立方塊代替)。
本月指令程式：Out-File
您是不是常使用 > 符號把指令程式的輸出導向檔案？像是 Get-Process > Processes.txt。您可知道您其實是假裝使用 Out-File 指令程式的嗎？下面是執行相同功能的命令：Get-Process | Out-File Processes.txt。
沒錯，是得多打幾個字，可是何苦要打出完整的 Out-File 指令程式呢？其中一個理由是 Out-File 讀起來要清楚得多。比方說，六個月後要是有人查看您的指令碼，可能會納悶 > 指的是什麼 (它畢竟是有點過時的用法)。
相反地，Out-File 就很明顯的表示即將建立和寫入檔案。另外，Out-File 還提供 -append 參數 (就是 >> 啦)，還有 -force 和 -noClobber 參數，讓您控制是否要覆寫現有的檔案。最後一點，打出完整的 Out-File 還可以存取 -whatif 參數。這個實用的參數只會告訴您 Out-File 的作法，但不會實際進行。這個方法不但可以測試複雜的命令列，而且沒有任何危險，可說是相當不錯的方法。
影片
觀看 Don Jones 實作操作這些指令程式。

Don Jones 是《Windows PowerShell:TFM》的作者之一，並且負責教授 Windows PowerShell 課程 (www.ScriptingTraining.com)。


嗨，Scripting Guy！ 快感
Microsoft Scripting Guy

毫無疑問的，在我們心目中，為《TechNet Magazine》撰寫文章可說是最高尚，而且回報最多的一項工作了 (當然囉，如果我們真的有薪水可拿的話，那回報就更多了，不過這是題外話啦)。話說回來，這份工作到底有多崇高呢？我不妨這麼說吧：現在全世界躺在被窩裡準備睡覺的小孩，都會抬頭看著媽媽說：「媽咪，等我長大後，一定要每月幫《TechNet Magazine》寫一篇指令碼專欄。」就是這麼高尚。
附註當然嘍，世界各地也有人相信這篇專欄其實根本是兒童寫的。不過這又離題了，暫且不談)。
大家都知道，Scripting Guy 很享受來自各方對於我們幫《TechNet Magazine》撰文所給予的讚美；甚至已經懂得如何應付那些爭相索取親筆簽名的粉絲還有狗仔了。不過我們從事這份工作可不是為了榮譽和面子，而是為了享受撰寫系統管理指令碼所帶來的快感。
的確，「快感」和「系統管理指令碼」這兩個名詞，很少同時出現在一個句子當中 (當然啦，如果「快感」是發生在完全沒有分泌腎上腺素的情況下，那就另當別論了)。
通常一般人會把編寫系統管理指令碼歸類為相當有用、但好像不是那麼刺激的工作，與其說不那麼刺激，不如說有點乏味吧。那是因為：他們根本沒在 Windows Vista® 或 Windows Server® 2008 寫過開機設定資料指令碼！
怎麼樣，心跳有沒有加快一點哪？大部分看過本專欄的人大概都知道，Windows Vista 和 Windows Server 2008 已經捨棄舊的 boot.ini 檔，換上可以增加開機程序管理彈性 (和功能) 的新開機設定資料儲存區了。
很酷吧。不過真正酷的是：多虧新 Windows® Management Instrumentation (WMI) 提供者的幫忙，現在使用指令碼來存取開機設定資料 (BCD) 儲存區要比以前容易多了 — 而且儲存區也獲得全面的管理。
如果您突然感覺心頭小鹿亂撞，別擔心，那就是所謂腎上腺素分泌。只要開始使用 BCD 指令碼之後，您就會習慣了。
不過在正式開講之前，我們要先表明一點，那就是我們不可能一開始就把使用 BCD 提供者所能做到的事情一一涵蓋，至少本文不可能 (我們已經寫信給雜誌編輯，問他可不可能特別針對編寫開機設定資料指令碼，做一次長達兩期的專題報導，不過還沒收到他的回函就是了)。
如果您需要更多完整資訊，請查訪 BCD WMI 提供者文件，網址是：go.microsoft.com/fwlink/?LinkId=116953。同時，我們還要示範針對多重開機電腦而設計的範例程式碼 — 所謂多重開機電腦，就是不只安裝一個作業系統的電腦。
對了，這些指令碼只能用在 Windows Vista 和 Windows Server 2008。之前我們也提過，那是因為它們兩個是目前唯一支援 BCD 的作業系統。
我們先來看看一個可以告訴我們電腦目前正在使用哪一個作業系統的指令碼。那的確不是 BCD 提供者最刺激的用法；畢竟我們已經可以使用 WMI 類別 Win32_OperatingSystem 來判斷電腦目前正在使用哪一個作業系統了。不過，這卻是相當簡單好用的指令碼 (至少到目前為止的 BCD 指令碼是如此)，很適合用來示範使用 BCD 必備的基本技巧 (那些技巧至少都有那麼一點…不尋常)。
而且，我們也不好在專欄裡面描述太多刺激的內容：《TechNet Magazine》已經指示我們要為《嗨，Scripting Guy！》瘋狂粉絲所造成的任何危險事件負責到底。說到危險事件，自從我們發表以規則運算式為題的專欄之後，全球各地就陸續掀起受傷潮，讓我們深感困擾，實在是禁不起任何刺激了。
附註記不記得披頭四被粉絲包圍的影帶？還有當約翰藍儂、保羅麥卡里、喬治哈里森和林格史塔一露面時，引起現場女粉絲尖叫昏倒的照片？那正是我們每次一發表新專欄時的寫照。
好啦，也許我是有點誇大其詞啦。但是許多人 (不分男女) 在讀了我們的專欄之後，禁不住淚流滿面，泣不成聲，這話可是一點也不假。
不管怎樣，讓我們先來看看 [圖 1] 所示的指令碼，這個指令碼是使用 BCD 提供者來判斷電腦目前正在使用哪一個作業系統。在執行這個指令碼之前，應該先知道您必須以系統管理員的身分執行，否則指令碼就無法執行。
[圖 1] 取得目前的作業系統
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
不過，這不表示您非得用系統管理員權限登入帳戶，而是您必須在 [開始] 功能表的 [命令提示字元] 按一下滑鼠右鍵，然後選取 [以系統管理員身分執行]，開啟 [命令提示字元] 視窗。接著再從命令提示字元執行這個指令碼。
到底這個指令碼是做什麼用的呢？問得好，我們就是怕您問。不過無所謂啦，我們還是會盡可能地說清楚講明白 (這麼做應該可以把刺激感降到最低，至少可以冷卻一段時間吧)。
一開始我們先定義兩個常數：BcdLibraryString_Description 和 Current。BcdLibraryString_Description 是指我們要擷取的物件；在本例中，該物件包含了目前作業系統的描述 (名稱)。
對了，這是使用 BCD 提供者其中一項可愛的轉變。在一般情況下，您根本不必擷取屬性值，而是使用其中一個常數值 (和 GetElement 方法) 來擷取另一個物件，然後回應屬於該物件的屬性值。沒錯，這麼做是有點白目，不過您應該聽過一句話：旅遊的樂趣有一半是在旅途上。
附註您一定在想，他們的目的地到底是哪裡對吧？
以常數 Current 來說，目的地就是代表使用中作業系統的 GUID。該值
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
被認為是「眾所周知」的 GUID (這句話證明 Microsoft 的人確實有點幽默感)。
雖然這個 GUID 已經名聞遐耳了，不過我們還是把它囊括進來，以免您之中的哪一位不記得下列哪一個才是正確的值：
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
附註如果您好奇的話，GUID 其實可以唸成「gwid」或「goo-id」。我們還可以告訴您更多小撇步喔，像是第一個 GUID 必須是 V1 GUID，以及第三組數字如何以 4 開頭。不過，我們答應您一定會努力把刺激降到最低，而且我們說到做到。
您或許已經猜到了，無論在什麼場合，只要使用 BCD 提供者，就必須使用常數、十六進位值，以及 GUID。雖然本月份的專欄無法涵蓋所有的細節，不過您可以前往我們之前提過的，位於 MSDN® 的 BCD 網頁 (go.microsoft.com/fwlink/?LinkId=116953)，查看其他資訊。這裡有的是刺激快感，只要您擋得住，就進去吧。
定義完兩個常數之後，接著就要連接本機電腦上的 WMI 服務。您可以使用這個指令碼來擷取遠端機器的開機設定資料嗎？當然可以。
老實說，如果不行的話，這個 BCD 就沒什麼價值了。如果要從遠端機器擷取開機設定資料 (同樣的，遠端機器必須執行 Windows Vista 或 Windows Server 2008)，只要把那部機器的名稱指派給變數 strComputer 就行了：
strComputer = "atl-fs-001"
我們也會在我們的 WMI 連接字串中，指出幾個重要項目。一開始您也許已經注意到我們在連接字串囊括了備份和還原權限，這是 {(Backup,Restore)} 建構的做法。這一點很重要嗎？這個嘛，如果您希望指令碼能夠運作的話，這一點就很重要了：如果沒有明確加入這兩項權限，指令碼就無法運作。
第二點，請注意我們並未連接到 root\cimv2 命名空間 (這是系統管理指令碼最常用的命名空間)，而是連接到 root\WMI 命名空間，直接連結 BCDStore 類別。這就是下面這一段程式碼的作用：
"\root\wmi:BcdStore"
這還不算什麼，好戲還在後頭呢。
雖然偶而會有一兩個例外出現，但是您所寫的任何 BCD 指令碼，多半都是以下面三個步驟開頭：定義常數、連接到 WMI 服務，然後開啟 BCD 儲存區。我們已經完成第 1 步和第 2 步了；下面這行程式碼則是第 3 步：
objStoreClass.OpenStore "", objStore
根據我們之前的說法，接下來我們就要開啟 BCD 儲存區，這是儲存所有開機設定資訊的作業系統實體。如果要開啟儲存區，只要呼叫 OpenStore 方法，在方法中代入兩個參數即可：
  • 空字串 ("")。這是在告訴指令碼，我們要開啟預設的儲存區。
  • objStore。這是我們提供給指令碼的 "out" 參數。我們提供變數名稱給方法，而方法則提供一個以變數名稱作為物件參照的物件作為回報 (這個案例所提供的物件，是一個代表 BCD 儲存區的物件)。
只要儲存區一開啟，我們就可以使用 OpenObject 方法來擷取另一個物件 (儲存在 out 參數 objDefault 中)：
objStore.OpenObject Current, objDefault
那麼這個新物件是什麼呢？沒錯：它就是目前正在使用的作業系統。這一點我們知道，因為我們在常數 Current 代入 OpenObject，也就是代表目前作業系統的知名 GUID。
好了，現在我們已經知道電腦目前所用的是哪一個作業系統了對吧？這個嘛，就快知道了。如果要得到這項資訊，還需要使用 GetElement 來擷取代表該作業系統的描述的物件：
objDefault.GetElement _
  BcdLibraryString_Description, objElement
不過，您得答應我不能駭到受傷才行。很好。那我們就告訴您，現在可以回應 String 屬性的值，並且 (終於！) 判斷電腦目前正在使用的是哪一個作業系統了：
Wscript.Echo "Current operating system: " _
  & objElement.String
請保持冷靜，拜託。記得您答應過我：不可以駭過頭。沒錯，我知道很難。您盡力就好。碰到這種情況時，就深吸一口氣，我們每次編寫 BCD 指令碼時，這一招都很管用。
就像我們所說，光是要判斷目前電腦正在使用哪一個作業系統，就夠我們傷腦筋的了；其實還有別的方法可以運用。但是，從好的方面來看，您現在已經瞭解 BCD 指令碼的運作方式，也就是說，您可以做一些指令碼撰寫人員一直做不到的事 (冷靜，保持冷靜)。舉個例說，在多重開機電腦上，永遠會有一個作業系統被標為「預設值」；如果電腦重新開機時，沒人另外特別註明，電腦就會自動載入預設的作業系統。在 Windows Vista (和 BCD 提供者) 啟動之前，指令碼作者根本無法判斷電腦上哪一個是預設作業系統。但是現在就跟執行 [圖 2] 所示的指令碼一樣簡單。
[圖 2] 判斷預設的作業系統
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
您說得沒錯：的確需要一點受傷事件點綴一下對吧？不過只要一點點就好，可以嗎？我們不打算詳細解說這個指令碼；假設您沒有跳著看前 10 個或 12 個段落，應該可以跟上邏輯。不過您也許會注意到，為了找出預設的作業系統，我們必須採取一個中間步驟：我們必須使用 OpenObject 方法，來開啟一個「開機管理程式」物件的執行個體。開啟開機管理程式之後，就可以使用常數 DefaultType 來擷取一個代表預設作業系統的物件。
怎麼樣？夠刺激吧：我們可以判斷目前的作業系統，同時也可以判斷預設的作業系統。但是真正勁爆的是什麼您知道嗎？那就是擷取一份所有安裝在電腦上的作業系統的清單。這才叫做刺激！繫好安全帶了，讓找們看看 [圖 3]。
這裡到底要做什麼呢？這個嘛，一開始我們要定義兩個新常數：一個是 WindowsImages，可讓我們擷取所有支援 BCD 之作業系統的執行個體 (也就是 Windows Vista 和 Windows Server 2008)；另一個是 LegacyImages，可讓我們擷取電腦上所有「舊版」作業系統的執行個體。連接到 BCD 儲存區之後，接著就使用 EnumerateObjects 方法來擷取電腦上所有支援 BCD 之作業系統的執行個體：
objStore.EnumerateObjects _
  WindowsImages, colObjects
[圖 3] 尋找電腦上所有的作業系統
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
待 EnumerateObjects 完成它自己的任務之後，我們就要安裝 For Each 迴圈，逐一執行集合中所有的作業系統。在這個迴圈當中，我們使用下面這兩行程式碼來擷取、然後顯示作業系統的描述：
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
接著在所有安裝在電腦上的舊版作業系統重複這個程序：
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
附註我們非常瞭解您內心的激動，不過還是要請您耐住性子，好好執行 BCD 指令碼；人體撐得住的快感是有限的。那些懷孕或者可能懷孕、或者可能永遠不會懷孕、或者曾經懷孕過的女士，或者根本不是女士的人士，只要未先經過醫師檢查，千萬不要輕易執行 BCD 指令碼。
哎呀，好啦，您就不必經過醫師同意了。不過，如果您問醫生對於執行 BCD 指令碼有何看法時，我倒是很想聽聽他的回答。
接著我們要試試真正瘋狂的事了；看看能不能變更預設的作業系統。舉個例來說吧，假設我們有一部同時擁有 Windows Vista 和 Windows Server 2008 兩種作業系統的雙重開機電腦，而且我們想要把 Windows Vista 設為預設的作業系統。這時候該怎麼做呢？請看看 [圖 4]，它為我們指出一條完成這項工作的途徑。
[圖 4] 變更預設的作業系統
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
我們可以利用這個指令碼，再次開啟 BCD 儲存區，然後使用 EnumerateObjects 來擷取所有安裝在電腦上的 BCD 感知作業系統。在這裡我們要設定一個 For Each 迴圈，逐一執行集合中所有的項目，以下面這行目前已經熟悉的程式碼，擷取每一個作業系統的描述：
objObject.GetElement _
  BcdLibraryString_Description, objElement
只要一擷取到某個作業系統的描述，就利用 InStr function 看看該值當中有沒有出現 Vista 這個字眼：
If Instr(objElement.String, "Vista") Then
沒錯，這方法是有點笨拙。如果能夠使用 Windows Vista 的 GUID，就可以直接開啟那個作業系統，而不必逐一列舉並巡邏電腦上所有的作業系統了，堪稱是一個好方法。
只不過，要使用這個好方法，必須知道 Windows Vista 的 GUID。而採用這種方法，我們什麼都不用知道 (對於 Scripting Guy 來說真是一大福音)；我們只要不斷搜尋，直到發現標題出現 Vista 這個字眼的作業系統就行了。
附註萬一您電腦上裝有多個 Windows Vista 執行個體的話，那該怎麼辦？嗯，這時候您可能得尋找像是 Vista Ultimate 或 Vista Enterprise 這樣的字串。
只要一找到 Windows Vista，就使用下面這兩行程式碼開啟 Windows 開機管理程式，然後將預設的作業系統設為…就設為 Windows Vista 吧：
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
本月份我們只能講這麼多了；畢章就算是 Scripting Guy，也禁不起每週 7 天，每天 24 小時不停的駭翻天吧。不過別擔心，下個月我們會再推出另一個令人興奮的《嗨，Scripting Guy！》連載系列。運氣好的話，說不定那時候您已經恢復正常了。
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
這個每月一次的挑戰不僅測試您的解謎功力，更要測試您的指令碼技巧。

2008 年 7 月：VBScript 正方形
好吧，它們也許是長方形，而不是正方形啦，不過那是題外話了，暫且不談。要解開這個謎題，請把右手邊的每一個正方形，搭配左手邊的一個空正方形，建立 VBScript 函數的名稱。每一個正方形只能使用一次。請看看下面這個例子：
如果要正確解出這個範例，必須將 OU 正方形 (矩形) 移到第一個字當中的空正方形，然後將 MS 和 OX 移到第二個字當中的空正方形。這樣就得出 UBound 和 MsgBox 這兩個 VBScript 函數，如下所示：
現在就試試看吧：

答案是：
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：VBScript 正方形，2008 年 7 月

Scripting Guy 為 Microsoft 做事，也就是受雇於 Microsoft。他們在不玩、不教或不看棒球 (以及其他各種活動) 的時候，就負責管理 TechNet 指令碼中心。請造訪他們的網站：www.scriptingguys.com。


桌面檔案 從網路啟動 Windows
Wes Miller

目錄
PXE 的運作方式
探討 RIS
WDS — 開場
其他玩家
總結
接下來的幾個月，我打算研究 Windows 部署服務 (WDS)，這項功能可從 Windows Server 2003 使用，而且是內建在 Windows Server 2008 中。WDS 在您的部署基礎結構中可能是非常重要的元件，因此我必須讓您藉著這次討論，打下良好的基礎。這一篇 (也是第一篇)
專欄將講解開機前執行環境 (PXE；讀為 pixie) 的架構、遠端安裝服務 (RIS) 的歷程，以及 Microsoft 所用的其他 PXE 相關技術。
我在 2001 年轉到 Windows 核心 OS 小組時，RIS 是我接手的其中一項技術 (由於它的複雜性，以及它對 BIOS 實作和硬體的依存性，讓當時接手的我顯得有些戰戰兢兢)。但它卻是除了 Windows® PE 之外，在我擔任程式經理任內最玩味的一項技術。
我還記得第一次安裝 Windows 3.0 時，是用一組 3.5" 磁片安裝的。時隔多年，現在安裝作業因為有了可開機光碟 (有些 Windows 98 版本有含)，已經方便許多。但是，安裝作業始終都需要借助某種類型的本機媒體以及本機硬碟。
這幾年，從網路啟動 Windows 的功能 (亦即，完全透過網路開機，無需經由硬碟) 已經成為客戶常見的要求了。雖然有些舊版 Windows 具備這項功能，但是 Windows NT® 卻從未有過。由於現版的 Windows Server® 2003 和 Windows Server 2008 可以透過 iSCSI 啟動器開機，程序與以往大相逕庭，因為它並非真正的本機，而是必須持續仰賴遠端磁碟機作為開機磁碟機。
預備用戶端
  • 評估 RIS 用戶端預備程序
  • 使用預備用戶端規劃網路安全性強化
  • 預備用戶端電腦
  • 遠端作業系統安裝
從 Windows 2000 以來，Microsoft 便開始開發這項容許進行網路安裝、後來稱為 RIS 的技術。RIS 的目標相當簡單 — 就是使用 PXE，將作業系統映像置於目標電腦的本機磁碟上。

PXE 的運作方式
[圖 1] 所顯示的是 PXE 開機順序。PXE 是一個相當簡單的通訊協定，由 Intel 及其他廠商開發，屬於主動線上管理方案 (Wired for Management initiative) 的一部分。PXE 是衍生自動態主機設定通訊協定 (DHCP)，它本身則是衍生自 BootP，而且通常都在您的網路介面卡 (NIC) 中實作。簡單說，其步驟如下：
[圖 1] PXE 開機順序 (按一下以放大影像)
第 1 步系統 BIOS 開機，並且決定開機順序。
第 2 步如果開機順序把 PXE 排在硬碟，或快閃磁碟機或光碟機前面，或者如果沒有那些裝置的話，萬用網路驅動程式介面 (Universal Network Driver Interface，UNDI) 就會從 NIC 載入。NIC 主要包含一個極微小的網路裝置驅動程式以及一個簡單式檔案傳輸通訊協定 (TFTP) 實作 (有的 BIOS 實作要求使用者按 F12 鍵才讓他進行 PXE 開機。但這並非標準作法，我個人主張停用它)。
第 3 步系統開始發出簡單的使用者資料包通訊協定 (UDP) 廣播，尋找 DHCP 伺服器。其實這才是 PXE 開機順序的第一步，稱為「探索」。請注意，該通訊協定是 UDP — 也就是說，如果您沒有 UDP，就得在路由器和交換機花點時間，以確保 PXE 通訊能夠全部過關。
第 4 步如果 DHCP 伺服器聽到廣播，它會回應一個 IP 位址。這個步驟稱為「提供」。此處必須注意的一點是，PXE 是無狀態的，而用戶端在此處必須提供的系統專屬狀態資訊量相當有限 (MAC 位址，如果可用的話，再加上系統管理 BIOS GUID，後者又稱為 SMBIOS GUID)。
第 5 步用戶端在接收封包和 IP 位址之後，接著會表明它其實還需要進一步的資訊 — 那就是 PXE 伺服器的位址。這時候會再發出另一個廣播，其中包含原先回應的 DHCP 伺服器所傳來的資訊。用戶端的用意是要告訴 DHCP 伺服器：「我還需要更多資訊 — 尤其是網路開機程式 (NBP) 的位置」。這個步驟稱為「要求」。
第 6 步PXE 伺服器以 PXE 伺服器的位址以及 NBP 的位置作為回應，那是一個極微小的開機執行檔，必須小於 32KB。這個步驟稱為「通知」。如果您有跟著一起試著做，也許已經注意到 DORA 這個縮寫字了 — Discover (探索)、Offer (提供)、Request (要求)、Acknowledge (通知)，這倒是記住順序的好方法。
請注意，如果您已經安裝 Microsoft DHCP 和 WDS (或者使用其他廠商的技術)，就不會進行要求步驟，事實上 DHCP 伺服器所傳來的原始「提供」封包，已經包含 PXE 伺服器和 NBP 程式的位置了 (因此省了兩個步驟，也省了一些時間)。
第 7 步具有先前提及的小型 TFTP 通訊協定堆疊的用戶端，從 PXE 伺服器所指定的網路位置下載 NBP。TFTP 是一個老舊的超小型無狀態通訊協定。選擇它並不是為了效能或安全性 — 因此許多路由器系統管理員預設都會停用它。如果您希望 PXE 能夠運作，就必須啟用它。
許多 PXE 實作 (包括 RIS 在內) 都具有在此處要求使用者按 F12 鍵才能繼續進行的功能，但是 PXE 伺服器的系統管理員通常都能夠停用這項功能。下個月當我再進一步探討 WDS 時，我會討論 Microsoft 為了提升 Windows Server 2008 效能，在 WDS 的 TFTPD (TFTP 精靈) 當中新增的一些加強功能。
第 8 步將 NBP 初始化。以 RIS 這個案例來說，這個動作會啟動 Windows 開機載入器，開始進行部署程序。PXE (至少實際的開機層級通訊協定) 不再是程序中的一個元件。
您必須記住，PXE (無論是 RIS、WDS 或其他任何基礎結構) 透過慢速連結 (它可以傳輸相當大量的資料) 或者像衛星這樣的高延遲連結 (通訊就是無法正常運作，甚至無法存活) 的效率並不是很好。
您也許會注意到在 PXE 開機程序中，當用戶端傳送要求時，畫面並未特別詢問：「您是我媽媽嗎？」。事實上畫面根本不會出現太多敘述資訊知會 PXE 伺服器。通常會出現的是競爭狀況 — 而獲勝的是第一個回應您用戶端要求的伺服器。您可以執行幾個動作來減輕這個問題：
  • 調整其中一部 PXE 伺服器或另一部伺服器的回應速度。網路延遲和伺服器馬力會影響伺服器的回應速度。事實上，過去 Microsoft IT 所用的伺服器都相當厲害，即使 PXE 伺服器就在您辦公室內，公司伺服器有時候還是會贏過它。這時候，您只要針對預備用戶端，將本機 PXE 伺服器設定為完全沒有逾時值就行了。
  • 預備用戶端。如果您希望 PXE 伺服器先於其他公司 IT 伺服器之前回應，就不能漏掉這一步。您可以預備用戶端，讓 Active Directory® 告訴 WDS 或 RIS，沒錯，其實「我就是你媽媽」。請注意，在 Active Directory 的系統中，使用 SMBIOS GUID 是遠優於專屬識別碼，但如果 SMBIOS GUID 並不是在這些系統中實作 (很可能是在相當老舊的硬體中實作)，您就可以 (也必須) 使用以 MAC 位址為基礎的 GUID。如需詳細資訊，請參閱「預備用戶端」資訊看板。
  • 別讓 PXE 通訊穿越交換器或路由器；請在每一端分別安置一部 PXE 伺服器。這個做法的缺點是，實作與維護的費用都相當昂貴 (每一部伺服器都必須維護它自己的映像)。
RIS (現在是 WDS) 伺服器與 Microsoft DHCP 伺服器一樣，必須對它們所關聯的 Active Directory 實作進行驗證。其目標是讓 Active Directory 知道所有的伺服器，以減少惡意 PXE 伺服器可能造成的問題 (例如，PXE 廣播風暴)。
請注意，此舉只能保護 Active Directory 所知的伺服器。如果您設定的是自己的網域，或是設定非 Microsoft PXE 伺服器，那就另當別論了。
過去 Microsoft 曾經有一位熱心過頭的員工，設定了一部「零接觸」(zero-touch) 部署非 RIS PXE 伺服器。進行這項實作必須完全清除硬碟，並且放置一個全新的映像。如果部署是在隔離 (與網路切斷連線) 的實驗室裡進行，那就什麼事都不會發生，很不巧的它並不是 — 所以它就這樣把一位將 PXE 開機順序排在硬碟之前的 Microsoft 主管的磁碟一舉清除殆盡了。
其實原本它還不至於會導致什麼大問題，因為 Microsoft IT 都必須按 F12 才能進行 PXE 開機，但偏偏這一部 PXE 伺服器剛好就是沒有延遲、沒有 F12 提示，也沒有任何類型的通知。也就是說，那位主管的電腦，還有其中由漫遊使用者設定檔所保護的所有資料，就這樣很有效率的全部消失了。
這個教訓告訴您，如果您要使用「零接觸」，千萬要隔離您的 PXE 伺服器，否則至少也必須要求按 F12 才行。

探討 RIS
在 Windows 2000 推出之後，我承接了 RIS。只要是攸關 RIS，Windows 2000 就像跟時間賽跑一樣 — 而測試、效能以及其他限制都讓 RIS for Windows Server 2000 只能用於 Windows 2000 Professional 部署。沒辦法，伺服器產品就是無法透過 RIS 加以部署。Windows 2000 只能用於 x86 的機器，也因此正好成為絕佳的 RIS 測試台，因為它一個架構只有一個產品。過去 RIS 不但與 (而且必須與) Active Directory 完全整合，也能夠妥善整合到 Microsoft DHCP 伺服器，並且還包含它自己的 TFTPD。
現在 RIS 則使用 NBP 繼續下載 TFTP — 並且帶下足夠的 Windows 核心，開始進行安裝程序 (在某特定點，一旦 Windows 與伺服器的連線從 TFTPD 切換到伺服器訊息區 (或 SMB)，常值程式碼路徑就與傳統磁片起始的 Windows 2000 或 Windows XP 安裝實際共用了)。待原生模式 Windows 起始之後，Windows 安裝便開始啟動「RIS OS 選擇器 (OSC) 精靈」。
OSC 螢幕有點像可以設定的 HTML 2.0 頁面。它們受到嚴格限制，不能包含影像或其他類似項目，事實上，它們根本不能包含非 ANSI 字元，因此使得特定的 Windows 地區設定部署起來相當複雜。
RIS 的最終產品就是 RIS 伺服器上的 txtsetup.sif 檔。當 OSChooser 精靈完成時，用戶端便「由軟體重新開機」，但是 RIS 伺服器 txtsetup.sif 檔的位置，會在軟體重新開機之後保留並重新載入。這個 txtsetup.sif 檔與 unattend.txt 檔沒什麼兩樣，只是多了幾個欄位，幫助 RIS 完成安裝程序。
RIS 也可以執行類似傳統自動安裝的安裝作業 (RISetup)，另外它還有類似 Sysprep (RIPrep) 的複製基礎結構，並且還與它共用程式碼。但是 RIPrep 也可以將自己的映像上傳到 RIS 伺服器。
不過，RIS 卻有一些眾所周知的基本限制。第一，它缺乏伺服器部署的支援。有些結合 IT 複雜性的入侵程式 (例如 Code Red 和 Sasser) 曾讓許多重要客戶直接從 2001 年 9 月 11 日的悲劇復原，這些入侵程式引導我們實際快速追蹤現有 Windows 2000 RIS 伺服器的解決方案，以便進行 Windows Server 部署。雖然我們曾經為了 Windows Server 2003 研究它，但是它並未正式發行。
PXE 相關技術的其他資訊
  • 描述 PXE 用戶端、DHCP 和 RIS 伺服器之間的 PXE 互動
  • 規劃 PXE 起始的作業系統部署
  • PXE 架構
  • 遠端安裝服務
  • 遠端作業系統安裝
  • 遠端作業系統安裝的逐步指南
  • WDS PXE 提供者
  • 什麼是遠端作業系統安裝？
  • Windows Server 2003 自動化部署服務
第二，RIS 缺乏將 OSChooser 精靈自動化的能力，這項功能後來是以 Windows Server 2003 中的 <META ACTION="AUTOENTER"> 元素加以啟用。最後一點，OSChooser 無法妥善用於非 ANSI 字元 — 這是許多美國以外的客戶指出的重要弱點。
舉個例說，如果您用的是法文鍵盤，就無法完成 RIS 安裝。要在全球各地的電腦上，讓非 ANSI 字元在 BIOS 層級正常運作是相當複雜的任務，很難辦到。
自 Windows Server 2003 推出之後，我們開始正式支援 Intel Itanium 架構，以及所有 Windows 2000 和 Windows Server 2003 的各種伺服器。 Windows Server 2003 甚至還支援 x64 架構。
為了提升效能，RIS 也大幅重新改寫 TFTPD。Windows Server 2003 支援同時開機多達 75 個用戶端；記住，只要 SMB 管道一填滿流向用戶端的網路流量時，就到達上限了。

WDS — 開場
在著手開發 RIS for "Longhorn" (就是 Windows Server 2008 的產品代碼) 之後，我們發現還是需要倒退一步。之前我曾在專欄中提過，我們已經下了大盤賭注，從 Windows PE 進行映像式 (WIM) 安裝。因此 WDS 的主要宗旨，是從 PXE 開機的 Windows PE 執行個體進行映像式部署。
另外，我們也知道 Windows Server 2003 是 Windows Vista® 部署的常用平台，而且舊版的 WDS 需要採用「遠端」(Out of Band) 解決方案。因此，WDS 可以在 Windows Server 2003 SP1 執行，而且內建在 Windows Server 2003 SP2 中。
由於它可以當作 RIS 伺服器 (傳統模式)、混合伺服器 (混合模式) 或 WDS 專用伺服器 (原生模式) 使用，因此 WDS 可讓您移轉到正式的 WDS 式部署，一如它之前所保證。我聽過客戶問起，是否可以將 RIS 安裝在 Windows Server 2003 SP2 系統上。沒錯，的確可以 — 您可以安裝 WDS，以傳統模式執行。[圖 2] 顯示的是支援的作業系統。
[圖 2] 支援的部署用平台
作業系統 | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 和 IA64)*** | X | X
Windows Server 2003 |  | X (x86 和 IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* support.microsoft.com/kb/308508 和 support.microsoft.com/kb/313069 已經透過 RIS 新增 Windows 2000 Server 的支援。 ** WDS 傳統模式和混合模式同樣支援這個矩陣進行傳統安裝。 *** Windows Server 2003 SP1 已經增加 x64 系統的支援。IA64 系統過去只支援 RISetup 安裝。 **** 原生模式支援。
Windows Server 2003 SP1 和 SP2 中的 WDS 已開始移轉到 WDS。就像我之前提過，WDS 在 Windows Server 2008 中所增加的主要功能，是一個經過修訂的 TFTPD、可延伸韌體介面 (EFI) 開機支援，當然啦，還有多點傳送部署。

其他玩家
自動化部署服務 (ADS) 是由 Microsoft 的另一個小組所建構，主要目標是快速伺服器佈建。ADS 具備正式的磁區映像處理、自己的開機代理程式 (小於 Windows PE，但功能不如它完整)、自己的 TFTPD，以及相當進階的多點傳送。內建在 ADS 的功能，雖然沒有百分之百功能同位檢查，但是在 System Center Configuration Manager (SCCM) 當中已經差不多夠用。
Windows XP Embedded 則是透過自己的 TFTPD，進行完全 PXE 開機到 RAMDisk，但卻無法以這個方式進行遠端部署。這項技術是為了透過 PXE，同時從同一個磁碟映像開機眾多的系統而設計。

總結
簡單說，這就是它的歷史。如需詳細資訊，請參閱「PXE 相關技術的其他資訊」資訊看板。下個月我將探討 WDS 的基礎，接著是有關 WDS 進階功能 (多點傳送及其他資訊) 的專欄，最後是在不使用 WDS 的情況下使用 WDS，這個意思是超越現有的 WDS/安裝體驗，伸展您自己的部署技術。

Wes Miller 在位於德州奧斯汀的 CoreTrace (www.CoreTrace.com) 擔任資深技術產品經理。他之前任職於 Winternals Software，並且曾在 Microsoft 擔任專案經理一職。您可以透過電子郵件與 Wes 聯絡：technet@getwired.com。


安全性監控 密碼與信用卡 - 第一篇
Jesper M. Johansson

目錄
無用的安全性建議
無用且錯誤
費解的建議
影像式網站驗證的陷阱
我最近接到明尼蘇達大學的邀請，要我接受他們雜誌的專訪。很顯然，他們想要做一系列的傑出校友專題 — 找不到人 — 所以就找我充數。採訪者問到我的工作內容，於是我花了幾分鐘說明安全性
基礎結構軟體。她接著喊道：「聽起來太複雜了！對我來說，安全性就等於密碼與信用卡。」
我仔細思索了一下她的反應，過了幾分鐘，我發覺她說的有理。安全性的確就等於密碼與信用卡。至少對一般使用者來說是如此。在業界工作的我們一談到安全性，就想到密碼編譯演算法、Kerberos 是否比 TLS 或 NTLMv2 更適合、WS* 的好處、密碼雜湊是否要利用 Salt 值，還有其他我們愛討論的各種艱澀主題。的確，我們比一般使用者所關注的層面更深且迥異，但是我們往往忽略了一件基本的事：對於我們所要服務的大眾來說，安全性就等於密碼與信用卡。
的確，我們愛討論的艱澀話題還有我們特別喜歡發明的新技術全都是為了保護使用者資料的安全性。但是我想我們還是搞錯了方向。我們屬於 IT 世界的安全性次文化，存在的目的為了滿足使用者的特殊需求 — 也就是保障資料安全的需求。這不用說也包括了確保 IT 資產能夠安全地被使用。而這才是真正的目的。
在過去的專欄中，我強調沒有人會為了執行防毒軟體而去買一台電腦。使用者購買電腦的目的是要處理線上銀行業務、玩電腦遊戲、寫電子郵件、做功課，或其他一些基本功能。同樣地，沒有一家公司付錢給 IT 安全性小組是為了能夠實作 NTLMv2。公司資助 IT 安全性小組，好讓這些小組能保護組織資產，讓企業整體能安全地使用 IT 資源並達到營運目標。
服務大眾就是我們存在的意義。
因此我必須要問，我們真的有提供良好的「服務」嗎？或者說，身為安全性次文化的我們，實際上是否變成了阻礙而非助力？而立法及管理機構是否也助長這種阻礙？我懷疑我們開發的各種新技術真的對使用者有幫助。因此，我想探討幾個層面，說明身為世界上的 IT 提供者，我們實際上的行為是弊多於利。
有時候我們給使用者的大部分安全性建議和許多安全性技術似乎無用、錯誤、費解，或者往往結合了這三個缺點。在這一系列三篇連載的文章中，我將探討在提供建議和部署犯了上述一個或多個錯誤的技術時，造成使用者混淆的情況。

無用的安全性建議
最能混淆視聽方法之一，就是提供無用的安全性建議。若要變本加厲，您還可以提供錯誤的無用建議。[圖 1] 指出一個經過時間考驗、理論上完善但全然無用的常見建議。
[圖 1] 無用的安全性建議 (按一下以放大影像)
它說您的每個線上帳戶都要使用不同密碼，看到了嗎？這項建議在三十年前行得通。當時在使用日後成為網際網路的工具的人數不過幾百出頭，這些聰明人並未選用特別完善的密碼。不幸的是，這項建議一直保留下來而且不斷複述，而且顯然沒有任何力量讓這項建議隨著今日電腦的使用情況做出調整。
您有多少個線上帳戶？我個人擁有 115 個，再加減我沒有記錄的幾個。根據 [圖 1] 的建議，我不但應該使用 115 個不同的密碼，而且還要每 30 到 60 天變更這 115 個密碼。換言之，我每天都要變更 2 到 4 個密碼 (換算一下：我等於一年會有 690 到 1380 個密碼)。
雖然提出這項建議的某些技術人員可能有辦法每天想出 4 個好密碼，還能將 115 個目前使用的密碼保存在短期記憶裡，但肯定有 99.99 % 的一般網友做不到。
從純理論的角度來說，在各處使用不同密碼的建議實際上是正確妥當的，而每 30 到 60 天變更所有密碼的建議也是如此。但這項建議也是無用的。今日的使用者擁有這麼多密碼，除非憑藉外力 (例如書面記錄或軟體)，否則根本不可能遵從這項建議。接著是下一個例子。

無用且錯誤
[圖 2] 顯示的建議來自全球最大銀行之一的網站，其中的建議不僅無用，而且錯誤。標題＜閱讀我們的密碼建議＞底下提供的資訊再次重申「各處使用不同密碼」這行。它還建議您「永遠不要寫下密碼」。
[圖 2] 無用且錯誤的建議 (按一下以放大影像)
這麼一來，我有 115 個不同的密碼，必須每天建立 4 個新密碼，而且還不准把它們寫下來。一開始我覺得自己很笨，因為我記不住所有的密碼。之後我發現其他人也是一樣。人類就是記不得 115 個密碼。我們可以記住和處理大約七段資訊 — 我們生來如此。根據在網際網路上所找到的多數密碼建議，其實連對一組密碼來說都不夠了，更別提多組密碼 (請參閱 George A. Miller 所著的《The Magical Number Seven, Plus or Minus Two:Some Limits on Our Capacity for Processing Information》，網址是 musanim.com/miller1956)。
可悲的是，每次一談到密碼建議，我們的產業往往會誤導使用者。如果安全性次文化要告訴使用者在各處使用不同的密碼，那麼也必須告訴他們方法 — 也就是將密碼記錄並保存在其他安全的地方。將密碼寫在紙上、使用保密的文件，或利用專門工具，例如 PasswordSafe (sourceforge.net/projects/passwordsafe)。面對現實，我們要不是記下密碼，不然就是到處使用相同的密碼。事實上，最近的一份調查發現有 88 % 的使用者在每個需要驗證的系統上都使用相同的密碼 (請參閱 msnbc.msn.com/id/24162478)。
反對記下密碼的建議確實會助長這種趨勢。我們需要做的是，教導使用者如何有效管理密碼 (以及其他機密資料)，而非教導他們完全不管理這些資訊。如此一來，就能大幅減少使用者洩漏憑證的風險。

費解的建議
前兩圖都重現了早在 1960、70 及 80 年代有效的陳年建議，當時的主流使用者尚未開始上網和使用 Web 形式的服務。也還沒有人大聲抱怨這類建議，因為當時普遍認為這是明智的建議。
這類建議不但會混淆使用者，而且還會讓他們一想到得把密碼儲存到別處就充滿罪惡感。安全性專家提出這類建議，卻不協助使用者完成必要的工作，反而造成傷害。畢竟，找出辦法來管理安全性並非使用者的責任。這應該是安全性專家的責任。我們應該為使用者想出可行的方法來管理他們所有的線上帳戶。既然大部分的指引都只是重複相同的過時建議，使用者只好求助於便利貼和試算表來記錄他們眾多密碼。
作為驗證機制的一環，密碼的功用很多。不過密碼的主要問題在於，人類在記憶密碼方面表現得很差勁。IT 世界不試圖解決人性的問題，反而是忙著發明各種新機制來取代密碼 — 更糟的是還要加油添醋一番。這使得使用者更加困惑。
上次我存取一個特定的金融服務網站，結果出現只包含使用者名稱文字方塊的登入畫面，想像一下我有多驚訝 (見 [圖 3])。
[圖 3] 在哪裡輸入我的密碼？
一開始我以為我踏入了某種惡意網站。接著我很快地驗證這個網站 — 該網站提供憑證，因此這個步驟很簡單 — 我發現實際上我所連接的網站沒錯。問題是，大家已經習慣在登入網站時，同時看到使用者名稱與密碼這兩個文字欄位。這是多年來不斷遇到的相同工作流程。因此當您突然遇到一個只詢問使用者名稱的網站，便開始猶豫起來。原來是這個提供者實作了一項技術，它使用圖片來讓使用者識別網站，以避免網路釣魚攻擊。接下來，當您填入使用者名稱後，網站顯示一個包含可辨識圖片的畫面，如 [圖 4] 所示。
[圖 4] 現在有些網站使用影像來讓使用者驗證網站 (按一下以放大影像)
它的理論是您知道哪個影像是搭配哪個網站。若未顯示正確影像，就可以確認它是假造的網站。這個方法本身是一個很完整的概念。以使用者知道影像與網站組合為前提，這個策略還算合理。
當然，精明的讀者一定注意到 [圖 4] 中的綠色位址列。這表示此網站使用 SSL 與加強式驗證 (EV) 憑證，因此位址列是綠色的。這也表示使用影像來識別網站的整個前提並未提供任何附加價值。相反地，至少有一部份的使用者會對該影像感到困惑。這個網站已經向使用者驗明正身 — 它已經提供憑證，其中包含公司名稱、網站位址和信任的發行者名稱。而位址列是綠色的，這也告訴我們這家公司付了三倍的 EV 憑證費用來獲得更進一步的安全性。
當然，圖片也可能偽造。如果使用者可以提交自己的圖片，攻擊者也有辦法猜到使用的是哪張影像。此外，使用者很可能在每個網站都使用相同的圖片，因此攻擊者只要建立使用者想去的內容網站 (我讓您自己想一個切身的例子)，然後要求使用者提供圖片以供網站驗證之用。如果使用者的確針對所有網站使用相同圖片，那麼這個新網站就得以存取使用者在銀行網站 (舉例來說) 使用的圖片。
雖然有些網站讓您選取自己的影像，但有些網站是使用現有圖片庫。譬如說，[圖 4] 中的網站就有 318 張現有照片供您選擇。如果網站不允許使用者提交自己的照片，上述的把戲就無法得逞。然而，若使用者無法挑選自己的影像，對於不常造訪的網站，使用者很難記得哪個網站要搭配哪個圖片。老實說，我就不曉得我在 [圖 4] 的網站上使用哪個圖片，但保證不是螢幕擷取畫面中顯示的那個。
影像式方法的問題在於，攻擊者可以任意顯示 318 張圖片中的一張，或乾脆隨機挑選 Flickr 中的一張照片，許多使用者都會以為那就是正確的影像。如果大部分的人都記得圖片與網站的組合，今天就不會有那麼多關於釣魚網站和安全性的問題了。
那麼既然網站已經使用憑證來自我驗證，又何必使用圖片來向使用者驗證網站呢？何不只使用憑證，並協助使用者學會如何驗證憑證？憑證已經能向使用者證明網站的真偽了。
取得憑證的程序絕對比取得使用者網站驗證影像的程序更安全。如果憑證是 EV 憑證，而且您使用的是 Internet Explorer® 7 或 Firefox 3，瀏覽器甚至會在位址列反白顯示相關的憑證資訊。但是很可惜，反白顯示功能只適用於極其昂貴的 EV 憑證。

影像式網站驗證的陷阱
圖片驗證技術有一些問題。首先，它非常容易從網站蒐集使用者名稱。事實上，若您輸入錯誤的使用者名稱，[圖 4] 中的網站會顯示如 [圖 5] 所示的對話方塊。一旦您輸入已經選擇秘密影像的使用者的正確使用者名稱，就可以看到那個人的秘密影像。顯然，這項資訊對於想要蒐集使用者相關資訊的攻擊者來說非常珍貴。
[圖 5] 影像式驗證網站方便使用者名稱蒐集
此處顯示的實作類型實際上沒有任何安全性價值。攻擊者可以在假網站上直接複製登入流程。假網站會詢問使用者名稱，然後傳送到真網站。您甚至可以在用戶端使用 AJAX 來即時更新表單，讓它看起來更逼真。此外，如果正牌網站並未防範針對登入表單的跨網站要求偽造攻擊的風險，那麼 AJAX 程式碼甚至能直接提交要求到真網站，除非瀏覽器具有跨網站 XML-HTTP 要求的防護功能。
現在當結果傳回時，攻擊者可以剖析資料，調出圖片，然後向使用者顯示。換句話說，可以向使用者顯示假登入網站的任何攻擊者也能夠顯示使用者的秘密圖片。結論就是使用影像式網站驗證完全沒有任何附加價值。圖片會在使用者驗證網站之前顯示，因此擁有或能夠取得使用者的使用者名稱的攻擊者也同樣能取得該圖片。
假如從來沒有人教導使用者在提交表單之前先檢查憑證 — 如果考慮到影像式驗證用法本身也是基於相同假設的話，這個假設應該蠻寫實的 — 那麼從使用者取得使用者名稱可說是小事一樁。此外，由於許多影像式網站驗證方法對於有效使用者名稱與無效使用者名稱的反應不一，因此使用者名稱蒐集也很稀鬆平常。攻擊者甚至可以在發動攻擊之前，採用 Out-of-Band 的方式進行這些作業。
最終，我們的使用者要不是以為自己更安全，肯定是更加困惑。我們耗費了大量的股東權益來實作影像式網站驗證，卻完全沒有讓惡意使用者難以說服使用者提交憑證到假的網站。
本期《安全性監控》的內容到此為止。下個月請記得鎖定本系列文章的《第二篇》，我將舉出更多例子來討論誤導的安全性作法與不正確的驗證實作。

Jesper M. Johansson 是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有 MIS 博士學位，在安全性領域有 20 年以上的經驗，而且是企業安全性方面的 Microsoft MVP；其最新著述為《Windows Server 2008 Security Resource Kit》。


現場筆記 確保選舉的精確度
Josh Benaloh

今年正逢美國大選年，眾人都把目光集中在投票技術上。下面幾種投票方式，是我們極力反對的目標：人工計算的紙張選票 (不但費時費力，而且容易出錯)；槓桿機器 (容易受到熟知內幕的人士操縱)；穿孔卡片以及最近聲名大噪的懸空票；以光學掃描的選票 (口徑不準的掃描器很容易讀錯)；觸控式螢幕系統 (容易受到粗糙或惡意軟體的連累)；以及各種混合式選票 (它們所產生的問題，常常多過他們所解決的問題)。
其實這只是這些系統當中一小部分的弱點取樣而已。目前國際間常用的技術，多半還是要仰賴誠實和嫻熟的選務管理人員來維護選舉的清廉。
不過，選舉的清廉不必完全押在選務管理人員或選務設備上，還是有更好的方法可以取代他們。選舉能夠順利進行，是因為選務人員、個人選民，甚至是對選舉抱持興趣的觀察家，共同針對選舉的精確度進行端對端驗證之故。
假設我們提供程式碼給合法選民，讓他們上公開網站，在自己的名字旁邊投票。選民不但可以自行檢查網站，看看他們自己的選票是否有被正確記錄，甚至任何人都可以執行獨立稽核，檢查所有的選民是否合法，以及檢查實際的計票結果是否符合宣布的計票結果。
不過且慢 — 這種公開式的選舉還欠缺一樣東西，那就是私密性。沒錯，所以我們要用密碼編譯來彌補這個缺失，以達到完全驗證的不計名投票。選民並不是投下原始選票，他們所投的選票會以公開金鑰加密，而其加密金鑰則由選務人員共用，以方便要求共同解密。投票完成之後，選務人員便開始進入分工合作程序，共同產生選舉計票以及加密證明，證明計票結果完全符合選民所投下的加密選票組合。
不但個人選民可以檢查他們的加密選票是否符合他們自己的意願，任何人都可以檢查加密證明，看看加密選票是否都有正確計票。這麼一來，選舉計票就可以用端對端的方式加以驗證了。
真的這麼簡單嗎？當然不。這只是忠實呈現的概觀，但其實還有許多細節必須仔細妥善管理，才能確保一切就緒。舉個例說，我們還是得靠傳統方法，確保投票裝置充分保有選民的隱私。而且選民該如何將他們的意願，轉化為加密的選票呢？選民必須相信他們在名字旁邊投下的神秘加密值，確實符合他們自己的意願，而不必將對應值顯示給第三方看 (以免他們受到高壓政治或賄選的影響)。而且我們要求選民所做的，絕不能比傳統的投票系統更為複雜。
端對端驗證選舉程序已在加密文獻中研究長達四分之一世紀，現在終於找到可靠且實用的方法，可以提供計票精確度的加密證明了。研究社群最近開始把焦點轉移到呈現在選民面前的前端，使得這個領域有了長足的進展。
商界對於選舉技術的要求的確很大，但還不算太大。與多方利益大量結合，在這個市場很容易被人以懷疑的眼光看待，這是因為他們的部分利益可能是來自特定的選舉結果。因此，這個市場最適合完全仰賴調整選舉來獲得商業利益的小型利基型企業發展。如需有關端對端驗證選舉方法的詳細資訊及其連結，請上 research.microsoft.com/crypto/voting。

Josh Benaloh 是微軟研究院 (Microsoft Research) 的資深密碼編譯人員。他曾在國際密碼安全研究協會 (International Association for Cryptologic Research) 的董事會任職八年，其延伸著作包括他在 1987 年撰寫的博士論文＜Verifiable Secret-Ballot Elections＞。


Windows 機密文件 空間佔用回顧
Raymond Chen

還記得 Microsoft Bob 嗎？ 它原本是為了在 Windows® 3.1 上層提供方便使用的使用者介面，結果卻搞得臭名遠播 (贏得《PC World》選出的史上最糟技術產品之名)。在 Bob 落幕後的這麼多年來，這個產品逐漸被貶為笑柄，只現身在印著它的名字的球鞋上。
附帶一提，Microsoft® Bob 的內部產品代碼是「烏托邦」 — 果然是野心勃勃，不過至少這個名稱比較有活力。當我們知道行銷部同仁決定將產品命名為 Bob，我們全都不敢置信地搖著頭。
不過您可能不知道，Bob 的殘餘價值不只如此。事實證明，死掉的 Bob 比活著更有用。
當您想要在 CD 上散發軟體時，有一件事必須要注意，就是確保單一 CD 能夠確實容納產品。幸好，考慮到轉譯、支援工具以及其他要放入 Windows XP CD 的東西所需的磁碟空間之後，空間還夠，而且還剩下 30 MB 的儲存容量。負責處理這些事情的人員想到，既然 CD 上的這些儲存空間也算在成本內，不如利用一下剩餘的空間，不是嗎？
Microsoft Bob 的內部產品代碼是「烏托邦」 — 果然是野心勃勃，不過至少這個名稱比較有活力 (按一下以放大影像)
嘗試的結果卻還是阻擋不了想要非法拷貝 Windows 的人。有人決定在 CD 上多餘的容量填滿假資料，並讓 Windows 安裝程式檢查這些假資料是否還在原處。按這個邏輯來說，這樣能強迫下載 CD 映象複本的使用者下載額外的 30 MB 左右的資料。別忘了，我們所說的時代背景是當「寬頻」這個字眼尚未普及，而主流使用者仍在使用撥號連線的年代。必須透過 56Kb 的數據機傳輸額外的 30 MB 的確會造成一些阻礙並拖延使用者的行動 — 當然以今日的標準來看，這麼做並不會拖慢傳輸速度。
被指派實作這項檢查的人員需要找出假資料的來源。現在，他只要呼叫 CryptGenRandom 函式來產生 30 MB 的隨機加密位元組就行了，不過這樣還有什麼樂趣？相反地，他尋遍了封存資料，然後找到一版 Microsoft Bob。他取出所有磁片映象檔，然後結合成一大個檔案。Microsoft Bob 磁片映象檔的內容並不太隨機，因此他決定以加密方式來打散資料。要輸入加密金鑰時，他直接在鍵盤上亂敲，於是便出現 Microsoft Bob 的加密版本。就這樣變成了 Windows XP CD 中未使用空間的填充資料。
最後，Windows XP 就變成了最有效開發的 Microsoft Bob 部署工具。因此如果您從衣櫃中找出 Windows XP 的光碟，然後憑著靈感在鍵盤上敲出一樣的金鑰，Microsoft Bob 就會從加密程式中出現。

Raymond Chen 的網站「The Old New Thing」以及同名著作均探討 Windows 的歷史和 Win32 程式設計。他很想知道核聚變在他有生之年是否能夠實現。

© 2008 Microsoft Corporation and CMP Media, LLC.著作權所有，並保留一切權利。未經許可，不得部分或全部重製