 TechNet Magazine December 2006

TechNet Magazine December 2006

Exchange Server 2007: 將基礎結構升級到 Exchange 2007

不論組織規模大小，順利轉換至 Exchange Server 2007 都需要事先規劃。有了正確的行動計劃，您就能避免任何的服務中斷。以下是升級時需要遵循之步驟的說明。

Kate Follis Exchange Server 2007: 使用 Exchange 管理命令介面

Exchange 管理命令介面提供強大的介面，讓管理員能管理 Exchange Server 2007 的各個層面。請參閱以下有關如何開始撰寫指令碼、整合應用程式，以及從命令列執行其他強大管理工作的概觀。

David Strome Exchange Server 2007: Exchange 和 Outlook 相得益彰

Exchange Server 2007 搭配 Microsoft Office Outlook 2007 是通訊和協同作業的一大進展。瞭解我們如何潛心鑽研更簡單的組態、改進的搜尋功能、整合通訊等等。

Michael Khalili Exchange Server 2007: 與 Exchange 2007 永不分離

通訊功能比以往更加強大。瞭解 Exchange Server 2007 內建的整合通訊和 Outlook Web Access 如何讓您隨處存取集中在某個地點的所有郵件。

Joshua Trupin Exchange Server 2007: Exchange 2007 更強大的日誌功能

Exchange Server 2007 提供更有彈性的日誌功能，讓大型組織能夠更容易監視內部特定使用者帳戶並符合規範需求。

David Strome Exchange Server 2007: 利用寄件者識別碼抵制垃圾郵件和網路釣魚

以寄件者識別碼架構 (SIDF) 為基礎而建置的電子郵件驗證，在抵制垃圾郵件和網路釣魚郵件方面實現了重大改進，得到了廣泛採納。實際上，全世界三分之一以上的電子郵件都得通過驗證並遵循 SIDF。本文介紹其工作原理。

Craig Spiezle and Alexander Nikolayev 編輯的話: 延伸觸角

TECHNET MAGAZINE IS MORE than just this fabulous publication you hold in your hands today. Our team has been working furiously to create an innovative new Web site that will make our content accessible to more than a billion people around the world.

Joshua Trupin 工具箱: 向 IT 專業人員推薦的新產品

Greg Steen Windows PowerShell: 命令精簡，管理能力超強

Don Jones 事後剖析: 從 Exchange 5.5 遷移

Whitney Roberts SQL 問題與解答: 預防重新開機、安裝多項更新及其他資訊

Edited by Nancy Michell 嗨，Scripting Guy！: 杯架在哪？

The Microsoft Scripting Guys 資訊安全新知: 部署全球信任的 PKI

John Morello 桌面檔案: 瞭解 Windows 影像格式

Wes Miller Windows 機密: 等待 RunOnce

CONSIDER AN installation that needs to restart the system in the midst of the process. For example, the program might wish to upgrade a system DLL that is currently in use. You would need to trigger an intervening reboot to get the new DLL file installed, and then after the DLL has been upgraded, you could use it in the next stage of the installation.

Raymond Chen


 Exchange Server 2007: 將基礎結構升級到 Exchange 2007
Exchange Server 2007 Kate Follis

將基礎結構升級到 Exchange 2007
摘要:
  • Exchange 2007 的新功能
  • 準備升級
  • 以角色為基礎的部署
  • 郵件路由拓樸

我過去經常講授有關從 Exchange Server 5.5 遷移到 Exchange 2000 Server 的課程。課程從早上 8:30 開始，下午 6:00 左右結束。我每次離開教室時都會感到
筋疲力盡。僅僅為了轉移目錄資源，以及有關 NTDSNoMatch 的各種混淆和偶爾會拒絕信任的 Windows NT® 4.0 信任，就需要大量的準備工作。由於時間限制，我們僅勉強觸及 Exchange 2000 Server 管理，但總是有幾個迫不及待的學生打算在星期五夜晚離開教室，在週末完成遷移程序。我警告過不要這樣做，並建議多花一些時間做計畫，但我不能確定他們是否聽進去。
從 Exchange 2000 Server 或 Exchange Server 2003 轉換到 Exchange Server 2007 同樣需要花時間謹慎地規劃。實際的轉換程序將因組織和目前部署的複雜性而異，但轉換程序仍需要若干個階段。小型組織可以一個單獨專案的方式來展開這些階段，而大型組織可以決定逐步導入伺服器角色並支援 Exchange 在一段時間內處於共存模式。端對端程序是專用於在整個轉換期間保持郵件功能和穩定性。在本文中，我將著重在升級到 Exchange Server 2007 時維護組織中之郵件流程所需的基本步驟。

考量因素
第一個值得注意的需求是，Exchange Server 2007 必須部署於 64 位元硬體中，而且它不支援從任何舊版的 Exchange 進行就地升級。必須使用迴旋升級方法將現有的訊息服務移至 Exchange 2007。而且，Exchange 組織必須在原生模式下運作，以支援加入的 Exchange 2007 伺服器。因此，如果組織目前正在使用 Exchange 5.5，則您必須先執行暫時升級到 Exchange Server 2003，然後才能移至 Exchange 2007。
規劃轉換時，必須考慮 Exchange 2007 中的一些重要變更。例如，Exchange 2007 導入以角色為基礎的部署，它允許您選擇要提供的訊息服務，並部署這些服務特定的伺服器角色。可以分別在專用的硬體中部署伺服器角色，也可以在同一台實體伺服器中安裝多個角色，做為獨立的實體進行管理。如需有關每個伺服器角色的說明，請參閱資訊看板「Exchange 2007 伺服器角色」。
Exchange Server 2007 伺服器角色
信箱伺服器 信箱伺服器角色為組織提供郵件儲存區。Exchange 2007 可支援每個伺服器有多達 50 個儲存區。這些儲存區可以做為 50 個個別的儲存群組進行部署，也可以在一個儲存群組中建立多達 50 個儲存區。信箱伺服器角色是唯一能夠叢集化部署的角色，因此，如果您要使用叢集，將需要在專用硬體上安裝信箱伺服器。
Client Access Server Client Access Server 角色取代前端伺服器所提供的功能。它可以對使用 POP3、IMAP4、Outlook® Web Access (OWA)、RPC over HTTPS (現在稱為「Outlook 無所不在」) 及 Exchange ActiveSync® 存取 Exchange 的用戶端，提供信箱存取。
Hub Transport Server 此角色為 Exchange 組織提供 SMTP 和 MAPI 郵件傳輸服務。組織中使用者所傳送或接收的每個郵件都是由 Hub Transport Server 處理的。這很重要。因為這確保了任何郵件都不能略過伺服器規則或日誌原則，這些原則由針對傳輸管線中各點的代理程式所提供。
Unified Messaging Server 此角色提供對信箱的語音存取。它透過與 IP/VoIP 閘道或 IP-PBX 進行整合，提供對郵件和行事曆項目的電話存取，同時允許您錄製回覆。此角色是 Exchange 的新功能，不能與任何舊版的 Exchange 相互操作。
Edge Transport Server Edge Transport Server 一般部署在周邊網路中。它在 Exchange 組織和網際網路之間提供 SMTP 郵件傳輸，並且藉由使用傳輸代理程式提供反垃圾郵件和防病毒處理。您現在可以為組織和周邊網路伺服器建立一套標準化的單一技術。這種無接縫互動模式簡化管理程序，並讓周邊伺服器整合更容易。

檢查拓樸
從哪裡開始呢？除非您知道身在何處，否則很難決定方向。花一些時間來評估目前環境並記錄拓樸 (不僅是 Exchange，還有 Active Directory® 環境)。您可能會高興地知道 Exchange 2007 已經擺脫了連結狀態路由，以及基於路由群組和連接器的拓樸。相反地，Exchange 2007 會利用組織在設計 Active Directory 拓樸時已經做出的投資。因此，所有 Exchange 收件者和組態資料都儲存在 Active Directory 中、路由拓樸從 Active Directory 站台組態衍生而來，而且所有伺服器角色都將使用站台感知來偵查在其他伺服器角色上執行的服務。
確定目前的 Active Directory 站台拓樸真正利用基礎實體網路，並且所有 Active Directory 站台都具有關聯的子網路，然後記錄現有 Active Directory 站台和 IP 站台連結。也記錄所有 Exchange 2003 伺服器所在的實體位置，以及路由群組和路由群組連接器結構。
以下是轉換程序中最棘手的部分：從基於路由群組的 Exchange 路由基礎結構移至基於 Active Directory 站台的路由基礎結構。對於小型組織，這通常是簡單的程序。但對於具有許多路由群組的大型組織來說，則需要對 Exchange 2003 和 Exchange 2007 同時存在的過渡階段仔細規劃。您最不想要的一件事是，透過由低頻寬連線的特定遠端路由群組，使郵件從對面辦公室的 Exchange 2007 使用者傳送到您的 Exchange 2003 信箱。
讓我們首先針對目前的拓樸做出一些假設：
  • Exchange 2003 組織在原生模式下執行。
  • 有多個路由群組。
  • 有多個 Active Directory 站台。
[圖 1] 說明 Exchange 和 Active Directory 拓樸。請記住，初步計畫中包含的資訊越詳細，設計結果越好。
圖 1 Exchange 和 Active Directory 拓樸
圖 1 Exchange 和 Active Directory 拓樸

Exchange 2007 如何使用 Active Directory
當 Exchange 2007 伺服器啓動時，會被加上一個站台屬性戳記，可協助其他 Exchange 2007 伺服器尋找該伺服器所提供的服務。只有 Hub Transport Server 可以使用 SMTP 在組織內傳輸郵件。每個包含信箱伺服器的 Active Directory 站台也必須包含 Hub Transport Server，而且，如果信箱使用者使用任何非 MAPI 方法存取其信箱，那麽各站台也必須包含 Client Access Server。無論何時需要處理郵件進行傳遞，郵件都將經過 Hub Transport Server，該伺服器將決定如何對該郵件進行路由。如果郵件的目的信箱伺服器與 Hub Transport Server 位於相同 Active Directory 站台，則此 Hub Transport Server 會將郵件傳遞至信箱。如果郵件的目的信箱伺服器在其他站台中，則此 Hub Transport Server 會將郵件直接轉送至遠端站台的 Hub Transport Server。
Hub Transport Server 使用 Active Directory IP 站台連結成本資訊，來計算通往收件者信箱所在的 Active Directory 站台的最低成本路由。此路由選取演算法與 Exchange 2003 非常相似，但它是基於 IP 站台連結成本，而不是路由群組連接器成本。而且，郵件不會在途中的每個 Hub Transport Server 上停止。它會直接從來源位置傳輸到目標位置。既然依賴 IP 網路傳輸郵件，為什麽還要勞神費力地去計算最低成本路由呢？有幾個原因。一個是為了讓郵件延遲出現分枝。傳送給多個收件者的郵件可能需要被傳遞至多個 Active Directory 站台中的信箱伺服器。Exchange 2007 在郵件達到路由路徑中的岔口時才會將其分割，而不是在第一個 Hub Transport Server 中產生郵件分枝或分割郵件。因此，郵件將直接轉送至 Active Directory 站台中代表分枝點的 Hub Transport Server。這種行為稱為延遲散開 (Delay Fan-out)。
最低成本路由也用來決定在無法到達目標位置時郵件在何處佇列。如果無法到達目標 Active Directory 站台中的 Hub Transport Server，傳送端 Hub Transport Server 隨後將嘗試傳遞至路由路徑中下一個最近的 Active Directory 站台中的 Hub Transport Server。郵件將沿最低成本路由繼續進行傳遞，直至到達可使用 Hub Transport Server 的 Active Directory 站台。最後，如果通往收件者 Active Directory 站台的路由中沒有可用的 Hub Transport Server，則郵件將在本機佇列中等待。此方法使郵件在盡可能接近傳遞點的位置佇列等待，有助於使網路故障診斷更具確定性。這種行為稱為「於故障點佇列」(Queue At Point Of Failure)。
Exchange 2003 的運作方式完全不同。它基於指配給路由群組連接器的成本，來計算從一個路由群組到另一個路由群組的最低成本路由。路由路徑中各路由群組的 Bridgehead 伺服器將接收郵件，然後將其轉送。如果路徑中的下一個連接器不可用，則會嘗試計算替代路由。此外，也會在整個 Exchange 組織內傳達連結狀態更新訊息，以通知其他 Exchange 伺服器連線中斷。Bridgehead 伺服器將嘗試在已停機的連接器周圍進行路由，直到收到指示連線已建立的連結狀態通知。
大型組織進行轉換時所面臨的挑戰在於維護共存期間的郵件流程。為了在將 Exchange 2007 導入環境中時達成此連續性，所有 Exchange 2007 伺服器都應成為一個路由群組的成員。這意味著，無論 Exchange 2007 伺服器屬於哪個 Active Directory 站台，Exchange 2003 都會將它視為屬於該路由群組。這可讓您在此路由群組和 Exchange 2003 路由群組之間建立一個路由群組連接器，以使 Exchange 2003 可以指出如何將郵件路由至 Exchange 2007。Exchange 2007 也將使用此路由群組連接器，以決定如何將郵件傳送至 Exchange 2003。但是，Exchange 2007 一定都希望透過其他 Exchange 2007 伺服器路由郵件，並且絕不會透過 Exchange 2003 路由群組中的骨幹到達另一個 Exchange 2007 伺服器。

導入第一個 Exchange 2007 伺服器
當您在 Exchange 2003 組織中安裝第一個 Exchange 2007 伺服器時，將需要選取 Exchange 2003 Bridgehead 伺服器，用來建立第一個路由群組連接器。
[圖 2] 顯示導入的第一個 Exchange 2007 伺服器是如何影響組織拓樸。
圖 2 安裝第一個 Exchange 2007 伺服器
圖 2 安裝第一個 Exchange 2007 伺服器
至此不會有什麽問題。請注意，由 Exchange 2007 建立的路由群組連接器的預設成本只為 1。郵件將和往常一樣繼續流過 Exchange 2003 伺服器。如果郵件從任何 Exchange 2003 伺服器傳送給 Exchange 2007 伺服器使用者，則該郵件將流過亞加普科路由群組。建立路由群組連接器後，您選取的 Exchange 2003 Bridgehead 伺服器便會自動成為 ExchangeLegacyInterop 萬用安全性群組的成員，並被授與正確的權限以從 Exchange 2007 收發電子郵件。只要 Exchange 2007 伺服器被指定為連接器的來源伺服器或目標伺服器，就必須使用 Exchange 管理命令介面中的 New-RoutingGroupConnector 來建立路由群組連接器。也可以使用 Set-RoutingGroupConnector Cmdlet 來修改路由群組連接器的組態。例如，您可能想要將來源和目標伺服器加入至初始路由群組連接器，以提供備援 (如需詳細資訊，請參閱 David Strome 在本期 TechNet Magazine 關於 Exchange 管理命令介面的文章)。

準備移動一些信箱
下一步是將 Exchange 2003 伺服器中的某些信箱移至 Exchange 2007 伺服器。使用 Move-Mailbox Cmdlet 達成此目的。但是，在解除 Exchange 2003 伺服器的任務之前，您會希望在 Exchange 2007 伺服器上建立傳送和接收連接器，來取代在 Exchange 2003 伺服器中定義的 SMTP 連接器，以處理通往外部 SMTP 位址空間的路由。
在下圖中，來自亞加普科路由群組的資源已被移至 Exchange 2007。可以解除亞加普科路由群組的任務，但這意味著您必須立即建立連接其他路由群組的路由群組連接器。在 [圖 3] 中，我將路由群組連接器設定成連接邁阿密北部路由群組的 Bridgehead 伺服器。
圖 3 設定路由群組連接器
圖 3 設定路由群組連接器
讓我們繼續將洛杉磯東部路由群組轉換至 Exchange 2007。這種情況下維護路由有一點棘手。在 [圖 4] 中，Exchange 2007 已安裝在洛杉磯站台中，第二個路由群組也已解除任務，但沒有建立其他任何路由群組連接器。
圖 4 安裝在洛杉磯站台的 Exchange 2007
圖 4 安裝在洛杉磯站台的 Exchange 2007
現在，如果郵件從洛杉磯站台中的 Exchange 2007 伺服器傳送到洛杉磯西部路由群組中的 Exchange 2003 伺服器，該郵件將首先被轉送到亞加普科，然後依序經過邁阿密北部和邁阿密南部，最後到達洛杉磯西部。如果郵件從洛杉磯西部路由群組中的 Exchange 2003 伺服器傳送到洛杉磯站台中的 Exchange 2007 伺服器，該郵件將首先被轉送到邁阿密南部，然後依序經過邁阿密北部和亞加普科，最後到達洛杉磯。真麻煩！
為了避免出現這種情況，我們將需要再增加一個路由群組連接器。[圖 5] 顯示在洛杉磯站台增加連接洛杉磯西部和 Exchange 2007 伺服器的路由群組連接器。附註：如果要避免存在過多的路由群組連接器，請確保您的第一個路由群組連接器已在連接良好的中央 Active Directory 站台中進行設定。
圖 5 更有效的路由
圖 5 更有效的路由
這會引發可能不是很明顯的問題。現在有多種流入和流出 Exchange 2007 路由群組的方法。由於 Exchange 2007 路由群組不使用連結狀態，所以目前可能存在路由迴圈。Exchange 2003 伺服器可能會選取替代路由，以便在已停機的連接器周圍進行路由，而 Exchange 2007 則一定選取最低成本路由。解決這個問題的方法是抑制不重要的連結狀態更新訊息，這將防止出現傳達連接器為已停機狀態的連結狀態訊息，但不會防止出現傳達組態變更的連結狀態訊息。這一點非常重要，因為我們希望 Exchange 2003 伺服器知道新的路由群組連接器，但不希望它們嘗試計算替代路由。最終結果是 Exchange 2003 伺服器將表現與 Exchange 2007 伺服器相同的行為，也就是「於故障點佇列」。
在 [圖 6] 中，我們已將更多的 Exchange 2003 資源轉換到 Exchange 2007。連結狀態更新已被抑制，我們也非常小心地建立會維護邏輯路由路徑的路由群組連接器。
圖 6 更多的 Exchange 2003 資源移至 Exchange 2007
圖 6 更多的 Exchange 2003 資源移至 Exchange 2007
但有另一個問題。我們已在雷德蒙和溫哥華建立連結狀態島。郵件可以正常傳送，雖然經過邁阿密，但雷德蒙和邁阿密之間無法傳達連結狀態組態變更。如果要保持目前的路由表，您將需要在雷德蒙和溫哥華之間設定另一個路由群組連接器。您可以調高此路由群組連接器的成本，使其足以防止 Exchange 2003 在該連線上進行路由，同時允許傳達連結狀態組態變更。
透過仔細規劃，您可以避開維護兩個單獨的 Exchange 路由拓樸可能會帶來的一些問題。藉由一次轉換一個路由群組，然後再轉換下一個路由群組，直到只有 Exchange 2007 伺服器在執行為止，您將會得到最順暢的結果。
至此，我已重點說明 Exchange 2007 中的路由變更及其對您的轉換所產生的影響。規劃移至 Exchange 2007 時還需要記住其他幾個考量因素。
Exchange 2003 前端伺服器無法存取 Exchange 2007 信箱。不過，Exchange 2007 Client Access Server 可將您與 Exchange 2003 信箱連接，不會產生任何問題。使用 Exchange 2007 Client Access Server 時，您只會看到與儲存您信箱的信箱伺服器相同的 OWA 版本。如果在單獨的硬體上部署 Exchange 2007，則 Client Access Server 應是在 Active Directory 站台中導入的第一個角色。在任何信箱移至 Exchange 2007 之前，任何提供對信箱的公共網際網路存取的 Exchange 2003 前端伺服器都應取代成 Exchange 2007 Client Access Server。
我先前曾提到過，每個包含信箱伺服器角色的站台，也需要有 Client Access Server 角色 (如果您具有非 MAPI 用戶端 -- 但誰能在沒有 OWA 的日子裏活著？) 和 Hub Transport Server。所以，如果打算使伺服器角色共用硬體，務必要將 Client Access Server 包含在角色選取中。典型安裝將包含 Hub Transport Server 角色、Client Access Server 角色及信箱伺服器角色，即實作完整功能的 Exchange 環境所需的所有角色。
轉換程序的另一個考量因素是何時升級用戶端應用程式 (Outlook)。在用戶端升級到 Outlook 2007 之前，您將無法充分利用所有 Exchange 2007 伺服器功能，包括增強的郵件答錄機訊息設定和受管理信箱資料夾功能。
您也需要決定何時部署 Edge Transport Server 角色。技術上，在導入其他任何 Exchange 2007 伺服器角色之前或之後，都可以將周邊網路的 SMTP 中繼和智慧主機取代成 Edge Transport Server。不過，如果先部署 Edge Transport Server，整體功能將會受到限制，原因是 Exchange 2003 無法將 Edge Transport Server 所需的收件者和組態資料從 Active Directory 複寫至 ADAM (Active Directory 應用程式模式)。
安裝至少一個 Hub Transport Server 之後，可以在周邊網路中部署 Edge Transport Server，然後再為 Edge Transport server 訂閱 Hub Transport Server 所在的 Active Directory 站台。Hub Transport Server 上的 EdgeSync 服務會將 Active Directory 中的收件者資料子集複寫至 ADAM。
透過該資料，Edge Transport Server 可以執行收件者查閱和安全清單彙總，這樣您就可以充分利用 Edge Transport Server 上執行的反垃圾郵件代理程式。此外，EdgeSync 將建立端對端郵件流經 Exchange 組織和網際網路所需的傳送連接器。這可以使提供外部位址空間路由的 Exchange 2003 SMTP 連接器的取代程序得以簡化。
因此，花點時間規劃 Exchange 2007 的轉換，您將發現路由非常簡單省力。

Kate Follis 是 Exchange 2007 技術寫作團隊的資深內容發行者。其小組專門研究 Edge Transport Server 和 Hub Transport Server 角色。在加入 Microsoft 之前，Kate 曾擔任多年 Microsoft 認證講師，講授 Exchange 和 Active Directory。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 Exchange Server 2007: 使用 Exchange 管理命令介面
Exchange Server 2007 David Strome

使用 Exchange 管理命令介面
摘要:
  • Exchange 管理命令介面的運作方式
  • 如何使用 Cmdlet
  • Cmdlet 和命令的比較

如果您是 Exchange 環境的管理員，現在您一定已經聽說即將發行的 Exchange Server 2007 包含一個稱為 Exchange 管理命令介面的新命令列介面。Exchange 管理命令介面奠基於 Microsoft Windows PowerShell 技術之上，
是強大的管理介面，可用來從命令列管理 Exchange Server 2007 的各個層面。從命令列，您可以與 Exchange 管理命令介面直接互動、撰寫自動化指令碼，或將應用程式與基礎引擎整合。[圖 1] 顯示作用中的命令介面。
圖 1 Exchange 管理命令介面
圖 1 Exchange 管理命令介面
Exchange 管理主控台不只是使用 Exchange 管理命令介面來執行作業；其中的精靈還會告訴您它們正在執行哪些命令。複製精靈所建立的命令，並將它們直接貼上命令列或指令碼中。視需要修改參數之後，可使用 WhatIf 參數，對指令碼或命令進行測試，以便在環境中進行任何變更之前查看其結果。
Exchange 管理命令介面提供穩健、有彈性的指令碼處理平台，可以和您目前的指令碼解決方案整合，而且還能讓您直接與 COM 和 Windows Management Instrumentation (WMI) 等資料來源通訊。Exchange 管理命令介面以 .NET Framework 為基礎，它使用 Cmdlet (Exchange 管理命令介面的最小功能單元) 來接受和傳回結構化資料而非純文字。稍後我將詳細說明 Cmdlet。

Windows PowerShell 嵌入式管理單元
瞭解 Exchange 管理命令介面的第一步，必須從它與 Windows PowerShell™ 的關係開始，後者是一個基於 .NET Framework、強大、有彈性的新命令列介面。它結合許多其他命令介面的最佳功能，而且也加入許多新功能。Windows PowerShell 是設計成裝載其他應用程式，與裝載應用程式提供之各種嵌入式管理單元的 Microsoft Management Console (MMC) 非常類似。Exchange 管理命令介面是第一個發行的 Windows PowerShell 嵌入式管理單元。
嵌入式管理單元是用來管理應用程式或主要元件的 Cmdlet 集合。如果不先載入，便無法使用。所幸，啓動 Exchange 管理命令介面嵌入式管理單元，極為容易。但在說明這點之前，我應該先解釋，您在閱讀本文及使用 Exchange 管理命令介面時需要瞭解的一些重要概念。
Cmdlet：Cmdlet 類似其他命令介面中的內建命令，例如 cmd.exe 中的 dir 命令。如同人們所熟知的這些命令，Cmdlet 可以從 Exchange 管理命令介面的命令列中直接呼叫，並在該命令介面的內容中執行，而非做為單獨的程序。但與其他命令介面中的命令不同的是，Cmdlet 有「動詞-名詞」形式的描述性名稱。動詞說明 Cmdlet 所執行的動作，而名詞則說明發生作用的元件或功能。
您不必猜測 Cmdlet 的用途。例如，當您看到 Move-Mailbox Cmdlet 時，一切不言而喻。
如果要瞭解 Cmdlet 與一般命令的差異，請參閱資訊看板「Cmdlet 和命令的比較」，它摘錄自 Windows® SDK 的 .NET Framework 3.0 部分，網址為 windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx。
Identity 和 Positional 參數：Identity 參數可以和大部分 Exchange 相關 Cmdlet 搭配使用。它可讓您存取用來參照 Exchange Server 2007 中之特定物件的唯一識別碼，以便使用對您最有意義的唯一值，對特定 Exchange 物件執行動作。
Identity 參數是來自其他參數的值集合。這些值對於該組物件一定是唯一的。您可以指定這些其他參數 (例如 Name 和 DistinguishedName) 的值，也可以由系統產生 (例如 GUID)。使用的其他參數 (如果有) 及其填入方式取決於參照的物件。
Identity 參數也可視為位置參數，對於這種參數，您可以指定其值而不需指定其名稱。如果 Parameter Position 屬性是整數，該參數就是位置參數。此整數表示命令列上 Cmdlet 可找到參數值的位置。因為 Identity 是位於位置 0 (第一個位置) 的位置參數，所以在此位置輸入的任何不具有參數名的值都會被視為 Identity 參數值。如此可減少您在輸入命令時的按鍵次數。例如：
Get-Mailbox –Identity "Kim Akers"
執行的動作與下列命令相同：
Get-Mailbox "Kim Akers"
管線：Exchange 管理命令介面中的管線是指一個 Cmdlet 在執行作業時使用另一個 Cmdlet 的輸出。管線是使用管道符號 "|" 完成的。相同名詞 Cmdlet 集內的所有動詞都可以使用管道傳來的另一個命令的資訊。某些名詞 Cmdlet 集也會讓您透過管線將資料傳遞至另一個名詞 Cmdlet 集。
藉由管線來串連兩個或更多 Cmdlet 的動作，可以將數個小元件轉換成更強大的元件集合。例如，您可以使用一個 Cmdlet 來收集資料，將該資料傳遞給第二個 Cmdlet 以篩選資料成為子集，然後將該資料傳遞給第三個 Cmdlet 以便只對該子集執行動作。

