 TechNet Magazine February 2008

TechNet Magazine February 2008

Sharepoint: 在企業內收集資料的好方法

資訊是企業當中最重要的資產之一。但是要管理透過電子郵件、網頁表單和其他機制收集到的滿山滿谷的資料，可說是困難重重。本文將探討 Microsoft Office System 如何幫助您整合各個系統，並讓資料更容易存取。

Keith Deshaies Sharepoint: 建置強大的問卷基礎結構

收集和分析資料是企業營運不可或缺的一部分，但是您需要有工具可讓獨立的小組在需要的時候收集他們所需的資料。一同來了解您要如何使用 WSS 3.0、MOSS 2007 和 InfoPath 2007 建置一套完整而富彈性的問卷解決方案，並應用於整個企業。

Jim Bradley Sharepoint: 透過自訂內容類型將資料管理標準化

一般大型企業儲存的各種文件等內容為數眾多。要以集中、可重複使用的方式管理文件、相關的中繼資料及其行為並非易事。一同來了解 SharePoint 2007 的內容類型如何幫忙簡化整個企業的內容管理。

Pav Cherny Office Communications Server: 目前狀態如何發揮 OCS 2007 的功力

Office Communications Server 2007 會利用使用者空閒狀態的資訊，將通訊路由到最適當的地方 — 無論是傳送語音電話、視訊會議、電子郵件訊息，或是 IM。讓我們一同來了解 OCS 2007 系統如何利用目前狀態連接各個端點。

Rajesh Ramanathan Office Communications Server: 規劃 OCS 2007 語音部署

整合 Office Communications Server 2007 與現有的 PBX 系統可說是極具挑戰的工作。除了必須挑選整合的案例、了解呼叫路由、知道如何設定使用者設定、處理號碼對應表等外，還有其他考量。不過別擔心！這篇文章會概述說明您需要知道的一切。

Jochen Kunert and Rui Maximo 高效能運算: Windows Compute Cluster Server 簡介

高效能運算已不再依賴大型的特製系統，轉而採用規模較小的標準系統叢集。透過這種方式來分散工作負載可提供具有經濟效益的解決方案，進而迅速處理複雜的問題。一同探索 Windows Compute Cluster Server 2003 提供的運算叢集功能與支援。

John Kelbley and Doug Lindsey 線上特刊: 透過終端機服務部署 2007 Office System

在將 2007 Microsoft Office System 部署到您的終端機服務伺服陣列之前，有些設計上的變更要特別注意。本文將概略說明這些變更。

James D. Silliman 編輯的話: 面對資訊爆炸的時代

Joshua Hoffman 讀者來信: 讀者有話直說

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

Greg Steen SQL 問答集: 非叢集索引和保留權限

Saleem Hakani and Dan Carollo 公用程式焦點: ADMX Migrator

Windows Vista 把群組原則範本的格式改為以 XML 為主的結構。ADMX Migrator 公用程式可以將您的舊版 ADM 檔案轉換成新的 ADMX 格式，並且幫助您輕鬆建立自己的自訂 ADMX 檔案

Lance Whitney The Cable Guy: IEEE 802.1X 有線驗證

IEEE 802.1X 驗證在您存取內部網路時，會額外提供一層安全性屏障。且讓我們看看 Windows Vista 和 Windows Server 2008 如何輕而易舉的實作有線網路的 IEEE 802.1X 驗證。

Joseph Davies Windows PowerShell: 命令介面權限

Windows 中的權限本來就很複雜，沒辦法。但是 Windows PowerShell 可以幫忙簡化。接下來就讓我們快速掌握 Windows 權限的運作方式，並了解如何利用它們來簡化工作。

Don Jones 嗨，Scripting Guy！: 比賽即將展開！還有一些 XML 也準備好了

Microsoft Scripting Guy 為「2008 指令碼比賽」持續加溫，並為您示範如何建立、附加及修改 XML 文件。附帶一提，您應該聽過「2008 指令碼比賽」吧？

The Microsoft Scripting Guys 安全性監控: 跳島攻擊：防堵不當的依存性

不當的安全依存性可能害讓整個網路暴露於攻擊下。唯有找出安全依存性的運作方式，方能分析環境中的依存性，解決潛在的問題。

Jesper M. Johansson 桌面檔案: Windows XP 和 Windows PE 2.0 雙重開機

從 Windows 的同個磁碟分割啟動 Windows PE 2.0 有很多優點。一同來了解如何從相同的磁碟分割雙重啟動 Windows XP 和 Windows PE 2.0，並探索這種作法可解決的問題。

Wes Miller 現場筆記: 樂捐您的電腦

藉由捐贈和重複使用舊硬體，您可以避免將舊硬體送入垃圾掩埋場，進而保護我們的環境。本文中的秘訣能夠協助您從舊電腦設備中有效刪除個人資料，以準備好捐出電腦。

Jim Lynch Windows 機密文件: 去蕪存菁

本文的故事是關於某些不那麼受歡迎的功能是如何漸漸消失的。

Raymond Chen


 Sharepoint: 在企業內收集資料的好方法
Sharepoint Keith Deshaies

在企業內收集資料的好方法
摘要:
  • 收集和處理資料
  • 區隔展示邏輯與資訊管理邏輯
  • 使用 Microsoft Office 2007 技術來建造資料收集解決方案
下載本文程式碼: DataGathering2008_02.exe (567KB)

企業採用各式各樣的方法來收集大量的資訊。資料透過電子郵件、問卷、網路表單和其他資料收集機制接踵而至。有資料，通常
是好事。不過，管理一系列資料收集工具，以及各種不同的資訊並不容易。可靠的整合和安全分享資料是 IT 組織經常面臨的挑戰。各項標準和服務導向架構的不斷發展，方便 IT 專業人員讓資料更容易存取，也更安全。雖然您擁有所需的工具和技術來建置一套有效的企業架構，但卻常常受限於專有的介面 — 而這往往會使解決方案孤立無援。
舉 Microsoft® Office System 中提供的技術為例。您可以根據 Windows® SharePoint® Services 3.0 迅速建立部門問卷，但這是否是標準的解決方案，得看貴組織而定。 如果貴公司使用 ASP.NET 和 SharePoint 作為進行網路共同作業和資料整合的平台，那麼此問卷的確能提供標準的解決方案。但若是您的環境跟我使用的一樣，SharePoint 只不過是許多平台當中的一個。
沒錯，SharePoint 提供與 IBM、HP、Siebel 等系統整合的許多選項。這對於想要建立臨機操作解決方案，卻仍然希望資料結果流向各類後端系統的進階使用者來說，無非是個好消息。不過，如果您是解決方案架構設計師，甚至還有更棒的選擇 — InfoPath® 2007。
透過 InfoPath 2007 (它是 2007 Office System 的一部分)，您可以將解決方案的展示邏輯與伺服器上裝載的資訊管理邏輯相區隔。藉著 XML 架構的 InfoPath 技術，您便能建立適合企業使用的資料收集解決方案。而且，InfoPath 表單設計人員通常不用精通 XML、Web 服務、解決方案架構、ASP.NET，或是 SharePoint 物件模型。
在本文中，我將探討您要如何使用 InfoPath 2007、Office SharePoint Server 2007 和 Forms Services 來建置具彈性的資料收集解決方案。而且我還會向您說明 XML 如何讓您在多層式的企業架構中區隔展示邏輯與商務邏輯。
請注意，我所謂的「資料收集」是指以人為對象收集資訊的過程。收集資料當然還有其他方法，像是為資料來源編目，但是那些自動化的方法已超出本文討論範圍。

取得和處理資料
資料取得的需求可能很複雜，但是這些程序有一些共同的特色。以集中模組處理這些相似特性，同時以分散元件來滿足獨特需求，便能避免投入多餘的心力，並減少額外的維護負荷和擁有權總成本。
比方說，上市公司所遵循的規範會產生商務需求，進而轉化成全公司的資訊管理原則。這些原則會影響跨部門界限的資料收集解決方案，而且往往會導致個別的部門進行重複工作 — 例如，人事部門 (處理員工資訊) 和客服部門 (處理客戶資訊) 收集個人識別資訊的相關規則。即使是個別部門間類似卻不相關的商務處理流程，也會製造統合資訊管理解決方案的機會。
[圖 1] 顯示典型商務處理流程的範例。若員工想要與同事交換工作分派，他必須取得同事的同意，然後依序獲得經理或工作分派排程協調員，最後獲得監督員的核准。例如，這可能包括員工交換值班。雖然這些交換動作是發生在不同的部門，而且也可能仰賴不同的形式，可是工作流程和資訊管理邏輯也許可以在不同的部門解決方案之間共用。
[圖 1] 可在部門間共用的資料收集程序範例
[圖 1] 可在部門間共用的資料收集程序範例
不用說，整合冗餘元件的工程浩大。在公司內推動組織方面的變革並不容易，但是透過 Office System 技術，您便能建置堅固的基礎來促進這些改變。InfoPath 2007 可讓個別的部門建立表單應用程式，與集中化、標準化的資訊管理系統整合。同時 SharePoint 2007 則可讓 IT 部門將網站集合、網站和文件庫的系統管理控制權，委派給個別的部門和小組。這樣一來，小組不太需要 IT 的參與，就可以建置和部署他們自己的解決方案，而由 IT 部門繼續控制所有共用的服務和元件，例如工作流程、資訊管理原則和備份程序等。

集中進行資料收集
企業經常提供小組部門應用程式伺服器，以配合個別的資訊管理需要。IT 部門的責任只限於確保硬體和作業系統能順利運作，而解決方案的其他層面則須由個別部門自行負責。部門之間缺乏足夠的協調，使得資訊的共用難以成行。
集中進行資料收集的技術挑戰，主要是出在安全性、效能、維護和支援共用環境中裝載的自訂元件上。舉例來說，如果個別的解決方案是裝載在部門的應用程式伺服器上，就可以將運作失常的元件所產生的衝擊加以隔離。然而在共用的環境中，運作失常的元件可能會大規模地影響商務處理流程。IT 部門緊接著便得針對在集中式系統上部署和維護自訂元件，建立嚴格的原則。
要在中央伺服陣列上裝載部門的 SharePoint 解決方案，您必須在中央應用程式伺服器上部署和維護這些部門解決方案的所有自訂元件。其中一套解決方案可能有賴自訂欄位類型，以後端 Web 服務所填入的下拉式清單來擴充解決方案的 UI。另一套解決方案針對相同的目的，可能是依賴網頁組件，而其他解決方案可能是使用自訂工作流程 — 這些全都寫在 Managed 程式碼中，而且部署成 Microsoft .NET Framework 組件。
即使是移動極少數的 SharePoint 解決方案到中央應用程式伺服陣列，也可能導致艱難的設定和支援問題。如果組件必須部署在全域組件快取 (GAC) 的話，更會因為這些組件是以完全信任的權限來執行而出現安全性問題。設計不良的元件可能會敞開系統的大門引發 SQL 插入式攻擊、跨站台指令碼處理，或是拒絕服務等攻擊。您必須確保各個元件不但能支撐一般的工作負載，也能應付尖峰的需要和長時間執行的作業。您必須確保各個元件不會封鎖其他處理序，同步處理事件，而且元件可執行可靠的輸入驗證 — 以免使用者將 SQL 陳述式或指令碼插入用來更新資料庫或遠端 Web 系統的資料行。
簡而言之，目的是要強調以標準產品功能為基礎的伺服器設定既安全又可擴充。憑藉著可重複使用、經過徹底測試的解決方案，您便能免於陷入必須建立無數自訂元件的困境。這解釋了為什麼要讓前端保持分散，而後端保持集中。關鍵是要以鬆散的連結方式來整合元件，以便促進現有解決方案的重複使用效益。

分割商務邏輯
那麼您要如何建置富於彈性且能夠在伺服器上設定的資料收集解決方案呢？最佳的策略是將解決方案架構劃分成各個不同的階層，如 [圖 2]：資料存放、商務邏輯和展示或 UI。現在的 UI 一般是以瀏覽器為主，而商務邏輯則是存在 Web 應用程式伺服器上。這些會轉而存取資料庫和非關聯式資料儲存機制。
[圖 2] 以三層式架構為基礎建置的典型企業解決方案
[圖 2] 以三層式架構為基礎建置的典型企業解決方案
商務邏輯通常包含交易邏輯，確保交易是以不可分割的方式套用到各個資料庫管理系統。商務邏輯也可透過 HTTP、訊息佇列、RPC 等等與多個中間層服務相整合。然而，解決方案的整體架構基本上會保持三層式模型。
[圖 2] 並沒有顯示出商務邏輯在企業環境中的複雜性。此圖中的應用程式伺服器看起來只著重於產生以瀏覽器為主的表單和處理提交的資料，但當中並沒有將工作流程、循規或資訊管理需求列入考慮。若要解決這些需求，您必須將商務邏輯一分為二：展示邏輯和資訊管理邏輯。這樣您就可以在必要時混搭中間層元件，而不需要為每個解決方案從頭重建各個元件。
[圖 3] 說明了此架構，最核心是內容或資料，外圍是資訊管理邏輯，掌管著整個生命週期的內容。展示邏輯介面與資訊管理邏輯則透過使用者介面提供對資料的存取。
[圖 3] 將展示邏輯與資訊管理邏輯加以分隔
[圖 3] 將展示邏輯與資訊管理邏輯加以分隔

收集和處理 XML
在服務導向的應用程式 (SOA) 環境中，XML 是用來定義和共用元件間的資料和資料結構的主要標準。因此 XML 非常適合作為展示和資訊管理元件之間的介面。
通訊必須雙向進行：您必須將 XML 轉譯成瀏覽器可讀取的文件，也必須轉譯表單產生的 XML 文件。直至最近，建置 XML 架構的表單應用程式都需要相當熟練的程式設計技能。尤其當產生的 XML 資料必須符合業界結構描述，以利在組織間進行資料交換時更是如此。
InfoPath 2007 使得開發 XMl 架構表單的工作更加簡單。詳悉 XML 當然有幫助，但是表單設計人員和進階使用者不必是 XML 專家，也可以建置 XML 架構的表單應用程式。表單設計人員只需要將 XML 文件或 XML 結構描述匯入 InfoPath，然後將來自該資料來源的個別屬性和元素節點對應到表單中的欄位就行了。表單設計人員也可以從 Web 服務或 SQL Server® 資料庫著手，或是使用空白的範本，然後從頭建置表單，然後讓 InfoPath 在背景自動建立基本的結構描述和資料繫結。
使用 InfoPath 和 XML 結構描述的標準化表單有幾項優點。如果您已經有一個定義完善的 XML 結構描述，表單設計人員和工作流程與資訊管理元件的開發人員就可以比照相同的資料結構來建立解決方案。如果表單設計人員從頭開始進行，開發人員就必須等待表單完成後，才能觀察它對基礎資料結構有何影響。資料結構一經定義之後，如果未來的解決方案 (例如新表單範本) 也是仰賴相同的資料結構，就可以重複使用現有的工作流程和資訊管理元件。而未來的工作流程和資訊管理元件便可與現有的表單和資料搭配運作。如果您是根據既定的業界結構描述來建置資料收集解決方案，結果甚至將更具彈性。事實上，這些解決方案將與其他使用相同結構描述的公司所建置的解決方案相容。
我建立了一個簡單的 DirectReports 結構描述，使員工與經理產生關聯。經理可以使用產生的表單來評估他們的部屬。在本文所附的下載中的 [Direct Reports] 資料夾內，您可以找到結構描述、表單和內含指示的 readme.htm 來重建此表單，下載網址是 technetmagazine.com/code08.aspx。表單很基本，但它為我們說明了一般的概念。
在這裡有一點很重要：我並沒有在 InfoPath 中建立任何驗證邏輯，但 InfoPath 仍要求以特定的格式 (網域\帳戶，和 recipient@domain.tld) 輸入使用者識別碼和電子郵件地址。若沒有這個動作，所得的 XML 文件將會無效。這是因為 XML 結構描述已定義這些格式。您可以儲存含無效資料的表單，但是您將無法提交它，如 [圖 4] 所示 (我在表單加入了一條虛擬的提交規則，供您進行測試而不用實際將資料提交到任何位置)。InfoPath 2007 驗證作業會自動確保表單已完整填寫，而且沒有這類錯誤。
[圖 4a] 驗證錯誤阻止使用者提交表單
[圖 4a] 驗證錯誤阻止使用者提交表單
[圖 4b] 產生的錯誤訊息
[圖 4b] 產生的錯誤訊息
XML 結構描述的作用是扮演展示邏輯與資訊管理邏輯的有效合約。InfoPath 會鎖定結構描述，讓表單設計人員無法故意變更資料結構。它之所以重要是因為變更既定的 XML 結構描述有可能會破壞現有的企業解決方案，例如您打算與新表單範本搭配使用的工作流程模組。
InfoPath 提供豐富的功能，讓您在表單應用程式中建置進階的展示邏輯。您可以從 XML 檔案、Web 服務、SharePoint 文件庫和清單、資料庫等等取用資料，以提取出有意義的預設值。您可以根據使用者透過規則進行的選項來變更欄位值、納入驗證邏輯、加入 Managed 程式碼以滿足最先進的自訂需求，以及使用 Forms Service 透過網路提供表單範本。無論是哪一種情況，表單的資料最終都會以符合結構描述定義的 XML 文件形式，抵達資訊管理邏輯。

使用 XML 或中繼資料
您可能不確定是否應該將資訊管理邏輯直接套用到提交的 XML 文件中，或是改用剖析器將必要的資訊擷取成中繼資料。SharePoint 兩種方法都支援。開發人員都習慣直接使用 XML 文件，但中繼資料其實提供更大的彈性。
為了示範這一點，我建立了一個簡單的 Web 服務，來剖析從 [圖 4] 所示的 Direct Reports 表單傳入的 XML 文件 (您可以在附隨下載中的 XMLParsingWebService 資料夾內找到原始程式碼、安裝檔案，以及含逐步說明的 readme.htm)。Web 服務會直接從 XML 文件讀取經理的使用者識別碼，將使用者識別碼分成網域和使用者名稱兩部分，根據這些部分建立訊息，然後發出泛型例外狀況，在 InfoPath 的表單中以虛擬錯誤訊息的形式傳回和顯示處理過的資訊。這是在資料提交後，於 InfoPath 內顯示對話方塊的簡單方法。Web 服務很好用沒錯，但要是您變更基礎資料來源 (例如，將 DirectReports.xsd 中的 OrgPerson 元素重新命名為 Manager，並以 readme.htm 檔案中所述的新結構描述來更新 InfoPath 表單)，Web 服務就會失敗。不過這種情形應該可以預料得到，因為 XML 文件現在已經不同，而存取使用者識別碼元素的舊 XPath 運算式也已無效。OrgPerson 和 Manager 結構描述幾乎如出一轍，InfoPath 表單完全一樣，而且所要的處理結果也相同，可是即使差異微乎其微，您還是需要部署和維護重複的 Web 服務。
如果您想要盡量減少應用程式伺服器上的自訂程式碼量，這並不是妥當的作法。相反地，將 XML 節點對應到中繼資料欄位，然後根據中繼資料來執行處理作業，可讓您將相同的工作流程和資訊管理邏輯運用於類似的資料結構，即使 XML 結構描述截然不同也可行。您只要確定子元素對應到正確的中繼資料欄位，而且該資料格式符合處理需求便可 — 之後您就可以重複使用現有的程式碼。
將 XML 節點對應到中繼資料欄位與將 XML 節點繫結到 InfoPath 表單中的 UI 控制項類似，如 [圖 5] 所示。在 SharePoint 中，中繼資料欄位會與在網站或清單層級定義且在內容類型定義中所參考的資料行相對應。內容類型定義著內容項目的特性，例如中繼資料欄位、工作流程和表單。SharePoint 仰賴內建的 XML 剖析器來執行屬性升級和降級作業，藉以讓內容類型的中繼資料欄位與相關聯 XML 文件中對應的節點保持同步。在屬性升級期間，XML 剖析器會將 XML 文件的節點值擷取到文件庫上相對應的資料行。屬性降級指的則是相反的程序，在此資料行值會自文件庫取得，然後寫入文件中。最重要的一點是，XML 剖析器會使中繼資料欄位與對應的 XML 節點保持同步。
[圖 5] InfoPath 和 SharePoint 之間的 XML 結構描述對應
[圖 5] InfoPath 和 SharePoint 之間的 XML 結構描述對應
當使用 SharePoint 物件模型時，網頁組件、工作流程和資訊管理邏輯除了可與中繼資料欄位搭配使用外，也可與基礎 XML 文件搭配運作。變更對應的中繼資料欄位的值，也會變更 XML 文件中的節點值，反之亦然。不過，直接使用 XML 文件可將商務邏輯與 XML 結構描述緊密結合。另一方面來說，對應的中繼資料欄位則可提高程式碼的重複使用性。很顯然地，您必須決定哪種方法最適合您的環境，但仰賴中繼資料欄位的 SharePoint 解決方案一般來說提供比較大的彈性，也比較有利於重複使用程式碼。
我在隨附的材料當中涵蓋了一項 SharePoint 功能，以提供自訂文件庫 (請參閱 OrgPersonContentType.xml 檔案，此檔案位於附隨的下載中的 OrgPersonLib 資料夾內)，來示範 SharePoint 如何建立 XML 節點與中繼資料欄位的關聯。OrgPerson 內容類型會參考四個欄位：UserID、FullName、EMail 和 Direct_x0020_Reports。FullName 和 EMail 是內建欄位，而 UserID 和 Direct_x0020_Reports 則是 OrgPersonSiteColumns.xml 中的自訂欄位。
欄位定義相當直接明瞭，您可以直接在欄位定義內將欄位繫結至 XML 節點，也可以在內容類型中覆寫這項資訊。我決定使用後者，因為這個方法除了可以讓我將自訂欄位用於與 XML 文件不相關的內容類型外，也可以用於在仰賴不同 XML 結構的內容類型。OrgPerson 內容類型將中繼資料欄位繫結至符合我稍早提到的 OrgPerson 結構描述配置的 XML 節點。另外還有一個 AdditionalContentTypes.xml 檔案，定義著其他將相同中繼資料欄位繫結到不同 XML 節點的內容類型。如果在 Node 屬性中查看一下 XPath 運算式，就可以看出當中的差別。
OrgPersonLib 型別的文件庫可以存放不同類型的 XML 文件，而節點值則是透過相同的文件庫資料行公開。這套簡單的對應方法也可讓您重複使用工作流程和資訊管理邏輯，因為四個內容類型 (OrgPerson、Manager、Supervisor 和 User) 都是參考同一組中繼資料欄位。
[圖 6] 說明 FieldRef 元素，這是來自 Direct_x0020_Reports 的 OrgPerson 內容型別，它會根據 XPath 運算式 /OrgPerson/direct-report/user-id，將欄位對應到部屬的使用者識別碼節點。由於 XML 文件可以包含多個部屬項目，因此務必要指定 Aggregation 屬性。這個屬性定義了 XML 剖析器將如何處理傳回的值集合。如果您忽略此屬性，XML 剖析器便只會擷取第一個節點值。支援的彙總值有 sum、count、average、min、max、merge、plain text、first 和 last。
[圖 6] 對應到 XPath 運算式的中繼資料欄位
[圖 6] 對應到 XPath 運算式的中繼資料欄位
所有的範例內容類型都是使用標準 upload.aspx 網頁作為 DocumentTemplate，所以您可以在按下 SharePoint UI 裡面的 [新增] 按鈕時，將 XML 檔案上載至文件庫。只要是以 .xml 檔案副檔名上載檔案，SharePoint 就會自動呼叫內建的 XML 剖析器 (唯一的例外是 WordProcessingML 檔案，針對這個檔案，SharePoint 會呼叫 WordProcessingML 剖析器)。XML 剖析器會檢查上載的 .xml 檔案，來判定相關聯的內容類型。這麼一來，它就可以從欄位定義內指定的位置擷取節點值，並執行屬性升級 (您可以在上載 OrgPersonLib\XMLFiles 資料夾中內含的 OrgPerson.xml 檔案時驗證此程序)。這個 XML 文件的結構符合 OrgPerson 內容類型定義中指定的 XPath 運算式。SharePoint 會據此從 .xml 檔案擷取資料，將該資料寫入相對應的文件庫資料行，並將該資料顯示在 EditForm.aspx 網頁中，以便您驗證和更新未標示為唯讀的文件屬性。[圖 7] 說明了內含自 OrgPerson.xml 擷取的資料的 EditForm.aspx 表單。
[圖 7] 內含擷取資料的 EditForm.aspx 表單
[圖 7] 內含擷取資料的 EditForm.aspx 表單
如果您變更 EditForm.aspx 中的 [User ID (使用者識別碼)]、[Full Name (完整名稱)] 或 [E-Mail (電子郵件)] 值，SharePoint 便會執行屬性降級來變更基礎 XML 文件內的節點值。不過，要注意的一點是，除非您自行在表單中實作必要的邏輯，否則 SharePoint 不會強制執行 XML 結構描述限制。
SharePoint 也不會執行表單應用程式的展示邏輯。比方說，當您變更 [User ID (使用者識別碼)] 時，SharePoint 並不會驗證新值是否符合 NetBIOS 慣例，也不會自動更新 [Full Name (完整名稱)] 和 [E-Mail (電子郵件)] 欄位來對應新的選項。因此，若是變更個別欄位可能會導致不一致的話，您應該將內容類型定義中相對應的資料行標示為唯讀。這可強迫使用者使用表單應用程式 (例如 InfoPath) 來更新資料。而 XML 剖析器也會將 XML 文件的任何變更升級到 SharePoint 中相對應的中繼資料欄位。
在 OrgPersonLib 範例中，您可以上載 OrgPersonLib\XMLFiles 資料夾中的任何 .xml 檔案。.xml 檔案使用的資料結構截然不同，但是 SharePoint 可以辨識出內容類型，並將正確的節點值升級到網站資料行。這是因為我使用 XML 檔案中的處理指示來建立 XML 文件與其相對應內容類型的關聯。不過，OrgPerson.xml 檔案並不包含此資訊，可是這並不成問題。如果 SharePoint 無法透過處理指示或是文件範本建立 XML 文件與內容類型的關聯，它會使用預設的內容類型。在 OrgPersonLib 的例子中，這剛好是 OrgPerson 內容類型，因此 XML 文件的剖析正確無誤。
[圖 8] 說明您如何明確建立 XML 文件與內容類型的關聯。MicrosoftWindowsSharePointServices 處理指示將 ContentTypeID 定義成 0x010100668E393E4F0EFF4294DBD202D5D8321D。這剛好是 User 內容類型的識別碼，如 AdditionalContentTypes.xml 中所定義。
[圖 8] User.xml 範例檔案的處理指示和 XML 資料
[圖 8] User.xml 範例檔案的處理指示和 XML 資料
XML 剖析器會處理 MicrosoftWindowsSharePointServices 處理指示，並將 ContentTypeID 值寫入 ContentType metadata 中繼資料欄位。所有的 SharePoint 內容類型都共用這個中繼資料欄位，因為它是在 System 內容類型中的根層級定義的。如果您在 SharePoint 伺服器上開啟 fieldswss.xml 檔案 (位於 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 資料夾中)，然後搜尋 MicrosoftWindowsSharePointServices，就可以看到 SharePoint 如何建立處理指示與 ContentType 欄位的關聯。PITarget 屬性指向 MicrosoftWindowsSharePointServices (這是處理指示)，而 PIAttribute 指向 ContentTypeID (當中包含 User 內容類型的識別碼)。

InfoPath 中的內容類型關聯
許多表單設計人員對 XML 剖析和內容類型關聯的專有名詞都敬而遠之，但是 InfoPath 2007 會處理好所有這些枝微末節。隨附在 OrgPersonLib 範例中的 readme.htm 檔案包含了相關指示，可讓您在 SharePoint 中發佈 Direct Reports 表單範本，以及建立繫結至相同中繼資料欄位 (UserID、FullName、EMail 和 Direct_x0020_Reports) 的內容類型。您可以在 SharePoint UI 中輕鬆地加入新的內容類型到 OrgPersonLib 文件庫中。但是新的內容類型也會指向 InfoPath 表單範本，作為在更新現有 XML 文件時呼叫表單應用程式的文件範本。[圖 9] 舉例說明「InfoPath 發佈精靈」如何簡化 XML 節點值與 SharePoint 網站資料行之間的屬性對應工作。再次強調，如果您將節點值與現有的網站資料行建立關聯，就可以重複使用現有的 SharePoint 元件。
[圖 9] InfoPath 2007 中的屬性對應
[圖 9] InfoPath 2007 中的屬性對應

結論
其他線上資源
  • InfoPath 2007 小組部落格
  • W3C XML 結構描述規格和開發
  • XML 結構描述簡介 (XML 設計工具)
  • Office SharePoint Server 2007 的工作流程
  • InfoPath 2007 Forms Services

透過 Office 所提供的技術，企業架構設計師得以建置資料收集解決方案，輕易地促進程式碼重複使用和資訊交換。InfoPath 2007 容許部門建立各種解決方案，從不同來源提取資料的，然後將該資料提交至不同的系統，例如 SharePoint。SharePoint 也提供開發人員一組完整的 Web 服務和介面，來建置工作流程和資訊管理元件。憑藉著將這些元件裝載在集中式 SharePoint 伺服器上，各個部門便有所需的基礎結構來建置各自的應用程式。
同時，各個部門還可以更迅速地建立他們的資料收集解決方案。循規和其他一般商務需求可以在跨部門的層級加以解決，並且隨著應用程式伺服器上使用的自訂元件變少，IT 環境的易管理性和可靠性因而可獲得提升。

Keith Deshaies 是一名自由技術作家，也是大型電信公司的 IT 分析師。他專長於 Microsoft Office 和 SharePoint 技術，而且是技術通訊社團 (Society for Technical Communications) 的一員。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 Sharepoint: 建置強大的問卷基礎結構
Sharepoint Jim Bradley

建置強大的問卷基礎結構
摘要:
  • 規劃和實作問卷解決方案
  • 在 SharePoint 文件庫收集和處理問卷結果
  • 管理效能和安全性問題