啓動 Exchange 管理命令介面
此命令介面最簡單的載入方式是：依序按一下 [開始]、[程式集]、[Microsoft Exchange Server 2007]，然後按一下 [Exchange 管理命令介面]。
Exchange 管理命令介面嵌入式管理單元的另一種載入方式是從 Windows PowerShell 工作階段手動進行。依序按一下 [開始]、[程式集]，然後按一下 [Windows PowerShell]。在啓動它之後，執行下列命令來載入 Exchange 管理命令介面：
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
在使用 [程式集] 功能表項目載入 Exchange 管理命令介面嵌入式管理單元，和使用 Add-PSSnapin Cmdlet 手動啓動這兩種方式之間有些差異。使用 [程式集] 功能表項目時，不僅會載入 Exchange 管理命令介面嵌入式管理單元，還會執行 Windows PowerShell 指令碼以設定自訂的 Exchange 管理環境。如果要在手動載入 Exchange 管理命令介面後設定類似的管理環境，請切換至 Exchange 安裝的 bin 目錄，例如 C:\Program Files\Microsoft\Exchange Server\Bin。然後，執行下列命令：
.\Exchange.ps1
看看 Exchange.ps1 指令碼，可以瞭解如何自訂 Windows PowerShell 環境以符合您的需要。當您載入 Exchange 管理命令介面時，會出現類似 [圖 2] 的歡迎使用資訊。
圖 2 Exchange 管理命令介面的歡迎使用橫幅
圖 2 Exchange 管理命令介面的歡迎使用橫幅

從何處入門
此命令介面的 Cmdlet 內容包羅萬象，因此 Get-Help Cmdlet 和 Exchange Server 2007 說明檔將是非常寶貴的資源。Exchange Server 2007 說明檔的＜作業＞一節針對大部分管理工作提供許多操作程序。
單獨輸入 Get-Help 後，會顯示有關如何取得說明的一般說明資訊。如果要取得特定 Cmdlet 的說明，請輸入 Get-Help，後面加上特定的 Cmdlet。使用 Detailed、Full 和 Example 參數可以控制顯示的資訊。只需將它們加入至命令結尾即可。例如，Get-Help cmdlet name –Full 會傳回某個 Cmdlet 所有可用的說明部分。
如果要擷取某個 Cmdlet 的一或多個特定參數的資訊，可以搭配 Get-Help 使用 Parameters 參數。例如，如果要檢視 Set-Mailbox Cmdlet 所有包含 "quota" 一詞的參數及其說明，請使用下列命令：
Get-Help Set-Mailbox –Parameter *quota*
您可能想列出所有管理特定伺服器角色或元件功能、或在某特定功能範圍內影響物件的 Cmdlet。為此，可以在 Get-Help Cmdlet 中使用下列三個參數：Role、Component 及 Functionality。搭配這些參數使用 Get-Help Cmdlet 時，必須將透過這些參數指定的值以萬用字元 "*" 括住。下列範例說明如何以每個參數呼叫 Get-Help：
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
如需詳細資訊，Exchange Server 2007 說明檔中的＜取得說明＞主題列出可供使用的所有角色、元件及功能值。

設定命令輸出格式
根據預設，當 Exchange 管理命令介面在螢幕上顯示輸出時，只顯示每個物件可用屬性的子集。不過，將命令輸出透過管道傳遞給下列三個格式化 Cmdlet 後，即可輕鬆存取所有屬性：Format-List、Format-Table 及 Format-Wide。您可能會經常使用 Format-List 和 Format-Table，所以我將對它們詳細說明。
Format-List Cmdlet 從管線取得輸入，並輸出由每個物件的所有指定屬性組成的垂直分欄清單。使用 Property 參數可以指定所要顯示的屬性 (不過 Property 參數是位置參數，也就是說您只需指定值而無需指定參數名稱)。如果呼叫未指定任何參數的 Format-List Cmdlet，則會輸出所有屬性。此 Cmdlet 會將輸出內容自動換行而不會將其截斷。Format-List 的一個最佳用途是覆寫 Cmdlet 的預設輸出，讓您可以擷取其他資訊或更適合的資訊。例如：
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
[圖 3] 顯示此命令的輸出。
圖 3 Format-List 範例輸出
圖 3 Format-List 範例輸出
Format-Table Cmdlet 可以在由屬性資料的標籤標題和資料行組成的表格中顯示各項內容。根據預設，Get-Mailbox 和 Get-JournalRule 等許多 Cmdlet 都使用表格格式的輸出內容。Format-Table Cmdlet 的參數包括 Properties 和 GroupBy。這些參數運作方式與 Format-List Cmdlet 中的完全相同。如果要完整顯示較長的屬性資訊行而不是在行尾將其截斷，可以使用 Wrap 參數，如下：
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
請參閱 [圖 4] 以檢視輸出。
圖 4 Format-Table 範例輸出
圖 4 Format-Table 範例輸出
如果包含萬用字元，您可以對應多個屬性，無需分別輸入每個屬性名稱。例如，下列範例會傳回所有以 Email 開頭的屬性。
Get-Mailbox | Format-List Email*

練習時間
現在您已經掌握一些基本命令，何不練習下列範例。它們將展示 Exchange 管理命令介面的強大功能和彈性，並讓您親身實作。
您將嘗試的第一個命令會建立 10 個使用者，其名稱從 User1 到 User10：
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
讓我們來逐一分析各段程式碼。命令 1.0 會輸出整數 1 到 10，並透過管線傳遞給 ForEach Cmdlet。ForEach Cmdlet 會在收到每個物件時作用於其上，並對每個物件執行 { } 括弧內的命令。Net User 命令會建立新的網域使用者，Enable-Mailbox Cmdlet 則會在本機伺服器上的 "Mailbox Database" 中建立新的信箱。這兩個命令以分號分隔，所以能夠置於同一行命令。$_ 變數是包含管線中之目前物件值的特殊變數。對本範例而言，$_ 變數包含目前管線中的整數。
下一個範例將會顯示伺服器 MBX 上的信箱，並傳回每個信箱的 Name、mailbox database 及 quota 屬性。
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Get-Mailbox Cmdlet 會傳回以 Server 參數指定的每個信箱，然後將每個信箱物件的輸出透過管道傳遞給 Format-Table Cmdlet。根據預設，Format-Table Cmdlet 會顯示由 Cmdlet 傳回的所有屬性，除非您指定所要顯示的屬性。這裡只要求 Name 和 Database 屬性，以及所有包含字串 "quota" 的屬性。[圖 5] 顯示可能的輸出結果。
圖 5 Get-Mailbox 命令輸出
圖 5 Get-Mailbox 命令輸出
在下列範例中，針對組織中職稱含 "Manager" 一詞的所有具郵件功能的使用者，將傳送配額限制設成 600MB。
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
如果單獨執行 Get-User Cmdlet，會傳回 Active Directory 中的所有使用者物件，包括不具信箱功能的使用者。為了擷取一組可由 Set-Mailbox Cmdlet 使用的使用者物件，您必須指示 Get-User Cmdlet 只傳回具信箱功能之使用者的 Active Directory 使用者物件。RecipientTypeDetails 參數用來指定 Active Directory 收件者類型 (本例中為 UserMailbox)。下一步，您需要擷取一組職稱為經理並且具信箱功能的使用者。在這個範例中，每個 Active Directory 使用者物件的 Title 屬性都已填入。可以透過 Filter 參數 (用來指示伺服器只傳回符合準則的 Active Directory 物件)，利用此屬性值來判斷哪些使用者是經理。這稱為伺服器端篩選。一旦您擁有一組物件，它們會被傳遞給 Set-Mailbox Cmdlet，該命令隨後會將每個信箱的 ProhibitSendQuota 屬性設成 600MB。
下一步，我們將測試一個命令的結果，看其是否能移除某個通訊群組的所有信箱。命令如下：
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
第一個 Cmdlet 會擷取做為 "Fourth Year Students" 通訊群組成員的收件者物件。然後，只將 RecipientType 為 "UserMailbox" 的收件者物件傳遞給 Remove-Mailbox Cmdlet。Remove-Mailbox Cmdlet 會顯示其將執行的動作以及作用於其上的物件，並不會移除這些信箱。Get-DistributionGroupMember Cmdlet 會擷取做為 "Fourth Year Students" 通訊群組成員的所有收件者物件的清單。但由於 Remove-Mailbox Cmdlet 只能處理具信箱功能的使用者，所以您需要篩選掉除了 "UserMailbox" 之外的所有收件者類型。與其他 Cmdlet 不同，Get-DistributionGroupMember Cmdlet 沒有 Filter Cmdlet，這意味著它無法執行伺服器端篩選。對於無法執行伺服器端篩選的 Cmdlet (因為它們沒有任何效能優勢)，可以使用 Where Cmdlet 來執行用戶端篩選，該命令會擷取所有物件並在本機用戶端電腦上執行篩選。Where Cmdlet 只允許那些符合所指定準則的物件通過。RecipientType 為 "UserMailbox" 的物件會被傳送至 Remove-Mailbox Cmdlet。此 Cmdlet 會移除 Active Directory 使用者物件並將信箱標示為移除。使用 WhatIf 參數時，Remove-Mailbox Cmdlet 會顯示如下的文字：
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
如果您對該命令將執行的動作感到滿意，請移除 WhatIf 參數再次執行該命令。對於特定 Cmdlet，例如具有 Remove 動詞的 Cmdlet，此命令介面將在進行任何變更之前自動要求確認。您可以選擇逐步進行每個變更、指示命令介面不再提示確認，或者取消進一步處理。對於不會自動執行確認的 Cmdlet，可使用 Confirm 參數進行強制確認。

結論
現在您已經一窺 Cmdlet 的強大功能，想必您已準備親身體驗，感受 Exchange 管理命令介面和 Microsoft Windows PowerShell 對您未來的系統管理工作帶來的助益。如果想要閱讀更多有關這兩個主題的資訊，請查看下列資源。如需管理命令介面的相關資訊，請參閱 Exchange Server 2007 說明檔 (go.microsoft.com/fwlink/?LinkId=69434)、Windows Powershell 指令碼中心 (go.microsoft.com/fwlink/?LinkId=71134) 及 Exchange 團隊部落格 (msexchangeteam.com)。

David Strome 擔任 Microsoft Exchange User Education 團隊的技術文件作者剛滿一年。在加入位於華盛頓州雷德蒙市的 Microsoft 之前，David 約有 10 年經歷，曾服務於加拿大卑詩省的多家公司，從事 Exchange Server 安裝的設計、實作和管理工作。他的連絡方式為：dstrome@microsoft.com。


 Exchange Server 2007: Exchange 和 Outlook 相得益彰
Exchange Server 2007 Michael Khalili

Exchange 和 Outlook 相得益彰
摘要:
  • 安裝簡化
  • 整合語音、傳真及電子郵件
  • 符合性的受管理資料夾

多年來，Microsoft Exchange Server 和 Outlook 為數百萬使用者提供可靠的電子郵件，協助人們協調和管理行事曆，並使連絡人的整理變得輕而易舉。有人可能想知道此組合有何創新。Exchange Server 2007
和 Microsoft Office Outlook 2007 很快即將發行，它們將共同在通訊和協同作業領域實現一大進展。
從您啓動 Outlook 用戶端那一刻起，就會明顯感受 Exchange Server 2007 和 Office Outlook® 2007 的改進。在舊版中，Outlook 要求您提供 Exchange 信箱伺服器的名稱，這是令許多使用者困擾的資訊。這導致服務台求助電話過於頻繁或初始化指令碼複雜化，這兩者都會增加運行有效通訊環境的成本和複雜性。現在，透過 Exchange Autodiscover Web 服務，只要將用戶端加入至網域中，Outlook 就會自動設定帳戶。如果用戶端沒有加入網域，使用者只需輸入名稱、電子郵件地址及密碼。Outlook 和 Exchange 會解決其餘設定 (請參閱 [圖 1])。
圖 1 帳戶設定
圖 1 帳戶設定
同樣地，在過去，使用者不僅要在初次使用時設定 Outlook，還要在移至不同郵件伺服器時重新設定。即使有電子郵件提醒使用者信箱將要遷移，但忙碌的員工沒注意到即將發生的遷移相關事宜，直到某天早上他們進辦公室時，才發現被鎖在 Outlook 之外。這時，服務台求助電話又接踵而來。Autodiscover Web 服務也會解決這個問題。當使用者從一個信箱伺服器移到另一個信箱伺服器時，Outlook 會識別出原有組態不再有效，並會再次查詢 Autodiscover Web 服務，然後重新設定新信箱的用戶端。使用者完全不會感覺到這段過程。

重塑行事曆
在過去，大部分行事曆邏輯位於 Outlook 中。每個會議更新都被視為一個獨立的會議邀請，這意味著可不按順序接受通知。如果連續發出兩個會議更新，並且收件者先接受第二個會議更新，則他的行事曆上可能會有過時資訊。而且，如果從 Smartphone 或 PDA 存取 Outlook 資訊，將導致不一致的空閒/忙碌資訊 (取決於使用者檢視資料的方法)。
解決方法是將所有行事曆邏輯從 Outlook 用戶端移至 Exchange Server 2007。當該伺服器收到會議邀請時，會議會被臨時自動置於行事曆中，直到使用者選擇接受或拒絕此邀請。如果收到有關會議時間和地點的變更，會議會被自動更新，而且舊的邀請會被標示為過時，所以使用者便不會意外接受它。此邏輯在所有用戶端 (Office Outlook、Outlook Web Access、Outlook Mobile 或其他協力廠商用戶端) 中都一致，所以只會顯示正確、最新的會議。
有了如此可靠、準確的行事曆，就能夠提供一組可提高使用者生產力的新工具。在過去，為多名忙碌員工安排會議非常不容易。使用者必須手動尋找適合會議的空閒時間，並且捲動瀏覽數天的資訊以尋找適合全部出席者的時間。現在 Outlook 2007 排程助理員 (如 [圖 2] 所示) 將會尋找適合所有人的最佳時間。在輸入出席者和列席者以及所需的會議室和資源之後，排程助理員會顯示最佳會議日期的彩色編碼檢視。一旦選擇日期，便會使用相同配置來尋找當日最佳時間。
圖 2 排程助理員
圖 2 排程助理員
排程助理員按照出席者、列席者、會議室及資源的優先順序來決定會議的最佳時間。排程助理員還可以讓您更容易地處理彈性工作時間和不同時區等問題。使用者可以設定自己的工作時間，定義早上到達時間和晚上離開時間。因此，直到上午 9、10 點鐘才會工作的夜貓族，可以設定在這個時間開始工作。當其他人需要安排會議時，就不會建議較早的時間 (例如上午 8 點)。如果位在不同時區的兩個群組 (例如一個在倫敦，一個在洛杉磯) 需要開會，只會建議雙方工時重疊的會議時間。倫敦員工將會在下午稍晚開會，洛杉磯員工則會在一大早開會，而不會讓開會時間落在其中一方的凌晨 2 點。

大海撈針
近年來，送達一般使用者收件匣內的電子郵件數量正以驚人的速度增加。從前一般辦公信箱僅能容納幾百封郵件，現在有些人一天就能收到那麽多郵件。在雪片般飛來的郵件之下，埋藏著對任何企業營運極為重要的資訊。在需要時找到合適的資訊是很大的挑戰。
Office Outlook 2007 和 Exchange Server 2007 的搜尋功能比起舊版有大幅改進。無論使用者處於快取模式還是線上模式，都將對郵件套用相同的搜尋演算法。在線上模式中，搜尋查詢會被傳送至 Exchange 伺服器，在那裏執行搜尋。Exchange Content Indexer (比 Exchange Server 2003 中的索引工具快上 35 倍) 用於確保快速尋找和擷取郵件。在快取模式中，Outlook 會使用 [立即搜尋] (基於 Windows® Desktop Search 3.0)，同時結合索引引擎並減少 CPU 時間。可以對出現在主旨、內文、收件者和寄件者欄位甚至是附件中的文字進行搜尋，如 [圖 3] 所示。
圖 3 搜尋重要電子郵件的新方法
圖 3 搜尋重要電子郵件的新方法

透過整合通訊無所不在的存取
Exchange 整合通訊是 Exchange Server 2007 的內建元件，它將所有類型的商務通訊 (包括電子郵件、語音郵件及傳真) 都匯集到一個單獨的收件匣中。在傳統的系統中，語音郵件是透過電話取得，電子郵件是透過電腦取得，而傳真則是透過專用的傳真機取得。Exchange 整合通訊可讓使用者選擇最佳用戶端來滿足他們在特定時空的需求。在 Outlook 中，語音和傳真訊息會出現在收件匣中，緊鄰電子郵件。語音郵件一經選取，會包含一個內嵌播放機，以便能夠直接從讀取窗格播放訊息 (請參閱 [圖 4])。
圖 4 透過 Outlook 播放語音郵件
圖 4 透過 Outlook 播放語音郵件
Outlook 也可以讓您在處理郵件時，維持郵件與其背景資訊的脈絡。通常，當您聆聽語音郵件時，會草草在紙張上做些記錄。這些記事與郵件沒有關聯，可能會遺失，很難稱得上有效的通訊模式。使用 Exchange 整合通訊可以直接在 Outlook 中進行記事。它們與郵件緊密相關，並以可搜尋文字形式建立索引，確保記事一定會出現在語音郵件的脈絡中。所以，使用 Exchange Server 2007 和 Office Outlook 2007 的改進搜尋功能就能快速找到它們。
Outlook 也可以管理許多語音郵件選項 (請參閱 [圖 5])，包括允許使用者在用戶端變更語音信箱的個人識別碼 (PIN) (PIN 碼重設是語音郵件系統服務求助電話的一個主要原因)。從 Outlook 的選項，使用者可以產生新的 PIN 碼並透過電子郵件傳送給他們。此 PIN 讓他們能夠一次完成存取 Exchange 整合通訊電話介面、Outlook 語音存取，以及變更 PIN 碼等動作。
圖 5 整合通訊包含 Pin 碼重設選項
圖 5 整合通訊包含 Pin 碼重設選項

安全和保護
當今組織的通訊環境面臨著許多威脅。Outlook 和 Exchange 將聯手對抗這些威脅。垃圾郵件只是其中的一個威脅，Office Outlook 2007 加入了 Outlook 電子郵件郵戳的支援 (對抗垃圾郵件的新方法)。Outlook 會在外寄郵件執行一個計算題，並將解答附加到該郵件。然後 Exchange 會檢查結果。對於一次只傳送一封的訊息 (合法郵件通常是這種情況) 執行這類計算時，幾乎不佔用 CPU 時間，但如果垃圾郵件傳送者的電腦必須為大量電子郵件建立這些計算題的話，他們電腦的負擔將會變得非常沈重。因此，具有 Outlook 電子郵件郵戳的郵件比沒有郵戳的更有可能合法，Exchange 在判斷每封電子郵件的有效性時會考慮這個因素。
除了垃圾郵件等舊有威脅，新的法規制度也在改變郵件系統的要求。Sarbanes-Oxley、HIPPA 及 Basel II 等法規規定了嚴格的記錄保留或破壞規則。為了滿足這一新需求，Exchange 和 Outlook 導入了「受管理資料夾」。這些資料夾由管理員針對特定類型的郵件而建立。在 Outlook 中，使用者可以看到這些資料夾以及資料夾中應儲存的內容的描述 (請參閱 [圖 6])。使用 Exchange 傳輸規則也可以將郵件自動傳送至特定資料夾中。一旦郵件位於指定的受管理資料夾中，就會遵循該資料夾的存檔、保留及到期原則，並會以與組織原則一致的方式自動進行處理。
圖 6 受管理資料夾強制執行電子郵件的符合性規則
圖 6 受管理資料夾強制執行電子郵件的符合性規則
儘管做出了最大努力，但偶爾也會發生符合性違規。在這種情況下，快速識別和修復是必要的。Exchange 提供的快速搜尋功能成為關鍵工具，可供符合性專員尋找能識別符合性違規之線索的郵件。為了追蹤並更正此違規情況，可跨信箱執行搜尋。

更容易管理的環境
與舊版相較之下，Exchange Server 2007 和 Office Outlook 2007 通力合作，提供大幅改進的郵件系統。它們將所有重要商務郵件都匯集在一個位置，使這些郵件更容易尋找、設定，並提高安全性和符合性。它們共同將協同作業和通訊帶入更高的層級。

Michael Khalili 是 Exchange Server 的產品經理，負責用戶端存取和整合通訊。此外，他還負責 Outlook 和 Exchange 的整合。


 Exchange Server 2007: 與 Exchange 2007 永不分離
Exchange Server 2007 Joshua Trupin

與 Exchange 2007 永不分離
摘要:
  • Outlook Web Access 的改進
  • Exchange Server 2007 的整合通訊
  • 透過 ISA Server 2006 的安全性

幾年前，線上通訊只是基本的通訊方式。人們透過 POP3 和 SMTP 傳送電子郵件。太簡單了，當然需要改變。今天，組織需要為員工提供
足夠的彈性，使他們可以自由選擇工作的時間和方式，同時也要顧及安全性。Microsoft® Exchange Server 2007 有幾項針對這些需求的內建功能，其中包括 Microsoft Office Outlook® Web Access (OWA) 和整合通訊。讓我們一起研究 Exchange Server 2007 的這兩個關鍵元件，瞭解它們如何超越舊版，為現今的企業建立功能更強大的通訊平台。
OWA 從 5.5 版開始成為 Exchange 的一部分。坦白說，前幾版不太靈活。它們解決透過 Web 瀏覽器存取 Exchange 信箱的問題，但沒有充分利用 Outlook 所提供的各種功能。
在 Exchange Server 2003 中，OWA 已有改進。使用者的瀏覽器體驗比以往更加自然，就像是在使用用戶端程式。Exchange Server 2007 中的 OWA 又更進一步，它全想改寫了舊版，所以能採用其他最新的技術創新，例如 RPC over HTTP 和 ASP.NET 2.0。
例如，試想 OWA 如何轉換。舊版的 OWA 是在儲存程序中由信箱伺服器轉換的。這會對信箱伺服器增加額外的負載，可能造成系統效能低落。相較之下，Outlook Web Access 2007 是透過 ASP.NET 在 Client Access Server (CAS) 上轉換資料。這會讓信箱伺服器從頁面處理工作中解脫出來，因此提高效能。
此外，前端所執行的工作也有改變。在舊版的 Exchange 中，OWA HTTP 要求會透過 Proxy 傳遞至適當的信箱伺服器。Exchange Server 2007 則透過 RPC 直接從適當信箱伺服器擷取資料，減少與 OWA 相關的流量。大致說來，由於這個程序，您才可以在企業虛擬私人網路 (VPN) 連線之外的用戶端上使用 Outlook。然後由 OWA 轉換信箱資訊。Exchange Server 2007 也可以 Proxy 傳遞 OWA 要求，但它並不是將其直接傳送至信箱伺服器，而是轉寄給其他 CAS 伺服器。
[圖 1] 顯示 Exchange Server 2007 上 OWA 的架構。
圖 1 OWA 如何存取 Exchange Server 資源
圖 1 OWA 如何存取 Exchange Server 資源

管理
改造後的 Exchange Server 2007 架構中包含更多管理 OWA 的選項。您可以使用 Exchange 管理主控台或使用 Exchange 管理命令介面。組態設定儲存在幾個位置。
Exchange 管理主控台可讓您存取大部分可能的組態設定，例如啓用或停用分割使用、附件封鎖、驗證等功能，以及存取行事曆、工作清單及拼字檢查等功能。在 Exchange 管理主控台中能達成的任何工作，也都可以透過 Exchange 管理命令介面工作來完成。
此外，Exchange 管理命令介面也可讓您建立和刪除 OWA 的新虛擬目錄。您也可以更詳細地的控制每個使用者的分割設定，以及變更預設語言設定等等。
Windows 登錄是表單型驗證逾時值的預設儲存位置 (這些設定無法透過 Exchange 管理主控台或 Exchange 管理命令介面取得)。透過 Active Directory® 可以存取 OWA 特定的設定，例如附件封鎖和分割。IIS Metabase 包含可影響 IIS 行為的任何設定 (驗證、GZIP)。web.config 會保留 ASP.NET 設定，例如控制 OWA 附件上載的 "maxuploadsize"。