沒有資訊就做不出明智的決策。光靠直覺是不夠的，當您的決定會影響整個公司業務時更不能只靠直覺。無論您是要決定在哪裡舉辦小組派對，
或是打算重新配置 50% 的公司資源以推出新產品，都需要有資訊。但是您要如何取得這些資訊？
問卷是集思廣益的一種有效而划算的方法，從客戶對產品的滿意度，乃至員工對上次小組會議供應的三明治是否喜歡，無所不包。問卷能夠產生未來產品、系統或流程改良和開發所需的要素。那麼身為 IT 專業人員的您，要如何應用問卷系統來收集、儲存資料，使資訊的運用更有意義呢？
或許您已經再有收集、建構和分析這類資料的工具。不過，2007 Microsoft® Office System 不但提供這些工具，而且使用起來相當簡單。進行問卷調查的方法多得很，重點在於根據特定需求找出適當的方法。舉例來說，如果受訪者不多且內容並非關鍵，那麼電子郵件型態的問卷就非常適合進行即席、即時的資料收集。如需詳細資訊，請參閱下方的「使用電子郵件進行快速問卷調查」資訊看板。要是受訪者人數較多且攸關關鍵資料，這種比較複雜的方案比較適合用資料庫為導向的問卷。如需本主題的詳細資訊，請參閱下方的「建置以資料庫導向的問卷解決方案」資訊看板。
在本文中，我將把重點放在另外一套比較全面化且富彈性的解決方案：以 SharePoint® 為基礎的線上問卷。這種方法同時適用於各種複雜程度的關鍵及非關鍵問卷。因為 SharePoint 問卷是以網路為基礎，所以只要可以存取網頁瀏覽器的人，都可以接受問卷調查 — 它甚至還支援行動裝置。在 SharePoint 問卷中，回答可以具名亦可匿名，另外也提供即時結果，還可以存取分析工具。
這種問卷是使用 Windows® SharePoint Services 3.0 (WSS) 含 Forms Server 和 InfoPath®，或是 Microsoft Office SharePoint Server 2007 (MOSS) 含 Forms Services 和 InfoPath® 實作而成 ([圖 1] 中有各項技術的描述)。這兩種案例基本上都提供相同的功能，所以我會把討論重點放在後者的組合上。有關 SharePoint 產品及其功能的完整比較，請參閱 Microsoft Office SharePoint Server 2007 產品比較下載，網址是 office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx。
Figure 1 實現 SharePoint 問卷的 Microsoft 技術 (Close Figure 1)

技術 | 描述
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007 是建立表單和收集資訊的工具。如需詳細資訊，請參閱 office.microsoft.com/infopath。
Windows SharePoint Services 3.0 | 前身為 SharePoint Team Services 的 Windows SharePoint Services 3.0 是建立擴充 SharePoint 應用程式的基礎。如需詳細資訊，請參閱 microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx。
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007 (前身為 SharePoint Portal Server 2003) 提供一套伺服器端的基礎結構，可將 Office 2007 用戶端轉換成 SharePoint 應用程式的內容產生器和取用者。如需詳細資訊，請參閱 microsoft.com/sharepoint。
InfoPath Forms Services，Microsoft Office Forms Server 2007 | InfoPath Forms Services 讓使用者不需要安裝 InfoPath，即可在網頁瀏覽器中完成 InfoPath 表單，使得問卷與各種平台、各種瀏覽器相容。Forms Services 需要用到 Windows SharePoint Services 3.0，不過您也可以使用名為 Microsoft Office Forms Server 2007 的獨立產品取得相同功能。如需 Forms Services 的詳細資訊，請參閱 microsoft.com/ms540731。如需 Forms Server 的詳細資訊，請參閱 office.microsoft.com/en-us/formsserver/FX100490391033.aspx。

規劃和實作
設計問卷時必須事先考慮幾項要素，行前分析是一定要的，請確實投入時間詳擬問卷計畫。在最初的規劃階段中，您應該界定問題的範圍、期望取得的資料類型、判斷需要採用的技術、確立預算和管理方面的需求。接下來可以進展到實作階段，大致的工作流程是設計問卷表單、發佈問卷表單、收集和查驗答案、彙整和分析資料，然後報告結果。
問卷實作的工作流程一般包括至少一名問卷設計人員、受訪者和一名分析師 (如 [圖 2] 所示)。想當然爾，問卷工作流程可以簡單也可以複雜。比方說，公司上下的全面問卷調查很可能需要好幾回合的設計編排和核准。可能會有自動通知來提醒受訪者、提供各種支援和疑難排解表、管理員可檢視即時結果，並且有清楚的流程來判斷傳達最終分析結果。如此錯綜複雜的工作流程，確實需要以網路為主的系統來支援工作流程和報告功能。
[圖 2] 從表單設計到資料分析的問卷工作流程
[圖 2] 從表單設計到資料分析的問卷工作流程

對全方位解決方案的期望
對全方位的問卷解決方案，您應該期望它符合一長串的重要需求。對於這類解決方案，個別小組或業務單位應該不需要 IT 部門的協助，就算缺乏程式設計技巧，也能建立、散發和收集問卷結果。表單建立工具應該提供容易使用的所見即所得 (WYSIWYG) 介面，以及一組豐富的功能使管線、分支和條件邏輯更具效率。而且想當然爾，問卷表單建立工具也應該配合各種規模大小和複雜度的問卷。
此外，問卷應該在網頁伺服器上執行，而且應該與集中維護的 SQL Server® 資料庫相整合，這樣各個部門就不用維護專用的 SQL 資料庫。任何可以存取網際網路的受訪者應該能夠從任何標準相容的瀏覽器完成問卷。
問卷流程應該輕易地連結工作流程，而且應該在不危及安全性的情況下滿足商務需要。另外，對許多組織來說，問卷解決方案應該提供多語言支援。
MOSS 2007、WSS 3.0 和 InfoPath 2007 互相搭配使用時，可創造出一套能解決所有這些需求的整合解決方案。[圖 3] 說明 SharePoint 堆疊內的各個元件如何彼此搭配運作。在探討這套完整的問卷解決方案之前，我想要稍微討論一下單獨使用 WSS 可以達成什麼成果。接下來我會說明搭配使用 MOSS 和 InfoPath 後可以獲得什麼附加的好處。
[圖 3] SharePoint 堆疊的元件
[圖 3] SharePoint 堆疊的元件

單獨使用 WSS
即使沒有其他元件，您還是可以使用 WSS 來建立和實作問卷。事實上，WSS 包含一個內建的問卷範本，讓整個程序更加簡單。若要建立問卷，按一下 [開始] | [所有程式] | [系統管理工具]，然後選取 [SharePoint 3.0 管理中心]。從下拉式清單選取 [網站動作]，然後按一下 [建立]。接著會顯示 [建立] 頁面，顯示 [文件庫]、[通訊]、[追蹤]、[自訂清單] 和 [網頁] 的標題。每個標題下都有個範本選項。在 [追蹤] 下，按一下 [問卷]。
此時，WSS 會引導您逐步完成問卷建立程序。您可以建立開放式或封閉式的問題，並指定問題是否可以不作答。您甚至可以建立分支邏輯問卷，這類問卷會根據答案引導受訪者往下繼續不同的行徑。問卷可以是匿名的，或者必要時，也可以確認受訪者的身分。您還可以選擇是否在問卷中指定工作流程。
問卷是以瀏覽器為主，所以建立或回答問卷並不需要特殊的軟體。若要完成問卷，受訪者只要前往 SharePoint 網站，然後完成表單就行了。存取權限是繼承自上層網站，但可以直接從 SharePoint [動作] 功能表編輯。問卷的答案會儲存到 SharePoint 問卷網站，您可以透過清單的形式或圖形摘要，或是匯出到 Excel® 來檢視結果。
若要反覆進行，不需要額外的軟體，就可以透過 WSS 來達成此解決方案 (經由 [圖 4] 所示的流程)。假設您已經建置好一個設計完善的 SharePoint 網站，各部門應該不太需要 IT 的協助便可建立和實作問卷。
[圖 4] 以 Windows SharePoint Services 為基礎的問卷
[圖 4] 以 Windows SharePoint Services 為基礎的問卷
當問卷需要自訂時，只採用 WSS 的程序會浮現一項明顯的限制。WSS 使用各種不同的預設 ASPX 網頁 (AllItems.aspx、DispForm.aspx、EditForm.aspx、NewForm.aspx、overview.aspx 和 summary.aspx) 來建立問卷清單。雖然不用 WSS 中繼承的參數就可以自訂網頁，但是大多數功能都是源自不容易自訂的網頁組件。另外，只採用 WSS 的解決方案最適合不需要整合外部資料來源的問卷，例如貴公司的 ERP 系統。
如果您的確需要擴充問卷解決方案以包含自訂 UI 或與額外資料來源整合，就應該認真考慮結合 MOSS、WSS 和 InfoPath 的解決方案。

完整的問卷解決方案
MOSS 包含許多功能可以擴充 WSS，但是就目前來說，我只想把重點放在單一元件上 — 那就是 InfoPath Forms Services。透過 InfoPath Forms Services，只有問卷設計人員需要在她的電腦上安裝 InfoPath。其他人可以透過網頁瀏覽器來存取問卷。
在 InfoPath 中，設計人員可選取使用瀏覽器填寫表單的選項。InfoPath 隨後會建立一個可在任何標準相容的網頁瀏覽器上檢視的表單。除了一些進階的 InfoPath 功能 (例如使用者角色、垂直文字、對話方塊動作和進階控制項等) 之外，這個網頁表單執行的方式與 InfoPath 表單並沒什麼兩樣。表單接著會發佈到 SharePoint 文件庫或清單。在此同時，另一個稱為設計檢查的 InfoPath 功能會確保問卷表單與 InfoPath Forms Services 確實相容。
InfoPath 表單檔案庫與瀏覽器啟用的表單檔案庫之間並無差別。這兩個例子中的表單範本都是 .xsn 檔案。InfoPath Forms Services 若非將表單顯示在瀏覽器中，否則就會下載檔案到用戶端然後直接在 InfoPath 中顯示。若問卷設計人員在 SharePoint 網站上至少具備「參與者」權限，他就可以使用 SharePoint 文件庫來發佈表單範本。
擁有標準相容的瀏覽器的受訪者可以完成 InfoPath Forms Services 問卷，而他的答案接著會順暢地傳回 SharePoint 伺服器。在 SharePoint 內，您可以安全地存放、剖析、共用和分析資料 (使用 Excel、SQL，或其他網路上可用的工具)。所有這些動作都不太需要 IT 管理協助就能達成。

回傳和效能問題
不過，這有潛在的效能問題。例如，啟用瀏覽器的表單在 SharePoint 伺服器上是以系統帳戶的內容執行，也就是說如果表單包含程式碼或資料連線 (如 [圖 5] 所示)，那麼該程式碼或資料連線會是在伺服器上，而不是在用戶端上執行。而複雜的表單可能需要經常回傳資料給伺服器，無疑是增加伺服器上的工作負載。
[圖 5] 以 InfoPath Forms Services 為基礎的問卷解決方案與額外的資料連線
[圖 5] 以 InfoPath Forms Services 為基礎的問卷解決方案與額外的資料連線
問卷使用回傳的頻率越高，前端網頁伺服器的負載就越大。不過，回傳有時候是不可避免的，像是在實作回應分支的時候。為了盡可能避免對系統產生潛在的反效果，問卷設計人員必須清楚回傳的問題，並了解若回傳終究是免不了時，該如何有效地實作問卷。譬如說，設計人員應該在使用者按下 [下一步] 按鈕時，使用類似精靈的問卷回傳資料到伺服器，藉此減少回傳次數。
InfoPath Forms Services 必須維護伺服器上每個目前正在使用中的表單狀態。預設的工作階段逾時是 60 分鐘，也就是說，如果填寫複雜問卷的時間超過 60 分鐘，而在這段期間內沒有任何回傳，那麼伺服器上就會關閉該工作階段。已經輸入但未提交的資料將會遺失，受訪者必須重填問卷。
當大量受訪者同時填寫問卷表單，以及在問卷有大量資料來源或包括檔案附件時，這種問題更是明顯。如需詳細資訊，請參閱《提升 InfoPath 2007 表單的效能》，網址是 msdn2.microsoft.com/bb380251。

安全性考量
深入探討安全性雖不在本文討論範圍內，但有些安全性考量值得特別注意。首先，SharePoint 和 InfoPath 2007 遵守 Microsoft 在 2002 年初所採行的「高可信度電腦運算計畫」。InfoPath 表單採三種可能的安全性層級：限制、網域和完全信任。而且在預設的情況下，InfoPath 會自動判定和套用建議的安全性層級到表單。
數位簽章功能有助於確保表單是由特定的使用者所建立或填寫，而且未經修改。而資訊版權管理 (IRM) 可以限制對範本和已完成表單的存取。為了防止惡意使用者上載包含有害程式碼的表單，或使用 SharePoint 平台透過資料連線對其他系統發出攻擊，InfoPath 會區別使用者部署和系統管理員部署的表單。只要表單不含任何自訂程式碼，而且只設為 [網域] 安全性層級 (這可限制跨網域資料連線)，使用者就可以上載表單。對大多數問卷解決方案來說，這些參數已綽綽有餘。
當問卷設計需要 [完全信任] 安全性層級時，為了能夠不受限制地存取資源，就必須有 IT 管理核准才能發佈表單。根據預設，需要 IT 管理核准的情況有：當表單包含 Managed 程式碼、表單範本中有定義跨網域資料連線、表單使用集中管理的資料連線庫中定義的資料連線，以及啟用支援在行動裝置上的轉譯選項等時候。
在 [完全信任] 安全性層級，問卷設計人員可建立 InfoPath 表單，並儲存表單範本。範本或 .xsn 檔案會以電子郵件附件的方式傳送到 SharePoint 系統管理員，或透過網路共用傳遞。IT 系統管理員接著會先檢查問卷功能及當中所含的任何程式碼，然後再於實際執行系統上提供問卷。IT 系統管理員會將問卷範本上載到網站集合，然後啟動問卷範本來完成部署作業。這兩個程序都是在 [WSS 管理中心] 主控台的 [應用程式管理] 網頁上完成。如此一來，IT 系統管理員可以將表單發佈委派給個別的部門，同時在表單超出基本的資料收集活動範圍時，仍然能夠繼續監督發佈程序。
在某些常見的案例中，IT 系統管理員監督是必要的：當表單必須填入預設資料，以及當問卷結果提交到多個資料來源時。在預設的情況下，網域信任表單範本並不能建立跨網域資料連線，但是您可以採取幾個動作來解決這項限制，包括：
  • 授與表單 [完全信任] 權限。
  • 從資料連線庫使用資料連線來建立網域信任。
  • 透過集中管理的連線庫使用網域信任。
完全信任和集中管理連線庫兩種選項在表單發佈期間都需要有系統管理員的核准。然而，資料連線庫 (DCL) 可讓使用者發佈的表單使用網站集合層級維護的 DCL 跨越網域界線。這個 DCL 可由個別的部門加以掌控。不過有一點要注意的是，容許各個部門自行定義以伺服器為主的資料連線，可能會有安全性方面的疑慮。
最安全的選項是在集中管理的連線庫中定義資料連線，然後讓 IT 系統管理員部署進階的問卷表單來使用這些資料連線。集中管理的連線庫之所以有利是因為它可用於所有的網站集合以及整個伺服器陣列。這容許系統管理員定義中央驗證設定，以便存取本機 SharePoint 伺服器以外的資料來源。如需詳細資訊，請參閱線上文件《關於資料連線、驗證和替代存取對應》，網址是 msdn2.microsoft.com/ms771995.

結論
問卷提供一種有效的方式收集各種業務、各種等級的關鍵 (以及不太關鍵的) 資訊。然而，建立有效率的問卷需要有適當的工具、完善的計畫，以及在藝術與科學雙方面取得均衡。事先進行周密的規劃將有助您建造一套可讓組織內各個部門建立、傳送、接收、儲存和分析問卷資料的解決方案。
最有效的問卷是那些能產生及時且相關資訊的問卷。為了在需要時收集資訊，您的解決方案必須在不危及安全性的情況下，簡化在部門層級建立和管理問卷的程序。InfoPath 提供的直覺化介面無須特殊訓練就可以使用，讓資訊工作者能夠建立高品質的問卷。而且透過 InfoPath，您不必執行繁複的 IT 管理工作，便可收集高品質的問卷資料。
InfoPath 2007 與 WSS 和 MOSS 緊密地搭配運作，創造出豐富、複雜的問卷解決方案，與各式各樣的平台和瀏覽器都相容。您的企業將可藉此駕馭最重要的資產之一：資訊。
使用電子郵件進行快速問卷調查
即席的問卷是向一小群受訪者迅速收集資料的基本工具。以電子郵件為主的問卷最適合這類的即時研究調查，既可迅速建立，亦無須專用的伺服器或 IT 協助。其中一個最簡單的方法是，內嵌在 Microsoft® Outlook® 郵件的投票按鈕，它可讓您傳送、接收和列表顯示單面向問卷。
開始投票按鈕問卷之後，您的收件者會收到一封內含投票區的電子郵件，當中會顯示下拉式選項清單。收件者可以按下其中一個選項來回應。快顯視窗接著會顯示一則訊息：「您選擇回應：<您的選擇>」，並提供選項來 [傳送] 或 [編輯] 回應。
問卷設計人員，或是指定的代理人，會透過電子郵件收到個別的回應，並手動將結果製作成列表。如果問卷包含大量收件者，您應該在 Outlook 中建立規則 (使用「規則精靈」)，自動將回應路由到專用資料夾，如 [圖 A] 所示。
[圖 A] 問卷回應自動路由到專用資料夾
[圖 A] 問卷回應自動路由到專用資料夾
不過，投票按鈕功能蠻有限的。插入電子郵件訊息中的問卷表單所能收集的資料更多，但是手動擷取資料及製作列表其實並不容易管理。以電子郵件為主的問卷比較複雜的一點，就是使用 VBScript 來自訂 Outlook 問卷。自訂表單其實比較方便收集和分析大量複雜的資料。若要存取 Outlook 2007 中的開發人員功能，您必須先顯示 [開發人員] 索引標籤，如 [圖 B] 所示。
[圖 B] Outlook 2007 中的 [開發人員] 索引標籤
[圖 B] Outlook 2007 中的 [開發人員] 索引標籤
一般 Outlook 使用者可能不具備建立自訂 Outlook 表單的知識。但是 InfoPath® 2007 提供的新功能可以讓實作自訂表單更容易。問卷設計人員不需要特殊的專才，就可以透過三種方式建立 InfoPath 表單和範本：
  • 透過匯入現有的 Microsoft Word 文件或 Excel® 試算表。
  • 透過下載預先設計的 InfoPath 範本，然後修改它們來滿足特定需要。
  • 使用 InfoPath 的表單設計功能從頭開始設計範本。
這三種情況下的範本都可以發佈到 Outlook，並透過電子郵件散發。使用 InfoPath 2007 和 Outlook 2007，IT 只需要稍微從旁協助 (有時甚至完全不需要)，不出幾個小時資訊工作者就可以建立出包含二十個問題的問卷，以電子郵件寄給群組，在 Outlook 中接收結果，然後以 Excel 試算表分析資料。
此案例中有個唯一的實際需求：所有參與者都必須在電腦上安裝 InfoPath 和 Outlook。而且 InfoPath 2007 實際上會擴充 Outlook 2007 的功能，所以收件者可以直接從 Outlook 介面回應問卷。
但是 InfoPath 不光是支援以電子郵件為主的問卷而已。您還可以建立範本，查詢和提交資料到 Web 服務和 SQL Server® 資料庫，或者您可以使用現有的 XML 文件或 XML 結構描述當做資料來源。換句話說，只需要一點點訓練和程式碼 (或是完全不用加入程式碼)，使用者便能感受到 XML 的強大功能和彈性。
使用電子郵件作為問卷解決方案還有一些明顯的缺點。比方說，這些問卷並不是匿名的，因為受訪者必須提供電子郵件地址。這可能會妨礙受訪者誠實作答而扭曲結果。另外也有安全性方面的考量，例如網路釣魚攻擊，因此使用以電子郵件為主的問卷所收集到的資料類型和深度其實有限。

建置資料庫導向的問卷解決方案
以電子郵件為主的問卷並不適合比較複雜且牽涉大量受訪者的研究調查 — 要管理和分析所有資料，光靠 Outlook® 中的單一資料夾是不夠的。更穩固的解決方案是將問卷的回應導向資料庫。資料庫所提供的進階存放、索引、處理和報告功能都相當有幫助。例如，Microsoft® SQL Server® 2005 包含了 SQL Server Reporting Services，可用來自動處理問卷結果。
若要建立可以提交回應到資料庫的 InfoPath 表單範本，您必須先在網路內建立 Access® 或 SQL Server 資料庫。接著，在 InfoPath® 中，您可以使用「設計表單範本」精靈開始建立範本的程序。這個動作會開啟「資料連線精靈」，並逐步帶您完成將表單連結到資料庫的程序。InfoPath 會使用資料庫中的資訊來建置資料來源查詢和資料欄位。
大部分的工作人員都具備足夠的知識，只需要一點點訓練或輔助，就可完成和提交問卷。然而，在這個案例中 (資料會直接傳遞到資料庫中)，受訪者必須安裝 InfoPath 和 Outlook，而且他們必須位在公司防火牆背後，或是具備公司網路的 VPN 存取權。
InfoPath 的「資料連線精靈」只會與 Microsoft SQL Server 2000 或更新版本和本身使用 ADOXML 的 Access 資料庫進行互動。它不支援直接提交到其他資料庫。其他的限制包括，InfoPath 不容許將 RTF 控制項繫結到資料庫欄位，而且也不支援大型二進位資料型別。
隨著網路拓撲的規模漸大也漸形複雜，將資料提交到中繼 Web 服務，再將資料傳遞到資料庫的作法也越來越有利。藉由 Web 服務將問卷表單前端與資料庫後端分開，也能提高在網頁伺服器上實作商務邏輯的效率。再加上由於 Web 服務是經由 HTTP 或 HTTPS 連線執行，參與者便能透過防火牆提交資料，如 [圖 C] 所示。不過要注意的是，受訪者還是必須安裝 InfoPath 2003 或 2007。
這種案例的缺點是，實作時需要有 IT 的參與。細述此程序將超出本文討論範圍，不過我可以警告您從頭建置資料庫解決方案可說是相當費力的工作，其中包括事先規劃、良好的問卷設計、程式設計 Web 服務，以及設計資料庫後端。雖然 InfoPath 2007 已經簡化了這項作業的表單設計部分，但是端對端解決方案仍然需要熟練的程式設計和資料庫設計技能。而加入進階功能，例如工作流程或多語言支援，更會使得實作的成本遽增。
[圖 C] 透過 Web 服務的 InfoPath 資料流
[圖 C] 透過 Web 服務的 InfoPath 資料流

Jim Bradley 是 CoyoteTech LLC 的老闆，這家技術通訊公司專門針對 Microsoft 伺服器產品提供使用者輔助資源文件。參與的說明文件專案包括《Microsoft Exchange Server 2007 邊際傳輸和訊息保護》、《透過 Microsoft Exchange Server 2007 進入 64 位元的世界》，以及《Microsoft Exchange 2003 技術參考指南》。


 Sharepoint: 透過自訂內容類型將資料管理標準化
Sharepoint Pav Cherny

透過自訂內容類型將資料管理標準化
摘要:
  • 透過 SharePoint 管理內容生命週期
  • 建立文件資訊面板
  • 透過 InfoPath 編輯 Office 和 SharePoint 文件
下載本文程式碼: ContentTypes2008_02.exe (779KB)

企業環境中往往累積了龐大的文件等內容項目，要以集中、可重複使用的方式管理文件、中繼資料及其行為，無非是
商務和技術上的一大挑戰。Microsoft® Office SharePoint® Server 2007 針對這點推出全公司通用的合作方式，方便企業內部職能各異的小組透過網站、文件庫和清單共用工作區，從而提升企業整體的合作效率。
透過內容類型，SharePoint 2007 可將內容和生命週期的各種特性標準化。網站內容類型是獨立於任何具體網站集合、網站、清單或文件庫而建立的中繼資料定義。有了它，您可以採用一貫作法建立應用全公司的屬性、工作流程、資訊管理原則及其他元素，同時又容許個別部門或網站擁有者根據具體用途自訂內容類型。
本文就要告訴您，如何使用 Windows® SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 所附隨的全新 SharePoint 內容模型，根據一般特性建立企業內容的各個階層。這些內容階層一方面容許全域統一應用中繼資料、工作流程和資訊管理原則，另一方面又能夠彈性配合網站集合、網站、文件庫和清單方面獨特的內容管理需求。
為了示範部分低階的 SharePoint 內容類型，我在隨附的資料當中加入一些自訂工具，還另附原始程式碼，方便讀者根據個人需求進行擴充。不過請記住，這些工具尚未經過徹底測試，不應用於實際執行系統。您可以從 TechNet Magazine 網站下載程式碼，網址為 technetmagazine.com/code08.aspx。

內容生命週期和內容類型定義
SharePoint 資源
  • InfoPath 小組部落格
  • Office SharePoint Server 2007 的工作流程
  • TechNet 網路廣播：在 SharePoint Server 2007 安裝和設定搜尋
  • InfoPath Forms Services

管理公司文件等內容時要考量很多細節，像是建立、發佈、封存和處置內容時，必須定義由誰或哪個程序負責執行什麼動作。公司通常必須進行的工作有：建立出內容製作專用範本、界定角色以分派工作和使用者存取權、提供版本控制、監視相容性、儲存與封存，以及定義中繼資料等等。
內容生命週期的確是相當複雜，不過 SharePoint 內容模型已經從個別內容項目的處理方式找出一般特性和標準階段。比方說，可以透過範本和輸入表單來制定建立內容的結構，以及透過中繼資料來制定顯示和搜尋內容的結構。您也可以藉由編輯、核准或其他工作流程需求、封存需求、到期時間範圍以及適用的資訊管理原則，劃分出有哪些個別內容。有些內容也許不需要特別的範本，也許永遠都不必封存，但即使如此，這些都是區分項目與項目的生命週期特性。
SharePoint 內容模型可讓您定義個別的內容類型，並且建立階層關係。在階層關係中，子系繼承了父系內容類型的一般特性，也可以根據自身需求添加具體特性。
這點可以從 SharePoint 的內建內容類型看出。WSS 3.0 和 MOSS 2007 含有針對文件和工作等一般項目預先定義的內容類型，可以儲存在文件庫或清單中。這些標準內容類型的定義位在 SharePoint 伺服器的 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 資料夾當中，其中有個名為 feature.xml 的資訊清單檔。從這個檔案可以看出，SharePoint 實作的標準內容類型定義是附有網站集合範圍 (Scope="Site") 的隱藏功能 (Hidden="TRUE")，而含有實際內容類型元素的 Element 資訊清單檔則是 ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />)。
如果您有興趣深入瞭解 SharePoint 功能，建議您閱讀《MSDN® Magazine》的《Office Space》專欄中，由 Ted Pattison 所寫的＜適用於 SharePoint 的功能＞一文 (msdnmagazine.com/issues/07/05/OfficeSpace)。
無論 SharePoint 使用者介面中是否看得見標準內容類型，我們都可以用記事本開啟 ctypeswss.xml 檔案察看標準內容類型，不過別修改這個檔案。有些 SharePoint 使用者希望修改 ctypeswss.xml，在標準內容類型另添欄位或將顯示原為隱藏的內容類型，好衍生出新的內容類型。這種做法不但沒有必要，還會產生不支援的設定，稍後安裝的 Service Pack 也會覆寫您的自訂，結果將內容管理解決方案搞得一團亂。
理想的做法是將需要的內容類型複製到新的元素資訊清單檔案中，根據需要另添自訂的內容類型，最後再將自訂的內容類型部署為含有網站集合範圍的新功能，方便網站集合中所有的網站加以使用。
下面就是 ctypeswss.xml 所指定之 System 內容類型的共同應用程式標記語言 (CAML) 定義：
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Group 和 Sealed 屬性表示 System 內容類型已經隱藏密封，不得在 SharePoint 使用者介面中變更。System 內容類型只有一個 FieldRef 元素會參考一個稱為 ContentType 的內建網站欄，這是最高的抽象層，其他的 SharePoint 內容類型一概從 System 內容類型繼承這個屬性。因此，SharePoint 便可確保所有儲存在任何文件庫或清單的內容項目，全部具有這個共同屬性。
[圖 1] 顯示的是本文隨附贈資料內含的 ContentTypeHierarchy 網頁組件，圖解說明的階層更加直接易懂。System 是所有內容類型的根目錄，接下來是 Item，然後依此類推。舉例來說，Item 內容類型會建立下一層的詳細資料。您只要查看 ctypeswss.xml，就會發現 Item 負責定義一個參考 Title 網站欄的中繼資料欄位。因此，所有比它低階的內建內容類型都會具備 Title 屬性。
[圖 1] WSS 3.0 內建內容類型階層
[圖 1] WSS 3.0 內建內容類型階層
您也可以比照 ctypeswss.xml 中的 Document 內容類型定義，移除一個繼承的欄位。Document 內容類型包含好幾個相對應的 RemoveFieldRef 元素，不過最好把 Title 欄位保留在自訂內容類型中，因為 Title 欄可讓您存取 SharePoint 的 [文件庫] 和 [清單] 檢視中的 [編輯控制項方塊] (ECB) 下拉式功能表。
如果您想知道如何重新命名繼承的欄位，不妨參考 ctypeswss.xml 中的 Far East Contact 內容類型一例。請搜尋對應的內容類型識別碼 0x0116，然後檢查屬性為 Name="Title" 的 FieldRef 元素，看看如何使用 DisplayName 屬性，在使用者介面中重新命名欄位。在這個範例中，DisplayName 屬性把使用者介面的 Title 欄位名稱，改成一個 "$Resources:core,Last_Name;" 所參考的當地語系化資料值。
如果您再細看 [圖 1]，就知道 ContentType 元素的 ID 屬性是唯一識別該內容類型、並且負責建立階層關係的屬性。所有的識別碼，都以另外附加其他十六進位值的父系內容類型的識別碼開頭。標準內容類型通常都會額外附加兩個十六進位值，目的是為子系內容類型建立新的專屬識別碼。另一種方法是附加 "00" 和十六進位 GUID。比方說，「Office 資料連線檔案」和「通用資料連線檔案」內容類型，就是以這種方式從 Document 內容類型衍生出來。
使用者還必須記住一點，ContentType 元素的 ID 屬性不能多於 1,024 個字元。如果大型階層關係中所有的內容類型都使用十六進位 GUID 定址技術的話，可能會產生問題。但是以較短的定址技術開頭也不見得理想，因為這些識別碼未必是專屬識別碼。
為了確保它的專屬性，您可以使用 GUID 技術，為企業內容類型建立一個全域命名空間，然後再切換到該命名空間中較短的定址技術。如需有關 ID 屬性及內容類型定義之其他元素的詳細資訊，請參閱 WSS 3.0 SDK 中的＜內容類型定義架構＞一文。

內容類型依存關係
現在讓我們看看如何使用 SharePoint 內容類型來制定內容項目管理的結構。您必須考量幾個依存關係，例如文件庫和清單、內容類型、網站欄及欄位類型之間的相互依存性。文件庫和清單會參考內容類型，內容類型會參考網站欄，網站欄會轉而參考欄位類型 (例如，標準 WSS 欄位類型文字、附註、選項、號碼和貨幣等等)，而欄位類型位於 Microsoft .NET Framework 組件中，例如 WSS 核心組件 Microsoft.SharePoint.dll。
為了舉例說明，讓我們回到之前在 System 內容類型資訊清單檔案項目的 CAML 定義中所說明的 System 內容類型。如您所見，這個內容類型包含一個 FieldRef 元素會參考 ContentType 網站欄。請注意，內容類型定義並不會定義實際的 ContentType 網站欄。ContentType 是一個文字欄位，定義在 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 資料夾的 Elements 資訊清單 fieldswss.xml 中。您可以在 SharePoint 伺服器的 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 資料夾中，找到這些標準內容類型的定義。在使用這個依存樹狀目錄時，您必須確保 SharePoint 伺服器上所有的資源都能夠使用。
您要使用的內容類型，必須在文件庫和清單的網站層級、或網站階層中的更高層級建立。同樣地，內容類型的中繼資料欄位也必須參考現有的網站欄。您可以根據標準或自訂欄位類型，在內容類型新增標準或自訂網站欄，但是您必須確保這些網站欄都在本機網站上。此外，如果要使用自訂欄位類型，也必須將基礎 .NET 組件部署到 SharePoint 伺服器上。
參考文件範本、自訂事件接收器、工作流程和其他元件的內容類型也有類似的依存性。比如，內容類型定義可以包含一個 DocumentTemplate 元素，指向與該內容類型相關聯的文件範本。內容類型定義也可以包含一個含有一或多個 XmlDocument 子元素的 XmlDocuments 元素，負責定義內容類型的其他特性，例如命名空間定義、文件資訊面板定義或任何自訂資訊。

建立全域內容類型
具有製作權限的使用者，可以直接在 SharePoint 使用者介面，建立新的內容類型和網站欄，但是內容類型只能用在網站階層中的本機網站以及本機網站以下。自訂網站欄只能用在本機網站。如果您要建立全域內容類型，這還不夠，您必須確保全域內容類型都能用在環境中所有的網站集合才行。這時候 SharePoint 功能就派上用場了。要在多個網站集合安裝和啟動 SharePoint 功能，以便在所有的地方一致套用相對應的網站欄和內容類型定義，是很簡單的程序。
本文隨附的資料包含一個名為 AdventureWorks 的範例功能，它可以示範建立全域內容類型的方法。這項功能會定義一個名為「客戶說明文件」的一般內容類型，該內容類型可用來建立任何類型的客戶資料，例如提案和業務信件。您大可假設上述類型的文件都應該與公司名稱、連絡人詳細資料和地址等客戶資訊相關聯。我特別針對您的內容類型建立了叫做 [客戶名稱 (Customer Name)] 的自訂欄位，並且加入 [部門 (Department)] 和 [主要電話號碼 (Primary Phone)] 等內建欄位。您可以在隨附的範例中編輯 ContentTypes.xml 檔案來變更內容類型，以及編輯 SiteColumns.xml 檔案來變更欄位參照。
如果您根據 readme.htm 檔的說明來部署該功能，就可以在多個網站集合一致啟動它。接著「客戶說明文件」內容類型就可以全域使用。這麼一來，個別部門就可以透過與指定文件範本相關聯的衍生內容類型，建立特定的客戶文件。隨附的資料中還包括銷售和諮詢用的範例文件範本。[圖 2] 顯示最後得出的內容類型。
[圖 2] 客戶文件的父系和子系內容類型
[圖 2] 客戶文件的父系和子系內容類型
要在 WSS 3.0 和 MOSS 2007 建立自訂網站欄和內容類型的功能，方法有好幾種。您可以研讀 WSS 3.0 SDK，從頭撰寫 XML 檔案；也可以選擇使用 SharePoint Designer，將清單匯出到個人網頁套件、把得出的 .fwp 檔重新命名為 .cab 檔案、從 .cab 檔案擷取 manifest.xml 檔案，然後再搜尋 manifest.xml 檔案中的 ContentType 定義。不過這兩種方法都不太方便，而且很容易出錯。
相較之下，在 SharePoint 使用者介面建立自訂網站欄和內容類型，要容易得多。但是，介面無法讓您編輯某功能的 XML 檔案。功能雖然足以提供 SharePoint 資源，但是它們所提供的資源只位於內容資料庫中。也許未來的 WSS 可以透過 SharePoint 使用者介面，將網站欄和內容類型匯出到 XML 檔案，就像匯出網頁組件一樣，但是目前您只能使用手邊現有的功能。
您也可以從隨附的資料內含的網頁組件 ContentTypeSchema 著手。這個網頁組件利用 SharePoint 物件模型，從選定的內容類型擷取 SchemaXML 屬性。然後透過以 eXtensible 樣式表語言轉換 (XSLT) 為基礎的轉換，您在按下 [顯示] 按鈕之前，網頁組件會根據您在使用者介面選取的選項，衍生 Field 定義或 ContentType 定義。
[圖 3] 所顯示的就是這個網頁組件。它顯示了我以「客戶說明文件」內容類型為基礎而建立的「Active Directory® 說明文件」內容類型。「Active Directory 說明文件」內容類型與一個自訂 Microsoft Word 範本 (Active Directory Template.dot) 相關聯。請注意，這個內容類型並沒有額外的欄位，所有的欄位都是繼承自父系的內容類型。
如果您打算在自己的環境內使用 ContentTypeSchema 網頁組件，請記住，這個網頁組件尚未經過完整的測試。我的網頁組件是使用相當複雜的 XSL 轉換，來建立目前所選內容類型及其父系內容類型的 SchemaXML 屬性差異值。但是，XSLT 1.0 並非真的針對進階 XML 文件轉換而設計，它沒有內建功能可以比較 XML 節點。另外，XML 命名空間和 CDATA 區段，都表示 XSLT 1.0 無法有效處理。
SharePoint 會儲存以 SharePoint 使用者介面或 SharePoint 物件模型所建立之網站欄和網站內容類型的定義，而 SharePoint 使用者介面或 SharePoint 物件模型是位於表格 ContentTypes 的內容資料庫中。[圖 3] 就是我的自訂內容類型識別碼。根據這一點，下面這個 T-SQL 陳述式會得出明確的結果：SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>。
[圖 3] SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>。 網頁組件
[圖 3] SELECT Definition FROM ContentTypes WHERE ContentTypeId = <content type ID>。 網頁組件
無論您決定使用哪一種方法，只要取得網站欄和內容類型定義，就不難建立全企業內容類型的功能。我建議您在貴公司或貴部門的所有全域網站欄和內容類型上，只採用單一功能，這麼一來，就能一眼看出該在哪裡加入新的網站欄和內容類型定義。

全企業搜尋自訂中繼資料
內容類型階層有一個現成的優點，那就是所有的子系內容類型都會繼承父系內容類型的中繼資料欄位。由於所有的內容類型都有共同的中繼資料欄位，因此使用者很容易就可以在文件庫中建立自訂檢視和篩選器。
AdventureWorks 範例功能說明得相當清楚。無論顧問或業務人員建立的內容是什麼，只要您想把得出的 Word 2007 文件儲存在文件庫中，都必須指定一個「客戶名稱」，因為「客戶說明文件」父系內容類型會在必要時，定義這個中繼資料欄位。顧問和業務小組成員可以根據「客戶名稱」，將文件庫檢視中的項目加以分組或篩選，以便快速方便的找到客戶所有的現有文件，如 [圖 4] 所示。
[圖 4] 根據共同的中繼資料將文件庫中的各種文件加以分組
[圖 4] 根據共同的中繼資料將文件庫中的各種文件加以分組
共同的中繼資料也方便您使用 WSS 3.0 和 MOSS 2007 的搜尋功能，尋找多個文件庫和網站上的內容。WSS 容許您在一個網站集合內的各文件庫、清單和網站進行搜尋，而 MOSS 2007 更超越這些基本功能，容許您實作全企業的搜尋中心，並且在 SharePoint 3.0 管理中心使用者介面上管理自訂中繼資料。因此，下面我們將把重點擺在 MOSS 2007。
當您在 MOSS 2007 設定共用服務提供者 (Shared Service Provider，SSP)，以及在 SharePoint 網站上進行編目時，MOSS 2007 會自動發現內容來源所用的自訂中繼資料欄位。因此，您可以在編目屬性清單中，找到自訂中繼資料欄位。
在 SharePoint 功能中定義的中繼資料欄位，通常都落在 SharePoint 類別下。若要尋找它在 SharePoint 管理中心的位置，請在 [快速啟動] 功能表的 [共用服務管理] 下方，按一下連至您 SSP 的連結、按一下 [搜尋設定]、按一下 [中繼資料屬性對應]、再按一下 [快速啟動] 功能表的 [編目屬性]，然後再開啟 SharePoint 類別。
我會提供一個運作範例。稱為 [Customer Name (客戶名稱)] 的中繼資料欄位最後會變成編目屬性，名叫 ows_Customer_x0020_Name。SharePoint 在編目屬性前面加上 "ows_" 作為首碼，而 "_x0020_" 則代表編碼版的一個空格。只要顯示這個編目屬性的詳細資料，就會發現它預設包含在搜尋索引中，因此使用者可以使用這個編目屬性的值來執行內容搜尋。但是為了提高搜尋精準度，您可能不希望將編目屬性對應到 Managed 屬性，這樣使用者才能依據客戶名稱明確搜尋內容。
您有兩種方式可以將編目屬性對應到 Managed 屬性。您可以為每一個編目屬性自動產生一個新的 Managed 屬性，也可以手動將編目屬性對應到 Managed 屬性。當您顯示所要的編目屬性類別設定時 (要顯示某類別中的編目屬性 (例如 SharePoint 類別)，請按一下 [快速啟動] 連結上的 [編輯類别] 選項)，可以採用第一個方法。您必須在 [大量編目屬性設定] 下方，勾選 [為每個再此類別中探索到的編目屬性自動產生新的Managed 屬性] 核取方塊。但是 SharePoint 會自動在您所建立的 Managed 屬性前面加上 "ows" 作為首碼，並且以 "x0020" 建立空格。編目屬性 ows_Customer_x0020_Name 的 Managed 屬性是 owsCustomerx0020Name，不過這並不是一個令人一目瞭然的屬性名稱。
所以也許在部署全企業內容類型之後，再手動將編目屬性對應到 Managed 屬性，是比較理想的方式。您可以將一個編目屬性對應到一或多個 Managed 屬性。若要建立新的 Managed 屬性，請在 SharePoint 管理中心的 [快速啟動] 功能表的 [共用服務管理] 下方，按一下連至您 SSP 的連結、按一下 [搜尋設定]、再按一下 [中繼資料屬性對應]，然後再按一下 [新增 Managed 屬性]，指定所需的資訊，並且將新的 Managed 屬性關聯到您所要的編目屬性。
接著使用者就可以在 property: 語法中或者使用進階搜尋來使用 Managed 屬性，藉此尋找相關的內容項目。比方說，如果您將編目屬性 ows_Customer_x0020_Name 對應到 Customer Managed 屬性，使用者只要在標準搜尋方塊指定 Customer:<客戶名稱> (例如 Customer:Contoso)，就可以搜尋客戶的所有文件。
您也可以針對內容類型最重要的中繼資料欄位，加入 Managed 屬性 (內容類型位於 [進階搜尋] 網頁上的屬性清單中)。做法是先顯示 [進階搜尋] 網頁，然後按一下 [動作]，再選取 [編輯網頁] 命令。現在您就可以按一下 [進階搜尋] 方塊的 [編輯]，選取 [修改共用的網頁組件] 選項。當您展開 [屬性] 類別，並將游標放在相對應的文字欄位時，可以按一下按鈕來編輯屬性 XML 文件。您必須在 <PropertyDefs> 元素加入一個屬性定義 (例如 <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>)，另外還要在 ResultType 元素 (例如，元素 <ResultType DisplayName="All Results" Name="default">) 下方，加入這個屬性定義的參考，例如 <PropertyRef Name="Customer" />。[圖 5a] 顯示的是最後得出的 [進階搜尋] 使用者介面。[圖 5b] 顯示的是搜尋結果。
[圖 5a] 依照客戶名稱搜尋 IT 基礎結構文件
[圖 5a] 依照客戶名稱搜尋 IT 基礎結構文件
[圖 5b] 客戶名稱搜尋的結果
[圖 5b] 客戶名稱搜尋的結果

確保資訊一致性
這時候，我已順利將最重要的中繼資料欄位和內容類型標準化，並且根據 MOSS 2007，在我企業中擴充網站集合的搜尋能力。接下來就是確保使用者在中繼資料欄位輸入精確的資訊。
做法有兩種：第一，您可以把文件範本中的標準文件資訊面板，替換成自訂 InfoPath® 表單，提供使用者預先定義的輸入選項，例如您在清單方塊中的選項。第二，您可以將事件接收器繋結到內容類型，然後每當使用者建立、修改或刪除相對應的內容項目時，就檢查中繼資料及其他資訊的精確性。
這兩個選項彼此互補。InfoPath 表單主要在提供一個方便的方式，讓您編輯 SharePoint 內容類型的屬性，而事件接收器則是確保中繼資料有效 (即使使用者在 InfoPath 表單外面編輯內容類型屬性也一樣)。您可以將事件處理器繫結到特定的內容類型，讓您針對所有網站集合中所有與個別內容類型相關聯的文件，指定事件及其回應，而不論文件庫為何。有關如何開發和部署事件處理器的其他相關資訊，請參閱 msdn2.microsoft.com/ms453149。
如果要將內容類型關聯到自訂文件資訊面板，最簡單的方式應該是在裝有 InfoPath 2007 的電腦的 SharePoint 使用者介面中，顯示內容類型的 [文件資訊面板] 設定，然後按一下 [文件資訊面板範本] 下方的 [建立新的自訂範本] 連結，以設計模式啟動 InfoPath 2007。但是，如果您的網站內容類型包含沒有明確 SourceID 屬性的網站欄，InfoPath 可能就無法為 [文件資訊面板] 表單建立有效的 XSD 結構描述。比方說，之前介紹的「客戶說明文件」內容類型包含了好幾個連絡人專屬欄 (例如，[部門]、[辦公室] 和 [電子郵件])，而這些專屬欄都有可能導致這個問題，如 [圖 6] 所示。
[圖 6] InfoPath 2007 的 XSD 結構描述不相容
[圖 6] InfoPath 2007 的 XSD 結構描述不相容
如果這時候遇到這個問題，有兩種方法可以解決。您可以從內容類型定義，移除沒有明確 SourceID 屬性的網站欄參考，也可以把導致問題的內建網站欄替換成與 InfoPath 2007 相容的自訂網站欄。請記住，一旦將 CAML 內容類型的欄位參考提供到內容資料庫之後，就不可以變更它，如果您已建立子系內容類型的話更是不行。您不可以只是更新 CAML 內容類型定義檔，也不可以將變更下推至子系內容類型，因為 Windows SharePoint Services 不會追蹤您對父系內容類型定義所做的變更。
如果要下推變更，必須透過 SharePoint 使用者介面或物件模型，變更父系內容類型，否則就必須從現有內容類型衍生並定義新的內容類型。後者可讓您移除重要欄位，加入新欄。接著使用者可以再從新的內容類型衍生未來的內容類型。為了不讓使用者選錯內容類型，請在 _Hidden 內容類型群組加入前一個內容類型。
我之前說過，CAML 內容類型一經部署和啟動之後，就不可以更新。因此在部署之前，一定要測試全域內容類型。如需詳細資訊，請參閱 MSDN 文章＜更新內容類型＞，網址為 msdn2.microsoft.com/aa543504。
只要建立含適當欄位參考的內容類型之後，就可以在 InfoPath 2007 建立自訂文件資訊面板。最妥當的方法是讓網站擁有者建立其子系內容類型的自訂文件資訊面板。您可以使用 InfoPath 2007，把自訂文件資訊面板直接發佈到選定的內容類型，以方便您部署。不過您也可以在中心位置 (例如，文件庫) 發佈 InfoPath 表單，並且在內容類型加入文件資訊面板的參考。如果您打算連同 CAML 內容類型一起提供自訂文件資訊面板，這是最佳的選擇。[圖 7] 說明的是實作架構。
[圖 7] 在 MOSS 2007 的中心位置實作 XSN 檔案
[圖 7] 在 MOSS 2007 的中心位置實作 XSN 檔案
本文隨附的下載檔案還包括一項名為 AdventureWorks_Update 的功能，它另外新增了一個網站欄與 InfoPath 2007 搭配使用，藉此延伸之前的 AdventureWorks 功能。AdventureWorks_Update 功能將原始的「客戶說明文件」內容類型標示為隱藏，並且衍生一個新的內容類型「客戶文件」，它把繼承而來的內建欄位取代成新的網站欄，並且把新的內容類型關聯到自訂文件資訊面板。
新的「客戶文件」內容類型定義包含一個提供文件資訊面板相關資訊的 XmlDocument 元素。特別的是，xsnLocation 元素會指向 InfoPath 表單 ，來實作文件資訊面板。有關如何套用 AdventureWorks_Update 功能的詳細資訊，請參閱 AdventureWorks_Update 資料夾中的 readme.htm 檔。

總結
您可以使用 SharePoint 內容類型來建立中繼資料原則，並且全面導入企業以進行內容管理。內容類型的階層可讓您把與整個企業環境有關的特性標準化，並且藉由繼承關係，將它們統一套用到所有的網站上。
除此之外，還可以延伸 MOSS 2007 的內建搜尋功能，讓使用者更快速且更方便的尋找特定的內容。您也可以強制將中繼資料相關資訊一致化，並且建立中央資訊管理原則。最理想的方式就是將最抽象的中繼資料特性的全域內容類型標準化，盡量降低日後變更的需要。SharePoint 內容類型是以審慎設計的內容模型為基礎，可以提供新的功能，將整個企業的內容生命週期管理標準化。

Pav Cherny 是 Biblioso Corporation 總裁暨 IT 專家與作者，專攻 Microsoft 共同作業與整合通訊技術。其出版著作多半集中於 IT 作業與系統管理領域。


 Office Communications Server: 目前狀態如何發揮 OCS 2007 的功力
Office Communications Server Rajesh Ramanathan

目前狀態如何發揮 OCS 2007 的功力
摘要:
  • 驗證和目錄服務
  • OCS 2007 中的訊息選項
  • 利用目前狀態路由通訊

Microsoft Office Communication Server (OCS) 2007 是以 Live Communication Server (LCS) 2005 版本為基礎建置而成。LCS 2005 不但提供企業級的立即訊息
(IM) 和目前狀態等功能，更透過遠端呼叫控制 (RCC)，推出與現有 PBX 安裝的電話語音整合。
OCS 2007 更進一步強化 LCS 2005 當中的目前狀態和 IM 功能，並透過 Office Communictor 2007 添加進階的媒體和電話功能，使它成為名副其實的 Softphone (軟體網路電話)。Microsoft 另外也針對媒體開發了會議伺服器和邊緣伺服器，將它作為獨立的完整解決方案，或者連同現有的 PBX，滿足貴公司的各種通訊需求。
Office Communicator 2007 除了提供「Softphone」功能，讓使用者選擇 USB 裝置之外，它還提供豐富的使用者體驗，方便他們尋找和使用常見的電話功能，例如保留和轉接電話等。使用者不必再熟記電話號碼，也不必使用撥號盤，只要從桌面應用程式按一下按鍵，就可以輕鬆進行通話，或是將人員或通訊群組清單拖放到交談中來建立電話會議。
對於實際需要有線電話的使用者，可以將 Office Communicator Phone Edition (或 Tanjay 電話) 當作是另外一個端點，享受觸控式快顯功能表和熟悉的 Office Communicator 目前狀態體驗。
這些 OCS 系統功能都是以使用者目前狀態的概念為中心來建置。OCS 2007 運用使用者空閒狀態、通訊端點和使用者關係，及時透過在任何一個點上最適當的媒介來聯繫人員。由於 OCS 已與語音、電子郵件、IM 和其他通訊路徑緊密整合，因此可以最有效的方式幫助您路由訊息。
在本文中，我會概略介紹 OCS 2007 解決方案，並說明各個部分如何彼此搭配運作。我還會探討如何將目前狀態作為重要的食材，用於整合通訊的食譜當中，以及如何更有效地將它應用到路由語音電話上。

驗證和目錄服務
企業語音系統必須能夠驗證獲准發話者的身分，也應該能夠針對每通電話套用限制或原則。在 Voice over IP (VoIP) 系統中，用戶端必須向伺服器驗證身分之後才能撥打電話，這與傳統的 PBX 系統雷同，也就是只要存取實際的電話線，就可以強制識別身分。
如 [圖 1] 所示，OCS 2007 系統是使用 Active Directory® 來驗證和儲存存取原則，並且以 Active Directory 中的使用者原則來驗證電話，然後授權發話。由於 OCS 跟其他 Microsoft 應用程式 (例如 Exchange Server 或 Microsoft® Outlook®) 都是使用相同的 Active Directory 資訊，所以您只要在 Active Directory 的現有使用者加入語音功能就行了，方法是擴充使用者的屬性和原則 (透過 Active Directory 架構延伸)，然後提供一個統一的目錄作為即時應用程式 (例如語音或 IM)。
[圖 1] OCS 整合通訊元件
[圖 1] OCS 整合通訊元件
在 Active Directory 中與整合通訊相關的屬性，最重要的當屬工作階段初始通訊協定 (Session Initiation Protocol，SIP) 位址了 (也稱為 SIP URI)，它在本質上跟使用者的電子郵件地址非常相似。比方說，如果 Active Directory 中的使用者，其電子郵件地址為 someone@contoso.com，他的 SIP 位址就是 sip:someone@contoso.com。既然 SIP 位址與使用者物件相繫結，您便可以提供單一身分識別，讓使用者將登入桌上型電腦或 Exchange 伺服器所用的認證，拿來登入 OCS 伺服器。
另一個重要的屬性是使用者的電話號碼。OCS 伺服器會在內部將傳送到電話號碼的電話，重定成使用者的 SIP URI，以便路由電話。
OCS 2007 提供的通訊錄服務 (ABS) 介面，可以方便您查詢組織當中的名錄。有了這份離線通訊錄，用戶端端點在用戶端進行搜尋查詢時，就不需要每次都查詢 Active Directory 了。
除了 ABS 外，OCS 2007 還提供通訊群組清單延伸 (DLX) 服務，進一步發揮通訊群組清單的效用，這項服務可讓使用者在 Office Communictor 中檢視他們在 Outlook 所查看的同一份通訊群組清單，並且在 Communicator 中擴充通訊群組清單。使用者可以直接從 Office Communicator 與這些通訊群組清單的成員進行電話會議，或是進行群組 IM 線上交談。

語音和訊息服務
其他 OCS 資源
如需詳細資訊，請參閱以下資源：
  • 整合通訊活動和網路廣播
  • Office Communications Server TechCenter
  • TechNet 虛擬實驗室：啟用使用者和安裝 Office Communicator 2007

企業語音解決方案必須提供使用者最熟悉的呼叫控制功能。有鑑於此，OCS 2007 提供了最普遍的功能，例如來電保留、來電轉接和諮詢轉接、轉接，以及同時響鈴，另外還有非語音模式，例如 IM。
OCS 2007 是語音電話路由的核心，它同時提供發話和受話路由功能。發話路由包括轉譯號碼、套用與使用者相關的原則 (例如國際電話限制)，以及將電話路由到適當的端點，或向外路由到公用交換電話網路 (Public Switched Telephone Network，PSTN)。受話路由功能則負責處理使用者選定的來電轉接，每日時間/目前狀態喜好設定，以及適當地路由來電等。
OCS 並不會自行終止來電，根據 SIP 說法，它的作用像是 SIM 登錄器和 SIP Proxy。訊號和媒體完全是由系統中的用戶端端點以點對點的方式提供。系統中的端點，例如 Office Communicator 2007，都提供一種寬頻音訊轉碼器 (稱為 RTAudio) 來順應和配合網路狀況。
OCS 2007 會使用適合各種通訊模式的 Conferencing Server 角色來提供內部 Web 會議，這些模式包括：音訊/視訊、IM 和資料。以 OCS 為基礎的 Conferencing Server，透過靜音、退出參與者和鎖定等功能，容許用戶端端點從對等式通訊，完美轉換成多名參與者的多模式通訊。它可以彈性容納上百名參與者進行排定的會議，以及多達一百名參與者進行臨機操作討論。您可以透過 Outlook 增益集或是在會議中進行通話中升級等方式來排定會議。會議解決方案也會提供檔案共用、白板和錄製等工具。
當然，您必須能夠連接外部 PSTN 網路和電話號碼，以及在組織內連接外部企業或提供現有 PBX 安裝。OCS 2007 整合了常見閘道所提供的 SIP 對 PSTN 閘道，這類閘道容許與 PSTN 或與現有 PBX 連接。您可以設定中繼伺服器用於轉碼器和訊號轉譯。中繼伺服器是選擇性的，而且是針對不支援 Microsoft 轉碼器的閘道而設定。
Exchange Server 2007 整合通訊是 OCS 2007 的語音信箱解決方案。Exchange 整合通訊為輸入語音和傳真呼叫提供自動答錄功能，並且會將收到的訊息放入使用者的 Exchange 信箱中。此外，Exchange 整合通訊還提供公司自動語音應答，供外部來電者尋找特定的個人或部門。
OCS 把即時 IM 作為使用語音的另一種管道，它也可以讓使用者參與同時包括語音、視訊和 IM 的多模式交談。除此之外，Office Communicator 2007 還容許在 IM 中使用 RTF 格式和進行格式化。另外在 IM 工作階段中也可以隨時加入音訊和視訊，毫無阻滯地將 IM 交談升級為音訊交談。
其他還有帳戶管理、記錄和疑難排解等元件。帳戶管理是使用 OCS 2007 詳細通話記錄伺服器功能來提供。對於在系統內所進行的每次通話，都會將來電的時間、接聽的目的地，以及各種其他參數 (例如該通來電是否經過轉接) 等記錄下來。OCS 也提供封存伺服器來記錄 IM 交談，以滿足循規的需求。體驗品質 (Quality of Experience，QoE) 監視服務會將通話品質的相關資訊儲存起來，以供疑難排解網路當中的語音品質問題之用。

註冊和初始化
OCS 系統當中的每個用戶端端點都需要註冊或登入 OCS，這是初始化用戶端的首要步驟。註冊是指連接到 OCS 伺服器的過程，這個步驟會通告用戶端的存在。註冊的程序包括由伺服器驗證使用者身份識別，這個程序會在用戶端執行個體和伺服器之間，建立一個安全性關聯。用戶端可以使用這個安全性關聯，透過伺服器進行後續的呼叫，並重新註冊以定期重新整理此安全性關聯。重新註冊的持續時間將視伺服器的拓僕而異。比方說，從企業外部透過 Microsoft AccessTM 邊緣伺服器註冊的用戶端端點，它們重新整理註冊的頻率，比在企業防火牆內部註冊的用戶端端點高。
請注意，只有那些需要與 OCS 保持持續驗證通道以接收傳入通知 (例如語音通話或目前狀態變更通知) 的用戶端端點才需要註冊。Live Meeting 只有在需要參加會議時才需要連接到 OCS 的用戶端端點，因此它不需要向 OCS 註冊。
為了更加了解用戶端在 OCS 2007 內互動的細節，讓我們仔細探討一下作為用戶端端點的 Office Communicator (大多數與 Office Communicator 相關的訊號流程，與其他像是 Office Communicator Phone Edition 或 Office Communicator Mobile 等用戶端端點所用的沒什麼兩樣)。註冊一經完成，Office Communicator 就會擷取設定資訊，這是操作用戶端端點不可或缺的要素。這項資訊包括：
  • 自我資訊，例如連絡人卡片、電子郵件地址、SIP URI、顯示名稱和電話號碼
  • 用戶端上啟用的功能和原則
  • 伺服器位址，例如 AV 邊緣伺服器 SIP 位址和語音信箱伺服器位址
  • 存放在伺服器上的連絡人好友清單
  • 根據用戶端地點而定的數字格式規則