驗證
OWA 提供數種伺服器端驗證選項。安裝後，安全性會預設成表單型驗證。但您可以根據組織需求，在必要時以數種方式改進。IIS 將根據 Active Directory 執行驗證，以確保通過驗證的使用者擁有相符的網域權限。您也可以使用基本驗證、摘要驗證、RSA SecurID 甚至智慧卡登入等方式來存取電子郵件。
OWA 最強的安全性層級是 Windows 整合安全性，它結合 Kerberos 和 NTLM。事實上，Outlook Web Access 2007 Web 組件存取和 Active Directory 站台之間的 CAS 代理都要求採用 Windows 整合安全性。它也對在內部網路上存取 OWA 之使用者提供額外的好處，即 Windows 用戶端驗證的單一登入。如果您已經是信任使用者，便無需登入 OWA。
如果您使用預設的表單型驗證，OWA 會在靜止一段時間後自動逾時。根據使用者在登入期間提示中所選擇的電腦類型 (公用或私人)，逾時值會不同，可能是 15 分鐘 (公用電腦)，也可能長達 8 小時 (私人電腦)。使用者對於公用或私人電腦所做的選擇非常重要，因為其他安全性設定也會因此項設定而異。例如，您可以在公用電腦上封鎖附件，或變更驗證逾時值。表單型驗證程序基本上分為四個步驟 (如 [圖 2] 所示)。
圖 2：驗證程序
  1. 用戶端將未加密的要求傳送至伺服器。
  2. 伺服器將加密的 Cookie 傳送回用戶端。
  3. 伺服器持續捨棄和建立新的加密金鑰，並將三個最新的金鑰保存在記憶體中。
  4. 如果用戶端在傳送要求時所使用的加密金鑰已經過時但仍在記憶體中，則會收到以最新金鑰加密的新 Cookie。
    或者
    如果用戶端在傳送要求時所使用的過時加密金鑰已被捨棄並且已逾時，則必須重新登入。

msExchQueryBaseDN 是用來限制某些使用者只能看到 OWA 一小部分通訊錄的機制。msExchQueryBaseDN 會標示在 Active Directory 使用者物件上，指向某個通訊清單 (AL) 或組織單位 (OU)。此 AL 將做為使用者的全域通訊清單 (GAL)，使用者所看見的 GAL 只包括此 OU 中的使用者帳戶。可使用 LDAP 設定 msExchQueryBaseDN。

回溯相容性
Exchange Server 2007 中 Outlook Web Access 的核心是 CAS，該 CAS 模型已改進，會在最大範圍內提供與舊版 Exchange 伺服器的交互操作性。為了確保這種交互操作性，務必先部署或升級 CAS 伺服器，然後再升級其相關的信箱伺服器。
可以使用 CAS 角色的 Exchange 2007 伺服器連接到 Exchange 2000 和 Exchange 2003 伺服器上的信箱。站台部分升級後，RPC over HTTP 和 Exchange ActiveSync® 都會繼續運作。如果透過 /exchange、/public 或 /exchweb 虛擬目錄進行存取，OWA 和 WebDAV 也會運作。您也可以在 Exchange Server 2007 上為這些舊版建立自訂的 OWA 虛擬目錄。

ISA Server 2006 是您的良伴益友
Exchange Server 2007 中的 Outlook Web Access 比以往有長足的進步，但如果與 Internet Security and Acceleration (ISA) Server 2006 搭配使用，則更是如虎添翼。
ISA Server 2006 是整合式邊緣安全閘道。它既能協助您保護站台免受來自網際網路的威脅，同時也提供對應用程式和資料的安全遠端存取。這也是 OWA 的目標，所以這兩個功能的搭配使用將實現所有計算概念中最神奇的一個：協同 (如需有關 ISA Server 的背景資訊，請參閱 microsoft.com/isaserver/2006)。
ISA Server 2006 為飽受折磨的 Exchange 管理員帶來幾點好處。例如，網頁發行負載平衡 (WPLB) 功能可讓您使用 HTTP Cookie 來平衡負載。即使用戶端 IP 變更後，也可以確保用戶端/伺服器關聯性。ISA Server 2006 也提供 GZIP 壓縮和解壓縮功能，可讓您分析流量或從 Web 伺服器卸載壓縮工作。使用 ISA Server 2004 時，您必須進行以下選擇：將 HTTP 壓縮與 OWA 搭配使用，或者將表單型驗證與 ISA Server 搭配使用。所幸 ISA Server 2006 同時支援這兩種選擇。
此外，也可以透過 ISA Server 執行 OWA 連結轉譯。如果有人在 OWA 電子郵件中放入內部網路連結，ISA Server 可以將其轉譯成正確的網際網路連結。這項功能相當有用，但必須記住要將內部網路連結發行到同一個發行 OWA 的 ISA 陣列。
或許最重要的是，ISA Server 2006 執行預先驗證，協助保護周邊網路的安全。預先驗證用意在確保惡意的 HTTP 流量不會到達伺服器。如果被導向 CAS 的流量事實上是有效的，ISA Server 會允許其從周邊網路進入網域中 (周邊伺服器在內部網路網域之外，負責封鎖不應進入網域中的流量。CAS 不應部署在周邊網域中，而需要部署在內部網路網域中，這樣才能存取 Active Directory 使用者帳戶)。

Outlook Web Access 疑難排解
Outlook Web Access 2007 提供一些用來改進監視和疑難排解工作的新工具。監視工作會自動執行於 CAS 伺服器上，用來測試每個信箱伺服器的連線和 OWA 登入。Exchange Server 2007 也提供更加詳細的事件日誌訊息和效能計數器。
Exchange Server Best Practices Analyzer (請參閱 microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange 中的報導) 已改進，會在 OWA 錯誤設定時傳送相關警告和錯誤訊息來提醒管理員。您也可以透過 LogParser 工具從 IIS 產生 OWA 使用情況報告 (2006 年 10 月號曾報導過，網址為 microsoft.com/technet/technetmag/issues/2006/10/LogParser)。

整合通訊
OWA 解決的是行動商務需求，而整合通訊則將不同形式的訊息合併到統一的位置 (因此而得名)。現在，電子郵件存在於 Exchange Server。語音 (電話呼叫、語音郵件) 則是透過電話語音伺服器來提供。您可以在桌面收電子郵件，並透過電話接聽語音郵件。我甚至還沒用過傳真訊息呢！
透過 Exchange Server 2007 整合通訊，組織可以將電子郵件、語音及傳真資料傳遞至一個收件匣中，使用者便能透過 Outlook 和 OWA 存取這裏的所有資料。整合通訊還提供另一種方式：使用者可以透過 Outlook 語音存取，以電話方式存取語音郵件、電子郵件、連絡人及行事曆。
對系統管理員而言，整合通訊將 Exchange 和電話語音基礎結構結合，提供單一的儲存解決方案、單一的目錄以及單一的傳輸，從而簡化了訊息傳遞工作。當每個人只有一個信箱時，整體複雜性就降低了。
最棒的是什麽呢？這可以透過現有伺服器來完成。瞭解 Exchange Server 2007 和電話語音後，您的學習曲線就會相當平坦。整合通訊的功能與 Exchange 相整合，意味著您將使用相同的安全性模型和相同的收件匣。您甚至可以透過 OWA 存取語音郵件和傳真。
[圖 3] 顯示在安裝 Unified Messaging Server Role 之後，Exchange Server 2007 中整合通訊的架構。仔細看一下 (後面可能會有測驗)，然後讓我們詳細探討整合通訊的架構。
圖 3 整合通訊將語音、傳真及電子郵件通訊整合在一起
圖 3 整合通訊將語音、傳真及電子郵件通訊整合在一起
在企業中設定整合通訊功能時，有許多需要瞭解的基本要素。Exchange Server 包含代表電話語音硬體的物件。隨後可以在 Exchange Server 環境中定義這些物件的關係。Exchange Server 整合通訊系統物件包括 UM 伺服器、UM 撥號對應表、UM IP 閘道及 UM 群組搜尋，此外還有 UM 信箱原則和 UM 自動語音應答。以下讓我們看看每個物件的定義。
UM 伺服器物件建立於已安裝有 UM 伺服器角色的 Active Directory 中。透過它，管理員可以控制 Exchange Server 2007 整合通訊部署的設定和屬性。UM 撥號對應表是整合通訊中的基本管理單元，表示分機號碼的內部使用方法。撥號對應表中的所有使用者只需撥打分機號碼，即可與所有其他人聯繫。如果要與其他位置結合在一起，通常雙方都要有自己的撥號對應表。
UM IP 閘道物件代表實體的 VoIP 閘道或已啓用工作階段初始通訊協定 (SIP) 的 IP 專用交換機 (PBX)。整合通訊伺服器可以從 IP/VoIP 閘道裝置接收呼叫。UM 群組搜尋連結 IP 閘道與 UM 撥號對應表。在 PBX 設定群組搜尋後，就會在 Active Directory 中建立 UM 群組搜尋來代表它。您可以設定群組搜尋來提供跨 IP 閘道的負載平衡。這些閘道又會透過將一個 UM 群組搜尋與多個閘道相關聯，來提供負載平衡。UM 信箱原則類似於語音郵件服務類別，其中包括一個撥號對應表和若干用來為使用者和群組設定作業原則的屬性。
UM 自動語音應答可以與一個 UM 撥號對應表相關聯。它可以自訂來執行多種工作，例如針對不同日期和時間自訂的提示記錄和定義工作。自動語音應答的作用範圍可以透過通訊清單來設定。
[圖 4] 顯示這六個整合通訊物件的合作方式。
圖 4 整合通訊物件的互動
圖 4 整合通訊物件的互動

設定
一旦使用者有 Exchange Server 2007 信箱時，管理員必須針對整合通訊來啓用它。為此，管理員必須在撥號對應表中將信箱與一個 UM 信箱原則和一個分機號碼相關聯。此外，也必須將 PBX 設定為在出現 RNA (接通但無人接聽) 時將呼叫路由至整合通訊。PBX 會先將呼叫路由至使用者的分機。如果發生 RNA，則再將呼叫路由至 VoIP 閘道，然後路由至整合通訊伺服器。
整合通訊是可調整的。您可以根據業務量需要，增加任意多個電路交換式 PBX 通道和 UM 伺服器。使用 VoIP 閘道時，IP 式呼叫會被傳遞至 Exchange 整合通訊。由於這對許多企業來說是全新的功能，所以您應進行全面的網路分析，以確保 IP 網路有足夠的頻寬，得以同時處理資料和語音。
一般 Exchange Server 2007 整合通訊伺服器可以處理 50 到 200 個同時 IP 呼叫，以及最多 200 個傳入的語音和傳真呼叫 (預設為 100)。如果您需要更大的容量，或要提高容錯能力，可以擴建額外的整合通訊伺服器。

總結
至此您已經找到答案！Exchange Server 2007 提供兩個功能：Outlook Web Access 和整合通訊，這兩個功能共同為組織帶來非常多的好處。Outlook Web Access 可讓您從任何地方安全地存取電子郵件，整合通訊則可讓使用者存取最終都將進入 Exchange 2007 信箱的電子郵件、語音郵件、傳真訊息及其他信箱資料。

Joshua Trupin 是 MSDN Magazine 和 TechNet Magazine 的執行編輯。他為 MSJ、MIND、MSDN Magazine 及 TechNet Magazine 撰寫過許多文章；此外，著有 Hoop Stats:The Basketball Abstract 一書。


 Exchange Server 2007: Exchange 2007 更強大的日誌功能
Exchange Server 2007 David Strome

Exchange 2007 更強大的日誌功能
摘要:
  • Exchange Server 2007 日誌規則
  • 全新日誌精靈
  • 日誌報告的內容

您是否曾經要記錄特定使用者的往來電子郵件，但除了所要的郵件之外，還取得位於該信箱儲存區中
其他 300 個信箱的郵件？Microsoft Exchange Server 2007 提供您所需要的細微控制，解決了這個問題。
企業用戶端存取授權 (CAL) 提供的每個收件者日誌功能，可讓您鎖定要記錄的人員。藉由使用日誌規則，現在您可以只鎖定要記錄的收件者和寄件者。例如，焦點可以縮小為單一信箱，也可擴大包括整個部門的全體人員。而且，他們的信箱不必位在相同伺服器、相同 Active Directory® 站台，甚或相同的 Exchange 組織。透過 Active Directory 複寫，您的變更會自動套用至組織中執行 Hub Transport Server 角色的所有電腦。

日誌運作方式
在 Exchange Server 2003 中，日誌功能是在每個實體伺服器上的個別信箱儲存區實作的。如果要記錄組織中的所有信箱，您需要在每個信箱儲存區上設定日誌功能。如果要記錄單一收件者的郵件，您必須在該使用者的信箱儲存區中記錄所有人或特別為該使用者建立新的信箱儲存區。
Exchange Server 2007 的日誌功能利用 Exchange 中以角色為基礎的新拓樸。如 [圖 1] 所示，當所有郵件進出信箱伺服器和整合通訊伺服器、其他 Exchange 系統、協力廠商應用程式及網際網路時，它們都是由 Hub Transport 伺服器處理的。所有 Hub Transport 伺服器都包含一個稱為日誌代理程式的傳輸代理程式，它負責將日誌規則套用至郵件。由於日誌代理程式位於 Hub Transport 伺服器上，所以它會在郵件送達收件者之前先接觸每個郵件並對其評估。日誌代理程式會在分類之後對郵件發生作用，以確保對郵件所有收件者和寄件者屬性的存取權，而且允許代理程式判定郵件是直接傳送給收件者還是透過通訊群組擴充接收的。它還會分辨收件者是在源自 Exchange Server 2007 組織之郵件的 [收件者]、[副本]，還是 [密件副本] 欄。
圖 1 Hub Transport Server 郵件流程
圖 1 Hub Transport Server 郵件流程
當郵件通過 Hub Transport 伺服器時，日誌代理程式會對其套用管理員設定的日誌規則。這些規則決定代理程式是否將擷取某郵件的相關資訊，並且將此資訊與原始郵件一起轉寄至日誌信箱。此資料將以稱為日誌報告的郵件形式傳送。
在舊版的 Exchange，您必須將組態套用至多個伺服器。但當您在 Exchange Server 2007 中建立日誌規則時，該變更將透過 Active Directory 套用至組織中的所有 Hub Transport 伺服器。所有 Hub Transport 伺服器 (因此包括所有日誌代理程式) 都會從 Active Directory 讀取相同組態。所以，這全面涵蓋範圍確保所有日誌代理程式都套用相同的日誌組態。
當您建立或修改日誌規則時，請記住 Active Directory 複寫時間，因為組態變更必須在整個組織中複寫並由 Hub Transport 伺服器讀取。這可能會花費數小時。為了協助您識別日誌組態的更新時間，Exchange 會在每個伺服器的安全性事件記錄檔中記錄事件。
Exchange Server 2007 可確保日誌報告絕不會由於日誌信箱不可用、已滿、錯誤設定或離線而遺失 (這尤其有利於協助您遵守各種法律或法規要求，因為遺失的郵件可能導致違規)。如果日誌報告無法傳遞至日誌信箱，則該報告會保留在 Hub Transport 伺服器的佇列中，直到日誌信箱可用。由於這可能會導致佇列迅速膨脹，所以您應監視日誌信箱的可用性，以確保其正確運作。如果日誌信箱在長時間內無法使用，您可以設定替代信箱來接收佇列中的報告。

決定日誌內容
開始建立日誌規則之前，您需要清楚知道要鎖定的人員以及要記錄的資料類型。藉由在日誌規則中指定使用者，可以選取要記錄的特定使用者。例如，這些使用者可能受到法規要求的限制，也可能牽涉到必須收集電子郵件和其他通訊資訊做為證據的法律訴訟。
除了指定要記錄的收件者之外，您還可以決定要記錄的郵件範圍，選項有 [內部]、[外部] 及 [全域]。[內部] 只鎖定組織內部的郵件、[外部] 鎖定寄件者或其中一位收件者在外部的郵件，[全域] 則同時鎖定內部和外部郵件 (請注意，[全域] 選項會記錄通過 Hub Transport 伺服器的所有郵件，甚至包括那些可能已依照 [內部] 和 [外部] 範圍由規則處理過的郵件)。
Exchange Server 2007 支援整合通訊，因此您可以將 Exchange 設定成為收集使用者收件匣中的所有電子郵件、語音郵件及傳真。這也意味著您可以記錄所有這些資料，或選擇排除特定資料。
如果執行的 Exchange Server 2007 具有標準 CAL，您仍然可以使用每個信箱儲存區日誌功能。然而，如果要使用新增的每個收件者日誌功能，則必須升級至 Exchange Server 2007 Enterprise CAL。

日誌信箱的位置
決定要記錄的內容後，還需要決定日誌報告應傳送至何處。如果您有多個站台，在決定日誌信箱的位置時，必須考慮目前或計劃的網路拓樸。根據組織規模和信箱數量，日誌可能會產生大量的重複報告。
但也不一定要使用 Exchange 信箱，您可以將日誌報告傳送至任何有效的 SMTP 地址。此地址可以指向 Exchange Hosted Services、協力廠商存檔解決方案，或使用通訊群組的這兩者的任意組合。但請注意，日誌報告傳送到的位置可能有相關的安全性隱憂。
不論您決定將日誌信箱置於何處，都必須在 Active Directory 中為其建立收件者物件。這可以是 Exchange Server 2007 信箱、將郵件重新導向至 Exchange Hosted Services 或協力廠商存檔解決方案的具郵件功能的連絡人，或者是同時包含信箱和連絡人的通訊群組清單。

日誌報告的內容
當日誌代理程式記錄郵件時，它會盡量將有關原始郵件的詳細資料擷取至日誌報告中。然後，將此報告傳送至日誌信箱。此資訊在協助您判斷郵件意圖、收件者和寄件者方面非常重要。例如，在何處識別收件者 (其位址直接填寫在 [收件者] 欄位中、包括在 [副本] 欄位中，還是僅作為通訊群組清單的一部分) 有助於決定收件者在郵件討論串中的關聯性。原始郵件是做為附件包含在其中。[圖 2] 中的螢幕擷取畫面顯示兩個日誌報告，其中一個日誌報告指出傳送至 david@contoso.com 的郵件已轉寄給 christine@contoso.com，另一個日誌報告指出傳送至 Sales_Group@contoso.com 通訊群組的郵件已擴充，收件者 lukas@contoso.com (Sales Group 通訊群組的成員) 已收到該郵件。這兩個報告都將原始郵件做為附件包含在內，顯示原始寄件者為 brian@contoso.com，主旨為 "Sales forecast"。
圖 2 顯示已轉寄收件者和已擴充通訊群組收件者的日誌報告
圖 2 顯示已轉寄收件者和已擴充通訊群組收件者的日誌報告
Exchange 只對其已知為正確的資訊進行分類。無法自動判定的資訊會放入日誌報告的適當欄位中。[圖 2] 說明日誌報告內文中包含的欄位。

關於安全性
根據預設，相同 Exchange 組織中執行 Exchange Server 2007 的電腦之間的所有通訊都會加密。此加密包括日誌報告。Exchange Server 會執行下列動作，以降低日誌報告被竄改的風險：
  • 在 Exchange 2007 組織中，Hub Transport 伺服器和信箱伺服器之間使用安全連結。
  • 由 "Microsoft Exchange" 代表原始郵件的寄件者傳送日誌報告。
  • Hub Transport 與信箱伺服器之間的工作階段會經過驗證。
  • 在相同 Exchange 2007 組織中，Hub Transport 伺服器和信箱伺服器之間傳送日誌報告時，只接受已驗證的連線。
當您建立日誌信箱時，必須保護其安全性，因為該信箱包含組織中收件者的往來郵件。有些郵件可能是法律訴訟的一部分或受到法規要求的限制，而且許多法律都要求郵件在提交給調查單位之前不得經過竄改。為了增強日誌信箱的安全性，您應將日誌信箱設定成為只接受 Microsoft Exchange 寄件者的郵件，並且要求傳送至日誌信箱的所有郵件都應由已驗證的寄件者傳送。[圖 3] 顯示日誌信箱上設定的郵件傳遞限制。您也可以使用下列 Exchange 管理命令介面的命令來設定這些郵件傳遞限制：
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
圖 3 郵件傳遞限制
圖 3 郵件傳遞限制
如果要將日誌報告傳送至 Exchange Server 2007 組織之外的日誌信箱，則必須對 Exchange Server 2007 電腦與接收伺服器之間的連線進行手動加密，並保護其安全性。做法是，要求在兩個系統之間使用傳輸層安全性 (TLS)、要求在接收系統上進行驗證、在接收系統上只接受來自 Microsoft Exchange 收件者 SMTP 地址的郵件 (此 SMTP 地址類似於 Exchange_UMUnique GUID@contoso.com)、將用於轉寄郵件的 Active Directory 連絡人設定成為只接受來自 Microsoft Exchange 收件者的郵件。

實作日誌規則
說得夠多了，讓我們實作一些規則吧！日誌代理程式中的日誌規則可以在 Exchange 管理命令介面或 Exchange 管理主控台中進行設定。每個規則都可以用來設定收件者、範圍及日誌信箱設定。根據預設，日誌規則會在建立後隨即啓用。您指定的日誌電子郵件地址值必須是 Exchange Server 2007 組織中的現有收件者物件。此收件者物件可以是信箱、通訊群組、動態通訊群組或傳送郵件至 SMTP 地址的連絡人。
使用 Exchange 管理主控台時，[新增日誌規則] 精靈會引導您完成新日誌規則的建立程序。在 [組織組態] 區段中，選取 [Hub Transport Server role]。然後，在 [執行] 窗格中，按一下 [新增日誌規則]。您必須在這裡提供規則名稱、日誌電子郵件地址和範圍的值。如果要日誌規則記錄組織中所有收件者的郵件，則不需指定 [收件者] 欄位的值。您也可以選擇是否要日誌規則在建立後停用。[圖 4] 顯示將記錄 brian@contoso.com 的所有往來郵件的範例組態。已記錄的郵件會被傳送至名為 Compliance Mailbox 的日誌信箱中。
圖 4 新增日誌規則精靈
圖 4 新增日誌規則精靈
在 Exchange 管理命令介面中，您可以使用下列六個 Cmdlet 來管理日誌代理程式：
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
New-JournalRule Cmdlet 可讓您建立新的日誌規則。以這種方式建立新日誌規則的基本準則與使用精靈時相同。您必須指定 Name、Scope 及 JournalEmailAddress 參數的值。同樣地，如果要日誌規則記錄組織中所有收件者的郵件，則不需指定 Recipient 參數的值。如果要在建立日誌規則後將其停用，您必須為 Enabled 參數指定值 $False。如果要建立組態與[圖 4] 相同的日誌規則，請使用下列命令：
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
使用 Get-JournalRule Cmdlet 可檢視已建立的所有日誌規則的清單。單獨執行此 Cmdlet，會顯示組織中設定的所有日誌規則及其組態設定的摘要清單。如果要檢視有關日誌規則的所有可用資訊，您可以在 Get-JournalRule Cmdlet 和 Format-List Cmdlet 之間建立管道。管道會將它前方 Cmdlet 的輸出傳送至下一個 Cmdlet，好讓第二個 Cmdlet 對該輸出進行其他處理。例如，Format-List Cmdlet 會顯示其接收到的所有輸出。如果要檢視先前建立的日誌規則的所有相關資訊，請使用下列命令：
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
如果要啓用或停用日誌規則，您可以使用 Enable-JournalRule 和 Disable-JournalRule Cmdlet。使用這兩個 Cmdlet 時，必須在 Identity 參數中指定日誌規則名稱。例如，如果要停用剛剛建立的日誌規則，請使用下列命令：
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Set-JournalRule Cmdlet 可讓您修改現有的日誌規則。日誌規則的名稱與 Identity 參數搭配使用，告知日誌代理程式您要修改的規則。然後，指定 Recipient、JournalEmailAddress、Scope 或這些參數的任意組合，以及新值。例如，如果要修改已建立規則的 JournalEmailAddress 參數值，請使用下列命令：
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
最後，您可以使用 Remove-JournalRule Cmdlet 來移除現有日誌規則。使用 Identity 參數來指定日誌規則的名稱。如果要刪除範例日誌規則，請使用下列命令：
Remove-JournalRule "Brian Smith Journal Rule"
當您執行此動作時，Exchange 管理命令介面會詢問您是否確定要刪除該日誌規則。以下是最後一個提示：幾乎所有的 Cmdlet，您都可以省略 Identity 參數標籤，只指定參數值即可。

David Strome 擔任 Microsoft Exchange User Education 團隊的技術文件作者剛滿一年。在加入位於華盛頓州雷德蒙市的 Microsoft 之前，David 約有 10 年經歷，曾服務於加拿大卑詩省的多家公司，從事 Exchange Server 安裝的設計、實作和管理工作。他的連絡方式為：dstrome@microsoft.com。


 Exchange Server 2007: 利用寄件者識別碼抵制垃圾郵件和網路釣魚
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

利用寄件者識別碼抵制垃圾郵件和網路釣魚
摘要:
  • 寄件者識別碼基本概念
  • 在 Exchange Server 中設定寄件者識別碼
  • 驗證的好處

有鑒於因應日益加劇的垃圾郵件威脅，至今已開發了許多身分識別和篩選技術。這些技術主要憑藉著詢問一些與每封電子郵件有關的問題來發揮效用，例如
寄件者是誰。遺憾的是，寄件者是誰這樣的基本問題並非總是那麼容易回答。電子郵件通常透過網際網路傳送，而不會對寄件者或代表寄件者身分的電腦進行驗證。事實上，要假冒他人身分傳送電子郵件是非常容易的事情，而且也沒有辦法自動偵測詐騙郵件。
Simple Mail Transfer Protocol (SMTP) 係用於收發電子郵件，其設計初衷並不包括確認電子郵件的寄件者。由於存在此一技術漏洞，任何名稱和地址都可插入充當寄件者。因此，內容篩選或反垃圾郵件措施不能單靠標題資訊確保郵件的確來自其聲稱的位置。
電子郵件驗證專門防堵這個漏洞。有了驗證，電子郵件傳送和接收系統就都能驗證郵件是否來自寄件者聲稱的網域。這使得組織可以更加容易地有效篩選垃圾郵件，還能確保合法電子郵件送達預定的收件者。
目前，有兩種免費提供的方法可用於電子郵件驗證：寄件者識別碼架構 (SIDF) 和網域認證鑰匙識別郵件 (DKIM)。SIDF 是以網際網路通訊協定 (IP) 為基礎的解決方案，經由合併「寄件者原則架構」(SPF) 和「Microsoft 電子郵件呼叫者識別碼」而產生。2006 年 4 月，網際網路工程任務推動小組 (IETF) 頒布了寄件者識別碼規格 RFC 4405-4408。業界及業務利害關係者 (包括 Microsoft) 聯合建議基於以下因素部署 SIDF：業務和技術價值、穩定性、完備性、部署靈活性、對輸出或輸入效能的影響最小，以及與 ISP 和企業環境的電子郵件生態系統間的互通性。
DKIM 綜合了 Yahoo! 的「網域認證鑰匙」(DomainKeys) 規格和 Cisco Systems Inc. 的「網際網路識別郵件」(IIM) 規格。2006 年 1 月，IETF 正式批准成立 DKIM 工作小組，而該規格目前正由 IETF 進行審查。
儘管尚無完美的解決方案可抵制垃圾郵件，SIDF 代表了業界抵制詐騙網域的一大創舉。因此，這是降低垃圾郵件和網路釣魚攻擊、為線上活動增進信任和信心的關鍵元件。全世界採用 SIDF 的組織數目現正急劇上升。目前，發佈 SPF 記錄的公司和網域持有者總計已超過 550 萬，受到 SIDF 保護的使用者亦多達 6 億以上。現今全世界每天有三分之一以上的電子郵件都得通過驗證並遵循 SIDF。
如果沒有眾多組織及公司的貢獻和支持，就無法開發出 SIDF 並推廣至全世界，這些機構包括 AOL、Authentication and Online Trust Alliance (AOTA)、Bell Canada、E-Mail Senders Provider Coalition (ESPC)、CipherTrust、Cisco Systems、IronPort Systems、MarkMonitor、Port25 Solutions Inc、Sendmail、Symantec、TRUSTe、VeriSign 等。

瞭解寄件者識別碼
部分的業界調查結果顯示，有 95% 以上的網路釣魚詐欺郵件係來自詐騙網域，並且假冒寄件者的電子郵件地址。就是這一點使 SIDF 與反垃圾郵件處理有著偌大差異。SIDF 本身無法解決垃圾郵件的問題，但會極力減輕因受到垃圾郵件和網路釣魚攻擊而遭致的後果。SIDF 不會防堵垃圾郵件傳送。但是，它能使垃圾郵件更容易偵測。此架構可協助電子郵件寄件者保護其網域名稱、信譽及品牌。它所構建的結實基礎將依據寄件者的信譽和電子郵件習性做出篩選決策。
寄件者識別碼會設法驗證每封電子郵件是否源自其本身所聲稱的網際網路網域。實施方法為，檢查電子郵件寄件伺服器的位址，再與網域持有者所登記已獲授權傳送電子郵件的伺服器清單進行比對。網際網路服務提供者 (ISP) 或收件者的郵件伺服器會在郵件送達使用者的收件匣之前自動執行驗證。
請注意，寄件者識別碼或任何其他驗證機制均不應取代內容篩選系統。無論 SIDF 或 DKIM 都不會掃描實際郵件內容。反而，驗證程序會通知輸入郵件系統，郵件是否已證實來自其聲稱的寄件者。由於大多數垃圾郵件和網路釣魚入侵其實都不是來自其外顯的網域，此方法有助於自動識別這類郵件，並將之從內送郵件串流中分離出來。
在 SIDF 內，SPF 記錄提供一份純文字記錄，載明了所有與某網域關聯的輸出郵件伺服器，及其對應的 IP 位址。組織會將 SPF 記錄發佈到其 DNS 伺服器區域檔，供收件者郵件伺服器日後檢查。設定 SPF 記錄是既快速、容易而又免費的過程。「寄件者識別碼架構 SPF 記錄精靈」(Sender ID Framework SPF Record Wizard) 提供按部就班的操作程序，可檢查網域郵件伺服器並建立要準備發佈的自訂記錄 (有關如何發佈 SPF 記錄的詳細資料，請參閱 microsoft.com/senderid。您可以從 microsoft.com/senderid/wizard 直接存取該精靈)。
收件端 SMTP 伺服器會對 DNS 中網域的區域檔執行 ping 以檢查是否有 SPF 記錄。找到後，即檢查比對寄件伺服器的 IP 位址與記錄中所列的 IP 位址。若發現相符項目，則驗明該郵件並非假冒。要不然，如果寄件者的網域 SPF 記錄與郵件的來源 IP 位址不符，就算驗證失敗並給予負分評價，而該郵件可能會被放入垃圾郵件資料夾中。[圖 1] 顯示這整個過程。
圖 1 針對內送郵件檢查 SPF 記錄
圖 1 針對內送郵件檢查 SPF 記錄
標示郵件後，SIDF 會讓收件伺服器根據寄件人過去的習性、信譽、郵件內容或其他可依需要定義的條件來分析郵件。這項功能提供了額外的安全保障。例如，濫發垃圾郵件者可能會登記酷似的網域和 SPF 發佈記錄，而讓使用者和收件端網路受騙誤以為郵件來自合法的寄件者。但即使這類電子郵件能通過驗證檢查，寄件者濫發垃圾郵件惡名遠播就足以構成將郵件被封鎖、歸為垃圾或刪除的條件。

寄件者識別碼部署選項
透過 SIDF 驗證輸出電子郵件不需要變更任何基礎結構或更新軟體，且與用戶端或伺服器軟體並無特定關聯。然而，如果組織想要併行輸入驗證以保護公司和員工，就必須更新輸入系統和郵件傳輸代理程式 (MTA)，並部署可支援 SIDF 的軟體或設備。絕大多數頂級商用與開放原始碼的 MTA 和反垃圾郵件廠商 (包括 Microsoft® Exchange Server 及 Exchange Hosted Filtering) 都會提供整合方案。
Microsoft 已將 SIDF 整合至其所有郵件產品，包括 Microsoft Exchange Server 2003 Service Pack 2 (SP2)、Exchange Server 2007、Microsoft Exchange Hosted Filtering、Microsoft Windows Live™ Mail、MSN® Hotmail®、Outlook® Express 和 Office Outlook 郵件及協同作業用戶端。
但即使是 Microsoft 也同樣會收到垃圾郵件。Microsoft 每日平均內送流量約為 1500 萬封郵件，而在最近的垃圾郵件攻擊期間，我們發現流量已達到該流量的 2 至 4 倍。在這樣的環境下，成功抵制垃圾郵件的方法關鍵在於戒慎實施可行技術。
Microsoft 內部目前執行的 Exchange Server 反垃圾郵件方案，其建構基礎包含寄件者識別碼篩選 (於 Exchange Server 2003) 和寄件者識別碼代理程式 (於 Exchange Server 2007)。在這兩種 Exchange Server 版本中，寄件者識別碼狀態的評估是根據位在其對應 DNS 伺服器上的寄件者識別碼記錄。將依下列優先順序檢查 RFC 2822 郵件標題以判定實際網域：
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
寄件者的網域 (或最近負責將郵件導入郵件串流的實體，因為電子郵件系統可以合法地代表其他郵件伺服器轉寄郵件) 係依定義的順序找出上述標題的第一項定義來判定。如果找不到其中任何標題，SIDF 將使用 SMTP RFC 2821 MAIL FROM 值。

設定寄件者識別碼
在 Exchange Server 2007，寄件者識別碼代理程式可從已安裝「邊際傳輸」角色的伺服器上啟用。寄件者識別碼代理程式一經啟用，便會篩選透過接收連接器傳入的郵件；所有未經驗證的內送 (從外部來源) 流量都將交付寄件者識別碼處理。在 Exchange Server 2003，寄件者識別碼狀態可於 EXCH50 blob 伺服器之間永久保存，而此狀態在 Exchange Server 2007 也已附加到郵件中繼資料。抵達最終目的地後，兩者均轉換為 MAPI 內容，以供用戶端日後使用。
Exchange Server 2003 中的寄件者識別碼篩選組態 (位於 [郵件傳遞內容] 下) 僅限於指定 Exchange Server 如何處理失敗的驗證。
如果要在 Exchange Server 2007 啟用寄件者識別碼，只需開啟設有「邊際傳輸」角色的伺服器的 [Exchange 管理主控台]，選取 [反垃圾郵件] 索引標籤，再選取 [寄件者識別碼]，然後從 [動作] 窗格按一下 [啟用] 或 [停用] 以切換寄件者識別碼代理程式的狀態，如 [圖 2] 所示。另外，您可以利用 Exchange 管理命令介面來啟用或停用寄件者識別碼，如 [圖 3] 所示。
圖 2 在 Exchange Server 2007 使用 [Exchange 管理主控台] 控制寄件者識別碼代理程式的狀態
圖 2 在 Exchange Server 2007 使用 [Exchange 管理主控台] 控制寄件者識別碼代理程式的狀態
圖 3 利用 Exchange 管理命令介面啟用寄件者識別碼
圖 3 利用 Exchange 管理命令介面啟用寄件者識別碼
[寄件者識別碼內容] 對話方塊將反映代理程式的狀態 (啟用或停用)。[動作] 索引標籤則提供了與 Exchange Server 2003 非常類似的選項 (請參閱 [圖 4])。
圖 4 Exhange Server 2007 中的寄件者識別碼代理程式動作內容
圖 4 Exhange Server 2007 中的寄件者識別碼代理程式動作內容
以寄件者識別碼實作和功能方面來講，Exchange Server 2003 和 Exchange Server 2007 並無太大差異，且寄件者識別碼篩選 (於 Exchange Server 2003) 和寄件者識別碼代理程式 (於 Exchange Server 2007) 使用相同的基礎演算法進行抽選和驗證。可行的動作範圍也都一樣：刪除郵件 (逕自刪除)、拒絕郵件 (500 等級 SMTP 通訊協定回應)，以及為郵件加上寄件者識別碼結果戳記後繼續處理。兩種 Exchange Server 版本均以最後一項為預設動作選項。
在 Exchange Server 2007，FAIL 和 TempError 狀態碼皆可觸發「拒絕郵件」動作 (在 Exchange Server 2003 只有 FAIL 狀態碼可以觸發此動作)。寄件者識別碼代理程式必須明確設定為對具有 TempError 狀態碼的郵件觸發「拒絕郵件」動作，因為預設情況下會允許這些郵件進入系統，加上寄件者識別碼結果戳記後繼續處理。
圖形使用者介面並未顯露有關此設定的選項，所以您必須利用 Exchange 管理命令介面針對 TempError 狀態碼設定寄件者識別碼動作。例如，若要強制寄件者識別碼代理程式拒絕具有 TempError 狀態碼的郵件，請執行下列的寄件者識別碼代理程式 Cmdlet：
Set-SenderIDConfig -TempErrorAction Reject
Exchange Server 2007 中的寄件者識別碼狀態結果和可行的動作範圍，與 Exchange Server 2003 寄件者識別碼篩選差不多，如 [圖 5] 所示。
Figure 5 Exchange Server 2007 中的寄件者識別碼狀態和動作 (Close Figure 5)

寄件者識別碼狀態 | 說明 | 動作
Neutral | 所發佈的寄件者識別碼資料尚無明確定論 | StampStatus
Pass | IP 位址屬於許可集 | StampStatus
Fail | IP 位址屬於非許可集 | StampStatus、Delete 或 Reject
SoftFail | IP 位址可能屬於非許可集 | StampStatus
None | 尚無發佈的資料 | StampStatus
TempError | 暫時性錯誤，例如 DNS 伺服器失聯 | StampStatus 或 Reject
PermError | 無法復原的錯誤，例如記錄格式錯誤 | StampStatus
Exchange (若已設定這麼做) 將只刪除寄件者識別碼驗證失敗的郵件。其他任何結果都不會觸發郵件刪除。結果狀態為 Neutral、None、SoftFail、TempError 或 PermError 的內送郵件將加上對應戳記，再繼續傳遞做進一步的反垃圾郵件驗證。在某些情況下，當郵件已完全異常且 FROM IP 位址遺失時，郵件即無法加上寄件者識別碼狀態戳記。此時，郵件不會被丟棄或拒絕。反倒是，郵件將以沒有設定寄件者識別碼狀態的情況，繼續傳遞做進一步處理，並且記錄對應事件以引起注意。
在 Exchange Server 2007，要定義不該進行寄件者識別碼驗證的寄件者網域和 Exchange Server 收件者很容易。同樣地，您只能透過 Exchange 管理命令介面設定這個選項。例如，若要排除網域 contoso.com 不進行寄件者識別碼篩選，請執行下列命令：
Set-SenderIDConfig -BypassedSenderDomains contoso.com
再來，執行下列命令可以將傳送給 Exchange Server 指定收件者的郵件排除不進行寄件者識別碼篩選：
Set-SenderIDConfig -BypassedRecipients user@contoso.com
在 Exchange Server 2007，可藉由從 Exchange 管理命令介面執行 Get-SenderIDConfig 命令輕鬆取得因圖形使用者介面沒有提供，而必須透過 Exchange 管理命令介面 Cmdlet 設定的寄件者識別碼組態值，如 [圖 6] 所示。
圖 6 寄件者識別碼組態 Cmdlet
圖 6 寄件者識別碼組態 Cmdlet
利用 Exchange 管理命令介面可迅速手動驗證 IP 位址和對應的網域名稱。執行下列命令即可檢查寄件者識別碼狀態：
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
若網域不存在，結果看起來就像 [圖 7]。
圖 7 驗證特定位址的寄件者識別碼狀態
圖 7 驗證特定位址的寄件者識別碼狀態

寄件者識別碼的好處
除了可驗證電子郵件及減少使用者收到的垃圾郵件份數等明顯的好處外，形同通訊協定的 SIDF 還提供其他優點。在開發期間，Microsoft 特別留意了幾個重要目標，包括效能、成本、部署和延展性以及互通性。
SIDF 會先驗證電子郵件寄件者，並考慮到為寄件者的信譽打分數。藉此，其潛在既可使垃圾郵件和詐騙電子郵件的數目明顯減少，又能提升來自受信任及已知寄件者的合法電子郵件傳遞能力。建立 SPF 記錄不必支付費用，所以任何想要遵循 SIDF 的組織都能隨手建立。希望遵循新標準中各項條款的組織大致上也沒問題。有了 SIDF，遵循標準就像發佈 SPF 記錄一樣簡單。
SIDF 已開發成儘可能搭配現有的軟體執行，包括各式各樣的電子郵件架構和用戶端及伺服器軟體。為求發揮功效，任何驗證服務都必須能夠符合最大規模 ISP 的需求，就跟符合最小型家用郵件伺服器的需求一樣容易。SIDF 可支援一部到上千部的電子郵件伺服器，以及那些將其電子郵件伺服器外包給其他組織的郵件伺服器。
2007 年 4 月 18 日和 19 日，Microsoft 與包括 30 多個組織及合作夥伴在內的同業協會將於麻州波士頓舉辦「Authentication & Online Identity Summit」活動。這個為期兩天的活動將討論案例研究和寄件者識別碼技術，同時詳談電子郵件驗證的商業價值。如需詳細資訊，請造訪 aotalliance.org/summit2007。此外，在 microsoft.com/senderid 和 microsoft.com/exchange 提供了包括工具和資源的相關資訊。

Craig Spiezle 是 Microsoft Windows Live Safety 技術策略和規劃方面的主管。身為電子郵件驗證的產品經理，Craig 已成為將寄件者識別碼引入該行業的驅動力。Craig 於 1992 年加入 Microsoft，曾擔任過多項管理職務，包括國際行銷、產品支援策略、OEM 和新市場開發。
Alexander Nikolayev 是 Microsoft 程式經理，主掌事務囊括 Exchange Server 及 Windows Server 的伺服器端通訊協定、傳輸核心和反垃圾郵件元件。他擁有瑪莉大學的 MBA 學位。請閱覽 Alexander 在 Exchange 小組部落格發表的文章，網址為 blogs.technet.com/exchange (英文)。


 編輯的話: 延伸觸角
編輯的話
延伸觸角

TECHNET MAGAZINE 現在不只是 廣受好評的書面刊物。我們的團隊一直為建立創新網站而努力不懈，以使全球讀者能夠超過十億。從本刊 11 月號起，在線上提供每篇文章的七種語言版本：英文、西班牙文、法文、德文、俄文、簡體中文和巴西葡萄牙文。藉由新增六個語言 (原先已提供線上英語版本)，母語讀者增加了 16 億之多。太不可思議了！
但我們不因此而滿足現狀，接著又增加一組功能，讓網站可用性更強。新增的可自訂 RSS 摘要可讓您依日期、專欄、作者或主題來選取內容，甚至可以混搭。請立即瀏覽 technetmagazine.com/rss，開始建立您專屬的摘要。
我們也導入新主題頁面。如需有關 IT 專業人員對 Windows Vista 各項準備工作的詳細資訊，請瀏覽 technetmagazine.com/vista。如果您是郵件管理員，一定要瀏覽 technetmagazine.com/exchange。technetmagazine.com/topics 提供 32 個研究主題，陸續還會提供更多 (截至 11 月，我們已提供 43 篇有關安全性的文章，以供您查看)。
但不止於此，現在您可以更深入洞察本雜誌以及 IT 專業領域。Joshua Hoffman 是 TechNet Magazine 的技術和徵稿編輯，在 blogs.technet.com/tnmag 主持本雜誌的部落格。而筆者則主持本網站每月的 Podcast，網址為 www.technetmagazine.com/podcasts。每期，我將與作者對談，說明文章背後的道理。希望您會喜歡這些一流作者就文章和工作的討論。
我們將繼續全力以赴，打造 TechNet Magazine 成為世上最適合 IT 專業人員的實用資源。很高興在 2006 年交出不錯的成績單，但是我們還是希望得到您的寶貴意見。若有任何意見，歡迎來信！我們的編輯熱線是 tnmag@microsoft.com。此意見信箱將永遠為您開啟。
—JOSHUA TRUPIN

感謝下列 Microsoft 技術專家：Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher 及 Scot Vidican。


 工具箱: 向 IT 專業人員推薦的新產品
工具箱
向 IT 專業人員推薦的新產品
Greg Steen

Web 應用程式的壓力測試
WAPT Web 應用程式壓力測試工具
www.loadtestingtool.com (英文)
瞭解您的最新版 Web 應用程式執行狀況非常重要，這關係到您能否正確調整基礎結構規模，免於面臨 CEO 質問您在測試網站時為何會看到「伺服器忙碌中」的回應之類令人高度緊張的時刻。而且，如果您在尋找價格相對低廉、簡單易用的 Web 應用程式壓力與效能測試工具，則可能會想試試 SoftLogica LLC 的 WAPT 4.0。
此應用程式可執行於大多數的 Windows® 版本，但要發揮其所有潛能最好使用 Windows 2000、Windows XP 或 Windows Server® 2003，因為舊版作業系統存在 Socket 限制。與大多數採用虛擬使用者的效能測試應用程式一樣，記憶體愈多處理器速度會愈快，且網路連線數目愈充足，能夠使用 WAPT 模擬的虛擬使用者人數就愈多。
產品文件中指出，配備 512MB RAM 和 gig-e 介面的 PIV 2.4，其虛擬使用者人數上限約為 2,000 位，但仍取決於您所測試的應用程式類型及測試設定檔的設置情形。測試會隨之而異的另一項因素是要求之間的延遲，WAPT 可讓您在虛擬使用者的設定檔中，將此因素設定為使用者花在思考上的時間。
一旦您完成了虛擬使用者設定檔的設置 (每次測試都能設置多種案例)，便可為該設定檔建立測試計劃。WAPT 將測試順序分成三部分：初始 (Initial)、主要 (Main) 和最終 (Final) 活動。這比較像是邏輯上而非功能上的劃分，儘管廠商建議將登入或註冊功能歸為初始部分，將登出活動歸為最終部分。WAPT 允許您手動輸入要求，或使用整合式瀏覽記錄器，依您希望特定設定檔的使用者瀏覽網站的方式產生瀏覽軌跡。接著，您可以轉到一般設定來確認該項測試的負載，以及是要將負載固定還是在指定時段內逐漸增加負載量。在測試期間，WAPT 可為您提供測試案例的效能統計即時檢視。看完統計資料後，您可以將結果儲存為 HTML 或 CSV 供日後審閱。
價格：每部電腦 $350 美元。
瞭解您的最新版 Web 應用程式執行狀況非常重要，這關係到您能否正確調整基礎結構規模，免於面臨 CEO 質問您在測試網站時為何會看到「伺服器忙碌中」的回應之類令人高度緊張的時刻。而且，如果您在尋找價格相對低廉、簡單易用的 Web 應用程式壓力與效能測試工具，則可能會想試試 SoftLogica LLC 的 WAPT 4.0。
此應用程式可執行於大多數的 Windows® 版本，但要發揮其所有潛能最好使用 Windows 2000、Windows XP 或 Windows Server® 2003，因為舊版作業系統存在 Socket 限制。與大多數採用虛擬使用者的效能測試應用程式一樣，記憶體愈多處理器速度會愈快，且網路連線數目愈充足，能夠使用 WAPT 模擬的虛擬使用者人數就愈多。
WAPT Web 應用程式壓力測試工具
WAPT Web 應用程式壓力測試工具
產品文件中指出，配備 512MB RAM 和 gig-e 介面的 PIV 2.4，其虛擬使用者人數上限約為 2,000 位，但仍取決於您所測試的應用程式類型及測試設定檔的設置情形。測試會隨之而異的另一項因素是要求之間的延遲，WAPT 可讓您在虛擬使用者的設定檔中，將此因素設定為使用者花在思考上的時間。
一旦您完成了虛擬使用者設定檔的設置 (每次測試都能設置多種案例)，便可為該設定檔建立測試計劃。WAPT 將測試順序分成三部分：初始 (Initial)、主要 (Main) 和最終 (Final) 活動。這比較像是邏輯上而非功能上的劃分，儘管廠商建議將登入或註冊功能歸為初始部分，將登出活動歸為最終部分。WAPT 允許您手動輸入要求，或使用整合式瀏覽記錄器，依您希望特定設定檔的使用者瀏覽網站的方式產生瀏覽軌跡。接著，您可以轉到一般設定來確認該項測試的負載，以及是要將負載固定還是在指定時段內逐漸增加負載量。在測試期間，WAPT 可為您提供測試案例的效能統計即時檢視。看完統計資料後，您可以將結果儲存為 HTML 或 CSV 供日後審閱。
價格：每部電腦 $350 美元。

書評
Content Networking Fundamentals
www.ciscopress.com (英文)
內容稱霸，由 Silvano Da Ros 所著 Content Networking Fundamentals 一書 (Cisco Press，2006) 可協助您在增強內容傳遞基礎結構的快速追蹤方面進展順利。本書標註自稱其為「對內容網路的理論和實際應用做最全面性的介紹」，而事實上也的確如此。雖然本書明顯偏愛 Cisco 的網路設備，您還是能徹底窺探內容網路的各種元件，以及實作內容網路原則的實務指導方針，不論基礎結構中的內容網路產品屬於何種類型均一體適用。
本書一開場即從制高點針對內容網路的各種要素做了一番概述 (著實可增進 OSI 模型第 4 層到第 7 層通訊的效能與傳遞能力)。接著則是探究主要內容表現格式 (如 XML、HTML、WAP) 的具體細節，及透過 XSLT 於網路邊際進行內容轉換，還有一節專門討論串流媒體傳遞。最後，本書切入討論延展性和可用性，所涉領域包括伺服器負載平衡 (全面和局部)、防火牆負載平衡，以及內容快取裝置 (如 Cisco 的內容服務交換器) 的功用。
如果您的基礎結構使用了 Cisco 的內容服務交換器，應會對探討「交換安全內容」那一章特別感興趣。該章詳盡介紹了安全通訊端層 (SSL) 的內容服務模組規劃，以及設定 URL 和標頭改寫的細節。大致上，忠於品牌的任何網路專業人士都會覺得 QoS 專章有助於理解各式佇列機制和網路壅塞管理。
總之，縱使架設 Cisco 硬體設施的確非常困難 (畢竟出版商是 Cisco Press)，本書會盡力協助您將「內容網路」這個術語化為實際可行的方法，應用於您的內容傳遞基礎結構。
價格：$55.00.

監控服務
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp (英文)
有一件事情既可樹立也能破壞 IT 專業人員的形象，那就是能否比組織內的一般使用者更早偵測到 (但願還能修復) 問題。因此，IT 專業人員最重要的工具之一就是一套有效的監控系統，能夠深入檢測提供的各項服務正常運作與否。ExclamationSoft 的 WebWatchBot 即屬於這樣的系統。
此應用程式可以監控您想得到的每一項常用服務。WebWatchBot 不僅確認服務是否執行，還進行更深入的檢測。它將對服務實際進行測試，以確保服務正常運作。例如，FTP 驗證會真的上載和下載檔案，DNS 監控可以執行 40 種不同的查詢命令並在回應中搜尋字串，POP3 和 SMTP 測試則會實際記錄並回報郵件效能。
WebWatchBot
此外，WebWatchBot 還能讓您鏈結一連串交易步驟，並會回報整筆交易發生的任何錯誤或令人無法接受的延遲 (可接受程度依您設定的閾值而定)。此應用程式也將監控 HTTP 和 HTTPS URL 並可查核指定的內容。您甚至可以設置資料庫監控，使之執行查詢並對照範本回應來檢查資料。
價格：每一份使用者授權 $495.95 美元。

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


 Windows PowerShell: 命令精簡，管理能力超強
Windows PowerShell
命令精簡，管理能力超強
Don Jones
本專欄是根據 Windows PowerShell 的搶鮮版 (Prerelease Version) 所撰寫。本文包含的所有資訊均有可能變更。

經歷了漫長的等待之後，Windows PowerShell 終於已蓄勢待發。這意味著該是 Windows 系統管理員提起注意的時候了。Windows PowerShell 提供了也許是最簡單亦最靈活自動化各式系統管理工作的方法，從而使您的工作效率和成效都獲得提升。
但更重要的是，Microsoft 目前正積極在 Windows PowerShell™ 之上建構 Exchange Server 2007 和 System Center 2007 等產品的圖形化系統管理主控台。這意味著您將能夠從 Windows PowerShell 內部執行幾乎所有的系統管理工作。Microsoft 計劃循同樣方式逐年改進更多產品的系統管理能力。因此，Windows PowerShell 終將成為首創用於管理幾乎所有 Microsoft 伺服器產品的全方位工具。為了協助您盡快入門，我將在此新設的專欄中定期探討 Windows PowerShell。請務必下載這份軟體 (英文)。