這套使用現有 SIP 通道將所有佈建資訊擷取到伺服器的機制，稱為內頻佈建 (inband provisioning)。這可讓用戶端端點在用戶端每次登入，以及從網路或防火牆外部時，自動設定和重新整理他們的設定。
註冊接著繼續向伺服器註冊以初始化、取得和設定目前狀態，最後進入完備狀態 (見 [圖 2])。請注意，OCS 容許相同的使用者或 SIP URI 註冊多個用戶端端點。在註冊期間，伺服器會傳回一個唯一的 SIP 位址給用戶端，以容輸入的訊號鎖定特定的用戶端。這個位址也稱為可全域路由使用者 URI (Globally Routable User URI，GRUU)。對於在 OCS 註冊的每一個用戶端端點，OCS 伺服器都會指派一個不同的 GRUU 位址，以利它們唯一識別用戶端端點。
[圖 2] 註冊程序
[圖 2] 註冊程序
為了掌控註冊作業，對於每一名使用者，伺服器限制最多只能有八個作用中註冊。當一名使用者註冊多個用戶端時，這種設定稱為多點出席 (Multiple Points Of Presence，MPOP)。註冊單一用戶端時，就稱為單點出席 (Single Point Of Presence，SPOP)。
MPOP 的概念是 OCS 系統的核心，它讓使用者從任何一個端點接收來電或 IM 通知，基本上是讓使用者擁有多支電話或 IM 端點。它在應答 IM 方面，還有甚至是在為使用者準確的以語音輸入目前狀態方面，都提供了有趣的互動。
例如，遠端使用者可以登入 Communicator Phone Edition IP 電話 (SPOP 端點)，卻不能接收 IM。這個端點功能是由 IP 電話隨著目前狀態資訊一起發佈。使用者在電話上的目前狀態是處於連線狀態。另一名使用者可以查看線上目前狀態，並嘗試使用 Communicator 傳送 IM。但是因為目前狀態已發佈裝置功能，於是有通知顯示遠端使用者並不是位於具 IM 功能的裝置上，因此可能收不到訊息。
另外一個例子是自動接受 IM。如果遠端使用者是位於單一 Communicator 執行個體 (也就是 SPOP 端點) 上，只要 IM 交談一開始，便會立即自動接受訊息。但是如果遠端使用者是登入到兩個 Communicator 執行個體上 (比方說膝上型和桌上型電腦)，那麼便會提供 10 秒的延遲時間，讓使用者從其中一個裝置接受立即訊息。如果沒有應答，大多數作用中的 Communicator 執行個體都會自動接受立即訊息。

目前狀態
目前狀態在整合通訊裡面扮演著重要的角色，它可讓使用者預先知道遠端使用者的空閒狀態，以透過指定的模式進行通訊。因此，OCS 所指的「忙碌中 — 電話中」是與使用者的忙碌狀態相關，而與裝置或線路忙碌中無關。此外，OCS 2007 還提供一套增強的目前狀態基礎結構，可讓使用者分享諸如地點、工作時間和開會時間等資訊。
另外，OCS 還容許使用者指定權限，讓不同群組的人員根據他們的存取層級，存取不同的目前狀態資訊。OCS 也會運用使用者的目前狀態 (例如「請勿打擾」)，以及提供給來電者的行事曆工作時間和權限層級，來訂定路由的決策，決定是否應該接通使用者，或是送到語音信箱。
Office Communicator 裡面的 [按一下撥打] 所顯示的電話號碼是來自三個位置 — 其中兩個是以名錄為主 (全域通訊清單/通訊錄伺服器和 Outlook 連絡人)，第三個則是透過目前狀態取得。透過目前狀態，使用者可以彈性發佈他們希望其他人看到的電話號碼。
目前狀態也在許多語音路由案例中扮演著關鍵的角色。舉例來說，如果遠端使用者的目前狀態指出「忙碌中」，並顯示「會議中」的文字，那麼使用者接電話的可能性就很低。在這種情況下，來電者也許寧願使用 IM 或電子郵件。同樣地，當遠端使用者的目前狀態是「請勿打擾」時，就表示採用其他通訊方式可能比較恰當。
目前狀態也會傳達使用者目前參加的會議標題和行事曆位置等資訊，這類詳細資料是發佈給 [小組] 容器內的使用者。目前狀態還會攜帶特定功能慣用端點的相關資訊，這項資訊是用來挑選會採取預設動作的端點。舉例來說，行事曆資料發佈 (這在所有端點基本上都是一樣的) 只能從行事曆功能慣用的端點來完成。OCS 有它挑選慣用端點的邏輯。
[圖 3] 主要在強調目前系統帶給 OCS 系統的各種功能。前面曾經提過，目前狀態是一種空閒狀態和通訊意願的組合。「線上」狀態代表使用者最願意通訊的狀態，而「請勿打擾」則是使用者最不願意通訊的目前狀態。除了「請勿打擾」必須手動設定之外，所有其他狀態都是由 Communicator 根據各種狀況自動擷取，例如使用者是否正在開會中 (忙碌中)，或是不在電腦旁 (非使用中，然後離開)，如 [圖 4] 所示。
Figure 3 目前狀態資訊的設定方式 (Close Figure 3)

功能 | 來源
空閒狀態和意願 (線上、離線、離開、忙碌中、請勿打擾) | 自動。根據會議狀態、電話狀態等等，也可以手動設定。
行事曆狀態 (會議中，會議地點) | 自動。根據使用者喜好設定。
裝置功能 (容許 IM) | 自動。根據 MPOP 裝置。
電話號碼 | 自動。根據使用者喜好設定。
大多數作用中端點 | 自動。根據使用者活動。
備註 | 手動。換成不在辦公室備註。
不在辦公室備註 | 自動。根據行事曆。
工作時間 | 自動。根據空閒/忙碌資料。
地點 | 手動。根據使用者選擇。
[圖 4] 混合空閒狀態和通訊意願的目前狀態
[圖 4] 混合空閒狀態和通訊意願的目前狀態
請注意，空閒狀態可能會受到使用者目前登入的各種裝置所影響。因為同一名使用者有幾個不同的裝置，而每個裝置都會從裝置發佈目前狀態資訊和使用者資料，因此需要有彙總的邏輯向觀看者呈現單一檢視。OCS 具有這類彙總邏輯，它會根據不同的參數、裝置，以及自目前狀態系統收到的各種輸入，來計算目前狀態。
在探究彙總之前，最好能夠看看彙總資訊是怎麼發佈給使用者的。OCS 2007 引進了容器的概念，這跟與社交圈相關的存取等級有點類似。每個容器所提供的資訊量各不相同，被加到某個容器的人員，只能存取提供給該容器的資訊。使用者好友清單裡面的每個人，都必須出現在其中一個可用的容器內。Office Communicator 容許使用者指派人員到容器裡面，或是根據關係的等級，將他們移到不同的容器。Office Communicator 運用智慧的探索方法，自動選擇預設容器 (如 [圖 5] 所列)。
Figure 5 目前狀態容器 (Close Figure 5)

容器 | 用途
封鎖 | 封鎖目前狀態資訊。被封鎖的使用者不能夠打電話，但是仍然可以查看名稱和電子郵件地址資訊。
公用 | 提供名稱、職稱、公司、電子郵件地址和有限的空閒狀態。
公司 | 提供工作連絡人資訊、基本排程和空閒狀態。
小組 | 提供工作和行動號碼、排程、空閒狀態，而且可以在處於「請勿打擾」的狀態時打擾使用者。
私人 | 可查看所有已發佈連絡人資訊，包括住家和行動電話。
OCS 中的目前狀態彙總，會根據裝置報告給伺服器的各種目前狀態，來判斷使用者正確的目前狀態。[圖 6] 說明目前狀態從各種來源進行彙總的方式。請注意，其中有些資訊 (例如目前狀態和使用者活動) 是在容器內的資訊可用之前，透過 OCS 目前狀態彙總機制送出，而其他資訊 (例如連絡人詳細資料) 則是由用戶端端點新增至個別的容器內。被封鎖的容器之所以看不到，是因為會發佈到該容器的只有成員資格資訊。
[圖 6] 目前狀態彙總和發佈
[圖 6] 目前狀態彙總和發佈
在 OCS 系統中，目前狀態關係是在某位使用者將另一位使用者加入連絡人清單 (好友清單) 時建立而成。但是 OCS 系統也容許您查看公司名錄當中其他使用者的目前狀態，而不需要將這些使用者個別加入到您的連絡人當中。
取得某人目前狀態最簡單的方法，就是在 Office Communicator 中搜尋那個人。此舉會在伺服器上產生一項查詢，而不會向伺服器訂閱關於遠端使用者目前狀態變更的通知。不過，當使用者在好友清單加入其他使用者時，他同時會訂閱目前狀態變更的通知，好讓 OCS 在發生變更時自動傳送警示。

IM 和音訊
IM 擁有註冊和目前狀態兩者的優點。在 OCS 系統中，訊息是點對點行進，而 OCS 伺服器則扮演 Proxy 的角色，在 Office Communicator 用戶端之間來回運送訊息。
使用者初次發給另一名使用者的第一個訊息相當重要，根據 SIP 的說法，它會建立工作階段。建立工作階段有一部分是要從註冊的用戶端中尋找正確的 MPOP 用戶端，而這正是 OCS 扮演 Proxy 角色之所以重要的地方。使用者一旦接受傳入的 IM 工作階段，或是使用者其中一個 MPOP 端點自動接受之後，後續的訊息就可以順利地端對端行進，而不需要借助 OCS 尋找適當的用戶端。
使用者可以在桌上型電腦上將 IM 交談視窗保持開啟狀態，如果 10 分鐘內沒有任何活動，Office Communicator 2007 便會結束 SIP 工作階段 (不過 IM 視窗會保持開啟狀態)。任一端都可以終止 IM 工作階段。IM 階段一終止，Office Communicator 2007 便會自動建立交談的歷程記錄項目，將整次交談記錄到 Outlook 交談記錄資料夾中。這是 Office Communicator 在 Outlook 中建立的特別資料夾。這項用戶端的記錄功能是選擇性的，並且預設是處於關閉狀態。要與同一名使用者重新開始交談時，Office Communicator 會使用交談記錄，如果使用者在 IM 視窗關閉後要再繼續 IM 交談，那麼開啟這項功能會讓交談更加順利。
請注意，用於分接和 MPOP 的 IM 建構，也適用於語音的案例。只不過它並沒有包含 IM 工作階段說明的邀請函，只有指出音訊功能的語音工作階段說明。OCS 會將分接套用到所有端點的語音電話，這與套用 IM 的情況類似。
語音訊號在很多方面是從 IM 概念衍生而來，但是它有處理媒體的需要。這些我打算在日後另闢專文詳細討論。

Rajesh Ramanathan 在通訊領域工作已長達 14 年之久，目前正於 Office Communicator 小組擔任專案主管一職。您可以透過電子郵件與他聯絡：rajeshra@microsoft.com。


 Office Communications Server: 規劃 OCS 2007 語音部署
Office Communications Server Jochen Kunert and Rui Maximo

規劃 OCS 2007 語音部署
摘要:
  • 電話語音整合案例
  • 設定 Office Communications Server
  • 使用者、號碼對應表和路由

Microsoft Office Communications Server (OCS) 2007 是整合即時通訊媒體與使用者線上狀態的企業產品，包括 Web 會議
(共用資料、音訊和視訊)、立即訊息，以及音訊/視訊交談。整合 OCS 2007 與現有 PBX 系統的工作可說相當艱鉅，但是 Office Communications Server 2007 的設計目的並不是要作為 PBX 使用，因為當今的資訊工作者在日常工作流程中採用的媒體通訊林林總總 — 電子郵件、立即訊息、電話和語音信箱 — 而 PBX 系統只提供電話呼叫。
為了提供系統管理員所需的彈性，讓他們建立最佳的個人或公司電話語音整合策略，Office Communications Server 2007 提供三種設定案例，以利現有電話語音環境的整合。這些案例包括：遠端呼叫控制、Enterprise Voice，以及 Enterprise Voice 與 PBX 整合。
本文主重規劃 OCS 2007 電話語音部署的考量事項，進行這類部署時，可能需要整合現有的電話語音系統。這項資訊對系統架構設計師，以及 IT 和電話語音系統管理員特別有用。我們會概略介紹其他案例，但焦點將放在 Office Communications Server 2007 Enterprise Voice。

遠端呼叫控制
其他 OCS 資源
  • 精通 LCS：Live Communications Server 管理
  • 整合電話語音與 Office Communications Server 2007
  • Enterprise Voice 規劃與部署指南

以遠端呼叫控制 (RCC) 為例，使用者目前有 PBX、IP-PBX 或分時多工 (Time-Division Multiplexing，TDM) 有線電話。不必用撥號盤，也不用拿起聽筒，就可以從 Office Communicator 2007 用戶端撥打和接聽有線電話。雖然使用者可以利用 Office Communicator 2007 控制有線電話，但音訊還是由 PBX 系統處理，而且不會轉換成 Voice-over-IP (VoIP) 電話。雖然 Office Communicator 2007 可以控制有線電話，您仍然可以從 PBX 系統撥打和接聽電話，無論 Office Communicator 2007 是否正在執行中都一樣。
如果要透過 Office Communicator 2007 和 OCS 2007 啟用 RCC，除了必須為 RCC 準備 Office Communicationis Server 2007 環境之外，還必須部署工作階段初始通訊協定 (Session Initiation Protocol，SIP)/以電腦為基礎的電話語音應用程式 (Computer Supported Telephony Application，CSTA) 閘道。SIP/CSTA 閘道必須與您所用的 PBX 系統類型交互操作，並且必須與 OCS 2007 相容，因為它會橋接兩個系統。Office Communicator 2007 是使用 CSTA 通訊協定來控制 PBX 電話。根據歐洲電腦製造商協會 (European Computer Manufacturers Association，ECMA) 269 標準所述 (請參閱 www.ecma-international.org/publications/standards/Ecma-269.htm)，這個通訊協定會定義 XML 結構描述，與電話交換機 (PBX) 互動。
Office Communicator 2007 會傳送 CSTA 命令，把 PBX 電話當作 SIP 裝載加以控制，而 Office Communications Server 2007 則把 SIP 裝載路由給 SIP/CSTA 閘道。Office Communications Server 2007 並不需要了解 CSTA，它只需要知道怎麼路由它就行了。SIP/CSTA 閘道之後會將命令轉換成 PBX 所用的原生通訊協定。[圖 1] 說明的就是這個步驟。
[圖 1] RCC 整合案例
[圖 1] RCC 整合案例
啟用 RCC 需要五個步驟：第一個步驟是設定讓 SIP/CSTA 閘道與 PBX 通訊。接下來是設定 OCS 2007 將 CSTA 要求路由到 SIP/CSTA 閘道。第三步是設定 RCC 的使用者。第四個步驟是設定 Office Communicator 2007。第五個步驟是定義 OCS 2007 正規化規則，這些規則也用於通訊錄電話號碼正規化，但與搭配 Enterprise Voice 使用的電話號碼正規化規則不同。

Enterprise Voice
當使用者使用 Enterprise Voice 時，Office Communicator 2007 或 Office Communicator Phone Edition 遂取代 PBX 電話成為他的主要電話。Office Communicator 2007 會獲得一個指定的專屬電話號碼 (您可以將現有的 PBX 電話轉接到指定給 Office Communicator 2007 的新分機，作為測試用途)。Office Communicator 2007 與建議的 USB 音訊裝置兩者搭配使用，可同時處理呼叫控制 (或訊號) 和媒體 (音訊和視訊)。
在這個案例當中，Office Communications Server 2007 會路由 IP 網路上 Office Communicator 2007 端點間的電話 (IP-IP 呼叫)，並且將電話路由到公用交換電話網路 (PSTN)/PBX (IP-PSTN 呼叫)。OCS 2007 會對路由到 PSTN 的電話強制實施撥號限制。
如果您要將 Office Communications Server 2007 環境連接到 PBX 或 PSTN，必須部署媒體閘道 (又稱為 SIP/PSTN 或 IP/PSTN 閘道)。而媒體閘道必須搭配中繼伺服器 (OCS 2007 的伺服器角色)，才能連接到 Office Communications Server 2007 環境，如 [圖 1] 所示。因此最好將中繼伺服器和相關媒體閘道安裝在同一個實體位置上。
[圖 2] Enterprise Voice 與 PSTN 或現有 PBX 的整合案例
[圖 2] Enterprise Voice 與 PSTN 或現有 PBX 的整合案例
您可以透過中繼伺服器，連接媒體閘道來支援使用 Office Communications Server 2007 實作的標準 (甚至是不安全) SIP，因為 OCS 2007 只容許經過驗證和加密的通訊。中繼伺服器的另外一項工作是處理標準轉碼器 (G.711、G.723 等等) 與 Microsoft 即時音訊轉碼器之間的轉碼器轉譯。如需 Office Communications Server 2007 所支援的媒體閘道清單，請參閱策略硬體合作夥伴，網址是 technet.microsoft.com/bb735838。
您可以將媒體閘道直接連接到 PSTN，或是直接連接到現有 PBX 的 Primary Rate Interface (PRI) 中繼連線。[圖 2] 就是 Enterprise Voice 與 PSTN 和現有 PBX 案例的可能整合案例。部署 Enterprise Voice 並不需要 Director (通常是 Office Communications Server Standard Edition 伺服器)，不過還是建議使用。
啟用 Enterprise Voice 需要四個步驟：第一步是部署和設定媒體閘道。由於這是 Microsoft 合作夥伴產品，最好能夠參閱廠商的說明文件，因為每個媒體閘道的部署步驟不盡相同。
接下來是為每個媒體閘道部署中繼伺服器。在這個步驟中，您必須為中繼伺服器設定一張網路卡，來收發媒體閘道的流量，再為中繼伺服器設定另一張網路卡來收發 Office Communications Server 2007 的流量 (一般是 Enterprise Edition 部署中的 Director)。除非媒體閘道是進階閘道，否則還是需要 OCS 2007 中繼伺服器角色的協助，才能與 OCS 2007 Enterprise Voice 基礎結構交互操作。
第三步是定義號碼對應表。這個步驟包括定義語音原則、電話路由和位置設定檔。
之後就是設定 Enterprise Voice 的使用者。除此之外，還必須啟用 Enterprise Voice 的使用者，讓他們能夠從 PBX 或 PSTN 撥打或接聽電話，因此必須為每位使用者指派專屬的電話號碼。

Enterprise Voice 與 PBX 整合
這項設定是 Enterprise Voice 設定的延伸，差別在於使用者的 PBX 電話會與使用者的 Office Communicator 用戶端同步處理。這項設定與透過 PBX 連接到 PSTN 的 Enterprise Voice 案例雷同，如 [圖 2] 所示。不過此處並未以 Office Communicator 2007 用戶端取代使用者的 PBX 電話，Office Communicator 2007 和現有的 PBX 電話都是使用相同的電話號碼。
如果發話方從另外一支 PBX 電話或從 PSTN 電話撥打使用者的分機，PBX 系統會透過 Office Communications Server 2007，將電話分接到使用者的 PBX 電話和使用者的 Office Communicator 2007 用戶端。每當有來電時，使用者的 Office Communicator 2007 用戶端和 PBX 電話就會同時響鈴。相反的，Office Communications Server 則會把 OCS 2007 發出的電話，透過媒體閘道分接到 PBX。不過這種情況在使用 Office Communicator Phone Edition 時不可能發生，因為這種設定需要由 PBX 的語音信箱系統來處理語音信箱。因此遇到這類使用者，就不能把 Exchange Server 2007 整合通訊作為語音信箱解決方案。
啟用 Enterprise Voice 與 PBX 整合的步驟，與部署 Enterprise Voice 相同，只是另外多了三個步驟。第一個是必須將媒體閘道直接連接到 PBX，第二個是必須設定 PBX 來支援這個案例 (這可能得根據廠商而升級 PBX 的軟體)。最後一個是必須啟用使用者進行 PBX 整合。
Microsoft 正努力提供支援，希望能夠在不需要媒體閘道的媒介情況下，將中繼伺服器直接連接到 IP PBX。有關這個主題的最新資訊，請參閱 technet.microsoft.com/bb735838。

設定 Office Communications Server
Enterprise Voice 功能是由在 Office Communications Server 2007 Enterprise Edition 和 Office Communications Server 2007 Standard Edition 執行的服務所控制。[圖 3] 說明提供 Enterprise Voice 功能來路由發話和受話的服務
Figure 3 Enterprise Voice 服務 (Close Figure 3)

服務 | 描述
轉譯服務 | 根據位置設定檔或電話內容套用正規化規則。
使用者服務 | 對目標電話號碼執行反向號碼查詢。
輸入路由元件 | 套用目標使用者的撥號喜好設定。
Exchange 整合通訊 | 必要時將要求轉接到語音信箱。
輸出路由元件 | 根據 URI 和使用者原則判斷最佳路由。
[圖 4] 舉例說明了當中各個元件在經過 OCS 2007 路由進行電腦對電腦呼叫時，在來電上的運作方式。來電可以發自連線的端點，例如 Office Communicator 2007 或 Office Communicator Phone Edition，或是發自 PSTN/PBX 的中繼伺服器 (PSTN-SIP 呼叫)。從其中一個發話方的 Office Communicator 2007 用戶端或端點 (例如 Office Communicator 2007) 所撥出的電話，會傳送到 Standard Edition Server 或使用者所屬的 Enterprise Pool，這就是使用者的主集區。
[圖 4] OCS 前端伺服器上 Enterprise Voice 相關 服務的互動
[圖 4] OCS 前端伺服器上 Enterprise Voice 相關 服務的互動
此時，Office Communications Server 2007 會處理來電來判斷它的路由目的地。下一個躍點可以是連到受話方的主集區、中繼伺服器，或是 Microsoft® Exchange Server 2007 整合通訊 (見 [圖 5])。如果來電是路由到其他主集區，則 OCS 2007 會將該電話傳送到受話方所有作用中的端點。而受話方的 Office Communicator 2007 或 Office Communicator Phone Edition 會響鈴，並且裝置上會出現一個快顯視窗通知。
[圖 5] 來電路由
[圖 5] 來電路由
如果來電是路由到中繼伺服器，則會設定伺服器以路由到特定的媒體閘道。如果媒體閘道是直接連接到 PBX，那麼該來電便會由 PBX 路由到有線電話或 PSTN。不過，如果媒體閘道是直接連接到 PSTN，來電便向外轉到 PSTN。
如果下一個躍點是連到 Exchange Server 2007 整合通訊，則發話方可以留言。無論受話方是否登入 Office Communications Server 2007，都可以使用語音信箱。
當受話方接聽時，會以 IP 對 IP 呼叫的方式，直接將音訊從發話方的 Office Communicator 2007 或 Office Communicator Phone Edition，傳送到受話方的 Office Communicator 2007 或 Office Communicator Phone Edition。如果發話方是使用 PBX 或 PSTN 電話，那麼中繼伺服器便會將音訊流量，以 IP 對 PSTN 呼叫的方式，直接傳送到受話方的 Office Communicator 2007 或 Office Communicator Phone Edition。OCS 2007 只會處理通話訊號，這也正是音訊和視訊直接在端點之間行進而不經過 OCS 2007 路由的原因。

設定使用者
對於啟用 Enterprise Voice 的使用者，必須指派在組織內是獨一無二的電話號碼。這項設定是在 Active Directory ® 中完成。跟大多數電話語音系統不同的是，它會指派電話號碼給電話。這種設計的好處是，使用者可以將任何執行 Office Communicator 2007 的電腦轉換成他們的公司電話，只要從用戶端登入 OCS 2007 就成了。這種可攜性功能可能很吸引電信通訊者或外勤員工。
使用者的電話號碼是在 Active Directory 中以 E.164 格式來指定。這個格式會定義國際公用電信號碼對應表，而這種撥號配置可獨一無二且清楚地表示電話號碼。E.164 格式便是以這種格式指定電話號碼。
+<country code><area code><phone number>
啟用 Enterprise Voice 的使用者有兩種獨特的表示法：SIP URI 和 E.164 電話號碼。撥打電話號碼時，Office Communications Server 會將電話號碼的 E.164 表示法 (+14255551212) 解析成使用者的 SIP URI (joe@contoso.com)。Office Communications Server 2007 接著會根據受話方的 SIP URI 來路由該來電。如果電話號碼無法解析成 SIP URI，OCS 2007 會透過中繼伺服器將來電向外路由到 PBX/PSTN。
如果您是在每位 Office Communicator Server 使用者都必須分配到專屬電話號碼的情況下規劃 Enterprise Voice 部署，必須將現有的電話語音系統列入考量。如果您是直接透過媒體閘道連接到 PSTN，則很可能有整個號碼區塊含 2 或 3 位數分機的直接撥打內線 (Direct-Inward-Dialing，DID) 號碼，可以散發給 OCS 2007 使用者。如果您是經由 PBX 連接到 PSTN，PBX 可能會提供一組 DID 號碼，讓您指派給 OCS 2007 使用者。

號碼對應表
即使 E.164 格式的電話號碼有提供獨特的表示法，但撥號還是不太方便。在 Office Communicator Phone Edition 或標準 PBX/PSTN 電話裡面也不可能輸入這種格式的號碼。使用 10 位數的撥號盤要如何指定 + 字元呢？使用者習慣撥打簡短的分機號碼，這個號碼在某個地點也許是專屬號碼，但對整個公司就不見得了。因此您必須指定轉譯規則，將它們轉換成 E.164 格式。
系統管理員必須定義位置設定檔，指定正規化規則來執行這些號碼轉譯。當用戶端 (Office Communicator 2007 或 Communicator Phone Edition) 或 Office Communications Server 2007 的轉譯服務將電話號碼延伸為 E.164 格式之後，使用者服務就會執行反向號碼查詢，並將 E.164 號碼對應到相對應的 SIP URI。如果找到符合的項目，位置設定檔中所定義的正規化規則，便會使用規則運算式來執行轉譯。比方說，如果您撥 1234，則符合任何四位數模式以轉譯成 +1425555{4 位數} 的正規化作業，便會將 1234 轉譯成 +1425551234。位置設定檔因此能讓使用者保有他們所熟悉的撥號習慣。
系統管理員可以透過下列三種方式，指派位置設定檔給使用者：
  • 透過群組原則，定義位置設定檔給使用 Office Communicator 2007 的使用者。
  • 容許使用者從 Office Communicator Phone Edition 選擇位置設定檔。
  • 指派位置設定檔到主集區。該位置設定檔便會自動指派給屬於該集區的使用者。
定義號碼對應表的動作，包括使用正規化規則建立語音原則、電話路由和位置設定檔。語音原則是定義容許的電話存取使用者類型。Office Communications Server 2007 會透過電話路由的方式，判斷如何將來電路由到 PBX/PSTN。由於撥號方式眾多，所以位置設定檔的正規化規則，會定義如何將撥出的電話號碼轉譯成 E.164 格式，然後再進行路由。
系統管理員會將啟用 Enterprise Voice 的各個使用者與語音原則建立關聯。語音原則負責定義指派給使用者的通話權限，而通話權限負責判斷使用者可以使用哪些路由，以及使用者可以撥打哪些號碼。每位使用者都必須與單一語音原則相關聯，而可用的原則數量則由系統管理員建立。
每個語音原則都包含一個容許或禁止使用者啟用同時響鈴的設定，以及一份排好順序的電話使用方式清單。語音原則類似於會議原則，都是內含設定的邏輯容器，定義成存放在 Active Directory 中的 XML 文件。這種設計的價值在於，它不需要延伸 Active Directory 結構描述，就可以在 OCS 2007 的未來版本進行擴充以支援其他原則設定。比方說，如果語音原則不與任何電話使用方式相關聯，這就會影響到指派給該原則的使用者，使他們無法發話給 PBX/PSTN。這類使用者只能進行 IP-IP 呼叫。

電話使用方式和路由
電話使用方式負責定義使用者所容許的電話路由權限。電話使用方式是電話路由的集合，它是一個字串，而且必須是專屬關鍵字，換句話說，沒有其他電話使用方式可以擁有相同的名稱，但系統管理員要建立幾個使用方式都可以。
雖然語音原則可以直接與路由或一組路由相關聯，而不與電話使用方式關聯，但電話使用方式關鍵字卻是維護原則和路由之間的抽象層。如果原則直接與路由相關聯，實際上等於推翻了電話使用方式的概念，因此當系統管理員修改路由的名稱時，就必須更新每個與路由相關的原則。如果透過使用電話使用方式 (此為原則和路由兩者可在原則和路由之間建立關聯的特性)，即使變更路由的名稱，仍可保有原則和路由之間的關係。
路由當中包含了電話號碼模式和連接到媒體閘道的中繼伺服器清單。路由至少必須指派一個電話使用方式，而模式和閘道之間的這個關聯，會指定如何路由符合特定模式的電話號碼，
而模式會指定它可以對應的電話號碼範圍。它是定義成規則運算式，當中可能包含也可能不含電話號碼。為了幫助您更輕鬆的建立這些規則運算式，其中也包含了 Enterprise Voice Route Helper 工具。如此一來，要是撥打的電話號碼與路由的規則運算式模式相符，就會將來電路由到在路由中定義的其中一個閘道。
一個路由可以列出一部以上的中繼伺服器 (也包括媒體閘道在內)。Office Communications Server 2007 會以循環配置的方式將來電路由到中繼伺服器，來平衡閘道間的流量。如果閘道失敗或者因為維護之故而暫停服務，對應的中繼伺服器會傳送回應給 Office Communications Server 2007，而 Office Communications Server 2007 也會立即將來電路由到路由清單上的其他中繼伺服器 (也路由到不同的媒體閘道)。
如果來電路由到媒體閘道的失敗次數超過 10 次，Office Communications Server 2007 便會配合媒體閘道縮小流量，直到該閘道有所回應為止。萬一媒體閘道在另外經過 10 次失敗之後還是無法回應，Office Communications Server 2007 便不再將來電路由到該媒體閘道，除非它有回應。
電話路由中所定義的媒體閘道清單，是由閘道的完整網域名稱和連接埠號碼定義而成。如果電話號碼與規則運算式模式不符，便會檢查與指派給使用者之電話使用方式相關聯的下一個路由，直到找到符合項目為止。如果找不到符合項目，就無法路由來電，也無法送達目的地，這時候使用者就會收到通知，告訴他通話無法完成。

下一步
Office Communications Server 2007 提供了三種等級的電話語音整合。在規劃電話語音部署時，您必須先判斷哪一種等級最符合您當前和未來的電話語音商務需要，一旦確定之後，就可以規劃部署。在規劃部署時，定義 Office Communications Server Enterprise Voice 部署的號碼對應表是相當重要的一環，一定要謹慎考量。
有關 Office Communications Server 2007 Enterprise Voice 及相關技術的詳細資訊，請參閱「其他 OCS 2007 資源」資訊看板。

Jochen Kunert 在電訊產業已有 10 年的經驗，目前正於 Microsoft 擔任 Office Communications 小組的資深專案經理。他是即將出版的《Microsoft Office Communications Server 2007 Resource Kit》一書的作者之一。您可以透過電子郵件與 Jochen 聯絡：jkunert@microsoft.com。
Rui Maximo 是在 IT 產業擁有 14 年經驗的老手，他合著了兩本書：《Pro LCS:Live Communications Server Administration》和《Microsoft Office Communications Server 2007 Resource Kit》。您可以透過電子郵件與 Rui 聯絡：ruim@ruimaximo.com。


 高效能運算: Windows Compute Cluster Server 簡介
高效能運算 John Kelbley and Doug Lindsey

Windows Compute Cluster Server 簡介
摘要:
  • 運用叢集解決複雜問題
  • 運算叢集的一般需求
  • 設定 Windows 架構運算叢集
  • 遠端執行命令

高效能運算 (HPC) 是指集中一部份的應用運算能力，專門用來解決耗用大量運算資源的問題。多年前，HPC (更常被稱為「超級運算能力」) 通常是以
特製大型 (昂貴) 系統為主，而這些系統多半都屬於研究中心所有。不過，隨著小型系統的運算能力日益增強，成本/效能比也跟著改變，而運算工作負載逐漸移往個人電腦等級的系統。
許多耗用大量運算資源的問題都可以經由平行計算的方式獲得解決；也就是說，特定的計算或作業不見得要依靠其他計算或作業的輸出結果來完成。在這種情況下，龐雜的問題可以利用組合成運算叢集的多個小型系統 (節點)。以下試舉出幾個例子來說明能夠利用運算叢集的各種應用程式：
  • 財務模型 — 個別演算法或公式會執行上千次，且每次都具有不同的輸出。
  • 工程 — 模擬各個組件的效果，並在模型上套用材質。
  • 電腦動畫 — 對影片的每個畫面套用材質與光源效果。
運算叢集提供符合經濟效益的方式，在短時間內解決複雜的問題。在本文中您將看到，Microsoft 所推出的 Windows® Compute Cluster Server 2003 可提供關鍵的運算叢集功能與支援。
有一點您必須了解，那就是運算叢集與可用性 (容錯移轉) 叢集是不同的。您可能很熟悉 Exchange、SQL Server® 或 Windows Server® 2003 中的其他應用程式所使用的可用性叢集。這些叢集通常是運用共用存放裝置來達到最長的應用程式執行時間。不過運算叢集的用意並非是在中斷時延續另一個系統的工作，而是讓所有節點都能協力運作。

運算叢集的一般需求
HCP 資源
  • Windows HPC 社群
  • WCCS 2003 的高效能運算
  • Microsoft 64 位元運算概觀
  • Microsoft 伺服器首頁
  • Compute Cluster Server TechCenter
  • 高效能運算叢集部署的逐步安裝、設定及微調指南

現代的 HPC 系統都具有一些共通的特性，以便協助處理工作負載。簡單來說，您需要的系統不只一部，另外還需要排程器來協調各個節點間的工作指派。排程器會在主導的節點 (主節點) 上執行，識別可用的資源，指派和分配工作，同時追蹤整體的工作狀態。它可說是系統叢集中各項資源的協調者，而且也是使用者與系統管理員提交處理工作的目標。
叢集需要透過某種方式在節點間進行通訊。視工作類型而定，節點可能需要高速且低延遲的互連機制來彼此傳送訊息以協調處理作業。各個運算節點與主節點至少都必須連線到一個共通的網路上。
在大量的互連系統協力運作來解決複雜問題的情況下，您也必須特別小心維護和保持傳輸狀態。您必須安排作業與工具來準備、監視、管理和維護成千上百的系統，這樣才能確保穩定一致的環境。
最後也是最重要的一點，系統中必須有應用程式能夠利用運算叢集的平行處理能力。如果沒有能夠細分工作好讓工作在多台電腦上執行的應用程式，或是缺少包含「平行偵錯工具」支援的開發工具，那麼所謂的叢集環境也只不過是徒佔電腦室的空間罷了。

Windows Server 架構叢集
為了滿足廣大的 HPC 應用程式需求，Microsoft 於 2006 年推出 Windows Server 2003 Compute Cluster Edition (CCE) 和 Windows Compute Cluster Server 2003 (WCCS)。CCE 和 WCCS 同樣都以您熟知的 Windows Server 2003 為基礎。CCE 是 Windows Server 2003 專為使用 HPC 應用程式而授權的版本。WCCS 與 CCE 相同，但另外還加上 Microsoft® Compute Cluster Pack (CCP)。這表示您可以透過原先用來管理現有 Windows Server 2003 系統的相同工具來部署、管理、監視及維護 Windows Server 架構叢集。
需要注意的是，CCE 和 WCCS 只有 x64 版本 — 這些產品並未提供 32 位元 (x86) 版本。CCE 與 WCCS 的硬體需求與 Windows Server 2003 x64 標準版的硬體需求一樣。除了支援高效能硬體 (64 位元架構) 以外，這些產品還包含高效能互連 (Gigabit Ethernet、InfiniBand、Myrinet 等等) 的遠端直接記憶體存取 (Remote Direct Memory Access，RDMA) 支援。

Compute Cluster Pack
如前所述，運算叢集的某些基本需求可以經由安裝 Compute Cluster Pack 來滿足。CCP 是獨立的安裝套件，其中包括：
  • 整合的工作排程器
  • 業界標準 MPICH2 的訊息傳送介面 (Messaging Passing Interface，MPI) 支援
  • 叢集資源管理和使用者工具
CCE 與 WCCS 之間的關鍵區別正是 CCP。您可能覺得奇怪，運算叢集需要這些元件，但這些元件只包含在 WCCS 而未包含在 CCE 中。原因是某些 HPC 解決方案會使用不同的工作排程器或特製 MPI (或者不需要 MPI 支援)，而且只需要在一流的平台上執行 — 也就是 Windows Server 2003。由於 CCP 是獨立套件，您可以在其他 x64 版本的 Windows Server 2003 (CCE、標準版、標準版 R2、企業版及企業版 R2) 上安裝。

具體細節
WCCS 採納主要的 Windows 基本概念 (包括 Active Directory® 和遠端安裝服務 (RIS)) 來簡化 Windows 架構叢集的管理與操作工作。Compute Cluster Server 使用 Active Directory 以明確地管理安全性。藉由 Active Directory，使用者可以將工作提交給主節點 — 使用單一的認證組合，而這個工作可以在數百個伺服器節點上執行。當工作在一或多個運算節點上執行時，是在工作提交時所提供之使用者認證的路徑位置中執行，並就此進行安全快取。WCCS 憑藉 Active Directory 來提供這樣的「單點登入」功能。環境裡面擁有 Active Directory 的另一項好處是，可以透過群組原則來集中管理伺服器與設定原則。
如果您的 IT 組織已經部署 Active Directory，您可以在現有網域中建置叢集來省下大量的時間與系統管理工作。這是建議的做法。
如果您需要在沒有 Active Directory 的環境中部署運算叢集，那麼建議您部署一或多個專用網域控制站來為叢集裝載 Active Directory。將主節點當做 Active Directory 網域控制站的情況並不稀奇，因為無論網路拓撲為何，所有節點都已經具備連接系統的網路。然而，考量到主節點的負載增加，並不建議在大規模叢集中將主節點當做網域控制站。而是應該要遵循 Active Directory 部署與管理的常見做法 (安裝備援網域控制站、適當備份、良好的安全性實務等等)。

遠端安裝服務
WCCS 專為 Microsoft 遠端安裝服務映像部署平台提供整合式前端。RIS 可用來從主節點部署作業系統映像到各個運算節點，換句話說，您可以使用 RIS 來快速安裝新的叢集節點。您不一定要採取這種方式 — 與 WCCS 整合的 RIS 只是為了方便您使用而提供。您也可以使用其他常見的 Windows Server 部署技術，例如 Windows Server 2003 Automated Deployment Services (ADS) 或手動安裝 Windows Server 2003。
若您要使用 RIS，請在主節點上安裝 CCP 之前，先確認至少已有定義兩個邏輯磁碟。RIS 需要一個與作業系統分開的磁碟來存放伺服器映像。您的 RIS 磁碟分割應該具備足夠的可用磁碟空間來放置一或多個完整的 Windows Server 映像複本。
較新的伺服器硬體 (尤其是網路與儲存導向的硬體) 所需的隨插即用驅動程式，可能不包含在預設 Window Server 2003 映像中。此時，您就必須手動將這些驅動程式加入到映像中。您可以在以下網站找到說明此作業程序的文件：support.microsoft.com/kb/254078。

安裝叢集
第一個步驟是設定叢集的首腦 — 主節點。首先要安裝之前提到的 x64 版本的 Windows Server 2003。在安裝作業系統的過程中，您得選擇是要讓伺服器加入現有網域 (建議做法)，還是要在伺服器上安裝 Active Directory (不建議大規模叢集這麼做)。
安裝作業系統之後，確保您已經下載並安裝 Microsoft Update 建議的所有修正程式。若您打算使用 RIS 來處理運算節點映像，就必須使用 [電腦管理] | [磁碟管理] 系統管理工具來確定至少已定義兩個邏輯磁碟。由於篇幅有限，本文就不在此討論以 RIS 為主的安裝。
當您成功登入和更新伺服器之後，將會執行 CCP 安裝程式。CCP 安裝程式會安裝或指引您完成下載和安裝下列必備檔案及更新：
  • RIS Hotfix (請參閱 go.microsoft.com/fwlink/?linkid=55167)
  • Microsoft Management Console (MMC) 3.0 (請參閱 go.microsoft.com/fwlink/?linkid=62400)
  • SQL Server Desktop Edition，當做 Compute Cluster Server 2003 主節點安裝程序的一部份來安裝
  • Microsoft .NET Framework 2.0
CCP 安裝程式能夠出色地評估您的系統是否做好安裝準備。它會讓您知道在執行安裝作業中需要使用及安裝哪些元件，並安裝這些元件，如 [圖 1] 所示。
[圖 1] CCP 安裝的必要元件
[圖 1] CCP 安裝的必要元件

待辦清單
當 CCP 安裝程式完成時，便會啟動系統管理員主控台，並將焦點放在待辦清單上。如 [圖 2] 所示，待辦清單包含多個窗格，分別處理不同部分，並列出完成叢集設定所需的關鍵任務。
[圖 2] 待辦清單中顯示設定叢集所需的任務
[圖 2] 待辦清單中顯示設定叢集所需的任務
待辦清單可讓您輕鬆地實作您所規畫的架構，包括選取和設定網路拓撲、節點安裝程序以及使用者管理模型。每個窗格的任務都列在右邊，而且各項任務都會啟動精靈。依序完成每項任務以便完全設定主節點，好讓主節點將 RIS 映像部署到已知的運算節點集合上，並讓定義好的使用者組合能夠管理和存取主節點。
網路拓撲 WCCS 支援 HPC 中最常使用的五種網路拓撲。所有運算節點與主節點至少都必須共用一個共通網路。這些拓撲支援在節點間有多種互連類型，並具有各自的優點與成本。
您的網路拓撲會取決於叢集的效能、安全性和部署需求。譬如說，針對不想要在企業網路上公開的訊息，您的應用程式可能需要高速互連機制來傳送這些訊息。或者您想要使用以 RIS 為主的整合式自動部署功能。或許您選擇的硬體只能容納單一 NIC，又或者您可能希望主節點執行網際網路連線共用 (ICS) 來管理運算節點的名稱解析和定址。從待辦清單啟動的「設定叢集網路拓撲 (Configure Cluster Network Topology)」精靈會提供一般 HPC 實作支援的五種常見拓撲，並協助您設定網路連線，包括主節點和運算節點上的 Windows 防火牆設定。[圖 3] 顯示其中一種支援的網路拓撲。
[圖 3] 其中一種支援的 WCCS 網路拓撲
[圖 3] 其中一種支援的 WCCS 網路拓撲
遠端安裝服務 如前所述，RIS 會啟用叢集節點的自動部署。
節點管理 您能夠指定在此叢集中當做運算節點之伺服器的電腦名稱。在節點上執行 CCP 時，節點所要加入的叢集主節點也是在此時指定。
使用者管理 您可以在此指定要將哪個 Active Directory 使用者帳戶或群組指派為系統管理員和叢集的使用者。

安裝節點
運算節點的部署可以經由 RIS 系統管理公用程式來自動完成，也可以使用其他受支援的部署方法。就像主節點，CCP 也必須安裝各個運算節點上。如 [圖 4] 所示，運算節點的 CCP 安裝設定選項更為簡單，其中包含以下項目：
[圖 4] Compute Cluster Pack 安裝
[圖 4] Compute Cluster Pack 安裝
  • 指定伺服器必須是運算節點 (非主節點)。
  • 指定伺服器要加入的叢集的主節點名稱。
  • 指定是否要在運算節點上安裝系統管理與使用者工具。

系統管理員主控台
當您的節點與主節點開始通訊後，所有系統的管理和系統管理工作大多可以透過系統管理員主控台來完成，如 [圖 5] 所示。此主控台為整個叢集提供一種集中檢視的機制，內含所有相關節點的清單、重要系統管理動作的存取以及其他詳細資料。最左邊的窗格提供主控台的高階層巡覽，包括「叢集系統管理員」的存取，當您反白顯示叢集系統管理員時，便會出現顯示叢集狀態與工作統計資料的摘要畫面。此外，所有遠端桌面和系統監視器工作階段的存取都可以在此進行，但是您在叢集管理部分所花的時間將以「節點管理」為主。
[圖 5] 系統管理員主控台提供整體叢集檢視
[圖 5] 系統管理員主控台提供整體叢集檢視
您應該自行探索系統管理員主控台，因為在此可以存取集中管理 Windows 與叢集節點所需的主要工具和功能。按一下上半部的中間窗格將填入其他幾個視窗，您可以據此探究節點特定的功能。
按右鍵功能表支援的功能方便您輕鬆地從節點管理來集中管理運算節點。您可以使用節點管理來暫停和繼續節點；在叢集間核准或移除節點；啟動遠端桌面、系統監視器或甚至是檢視器；或是退出光碟托盤 (當您想在大型叢集中實際辨別出單一機器時，這個功能就很有用)。

酷炫的 ClusRun
在這份清單中有一個超酷的功能，那就是「執行命令」，這項功能可以從遠端任意執行任何命令，彷彿您就在目標機器上使用命令提示字元一樣。WCCS 包含命令列版本的「執行命令」功能，稱為 Clusrun.exe，此「ClusRun」可同時用來表示 GUI 與命令列版本。
ClusRun 的公用程式的優點一言難盡 — 在大型叢集上尤其明顯。對於執行重複性高的命令列工作來說，ClusRun 可以節省很多時間，而且往往能夠避免撰寫更複雜的系統管理指令碼。
若要使用此功能，請針對您要執行命令的機器反白顯示這些機器清單，然後按一下滑鼠右鍵，再選取 [執行命令]。[圖 6] 中的對話方塊便會出現。現在只要輸入所要的命令，按一下 [執行]，並等待 [結果] 視窗顯示輸出即可。第一次使用 ClusRun 時會出現要求認證的提示，不過您可以選擇快取這些認證以供後續重複使用。
[圖 6] 您可以在多個節點上執行命令。
[圖 6] 您可以在多個節點上執行命令。
修補叢集或安裝包含自動安裝常式的程式常用的方法是，將它們放置在檔案共用中，然後使用 ClusRun 來強制所有運算節點叫用該命令。利用單一命令就可以重新啟動整個叢集中的所有運算節點：
CLUSRUN SHUTDOWN –R –F –T 0

工具組
HPC 小組在 2007 年 5 月發行了 Compute Cluster Pack 工具組 (您可從以下網站取得：windowshpc.net/resources/Pages/default.aspx)。這個工具組包含 Windows PowerShellTM 的支援、用來診斷連線健康狀況的 MPIPingPong 工具，以及一個簡單卻好用的圖形化叢集監視器。
如 [圖 7] 所示，簡易叢集監視器 (Simple Cluster Monitor) 可以在單一畫面上顯示叢集中的每個節點、各個節點擁有的核心數量、每顆 CPU 的使用率 (以鮮綠色表示)、記憶體使用率 (黃色)、磁碟時間百分比 (紅色)，以及網路頻寬使用率 (橘色)。系統管理員只要執行這個超棒的工具，對叢集的運作狀況就可以一目了然。
[圖 7] 使用簡易叢集監視器 (Simple Cluster Monitor) 監視多個節點
[圖 7] 使用簡易叢集監視器 (Simple Cluster Monitor) 監視多個節點
這個叢集監視器也包含「可遠端操控」功能。您必須在主節點上執行叢集監視器的第一個執行個體。不過，如果您在主節點的主控台工作階段中執行叢集的執行個體，就有機會從工作站啟動叢集的執行個體，在主節點指向這些執行個體，然後取得相同的顯示畫面。

還等什麼？
您現在已經獲得 HPC 與 Windows Server 2003 Compute Cluster Server 的相關知識，也懂得如何安裝 CCP，您已經見識到全方位的超強主控台，能夠使用一些酷炫的新命令，還有一些圖形化工具能向同事及使用者炫耀。您可以在「HPC 資源」資訊看板找到更多有關高效能運算的資訊來源。

John Kelbley 在 Microsoft 以美國東北部為據點的全球解決方案技術小組 (Global Solutions Technology Team) 擔任技術產品經理。您可以透過電子郵件與 John 聯絡：Johnkel@microsoft.com
Doug Lindsey 是 Microsoft HPC 小組的專案經理，同時也負責管理生產運算叢集 (名列 www.top500.org 的 2007 年 11 月名單的第 116 名)。您可以透過電子郵件與 Doug 聯絡：Dougli@microsoft.com。


 線上特刊: 透過終端機服務部署 2007 Office System
線上特刊 James D. Silliman

透過終端機服務部署 2007 Office System
摘要:
  • 2007 Office System 的部署
  • 管理使用者設定
  • 全新的快速存取工具列
  • 2007 Office System 的自訂工具

在終端機服務伺服陣列裡部署 2007 Microsoft Office System 或從舊版升級之前，您應該先了解它在設計上的重要變更。您必須熟悉通用範本、快速存取工具列、
用於群組原則的 .adm 檔案嵌入式管理單元，以及 Office 自訂工具 (OCT)。事先了解所有這些工具，將使得部署作業更加順暢。讓我們先看看 Microsoft® Word 來了解一些比較顯著的變更。

部署 Word 2007
Word 向來都是使用通用範本檔案，而這個檔案在 2007 Office System 中稱為 normal.dotm。在終端機服務的環境中，部署 Word 和 normal.dotm 檔案有三種不同的方法。您可以把這個檔案留在所有裝有 Office 的終端機服務伺服器上，好讓使用者看到標準的 Word 預設檢視。若不想讓使用者使用 Word 裡面的預設檢視，您可以在每部終端機伺服器上開啟這個檔案，自行進行修改、自訂。或者您可以將這個檔案徹底重新命名，讓使用者擁有自己的檔案 (使用者在 Word 裡面變更設定並按下 [預設] 時就可以修改)。
無論選擇怎麼做，最好是在部署之前做好決定。如果您不對預設值做任何變更，使用者便無法儲存他們的通用範本變更，因為位於終端機服務伺服器上的通用範本檔案會覆寫他們個別設定檔中的檔案。假如您不開啟範本檔案做些修改，Word 2007 就只會對使用者呈現預設設定。
真要的話，倒是可以在終端機服務伺服陣列中的每部伺服器上修改檔案。若要採取這種做法，並為每名使用者保有相同的 Word 設定 (例如預設字型和大小、段落間距和配置)，就必須將這個通用範本檔案留在它預設的路徑位置。然後若要修改希望全域部署到使用者的設定，只要在每部終端機服務的電腦上開啟這個檔案，在 Word 2007 配置 (按一下 [預設]) 中進行所要的變更然後存檔，再把變更往外寫入預設的 normal.dotm 檔案就可以了。
在進行任何變更前，記得先備份預設檔案，否則您可能為了擷取原始檔案而需要重新安裝 Word 2007。要注意的是，如果您在修改 normal.dotm 檔案時對快速存取工具列進行任何變更的話，這些變更將不會儲存到範本檔案中。我稍後會說明快速存取工具列及它的行為模式。
要是您決定使用者應該在 Word 裡面管理自己的通用設定該怎麼辦？他們可以這麼做，但是您必須在伺服陣列中的所有伺服器上，將 normal.dotm 檔案重新命名成像 normal.dotm.old 之類的名稱。這是我建議的最佳作法，因為使用者在關閉 Word 時，如果有其他應用程式與檔案相連，可能會收到範本錯誤。
如果您重新命名這個檔案，Word 2007 就知道您希望讓使用者管理他們自己的喜好設定，而不採用通用喜好設定，藉此容許他們修改和儲存自己的設定。Word 2007 現在是把自訂的 normal.dotm 檔案放置在每個使用者的設定檔案路徑中。如果您使用漫遊設定檔 (根據您設定路徑的方式而定)，則範本檔案會存放在每名使用者的這個資料夾位置內：\\domain\sharename\%username%\Application Data\Microsoft\Templates。
有個使用者喜好設定並不會儲存在 normal.dotm 檔案中，那就是對快速存取工具列所作的任何變更。這個工具列是 2007 Office System 的新功能，與主要的功能區工具列 (這也是新功能) 不同。快速存取工具列預設是位於 2007 Office System 的畫面左上角的小型工具列。這個工具列是為了 2007 Office System 內的應用程式而存在，如 [圖 1] 所示。如需詳細資訊，請參閱 support.microsoft.com/kb/926805。
Figure 1 快速存取工具列檔案 (Close Figure 1)

Office 應用程式 | 功能區 | 檔案名稱
Access 2007 | 全部 | Access.qat
Excel 2007 | 全部 | Excel.qat
Outlook 2007 | 連絡人、行事曆、通訊群組清單、日誌項目、郵件、貼入資料夾、工作 | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | 全部 | PowerPoint.qat
Word 2007 | 全部 | Word.qat
您在 [圖 1] 中可以看到，快速存取工具列使用 .qat 副檔名的檔案來儲存個人化設定。這個檔案是放在伺服陣列中每部終端機服務伺服器上的預設檔案路徑位置，而且它們不會漫遊：C:\Documents and Settings\<username>\Local Setting\Application Data\Microsoft\Office (在執行 Windows Vista® 的電腦上則是 C:\Users\username\AppData\Local\Microsoft\Office)。
如果您仔細看看路徑，就會發現 .qat 檔案是位在終端機服務使用者的本機快取設定檔的 [本機設定] 子資料夾下。這個子資料夾並不會與使用者的漫遊設定檔在登出時同步處理，因為標準的漫遊設定檔路徑結構中並沒有本機設定。因此，很不幸的是，如果您因為啟用這個群組原則物件 (GPO) 設定而弄丟終端機服務伺服器上本機快取的設定檔，您將會遺失使用者自訂的 .qat 檔案 (如需詳細資訊，請參閱微軟知識庫文件，網址是 support.microsoft.com/kb/274152)。
事實上，透過刪除快取的設定檔，在使用者登出時進行本機設定檔的大掃除是終端機服務系統管理員間廣為流傳的作法，所以這項變更在 2007 Office System 裡面的影響深遠，因為它適用於快取設定檔和快速存取工具列。其中一個明顯的解決方案，是確定您沒有設定我剛剛提到的知識庫文件內所述的 GPO 設定。如果您禁止在登出時刪除快取設定檔，同時又擁有許多使用者，這將在每部終端機服務伺服器的本機 %systemroot% 磁碟機上耗用寶貴的硬碟空間，而且必須設立其他一些程序來留意它的一舉一動，因為您伺服器有可能會耗盡硬碟空間。這種情況很常見，因為本機設定檔可能會變得相當大。
無論您採取哪種方法，都應該至少在登入指令碼中加入一個常式，定期備份使用者 .qat 檔案，以便在這個檔案消失或不慎遭到刪除時進行復原。為這些自訂檔案保留一份備份，就不必發狂地打電話給支援工程師要他們協助復原檔案。
備份這些本機快取設定檔的終端機服務系統管理員是少之又少，雖然他們都會備份網路漫遊設定檔，但是我之前有提到，這些檔案並不會保留 .qat 檔案的複本。另外一個替代方案是考慮採用協力廠商產品，讓您為每名使用者部署一個強制的設定檔，然後將每名使用者的本機設定變更對應到您網路上不同的資料夾裡面。

群組原則嵌入式管理單元
為了在 Office 2003 裡面更妥善管理控制 Office 原則和使用者體驗，群組原則 .adm 檔案的存在由來已久。同樣地，在 2007 Office System 中也有一些新的 .adm 檔案可用來進行各項自訂，包括停用 [首次執行] 對話方塊，以及修改自動儲存設定和其他喜好設定。
如果您已經部署 Office 2003 群組原則，並決定移轉到 2007 Office System，在新增 2007 Office System .adm 檔案之前，必須先將現有的 Office 2003 .adm 檔案從 GPO 中移除。記得使用群組原則管理主控台 (GPMC) 介面來備份 GPO，這樣一來，若是在加入新的嵌入式管理單元後發生錯誤，就可以進行復原。我知道至少有一名終端機服務系統管理員就曾碰過在移除 Office 2003 嵌入式管理單元，然後將 2007 Office System .adm 檔案加入他的 GPO 後，產生幽靈原則項目。
我在 2007 年 5 月份的《部署終端機服務指南》(technetmagazine.com/issues/2007/05/TerminalServices) 一文中提過，終端機服務使用者不應該收到要執行某些動作的提示，例如 Outlook® 自動封存，或是接受 [首次執行] 對話方塊畫面。要注意在預設的情況下，第一次啟動 Outlook 2007 時，會向使用者顯示兩個 [首次執行] 畫面：一個是 [隱私權選項]，第二個是 [桌面搜尋]。要停用 [圖 2] 中顯示的第一個畫面，有幾種不同的方法可以進行：透過修改 GPO 設定 (使用新的 Outlook 2007 .adm 檔案)、使用 Office 自訂工具，或是修改登錄。
[圖 2] 2007 Office System 中的隱私權選項對話方塊
[圖 2] 2007 Office System 中的隱私權選項對話方塊
[隱私權選項] (如果您沒有停用它的話) 之後會馬上出現 [圖 3] 所示的畫面，而且會顯示在所有其他 2007 Office System 應用程式中。
[圖 3] 2007 Office System 中的立即搜尋功能對話方塊
[圖 3] 2007 Office System 中的立即搜尋功能對話方塊
若要關閉 Office 應用程式的 Windows® 搜尋提示，請從 go.microsoft.com/fwlink/?LinkId=78161 下載 2007 Office System ADM 範本，然後將它們載入到您網域控制站上的硬碟中。在群組原則中，您必須將 Office Outlook 2007 範本 (Outlk12.adm) 載入到 [電腦設定] 或 [使用者設定] 的 [新增] 嵌入式管理單元裡面。接下來，前往 [使用者設定]\[系統管理範本]\[Microsoft Office Outlook 2007]\[工具] | [選項]\[喜好設定]\[搜尋選項]，然後啟用 [若沒有 Windows 桌面搜尋元件，不要顯示安裝提示] 設定。
2007 Office System 中有許多群組原則設定可以左右使用者體驗，但是您必須在 GPO 中加入個別的 .adm 檔案，例如分別加入 Word (Word12.adm) 和 Excel® (Excel12.adm)。[圖 4] 的範例顯示出將 Outlook 2007 ADM 範本 (Outlook12.adm) 加入群組原則後看起來的樣子。
[圖 4] 群組原則中的 Outlook 2007 ADM 範本
[圖 4] 群組原則中的 Outlook 2007 ADM 範本

其他變更
請注意，在 Office 2003 中您也可以下載和使用「自訂安裝精靈」來建立自訂轉換。2007 Office System 中全新的 OCT 並不需要另外再下載，從 [執行] 命令使用「Setup /admin」就可以啟動它，此命令會導向您的 2007 Office System 媒體或安裝來源。對安裝來源檔案執行此命令，然後視所需變更個別的設定，此舉會建立一個 .msp 檔案 (等於是 Office 2003 中的 .mst 檔案)，而且您之後進行部署時不需要指定任何命令列選項來包含它。只要將自訂的 .msp 檔案放在網路安裝點的根目錄的 [更新] 資料夾中，就可以隨著您慣用的設定自動部署它。
Outlook 2007 還有另一個優於舊版的優點：如果在 LAN 內部啟動的話，它還會自動找出您的 Exchange 2007 伺服器，將服務連線點 (SCP) 查詢直接傳送到 Active Directory®。這項查詢使得連接到已部署的 Exchange 2007 基礎結構更加簡單。如需詳細資訊，請參閱 go.microsoft.com/fwlink/?linkid=76177。
Microsoft 在設計方面做了一些重大的變更，透過簡化部署工具、加入新的 .adm 檔案嵌入式管理單元，以及使介面更有效率等方式，讓 2007 Office System 在終端機服務環境內順利運作。在您部署或升級 Office 應用程式之前，先了解一些我在此處討論的重要概念，相信您對升級作業將有更深入的了解，且有助於預先作出重要的設計決策。如果您目前還不打算升級，可以考慮載入 2007 Office System 相容性套件，讓您的使用者可以開啟已經升級的使用者寄給他們的附件。您可以在 go.microsoft.com/fwlink?LinkID=77512 找到相容性套件。
手邊有了這項資訊，您便能順利部署 2007 Office System。別忘了對使用者社群進行部署之前，先備份您的原則，並在實驗室環境中測試所有建議的設定。