強大而又簡易
顧名思義，Windows PowerShell 是一種殼層，與自從 Windows NT® 3.1 問世起就有的命令提示字元 (Cmd.exe) 並無不同。Cmd.exe 不會銷聲匿跡，但隨著 Windows PowerShell 的到來，幾乎沒有什麼理由再繼續使用 Cmd.exe。
Windows PowerShell 在使用上與 Cmd.exe 並無多大差異，只是不可諱言，Windows PowerShell 的功能更為強大。和 Cmd.exe 一樣，Windows PowerShell 內建指令碼語言，不過它比 Cmd.exe 原始的批次處理語言更靈活。到底有多靈活？有了 Windows PowerShell，您可以使用僅包括大約不到十個內建關鍵字的語言自動化極其複雜的工作。
既然我已提到了指令碼，那麼現在大概就該來談一下安全性。Windows PowerShell 受惠於 Microsoft 在過去十多年長期研究安全性的成果。預設情況下，Windows PowerShell 並不執行指令碼，而只能用於以互動式執行個別命令。如果您確實啟用了指令執行，則可指示 Windows PowerShell 僅執行已經過數位簽署的指令碼。這一切是為確保 Windows PowerShell 不致演變成下一個 VBScript：表現優異卻屢遭濫用建立惡意指令碼的語言。VBScript 也不會告別歷史舞台，但您應會發現使用 Windows PowerShell 處理諸多各式工作更加容易。
Cmd.exe 辦得到的事情，Windows PowerShell 幾乎都能辦到。例如，您可以執行 ipconfig 而得到極為眼熟的相同輸出。但 Windows PowerShell 引進了一組不屬於外部可執行檔的全新命令。這些 Cmdlet (發音為 "command-let") 內建於 Windows PowerShell 中 (如需 Windows PowerShell 最實用的幾個入門 Cmdlet，請參閱「快速使用入門之前十大 Cmdlet」資訊看板)。
快速使用入門之前十大 Cmdlet
  • Get-Command 擷取所有可用 Cmdlet 的清單。
  • Get-Help 顯示 Cmdlet 的相關說明資訊和概念。
  • Get-WMIObject 擷取使用 WMI 所提供的管理資訊。
  • Get-EventLog 擷取 Windows 事件日誌。
  • Get-Process 擷取單一處理序或作用中處理序的清單。
  • Get-Service 擷取 Windows 服務。
  • Get-Content 讀取文字檔的內容，每一行視為一個子物件。
  • Add-Content 在文字檔結尾附加內容。
  • Copy-Item 複製檔案、資料夾及其他物件。
  • Get-Acl 擷取存取控制清單 (ACL)。
如需 Windows PowerShell 所附 Cmdlet 的完整清單，請前往 windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx (英文)。
所有 Cmdlet 均以標準的「動詞-名詞」格式命名，因此既容易理解又好記。例如，執行 Get-Command Cmdlet 將列出所有可用的 Cmdlet。對系統管理員來說，最有用的 Cmdlet 大概是 Get-WMIObject。若您想要查明 Server2 執行了哪一版的 Service Pack，只需執行：
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
如果換成使用 VBScript 要查出同樣的資訊，就得撰寫好幾行程式碼。使用 Cmdlet 還能處理服務 (Start-Service、Stop-Service 等)、處理序 (Stop-Process 等)、檔案 (如 Rename-Item、Copy-Item、Remove-Item、Move-Item) 及其他項目。這些 Cmdlet 甚至大多都有捷徑名稱，稱為「別名」。比方使用 Get-WMIObject 時，您可以只輸入 gwmi。執行 Get-Alias 即可取得這些捷徑名稱的清單。

物件導向為何舉足輕重
Windows PowerShell 係建構在 Microsoft® .NET Framework 的基礎上，因此徹底屬於物件導向。通常，只有軟體開發人員才會對此感興趣，但是就本專欄主題而言，物件導向能夠為系統管理員節省大量時間。這是因為系統管理員如今可以直接在文字架構的殼層內使用豐富的物件。請看以下範例：
Get-Process | Sort-Object pm –desc | Select-Object –first 10
此範例只有一行，內含三個以管線分隔、互不相同的 Cmdlet (稍後將詳細介紹管線)。第一個 Cmdlet 擷取所有執行中的處理序，然後將這些物件傳遞給 (經管線輸送到) Sort-Object。第二個 Cmdlet 則將每個處理序物件依其 pm (代表「實體記憶體」) 屬性進行遞減排序。排序後的處理序物件集合接著經管線輸送到 Select-Object，而由後者選出前 10 個物件並加以顯示。結果呢？這麼簡單的一行命令會顯示電腦上耗用最多實體記憶體的前 10 個處理序，如 [圖 1] 所示。此為極其有效的速查方法，可協助進行若干疑難排解。
圖 1 利用簡單的 Cmdlet 進行疑難排解
圖 1 利用簡單的 Cmdlet 進行疑難排解
管線 (垂直線字元，在美式鍵盤上通常與反斜線共用同一個按鍵) 的使用是造就 Windows PowerShell 具備此等能力不可或缺的一部分。使用這個字元，您可以在 Cmdlet 之間傳遞 (經管線輸送) 物件，而讓每個 Cmdlet 進一步精簡結果、設定結果的顯示格式等等。此機制能夠運作是因為每個 Cmdlet 均傳回一或多個物件而非純文字，以致全然交付物件供後續的 Cmdlet 進行處理。
Windows PowerShell 使用物件的情況非常普遍，乃至就連變數也一樣。您甚至不必預先宣告變數，只需在變數名稱前面加上貨幣符號 ($) 即可開始使用變數。儘管並非絕對必要，您也可以告知 Windows PowerShell 要在變數中儲存何種資料型別。這使得 Windows PowerShell 可將變數對應到任何一種極其強大的 .NET Framework 型別，進而給予您許多額外的內建功能。例如，假設您要提示輸入電腦名稱，以擷取該電腦的 Service Pack 版本，但您並不知道所輸入的電腦名稱是否包含兩個反斜線 (比方 \\Server2)。由於您知道 Get-WMIObject Cmdlet 不需要反斜線，那麼就可將電腦名稱儲存到 String 變數，再使用 Replace 方法以空字串取代反斜線，如下所示：
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
–Computer 參數的值已由 $c 變數提供。該變數最初係建立為字串，故具備 .NET Framework String 型別的所有功能，包括 Replace 方法。當然，要瞭解所有這些功能必得花些時間，但您應可經由範例輕鬆掌握各種訣竅。Windows PowerShell 本身亦有助於縮短學習時程。例如，若您輸入 $c = $c. (別忘了句號) 再按 Tab 鍵，Windows PowerShell 將會顯示 Clone()，也就是 String 型別的第一個方法。如果您不斷按 Tab 鍵，Windows PowerShell 則會循環顯示所有可用的方法。實質上，當您做這個動作時，Windows PowerShell 是在向您展示它所知道的 String 處理方法！
在此舉出一項更難的工作：從檔案讀取電腦名稱的清單 (每個名稱各佔一行)，然後顯示每部電腦的 Service Pack 版本號碼。使用 VBScript 完成這項工作需要十幾行程式碼。而 Cmd.exe 則必須使用複雜的批次檔。但在 Windows PowerShell 中，這項工作僅需一行：
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Get-Content Cmdlet 會讀取 C:\Computers.txt 的內容。檔案中的每一行均自成一個物件。由這些物件 (即電腦名稱) 構成的集合則經管線輸送到 foreach 命令 (其實就是 ForEach-Object Cmdlet 的別名)。大括號內的命令會對經管線送入的每個物件各重複一次 (在本例中即意味著對每個電腦名稱各執行一次)。特殊變數 $_ 將包含目前物件 (即當前電腦名稱)。
大括號內其實有兩個命令：前者只是藉由輸出 $_ 的內容以顯示當前電腦名稱，後者則是剛才介紹過的 gwmi。其結果為檔案中所列每一部電腦的 Service Pack 版本構成的清單。這一切全是使用一行相對簡單的命令所完成。
請注意，–Property 和 –Computer 參數名稱都使用了縮寫。Windows PowerShell 僅要求足以唯一識別參數名稱就沒問題。

可讀性與重複使用
然而，單僅撰寫一行命令加上幾個參數卻大大地降低了可讀性。Windows PowerShell 允許您將單一命令拆解成更具可讀性的形式，您甚至不必撰寫指令碼就能將其直接輸入殼層。拆解後的形式大致如下：
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
這時，檔案的內容儲存在 $names 變數中。本範例依舊使用 foreach，但其輸入並非經管線取得，因此您必須向其告知該循環處理哪個物件集合，以及每個物件儲存在哪個變數中，即 ($name in $names) 這一部分的寫法。其餘部分則基本維持不變，當您按下 Enter 後，程式碼就會執行並顯示結果。
如果您想重複使用上述程式碼，只要將其寫成函數即可。再次將下列內容直接輸入殼層：
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
如您所見，實際上並無多大改變。這裡只是將前一範例的程式碼封入名為 Get-ServicePacks 的函數而已 (函數名稱沿用 Windows PowerShell 的「動詞-名詞」命名慣例)。此函數如今已有輸入參數 $file，而該參數在傳給 Get-Content Cmdlet 後即遭替換，所以每次執行函數都可指定不同的檔案。函數定義完成後，要執行的話很簡單，寫法與 Cmdlet 大致相同，只需呼叫其名稱並傳遞輸入參數即可：
PS C:\> Get-ServicePacks c:\computers.txt
結果如 [圖 2] 所示。
其缺點在於此函數會隨著目前執行中的 Windows PowerShell 執行個體終結而不復存在。一旦關閉殼層，函數即告消失。您可以將函數複製到您的 Windows PowerShell 設定檔，這是一種自動執行的指令碼，會在 Windows PowerShell 每次啟動時執行。如此一來，您就能在每個開啟的 Windows PowerShell 視窗中執行特定函數。或者，您亦可視需要將函數寫成獨立指令碼，屆時只需輸入指令碼的路徑和檔名即可執行函數。
圖 2 執行 Get-ServicePacks 函數的結果
圖 2 執行 Get-ServicePacks 函數的結果

舉目所見盡是檔案 (或資料夾)
若說 Windows PowerShell 只有函數和 Cmdlet 那就太小看它了。讓我們以檔案管理為例來快速瞭解一下其中還蘊藏著哪些瑰寶。您可能對 Cmd.exe 中的磁碟機和資料夾巡覽再熟悉不過了：輸入 C: 可切換到 C 磁碟機，再輸入 cd \test 則可轉入 C:\Test 資料夾。Windows PowerShell 的操控方式完全相同，不過 cd 只是 Set-Location Cmdlet 的別名。
請試著執行 Get-PSDrive Cmdlet 列出所有可用的磁碟機。除了常見的 C:、D: (可能還有 A:) 磁碟機之外，您也將發現其他的具名磁碟機，諸如 Cert、Env 以及 HKCU 和 HKLM。實際上，Windows PowerShell 將許多不同的儲存體資源以「磁碟機」形式公開，使得一些事物如本機憑證存放區、環境變數和登錄等皆可透過像檔案那樣眾所熟悉的巡覽介面來存取。
要切換到 HKEY_LOCAL_MACHINE 登錄 Hive 的話，請輸入 Set-Location HKLM: (或 cd hklm:，若您慣用捷徑) 然後按 Enter。接著執行 cd software\microsoft 再轉入 SOFTWARE\Microsoft 機碼。您可以使用 dir (Get-ChildItem Cmdlet 的別名) 列出位於此登錄部分的子機碼。如要移除某個機碼，請使用 del 將其刪除，就像該機碼是檔案或資料夾一樣 (不過一定要非常小心；若是移除了系統所需的機碼或對登錄進行了不當修改，可能會發生嚴重問題)。
以上各種彈性均拜提供者所賜，端賴其將資源 (比方登錄和憑證存放區) 對應成類似於檔案系統的格式。Microsoft 計劃透過更多提供者繼續擴充 Windows PowerShell，例如，讓您能將 Exchange Server 儲存區視同檔案系統進行巡覽。這是一項非常重要的技術，關鍵就在於它納入了 Windows 所使用難以勝數的各種存放庫，並使其均以同樣方式呈現，而且您將能夠透過既已熟悉的命令和技術體系來管理這一切。

安全性設計
我已提到過 Windows PowerShell 在設計上很注重安全防護。Windows PowerShell 主要的安全性功能是其執行原則。依預設，此原則訂為 Restricted (受限制)，這可經由執行 Get-ExecutionPolicy Cmdlet 獲得證實。在 Restricted 模式下禁止執行指令碼，就這麼簡單。由於此為預設模式，Windows PowerShell 先天上無法用於執行指令碼。
您可以使用 Set-ExecutionPolicy Cmdlet 指定其他模式。我個人較偏好 RemoteSigned (遠端簽署) 模式。在此模式下可執行未經數位簽署的本機指令碼 (不包括遠端指令碼)，因此最方便從事指令碼的開發及測試。AllSigned (全已簽署) 模式則不會執行任何指令碼，除非指令碼使用了由受信任發行者核發的憑證進行數位簽署。最後，採用 Unrestricted (沒有限制) 原則將可執行所有指令碼。我建議千萬不要採用此原則，因為這極有可能導致 Windows PowerShell 執行惡意指令碼，無異於敞開大門歡迎其入侵您的電腦。請注意，執行原則也可能受群組原則所掌控，因為群組原則將覆蓋任何的本機設定 (當群組原則即將覆蓋您的本機設定時，Set-ExecutionPolicy 會提出警告)。
此外，若沒有指定當前目錄的路徑，Windows PowerShell 就不會從該處執行指令碼。這樣設計是要防止命令遭綁架。例如，某人建立了名為 IPConfig.ps1 的指令碼 (PS1 是 Windows PowerShell 指令檔的副檔名)。如果不必指定當前資料夾就可執行檔案，則您可能因輸入 ipconfig 而執行了該員建立的指令碼，但其實您是想要執行 Windows 程式 Ipconfig.exe，到頭來卻無端遭致危險。由於 Windows PowerShell 只會執行已指定當前資料夾位置的指令碼，這種錯誤便不可能發生。若您的確想從當前資料夾執行指令碼，只需指定路徑即可：例如，輸入 .\myscript。明確參考當前資料夾可確保您已知所要執行的是指令碼而非殼層命令。
Windows PowerShell 還提供幾個可讓您放心實驗的功能。例如，請看 (但「切莫」嘗試) 這個可怕的組合：
Get-Process | Stop-Process
Get-Process Cmdlet 會建立處理序物件的集合，再經管線輸送到 Stop-Process Cmdlet，而後者真的會停止這些處理序！如此將導致約在五秒後出現 STOP 藍色錯誤畫面，原因是終止了關鍵的 Windows 處理序。不過，您可以加上非常方便的 –Whatif 參數來看看將會發生什麼情況，而不是真的令其發生：
Get-process | Stop-Process -Whatif
在 Windows PowerShell 中執行上述命令會產生一串陳述式，告訴您 Cmdlet 將有何動作而非實際付諸執行。Windows PowerShell 的線上說明系統 (可利用 help 別名存取) 尚未記載 –Whatif 參數，但請將其牢記在心。這是極為實用的工具，可測試指令碼和 Cmdlet 以檢驗其結果，但不會實際做出任何具有潛在危害性或破壞性的事情。

總結
在這一版 Windows PowerShell 尚未加入的功能當中，最重要的也許是對 Active Directory® Services Interface (ADSI) 的支援。Windows PowerShell 雖可利用用於處理 Active Directory 及其他目錄服務、具有超強功能的 .NET 類別，目前卻未提供方便好用的 Get-ADSIObject Cmdlet。這使得處理目錄物件變得有點困難。
此外，Windows PowerShell 通常提供幾種不同方式執行同樣的工作。這可謂立意良善，但或許會令人在學習 Windows PowerShell 時感到更困惑，因為任何特定工作可能都有將近十個範例展示不同的處理方法。
隨著時間的推移，一切終將獲得解決，Windows PowerShell 小組會持續為產品新增更多特色和功能。要想隨時掌握最新資訊，請造訪該小組的部落格 (英文)。

Don Jones 是 ScriptingAnswers.com (英文) 的創始人，同時也是 Windows PowerShell:TFM (SAPIEN Press，2006) 一書的合著者。請透過 don@scriptinganswers.com 與他聯繫。


 事後剖析: 從 Exchange 5.5 遷移
事後剖析
從 Exchange 5.5 遷移
Whitney Roberts

專案
肯塔基州教育局需要將其現有的 Microsoft® Exchange Server 5.5 實作遷移至 Exchange Server 2003。該系統在每個學年大約支援 600,000 名教職員工和學生。
參與者
此專案由肯塔基州教育局的教育技術辦公室 (Office of Education Technology，OET) 負責，KiZAN Technologies 的顧問提供協助。OET 職員對現有 Exchange 5.5 實作進行管理監督。Exchange 伺服器的日常執行則由各學區的當地職員負責。
挑戰
教育局為肯塔基州內全部 178 個學區提供技術指導。這些學區透過 WAN 彼此連接，但每個學區都主控其自己的本機受管理 Exchange 5.5 伺服器，這些伺服器需要個別升級。升級後的系統將會支援 Outlook® 2003 快取模式用戶端、改進的 Outlook Web Access (OWA) 體驗、標準化的電子郵件地址設定配置等等。
除了部署新的電子郵件伺服器和用戶端基礎結構外，許多學區要增加對學生電子郵件的支援。州政策和聯邦政策都要求保護學生資訊，不允許向外洩漏這些資訊。
規劃
由於不能使用 Active Directory® Connector (ADC)，我們建立新的 Exchange 組織並遷移至其中。電子郵件地址標準化意味著，為各學區建立新的識別子網域和 400 多個新的收件者原則。學生地址的保護則需要建構由全域通訊清單 (GAL) 和各學區自訂通訊清單組成的系統。
實際的遷移包括轉換新的硬體、根據學區成員和使用者類型來建立並設定信箱，以及根據學區成員和使用者類型來設定擴充屬性，好讓使用者出現在適當的通訊清單中。
我們建立一個以 Visual Basic® 為基礎的應用程式，用以偵測和更正錯誤設定的帳戶屬性或群組成員，並正確佈建新信箱以確保符合可見度需求。此應用程式已部署至全部 178 個學區並在學區的伺服器上定期執行。

背景
表面上，這看起來不是很複雜或技術難度很高的工作。但有人曾善意地提醒過我，業務需求決定一切，而這個專案的業務需求令人大開眼界。
多年來，分散式管理和雜亂的各種標準造成衆多為支援而生的系統 (Silo)，而這些通常需要由 OET 管理。此外，OET 也必須確保 Exchange 5.5 實作能同時滿足學區和教育局的需求。也就是說，對於導入學生電子郵件的學區，必須依照州和聯邦指導方針 (請參閱 ed.gov/policy/gen/guid/fpco/ferpa/index.html) 的規定來保護學生資訊，不允許向外洩漏這些資訊。
在 Exchange 5.5 中，這些指導方針意味著學區內的學生資訊不能複寫至共用 GAL 資料的其他學區或其他州立單位。具體來說，這迫使全部 178 個 Exchange 5.5 站台都必須經歷手動的匯出/匯入程序：即隱藏學生、複寫清單、取消隱藏學生，以及最後再匯入通訊清單。以這種方式，其他學區只能看到職員資料。本學區則可以看到自己的所有資料，但只能看到其他學區的職員資料。
考慮到現有系統的優缺點，郵件基礎結構的升級必須滿足一些特定準則。首先，肯塔基州教育局需要在通用可讀的 SMTP 命名配置上，在整個專案範圍內實現標準化。此配置需要為教職員工和學生提供獨立的 SMTP 位址空間。
新系統也需要提供集中管理的服務，讓學區擺脫郵件管理和可用性等職責。也就是說，嚴重損壞修復、郵件流程和服務台呼叫解決都將採用集中式的管理。如此一來，新系統必須提供集中式的方法，跨所有學區進行使用者組態的標準化，無論給定使用者的地理位置或學區關係如何。
而且，新系統也必須在一個通用、統一命名空間上，針對所有學區提供 Web 式和行動裝置的安全電子郵件存取。
有鑒於這些需求 (其中許多需求在現有的 Exchange 5.5 系統中尚未實作)，Exchange 2003 的升級工作令人怯步。

方案建置組塊
為了滿足業務需求，我們決定幾種 Exchange 特定的部署選項。
由於缺乏標準化以及 Exchange 5.5 環境之巨大，所以不能使用 ADC。我們轉而建立新的 Exchange 組織並遷移至其中。
為了清理並標準化各學區職員和學生的電子郵件地址，我們建立 400 多個新的收件者原則。此外，還根據需求為每個學區建立一個唯一的識別子網域，其中包括學生的識別學區名稱。例如，就 Shelby 郡而言，主要子網域為 shelby.kyschools.us。各學區的學生都有一個 stu. 子網域名稱，所以 Shelby 郡學生的電子郵件地址為 stu.shelby.kyschools.us。
另一個限制是學生地址只能顯示在其所在學區，而職員地址可跨學區顯示。這意味著要建構由 GAL 和自訂通訊清單組成的一套完善系統，如 [圖 1] 和 [圖 2] 所示。移至 Exchange 2003 的一個好處是，可以透過權限來保證通訊清單的安全性，並且透過群組成員資格來控制對各通訊清單的存取。我們充分利用這個特點，建立兩個學區層級安全性群組 (一個用於職員，一個用於學生)，並為對應的學區職員和學生 GAL 及通訊清單設定安全性，只允許特定學區內的使用者帳戶存取某些通訊清單。刪除預設 GAL 和通訊清單，並確認 Everyone 和 Authenticated Users 群組不在各通訊清單的存取控制清單 (ACL) 中出現後，我們可以預先選取特定學區中特定使用者類型能夠查看的通訊清單。
圖 1 基於角色的自訂通訊清單
圖 1 基於角色的自訂通訊清單
然而，權限只解決可見度問題的一部分。我們必須提供方法來控制在不同通訊清單中哪些內容是可見的。為此，我們建立了一個基本輕量型目錄存取通訊協定 (LDAP) 查詢，用以查詢職員和學生的可見度；然後針對各通訊清單和 GAL 對該查詢稍加自訂。例如，針對 Shelby 職員 GAL 的 LDAP 查詢只會顯示 Shelby 學區對應的職員和學生，以及本州其他學區的所有職員 (但不包括學生)。針對 Shelby 學生 GAL 的 LDAP 查詢則只會顯示 Shelby 學區的職員和學生，並不顯示本州任何其他學區的其他職員和學生。我們為該組織中的所有學區重複這個查詢。[圖 3] 顯示在這次複雜的遷移中所使用的一些 LDAP 查詢範例。
Figure 3 通訊清單 LDAP 查詢 (Close Figure 3)

職員 GAL LDAP 查詢
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
學區通訊清單 LDAP 查詢
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
學區學生通訊清單 LDAP 查詢
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
學區職員離線通訊清單 LDAP 查詢
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
圖 2 將職員和學生隔離的全域通訊清單
圖 2 將職員和學生隔離的全域通訊清單
Exchange 使用者屬性 extensionAttribute14 (自訂屬性 14) 和 extensionAttribute15 (自訂屬性 15) 的自訂值是 LDAP 查詢背後的辨別機制。全州內所有職員和學生使用 extensionAttribute14 的特定值以指定使用者類型，並使用 extensionAttribute15 的唯一值以顯示學區關係。各學區都有唯一值，每個使用者類型又對應相同的值，所以，通訊清單就可以準確地顯示各學區內各使用者類型的所需資訊。
當使用者透過非快取模式下的 Outlook 或透過 OWA 存取電子郵件時，這些通訊清單的效果非常好 (我們使用 msExchQueryBaseDN 屬性將各使用者導向 OWA 中的正確通訊清單)。但在快取模式下執行 Outlook 的使用者卻面臨著另一個問題。由於 Outlook 不會將自訂的 GAL 視為指定的離線通訊錄 (OAB)，所以我們必須建立與 GAL 重複的附加通訊清單。然後以快取模式使用者的適當 OAB 通訊清單，來設定各學區信箱儲存區。總而言之，這個方案建立 1,500 多個通訊清單，以便為全部 178 個學區各種類型的使用者提供完整的功能。