James D. Silliman身為 MCSE，他是 Microsoft 方面的技術專家，擅長於終端機服務部署。他目前服務於 ASP，負責設計小型企業的 IT 解決方案架構。您可以透過電子郵件與他連絡：jsilliman@gmail.com。


 編輯的話: 面對資訊爆炸的時代
編輯的話
面對資訊爆炸的時代
Joshua Hoffman

我在思考 本月份的兩個重要主題 SharePoint 和 Office Communications Server 時，深刻感受到人際溝通的障礙。其實這並不令人意外，就拿我在一個月前撰寫這篇短文的時候來說吧，紐約市正籠罩在一片薄海歡騰的節慶氛圍中。而《TechNet Magazine》總部正位於紐約慶祝佳節的中心地帶：洛克斐勒中心。從許多方面來看，這裡實在是個很不錯的地段，但只要一到每年的某個月份，這裡就變成......就姑且稱之為挑戰吧。全國甚至世界各地的的觀光客蜂擁而至，這麼說還不足以形容。來購物的、看秀的，甚至把雄偉的摩天大樓腳當作溜冰的背景，令許多紐約客避之惟恐不及。
有些觀光客常常冷不防就停在人行道中間拍起照來，逼得走在後面的我們要不緊急煞車，要不就一頭撞上他們，實在非常不爽。不過這還不是不爽的主因，說真的我們很高興各位來此拍照，真正的原因是 — 這裡快要擠爆了！對於深處原已擁擠忙碌的城市的我們來說，已經達到瀕臨抓狂的邊緣了。
看看這種情況，再想想我們的業界，我發現這兩者頗有異曲同工之妙。隨著企業日益茁壯，雖然為我們樂見，但也在每天製造了大量的資訊。檔案共用塞爆了，資料庫塞爆了，電子郵件就更別提了。不久前，GB 還代表很大的儲存空間，而現在連 TB 在家用電腦都很普及了，許多資料中心還打算朝 PB 邁進呢。這無疑是個資訊充斥的世界，但是這些資訊真的有用嗎？亦或只是「充斥」而已？資訊有條有理嗎？容易分析嗎？容易共用嗎？
回到開頭那句話，到處充斥著各種資訊，要說沒有人際溝通障礙也難。其實人際溝通應該可以更容易才對，而這也是我們本月份所要討論的主題。在這個主題當中，我們要學習如何借助 SharePoint 之力，更方便而有條理地在企業內部收集資料；學習如何快速建立問卷調查，向使用者 (或客戶) 收集相關資料；學習如何定義自訂內容類型，為收集的資訊賦予更多意義。最後，還要學習如何使用 Office Communications Server，從而搭起友誼的橋樑。說的也是，空有資料卻無人分享，資料再多又有什麼意思呢？ —Joshua Hoffman

感謝下列 Microsoft 技術專業人員：Ed Banti、Susan Bradley、Byron Hynes、Michael Murgolo、Ken Oien、Jim Truher 和 Kay Unkroth。


 讀者來信: 讀者有話直說
讀者來信
讀者有話直說

ActiveX Installer 服務可用性
我剛剛拜讀一篇您在 2007 年 7 月份所寫的文章＜Windows Vista 的 ActiveX Installer 服務＞ (網址為 technetmagazine.com/issues/2007/07/AxIS)。能不能請您告訴我，這項服務現在可以使用了嗎？
—Eugene Y.

是的，ActiveX® Installer 服務現在可以開始使用。您只要在 Windows Vista® 的 [程式] 和 [功能] 控制台選取 [開啟或關閉 Windows 功能] 選項，就可以輕鬆啟用它。
ActiveX Installer 服務是選擇性元件，只有 Windows Vista 旗艦版、商用進階版和商用入門版才有提供。容許安裝 ActiveX 和 ActiveX Installer 服務的網站清單，是透過群組原則加以控制。這份清單是儲存在群組原則物件編輯器的 [電腦設定] | [系統管理範本] | [Windows 元件] | [ActiveX Installer 服務] 區段中。

Active Directory 工具
非常謝謝您提供＜11 個管理 Active Directory 的基本工具＞ (2007 年 9 月)。我一直想利用該文所介紹的 dsrm 公用程式，以下面這個命令列，從 Active Directory® 刪除使用者：
          dsquery user -samid <samid> | dsrm
卻收到一則錯誤訊息，告訴我 "dsrm" 輸入的格式不當。但是單獨執行這個命令時卻沒有什麼問題。您能夠給我什麼建議嗎？
—Keith E.

我們將您的問題轉給該文作者 Laura Hunter。Laura 指出，當您將 dsquery 結果傳送到 dsrm 時，dsrm 要求必須使用 -noprompt 參數。因此您需要使用下面這個命令列：
dsquery user -samid <samid> | dsrm -noprompt
關於未在原文中提及這項資訊，我們向您致歉，並且會在線上文章作出更正。

另一個謎底
我假設您知道，而且也有很多人提醒過您了，Dr. Scripto 的「指令碼謎題」(2007 年 11 月) 其實有兩種解決方案。如果第一行和第二行的 4 字元變數是 nnde，而且第三行和第五行的 5 字元變數是 iamex，一樣可以解開這個謎題 (我知道這兩者沒什麼差別，而且您解決方案所用的名稱，讓指令碼更好懂)。
我很感謝這個謎題帶給我的樂趣，我很樂在其中。
—Stan A.

Stan，謝謝您與我們分享另一個解決方案！我們很高興您喜歡這個新的 Scripting Guy 謎題，也很高興它正式成為《TechNet Magazine》的固定單元。

驅使我們進行 Windows Vista 移轉
2007 年 11 月號《TechNet Magazine》的＜Windows Vista 中關於離線檔案的變更＞一文 (請至 technetmagazine.com/issues/2007/11/Offline)，詳細解說了 Windows Vista 在離線檔案領域的優點。就是那篇文章驅使我們決定移轉到 Windows Vista，因為我們在 Windows® XP Professional 使用離線檔案時遇到很多問題。
—Daniel Z.

謝謝您，Daniel！我們很高興您認為這篇文章能夠幫上貴公司的忙。

遺漏書頁
貴雜誌相當引人入勝，內容也相當豐富。但是我的 2007 年 12 月號遺漏了 49 到 64 頁。我對於 Tom Cloward 和 Frank Simorjay 所寫的那篇電腦鑑識文章 (＜基本電腦鑑識指南＞) 很感興趣，而那篇文章應該在第 60 頁。是不是能夠請您的列印鑑識小組幫我找回那漏掉的幾頁或資料呢？如果那篇文章有在線上刊登，請把 URL 傳給我，我在線上讀它就好。
—Dave S.

不好意思，我們 2007 年 12 月號的印刷出了點問題，因此寄給讀者的印刷本有幾本漏印了 49 到 64 頁。在此我謹代表我們的出版服務和《TechNet Magazine》小組，為我們帶給您的不便致上誠摯的歉意。
另外，您所提及的那篇文章，以及 12 月號的其餘部分，現在皆已刊登在線上，網址為 technetmagazine.com/issues/2007/12。


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

解除鎖定檔案
Unlocker
ccollomb.free.fr/unlocker
我們都曾經遇過這種情況：某個自動化處理序在作業過程中停止回應，檔案遭到寫入鎖定的陷滯，導致另一項作業因無法複製、移動、寫入或刪除此檔案而失敗。有時候您就是找不出造成檔案鎖定的罪魁禍首，只知道被鎖定的是哪個檔案。那麼您該怎麼做呢？
處理這種情況的方法很多，但有一個工具可以針對檔案鎖定的問題，提供快速簡單的 Windows® 檔案總管整合式解決方案，那就是由 Cedrick Collomb 編寫的免費 Unlocker 工具。多虧它與 Windows 檔案管理員整合，您只要在鎖定檔案 (或一組檔案) 上按一下滑鼠右鍵，然後從內容功能表中選取 Unlocker，就能找到問題癥結。發現鎖定之後，您可以選擇執行數個選項，例如刪除有問題的處理序、解除鎖定檔案 (關閉控點)、刪除檔案、移動檔案，或重新命名檔案。您也可以將目前狀態下的鎖定檔案複製到另一個位置。
Unlocker 具有完整的應用程式安裝程式，因此您無須以手動方式登錄或取消登錄任何 DLL，也不需要讓系統重新開機來啟動此工具。這項工具還支援自動更新通知來確保您使用的是最新版本 (假使您不介意它三不五時就「打電話回娘家」的話)。
Unlocker 甚至支援命令列執行，這項功能特別有助於進行自動化。舉例來說，這表示您可以輕鬆地設定一個記錄傳送處理序，當您嘗試移動檔案記錄時，如果碰到鎖定的 .zip 檔案，這個處理序就能夠自動關閉控點並刪除壓縮處理序，這麼一來，您可能就不需要三更半夜起床親自修復這個問題。
此公用程式也包含名為 Unlocker Assistant 的系統匣工具。當您嘗試移動、重新命名或刪除鎖定檔案時，這個工具會自動啟動 Unlocker 介面，您就不用按那麼多按鍵來尋找檔案，也不用按滑鼠右鍵從內容功能表選擇 Unlocker。Unlocker 與大多數 Windows 版本 (包括 Windows Vista® 在內) 都相容。

售價：免費
有了 Unlocker，您就能迅速找到和解除鎖定的檔案

分析網路流量
Wireshark
wireshark.org
稱職的網路通訊協定分析器可讓您瞭解基礎結構上的網路流量基礎，以便確認互連應用程式各層底下的真實情況。其中最知名的開放原始碼分析器當屬 Wireshark，它是採用 WinPcap Packet Capture Library for Windows 開放原始碼，並且是從 Ethereal 演化而來 (仍由 Gerald Combs 參與開發)。
經由 Wireshark，您可以輕易地擷取在網路介面上傳遞的流量，並透過簡單好用的圖形化介面來查看每個封包的詳細資料。啟動新的封包擷取工作階段非常簡單，只要選取介面再按一下開始即可。GUI 是以色框來顯示擷取的封包，它會以近乎即時的方式詳載時間、來源、目的地、通訊協定和預定的事件說明。在某一段傳輸工作上按一下滑鼠按鍵，便會反白顯示詳細資料，並將封包資料解析為簡單易懂的詳細資料窗格。在窗格底下，您可以檢視十六進位與 ASCII 形式的原始封包資料。
當然，一旦找到分析所需的資料集之後，您也可以儲存或匯出該工作階段以供後續分析。Wireshark 可以解碼許多不同的通訊協定，而且應該足以應付大部分的疑難排解需求。
網路內容十分龐雜，為了協助您篩選所有這些資料，應用程式提供一個很棒的功能，這項以運算式為基礎的功能可讓您根據通訊協定的各個參數來縮小搜尋範圍。譬如說，您可以篩選出所有除了與網路中特定 IP 往來的 BitTorrent 相關以外的流量。另外，篩選器也可以丟出大量的假廣播訊息，好讓您輕鬆找出造成網路混亂的機器。
此介面也可讓您輕易設定要檢閱的封包旗標，並將特定傳輸設為擷取作業中的參考時間。我最愛的其中一項 Wireshark 功能，就是追蹤 TCP 資料流，方法是以滑鼠右鍵按一下 TCP 封包，並在內容功能表上選擇該選項。這個動作會叫出一個視窗，以顏色標示和格式化的文字顯示 TCP 資料流內容，此檢視特別適用於偵測 Web 應用程式錯誤、假的 HTTP 標題或其他您可能遇到的 TCP 通訊問題。而且您可以在此快速列印或儲存交談以供後續檢查或展示之用。
我只不過粗略介紹了應用程式的功能。Wireshark 是在 GPL 授權下發行；除了可用於 Windows 之外，也提供編譯的二進位檔，適用於大部分 Linux 與 FreeBSD 版本。

售價：免費
Wireshark 讓您分析完整的網路通訊協定

增強 Windows PowerShell
PowerShell Community Extensions
codeplex.com/PowerShellCX
若您過去有機會實際使用 Windows PowerShellTM，可能已經注意到有些重複執行的模式，如果有指令程式或別名的話該有多好。為此，一群來自開放原始碼社群的 Windows PowerShell 使用者和提倡者於是創建了 PowerShell Community Extensions 專案，這個專案將常見的功能要求整理成一套可散佈的指令程式、別名、提供者、函數、篩選器和指令碼。
此套件中包含的一些指令程式有 Get-Clipboard 及 Write-Clipboard，可讓您新增和擷取剪貼簿緩衝區上的資料。另一方面，Get-DomainController 會擷取目前網域中的可用網域控制站清單，而 Write-GZip 和 Write-Zip 可讓您編寫 GZIP 或 ZIP 檔案。
您可以在 Windows Vista 或 Windows Server® 2008 中分別使用 New-Symlink 與 New-Junction 來建立新的符號連結或接合。還有實用的 DirectoryServices 提供者可讓您存取 LDAP 伺服器，例如 Active Directory® 和 AssemblyCache，以便存取 Microsoft .NET Framework 全域組件快取與其中的組件。
此套件還包含一些很棒的指令碼。Set-Writable 和 Set-ReadOnly 指令碼可讓您快速變更檔案的唯讀狀態。Get-Url 可提出 WebRequest 並以字串傳回 WebResponse，而 Export-History 會將您的命令歷程記錄傾印到 .clixml 檔案以供後續重複使用。您可以使用 Get-DiskUsage 指令碼來掠取磁碟使用量資訊，甚至是使用有趣的 Out-Speech 命令來讓電腦講話。這個套件還包括其他許多實用功能，例如 Quote-List 可縮短命令列輸入字數，Add-PathVariable 可將一組路徑新增到指定環境中。
此專案為標準 Windows PowerShell 環境增添了非常實用的擴充功能集。若您恰好擅長 Windows PowerShell，相信這個專案將可讓您如虎添翼。

售價：免費
PowerShell Community Extension 滿足常見的功能要求
PowerShell Community Extension 滿足常見的功能要求

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


 SQL 問答集: 非叢集索引和保留權限
SQL 問答集
非叢集索引和保留權限
Saleem Hakani and Dan Carollo

非叢集索引及其用途
問：什麼是非叢集索引？使用它們有何利弊？
答：非叢集索引就好比一般書末的索引。書中所含的各項資訊在索引中依主題列出，並附有頁碼等指標，方便在書中的多個章節內找到所需資訊。另外，書籍索引資料所列的順序不等於在書中出現的順序，這一點跟非叢集索引一樣。如果您在資料表上有叢集索引，便可以指定項目的順序。否則，就無法確定順序。
除此之外，非叢集索引還有兩項限制：索引裡面只能包含 16 個資料行，而且索引鍵最大不得超過 900 個位元組。這是什麼意思呢？我們來看看，如果您希望在 MovieList 範例資料庫的 Movie 資料表內製作下列資料行的索引時，會發生什麼事：MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400)。
假設您發出下列陳述式來建立資料表：
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
這時會產生下列錯誤訊息：「警告！最大索引鍵長度是 900 個位元組。'Movie_IDX' 索引的最大長度是 1000 個位元組。有些大值的組合，是無法執行插入/更新作業的」。您會收到上列的訊息，是因為 "nvarchar" 資料型別每個字元會耗用 2 個位元組，而含有前三個資料行的索引，便超過了 900 個位元組的大小限制。
但是 SQL Server® 2005 推出之後，現在只要把資料行加入 INCLUDE 子句中，就可以克服這個問題了。如果您希望同時解決大小和資料行限制，這是非常實用的功能。您可以執行下列陳述式：
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
請注意，當您在建立索引期間使用 INCLUDE 子句時，資料庫引擎在計算索引鍵資料行或索引鍵大小的時候，並不會考慮非索引鍵資料行。
如需其他非叢集索引的實用資訊，請參閱＜非叢集索引＞，位於msdn2.microsoft.com/aa174537 和＜使用非叢集索引＞，位於 msdn2.microsoft.com/aa933130。如需將索引最佳化的秘訣，則請參閱 sql-server-performance.com/optimizing_ indexes.asp。

保留權限資料
問：當訂閱重新初始化時，該如何避免遺失權限？這個問題我遇過好幾次：當快照集重新初始化時，就會遺失所有授予的權限。
答：在預設的情況下，訂閱每次重新初始化時，訂閱資料庫中所有的物件全都會被捨棄然後重建。但是有兩種方法可以解決這種情況。
首先，您可以在重新初始化之後，重新套用所有的權限。當您手動設定權限時，最好把所有的物件/陳述式層級權限寫成指令碼，然後分開存放，這樣就可以在重新初始化訂閱之後，立即使用它們。
其次，您可以設定訂閱，讓它不要在每次重新初始化訂閱時，捨棄任何物件。您可以使用 SP_CHANGEARTICLE 系統預存程序，為 @PROPERTY 參數設定 PRE_CREATION_CMD 一值，以及為 @Value 參數設定 NONE、DELETE 或 TRUNCATE 的值。
另外，請在目的地物件區段中的 [發行項屬性] 對話方塊裡，選取 [不要變更現有物件，請刪除資料]。[如果發行項有資料列篩選器，請只刪除符合篩選的資料]。[請截斷現有物件中的所有資料的值]。請務必先在測試環境中試驗這個動作，如果需要進一步的協助，請查看《SQL Server 線上叢書》最新版本以取得最新資訊。

Saleem Hakani 身兼資深資料庫工程師、資深問題工程師，以及全球 Microsoft SQL Server 社群主管，他在資料庫系統方面有超過 14 年的經驗。他負責外部 SQL Server 社群網站，網址是 sqlcommunity.com，您可以透過電子郵件與他連絡：Saleem@sqlcommunity.com。
Dan Carollo 在 Microsoft 的 Windows 防惡意程式碼研究與因應 (Windows Anti-Malware Research and Response) 小組擔任作業工程師和 SQL Server DBA。他在 SQL Server 擁有 MCT 認證。


 公用程式焦點: ADMX Migrator
公用程式焦點
ADMX Migrator
Lance Whitney
下載本文程式碼: ADMX Migrator (2765KB)

要是您使用群組原則， 想必對系統管理範本來設定作業系統與應用程式設定也不陌生。附隨在 Windows® 和主要軟體 (例如 Microsoft® Office) 中的 ADM 檔案，涵蓋了大部分的一般桌面設定。不過，有時候還是要建立自己的 ADM 範本來合併自訂設定。從頭設計 ADM 並不容易，因為它們具有自己專屬的語法，而且必須使用文字編輯器建立。有了經驗再投入一點時間，但是許多群組原則專家也變成了製作自己 ADM 檔案的高手。
Microsoft 在推出 Vista® 時，把群組原則範本的格式改成以 XML 為主的結構。這個新格式稱為 ADMX，它提供了幾種舊版 ADM 檔案所沒有的優點，例如多語言支援，以及一個中央存放點供您管理所有範本。
雖然這是好事，不過萬一您要建立自己的 ADMX 檔案，卻不了解 XML 的時候該怎麼辦？更重要的是，那些您花費多年建立的自訂 ADM 又會變成什麼呢？幸好，ADMX Migrator 公用程式正可以解決您的困難。這個免費工具是由 FullArmor Corporation 開發，並由 Microsoft 取得授權，它有兩個主要優點：容許您建立自己的自訂 ADMX 檔，並且將您的舊版 ADM 檔案轉換成 ADMX。
ADMX Migrator 圖形化介面
ADMX Migrator 圖形化介面
為了以新格式建立範本，ADMX Migrator 提供了附有圖形化使用者介面的 ADMX 編輯器 — 不再需要文字編輯器。您在清楚簡單的介面中，以下拉式功能表和下拉式清單建立自己的範本 (見圖)。一開始先選擇 [新增範本] 命令、為範本檔命名，然後輸入類別，將檔案分類。接著再輸入要套用原則的登錄機碼、登錄值的名稱，以及它所影響的類別 (使用者、電腦或兩者)，來建立實際的原則設定。您也可以說明原則的功能。
完成之後，以 ADMX 格式儲存新範本。它會儲存成 ADMX 和 ADML 兩個檔案。ADMX 檔案包含實際的原則設定，而 ADML 檔案則包含原則的語言特定資訊。現在您可以將這兩個檔案複製到網域中適當的目錄下，並且將它們合併到群組原則。
您也許會希望將 ADM 檔案轉換成 ADMX，以充份利用新格式的優點。ADMX Migrator 提供兩種轉換方法 — 透過編輯器或透過命令列程式。您可以從 ADMX 編輯器選擇 [Generate ADMX from ADM (從 ADM 產生 ADMX)] 的選項，然後再瀏覽至 ADM 檔，此時工具便會自動並快速地轉換它。接著您可以在編輯器開啟轉換後的檔案，檢查它的值和內容，必要時也可進行修改。ADMX Migrator 命令視窗有點複雜，您必須在提示輸入冗長的命令字串來執行轉換作業。但是，它含有一些圖形化編輯器所沒有的選項和彈性。
ADMX Migrator 是一種 Microsoft Management Console (MMC) 嵌入式管理單元，必須搭配 MMC 3.0 和 Microsoft .NET Framework 2.0 使用。ADMX Migrator 可在 Windows XP SP2、Windows Server® 2003 SP1 和 Windows Vista 下執行。您可以在 go.microsoft.com/fwlink/?LinkId=77409 下載此軟體。

Lance Whitney 身兼 IT 顧問、培訓講師和技術文件作家。他投入許多時間改良 Windows 工作站與伺服器。記者出身的 Lance 在 15 年前一頭栽進 IT 產業。


 The Cable Guy: IEEE 802.1X 有線驗證
The Cable Guy
IEEE 802.1X 有線驗證
Joseph Davies
本文是根據 Windows Server 2008 的搶鮮版所撰寫。本文包含的所有資訊均有可能變更。

隨著 IEEE 802.1X 驗證在 IEEE 802.11 無線網路上的應用越來越普及，網路系統管理員也希望將這個標準應用在有線連線上。無線用戶端必須先提交一組憑證接受驗證之後，才能將無線框架轉送到內部網路，
同樣的，IEEE 802.1X 有線用戶端也必須先執行驗證，才能使用其切換連接埠。IEEE 802.1X 驗證可以為內部網路提供一層額外的安全性屏障，防止無法順利執行驗證的訪客、惡意或不受管理的電腦連接到您的內部網路。
您的有線交換器可能已經支援 IEEE 802.1X 驗證，只需要啟用和設定就可以了。在進行有線連線的驗證和授權時，支援 802.1X 的交換器通常是使用遠端驗證撥入使用者服務 (RADIUS) 通訊協定，將連線要求資訊傳給 RADIUS 伺服器，例如 Windows Server® 2008 網路原則伺服器 (NPS) 或 Windows Server 2003 網際網路驗證服務 (IAS) 伺服器。
在您設定 RADIUS 的交換器之後，必須在要求 802.1X 驗證前於有線電腦上啟用並設定 802.1X 驗證。其實，自 Windows XP 以降，Microsoft® Windows® 便已開始支援有線網路連線的 IEEE 802.1X 驗證。只是您必須在每個單獨的有線用戶端 Windows XP 和 Windows Server 2003 上，手動進行 802.1X 驗證設定 (從 [網路連線] 資料夾中，網路連線內容的 [驗證] 索引標籤執行)，因為我們無法為這些舊版作業系統集中設定或編寫有線 802.1X 設定。
幸好，現在群組原則中支援有線設定，再加上 Windows Vista® 和 Windows Server 2008 的 Netsh 工具也支援指令碼，部署 802.1X 有線設定要比過去簡單多了。

群組原則中的有線網路設定
使用有線自動設定服務
Windows XP 和 Windows Server 2003 是以無線零設定服務，控制有線連線的 802.1X 行為。這項服務在這兩個作業系統上都是預設啟用的服務，而有線網路連線是以被動接聽模式，等候交換器起始驗證作業。
相對的，Windows Vista 和 Windows Server 2008 是由有線自動設定服務控制有線連線的 802.1X 行為，不過它在預設情況下是停用的。因此，網路連線內容的 [驗證] 索引標籤要等有線自動設定服務啟動之後才會出現。
執行 Windows Vista 或 Windows Server 2008 的個別有線用戶端，可以使用 [服務] 嵌入式管理單元來啟動有線自動設定服務，並且設定讓它自動啟動。當有線自動設定服務啟動時，有線網路連線便以主動接聽模式運作，這時候網路連線就會啟動交換器驗證。
如果是 Active Directory 網域，則可以使用群組原則，設定讓有線自動設定服務自動啟動。您可以使用 [群組原則管理編輯器] 嵌入式管理單元，設定 [電腦設定] | [Windows 設定] | [安全性設定] | [系統服務] | [有線自動設定] 設定，來使用自動啟動模式。

為了將有線網路設定的設定作業集中化和自動化，Windows Server 2008 和 Windows Server 2003 Active Directory® 網域服務支援群組原則中的有線原則設定。這些設定可讓您將有線網路設定，設定為網域群組原則物件的電腦設定群組原則一部分。
有了這些有線原則設定，您就可以針對執行 Windows Server 2008 或 Windows Vista 的有線有戶端，指定驗證方法和其他 802.1X 設定。不論是加入網域、啟動，或是啟動之後定期使用設定，這兩個作業系統都會自動下載有線群組原則設定，並且套用它們。但是請注意，您必須擴充 Windows Server 2003 Active Directory 網域來支援這些新原則。有關擴充 Windows Server 2003 Active Directory 網域的方法，請參閱 technet.microsoft.com/bb727029。
您可以從 [群組原則管理編輯器] 嵌入式管理單元的 [電腦設定] | [Windows 設定] | [安全性設定] | [有線網路 (IEEE 802.3) 原則] 節點，設定有線原則。根據預設值，系統並無有線網路 (IEEE 802.3) 原則。若要建立新原則，請用滑鼠右鍵按一下主控台樹狀目錄中的 [有線網路 (IEEE 802.3) 原則]，然後按一下 [建立新的 Windows Vista 原則]。
Windows Vista 有線原則的 [內容] 對話方塊，有 [一般] 和 [安全性] 兩個索引標籤。[圖 1] 是預設的 [一般] 索引標籤。您可以在 [一般] 索引標籤設定原則的名稱和說明，並且指定是否要以有線自動設定服務控制有線連線的 802.1X 行為。如需詳細資訊，請參閱本文的「使用有線自動設定服務」資訊看板。
[圖 1] Windows Vista 有線原則的預設 [一般] 索引標籤
[圖 1] Windows Vista 有線原則的預設 [一般] 索引標籤
[圖 2] 是 Windows Vista 有線原則的預設 [安全性] 索引標籤。您可以在 [安全性] 索引標籤上啟用或停用 802.1X 驗證、選取和設定可延伸驗證通訊協定 (EAP) 驗證方法、選取驗證模式 (使用者重新驗證、僅限電腦、使用者驗證或訪客驗證)、設定放棄驗證前容許的驗證失敗次數，以及設定是否要快取使用者資訊供後續連線使用。停用快取時，Windows 會在使用者登出時，從登錄移除使用者認證資料。這樣，當下一個使用者登入時，畫面會提示他輸入他的認證 (例如使用者名稱和密碼)。
[圖 2] Windows Vista 有線原則的預設 [安全性] 索引標籤。
[圖 2] Windows Vista 有線原則的預設 [安全性] 索引標籤。
當您按一下 [安全性] 索引標籤的 [進階] 按鈕時，可以設定 802.1X 和單一登入的進階設定。[圖 3] 是 Windows Vista 有線原則的預設 [進階安全性設定] 對話方塊。您可以在 [進階安全性設定] 對話方塊中，設定 802.1X 設定，如 [圖 4] 所示。
Figure 4 [進階安全性設定] 方塊中的 802.1X 設定 (Close Figure 4)

設定值 | 描述
送出的 EAPOL-Start 訊息上限 | 因為沒有收到對初始 EAPOL-Start 訊息的回應，而傳出的後續 EAP over LAN (EAPOL)-Start 訊息數目。
保留週期 | 因為沒有收到對之前傳送之 EAPOL-Start 訊息的回應，而重新傳輸 EAPOL-Start 訊息的時間間隔。
開始週期 | 當驗證用戶端收到驗證器傳來的驗證失敗指示訊息之後，而不執行任何 802.1X 驗證活動的期間。
驗證期間 | 驗證用戶端在起始端對端 802.1X 驗證之後，以及重新傳輸任何 802.1X 要求之前，所等待的期間。
EAPOL-Start 訊息 | 當有線用戶端傳送 EAPOL-Start 訊息時。
[圖 3] Windows Vista 有線原則的預設 [進階安全性設定] 對話方塊
[圖 3] Windows Vista 有線原則的預設 [進階安全性設定] 對話方塊
執行 Windows Server 2008 的有線用戶端，支援在有線連線時採用單一登入。這項功能也是針對即將問世的 Windows Vista Service Pack 1 而規劃。如需詳細資訊，請參閱 technetmagazine.com/issues/2007/11/CableGuy。
您會看到好幾個單一登入設定，您可以使用這些設定，在使用者登入程序之前或之後，執行使用者層級的 802.1X 驗證，並且等候指定秒數，讓使用者層級的 802.1X 驗證完成之後，再啟動使用者登入程序。您可以決定是否要在 Windows 登入畫面上，將使用者層級驗證的對話方塊，顯示在合併的輸入欄位之外。比方說，如果 EAP 類型要使用者在驗證時，確認 RADIUS 伺服器傳來的憑證，該 EAP 類型就可以顯示這個對話方塊。
此外，您也可以指定在執行使用者層級的驗證之後，讓系統起始有線介面卡 TCP/IP 設定的動態主機設定通訊協定 (DHCP) 更新。如果電腦和使用者層級驗證的有線用戶端各有各的虛擬 LAN (VLAN)，而且那些 VLAN 是不同的 IPv4 或 IPv6 子網路，請選取這個選項。

Netsh 工具附隨的指令碼支援
Windows Server 2008 和 Windows Vista 支援在 Netsh 工具的 netsh lan 路徑位置中使用命令來設定有線設定，或者匯出或匯入有線設定檔，後者是一組 XML 格式的具名有線設定。有了有線設定的命令列設定，您不需要借助群組原則，就可以為有線設定建立自動化的指令碼，這也使得有線網路的部署更加方便。有線網路 (IEEE 802.3) 原則群組原則設定只適用於 Active Directory 網域。對於不具群組原則基礎結構的環境，則可以將指令碼包含為登入指令碼的一部分，透過手動或自動方式來執行，這個指令碼會以有線設定檔將有線連線設定作業自動化。
若要對執行 Windows Vista 或 Windows Server 2008 的有線用戶端執行命令列設定，請以適當的參數執行 netsh lan 命令。比方說，下面這個命令可以在一個名叫「區域連線」的網路連線啟用單一登入，並且設定單一登入，在使用者登入之前執行使用者驗證：
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
如需 netsh lan 命令語法的詳細資訊，請參閱 technet.microsoft.com/aa905084。
您可以利用 Netsh 工具，將有線 XML 設定檔從 Windows Server 2008 或 Windows Vista 有線用戶端匯出，然後再匯入到 Windows Server 2008 或 Windows Vista 有線用戶端。如果要匯出有線設定檔，請使用 netsh lan export profile 命令。如果要匯入有線設定檔，則使用 netsh lan add profile 命令。如需一些有用的有線設定檔範例，請參閱 msdn2.microsoft.com/aa816372。
有了命令列和 XML 設定檔支援，您可以將有線用戶端啟動載入到公司由 802.1X 驗證的有線網路。不屬於網域成員的有線用戶端電腦，就無法使用電腦認證連接到有線網路。此外，電腦必須順利連接到有線網路之後，才能夠加入該網域。但是，命令列和 XML 設定檔支援可讓有線電腦以使用者認證連接到公司的有線網路，然後將該電腦加到網域中。如需詳細資訊，請參閱 technet.microsoft.com/bb727031。

Joseph Davies 是 Microsoft 的技術文件作家，從 1992 年開始教導和編寫 Windows 網路方面的主題。他出過五本 Microsoft Press 的書，同時也是每個月線上 TechNet Cable Guy 專欄的作家。


 Windows PowerShell: 命令介面權限
Windows PowerShell
命令介面權限
Don Jones
下載本文程式碼: PowerShell2008_02.exe (151KB)

在討論 Windows PowerShell 時，經常有人問我權限方面的問題，尤其是命令介面能否讓您自動變更權限，如果可以的話，又該如何進行。檔案權限或許是最常見的疑問，不過目錄和登錄權限也常常被問到。關於權限和幾乎
所有的命令列或指令碼介面 (包括 Windows PowerShellTM 和 VBScript 在內)，我要報告的消息有好有壞。
壞消息是 Windows® 中的權限本來就很複雜，這方面 Windows PowerShell 實在無能為力。問題的癥結點是，在 Windows 作業系統上，無論是檔案系統、Active Directory®、登錄或幾乎其他所有地方，只要攸關權限，都會牽涉到好幾個物件。
首先是資源本身 — 例如目錄物件、檔案或資料夾。接下來是存取控制清單 (ACL) 物件，這是附加在資源的部分。ACL 包含一或多個存取控制項目 (或稱 ACE) 物件，而 ACE 則將安全性主體 (使用者或群組，本身也是物件) 和權限 (例如讀取權或完全控制權) 以及「授與」或「拒絕」狀態繫結在一起。物件總共不超過五個：資源、ACL、ACE、主體和權限。
每種類型的資源又各有不同的權限類型，使得權限本身更形複雜。比方說，目錄物件的權限是掌控個別物件屬性的存取權，相當複雜。相較之下檔案權限就簡單多了。
而就技術上來說，當權限碰上稽核時，更是加倍複雜。每個資源實際上有兩個 ACL，一個是 Discretionary 存取控制清單 (DACL) 物件，負責掌控資源的存取權。另一個是安全性 ACL (SACL)，負責控制資源的稽核。而使用這些權限，就像一頭栽進一堆看起來很複雜的程式設計物件，要幫您簡化這樣的工作，像 Windows PowerShell 這類的命令介面能做的其實有限。

受限於 .NET Framework
還要其他相關資源嗎？
如需 Windows PowerShell 資源的詳細資訊 (包括可搜尋的 Cmdlet 程式庫)，以及與 Don Jones 和其他 Windows PowerShell 專家聯絡，請造訪 www.PowerShellCommunity.org。

Windows PowerShell 生來就具有讓事情複雜化的特性。以 Microsoft® .NET Framework 為基礎建置而成的 Windows PowerShell，是使用 .NET Framework 的基礎類別來呈現和處理權限。這些基礎 .NET Framework 類別都是為了讓軟體開發人員更細微且更準確地控制權限而設計。不用說，「細微和準確」想必牽涉到許多資訊，而且通常是指「非常複雜」的資訊。
此外，.NET Framework 並不會提供類別來表示每種 Windows 資源類型的權限。比方說，雖然 .NET Framework 會提供類別讓您操控檔案安全性，但卻不會提供類別讓您處理共用資料夾的安全性，因此 Windows PowerShell 便無法操控任何 Windows 資源類型的權限。簡單地說，Windows PowerShell 是受限於 .NET Framework 所公開的功能。