確保符合性
為了確保部署中的結構能夠正常運作，符合新建立的各項標準是最重要的。對於組織中每個已啓用 Exchange 的使用者，必須執行一些高階工作。這是因為每個使用者必須正確定位在所有學區的 Exchange 伺服器上，而且使用者資訊也必須顯示在正確的通訊清單中。
使用者必須是學區網域內適當安全性群組的成員，因為安全性群組會授與權限來打開適當通訊清單。此外，也必須根據學區和組織單位 (OU) 成員資格，正確設定使用者的 msExchQuerybaseDN 屬性。使用者的 OU 決定使用者類型。
下一步是根據學區成員資格和使用者類型，在適當伺服器的正確儲存區上建立使用者信箱。這個工作影響服務等級、信箱大小限制及離線通訊錄通訊清單，以便讓 Outlook 快取模式能夠正常運作。擴充屬性是根據學區成員資格和使用者類型來設定，好讓使用者出現在適當的通訊清單中，而不會出現在其他通訊清單中。
最後，我們需要提供更正方法。如果有任何帳戶的屬性或群組成員資格被錯誤設定 (或變更) 成為不適當的值，這個方法可以自動進行更正。如果使用者在學區的網域內從一個 OU 移至另一個，這意味著使用者分類已變更，必須更新信箱位置、GAL 選取及通訊清單可見度。
我們需要一種佈建系統，用來完成這些工作並確保 Active Directory 的一致性和準確性。於是，我們建立一個主控台式、以 Visual Basic 為基礎的應用程式，可以從學區 Exchange 2003 伺服器上定期執行該應用程式，來檢查對原則和標準的符合性，並處理新物件的建立和佈建，我們將該應用程式部署至全部 178 個學區。
我們覺得當前的工作過於複雜，無法透過一系列指令碼快速可靠地執行。由於以 Visual Basic 為基礎的應用程式效率較高、具有結構化的錯誤和例外狀況處理支援，而且其內部碼只需最小量的改寫即可輕鬆配合未來的 Microsoft Identity Integration Server (MIIS) 擴充碼，所以被視為適合上述問題的方案。
我們要遷移至新組織，所以必須找到特定的共存方法。新環境中要支援超過 178 個傳統 SMTP 網域 (有些學區先前有學生電子郵件網域，有些則沒有)，但我們卻要逐個遷移每個學區並將其傳統郵件和地址傳遞到新系統中，而不影響其他學區。然而，我們需要避免學區從 Exchange 5.5 遷移至 Exchange 2003 時出現電子郵件流程中斷。這意味著要在 Exchange 2003 Active Directory 和傳統 Exchange 5.5 目錄之間實作某種類型的目錄同步。Microsoft 只授與肯塔基州教育局在遷移期間有限的 MIIS 使用權限，於是我們開發自訂的擴充碼，用來在遷移期間和前後透過 MIIS 同步處理兩種 Exchange 組織。
移至新的 Exchange 組織自然會影響 MAPI 用戶端組態。教育局面臨著一個難題：遷移期間在學區層級差不多有上萬個 MAPI 設定檔必須重新設定。所幸 Microsoft 發行 Exchange Profile Tool (ExProfRe.exe)，可以用來遷移學區層級設定檔。我們建立一個封裝安裝程式，它以預先載入的值執行 ExProfRe.exe，使學區層級設定檔的遷移可以自動執行。此程式是透過群組原則呼叫的。我們這項組織間設定檔自動遷移的成功率接近百分之百。

硬體升級
由於新的 Exchange 2003 伺服器將取代分散在各地的 Exchange 5.5 伺服器，所以在硬體方面，此方案必須與 Exchange 5.5 部署支援相同數目的使用者，再加上新增的學生帳戶。伺服器必須裝載於學區本地，因為根據 WAN 拓樸的設計，所有學區間流量 (網際網路和內部) 都是經由一條專用 T1 線路 (某些學區中為多條 T1 線路)。
由於預算、管理及設備主控限制，Exchange 伺服器不能有透過存放區域網路 (SAN) 附加的儲存裝置，所以所有儲存裝置必須是內部或直接附加的。因為大多數學區沒有配備機架儲存裝置和中央冷卻設備的資料中心，所以伺服器必須盡可能自給自足。所幸大多數學區的使用者數少於 5,000，所以可以實作單一伺服器部署。使用者較多的學區則使用更強大的伺服器 (或多個伺服器) 及額外的儲存裝置，有些還搭配單獨的前端伺服器，進一步隔離學生與職員的流量。
在大多數學區中，我們部署配備精良的雙處理器伺服器，這些伺服器配置有高達 15,000 RPM Ultra320 SCSI 磁碟機、多個 RAID 控制器及 4GB RAM。更大的學區則部署一個或多個四處理器伺服器，必要時使用較小的前端伺服器。部署前的基準測試和效能測試結果表示系統沒有使用率或負載問題。但不同程度的本機使用模式將是伺服器整體效能的真正決定因素。

概念證明測試
儘管此生產環境包括一個由 178 個網域組成的 Active Directory 樹系，但概念證明 (POC) 實驗室將此環境縮減到 13 個學區網域和一個空的根網域。所有測試網域都是由生產網域匯出的資料填入。虛擬 Exchange 5.5 伺服器是以選定學區資料庫的複本建立和設定，以便我們能夠對計劃環境測試遷移程序和增建。整個 POC 測試實驗室由虛擬機器建構，所以環境可以基準化、凍結，並在必要時重新部署。
我們設計、編碼、測試並完成各種指令碼 (使用 VBScript)、Systems Management Server (SMS) 安裝套件及主控台應用程式。最後，我們擁有會執行初始 Exchange 2003 安裝和組態 (包括收件者原則、GAL 和自訂通訊清單及權限) 的指令碼。此外，也透過指令碼來處理遷移中的管理群組組態、學區網域組態 (建立安全性群組和委派權限) 及部署後組態。
Exchange 2003 伺服器的接移工作面臨一些重大的挑戰。我們需要在所有 178 個網域中成功安裝全部 Exchange 伺服器，而且在安裝時不能危及遷移工作的其他部分。Exchange 2003 與 Exchange 2000 不同的是，直到網域中安裝第一個 Exchange 2003 伺服器後，網域特定的 Exchange 網域伺服器群組才會加入至組織的 ACL 中 (在 Exchange 2000 中，該群組則是在執行 DomainPrep 程序時加入的)。為確保 Active Directory 的組織物件中能列出所有必要的安全性群組，我們必須先在一個特定網域中安裝，然後手動將 Active Directory 從該網域複寫至 Active Directory 複寫中心站台，再將該複寫提取至下一個要安裝的學區。只有在確認組織物件上的 ACL 擁有來自上一個學區的 Exchange 網域伺服器群組後，才能安全地開始下一個學區的安裝工作。即使只有一個網域沒有按照上述順序完成這個程序，該學區也都至少必須進行重新安裝，否則其他學區將不能進行學區間通訊，這是因為該組織物件 ACL 不能正確列出所有其他學區。
我們對整個部署、組態、伺服器接移及遷移進行多次測試，直至我們確信此程序在 POC 環境中執行良好。

遷移和初期難題
一旦專案小組認可 POC 程序和結果時，即準備開始遷移。OET 選擇先進行本身的遷移，這樣他們可以親身體驗此程序及其結果。遷移時，所有伺服器都已接移，而且初始環境已驗證。所有前端通訊協定伺服器和信箱伺服器都已就位，準備投入生產供使用者使用。
此遷移計畫執行得相當順利，經過長達 21 小時伺服器間的內容傳輸後，OET 在 Exchange 2003 上啓動並正常運作。所幸 Outlook 設定檔在從 Exchange 5.5 遷移至 Exchange 2003 時沒有出現重大的問題。我們封裝一個批次檔案，它根據一些簡單的邏輯，在不同組態中呼叫 ExProfRe.exe。然後，我們將此批次檔案和 ExProfRe.exe 散佈至各學區中網域控制站 (DC) 的 Netlogon 共用，並使用群組原則，在遷移結束時針對所有用戶端執行該批次檔案。這個程序在 OET 執行良好，我們有信心後面的遷移程序也會成功。
這時，相關人員又根據 OET 部署的經驗，對遷移計劃重新檢閱和核准。在接下來的遷移中，我們選擇六個學區做為首批生產站台。在各學區進行遷移前，MIIS 從 Exchange 5.5 中讀取有關學區信箱的最新資訊並更新學區網域中的對應使用者。我們使用 Exchange 遷移精靈 (Mailmig.exe) 來實際地在組織之間移動信箱資料。在精靈移動信箱資料時，所有 Proxy 位址會從 MIIS 最初所匯出的部分移動並更新到 Active Directory 中。在遷移期間，郵件在前端 SMTP 伺服器上進入佇列，然後在遷移、遷移後伺服器組態及使用者測試完成後釋出給學區；學區準備使用 ExProfRe.exe 來執行大規模的用戶端遷移。

RUS 之爭
為了讓 Outlook 用戶端正常運作，我們需要確保佈建方案在設定屬性值方面具有絕對的權威性。我們也需要收件者更新服務 (RUS) 來完成帳戶設定工作；但 RUS 只能在佈建完成後執行。為此，學區 (所有 178 個學區) 的 RUS 執行個體設為「永不」根據其排程執行，而佈建方案使用會在佈建完成後觸發 RUS 的程式碼。
大多數學區的使用者數少於 5,000，而日常的更新更是少之又少，再加上佈建系統會在日常執行結束後觸發更新工作 (而不是重建)，所以 RUS 很快完成。但有些學區的使用者數超過 10,000。在這些環境中進行更新較費時，如果需要在這些大型網域中完全重建 RUS，可能要花費一星期甚至更長的時間。由於 RUS 會在執行時評估所有物件類型，因此在這類大型網域中進行重建將是極為漫長。
雖然我們無法提出遷移策略 (我們曾與 Exchange 產品小組的成員一起研究，試圖提出方案)，但我們增強佈建程式碼，使它可以處理許多通常由 RUS 執行的工作。一旦開始佈建時，就會填入使用者的 showInAddressBook 和 proxyAddresses 屬性，讓使用者無需等待 RUS 完成其工作即可立即登入。我們也建立會在其中一個前端 Exchange 2003 通訊協定伺服器上執行的手動工作。它會定期執行 LDIFDE 匯入並清除 RUS gatewayProxy 位址，如此一來，如果某個收件者原則在環境中只是被意外套用，它就不會被放入企業每個 RUS 的待辦事項清單中。

分類程式問題
就避免學生資料洩漏到學區外而言，一個令人關注的方面是透過實作控制，來防止學生向本學區外的使用者或者本系統外的網際網路地址傳送電子郵件。我們沒有採用由連接器和相關項目組成的完善系統，而是決定實作 Exchange 2003 鮮為人知的功能，並對學區與前端通訊協定伺服器所在中央集線器之間的現有路由群組連接器，施以連接器限制。在每個網域中建立兩個安全性群組 (一個用於職員，一個用於學生)，並將這些群組加入至連接器限制中。
一旦在登錄中啓用連接器限制檢查功能，我們開始注意到一些顯著的效能低落問題。郵件會在分類程式和本機傳遞佇列中阻塞數小時，即使是要傳送給相同伺服器上收件者的郵件也是如此。隨著時間的推移，當更多學區完成遷移時，這些問題越來越嚴重。做為一個短期方案，我們關閉了連接器限制檢查功能，結果郵件傳遞的效能有所提高。進一步的檢查揭露，分類程式不僅會在郵件提交後檢查本身網域中兩個群組的成員，而且還會檢查其他 177 個網域中相同兩個群組的成員。對於進出伺服器的每封郵件都是如此。
我們隨後向 Microsoft 開啟支援案例。Microsoft 在進行評估後，目前正在產生 Hotfix，希望透過允許分類程式在拓樸複雜性更低的模式下工作，來減輕此問題。截至發稿時，我們尚未得到有關 Hotfix 的進一步資訊，但目標是提供一種設定，來允許分類程式對路由拓樸進行某些假設，而不會跨所有連接器來檢查群組成員。

心得
如果說從這個專案中我學到一些教訓的話，那就是對我們技術顧問而言，業務需求決定一切。很多時候，我們必須在業務需求的可行性和方案的複雜性之間權衡輕重。我在本專欄中介紹的各種決策和選擇，都是我們認為最適合我們的特定環境 (包括我沒來得及在此討論的要素)、資源及業務需求的決策和選擇。對於您而言，可能有不同的決策，但希望本專欄能帶給您一些啓示。所幸，對於我們，Exchange 2003 和 Active Directory 提供了足夠的彈性，來滿足這次複雜的遷移工作的所有需求。一旦解決了肯塔基州教育局部署專案最為棘手的規模問題，實際的方案就相當簡單，它基於 Active Directory 和 Exchange 2003 中我認為未被充分利用的功能而建立。
第二個寶貴的教訓是，採用一種平穩的方法來實施疑難排解和風險/問題管理。有時應當在本機實施疑難排解，有時則需要求助於 Microsoft 技術資援處 (Product Support Services) 的資深人員。

展望未來
肯塔基州教育局的環境確實是獨一無二的。在這次的部署過程中，我們幾乎利用或自訂 Exchange 中的每項功能來滿足其需求。目前整個環境已部署且成功遷移，進入實作附加功能的階段。教育局已經看到 Windows Mobile® 平台對於學區所帶來的益處，並希望繼續發展行動裝置。
透過伺服器合併可以獲得重要價值。肯塔基州教育局目前正在考慮將 Active Directory 環境的某些方面虛擬化。隨著 Exchange 2007 的即將發行，教育局已經開始考量其郵件系統的升級需求。
肯塔基州教育局也在考慮導入 Live Communication Server、Live Meeting Server 等工具中其他的協同作業功能。Microsoft Operations Manager 2005 目前也正在部署之中，準備用來管理並監視 Exchange 和 Active Directory 伺服器。

結果
這次實作的品質和普及率將影響肯塔基州公立學校體系中的每個孩童，包括我的孩子和這個專案中我同事的孩子。這次實作透過各種技術使肯塔基州教育局以前所未有的速度、以安全和標準化的方式獲得長足的進展。能參與這個專案，我深感榮幸。

Whitney Roberts 是 KiZAN Technologies (www.kizan.com (英文)) 的首席顧問，從 Exchange 4.0 版起就一直致力於 Exchange 方面的工作。


 SQL 問題與解答: 預防重新開機、安裝多項更新及其他資訊
SQL 問題與解答
預防重新開機、安裝多項更新及其他資訊
編輯：Nancy Michell

預防重新開機

問：對 SQL Server 甚至是一般伺服器作業系統套用 Hotfix 和類似更新時，如何限制重新開機的次數？

答：首先，您應要瞭解，大多數的安裝後重新開機程序並沒有固定編寫在安裝程式中。會重新開機通常是鎖定檔案導致的結果。也就是說，安裝程式試圖更新的檔案目前正由某些其他應用程式或由作業系統使用中 (鎖定)。有一種直接了當的辦法可以消除這些重新開機動作，即確定沒有任何處理序正在使用上述檔案。這要怎麼做？
第一步是找出在安裝期間遭鎖定的使用中特定檔案。最簡單的方法就是在登錄 HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations 中尋找。檢查此登錄機碼有兩個目的：證實重新開機要求確為鎖定檔案所導致，以及得知哪些檔案遭鎖定。如果您在安裝後重新開機前檢查這些項目，大概就能研判導致需要重新開機的原因，進而在日後的安裝過程中採取措施以免重新開機。
您可能會發現兩種類型的項目。如果檔案因讀取而鎖定，您將看到每個檔案各佔一行的項目，表示更新過的檔案已存在磁碟上，但您還需清除仍在使用中的暫存複本。如果檔案因寫入而鎖定，您將看到每個檔案各佔兩行的項目，表示尚未進行更新、應用程式狀態不明所以不應使用。應用程式有如在安裝過程中暫止。若是如此，其中一行代表實際檔案，另一行則指向暫存檔案 (重新開機後將變成實際檔案)。
下一步取決於多項因素，但歸根究底是判別鎖定的檔案正由哪個軟體使用中。請利用依存性檢查程式 (如果可行) 判別，或造訪 MSDN® 的 DLL HELP 資料庫 (請參閱 support.microsoft.com/kb/815065)。
如果經您判定的軟體有依存服務，請手動停止該服務，然後再次進行測試。如果軟體是應用程式，則將它關閉後再試一次。有時候會是數個應用程式都在使用同一個檔案，那麼就必須停止所有這些應用程式。
上述測試 (在您的測試環境中進行) 的結果將是實際執行環境應在安裝前停止的應用程式及服務的清單。藉此，實際執行環境即不會要求重新開機，因為安裝程式要安裝的檔案並未被任何軟體鎖定。當然，別忘了在安裝完成後重新啟動那些應用程式和服務。
還好，鎖定的情況通常不會有太大變化。因此您只需要測試一次，查明系統的常規模式後，大致就能在系統的整個存留期間內避免多次的重新開機。
尚有一種技巧值得一提。您可能並存安裝了多個版本的 SQL Server™ 或其他產品，甚至這些產品屬於不同的版本層級。請一律先更新最新的版本。更新通常將以最新版本取代一切，因而所有其他執行個體根本不必擔心鎖定的問題。例如，假設您有三個 SQL Server 2000 SP3 的執行個體，則最早升級到 SP4 的執行個體會對 MSXML3.dll 檔案進行升級且需要重新開機。接著您在升級後選擇立即重新開機。開機後就可繼續將另外兩個執行個體升級到 SP4 而不必重新開機，因為系統上已存在更新過的 MSXML3.dll 檔案。同樣地，若先升級 SQL Server 2005 執行個體再升級 SQL Server 2000 執行個體，或先升級 SQL Server 2000 再升級 SQL Server 7.0 執行個體，兩種情況下升級後者時都不需重新開機。這是一般儘量減少重新開機次數的好辦法。
整體來講，Microsoft 開發團隊已投入不少心力，為許多情況設法停止重新開機或限制重新開機次數。既然本篇是＜SQL 問題與解答＞專欄，我們就以 SQL Server 為例稍作說明。
在 SQL Server 2005 中，SQL Server 團隊將 SQL Server 所需的 Microsoft® Data Access Components (MDAC) 程式碼分離出來放入 SQLNCLI (新檔案) 中，而沒有更新 MDAC 本身，並且將 MDAC 移回與作業系統結合。這有什麼好處？嗯，Windows® 作業系統本身會用到 MDAC 並鎖定其相關檔案。這就是為何大多數的 SQL Server Service Pack 及其他封裝總是要求您重新開機的原因。如今 SQL Server 可以更新自己的 MDAC 版本，而不碰觸到作業系統使用中的 MDAC 檔案，所以您將不需要重新開機。
此外，SQL Server 2005 SP1 安裝程式如今還內建依存性檢查程式和暫停功能。這可用於檢查被鎖定的對象以及可能執行鎖定的主體，從而提供機會讓您即刻將執行鎖定的主體停止後繼續安裝，那麼就不需要重新開機了。也就是說，您將不需要架設測試平台，可以即時解決問題。當然，如果您選擇自動模式或正以自動模式執行，也可以一律讓安裝程式繼續完成工作再重新開機。無論如何，能夠輕易查明鎖定檔案的主體倒是不錯吧！
再者，Microsoft Installer 技術還能更完善處理既有的 PendingFileRenameOperations (PFR)。回想一下，若有任何檔案出現在上述登錄機碼中，SQL Server 2000 安裝程式便會受阻。SQL Server 2005 安裝程式就比較聰明，若已發現屬於 SQL Server 的檔案位在該機碼中 (表示可能發生衝突) 才會受阻，甚至在此等情況下，也經常能找到 PFR 機碼並直接進行更新而無需重新開機。MSI 和 update.exe 在若干程度上都納入了這項技術，而此二者正是用於執行所有更新的現行標準 Microsoft 安裝程式。
導致重新開機的已知因素有哪些？MSXML3.dll 是最主要的因素。Windows SVCHost 服務始終鎖定該檔案，因此任何包含這項服務的程式都必須重新開機。該檔案也存在於大多數的 MDAC 堆疊 (mdac_typ.exe) 上。所幸，MDAC 已經「集結」併入 Windows Server® 2003 和 Windows XP SP2 及後續版本中。SQL Server 開發團隊將 msxmlsql.dll 分離出來的傑出表現，使得 SQL Server 更新不致造成重新開機，但短期內偶爾仍會發生。面臨此問題只能順其自然；您總不能關閉 SVCHost 再繼續執行更新。
另外，update.exe 封裝的解除安裝程序有些古怪。如果解除安裝，程序會鎖定安裝程式原已安裝的檔案 (沒錯，就在 PFR 機碼外)。這可阻止其他 update.exe 封裝執行，直到重新開機解除鎖定為止。您所能做的大概就只有認清這一點，而有心理準備在解除安裝任何 Hotfix 之後重新開機。
另一問題是間歇性。並非所有程式一直都在使用某個檔案。事實上，大部分共用 DLL 的使用情形都是按時間點考量，也就是說其他程式會依自身的工作負載和程式碼路徑，只在必要時存取檔案。這表示您有可能測試了 10 次都沒發現檔案被鎖定，卻在實際部署時遭遇檔案鎖定。可惜此問題沒有仙丹妙藥能解決。您只能將測試環境建構得與實際執行環境儘量一樣，包括負載 (任何情況下都是不錯的目標)，並執行足夠的測試以便因應這類間歇變化。
作業系統 Service Pack 和升級將引發重新開機。並且請注意，下層版本 (Windows 2000、Windows XP 及其他更舊版本) 一定要重新開機，安裝才算完成，即使 pendingfilerenameoperations 登錄機碼是空的也是如此。在重新開機期間，系統可能會執行非例行性的封裝登錄作業，進而安裝程式碼。這些作業不屬於 Service Pack 安裝程式的一部分，而是目前作業系統內嵌的命令，因升級受到觸發才執行特定程式碼片段而得以繼續存留。
最後，PFR 機碼既不進行檔案版本檢查，也不會透過序列化強制排序。這表示檔案將依列出的順序逐一取代。但是，檔案套用到硬碟的順序經證實是從最後完成取代的檔案 (並非第一個取代的檔案) 開始。這很合理，不過也意味著如果相同路徑上有同一個檔案的兩份複本，分別指向不同的版本，重新開機後就會產生隨機結果。若您碰到這種情況，則務必予以修正。如果無法確定解決與否，就請於重新開機後再次執行兩種安裝程式。檔案若是正確無誤，兩種安裝程式將不做任何處理。如果檔案不對，擁有正確檔案的封裝便會修正問題。老實說，這比試著找出所要的結果來得更快又保險。

安裝多個 Service Pack

問：我的 4 節點叢集上有 8 個 SQL Server 2000 叢集執行個體，而希望在安裝 SP4 後能儘量減少重新開機次數。我可否先將 SP4 逐一安裝到這 8 個執行個體，完成後再同時將所有節點重新開機？

答：一旦您在特定的 Windows 伺服器 (叢集或非叢集) 上完成 SQL Server SP4 單一執行個體的安裝後 (可能需重新開機)，再陸續為該伺服器的任何其他 SQL Server 執行個體安裝 SQL Server SP4 時，應該就不必重新開機。原因在於，所有的共用檔案包括工具、MDAC、MSXML 等均已是正確的版本，因而這些項目無論鎖定與否都不需要進一步更新。所有非共用檔案均只由第一個執行個體使用，且安裝程式將會關閉該執行個體。值得注意的是，如果您有數種版本的多個執行個體，則應先更新最新版的 SQL Server 執行個體。

以 Network Service 身分執行

問：NT AUTHORITY\NETWORK SERVICE 帳戶究竟是什麼，其主要用途為何？另外，該帳戶有何安全性含意，特別是授與其系統管理員 (sa) 權限時？

答：Network Service 帳戶與網路上的 System 具有相同的身分識別 (電腦身分識別)，但前者在本機上擁有較少的權限。因此如果服務需要存取網路資源，也許是解析網域控制站與帳戶名稱的組合，就必須以 System、網域帳戶或 Network Service 身分執行。通常，Network Service 是最安全的選擇，因為其作用範圍僅及於本機電腦且權限受限制。
讓 Network Service 成為 SQL Server 的系統管理員 (sa) 意味著，本機電腦上其他任何以 Network Service 身分執行的服務均擁有整部伺服器的完全控制權。例如，當 SQL Server 服務帳戶設定為以 Network Service 身分執行時，就會發生這種情況。使 SQL Server 服務帳戶成為系統管理員的成員是基於伺服器發揮功能之需要 (如：為完成回送連線)。儘管讓 Network Service 以 SQL Server 系統管理員的身分執行不太有利於安全性，但可能 (或許也未必) 比改用網域帳戶更恰當，而且要比以 LocalSystem 身分執行 SQL Server 安全得多。
如果您不希望 Network Service 擁有系統管理員權限，退而求其次的選擇是使用網域帳戶，專門在一或多個 Windows NT® 安裝上執行 SQL Server。
以下幾篇文章對您應有所幫助：msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp (英文) 和 microsoft.com/technet/security/topics/serversecurity/serviceaccount (英文)。

建立多個資料庫

問：我想要分割資料放到個別的資料庫中，線上同時最多約有 250 個資料庫。我估計在任何特定時間，現用查詢只會用到其中 20% 的資料庫。資料庫多些還是少些比較好？

答：資料庫伺服器執行個體中的資料庫數目應由營運需求和管理因素決定。在單一伺服器執行個體中建立多個資料庫並不需要多少開銷，但資料庫愈多即表示執行維護工作 (如備份和還原、鏡像、使用者帳戶及使用者角色) 方面的管理負擔愈重。隨之升高的管理複雜度可能會超出資料庫數目增加所帶來的益處。
一般通則是：與同一應用程式有關的資料應全部儲存在同一個資料庫中，這樣的話故障時比較容易復原。若將同類應用程式的資料分散到多個資料庫，故障時就必須復原所有這些資料庫。如此將耽誤到復原進程，而如果其中某個資料庫無法復原，甚至會導致整體復原失敗。
總之，將資料分散到多個資料庫的原因如下：
  • 資料子集的備份需求有別於其他資料。
  • 部分資料需要有個單獨的安全環境，即不同的資料庫擁有者。
  • 有時，資料的用途僅供記錄歷史事件，因而需要以唯讀模式儲存。

感謝下列 Microsoft IT 專家提供其技術專業知識：Ramon Arjona、Frank De Waelle、Robert Djabarov、Herman Learmond-Criqui、Maxwell Myrick、Ruslan Ovechkin、Uttam Parui、Shashi Ramaka、Gary Roos、Gavin Sharpe、Vijay Sirohi、Jimmie Thompson 與 Madhusudhanan Vadlamaani。

編輯：Nancy Michell


 嗨，Scripting Guy！: 杯架在哪？
嗨，Scripting Guy！
杯架在哪？
Microsoft Scripting Guy
本專欄是根據 Windows PowerShell 的搶鮮版 (Prerelease Version) 所撰寫。本文包含的所有資訊均有可能變更。

每回一有新技術引進，人們總得花些時間才能真正搞懂新技術與原技術有何區別。就以第一部汽車為例來說吧。之所以會將這些新玩意兒當成是不用馬拉的馬車，是因為它們看起來就像這麼一回事。當您回過頭再次審視時，第一部汽車和馬車的區別就在於，一種要用馬而另一種不用馬。除了這一點外，真的很難分辨這兩種東西。
當然，現在幾乎不會有人把汽車誤認為是馬拉的馬車。這是因為，隨著時間的推移，汽車製造者已經設法做了不少改造，讓汽車明顯不同於馬車。例如，當今的汽車一出廠就配備了 CD 播放機、空調和衛星導航系統；而馬車則與這些東西完全沒關係。同樣地，假如您在 1880 年代駕著一輛馬車趕路，半途中需要放下一陣子手邊的星冰樂咖啡；那可真抱歉，您真是不走運！相比之下，有些休旅車則推出了多達 17 個杯架，而至少有一種車款光為駕駛一人就準備了 3 個杯架。一些較新款式的汽車甚至還配有讓您視狀況需要保溫或冷藏飲料的杯架。
附註 過去，人們在駕駛時竟無法喝到三份不同的飲料，真難以想像他們是如何活下去的。換作您，要是在駕駛時只能喝到一兩份飲料，一路上豈不難熬不堪？
在一項新技術實得人們的認同之前，要想讓人們支持新興的未知技術而拋棄舊的可靠技術，總得給些理由使他們信服。當 DVD 首度問世時，它們能夠像錄放影機那樣，讓您在家觀看電影。從另一方面來講，DVD 比錄影帶更貴，而且您不能用 DVD 播放機錄下自導自演秀。不用說，DVD 當時並沒有造成舉世轟動。事實上，直到 DVD 製造商開始在影碟內加入了過去您根本毫無所悉被刪掉的電影場景、演員訪談及從影帶上看不到的內容花絮後，DVD 才真正取代機能相同的 VHS。僅能在家觀看電影還不夠；DVD 製造商必須設法提供更先進甚至超乎人們想像的功能。
附註 是否真的有人觀看這些附贈內容其實不是重點：人性本是如此，只要有東西可拿就想要到手而不管是否有用。巧合的是，Scripting Guy 正考慮推出一張 DVD，主要收錄 TechNet Magazine 專欄所刪減的未公開字句以及系統管理指令碼的其他結局。

使用 Windows PowerShell
Windows PowerShell™ 是由 Microsoft 發行的新型命令殼層/指令碼技術，象徵著同樣面臨這種情況的另一項例證。當人們初次聽說 Windows PowerShell 時，通常會聽到這樣的說法：
  • "Windows PowerShell 能讓您管理處理序和服務。"
  • "Windows PowerShell 能讓您由事件日誌擷取事件。"
  • "Windows PowerShell 能讓您使用 WMI 管理電腦。"
當然，這些說法均非以訛傳訛，提到的都是些非常實用且重要的工作。但唯一的問題是，您早就能用 VBScript 和 Windows Script Host 來執行這幾項工作了。保持回溯相容性很重要，但如果 Windows PowerShell 甚至連 VBScript 能搞定的工作都辦不到，那還談什麼創新 (試想一下連電影都不能播放的 DVD 播放機。老實說，您根本不必想像：有位 Scripting Guy 家裡就擺著這樣一台機器)。
但話又說回來，假使 Windows PowerShell 只能辦到 VBScript 本可執行的同樣工作，那麼我們何需搶在第一時間關注這項新技術呢？不可否認，VBScript 沒有附送任何杯架，而 Windows PowerShell 也是如此。那麼我們不管使用哪種指令碼技術不都一樣嗎？
說實在的，倒也沒有任何不同。另一方面，撇開缺少杯架不談，Windows PowerShell 的確具備 VBScript 所沒有的若干功能。如果您需要做的只是管理處理序和服務，可能就毫無必要非得瞭解 Windows PowerShell 不可；有句話說得妙：沒壞，幹嘛修理 (聽在 Scripting Guy 耳裡，這句諺語應改為「若不稍微修補一下，一會兒就壞了」)。Windows PowerShell 著實吸引人的地方在於可以用來搞定 VBScript 辦不到的事情。比方說，更改檔案上次寫入時間。