命令介面中的權限
Windows PowerShell 中的權限管理是衍生自兩個指令程式：Get-ACL 與 Set-ACL。也許您已經猜到，Get-ACL 會從資源擷取 ACL。接著您可以配合自己的需求來修改 ACL，然後使用 Set-ACL 將它寫回資源。這兩個指令程式都是通用的，而且都有賴於 PSDrive 提供者的 Windows PowerShell 系統。因此，假設 PSDrive 提供者能夠辨識指定資源類型，並且能夠修改該資源類型的權限，那麼這兩個 ACL 指令程式理論上應該可與任何一種資源類型搭配使用。FileSystem 和登錄 PSDrive 提供者 (附隨在 Windows PowerShell 中)，都支援透過這兩個 ACL 指令程式來管理權限 (其他 PSDrive 提供者可能不支援這麼做)。
[圖 1] 所示的指令碼範例可讓您指定開始目錄、安全性主體和權限。接著指令碼會把您為該主體所指定的權限，套用到指定目錄中的所有檔案和資料夾，指令碼也會遞迴到子目錄。
Figure 1 將主體的權限套用到目錄中的檔案和資料夾 (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
這個指令碼的重心，是它在 $rule 變數中定義新存取規則的地方。為了找出這個地方，我使用「原始」的 .NET Framework 類別，這可能是 Windows PowerShell 管理權限最複雜的一部分了。指令碼接著使用 Get-ACL 從每個檔案和資料夾相繼擷取 ACL、使用 ACL 的 SetAccessRule 方法套用新規則，然後使用 Set-ACL 將修改過的 ACL 寫回資源。
雖然複雜的作業 (像是從 ACL 移除 ACE) 居多，但實際情況其實沒有那麼複雜。我認為它之所以看似複雜，是因為它所包含的步驟很多：取得 ACL、定義規則、修改 ACL，還有寫入 ACL。這可不是一次就能完成的動作。再加上我想要修改多個檔案的 ACL，所以必須將所有項目包裝在一個 foreach 迴圈中，並且使用 Get-ChildItem 以便實際存取所有的檔案和資料夾。

我要採取最簡單的方法
本月指令程式：Get-QADUser
如果您要管理 Active Directory 的話，絕對少不了這個指令程式。它並沒有內建到 Windows PowerShell 中，但是可以免費下載 Quest Software 針對 Active Direcotry 設計的 ActiveRoles 管理命令介面來取得 (www.quest.com/activeroles-server/arms.aspx)。
只要將這個嵌入式管理單元安裝好之後，就可以使用 Get-QADUser 從目錄擷取使用者物件了。當然啦，光是執行指令程式傳回所有的使用者，對大部分的系統管理工作並沒什麼幫助。但是指令程式容許您指定篩選條件，而且是在網域控制站套用，所以實際上只有您關心的使用者，才會傳回 Windows PowerShell。這種方法比先取得所有使用者，再以 Where-Object 指令程式篩選它們要快上許多。比方說，Get-QADUser -l Redmond 只會傳回那些 "l" 屬性包含 "Redmond" 的使用者 (順道一提，"l" 屬性代表位置 (locality)，而且在 GUI 是代表城市)。接著您可以將這些使用者傳到其他指令程式，看是要產生 HTML 報告、把它們放到群組中，甚至刪除它們都可以。

雖然我不覺得我舉的例子有多麼複雜，可是我知道很多系統管理員喜歡用更簡單的方法來管理權限。或許他們想要把某個使用者群組從一組資料夾一次移除，但是又不想編寫像 [圖 1] 所示的多步驟指令碼。
所幸 Windows PowerShell 確實有簡單的方法可以管理權限，而且您可能也不陌生。
Windows PowerShell 會讓您繼續保有凡事必定查驗的作風。您還是可以使用命令列工具 (例如 Dsacls.exe、Cacls.exe 和 Xcacls.exe)，這些都是為了讓您以更簡單的方法處理各種權限而設計的工具。雖然它們的語法與 Windows PowerShell 指令程式所用的標準化語法截然不同，但是您不必再以臨機操作的方式，在命令列使用這些命令列公用程式，就像過去在舊版 cmd.exe 命令介面下使用一樣。而且您可以使用 Windows PowerShell，將這些公用程式自動化。
我還碰過一些同道 — 我稱他們「純正派」— 他們堅持在 Windows PowerShell 裡面使用命令列公用程式是不正當的作法，我想不透他們的邏輯。我在乎的是把工作完成，如果這麼做最簡單的方法是使用有 10 年歷史的命令列公用程式，我照用不誤。我才不想多花時間嘗試以特定的方式來做事，就因為那種方法好像「比較純正」。Microsoft Windows PowerShell 小組也秉持類似的態度，如果有現成的工具可以達到目的，Windows PowerShell 會讓您在命令介面中使用該項工具。何必浪費時間重造呢？
[圖 2] 舉例說明了一個簡短的指令碼 (摘錄自敝作《Windows PowerShell:TFM》(SAPIEN Press，2006 年))，使用 Windows PowerShell 來自動化 Cacls.exe。這個指令碼只是作為示範之用，也就是說，如果您想要把它變成真正的自動化工具，還得另外做些修改。但它確實能夠示範 Windows PowerShell 指令碼如何收集資訊，並且運用它來啟動 Cacls.exe，就像 Cacls.exe 是 Windows PowerShell 的原生命令一樣 (雖然這個指令碼是提示使用者輸入資訊來收集資訊，但它也可以從檔案或資料庫讀取參數)。
Figure 2 將 Cacls.exe 自動化 (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

管理權限有成？
我曾聽過有人爭議 Windows PowerShell 在權限方面功能不佳，因為它沒有原生的指令程式可以提供簡化、通用的權限管理。這點我不茍同，首先，這種主張通常是由 UNIX 背景深厚的系統管理員所提出，而 Windows 權限系統遠比 UNIX 所用的複雜得多。一旦採用這個系統，Windows PowerShell 也會變得複雜起來。不過這對 Windows PowerShell 來說一點也不成問題。
此外，我在這裡也有示範，Windows PowerShell 確實可讓您透過老派命令列公用程式來使用簡化的工具。沒錯，.NET Framework 的確需要進行一些擴充，才能更完整地涵蓋整個 Windows 平台的權限管理。但整體而言，Windows PowerShell 兼具兩邊的優點：簡化的權限管理，以及存取細微且準確的管理工具。

Don Jones 是《Technet Magzine》的特約編輯，也是《Windows PowerShell:TFM》(SAPIEN Press，2007 年) 一書的作者之一。他負責教授 Windows PowerShell (請參閱 www.ScriptingTraining.com)，您可以透過 www.ScriptingAnswers.com 網站與他連絡。


 嗨，Scripting Guy！: 比賽即將展開！還有一些 XML 也準備好了
嗨，Scripting Guy！
比賽即將展開！還有一些 XML 也準備好了
The Microsoft Scripting Guys
下載本文程式碼: HeyScriptingGuy2008_02.exe (151KB)

大家都知道， 每次一談到運動界的傳奇人物，總免不了提起這些名字：貝比魯斯 (Babe Ruth)、比利 (Pele)、阿里 (Muhammad Ali)、華特培頓 (Walter Payton)、ScooterK 和 MrRat、強尼 (Johnny)—
哈，您真幽默 ... 噢，您是說真的啊？您真得沒聽過 ScooterK 和 MrRat？好吧，顯然有些人還未接獲「冬季指令碼比賽」的最新消息 (將於 2 月 15 日至 3 月 3 日在 TechNet 指令碼舉辦；詳情請參閱 microsoft.com/technet/scriptcenter/funzone/games)，ScooterK 和 MrRat 是貨真價實的傳奇人物，這兩位參賽者都至少在 2007 冬季指令碼比賽的其中一個組別中獲得極高分。
現在真正精彩的部份來了：您真的能像球王比利 (Pele) 一樣創造足球傳奇嗎？大概不行，您期望自己有朝一日成為重量級拳擊的世界拳王嗎？嗯，有些 Scripting Guy 的確屬於重量級，但是要成為拳擊冠軍可沒那麼簡單。不過您 — 就是您沒錯 — 卻可以很輕易地成為下一個 ScooterK 或 MrRat。
註：理論上，您也有可能成為下一個貝比魯斯 (Babe Ruth)，只要您能夠在棒球雙重賽之間的空檔吃下 24 個熱狗。
別緊張；我們會教導您如何成為下一個 ScooterK 或 MrRat (甚至是下一個 Bizzy 或 H2Data)。而您只需要到指令碼中心參加「指令碼比賽」就行了。我們將在 2 月 15 日發佈 10 個不同的比賽項目 (10 項指令碼挑戰)，向您下戰帖，看您是否能完成其中一個或所有挑戰。撰寫指令碼來解決我們發佈的問題，然後透過電子郵件寄給 Scripting Guy (「指令碼比賽」首頁有詳盡的指示說明)。我們將測試您的指令碼，看看是否可行，並加以評分。只要成功完成這 10 個比賽項目，您也會成為運動界的傳奇人物。至少在指令碼運動界是如此，反正也差不多啦。
「指令碼比賽」(2 月 15 日至 3 月 3 日) 有趣又充滿刺激。最棒的是，人人皆可參加「指令碼比賽」。您是系統管理指令碼的新手嗎？那就參加初學者組別；我們專為 VBScript、Windows PowerShellTM 和 (今年的新面孔) Perl 的初學者開設個別競賽。覺得初學者組別太簡單？那您一定要參加進階者組別，我們也有 VBScript、Windows PowerShellTM 和 Perl 的進階者競賽。
「指令碼比賽」(我們有沒有提過比賽期間是 2 月 15 日至 3 月 3 日？)算是指令碼旺季的一大盛事，錯過可惜喲。現在就造訪指令碼中心首頁，瞭解比賽訓練的秘訣和訣竅，等到 2 月 15 日比賽正式開始後再來參加競賽。
2 月 15 日至 3 月 3 日，再次強調，以免向隅。
您說什麼？您說的一點兒也沒錯：在新的《嗨，Scripting Guy！》專欄一開始就介紹了「指令碼比賽」的消息，這對每月的小小專欄來說內容實在是太豐富了。但是，為了取悅《TechNet Magazine》的一票好兄弟 (不用說，我們的人生目標就是取悅他們)，我們甘冒這個風險，硬是發表了一篇新專欄。
就在一年前 (哇，真的過那麼久了嗎？)，我們推出一篇專欄，講解如何使用指令碼來讀取 XML 檔案。但是那篇專欄中並未說明如何使用指令碼來建立、寫入和修改 XML 檔案。本月我們要亡羊補牢，您不是說想要知道如何撰寫指令碼來建立 XML 檔案嗎？只要您開口，呃，開口然後再等待一年，我們就會設法辦到。[圖 1] 顯示此指令碼。不可否認，這段指令碼看起來很複雜，不過我們會解說它的運作原理。
Figure 1 建立 XML 檔案 (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
一開始，我們先建立 Microsoft.XMLDOM 物件的執行個體。您可能已經猜到了，這個物件可讓我們處理 XML 檔案。我們的目標是要產生一個簡單的 XML 檔案，如 [圖 2] 所示。
[圖 2] 我們的目標：簡單的 XML 檔案
[圖 2] 我們的目標：簡單的 XML 檔案
若要建立此 XML 檔案，首先我們必須建立根節點 (ITChecklist)。我們該怎麼做？答案如下：
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
這很簡單，對吧？我們只需要呼叫 createElement 方法，再將要為根節點指定的名稱傳送給 createElement。接著直接呼叫 appendChild 方法，將物件參考傳送到新項目 (objRoot) 以當做唯一的方法參數。這時，我們就建立了一個根節點了。
但還不止這些呢！接下來，我們建立 ComputerAudit 節點，這個 ITChecklist 節點的子節點是用來表示單一電腦的資訊。如您所見，建立此節點的程式碼類似於用來建立根節點的程式碼：
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
唯一的差別在於：建立根節點時，我們會在 XML 文件本身呼叫 appendChild (請注意物件參考 xmlDoc)。若要新增根節點的子節點，我們則是在根節點 (objRoot) 而非 XML 文件上呼叫 appendChild。就是這麼簡單！
將 ComputerName 與 AuditDate 節點新增為 ComputerAudit 的節點也一樣簡單。若要這麼做，我們同樣要完成一個相似的程序：我們將呼叫 createElement 來建立新節點，並呼叫 appendChild 將此新節點附加到檔案中。
(隨堂考：這次我們要從何處呼叫 appendChild？沒錯，正確解答：從 objRecord，也就是我們剛才建立的父 (ComputerAudit) 節點)。
對了，由於 ComputerName 與 AuditDate 節點都必須包含值，所以我們一定要在新增這些節點到文件之前，先分別為它們指定 Text 屬性值。
我們來看一下實際建立 ComputerName 節點的程式碼，應該就一目了然了：
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
您可能已經猜到，建立 AuditDate 的程式碼幾乎一模一樣。我們只需要在呼叫 createElement 時指定另一個節點名稱，並為 Text 屬性指派不同的值即可。
天啊，我們把問題搞得太簡單了，不是嗎？
針對我們的第一筆 (在本例中也是唯一的一筆) 記錄建立好節點之後，我們要執行這一小巧的程式碼：
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
這樣只會在檔案開頭插入 <?xml version="1.0" ?>標記，以確保我們的 XML 文件格式正確。
此時，剩下的工作就是呼叫 Save 方法，將我們的新檔案儲存為 C:\Scripts\Audits.xml：
xmlDoc.Save "C:\Scripts\Audits.xml"
就這樣，全新的 XML 文件油然而生。
事實上這還蠻有用的：您現在就知道該如何使用指令碼來建立全新的 XML 檔案了。當然，通常您不太需要建立全新的 XML 檔案；相對來說，您只會需要附加新資料到現有檔案中。那麼，Scripting Guy 是否會為大家示範怎麼做呢？
其實，一開始我們本來想回答「不」的，我們才不要為大家示範如何附加資料到現有的 XML 檔案。不過，既然我們心地善良又大方，我們決定跟《TechNet Magazine》的讀者打個商量：如果這份雜誌的讀者都同意參加「2008 冬季指令碼比賽」，那麼為了回報大家，我們會示範如何使用指令碼來附加資料到 XML 檔案。那麼，每個人都同意參加「指令碼比賽」了嗎？
我們還在等您同意喔，沒錯，就是您 — 明尼蘇達州羅契斯特市的那位先生。
這樣才像話嘛！相信我們，「指令碼比賽」一定會讓您樂在其中的；大家每次都玩得不亦樂乎，我們保證。
既然已經一言為定，我們現在就來示範將資料附加到現有 XML 檔案的指令碼。請看一下 [圖 3]。
Figure 3 附加到 XML 檔案 (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
如您所見，這與建立 XML 檔案的指令碼並無太大差異。我們開始先建立 Microsoft.XMLDOM 物件的執行個體，接著將 Async 屬性設為 False，這會告訴指令碼我們要同步 (而不是非同步) 載入文件。這有什麼差別？這麼說好了，假如我們非同步載入文件，即使文件尚未完全載入，指令碼依舊可以繼續執行。不用說，如果您嘗試在還不存在的文件上執行作業，那麼很快就會帶來麻煩。藉由確保同步載入 XML 檔案，我們也可以確定在指令碼繼續執行之前，已經完全載入檔案。
一談到完全載入 — 還是算了，就當我們沒說過。接著，我們呼叫 Load 方法來開啟檔案 C:\Scripts\Audits.xml。開啟此檔案後，我們使用這一行程式碼來建立 documentElement 類別的執行個體，結果便會讓我們繫結到文件根節點。當然也就是本例中的 ITChecklist 節點：
Set objRoot = xmlDoc.documentElement
從這裡開始的工作毫不費力。我們建立 ComputerAudit 節點的新執行個體，並使用 appendChild 方法將這個新節點新增到檔案中。接著我們建立 ComputerName 和 AuditDate 節點的新執行個體，並為這些新節點各自指定適當值 (分別是 atl-ws-100 和目前日期)。我們將這兩個項目塞入剛才建立的新 ComputerAudit 節點中，呼叫 Save 方法來儲存檔案，然後再快快樂樂地繼續為即將到來的「指令碼比賽」準備指令碼。
避免我們忘了提，比賽預定於 2 月 15 日至 3 月 3 日在 TechNet 指令碼中心舉辦。
目前為止都很順利。我們能夠建立新的 XML 檔案，也能新增記錄到該檔案中。的確很不錯，但是這件事還沒完；舉例來說，我們要如何修改檔案中的現有記錄？我們至少可以採用一個方法來完成這項工作，如 [圖 4] 所示。
Figure 4 修改 XML (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
當我們呼叫 selectNodes 方法來決定查詢要傳回的記錄時，就浮現了這段指令碼最重要的部份。如您所見，當我們呼叫 selectNodes 時，得要細心指定兩個條件：我們只需要 ComputerName 屬性等於 atl-ws-100 的記錄，而且只要取回 AuditDate 屬性。
註：您不知道這是怎麼運作的嗎？那麼請參考一下關於使用 XML 檔案的第一篇文章 (technetmagazine.com/issues/2007/02/HeyScriptingGuy)；該文有詳細解說 selectNodes 查詢語法。
一如往常，selectNodes 傳回符合指定條件的所有 XML 記錄集合。這麼一來，我們只要設定 For Each 迴圈來循環處理集合中的所有項目，然後在該迴圈中指派新的值給 AuditDate，就可以更新 AuditDate 屬性值 (我們唯一要求的屬性)：
For Each objNode in colNodes
   objNode.Text = Date
Next
您說什麼？您想知道是否可以一次修改多個屬性？當然可以，只可惜今天不行；我們要留待之後的專欄再來討論。
您還有另一個問題：要如何在檔案中更新所有電腦的稽核日期？這很簡單，您可以使用 [圖 5] 中的指令碼。
Figure 5 變更稽核日期 (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
這個指令碼與先前修改 XML 的指令碼之間唯一的不同是什麼？在這個指令碼中，我們不會指定只要檢視 ComputerName 等於 atl-ws-100 的記錄。藉由忽略這項條件，預設將傳回所有記錄。
結束之前，我們再來看一下最後這個指令碼：假設我們的老友 atl-ws-100 已經打玩最後一場牌局，然後撒手前往天國中的電腦墓園了。
(從神學的角度來看：壽終正寢的電腦最後會到哪裡？後來才知道，原來這些電腦最後通常都給了 Scripting Guy。譬如說，執筆本專欄的 Scripting Guy 有一次得到了一台膝上型電腦，原因是：「你為 Microsoft 做了不少好事，實在該得到一台膝上型電腦」。而這項慷慨之舉只有一個問題，就是這台電腦已經壞到無法開機了。這樣也無妨，事實上，它連硬碟都沒有。
為了維持良好的矽生態循環，我們必須從 XML 檔案中刪除 atl-ws-100。我們該怎麼做？請參閱 [圖 6]。
Figure 6 從 XML 檔案刪除 (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
您可以看到，這與我們之前用來修改 AuditDate 屬性的指令碼很像。事實上，這兩段指令碼只有兩點不同：首先，請注意我們並未費神在 selectNodes 查詢中指定任何屬性值；藉由這麼做，便會傳回 atl-ws-100 的完整 XML 記錄：
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
接著，在我們的 For Each 迴圈中，我們直接呼叫 removeChild 方法來刪除 ComputerName 等於 atl-ws-100 的所有記錄：
xmlDoc.documentElement.removeChild _
  (objNode)
這樣就大功告成了。永別了，英年早逝的 atl-ws-100。
好了，有哪一位《TechNet Magazine》編輯還在閱讀本月專欄嗎？您說他們全都跑去玩每月的指令碼猜謎了？太棒了！現在沒人盯著我們，聽好：放下您手邊的事 (也包括閱讀這份雜誌)，快到指令碼中心，開始準備參加「指令碼比賽」。畢竟，《TechNet Magazine》隨時都可以看；但是「指令碼比賽」一年只有一次，而且期間有限 (精確的說就是 2 月 15 日至 3 月 3 日，免得您不知道)。千萬別錯過！
註：經您這麼一說，我們的確是等到您讀完整篇專欄，才要您暫停閱讀《TechNet Magazine》，不是嗎？不曉得是誰在搞鬼 ...

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
這個每月一次的挑戰不僅測試您的解謎功力，更要測試您的指令碼技巧。

2008 年 2 月：神秘的符號
電腦鍵盤包括各種奇形怪狀的字元；更奇怪的是，在指令碼語言 VBScript 或 Windows PowerShell 中，這些字元大多有特定的用途。看看您是否能將這些符號與其指令碼用途配對。第一題已經寫上答案了。

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：神秘的符號，2008 年 2 月

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


 安全性監控: 跳島攻擊：防堵不當的依存性
安全性監控
跳島攻擊：防堵不當的依存性
Jesper M. Johansson

在上一期的《安全性監控》，我討論了使用 USB 快閃磁碟機攻擊網路的初步行動。這種攻擊是將受感染的 USB 快閃磁碟機插入電腦中，惡意程式碼隨後便開始自動執行，或是只要使用者幫點忙 (利用簡單的社交工程)
就可以執行。這種攻擊範圍只限於工作站本機，但是惡意程式碼顯然有辦法傳播到網路各處。我在即將出版的《Windows Server 2008 Security Resource Kit》(Microsoft Press®，2008 年) 這本書裡面，詳細討論了這類網路攻擊，本文將引述該章節的部分內容。
當然，其中一項防護措施就是禁止使用卸除式磁碟機。這項措施看來似乎相當謹慎，但使用者其實還是有辦法中途埋伏，採取無懈可擊的攻擊行動。對所有的環境來說 (除了最機密的環境之外)，比較有效的措施還是妥善管理各種潛在風險，並且控制它們暴露於風險的程度。
此外，卸除式磁碟機也絕對不是入侵用戶端電腦的唯一途徑。還記得＜安全性十大定律＞ (請參閱 microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx) 嗎？第三定律的整體觀點仍然不變：「倘若不肖份子能夠毫無阻礙地存取您的實體電腦，您的電腦就淪陷了」。這段討論的大意是，如果攻擊者有權存取您的電腦，就表示那部電腦已遭入侵。如果攻擊者有辦法指使您在電腦上執行他的程式碼，他甚至可以從遠端犯案。所以您不妨把下面這句話當作第一定律：「倘若不肖份子能夠說服您在電腦上執行他的程式，您的電腦就淪陷了。」
您只要時時將十大定律謹記在心，就能確保電腦安全。這些定律不但被公認經得起各種考驗，而且不會有太大的變動 — 除非我們完全改變電腦的運作方式。所以，只要想想十大定律如何準確反映我們所提出的案例，就非確實遠離卸除式磁碟機不可。這一點，只要在登錄做少許變更就行了。
當然啦，您還得採用其他的防護層。您大可假設您有許多用戶端電腦已遭到入侵，或者正受到不把貴公司安全性當一回事的使用者所操控。因此，您必須減輕它們對網路其他部分所造成的衝擊，而且它也證明了瞭解、分析，以及減輕安全依存性的重要性。

安全依存性的定義
當一部電腦的安全性，必須仰賴另一部電腦的安全性時，這會產生安全依存性。也許您曾聽說，只要網域控制站 (DC) 被駭客入侵，就表示整個網路都遭殃了。把網域控制站視為所有網域成員安全性的依歸，可說是一針見血的說法。如果 DC 不安全，成員電腦也無法保持安全。如果駭客可以變更網域的安全性設定，那麼他只要在成員電腦的 Administrators 群組新增帳戶，就可以接管網域中的任何一部電腦。所以只要存在任何足以讓系統管理員入侵的罩門，都不是好玩的事。系統管理員對於它所管理的電腦，應該都具有完整的存取權。
電腦系統難免都有依存性，事實上，它們不但普遍存在，也經常有存在的必要；不過，這不表示所有的依存性都是妥當的依存性。在本文中，我要討論哪些是妥當、哪些是不當的依存性，然後再分析依存性的類型，以及減輕它們的方法。在《Windows Server 2008 Security Resource Kit》中，我會更詳細的解說特定的依存性，並且討論管理它們的方式。

妥當的依存性
一般說來，當比較不機密的系統仰賴比較機密的系統以求安全時，就屬於妥當的依存性。電腦和系統通常都可以根據它們的機密程度加以分類 (特定環境下的特定類別集合與一般討論並沒有關聯，最重要的是有繼承分類)。為了方便討論，假設我有兩種分類：工作站和網域控制站。在這個案例中，如果工作站為了安全必須仰賴網域控制站的話，並不成問題。網域控制站類別的機密性遠高於工作站，理當受到更嚴密的保護。
使用者帳戶也是同樣的道理。系統管理員有權存取使用者擁有的資料，這一點是可以接受的。這是因為系統管理員負責的範圍較廣，同時也能夠自由 (雖然不見得是直接或明顯) 存取電腦及其中所含的全部資料。如果您瞭解這一點，並且妥善管理這些電腦，這樣的依存性就不會有任何問題。
對於軟體，甚至可以透過相同的方式來分析。低機密性的軟體 (例如網頁瀏覽器) 理所當然能夠使用並且仰賴高機密性的軟體 (例如作業系統)。如果作業系統發現錯誤，即使網頁瀏覽器遭受新問題的威脅也不令人意外，說不定也不會馬上引起極度的關切 — 作業系統和其他重要的應用程式和資料，才是大家關切的焦點。這與修正錯誤的方式，或是將 Hotfix 安裝到哪裡有關 — 錯誤應該盡可能的切中問題加以修復。也正因如此，才得以充份發揮修正檔的保護影響力。所以，我們不應該是針對網頁瀏覽器中的問題尋找因應措施，而是要修復作業系統本身。
另外，您也可以變更設計，來移除依存性。比方說，您可以重新編寫網頁瀏覽器，降低它對作業系統的依存性。如果不打算像機密性低的元件 (網頁瀏覽器) 一樣使用安全性高的元件 (在此指作業系統) 的功能的話，不妨採用後者這個方法。

不當的依存性
看過前面解說何謂妥當的依存性之後，何謂不當的依存性就呼之欲出了。一般說來，機密性較高的系統絕對不能依賴機密性較低的系統來求取安全。
如果工作站遭到入侵，就表示網域控制站的安全性也已被破壞，那麼手邊的安全性問題可就嚴重了。若是網路的總體安全性必須仰頼該網路上每一部電腦的安全性，根本就保護不了這樣的網路。
用統計數字來說明的話，假如網路上的每一部電腦有 99.999% 的時候都很「安全」，您的網路的確相當安全。事實上，就當今的所有網路 (規模最小的網路除外) 而言，這個百分比可能相當不切實際。但是現在我們假設您的網路有 40,000 部電腦，每一部電腦有 .001% 的時候很容易入侵。這就表示您的整體網路可能有高達 40% 的時候不夠安全。
當然，如果依存性沒有妥善管理的話，只需要一部電腦那 .001% 的時間就足以入侵整個網路。這麼說來，網路到底有多安全呢？很顯然，比起機密性低的系統，機密性高的系統絕對是主要的受保護對象。
這個論點也可以延伸到使用者帳戶和軟體。比方說，新的 Terminal Services client for Windows® 容許您儲存使用者名稱和密碼，以進行實際透明化的終端機服務登入。這些認證都是使用認證管理員 API 來儲存，並且由主要登入工作階段所用的認證加以保護。
這麼一來就產生安全依存性了。假設現在有位網路系統管理員登入她的個人工作站，她使用這個工作站來收發電子郵件、瀏覽網頁以及進行其他一般資訊工作者的工作。當然，這些動作是使用低權限的網域帳戶來進行。
這位系統管理員在某段時間連接到其中一個網域控制站執行一些管理工作。她使用終端機服務用戶端來執行這個動作，並且為了方便日後連線，她選擇儲存密碼。這麼一來，就產生一個 (也許是兩個) 不當的安全依存性了。第一，她的網域系統管理員帳戶認證現在是受到她自己的低權限資訊工作者認證所保護。如果這個低權限使用者帳戶遭到入侵，網域系統管理使用者帳戶也會受到危害，最後導致整個網域淪陷。
第二個依存性是因為她在非網域控制站輸入網域系統管理認證而產生。除非她的個人工作站受到與網域控制站同級以上的保護 (這大概不可能)，否則就會產生網域控制站仰賴使用者個人工作站安全性的依存性。比方說，如果同一辦公室內有位員工心存不滿，在網路系統管理員的工作站安裝一個按鍵記錄器，這時候就可以擷取到網域系統管理認證。您只要在非網域控制站輸入網域系統管理認證，就等於把整個網域暴露在非網域控制站上所有的安全性漏洞。
假設現在有一個攻擊者在網域系統管理員目前登入、或者曾經登入或者即將登入的電腦上，插入一個卸除式磁碟機，這個網域系統管理員就會遭到入侵，淪陷範圍甚至會延伸到整個網域。所以您非得瞭解這種情況，才能加以防範。當然軟體也一樣，當一個安全應用程式必須仰賴不安全應用程式的功能來執行某些工作時，也會發生同樣的情況。

分析攻擊行為
我之前曾說過，當惡意卸除式磁碟機插入電腦時可能會發生的狀況。不過這也許只在最初有插入磁碟機的電腦，才比較明顯。因此，我們假設那部電腦有加入網域，如 [圖 1] 所示。
[圖 1] 理想的網域依存性
[圖 1] 理想的網域依存性
此處示範的案例是理想的依存性。這些箭頭都有方向，並且是指向依存性的來源。舉個例說，工作站的安全性仰賴網域控制站的安全性，而使用者的安全性仰賴工作站的安全性。攻擊者也許可以入侵工作站，進而入侵使用者放在該工作站的所有資訊，不過會將入侵的範圍隔離起來，限於該處。
但是萬一登入該工作站的使用者，是伺服器上本機 Administrators 群組的成員，而且網域系統管理員也經常登入該伺服器，那麼依存性就變成如 [圖 2] 所示。
[圖 2] 遭到入侵的網域依存性
[圖 2] 遭到入侵的網域依存性
只要變更一下誰登入了那些電腦的假設，整個網路的安全性都會遭受危害。由於網域系統管理員會登入伺服器，因此網域控制站以及整個網域的安全性，都會仰賴該伺服器的安全性。
如果將伺服器管理得網域控制站一樣安全，那就沒什麼關係。但是此處登入該工作站的使用者，是伺服器上 Administrators 群組的成員。因此伺服器的安全性，就得仰賴工作站的安全性。換句話說，整個網域的安全性，完全掌握在工作站的安全性手中。您猜怎麼著？工作站的使用者，竟然就在毫不知情的情況下執行攻擊者的工具。
在現今首重資訊安全性的世界裡，大概找不到比安全依存性更需要深入瞭解的概念。如果您開始分析網路，並且努力瞭解依存性，十之八九都會發現不當的依存性。最糟的情況是 (其實這種情況遠比您想像的更常見)，整個網路的安全性，都得仰賴整個網路 — 換句話說，每一部電腦的安全性，或多或少都要仰賴其他每一部電腦的安全性。因此，在這類的環境裡，不可能有任何適合且實用的風險管理策略，因為要控制當中的關係根本不可能，而複雜性更是難理解。唯有分析並管理依存性才是解決之道。
在本文中，我只簡短介紹依存性的概觀，以及分析和降低依存性的方法。如需更詳細的資訊，不妨參考我的著述《Windows Server 2008 Security Resource Kit》。我有整整一章都在說明如何運用複雜的技術 (例如伺服器與網域隔離) 以及普通的技術 (例如系統管理帳戶管理) 來分析和管理依存性，來保障網路的安全。
感謝 David LeBlanc 的協助，使本文的雛型構想成形。

Jesper M. Johansson 是負責軟體安全性問題的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有 MIS 博士學位，在安全性領域有超過 20 年的經驗。


 桌面檔案: Windows XP 和 Windows PE 2.0 雙重開機
桌面檔案
Windows XP 和 Windows PE 2.0 雙重開機
Wes Miller
下載本文程式碼: Desktop2008_02.exe (151KB)

在上一期的《桌面檔案》中，我曾提到 Windows PE 已變成一種修復工具，另外也說明了如何從第二個磁碟分割來使用它。我最近收到的疑問，讓我聯想到將這進一步發揚光大的作法，可能值得探討一番，那就是併用 Windows PE 2.0 和 Windows XP。
畢竟，諸位讀者中很多人使用 Windows® XP 已有一段時間，而 Windows PE 是 Microsoft 未來繼續支援的版本 (請注意，Windows PE 1.x 將不再有後續的更新)。
Windows PE 1.x 與 2.x 之間重要的差異在於，Windows PE 2.x 可以透過標準開機介面來開機 (Windows PE 1.x 則採用專門的方法)。雖然您可以從第二個磁碟分割來啟動 Windows PE 1.x 或 2.x，但是從您安裝作業系統的同一個開機磁碟分割來啟動，所帶來的便利性有很多潛在的優點，這稍後就會討論到。

Windows 雙開機
Windows NT® 對於雙重開機向來採取相當開放的態度。但是隨著以可延伸韌體介面 (EFI) 為基礎的電腦開始取代舊式 IBM PC AT BIOS 的地位，Microsoft 也跟著改變了 Windows 的開機機制，除了希望與 EFI 更順利搭配運作之外，也希望有一套所有架構通用的開機機制。這套全新的 Windows 開機機制，自 Windows Vista® 開始稱為開機設定資料庫 (Boot Configuration Database)，或 BCD (請參閱 microsoft.com/whdc/system/platform/firmware/bcd.mspx)。不過無論您指的是舊版的 boot.ini 或是新的 BCD 機制，Windows 通常都可以啟動其他作業系統，即使是要將開機處理序交由其他開機載入器進行。
開始前，一定要記住 Windows PE 2.0 只能在同時具有完整進階組態與電源介面 (ACPI) 功能且 384MB (理想是 512MB) RAM 的系統上運作。如我在五月號的專欄 (technetmagazine.com/issues/2007/05/DesktopFiles) 中提到的，非 ACPI 系統將無法啟動 Windows PE 2.0，而且因為 Windows PE 2.0 必須開機到 RAMDisk，所以它需要有足夠的 RAM 來容納 RAMDisk、任何塗銷空間，以及所有的 RAM 工作組。如果您系統的 RAM 低於 384MB，那麼根本不必考慮這種作法，請改用 Windows PE 1.6。即使是有技巧地手動減少 Windows PE 的大小，它也無法在 256MB 上順利運作。

喔，您能解決的問題
我們現在來討論一下，從 Windows XP 的同個磁碟分割啟動 Windows PE 2.0 可以解決哪些問題。
完整系統復原 這只是直接從 Windows XP 磁碟分割啟動 Windows PE 其中一項可行的工作。既然 Windows PE 2.0 (跟它之前的 Windows PE 1.6 一樣) 可以完全開機至 RAMDisk，您便可以重新製作整個磁碟的映像 — 或是使用 ImageX 讓 Windows XP 檔案自行還原，因為沒有必要重新製作整個磁碟分割的映像。
容許使用者在啟動時開機到 Windows PE，他們便能復原自己的系統，甚至是從遠端工作時也可以。這個映像可以來自第二個磁碟分割、網路共用 (適用於非行動使用者)、復原 DVD 或 USB 硬碟，或者若您使用 ImageX 的話，甚至可以將它存放到要復原的磁碟分割上。這類的磁碟上 (on-disk) 復原是許多問題的最佳解決方案 (除了實體磁碟損毀例外)。但除非資料原先有受到保護，然後作為復原的一部分進行還原，否則對於還原使用者資料顯然沒什麼效用。請記住，您應該使用漫遊設定檔並從電腦備份資料，來預防這類的損失。您更應該確保所採用的任何一種復原機制都能為使用者緩和任何可能的資料損失 (包括因 EFS 加密金鑰重設而導致的遺失)。
檔案復原 Windows PE 提供的機制也能在主要安裝的 Windows 不開機時，讓系統順利運作。在這種情況下，您能夠將使用者資料開機和復原到其他系統 (若您已熱備份供使用者使用的系統的話) 或其他位置，讓使用者可以盡快恢復工作。
系統修復 最後，在 Windows XP 上啟動 Windows PE 可讓您執行一組疑難排解指令碼或使用者啟動的簡單修復或復原應用程式，來修復系統。此程序與完整系統復原類似，但它的範圍比較窄 (而且不會危及使用者資料)。
稍微了解在 Windows XP 磁碟分割上啟動 Windows PE 對您有什麼幫助之後，讓我們來看看背後的運作原理，以便將此程序應用到您選擇採用的任一解決方案。

Windows Vista 之前
在 Windows Vista 問世之前，以 BIOS/主開機記錄 (MBR) 為主的系統的開機方式如下：BIOS 指向開機裝置 (以硬碟為例，它會指向磁碟上的 MBR)，MBR 會執行指定要啟動哪個磁碟分割的程式碼。請注意，這是第一個設有使用中旗標的磁碟分割。在最早的 diskpart 版本中，您無法使磁碟分割處於非使用中狀態 (也就是說，您無法移除使用中旗標)。為了修正這個問題，diskpart 裡面添加了一個參數，否則它會是磁碟分割表格順序裡面第一個設有使用中旗標的磁碟分割。磁碟分割包含開機磁區，這會告訴它接下來要執行哪個程式碼。從 Windows NT 到 Windows Server® 2003，要執行的程式碼一直是一個名為 ntldr 的檔案 (沒有副檔名)。如果您曾經格式化磁碟，然後在不安裝 Windows 的情況下嘗試開機，就一定看過「找不到 NTLDR」的錯誤訊息。
您應該很樂於知道 ntldr 完全與舊版相容，但是它當然不與未來版本相容。這表示 Windows XP 的 ntldr 可以啟動 Windows 2000，但反之則不然。這也正是為什麼如果您打算雙重開機，一定要先安裝最舊版的作業系統的原因。再加上 ntldr 並沒有版本編號，因此牢記這一點更是重要。
Ntldr 是真實模式 (16 位元) 應用程式，它會啟動 NTDetect.com，這個 NTDetect.com 會執行基本的裝置偵測，然後啟動核心：ntoskrnl.exe (這可能是好幾個檔案之一 — 永遠重新命名為 ntoskrnl.exe)。核心是 Windows 開機程序的重要元件。
以上簡述的開機程序有點過分簡化，而且我也省略了 Win32® 的整個初始化作業，不過那跟本文的討論範圍無關。如果您想瞭解更詳細的資訊，我建議您閱讀 Mark Russinovich 和 David Solomon 合著的《Windows Internals》第四版 (Microsoft Press®，2004 年)。
另外一件要注意的事，就是當您從 CD 開機時，Windows 安裝程式和 Windows PE 會執行 setupldr.bin 而非 ntldr。這個檔案實際上包含的開機程式碼有點不太一樣，所以才能從 CD 開機 (ntldr 則不能)。這是為什麼在啟動 Windows PE 1.x 時，您必須將 setupldr.bin 重新命名為 ntldr，並把它放到磁碟上的緣故。這也是為什麼檔案之後無法載入 boot.ini 檔案 (因為 setupldr.bin 的設計只能從 CD 開機，結果 boot.ini 被認為是不必要的) 的原因。

Windows Vista 及之後版本
Windows Vista 變更了這個程序的許多部分，而 Windows Server 2008 更是將它改頭換面，它啟用 IA32 (32 位元支援) 從 EFI 開機 — 到目前為止，只有 Itanium 架構系統才辦得到。對於以 BIOS 為主的系統，開機程序的初始步驟大致上保持不變。主要的差別在於，初始化並執行後續步驟的開機載入器是 BOOTMGR。
它會在開機目錄中尋找 BCD 檔案，這實際上是它自己的登錄 Hive。BCD 包含要啟動的開機項目 (包括預設值)。請參閱 [圖 1] 查看映像類型 (可執行檔類型)，並參閱 [圖 2] 查看要啟動的特定應用程式類型。這些項目當中的一個 (或多個) 項目可以作為 ntldr 的參考。但實際上只有一個項目可以參考用來載入 ntldr 已知 GUID (請參閱 [圖 3] 的第五行)。然後 bootmgr 會根據系統是否正在開機、進入休眠或開機至 ntldr 或其他開機管理程式 (在這種情況下，它會指向其他開機磁區，並啟動該載入器)，來決定接下來要載入的項目。如果您是從非 Windows 作業系統進行雙重開機，這是最常見的情況。您可以在 microsoft.com/whdc/system/platform/firmware/bcd.mspx 找到更詳細的資訊。
Figure 3 標準應用程式物件 (Close Figure 3)

描述 | BCDEdit 識別碼 | GUID
Windows 開機管理程式 | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
韌體開機管理程式 | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Windows 記憶體測試器 | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Windows 恢復應用程式 | 無別名 | 147aa509-0358-4473-b83b-d950dda00615
舊版 Windows 載入器 | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
目前開機項目 | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
預設開機項目 | {default} | 無預先定義的 GUID
Figure 2 應用程式類型 (Close Figure 2)

描述 | 值 | 描述
韌體開機管理程式 | 0x1 | 僅適用於 EFI 系統。
Windows 開機管理程式 | 0x2 | 控制開機流程。在雙重開機的系統中，會向使用者顯示開機選項功能表。
Windows 開機載入器 | 0x3 | 載入特定的 Windows 版本或設定。
Windows 恢復應用程式 | 0x4 | 當電腦從休眠狀態恢復時，將 Windows 還原成其執行狀態。
Windows 記憶體測試器 | 0x5 | 記憶體診斷應用程式。
Ntldr | 0x6 | 僅適用於 PC/AT BIOS 系統。載入 Windows Vista 之前的 Windows 版本。
開機磁區 | 0x8 | 16 位元真實模式應用程式僅適用於 PC/AT BIOS 系統。可用來重新啟動開機程序，以及載入非 Windows 作業系統。
Figure 1 映像類型 (Close Figure 1)

描述 | 值
韌體應用程式 | 0x1
開機應用程式 | 0x2
以 Ntldr 為基礎的載入器物件 | 0x3
真實模式應用程式 | 0x4
您會發現到 Windows Vista 改造的開機基礎結構遠比前版更有組織 — bootmgr 外面的所有開機程式碼都是存在根層級 \boot 目錄中，而且是在 BCD 指定這麼做時，交由 Windows 特定的二進位檔處理。

啟動 Windows XP 和 Windows PE 2.0
您可能開始觀察到透過使用 Windows Vista 開機管理程式，Windows PE 如何扮演中間的媒介讓您繼續啟動 Windows XP 或 Windows 早期版本，並同時混合加入 Windows PE 2.0 來作為整合式復原工具。
當然，您需要在開機程序中多加一個步驟，不過這是 Microsoft 設計的步驟。因為全新的 bootmgr 基礎結構需要為現有的 ntldr 和其他協力廠商的開機管理程式提供回溯相容性，所以特別建置 bootmgr 來支援這類的解決方案。
探討過 Windows 開機的方式，以及全新的 BCD 如何運作後，要怎麼結合這兩者，並將 Windows PE 2.0 合併到現有的 Windows XP 安裝呢？要指定 Windows Vista 開機磁區 — 告知系統啟動 bootmgr 的那段開機程式碼 — 的方法有二。其中一種方法是使用 diskpart，建立和格式化一個新的 Windows PE 2.0 磁碟分割。但這個選項在此處並不可行，因為您並不想損毀或移動現有的 Windows XP 安裝。因此，請改採這個程序：
  1. 確定您在 Windows PE 2.0 開機 CD 上有 bootsect.exe 和 bcdedit.exe 的複本 (您可以在 Windows Vista 安裝 DVD 上找到這兩個檔案)。
  2. 將 Windows XP 系統開機到 Windows PE 2.0 CD。
  3. 開機後，馬上執行此命令：
    bootsect.exe /NT60 ALL
這會將開機磁區設成與 Windows Vista 相容且知道如何啟動 bootmgr 的開機磁區。
4. 將開機管理程式複製到硬碟：
    xcopy BOOTMGR C:\BOOTMGR /I
5. 將 boot.SDI 檔案複製到硬碟上的 \BOOT 目錄。您必須在開機前先複製這個檔案的副本，因為在執行 Windows PE 時，這個檔案會鎖定起來而且無法複製：
    xcopy BOOT.SDI C:\BOOT\
適當地修正來源路徑。
6. 將 boot.WIM 複製到硬碟。就跟 SDI 一樣，您應該準備次要複本，因為您將無法複製從以下命令執行的這個檔案：
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
適當地修正來源路徑。
7. 現在，建立新的 BCD 存放區：
    bcdedit /createstore
8. 接下來，建立 BCD 項目以載入 Windows PE：
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. 最後一行將傳回 GUID。以實際傳回的 GUID 取代 {YOURGUID}。這些是 RAMDisk 從您的硬碟啟動 Windows PE 的項目，如 [圖 4] 所示。
Figure 4 從硬碟啟動 Windows PE 的 RAMDisk 項目 (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. 現在，建立 bootmgr 項目，讓開機管理程式啟動：
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. 最後，針對現有 Windows 安裝設定 BCD 項目 (將顯示文字從 Windows XP 變更為您希望在開機管理程式開機功能表中顯示的任意文字)。最後一個命令也會將它設定為開機功能表中的第一個 (預設) 項目：
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. 您現在應該可以重新啟動您的系統，並選擇適當的開機功能表項目，讓它啟動之前安裝的 Windows 或 Windows PE 2.0。[圖 5] 顯示 bcdedit / enum all 的範例輸出。這個命令會列出加入項目 (這是從 Windows PE 1.6 裡面加入的) 後在 BCD 中的全部項目。
範例輸入
我還在努力設計一個可以自動執行這項工作的指令碼。目前它只能將開機檔案複製到硬碟，然後設定 BCD 項目。它無法在執行 Windows 的同時將開機磁區設成新的 Windows Server 2008 值 — 這必須在 Windows PE 中以離線狀態進行。您可以在 TechNet Magazine 網站的程式碼下載區找到這個指令碼，網址是 technetmagazine.com。若要執行這個指令碼，您應該將下列項目放在執行 VBScript 的同個目錄中：
  1. BCDEdit
  2. BOOTMGR
  3. \BOOT\ 目錄 (從 Windows Vista 或 Windows PE 2.0 媒體)
  4. 含有效、可開機 Windows PE 2.0 BOOT.WIM 檔案的 \SOURCES\ 目錄
它會建立 BCD，然後複製適當的開機檔案。開機到 Windows PE 並執行 bootsect 之後，您應該就能夠雙重開機。

復原雙重開機
復原雙重開機比設定它還要簡單，您只要執行下列命令，將開機磁碟還原為先前的 Windows Vista 開機磁區就行了：
bootsect.exe /NT52 ALL
一經還原後，就可以刪除 bootmgr 和 \boot 目錄。在下次重新開機時，開機磁區會改成強制 ntldr 啟動，並將 Windows PE 2.0 和所有的 Windows Vista 開機二進位檔完全從開機流程移除。

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


 現場筆記: 樂捐您的電腦
現場筆記
樂捐您的電腦
Jim Lynch

多年來，大眾 認為最符合經濟效益的電腦處置方式，以 Gartner Group 的 Frances O'Brien 於 2003 年發行的研究報告《PC Disposal:TCO's Last Surprise》描述的最貼切。這份電腦處置方式的比較分析指出在六種處置選項中，捐贈設備是最昂貴的一種，因為它要花費漫長的時間尋找願意接受捐贈的適當慈善組織。
捐贈秘訣
TechSoup.org 在 techsoup.org/recycle 網站上提供一些捐贈的秘訣，並在此接受捐贈。捐贈前需要考量的事項包括：
  • 升級到新硬體之後，就別再緊抓著 IT 設備不放。電腦設備在五年後便會喪失重複使用的價值。同樣地，行動電話的使用壽命通常在三年後結束。
  • 將壽命短於五年的 IT 設備捐贈給回收站，而不要直接送至非營利機構或學校。
  • 將設備的配件一同打包，包括鍵盤、滑鼠、印表機、數據機、軟體光碟以及設備隨附的手冊。
  • 保存一份捐贈明細的記錄，並索取收據。如果捐贈對象是非營利回收站，您可能享有減稅資格。在美國，企業捐贈者可減免電腦的未折舊價值，個人則可減免電腦的當前市值。若要查詢電腦的公平市價，請參閱加拿大免費的二手電腦估價工具 (Used Computer Evaluator) (servlets.edeal.com/servlets/PcEval)。

今日的情勢已大為改觀。事實上，美國環保署近來正推行一項新活動叫做「Do the PC Thing」，藉此教育使用者如何整理要回收使用的舊硬體，並提供一份資源清單。您可以在美國環保署的電子產品回收及重複使用公眾意識網站「Plug-In To eCycling」(epa.gov/plugin/) 中找到這項活動的資訊。按一下 [Reuse It!]連結，即可閱讀專為消費者或企業所撰寫的文章。
在這個網站中，您將瞭解到在捐贈或回收硬體時，第一要務就是保障自身的安全。「Do the PC Thing」的文章會點出清除硬碟內容以及資料安全性與機密性法規需求的相關基本知識。無論您處置電腦的目的是使用壽命終了而回收電腦，或為了重複使用電腦，都必須移除您的機密資料，例如密碼、文件、信用卡資料、電子郵件訊息及網頁記錄。
大部分的電子產品回收業者、回收站與資產管理公司都提供資料安全性服務，所採用的方式通常是摧毀硬碟或使用磁碟清理軟體公用程式來覆寫資料，讓資料無法復原。要注意的是，如果您將電腦標明為要回收，最好是保持電腦硬體的完整性。
可靠的磁碟清理軟體都遵循美國國防部 5220.22-M 規範。這種以軟體為基礎的資料清理作業會有系統地使用單一字元覆寫硬碟上所有可定址的位置，驗證覆寫，然後再次使用隨機字元來覆寫所有可定址的位置。美國國家安全局於 2004 年 (NSA Advisory LAA-006-2004) 發現使用國防部標準軟體執行單次覆寫就足以讓電子檔案無法復原。
現在打理您自己的資料安全性可說是非常容易。市面上有許多可靠的免費應用程式，例如 Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm) 或 Darik's Boot and Nuke (dban.sourceforge.net)。如果您有多台電腦需要清理資料，不妨考慮使用更可靠的商業應用程式，像是 Blancco Data Cleaner (blancco.com) 或 WipeDrive (whitecanyon.com)。
若您的 IT 設備已超過五年以上或已殘破不堪，在 Gartner 訪查的六個處置選項中，有一項是使用壽命結束的電子產品回收。現在全美有超過 900 家公司正推行這項運動。為了正確回收老舊 IT 設備，請參閱電子回收聯盟 (Electronic TakeBack Coalition) 所提供的正派回收業者清單 (www.computertakeback.com/the_solutions/recyclers_map.cfm)。

Jim Lynch 在 TechSoup.org 擔任電腦回收和再利用的專案主管，這是一家位於舊金山的非營利高科技機構，以提供成本低廉的硬體、軟體和實用知識給世界各地的慈善機構為使命。


 Windows 機密文件: 去蕪存菁
Windows 機密文件
去蕪存菁
Raymond Chen

雖然這種情況並不多見， 但舊功能偶爾還是會被剔除，而且產品小組一致叫好。以 Windows® XP 為例，設定桌面圖案的介面就被移除了。不過只要您有辦法撰寫程式來呼叫 SystemParametersInfo(SPI_SETDESKPATTERN)，仍舊能夠使用基本功能，但是系統已經不提供這項功能的內建介面。桌面圖案為何會從桌面控制台中移除？
我們的研究調查指出幾乎沒有人在使用桌面圖案。在記憶體費用昂貴的年代，桌面圖案比較受歡迎，因為使用者不想將四分之一的電腦記憶體浪費在 1MB 的底色圖案點陣圖上。在畫面上重複顯示的小小 8×8 單色圖案能夠為 640×480 顯示增添一定程度的個人化風格。
然而，這些年來的變化使得桌面圖案越來越乏人問津。首先當然是因為現在的電腦比起 1983 年擁有多更多的記憶體，其次 (這也是理所當然的)，現在的螢幕跟過去比起來是更高的解析度執行。基本上，可愛的 8×8 千鳥格紋圖案在 1600×1200 螢幕上只會變成模糊的灰色斑點。
這不是唯一被丟入垃圾堆的舊功能，還有剪輯資料。Windows 95 引入的剪輯資料，是以擷取至檔案的文件片段的形式呈現。此檔案片段其實是一個 OLE 物件。剪輯片段背後的用意是，比方說，您可以在文書處理器中反白顯示某些文字，然後將這些文字拖曳到桌面，並在此建立剪輯資料。稍後，您可以取用該剪輯資料，將之拖曳回文書處理器或一些其他程式中，而您用來建立此剪輯資料的文字便會插入新的文件中。這有點類似複製並貼上，只不過文字會儲存在檔案中，而非暫存在剪貼簿上。
當您建立這種剪輯資料檔案後，您唯一能夠執行的動作就是將它拖曳到另一份文件中，就像您只能將剪貼簿上的內容貼到他處一樣。曾經還有人新增一項功能，讓您按兩下剪輯資料檔案，接著該檔案便會在原本建立此剪輯資料的應用程式中開啟 (內容五花八門，因此顯示剪輯資料的唯一方法就是要求最初建立資料的程式)。
我不清楚加入這項功能的目的是要作為偵錯工具，還是為了讓使用者不必建立虛擬文件來拖曳資料，就可以查看剪輯資料中的內容。無論如何，病毒作者愛死了這項「開啟原本建立此剪輯資料的應用程式」的功能，因為他們可以藉此建立一個剪輯資料檔案，然後填入以下資料：「原始應用程式為 cmd.exe，且文件片段就是這個批次檔」。若有人按兩下那個特定剪輯資料檔案來查看其內容，剪輯資料檢視器便會將批此檔交給命令處理器，並告知「請開啟此檔案，並顯示給使用者檢視」。
有鑑於剪輯資料的不良記錄，命令介面小組決定在 Windows Vista® 移除這項功能。要這麼做，小組必須調查剪輯資料在真實世界中的受歡迎程度。於是，命令介面小組要求產品支援群組收集群組的記錄，查看曾經來電詢問剪輯資料相關問題的人數。理論上來說，受歡迎的功能會收到支援電話，不受歡迎的功能則否 (因為無人使用)。尤其是剪輯資料並不屬於「全憑直覺式」的功能類別，因此來電次數不多並不能解讀為：「這項功能太簡明易懂，因此大家都不需要來電尋求幫助！」
產品支援群組的回覆如下，過去一年來，群組總共接獲四通來電。而且這些來電全都提出類似問題：「我建立了一個奇怪的檔案，這是什麼東西，我要如何擺脫它？」

Raymond Chen的網站「The Old New Thing」以及同名著作 (Addison-Wesley，2007 年) 均探討 Windows 的歷史和 Win32 程式設計。距離 Raymond 上次和您見面已經好一段時間，Raymond 向您的家人問好。