更改上次寫入時間
您沒聽錯：更改檔案上次寫入時間。基於各種原因 (例如快捷形式的版本控制)，指令碼作者始終夢想著有一天能夠更改單一或一組檔案的上次寫入時間 (或建立時間)。令人沮喪的是，Windows Management Instrumentation (WMI) 和 FileSystemObject 居然都沒有這項功能；兩種技術均視檔案日期和時間為唯讀。
但若有了 Windows PowerShell，要將檔案上次寫入時間改為目前日期和時間就輕而易舉，只需執行下列命令：
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
在解釋這個命令的運作原理之前，且容我們答覆一下普遍存乎人們心中的疑問：如果 WMI 不能修改檔案上次寫入時間，那 Windows PowerShell 是如何辦到的呢？我們認為應先針對本問題解惑後再談別的事情；理由很單純，只因這代表了人們對 Windows PowerShell 常有的誤解。一般人常認定 Windows PowerShell 不過是使用 WMI 的一種新方式罷了。固然，您肯定可以使用 Windows PowerShell 存取 WMI 資料；但就在我們坐等其他 Cmdlet (Windows PowerShell 內建命令) 逐一建構齊備的同時，大多數系統管理指令碼仍主要倚賴 WMI 也是實情。然而本質上，Windows PowerShell 乃奠基於 .NET Framework，且 Windows PowerShell Cmdlet 處理的對象通常是 .NET 物件而非 WMI 物件。這點很重要，因為透過 .NET Framework 能夠存取的屬性未必與透過 WMI 可存取的屬性相同。
例如，若是使用 Get-Item Cmdlet 繫結到檔案，並不會傳回 WMI CIM_Datafile 類別的執行個體，而是傳回 .NET 物件。這真的有啥大不了嗎？答案是肯定的。.NET 物件所公開用於檔案管理的屬性和方法集與 WMI 提供的略有不同。但是，正如我們早先舉的例子，這些差別雖小卻相當重要，比方唯讀屬性和可讀寫屬性就差很多。
這背後又有個問題：我們怎麼知道 Get-Item Cmdlet 傳回的是 .NET 物件？以本例來說 (多數情況下亦復如此)，要查明我們正在處理的是哪種物件 (包括判別可供我們使用的屬性和方法)，最簡單的辦法是繫結到檔案，然後將該物件傳遞給 Get-Member Cmdlet：
Get-Item c:\scripts\test.txt | Get-Member
這個命令的執行結果如 [圖 1] 所示。如您所見，這確實是個 .NET 物件 (Scripting Guy 怎麼可能連這種小事都搞錯哩)！
Figure 1 由 Get-Item 傳回的物件的成員 (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
附帶一提，這個簡單的小命令道出了 Windows PowerShell 更耐人尋味 (超實用) 的兩項功能：管線和中繼資訊。我們今天姑且不談論技術細節，但管線背後的基本理念是能夠使用 Cmdlet 抓取物件，然後再將該物件交給其他 Cmdlet。在這個命令中，我們使用 Get-Item Cmdlet 取得代表檔案 C:\Scripts\Test.txt 的物件，再經管線將該物件 (當作物件) 交給 Get-Member Cmdlet (符號 | 在 Windows PowerShell 命令中代表管線)。
Get-Member 經手之後，即擷取所擷取物件的屬性和方法。這是 Windows PowerShell 極巧妙的另一項功能：存取中繼資訊 (資訊的描述資訊) 超方便。使用 Get-Member 和 Get-Command 等諸多 Cmdlet，您就能向 Windows PowerShell 查詢一切所需資訊，作法大體上如同撰寫 WMI 指令碼擷取 WMI 類別、屬性和方法的相關可用資訊。
請注意 Get-Member 提供的功能其實比 WMI 更超前一步。您雖可使用 WMI 取得 WMI 物件的相關資訊，卻無法使用 WMI 取得其他 COM 物件 (像是 FileSystemObject) 的相關資訊。Windows PowerShell 則不然。Get-Member 能夠處理任何您所繫結或建立的物件。不記得使用 FileSystemObject 時可以使用哪些方法了嗎？那就執行下列命令：
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
這真是一個非常實用，也是至今仍未被充分利用的功能。
不賴吧？如果我們把處理檔案 C:\Scripts\Test.txt 時所列可用屬性和方法的清單向下捲動，終究會看到這一行：
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
有意思。顯然 LastWriteTime 屬性既支援 get (讀取) 也支援 set (寫入)。這是否意味著我們可以使用 Windows PowerShell 變更檔案上次寫入時間的值？嗯...
Windows PowerShell 詞彙
別名 可自訂的名稱，用於代表現有的 Cmdlet。Windows PowerShell 提供若干預設別名，將常用的殼層命令對應到具有同等用途的 Cmdlet。
Cmdlet Windows PowerShell 的最小功能單元，相當於其他殼層的內建命令。
命令 Windows PowerShell 的執行單位。命令可以包含多項管線作業，使用 ; 字元甚至還能跨行撰寫命令。
星冰樂 星巴克銷售的一種混合式冰咖啡飲料。
Monad/MSH/Microsoft 命令殼層 Windows PowerShell 的舊稱產品代碼。
物件 擷取自系統或命令的結構化資料。Windows PowerShell 將資料視為 .NET 物件來操控，讓您可以透過名稱操控物件屬性，而不必剖析文字型的命令輸出。
參數 透過命令列對 Cmdlet 設定的選項。Windows PowerShell 使用起始連字號 (-) 字元表示參數。
管線 能將命令的輸出傳送給另一個命令做為輸入。也稱為管道；在命令中以 | 字元表示。
設定檔 Windows PowerShell 啟動時載入的設定，允許設置殼層的作業方式。
指令碼 另存成檔案並從該檔案執行的一或多個命令。Windows PowerShell 使用 .ps1 做為指令檔的副檔名。
殼層 可在其中同時執行命令和 Cmdlet 的命令列環境。
變數 可在命令執行期間設定、變更或擷取其值的物件或參數。

現在讓我們回過頭來談談，將 Test.txt 的上次寫入時間設定為目前日期和時間的命令。程式碼看起來像這樣：
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
如您所見，這個命令的確沒幾個字。我們首先宣告了名為 $a 的變數，接著使用 Get-Item Cmdlet 連接到 C:\Scripts\Test.txt 檔案。再過來，我們把該物件存入變數 $a。在輸入分號 (這讓我們只要寫一行就能執行多個命令) 後，我們將 LastWriteTime 屬性的值設定為目前日期和時間。好啦，這幾乎彌補了沒有杯架的缺憾，不是嗎？

好戲還在後頭
當然，您能夠做的絕不只有將上次寫入時間設定為目前日期和時間。例如，請看下列命令：
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
這回總共串連三個命令。首先，我們使用 Get-Date Cmdlet 建立了日期和時間各等於 5/22/2006 和 8:15 PM 的日期時間物件。為何稍早的指令碼 (指將上次寫入時間設定為目前日期和時間的指令碼) 沒有使用 Get-Date 建立日期時間物件呢？道理很簡單：Date 命令會自動傳回日期時間物件 (要親自證明這一點，請將下列命令輸入 Windows PowerShell 主控台：Date | Get-Member)。
建立了與所需日期和時間相等的日期時間物件後，我們接著使用熟悉的 Get-Item 命令，取得代表 Test.txt 檔案的物件 (即存入變數 $a 的物件)。最後，我們將 LastWriteTime 屬性設定為變數 $b 所代表的值：
$a.LastWriteTime = $b
信不信由您，精采的還介紹不到一半咧！瞧瞧這個不起眼的命令吧：
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
這個命令有什麼好玩的地方？呃，讓我們來看一下它的用途。第一部分倒很簡單：我們同樣建立了日期為 5/22/2006，時間為 8:15 PM 的日期時間物件。但是，注意第二部分使用的並非 Get-Item Cmdlet，而是底下這個命令：
Get-ChildItem c:\scripts
這是要幹嘛？嗯，將 Get-ChildItem Cmdlet 套用至資料夾就可傳回該資料夾內所有檔案的集合。我們抓取了該集合，再經管線 (即 | 符號) 將集合中所有的項目交給 ForEach-Object Cmdlet。
而 ForEach-Object 又會如何對待所有這些檔案？當然囉，它會逐一更改各個檔案的 LastWriteTime 屬性的值：
ForEach-Object {$_.LastWriteTime = $b}
附註 儘管本月專欄並非 Windows PowerShell 初學者指南，我們還是應該指出 $_ 是個特殊變數，代表 For Each 迴圈中的當前項目。此變數相當於下列 VBScript 迴圈中的 objItem：
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
在上述 Windows PowerShell 命令執行完成後，C:\Scripts 資料夾內所有檔案的上次寫入日期就都變成一樣。多虧有這些新發明的無馬自動馬車，我們辦到了！
要示範這類命令的千變萬化，我們可能得徹夜長談。例如，您或許只想更改 C:\Scripts 資料夾內 .txt 檔案的上次寫入時間？沒問題，那說一聲就行了：
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

激起您的興致
很酷吧！然而我們應該表明，本專欄的用意既不是向您「兜售」Windows PowerShell，也不是鼓勵您拋棄所有的 VBScript 指令碼而全部轉換成 Windows PowerShell。如果指令碼能依您的期盼完成需要執行的工作，那麼就留著不要更動；對於批次檔、命令列工具、密技指令和管理電腦所用的任何其他工具亦應比照辦理。記住這句話：沒壞，幹嘛...
其重點並不是說要用 Windows PowerShell 來完成原本就能辦到的事項；反倒在某種程度上因為 Windows PowerShell 提供了存取 .NET Framework 的能力，所以它能讓您辦到從來都無計可施的事項。例如，修改任一檔案 (或一組檔案) 的上次存取時間就是這種情況。視乎您需要做哪些事而定，也許還能舉出好幾個例子。Windows PowerShell 正因具備這些功能而值得人們仔細研究。
本篇內容針對 Windows PowerShell 的介紹法可能讓很多人感到稀奇：畢竟，有別於以 "Hello, world" 這種簡單的例子開場，我們直接切入了由多個部分組成的 Windows PowerShell 命令，且完全不談管線和 Cmdlet 等術語，似乎認為每個人都已瞭解其涵義。這是刻意安排的。歸根究底，我們知道讀者當中有很多人還沒嘗試過 Windows PowerShell；我們擔心，如果向您展示如何擷取電腦上各項服務的清單，您只會聳聳肩無奈地掉頭走人。
注意，我們希望您不要光是顧著駕駛。對許多讀者來說，開車時喝三份飲料、觀看 DVD 和打手機而不順便「閱讀 TechNet Magazine」是件困難的事。
嗨，繼續往下看：我們是在對大多數人說，而不是針對所有人。

Microsoft Scripting Guy 為 Microsoft 工作，也就是說受雇於 Microsoft。他們在不玩、不教或不看棒球 (以及其他各種活動) 的時候，就負責管理 TechNet Script Center。請到 www.scriptingguys.com (英文) 一探究竟。


 資訊安全新知: 部署全球信任的 PKI
資訊安全新知
部署全球信任的 PKI
John Morello
本專欄包含正式發行前資訊，隨時可能會有變動。

公開金鑰基礎結構 (PKI) 是在不同的應用程式、作業系統及身分識別領域間建立信任的基礎元素。此結構建立於階層式信任模型之上，在該模型中，終端實體信任最高根層次的通用金鑰，因而隱含信任由該根層次所簽署的其他任何金鑰。
鑒於此結構，只要再額外增加憑證授權單位 (CA)，設計周全的 PKI 很容易就能擴充規模，而無須引入終端實體變更。
PKI 的實作方式通常有兩種。最常用的方式是根據需要向某家隱含信任的全球根憑證提供者 (如 Cybertrust 或 VeriSign) 購得憑證。這些憑證通常用於保護網站流量，但也可以用於加密虛擬私人網路 (VPN)、對電子郵件簽章及執行類似工作。由於這些全球根憑證已內建到現今的每一種網頁瀏覽器和作業系統，採用此方法便能輕易跨越組織界限擴充信任關係。但是，由於這些憑證係視需要所購得，大型組織內部採用此方法進行廣泛部署可能所費不貲。
內部 PKI 模型近年來比較盛行。顧名思義，內部 PKI 僅在組織自身的網路中受信任。這種模型為組織提供成本較低廉的方法，可使用憑證佈建網路上的每位使用者和每部電腦裝置。此方法常用於促進諸如智慧卡登入、加密檔案系統 (EFS) 及保護無線網路等技術。其缺點在於因這些憑證並非全球受信任，故而不是很適合聯外的應用技術。因此，部署內部 PKI 的組織大多常用混合方式，向某家全球信任的根憑證授權單位購得公眾型應用所需的憑證。
然而，該如何併用兩種方式以獲取最大益處呢？貴組織能否執行自身的 PKI，既利用發行內部憑證來節省成本，而又同時佈建公眾信任的憑證，所有憑證均取自本機系統？這類方案不僅具有內部 PKI 的益處 (如 Active Directory® 整合、自動註冊及當地語系化 IT 支援)，還能施展全球信任根憑證的主要優點。路易斯安那州立大學 (LSU) 就擁有這樣的系統。在本期的「資訊安全新知」中，我將詳加介紹 LSU 實作的方案、討論其技術設計，並且重點說明部署類似系統的最佳作法。值得一提的是，以下介紹的方案係依據我們的環境、資源及業務需求的特殊需要而設計。您應當事先評估貴組織業務的所有這些層面，以便確定最合乎各項需要的方案類型。

LSU 的 PKI 作法
LSU 是以研究為主的一所大學，其學生和教職員工總數超過 40,000 人。本校擁有許多對校外公開的網站，其中多數網站都要求傳輸層安全性 (安全通訊端層 (SSL) 憑證的專用術語)。LSU 每年都編列數千美元預算，向全球信任的根憑證提供者購得憑證。
同時，LSU 還規劃其他的 IT 安全目標，基於此可善加利用設計周全的內部 PKI。根據 LSU 的目標和需求，您可能會研判我們選擇了混合模型。然實情卻非如此，我們決定採取另一種自認為更創新的作法。
我們與其中一家全球信任的根憑證提供者 Cybertrust 合作，在 LSU 校區部署了從屬於 Cybertrust 根 CA 的次級 CA (參見 [圖 1])。Cybertrust 依其 OmniRoot 計畫而提供這項服務。在此方案中，LSU 建立並且運行了在 LSU 自有的設備本機上執行的 CA。然而，與稍早討論的內部模型不同，LSU 的 CA 不是自我簽署，且其金鑰 (連同此金鑰簽署的任何金鑰) 幾乎在現今的所有作業系統和瀏覽器上都隱含受信任。就技術上而言，此設計是開放性 x.509 標準的邏輯擴充。由於 PKI 建立在這些標準上，不同廠商建立的系統可以安插到同一整體階層架構中。不可諱言，正是 OmniRoot 方案的服務使用規定特別引起了我們的注意。
圖 1 Cybertrust 全球根憑證
圖 1 Cybertrust 全球根憑證
OmniRoot 服務的設計對我們在 LSU 實作的 PKI 部署型態來講尤為合身。依據 OmniRoot 計畫，參與此計畫的組織每年要向 Cybertrust 支付一筆固定費用，然後就只需針對基於公眾用途而建立的憑證支付每份憑證的費用。換言之，LSU 可以視需要發行任意份數的憑證供內部使用，而不必擔心每份憑證費用累增。同時，公眾面的憑證費用如今也大大低於本所院校依需求購得憑證之情況下支付的費用。
說得更清楚些，內部憑證和公開憑證從技術觀點來看別無二致。兩者由同一 CA 鏈結所發行，具有相同的密碼編譯強度，而且是透過同一個註冊授權系統進行佈建。兩者唯一不同之處在於授權規定。
終於，我們已能夠用較低廉的成本擴展和增強 LSU IT 安全性平台。此項成就為 LSU 的這種 PKI 方案樹立了絕佳的業務典範。接著我們就來看看部署的其他技術細節。

PKI 階層架構
LSU 的 PKI 階層架構採用兩層式設計建構，根層是由 Cybertrust 管理，另一層為執行於 LSU 的線上發行 CA (參見 [圖 2])。根層形成了階層架構的信任支柱。換言之，由階層架構中任何 CA 發行的所有憑證，其間的信任關係均歸入根 CA 下 (參見 [圖 3])。因此，根 CA 形成了階層架構中所有 CA、憑證和終端實體之間聯繫的共同契約。由於 Cybertrust 全球根憑證已內建到 Windows® 及幾乎每一種現今的其他電腦系統，此共同聯繫契約將自動擴展到 LSU 的網路範圍外。
Figure 2 兩層式 PKI 階層架構 (Close Figure 2)

根層 (Cybertrust) | 發行層 (LSU)
由 Cybertrust 管理 | 由 LSU 管理
位於 Cybertrust 的保全資料中心 | 位於 LSU 的 Baton Rouge 校區
包含在幾乎現今所有電腦系統的預設根憑證內 | 發行憑證給 LSU 系統組織內的終端實體
 | 由 LSU 發行的憑證均歸入 Cybertrust 根層下，因此受到全球信任
圖 3 由 LSU 的發行 CA 所發行的憑證
圖 3 由 LSU 的發行 CA 所發行的憑證
Cybertrust 有個安全託管設施專責管理 CA。該託管設施採用強固的實體安全控制，包括人工攔截、生物特徵鎖和全銅外殼的儲存庫。Cybertrust 只會發行憑證給已證明符合其安全性及憑證原則的組織設置的發行 CA。
LSU 的發行 CA 是終端實體面的系統，負責為 LSU 的使用者和電腦群體提供憑證。提供的憑證由階層架構中位於其上層的 Cybertrust CA 所簽署，且所發行的憑證透過其本身鏈結到 Cybertrust 根 CA (參見 [圖 3])。

發行 CA 的作業系統和硬體
LSU 使用已安裝 Service Pack 1 的 Windows Server® 2003 Enterprise Edition 做為發行 CA。Windows Server 2003 憑證授權單位服務提供多種新功能，包括金鑰保存、delta CRL (憑證撤銷清單) 及「第 2 版」範本。做為發行 CA 的 Windows 執行個體依據 LSU Windows Server 標準建置原則而建置。該系統已使用所有相關的安全性更新進行更新，且系統管理上使用了 LSU 標準的變更管理措施及軟體清查和更新工具。簡言之，雖然在管理 CA 服務本身方面有一些獨特之處，基礎伺服器硬體和作業系統極易與組織既有的 IT 作業相整合。
除了遵循 LSU 最佳標準作法進行伺服器安裝，我們還利用了 Windows Server 2003 Service Pack 1 提供的資訊安全設定精靈 (SCW)。SCW 所用的資料庫含有依存性量表，當中詳列 Windows Server 可執行的各種負載，以及這些負載所需的安全性設定。該資料庫包括將由 CA 提供的兩個主要角色：CA 服務本身和 IIS (提供 PKI 自助網站)。
我們使用 SCW 很容易就建立了一個安全性範本，該範本建議停用所有服務，僅保留供這些負載執行及強化伺服器網路堆疊所需的服務。接著我們使用 scwcmd.exe 將該範本轉換成群組原則物件 (GPO)，以期能在組織單位層級下套用到伺服器。由於 LSU CA 以角色為主的安全性設定如今儲存在 Active Directory 內而與特定電腦無關，這種作法可簡化規模擴充和損毀修復的過程。
LSU 的發行 CA 建置在 IBM xSeries 346 伺服器上，有兩顆 3.2GHz Intel Xeon 處理器、4GB RAM 和五個 146GB SCSI 硬碟。根據 CA 服務的效能需求以及 LSU 採用硬體安全性模組的事實，這樣的平台應能展現顯著的生命力和成長空間。
我們依照最佳標準作法建立了兩個 RAID 1 陣列，將資料庫和異動記錄檔分置於不同的磁軸上。第五個硬碟保留做為這些陣列皆可使用的熱抽換備援。第一個陣列掛載為系統磁碟區，用於存放 CA 資料庫。第二個陣列用於存放異動記錄檔及其他各種資料檔 (如 CRL)。CA 資料庫採用的 Jet 技術與 Windows 其他部分 (像是 Active Directory) 相同，所以其他的 Jet 存放解決方案的維護和磁碟設定最佳作法在此同樣適用。
硬體安全性模組 (HSM) 是專責的硬體裝置，其管理體系與作業系統分開。HSM 通常是 PCI 介面卡的型式，但也有生產網路型的設備。這些模組提供了保全 CA 金鑰的硬體存放區，以及可加速簽署與加密作業的密碼編譯專用處理器。Windows 係透過 CryptoAPI 介面取用 HSM，將 HSM 視為密碼編譯服務提供者 (CSP) 裝置。OmniRoot 計畫要求每個 CA 至少使用一部已通過 FIPS 140-2 level 3 (level 4 裝置相當罕見) 認證的 HSM 來產生和存放金鑰。既為獨特而又高度安全的裝置，HSM 的造價當然不便宜；PCI 型式的 HSM 定價一般在 $10,000-15,000 美元之間。
LSU 的設計使用了一部 nCipher nShield 500 TPS (「每秒 500 次異動」型號) 做為直連式 HSM (「直連式」表示裝在伺服器內部且僅供該伺服器使用，不像網路型 HSM 可供多部主機共用)。該 HSM 是 FIPS 140-2 level 3 裝置，為金鑰產製原料提供 N 之 K 重保護。HSM 提供了高度保障以防私密金鑰遭洩露；攻擊者必須持有 HSM 儲存體以及額定數目的存取權杖及其 PIN 才能存取金鑰。
關鍵需注意一點，HSM 是為防止其內容遭到惡徒竄改而設計。因此，HSM 對連續登入嘗試失敗施加了嚴格的限制。在 LSU 的設計中，連續 10 次嘗試失敗後，儲存體將消除內容且無法挽回。
我們的配置只有一個 CA，因此沒有理由使用高價的網路型 HSM。不過，如果組織打算實作兩個以上的 CA，便可購買一台網路型 HSM，讓各 CA 共用以大幅降低成本。此方法也使權杖管理變得更容易，因為所有的金鑰儲存體可由同一組權杖加以保護。

Active Directory 和註冊
Windows 架構的 PKI 方案其主要優點之一是，無須在參與 PKI 的實體上安裝額外軟體即可完成憑證佈建。相反地，透過結合自動註冊和群組原則，大多數的憑證佈建都能進行自主式管理，且不可見於一般使用者。LSU 採用這項技術自動將電腦憑證分發到隸屬為其 Active Directory 成員的電腦。而且，我們使用了一個自訂網站，為非 Windows 主機提供自助憑證要求功能。
如前所述，OmniRoot 計畫區分公眾使用的憑證和內部使用的憑證。憑證若是供給不屬於 LSU 組織的系統和使用者使用 (例如，新生透過 SSL 安全網站提出入學許可申請)，即視為公眾憑證。供 LSU 組織內部使用的憑證 (比方用於加密 LSU 伺服器上資料的憑證) 則視為內部憑證。
由於 OmniRoot 計畫的費用取決於公眾面的憑證份數，我們必須能夠追蹤究竟發行了幾份憑證以及發行給哪些人。因此，對於任何公眾用途的憑證，範本的分辨名稱均以 "PublicCertificate" 開頭，顯示名稱則以 "Public Certificate" 開頭。例如，公眾面的 LSU TLS 憑證範本是以預設的 Windows 網頁伺服器範本為基礎，而稱為 Public Certificate LSU Web Server。針對內部使用的網頁伺服器，我們使用了另一份範本稱為 Internal Certificate LSU Web Server。就技術上而言，這兩份範本完全一樣；命名方式不同只是為了方便記帳。
對於大宗註冊需求 (例如：為與 IPSec 搭配使用憑證而註冊整個部門)，我們仰賴自動註冊。這是 Windows 所內建既簡單又高效率的工具。就 PKI 管理員的立場，唯一需要採取的動作是更改範本的存取控制清單，對需要憑證的使用者或電腦群組授與自動註冊權限。這些實體隨後會自動檢查 Active Directory、列舉其擁有自動註冊存取權限的範本、找出持有這些範本的 CA，然後自動註冊憑證。此外，自動註冊功能亦可確保當範本已遭替代及在到期之前自動更新時隨之更換憑證。
對於非大宗用途，諸如佈建備有憑證的網頁伺服器，我們利用自助網站讓使用者透過網頁瀏覽器要求憑證。該網站是根據 Windows Server 2003 隨附的註冊網頁 (/certsrv 虛擬目錄) 而自訂的版本；我們的實作包括 LSU 的標準 Web 商標，以及預先填妥正確預設手續的要求頁面。我們並且使用了 Windows CA 服務預設的結束模組，於透過該網站提交的要求需經核准時自動寄送電子郵件給我們的 PKI 管理小組。

撤銷憑證之設計
每份憑證都有存留有效期限。有時，LSU 需要使未達有效期限的某些憑證失效 (例如，若發給某位員工的憑證將於 2007 年 5 月期滿，但該員工在 2007 年 1 月就從 LSU 離職)。這類撤銷是利用 CRL (憑證撤銷清單，包含由 CA 簽署的憑證序號清單的檔案) 來完成。包含在 CRL 中的序號指出存留有效期限未滿但 LSU 不再認為其值得信任的憑證。隨後用戶端可下載這份 CRL，再與之比對以得知憑證的有限期限。
任何 x.509 v3 憑證 (根 CA 憑證本身除外) 均應有指向有效 CRL 的指標。這個指標稱為 CRL 發佈點，簡稱 CDP。CRL 發佈點隨附於憑證本身 (參見 [圖 4])，且在憑證發行後即無法修改。CRL 是能夠保證由 CA 發行的憑證確為有效的基本要件。正因此，我們確定了 LSU CRL 具有實體容錯性與高可用性，並且可供外部各方存取。
圖 4 LSU 的 CRL 發佈點
圖 4 LSU 的 CRL 發佈點
與 Active Directory 整合的 Windows Server 架構 CA (像 LSU 那樣) 會自動將其 CRL 發佈到 Active Directory，藉此即可透過輕量型目錄存取協定 (LDAP) 存取 CRL。預設發佈位置是在樹系中位於 Public Key Services 容器內的 CDP 容器 (參見 [圖 5])。此發佈位置是個絕佳選擇，因為它提供了自動複寫、容錯及 CDP 位置尋查功能。
圖 5 CDP 容器
圖 5 CDP 容器
然而，LSU 的設計尚有許多非 Windows 及非 Active Directory 電腦也利用了 PKI。且儘管 LSU 是個大型組織，其絕大多數的使用者都位於同一校區網路 (配備 10Gbps 骨幹)，使得以 Active Directory 為基礎的 CDP 發佈甚難發揮優點。
因此，我們只將 CRL 發佈到某個 HTTP 路徑，這樣就更容易建置備援主機平台 (我們的主網站已建立鏡像)。這也附帶消除了與啟用用戶端 LDAP 尋查有關的潛在複雜性。我們每天發佈一次 CRL，每小時發佈一次 delta CRL。

展望
儘管我們當前的 PKI 為大學社區提供了強固的安全性方案，我們仍計劃持續增強其功能。Windows Vista™ 及下一版 Windows Server (代號 "Longhorn") 將會提供大量新的金鑰管理功能，而我們正計劃對這些功能展開研究。我們尤其感興趣的計有：預定推出的線上憑證狀態通訊協定 (OCSP) 用戶端和回應程式能力、對 Elliptic Curve Cryptography 與 SHA-256 演算法的支援，及大幅改進的自動註冊介面。此外，Windows XP Service Pack 3 還預定納入所謂認證漫遊的功能，可為金鑰組提供安全漫遊且不會對漫遊設定檔造成負擔。最後，我們正積極研究憑證週期管理員 (目前已有測試版)，盼能改善報告及管理能力。
總之，LSU 的 PKI 為本所大學提供了基本的安全服務，並且應用於許多關鍵性的 IT 功能。使用 Cybertrust 的 OmniRoot 服務，我們得以執行與 LSU 的其他 IT 系統完美整合但廣受全球信任的 PKI。再者，經由將方案建置於 Windows CA 服務上，我們既擁有高效率的憑證佈建和管理能力，也完美整合了現有的目錄及身分識別管理系統。簡言之，具有強固安全性和綿密信任的 PKI 願景已在 LSU 獲得實現。

John Morello 以優等畢業生殊榮畢業於路易斯安那州立大學，並且在 Microsoft 的 Microsoft Consulting Services 擔任過六年的資深顧問。任職於 MCS 期間，他曾為策略性客戶如 Deloitte、GE 及各大聯邦組織建構 PKI。他目前擔任 LSU 的副首席資訊安全長。


 桌面檔案: 瞭解 Windows 影像格式
桌面檔案
瞭解 Windows 影像格式
Wes Miller
本專欄是根據 Windows 部署工具的搶鮮版 (Prerelease Version) 所撰寫。本文包含的所有資訊均有可能變更。

隨著 Windows Vista 的發行，Windows 的安裝與部署方式有了重大改變。Windows Vista (還有即將發行的 Windows Server 版本，代碼命名為 "Longhorn") 的安裝程式引擎和整套部署工具都已改寫。我曾在 TechNet Magazine 近期文章中討論過這些改變
及 Windows® 部署團隊為進行這些改變所付出的努力。但關於這一主題還有許多要討論的內容，所以我將在此新設的定期專欄中介紹 Windows PE、Windows 安裝與部署，以及其他 Windows 管理與安全性的主題。
在此第一期專欄中，我將討論全新的 Windows Imaging Format (WIM) 影像格式。如果您還不太熟悉影像的細節，請務必閱讀＜典型影像處理過程＞資訊看板上的概述。接著在下一期專欄中，我將討論 Windows Automated Installation Kit 這套新工具，看看如何利用其隨附的 ImageX (用於建立及操作 WIM 影像的命令列工具) 和 Windows 部署服務 (WDS，將取代遠端安裝服務 (RIS)) 等工具更輕鬆部署作業系統。

轉折點
Windows 部署團隊年復一年地從 OEM 和企業客戶那裡聽到相同的意見反應。他們希望改善對影像的支援，也期盼 Microsoft 提供統一的影像工具。這些使用者不想選擇協力廠商，深怕難以瞭解其產品的錯綜複雜。並且，我們常常聽到這樣的抱怨，即 OEM 和企業客戶認為他們使用影像工具部署 Windows 不該付費，而是應由 Microsoft 提供這些工具。
在 Windows Vista™ 開發初期，Windows 部署團隊下了一個非常大的賭注。我們決定徹底放棄整個安裝程式引擎；該引擎有許多元件已存在近十年之久。安裝程式一直是個脆弱的環節，而且步驟太多。我們打算加速安裝過程，移除不必要的步驟並增進 Windows 安裝程式的整體可靠性。為此，我們將一改過去一段時間以來所採用手動接合引擎的整個安裝過程，用完全以影像為基礎的安裝程序來取代。

設計全新的影像格式
在重新設計安裝程序之初，我們就著手定義應該使用的影像類型了。該用磁區或檔案一直是爭論的焦點。也就是說，應使用以逐個磁區複製的方式來儲存磁碟區複本的影像格式，還是使用以個別檔案為基礎儲存每一個檔案的影像格式。大多數人不外乎期望得益於速度 (複製磁區的方式) 和壓縮程度 (以檔案為基礎的方式)。最後，我們用了一種格式，我感覺此一格式最完美折衷了這兩項益處。它不但具有絕佳效能，還提供極高的壓縮程度。
為了設計出能滿足 OEM 和企業使用者需求的影像格式，我們首先定義了幾個必須實現的主要目標。我們列出的目標極度傾向於以檔案為基礎的架構。我想我們全都看到了此一架構的優勢，所以一開始就朝這個方向努力。不久之後 WIM 檔案即順勢誕生 (您可能會感到奇怪，WIM 中的 "M" 似乎不具任何意義。我們根據 Windows 團隊在逼近出貨里程碑期間的頻繁活動將其命名為 WIM，不然 *.WI 這種縮寫看起來怪怪的)。那麼，且容我介紹一下針對新影像格式提出的一組目標。
中性 Windows 檔案系統格式 影像格式必須能跨 Windows 支援的兩種檔案系統架構而運作。雖然幾乎所有系統都使用 NTFS 執行，許多 OEM 和企業仍使用 FAT 檔案系統做為權宜之計，以期能用 MS-DOS® 部署 Windows。他們日後會轉換為 NTFS。Windows Vista 必須繼續支援此格式。
中性磁碟區幾何 我們必須解決擷取大型磁碟區並將之套用於較小磁碟區此一歷史問題。儘管影像工具可透過磁碟分割操作手段解決此問題，卻不是很可靠。在以檔案為基礎的架構中，影像佔用的空間大小僅為組成該影像的多個檔案的大小。由於檔案系統單獨還原，磁碟區大小並不可靠。
典型影像處理過程
當 OEM 複製大量系統或大型組織需將 Windows 部署到眾多電腦時，通常會採用影像技術。前提是使用主機系統，完全按照需要進行建置，然後將其複製到目標系統。如果您不太熟悉影像處理過程，請看以下大略介紹。
  1. 系統管理員將 Windows 安裝到系統並視需要進行設定。設定層面包括新增和移除元件、安裝常用的應用程式，以及調整 UI 和其他設定。我們稱之為主機系統。
  2. 系統管理員接著執行 Sysprep (由 Microsoft 提供的 Windows 部署工具)，它會執行清理屬性的大幅翻新工作，使 Windows 安裝具有獨特性 (例如電腦名稱、Windows 安全性識別元 (SID) 及其他跨系統的唯一識別元)。當 Sysprep 執行到後半段時，會重設這些屬性。
  3. 隨後，系統管理員將電腦關機再重新開機，以進入 Windows PE、MS-DOS 或能執行影像應用程式的其他作業系統。
  4. 現在系統管理員會執行影像工具，建立參考系統的影像。該影像是個檔案 (或檔案集合)，含有參考磁碟或磁碟分割的確切複本。
  5. 待系統關機後，系統管理員將影像封存，並可視需要再更新影像 (新增應用程式、Hotfix 和 Service Pack)。
  6. 複製影像到一或多部電腦上，至此 Sysprep 完成其工作，執行簡化版安裝程式 (稱為「迷你安裝」或「Windows 歡迎畫面」，取決於執行 Sysprep 時所用的 Windows 版本和 Sysprep 的設定方式)。此階段依賴極小的原生模式可執行檔，名為 setupcl.exe。

中性系統架構 影像架構必須順應 Windows 可能支援的任何架構。當初，這意味著支援截然不同的 x86 和 IA64 (Intel Itanium) 架構。而如今還包括了 x64 (AMD64 和 EM64T) 架構。
必須快速擷取與套用：如果是壓縮形式，擷取影像的速度必須夠快。而更為關鍵的是，必須以極快速度套用影像。
支援非破壞性影像套用 由於我們改變了升級選項 (僅取代了 Windows 而無損於使用者資料或應用程式)，並推展出可用於系統修復的工具，我們希望此工具能夠製作系統影像，但不會銷毀磁碟區上任何現有的內容。以磁區為基礎的格式則需經相當繁複的作業，才能讓使用者達此目的；您通常只能還原整個磁碟區，或是完全不還原。
支援大量壓縮 在 Windows Vista 開發初期，我們仍著重於以 CD 供貨。但鑒於 Windows XP 的影像大小將近 1GB，我們確信儘量緊密壓縮影像很重要。以磁區為基礎的影像雖可透過一些手段實現此目的，我們所關切的是這種實現中的移動部分。以磁區為基礎的格式大多基於節省空間而省略磁碟上的空白區域 (影像大小若始終為 0，何需多此一舉再記錄 0)。然而，由於使用以檔案為基礎的方式，我們原本就能安然處理這點，因為我們不會佔用空白區域。
支援檔案的單一執行個體 這個問題與前述問題相同。眾所周知，Windows 可在幾個不同位置儲存同一檔案的多份複本。以檔案為基礎的方式使得每個檔案僅儲存單一執行個體更容易，便於視需要取用檔案。
支援跨媒體 (光碟) 延伸 甚至在 WIM 的初期階段，當我們可以將整個影像放入單張 CD 時，就已意識到必須支援多張媒體。即使 Windows 以單張 CD 供貨，一旦使用者新增應用程式、Service Pack 等元件後，其影像很可能超出單張 CD 或 DVD 可容納的大小。因此我們必須支援跨多張媒體延伸影像，讓使用者因應本身所需的安裝及復原方案。
單一檔案 Blob 支援多重磁碟區影像 單一影像很少能應付一切情況。在設計「單一執行個體」時，我們也納入了選取多重磁碟區的功能，賦予每個磁碟區相同程度壓縮且彼此互為支援單一執行個體。因此，如果您先選取 Windows XP Professional 的影像，又接著新附加 Windows XP Tablet PC Edition (Windows XP Professional 之超集合) 的影像，則影像增大的部分僅會包含兩種版本之間明確不同的檔案。
藉此，OEM 或企業使用者就能附加許多系出同門的影像，而其大小不致呈指數增加。以磁區為基礎的格式則很難實現此功能。

WIM 的運作方式
WIM 格式的設計目標是儘可能簡單，同時符合我們的指導原則。以檔案為基礎的方式恰能達成這些期盼。但確切的運作情形又是如何呢？
簡言之，您可以將 WIM 檔案看成是 CAB 檔案 (類似 ZIP 格式，但 CAB 格式為 Microsoft 所設計且擁有)。實際上，我曾聽說 WIM 被稱作「CAB 的子項」。WIM 檔案與 CAB 檔案之間的主要差別在於，除了擷取和壓縮檔案本身外，WIM 影像還針對擷取為特定磁碟區影像的磁碟區，儲存其組成檔案和目錄的中繼資料。因此，它有點像一種封存檔案，含有將磁碟區還原到影像建立當時狀態所需的一切中繼資訊，如：存取控制清單 (ACL)、短檔名和長檔名、檔案屬性等。
請注意，擷取程序從開始到結束都不會收集磁碟分割資訊 (大小或類型)。套用過程中也不會對系統進行磁碟分割。ImageX 與多數影像工具不同，對磁碟分割採取中性立場，套用前必須先建立並格式化磁碟分割。您可以使用 diskpart 和 format 命令列工具自動執行此程序，然後再套用影像。
磁碟區影像可儲存的內容不受任何限制。單一影像可以包含兩個磁碟區 (同一磁碟區分別在星期二和星期四擷取內容)，其中一個磁碟區影像有 Service Pack 而另一個則沒有，或者附帶您所需要的其他項目。主要應瞭解的重點是，同樣的檔案只會擷取一次。兩個磁碟區影像的共通之處愈少，即佔用愈多空間。
另外需提醒的是，WIM 格式的設計對舊版 Windows 來說毫無使用上的障礙。Windows 2000 也能使用此格式，與 Windows Vista 使用的情況一樣良好。現在我們就來仔細瞧瞧，擷取和套用影像時確切發生的現象。

擷取影像
擷取磁碟區影像時，將逐步執行下列作業：
擷取磁碟區中繼資料 ImageX 收集整個磁碟區有關檔案名稱、NTFS ACL 及其他檔案系統屬性的資料 (您可選擇利用指令檔排除若干檔案)。
擷取檔案資料 ImageX 載入檔案。每個檔案都載入到磁碟區上，以準備收集各檔案的特定相關資料。
產生檔案雜湊 根據檔案本身產生檔案的加密編譯雜湊。此雜湊將成為檔案在影像中的唯一識別元。
檢查若發現重複便予以移除 如果影像中存在另一個檔案具有相同的雜湊，即假定為同一個檔案，因而藉由指向既有檔案的方式來參考新檔案。
壓縮獨特的檔案資料 與採用 CAB 或眾多其他封存格式不同，WIM 檔案中的每個檔案會單獨壓縮，而不是將許多檔案組成集合視同單一資料流進行壓縮。您也可以選擇完全不壓縮，而跳過這個步驟。
壓縮並儲存磁碟區中繼資料 待所有檔案都已封存，會建立磁碟區的中繼資料項目。此項目列出加到磁碟區影像中的每個檔案。
產生並儲存影像的 XML 資料 這是所擷取的每個磁碟區影像的參考。例如，執行 ImageX /info 便會看到這份 XML 資料。
寫入快取的 WIM 資料索引 最後一步是寫入主資料索引 (連同快取的資料)。這是整個 WIM 的主檔案表格，其中每份雜湊各包括一個項目。
如您所見，WIM 是以逐一檔案的方式建立。此外，不論影像附加了幾個磁碟區，都只會建立一個 WIM 檔案。

影像超載
在我們開始著手進行 WIM 的相關研究時，某些團隊也正開發類似的方案。Automated Deployment Services 團隊當時正在為另一種客戶群開發影像方案。他們的作法有些低階的實作細節很耐人尋味，但仍不能免俗地採用該時期最普遍以磁區為基礎的影像引擎。Windows XP Embedded 團隊也建置了以磁區為基礎的影像引擎，讓嵌入式獨立硬體廠商 (IHV) 在系統製造階段部署其系統影像。而當 Microsoft 於 2003 年成立 Virtual PC 團隊後，該團隊甚至引進了另一種檔案格式，稱為虛擬硬碟 (VHD) 檔案。
所有這些格式的核心都是以磁區為基礎。這些方案雖能滿足特定客戶群的需求，卻未符合我們對 WIM 的指導方針。因此，我們繼續建置新的 WIM 格式，以及用於擷取影像的 ImageX 命令列工具。終於，在我們的格式隨著 Windows Vista Beta 版公諸於世之前，某些團隊早就予以採用且成效頗佳。例如，SMS 團隊在其 Operating System Deployment Feature Pack 中便已提供 WIM 的初期實作。

套用影像
接著我們就來看看反向程序：套用影像。
載入快取的 WIM 資料索引：此部分涉及前述程序的最後一個步驟。由於這是主索引，在您指定了要套用的磁碟區影像後，第一步就是從 WIM 將其載入。
擷取並載入影像中繼資料 ImageX 載入每個磁碟區影像特有的中繼資料。
建立目錄結構 為確保每個檔案的還原位置都已就緒，需建立磁碟區的整個目錄樹狀結構。
解壓縮檔案資料 完全按照檔案封存時的相同順序，從 WIM 逐一解壓縮檔案。
套用檔案資料 此步驟會將檔案載入、進行解壓縮 (若磁碟區影像曾使用 WIM 進行壓縮過)，接著複製檔案到參考位置。最後則套用每個檔案的中繼資料。
套用所有的目錄中繼資料 此為很重要的最後步驟，因為目錄的 ACL 若有問題可能會妨礙正確套用影像。

彈性壓縮
我們對 WIM 影像格式期許的主要目標之一就是提供彈性的壓縮選項。因此，我們提供了擷取磁碟區影像時可視需要予以壓縮的功能，也允許未壓縮便進行影像擷取。如果影像不需要積極壓縮，或是高速擷取很重要時，最好選擇不壓縮。
進行壓縮時，請切記一些關鍵原則。壓縮一定比解壓縮更耗時間。壓縮演算法愈精密，壓縮特定資料集就需要愈久的時間。而且提供給壓縮演算法的資料愈多，壓縮效果就愈好。
WIM 影像可使用 XPress 或 LZX 壓縮法進行壓縮；當然，也可以選擇不壓縮。如果您需要稍作壓縮，但不希望擷取程序耗費太多時間，XPress 算是不錯的折衷辦法。LZX 提供最佳壓縮比，但是可想而知，這種壓縮法佔用的時間相當長。
選擇不壓縮可達到最快的影像擷取速度，然而產生的影像也最大。壓縮類型是以每個 WIM 為準的選項。磁碟區影像一旦擷取為 WIM，後續擷取的所有磁碟區影像都必須採用與之相同的壓縮設定。
請注意，由於 WIM 影像壓縮是對逐一檔案進行，以致壓縮可能不完整。這是刻意做出的決定，目的是要讓影像更易於編輯。擷取後還能編輯影像是非常重要的選項。對已擷取為影像的檔案進行編輯意味著必須取代檔案資料及其中繼資料。如果我們一次就壓縮了整個 WIM，要設計出支援編輯檔案的選項 (若非全然不可行) 簡直複雜到令人難以置信的地步，而且取代影像中的檔案所耗時間將十分可觀。經由幾番折衷，我們想出了一種格式，不但可有效壓縮也能使用我們設計的工具進行編輯。
但願本文已讓您徹底瞭解，我們為 Windows Vista 所設計各種影像功能的運作方式。在下一期專欄中，我將介紹幾種用於管理與部署 WIM 影像的工具，針對 ImageX 和 Windows 部署服務詳加討論。

Wes Miller 是 Pluck 公司 (www.pluck.com (英文)) 的開發經理，該公司位於美國德州奧斯丁。Wes 之前任職於同樣位在奧斯丁的 Winternals Software，並在 Microsoft 擔任過 Windows 程式經理與產品經理。您可透過 technet@getwired.com 與 Wes 聯繫。Wes 對 John Macintyre (現任 Microsoft 的 WIM/ImageX 程式經理) 給予本專欄從旁協助甚表感謝。


 Windows 機密: 等待 RunOnce
Windows 機密
等待 RunOnce
Raymond Chen

試想 一個需要在程序中重新啓動系統的安裝。例如，程式可能想要升級目前正在使用的系統 DLL。您可能需要觸發一個中途的重新開機才能安裝新的 DLL 檔案，然後，在 DLL 升級完畢後，您才可以將其用於安裝的下一階段中。
RunOnce 機碼便是針對這類情況而開發，在中途重新啓動後，安裝程式利用它來完成各自的安裝 (這是過去認為程式不會突槌的那段日子)。
Windows® 檔案總管會在建立桌面和工作列之前等待 RunOnce 程式執行完畢。這是因為 RunOnce 的原則就是為了支援安裝程式而執行。由於 RunOnce 程式可能會變更系統組態資料，所以您不希望使用者在重新設定系統期間使用該系統。
例如，RunOnce 程式正在對其剛剛安裝的檔案執行重定基底和繫結，其中有些是殼層延伸的一部分。您當然不希望使用者在程式或延伸的可執行檔案仍在更新的同時，嘗試執行該程式或啟動該延伸。
「支援安裝程式」原則的另一個缺陷是，當具有管理員權限的使用者登入時，才會對 RunOnce 機碼進行處理。因此，不是管理員的使用者便無法完成安裝。除此之外，如果對非管理員執行 RunOnce 機碼，則它將不再是「執行一次」。事實上，這會造成一個進退兩難的局面。這時您會怎麽說呢，「好吧，我執行過了，別再執行了好嗎」？如果要改變這個系統全域狀態，您需要擁有管理權限。另外，很明顯地，非管理使用者就是沒有管理權限啊！程式再也不會是「執行一次」，相反地，它會「一次又一次地執行，直到管理員登入為止」。
RunOnce 主要用於完成程式安裝，會顯示在 Windows 安裝程式中。當您試圖安裝 Service Pack 或升級為更新版本的 Windows 時，安裝精靈會檢查 RunOnce 機碼。如果機碼不是空的，您將收到一則錯誤消息，「程式安裝仍在進行中，請先完成安裝，然後再嘗試升級作業系統」。這是合理的，因為您並不想恰好在程式安裝過程當中變更作業系統。
RunOnce 的整個設計透露著它的過去。它在 Windows 95 中誕生，而這套作業系統並未區分管理員和非管理員。實質上，由於每個人都是 Windows 95 的管理員，所以使用 RunOnce 的安裝程式會依賴下次重新啓動時所執行的 RunOnce 活動。
對於近代的 Windows 作業系統，可能好幾個月都不會有任何具管理員權限的使用者登入，對於 Windows Vista™ 尤其是這樣。因此，需要執行 RunOnce 的程式可能會經歷漫長的等待。
題外話，我曾經見過一個沒完沒了的 RunOnce。每當它執行時，都會將自己重新加入至 RunOnce 機碼中。這明顯違反 RunOnce 機碼的用意，因為它不再是程式安裝的一部分，而是程式一般操作的一部分。而且，這種行為會導致 Windows 安裝程式一直報告，有一個安裝正在進行。
因此，使用者永遠不能升級作業系統，因為這個麻煩的程式永遠在說：「我還需要做一些小事情，而且一定可以做完」。程式今天不會完成安裝，「但是明天一定可以」。這非常類似於等待果陀，但希望不會有存在危機。

Raymond Chen 的網站 The Old New Thing (英文)，專門討論 Windows 歷程記錄和 Win32 程式設計。他目前正在寫一本書，書名恰好也是 The Old New Thing (Addison-Wesley, 2007)。