 TechNet Magazine February 2007

TechNet Magazine February 2007

Windows 系統管理: 深入探索 Windows Vista 核心：第一篇

Windows Vista 對 OS 核心所做的變更在許多方面帶來若干進步，範圍涵蓋記憶體管理、可靠性、安全性等等。做為此系列的第一篇文章，讓我們先來了解核心如何在處理序、執行緒和 I/O 等方面提升效能。

Mark Russinovich Windows 系統管理: 在 Active Directory 中委派權限

在 Active Directory 中實作委派可以增強安全性並簡化管理工作，讓您更輕鬆入門。以下是一些簡單的委派模型，只需稍加修改就可以應用於大部分 IT 基礎結構中。

Joel Yoker and Rob Campbell Windows 系統管理: 深究 Windows Vista 新增的群組原則範本

Windows Vista 已大幅修改群組原則範本。您可以從此處瞭解到 ADMX 這種新的格式，以及這些變更將如何改善系統組態的管理。

Darren Mar-Elia Windows 系統管理: 群組原則疑難排解指南

要追根究底群組原則問題是很困難，但是要了解群組原則如何運作及可能發生問題之處就容易多了。本概觀將幫助您成為群組原則問題疑難排解的高手。

Derek Melber Windows 系統管理: 使用 MOM 來監視 Active Directory

Microsoft Operations Manager 2005 的管理套件可讓您更有效地監視 IT 基礎結構。我們來看一下這五個管理套件如何幫您監控 Active Directory 環境的健康狀態、安全性及可靠性。

John Hann Windows 系統管理: 在安全的環境中遊戲

不論您正在勤奮工作，或是在家認真玩遊戲，只要以限制權限使用者身分執行，就可以擁有更多安全性的保障。可惜的是，有許多遊戲都無法在非系統管理員身分下執行。以下就來看看一些常見的問題和解決方法。(本文含有連至英文網站的連結)

Matt Clapham 編輯的話: 揭開面紗

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

Greg Steen SQL 問題與解答: 資料庫大小、鏡像、標示的交易…等等

Edited by Nancy Michell 公用程式焦點: Group Policy Inventory

Greg Steen The Cable Guy: Windows 中的 QoS 支援

Joseph Davies Windows PowerShell: 一次編寫一行指令碼

Don Jones 嗨，Scripting Guy！: 對於追車… 還有 XML 的迷戀

The Microsoft Scripting Guys 安全性監控: 部署 EFS：第一篇

John Morello 桌面檔案: 擴充 Windows PE

Wes Miller 現場筆記: 就是無法使用

R'ykandar Korra'ti Windows 機密文件: 幾家歡樂幾家愁

Raymond Chen


 Windows 系統管理: 深入探索 Windows Vista 核心：第一篇
Windows 系統管理 Mark Russinovich

深入探索 Windows Vista 核心：第一篇
摘要:
  • 執行緒優先順序和排程
  • 檔案架構符號連結
  • 取消 I/O 作業

這是有關 Windows Vista 核心新功能一系列文章的第一篇。在這篇文章中，我們要看看處理序、執行緒和 I/O 等方面有哪些改變。未來幾期的文章將涵蓋記憶體管理、啟動和關閉、可靠性和修復及安全性。
本文的範圍只包括對 Windows Vista™ 核心的變更，尤其是 Ntoskrnl.exe 及其密切相關的元件。請記住，Windows Vista 有許多核心以外的其他重要變更不在此討論範圍內。這包括對 Shell (例如整合式桌面搜尋)、網路功能 (如新的 IPv6 堆疊和雙向防火牆) 及下一代繪圖模型 (例如 Aero™ Glass、Windows® Presentation Foundation、桌面視窗管理員和新圖形驅動程式模型) 的改進。此外，新的 Windows 使用者模式和核心模式驅動程式架構 (UMDF 和 KMDF) 也不包括在內，因為這些都可以逆向安裝在舊版 Windows 上。

CPU 循環計數
Windows Vista 增強了部分的處理序和執行緒功能，包括使用 CPU 循環計數器來達到更公平的 CPU 配置，以及新的多媒體類別排程器服務 (Multimedia Class Scheduler Service，MMCSS) 來幫助媒體應用程式呈現無瑕疵播放。
包括 Windows Vista 以下的所有 Windows NT® 設計間隔計時器插斷常式大約每隔 10 或 15 ms (毫秒) 執行一次 (視硬體平台而定)。此常式會檢查它插斷的執行緒並更新該執行緒的 CPU 使用量統計值，就好像該執行緒已執行了整個間隔之久，而實際上該執行緒可能是在該間隔結束之前才開始執行。不僅如此，可能在技術上已指派 CPU 給該執行緒，但因為執行了硬體和軟體插斷常式，反而沒有機會執行該執行緒。
雖然時鐘型時間計量對於報告執行緒和處理序 CPU 使用量的診斷工具而言沒有問題，但執行緒排程器使用該方法會造成不公平的 CPU 配置。在 Windows 的用戶端版本上，預設准許執行緒執行最多 2 個時鐘刻度 (如果是在幕前執行，則為 6 個刻度)。不過，執行緒實際上可能未得到 CPU 任何時間或最多得到 6 個刻度 (如果是在幕前執行，則為 18 個刻度)，視它在系統上的行為和其他活動而定)。
[圖 1] 顯示當兩個具有相同優先順序的執行緒同時準備好執行時可能會發生的不公平情況。執行緒 A 會執行到下一個時間配量間隔到期，而排程器卻假設它已執行了整個間隔之久，因而判斷執行緒 A 已執行完畢。不僅如此，讓執行緒 A 負責承擔在輪到它的期間內所發生的插斷，這是不公平的。在下次間隔時，排程器會選擇由執行緒 B 接管，並執行到整個間隔結束為止。
圖 1 不公平的執行緒排程
圖 1 不公平的執行緒排程
在 Windows Vista，排程器使用現代處理器的循環計數器登錄來準確追蹤一個執行緒執行的 CPU 循環次數。藉由評估 CPU 在一個時鐘間隔內可以執行的循環次數，可以更準確地在 CPU 上進行分配。此外，Windows Vista 排程器不會將執行緒執行期間的插斷執行計算在內。這表示在 Windows Vista 上，執行緒至少會輪到一次 CPU，但絕不會超過一次額外執行的時鐘間隔，以達到更好的公平性及更確定的應用程式行為。[圖 2] 顯示 Windows Vista 提供兩個執行緒至少一個時間配量的執行間隔，以回應 [圖 1] 所顯示的狀況。
圖 2 Windows Vista 循環式排程
圖 2 Windows Vista 循環式排程
[監看處理序 CPU 使用量] 資訊看板說明如何使用 Process Explorer 公用程式自行監視處理序 CPU 循環使用量。

多媒體類別排程器服務
使用者期望多媒體應用程式 (包括音樂和視訊播放程式) 能夠提供完美的播放體驗。不過，其他同時執行的應用程式 (如防毒軟體、內容檢索程式或甚至郵件用戶端) 對 CPU 的需求可能會引起你我所不樂見的一些風波。為了提供更好的播放體驗，Windows Vista 引進 MMCSS 來管理多媒體執行緒的 CPU 優先順序。
多媒體應用程式 (如 Windows Media® Player 11) 使用可指出其多媒體性質的新 API 在 MMCSS 中登錄，這些多媒體性質必須符合下列登錄機碼之下按名稱列出的其中之一：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks
圖 A在 Process Explorer 中檢視 CPU 時間和循環差異

圖 3 多媒體類別排程器音訊工作定義
圖 3 多媒體類別排程器音訊工作定義
實作於 %SystemRoot%\System32\Mmcss.dll 中並執行於 Service Host (Svchost.exe) 處理序中的 MMCSS，有一個優先順序管理執行緒是以優先順序 27 執行 (Windows 中的執行緒優先順序範圍是從 0 到 31)。這個執行緒將已登錄的多媒體執行緒優先順序增加到與其工作的登錄機碼的 Scheduling Category 值相關聯的範圍，如 [圖 4] 所列。在 Windows 中，執行緒優先順序 16 以上是在即時優先順序範圍內，高於系統上的所有其他執行緒 (但核心的記憶體管理員工作者執行緒例外，它是以優先順序 28 和 29 執行)。僅系統管理帳戶 (如 MMCSS 執行時所用的本機系統帳戶) 具有「增加優先順序」權限，這是要設定即時執行緒優先順序所需要的權限。
Figure 4 MMCSS 執行緒優先順序 (Close Figure 4)

排程類別 | 增加的執行緒優先順序
高 | 23-26
中 | 16-23
在播放音訊檔時，Windows Media Player 會登錄音訊工作執行緒，當您播放視訊時，它會登錄播放工作執行緒。若執行緒指出它們正在傳遞資料流，且同時在擁有幕前視窗的處理序中執行，並且已在其工作的定義機碼中將 BackgroundOnly 值設為 True，此時 MMCSS 服務會增加所有這些執行緒的優先順序。
但雖然 MMCSS 想要幫助多媒體執行緒取得它們所需要的 CPU 時間，它也想要確保其他執行緒至少可取得一些 CPU 時間，使系統和其他應用程式可以保持回應性。因此，MMCSS 保留一定的 CPU 時間百分比給其他活動使用，如下列登錄值所指定：
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
此值預設為 20%；MMCSS 會監視 CPU 使用量，以確保萬一其他執行緒需要 CPU 時，多媒體執行緒不會在 10 毫秒的期間內增加超過 8 毫秒。為了在剩餘 2 毫秒內擺脫多媒體執行緒，排程器使其優先順序掉到 1-7 範圍。
您可以看看 [監看 MMCSS 優先順序增加] 資訊看板，以了解 MMCSS 如何增加執行緒優先順序。

檔案架構符號連結
Windows Vista I/O 相關變更包括檔案架構符號連結、更有效的 I/O 完成處理、對於 I/O 取消作業的全面支援以及優先順序處理的 I/O。
許多人認為 NTFS 所缺少的一項檔案系統功能 – 符號檔案連結 (或是 UNIX 所謂的暫時連結) – 最後終於出現在 Windows Vista 中。NTFS 的 Windows 2000 版本引進的符號目錄連結叫做目錄連接，它可讓您建立一個指向不同目錄的目錄，但直到 Windows Vista 版本誕生，NTFS 才支援檔案永久連結。
Windows 解析符號連結和目錄連接的方式，其主要差異在於進行處理的位置。Windows 是在本機系統上處理符號連結，即使它們參考遠端檔案伺服器上的位置也一樣。Windows 處理的目錄連接是參考伺服器本身的遠端檔案伺服器。因此，伺服器上的符號連結可以參考只能從用戶端存取的位置，如其他用戶端磁碟區，而目錄連接則不行。為了解決此問題，Windows Vista 同時為檔案和目錄提供新的符號連結類型支援。
許多檔案系統命令已更新，以方便了解符號連結的含意。例如，Delete 命令知道不要遵循連結，以免刪除目標，但會刪除連結本身。不過，由於並非所有應用程式都能夠正確處理符號連結，因此要建立符號連結需要有新的「建立符號連結」權限，預設只有系統管理員才具有此權限。
您可以在命令提示字元中使用 Mklink 命令來建立符號連結。命令提示字元的內建目錄命令識別符號連結的方式是將它標示為 <SYMLINK>，並以方括弧顯示目錄，如 [圖 5] 所示。Windows 檔案總管也可以識別符號連結，並以快顯箭號顯示它們。您可以將 [連結目錄] 欄位新增至瀏覽視窗中，即可在檔案總管中看到連結的目錄。監看 MMCSS 優先順序增加
您可以播放一段視訊或音訊、執行效能監視器、將圖形比例設定為 31 (最高 Windows 執行緒優先順序)，並將 Windows Media Player (Wmplayer.exe) 執行緒物件的所有例項的 Priority Current 計數器新增至顯示畫面上，來目睹 MMCSS 服務套用至 Windows Media Player 執行緒的執行緒增加情形。一個或多個執行緒會以優先順序 21 執行。
圖 BWindows Media Player 的執行緒優先順序增加情形

圖 5 使用 Mklink 建立符號連結
圖 5 使用 Mklink 建立符號連結

I/O 完成和取消
I/O 系統有一些內部變更可改進伺服器應用程式的效能。這些應用程式通常使用一個叫做完成通訊埠的同步處理物件，等待非同步 I/O 要求完成。在 Windows Vista 之前，當 I/O 完成時，發出 I/O 的執行緒會執行一項 I/O 完成工作，而導致切換到該執行緒所屬的處理序並插斷其他正在進行的工作。然後，I/O 系統會更新完成通訊埠狀態，以喚醒等待其變更的執行緒。
在 Windows Vista 上，I/O 完成處理作業不一定要由發出 I/O 的執行緒執行，可改由等待完成通訊埠喚醒它的執行緒來執行。這項小小的變更避免因不必要的執行緒排程和內容切換而導致應用程式和系統整體效能下降。若要進一步改進效能，伺服器可以從一個要求的完成中擷取多項 I/O 作業的結果，避免轉換到核心模式。
從使用者角度來看，I/O 系統最明顯的變更可能是 Windows Vista 對於取消同步 I/O 作業的支援。如果您曾經執行過 net view 命令或嘗試使用 Windows XP 或 Windows Server® 2003 存取離線遠端系統的共用檔案，一定遇過無法取消 I/O 作業的問題：該命令或檔案瀏覽器無回應，直到網路逾時過期為止。應用程式別無選擇，只能枯等作業失敗，因為它無法告知執行此 I/O 的裝置驅動程式不要處理此 I/O 了。
在 Windows Vista 中，大部分 I/O 作業都可加以取消，包括 Net View 和 Explorer 使用的開啟檔案 I/O。不過，應用程式必須更新才能回應使用者取消 I/O 的要求，而且，許多與具有逾時設定的裝置互動的 Windows Vista 公用程式都有必要的支援。例如，幾乎每一個 Windows 應用程式都會用到的檔案開啟和儲存對話方塊，包括協力廠商應用程式在內，現在都可以在嘗試顯示資料夾內容時啟用其 [取消] 按鈕。當您按 Ctrl+C 時，Net 命令也可以取消其同步 I/O。
您可在 Windows Vista 上開啟命令提示字元並輸入下列命令，即可了解 I/O 取消作業的好處：
net view (\\nonexistentmachine)
當 Windows 嘗試連絡不存在的系統時，此命令會擱置，但您可以輸入 Ctrl+C 來終止它。在 Windows XP，Ctrl+C 沒有作用，且該命令要等到網路作業逾時為止才會傳回。
在 Windows 舊版中，還有另一種 I/O 類型造成使用者問題，亦即，裝置驅動程式因為不易得知是否應該取消而未能適當取消的 I/O 作業。如果您曾經終止一項處理序，但後來又看到它在處理序檢視工具中不當延遲，您就會目睹裝置驅動程式不但未回應處理序終止，還取消了尚未完成的處理序所發出的 I/O。Windows 會等到該處理序的所有 I/O 都已完成或取消之後，才會執行最終處理序清除。在 Windows Vista 中，裝置驅動程式很容易登錄處理序終止的通知，因此大部分無法刪除的處理序問題都能迎刃而解。

I/O 優先順序
雖然 Windows 一向支援 CPU 使用量的優先順序處理，但並未納入 I/O 優先順序的概念。沒有 I/O 優先順序，搜尋檢索、病毒掃描和磁碟重組之類的幕後活動可能嚴重影響幕前作業的回應性。例如，當使用者啟動應用程式或開啟文件時，若有另一項處理序正在執行磁碟 I/O，使用者會發現幕前工作在等待磁碟存取時速度變慢。相同的干擾也會影響硬碟多媒體內容 (如歌曲) 的資料流播放。
Windows Vista 引進兩種類型的 I/O 優先順序處理，以幫助幕前 I/O 作業獲得青睞：個別 I/O 作業和 I/O 頻寬保留的優先順序。Windows Vista I/O 系統內部包括五種 I/O 優先順序的支援，如 [圖 6] 所示，但只使用其中四種優先順序 (未來 Windows 版本可支援 [高] 優先順序)。
Figure 6 Windows Vista I/O 優先順序 (Close Figure 6)

I/O 優先順序 | 使用量
緊急 | 記憶體管理員
高 | 未使用
一般 | 預設優先順序
低 | 預設工作優先順序
非常低 | 幕後活動
I/O 的預設優先順序是 [中]，而在低記憶體情況下，記憶體管理員想要將更動過的記憶體資料寫至磁碟時會使用 [緊急] 優先順序，以騰出 RAM 的空間來存放其他資料和程式碼。Windows 工作排程器會將有預設工作優先順序的工作的 I/O 優先順序設為 [低]，而針對 Windows Vista 撰寫來執行幕後處理的應用程式所指定的優先順序為 [非常低]。所有 Windows Vista 幕後作業，包括 Windows Defender 掃描和桌面搜尋檢索在內，都使用 [非常低] I/O 優先順序。查看非常低 I/O 優先順序
Process Monitor 是來自 Sysinternals 的一個即時檔案系統及 Registry 監視公用程式，它收集檔案系統讀寫作業的詳細資訊，包括它們在 Windows Vista 上的 I/O 優先順序。反白行顯示由 SuperFetch 發出的非常低優先順序 I/O 的範例 (我會在下一期的文章中討論它)。
圖 C在 Process Monitor 中檢視非常低 I/O 優先順序

系統儲存類別裝置驅動程式 (%SystemRoot%\System32\Classpnp.sys) 會強制執行 I/O 優先順序，因此這些優先順序會自動套用至大部分儲存裝置指示的 I/O。類別和其他儲存驅動程式在其佇列中會將 [中] I/O 插入到 [低] 和 [非常低] 的 I/O 前面，但每秒至少會發出一個等待中的 [低] 或 [非常低] I/O，使幕後處理序能夠有所進展。使用 [非常低] I/O 讀取的資料也會使快取管理員立即將修改寫入磁碟，而不會延後寫入，並且在讀取作業中略過它的預先讀取邏輯，而不會從存取的檔案中預先讀取。請參考 [查看非常低 I/O 優先順序] 資訊看板，其中有關於使用 Process Monitor 公用程式的 [非常低] I/O 優先順序的範例。
Windows Vista 頻寬保留支援對於媒體播放應用程式很有幫助，Windows Media Player 使用它再配合 MMCSS 優先順序的增加，來呈現幾乎無瑕疵的本機內容播放。媒體播放應用程式會要求 I/O 系統保證它有能力在指定的速率下讀取資料，如果裝置可以在所要求的速率下傳遞資料，且現有的頻寬保留也接受的話，它會指導應用程式要在何種速度下發出 I/O 及應該具備的 I/O 大小。除非 I/O 系統可以滿足已在目標儲存裝置上做了保留的應用程式的需求，否則不會為其他 I/O 提供服務。
I/O 系統最後一項值得一提的改變與 I/O 作業的大小有關。從 Windows NT 第一版開始，記憶體管理員和 I/O 系統就把每一個儲存 I/O 要求處理的資料量限制為 64KB。因此，即使應用程式發出更大的 I/O 要求，也會分割成最大大小為 64KB 的個別要求。每一項 I/O 要轉換為核心模式以及在儲存裝置上起始 I/O 轉送時都會招致額外負荷，因此在 Windows Vista 中，不再壓低儲存 I/O 要求大小。有幾個 Windows Vista 使用者模式元件已經過修改，可利用更大 I/O 的支援，包括檔案總管的複製功能及命令提示字元的 Copy 命令，它現在可發出 1MB I/O。

接下來
現在您已經看到 Windows Vista 核心在兩方面的加強。您會在我的著作 Windows Internals (共同執筆者為 David Solomon) 的下一版看到更多深入資訊，此書預定與下一版的 Windows Server (名稱代碼 "Longhorn") 同時發行。在下一期的文章中，我會繼續介紹新核心，討論記憶體管理及系統啟動和關閉。

Mark Russinovich 是 Microsoft 平台服務事業群 (Platform and Services Division) 的技術人員。他是 Microsoft Windows Internals (Microsoft Press, 2004) 的共同執筆者，經常在 IT 和開發人員會議上發表演說。身為 Winternals Software 公司的共同創辦人，隨著 Microsoft 最近併購該公司，他也一同加入 Microsoft。他也創立了 Sysinternals，並在該公司發行 Process Explorer、Filemon 和 Regmon 等公用程式。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 Windows 系統管理: 在 Active Directory 中委派權限
Windows 系統管理 Joel Yoker and Rob Campbell

在 Active Directory 中委派權限
摘要:
  • 定義系統管理角色
  • 開發 OU 和安全性群組模型
  • 使用次要帳戶
  • 委派權限的工具

Active Directory 中的委派功能相當強大，不但可以解決一些安全性問題，而且能夠簡化管理工作。藉由在 Active
Directory® 內適當地委派權限，您可以在環境中強制執行指定的角色、限制管理錯誤發生的可能性及其帶來的影響，以及在整個基礎結構中套用最低權限的原則。然而，還有許多依賴 Active Directory 的組織尚未感受到委派的強大功能。在某種程度上，這是因為開發適合您企業的 Active Directory 委派模型表面上看起來好像很複雜。若要開發一個符合您組織獨特需求的委派模型的確有困難之處，但其實有一些非常簡單的模型只要稍加修改，就可以套用到大部分 IT 基礎結構中。
雖然每一個環境都有某方面的不同，實際上大部分的大型企業在許多方面是類似的，而且也都面臨相同的 IT 挑戰。例如，許多組織劃分成幾個地理區域，由不同的 IT 工程小組或作業支援小組發展而成，而且都有獨立的業務單位。許多大型組織也必須處理權限提升、服務帳戶濫用以及「信任」之類的問題。
「信任」是一個很有趣的詞彙，它往往變成擁有多個 Active Directory 樹系的理由。信任問題常肇因於一個部門或地區對另一個部門或地區之系統可用性的影響能力。位於不同地區的組織單位之間往往會有不同的技術層級，而缺乏對特定系統的深層認知，導致無法支援特定的地區或業務單位，也是很常見的。因此，公司的各個部門通常都不願意將其管理權限轉讓給中央單位。
同時，在任何 Active Directory 實作中，系統管理員必須對使用 Active Directory 基礎結構的應用程式定義參與規則。只可惜通常在應用程式安裝指南中引用的一般方法是將服務帳戶設定成 Domain Admins 群組的成員。此方法的問題在於服務帳戶基本上就是通用帳戶。如果對這些帳戶授與網域系統管理員權限，則會對 IT 環境造成重大的威脅。這些服務帳戶容易遭到惡意或粗心的系統管理員不當使用，也有可能遭受在應用程式內引發基礎安全性問題的攻擊者所利用。
這些困難似乎無法克服，它們代表了實作 Active Directory 委派模型的最佳案例。開發委派模型是一種反覆的設計流程，建議您遵循下列步驟進行：
  1. 定義組織內的 IT 系統管理角色。
  2. 開發組織單位 (OU) 和安全性群組模型。
  3. 建立 IT 系統管理員的次要帳戶。
  4. 委派權限。
現在就來看看這些步驟的細節。

定義角色
角色定義流程的第一步是徹底了解服務管理和資料管理。這些概念是任何 Active Directory 委派模型的基石。
服務管理的核心是管理關鍵目錄服務基礎結構元件，例如 Exchange 伺服器和網域控制站。資料管理則是管理物件，例如位於這些服務內的信箱和使用者帳戶。在 Active Directory 的範圍內，服務管理員最後負責傳遞目錄服務並確保其可用性，而資料管理員則負責管理使用者和伺服器帳戶、群組以及其他網域資源。
Active Directory 支援透過組織單位 (OU) 進行細微的權限委派。您可以經常修改 OU 來提供現有目錄服務或網域模型內適用於系統管理員的相同權限等級。但務必了解某些功能根本無法委派，且必須由單一受信任群組或實體加以管理。
工作分析也很重要。您必須知道系統管理員執行哪些 Active Directory 工作，以及這些工作如何對應至角色。例如，Active Directory 站台建立是屬於服務管理工作，而安全性群組成員資格的修改通常是屬於資料管理工作。每一個工作的頻率、重要性及難易度都應該加以評估。這些是工作定義的重要部分，因為它們對於是否應該委派權限具有決定性的影響。例行工作的風險有限且容易完成，是很好的委派對象。相反地，很少執行的工作對組織有重大影響，且需要較高技術層級，不是好的委派對象。提升權限 (暫時將帳戶提升至必要的角色或重新指派工作) 反而才是這些工作的正確途徑。
由於大型組織的許多特性相似，因此可以放心假設一般委派模型可供實作。基於本文的目的，我們將在遵守組織界限及嘗試減少信任問題方面 (例如針對網域控制站之類的泛企業資產的可用性)，提供一組啟用管理功能的範例角色。請注意，此模型只是一個範例，雖然它對於組織內的角色討論是一個很好的開始，但請不要將這份指引照單全收。
Active Directory 已定義一些角色，但某些角色必須重頭開始建立，才能完成委派模型。適合許多大型 Active Directory 環境的一組範例角色包括：Enterprise Admins、Domain Admins 和 Tier4 Admins (適用於服務管理)，以及 Tier3 Admins、Regional Admins、Tier2 Admins 和 Tier1 Admins (適用於資料管理)。如需這些角色及其責任的清單，請參閱 [圖 1]。
Figure 1 定義角色和責任 (Close Figure 1)

服務管理員 | 描述
Enterprise Admins | 負責企業最上層服務管理。不應該包含永久成員。
Domain Admins | 負責整個網域的最上層服務管理。應該僅包含少數幾個受信任的系統管理員，以利管理。
Tier 4 Admins | 負責網域的服務管理。只授與管理必要服務的必要權限。做為資料管理員的升級點。
資料管理員 | 描述
Tier 1 Admins | 負責目錄物件的一般管理，執行密碼重設、修改使用者帳戶內容之類的工作。
Tier 2 Admins | 負責為其地區設定或組織選擇性建立及 (或) 刪除使用者和電腦帳戶。
Regional Admins | 負責其本機 OU 結構的管理。具備在其 OU 內建立大部分物件的權限。
Tier 3 Admins | 負責所有資料管理員的管理。做為所有地區系統管理員的最上層服務台和升級點。

服務管理員
現在就來看看服務管理員角色的細節。服務管理員管理重要的基礎結構元件，而屬於這一類的所有系統管理員都具有高度權限。因此，在此情況下極力建議使用最低權限策略，這表示僅授與執行必要工作所需的最小一組使用權限。
Enterprise Admins 和 Domain Admins：Active Directory 會定義兩個特殊的系統管理員群組，目錄內的重要功能需要其安全性內容。這些群組 (Enterprise Admins 和 Domain Admins) 負責最上層服務管理。為了降低這種高度權限群組固有的風險，我們極力建議您限制這些群組的成員資格。事實上，Enterprise Admins 群組不應該有永久成員，而 Domain Admins 群組應該只包含少數可管理的受信任者，這些人在組織中擔任全職工作。
當必須執行企業管理工作 (例如 DHCP 伺服器授權或 Active Directory 站台建立) 時，Active Directory 樹系根網域中的 Domain Admins 可藉由管理 Enterprise Admins 群組的成員資格來提升權限。為了避免在 Enterprise Admins 群組中建立永久成員，應該只短期授與這些權限。當然，指定的 Active Directory 樹系中之 Domain Admins 群組的所有成員也必須受到同等的信任。
在開發委派模型時，大部分組織常常落入的陷阱是停用或減損這些內建角色。修改預設角色可能會造成無法預期的結果，而且不保證 Service Pack 修訂或產品升級會保留這些設定。此外，這類修改會在組織之外建立不受支援的環境。較實用的方法是使用內建群組和角色，但限制成員資格。若要這麼做，您可能必須為先前依賴群組 (如 Domain Admins) 中之成員資格的系統管理員建立新角色。
Tier4 Admins：Tier4 Admins 群組應該包含為所有企業服務提供支援的中央服務管理員。因為這是建立的角色，所以可修改目錄服務及系統存取權限，使其符合您組織的特定需求。雖然此群組的成員是服務管理員，但他們有時也可以執行整個樹系的資料管理工作。因為有許多系統類別及不同的責任區域，所以 Tier4 角色在目錄內會分成幾個不同的子群組。例如，若要分開管理特定系統 (例如 Exchange 伺服器)，則應該建立個別的 Tier4 群組。此群組也做為資料管理員的升級點。
使用者通常會想要獲得 Domain Admins 群組中的成員資格授權，理由之一是想要得到指定網域中所有系統的系統管理權限。若要讓這些服務管理員在最低權限模式下執行，秘訣就是要授與企業伺服器的 Tier4 Admins 控制權，而不使其成為 Domain Admins。為了防止權限提升，請不要在網域控制站的 BUILTIN\Administrators 群組中授與 Tier4 Admins 成員資格，因為該群組具有許多無法分開的目錄服務基本權限。例如，指定網域的 BUILTIN\Administrators 群組成員可以管理 Domain Admins 群組的成員資格，讓成員在不需要任何檢查及協調的情況下提升權限。
還記得我們有一條關於不減損預設權限的規則嗎？您可以將 Tier4 群組設定為 Server Operators 和 DNS Admins 內建網域群組的巢狀成員，以降低此風險。這樣您就可以進行網域控制站的本機管理，同時又能限制 Tier4 Admins 提升權限的能力。針對大部分系統 (網域控制站、憑證伺服器等等除外)，您應該將 Tier4 Admins 群組設定為本機 Administrators 群組的成員。您可以利用 [群組原則] 中的 [受限群組] 功能，來自動化巢狀本機群組成員資格的作業。

資料管理員
現在就來探討一下資料管理員角色。這些角色應該以累加權限的方式設計，意指 Tier2 Admin 應該具有 Tier1 Admin 的所有權限以及一些額外的權限，依此類推。基於這個理由，我們將從頭開始了解這些群組。
Tier1 Admins：Tier1 Admins 群組應該對先前建立的目錄物件提供一般管理。此群組適用於經驗不足的系統管理員，或是執行隔離的工作 (例如密碼重設) 的系統管理員。在此群組的組織單位內授與其權限來修改使用者帳戶內容、重設使用者帳戶密碼、解除帳戶鎖定、啟用/停用使用者帳戶、新增和重設工作站電腦帳戶，以及修改非系統管理群組的群組物件成員資格。
Tier2 Admins：此群組應該啟用物件的選擇性管理和建立，讓物件只能建立在可供 Tier1 Admins 管理之處 (例如，安全性群組只能建立在「群組 OU」中)。Tier2 Admins 可以新增及修改 Tier1 Admin 帳戶；新增、修改及刪除 OU 的使用者帳戶；刪除「工作站」電腦物件；以及新增、修改和刪除「伺服器」、「連絡人」及「共用資料夾」物件。
Regional Admins：此群組擁有其地區 OU 結構的專用權。不過，他們無法管理該目錄內的其他地區 OU 結構。Regional Admin 帳戶應視為具有高度權限的帳戶，因此這些帳戶會儲存於個別的 OU 階層中，並且由 Tier4 Admin 服務管理員進行管理。Regional Admins 可以不受限制地在其 OU 結構內建立大部分物件 (建立其他組織單位則屬明顯的例外狀況)，但這會帶來其建立的物件無法由下層管理的另一種風險。
Tier3 Admins：許多組織都有中央或高層服務台。此角色會指定資料管理員的清單，為所有 Regional Admins 提供一個資料管理員群組。權限並不會透過目錄委派給這些群組；而是會透過每一個 Regional Admins 群組中的巢狀成員資格來進行委派。這可以為所有資料管理員提供一個最上層的升級點，也為需要升級到服務管理群組的問題提供了進入點。

建置 OU 和安全性群組模型
在組織中定義角色之後，就必須定義 OU 和安全性群組模型。在 Active Directory 中建立 OU 的兩個主要理由如下：權限的委派以及群組原則物件連結點的建立。OU 會定義目錄內的管理領域 (SOM) 且可用來限制不同層級的物件權限。因此，您選擇委派權限的方式將會是影響您如何實作 OU 結構的一個主要因素。
所以，應該直接在網域下建立最上層 OU (或一系列 OU)，以存放所有物件。這個 OU 的功能，是要針對 Tier4 Admins 定義最高層 SOM。藉由建立最上層 OU，目錄服務的權限就可以從 OU 層級而非網域層級啟用。從最上層 OU 委派而不是從網域委派，可降低使用者運用我們先前所提到的內建網域群組來提升權限的風險。
在最上層 OU 下面，您應該建立個別的子 OU 階層來代表擁有獨立資料管理小組的每一個地區或業務單位。每一個地區的子 OU 都應該擁有不可延伸的通用 OU 階層來管理目錄物件。一致性對於持續進行的管理很重要，因為多數權限委派都是自動化的。這是很難達成的任務，因為每一個地區都希望有獨特的 OU。不過 IT 系統管理員必須堅持自己的主張，如果某個地區需要進行延伸，則所有地區的子 OU 結構也都必須延伸。雖然這一開始可能會有困難，但只要組織為物件提供通用儲存區，假以時日，例外狀況就能夠漸漸消失。
最後，建立個別子管理群組和帳戶來移除系統管理員提升其權限的能力 - 針對每一個子 OU 階層的 Tier1 Admins、Tier2 Admins 和 Regional Admins 群組。將這些帳戶存放在個別 OU 中，才能有效限制其管理範圍不會超越適當層級。因此，如果所有 Tier1 Admins 帳戶及關聯的安全性群組都位於他們沒有權限的 OU 中，系統管理員才無法綁架其他管理帳戶或將其他系統管理員的權限升級到其層級。例如，Domain Admins 群組的任何成員都可以使網域中的任何其他使用者帳戶成為 Domain Admin。不過，使用此 OU 模型便可降低這樣的風險。[圖 2] 顯示與安全性群組關聯之 OU 結構的範例。
圖 2 OU 結構及關聯的安全性群組
圖 2 OU 結構及關聯的安全性群組

建立次要帳戶
成功委派模型的關鍵在於強制執行最低權限原則。實際上，這表示安全性主體應該只具備執行其給定角色所需的工作能力而已。很可惜，許多 IT 系統管理員都使用相同安全性主體來進行目錄管理和每日例行工作，如瀏覽網站及讀取電子郵件。使用個別帳戶的話，分層系統管理員比較不會不小心損害到目錄服務，或成為駭客透過例行應用程式攻擊目錄系統管理員的受害者。
若要達成此目的但不需要使用者登出後再登入，您可以使用 Secondary Logon 服務 (Runas.exe)。這樣可讓使用者在伺服器和工作站執行指令碼或可執行檔時，提供一組替代認證來提升其權限。
雖然使用最低權限帳戶的概念很簡單，但是組織發現有時候執行起來並不容易，因為舊的 IT 習慣很難改變。防止在每日例行工作中使用特殊權限帳戶的直接方法，就是不在 Exchange Server 中提供郵件存取功能給這些帳戶，亦即透過組織內的系統管理原則強制執行。如此簡易的方法大幅降低這類帳戶用於例行、非系統管理工作的可能性。

委派權限
開發委派模型中的最後步驟，是要在 Active Directory 內實際委派權限。這包含對儲存在目錄內的資料進行存取控制項目 (ACE) 和存取控制清單 (ACL) 的操作。Active Directory 容器上的 ACL 會定義可建立的物件及那些物件的管理方式。委派權限涉及物件的基本作業，例如檢視物件、建立指定類別之子物件或讀取指定類別之物件屬性和安全性資訊的能力。除了這些基本作業之外，Active Directory 還會定義可啟用 [以下列傳送] 和 [管理複寫拓樸] 等作業的延伸權利。
在先前的步驟中，我們曾討論建立安全性群組來對應到已定義的組織角色。這表示每一個角色都有一個子 OU 結構的關聯安全性群組。若要實作委派模型，則需要指派目錄物件的權限給這些群組。此時，您並不想要從頭來過，建立一個高度自訂的環境。因此，請盡量運用內建群組和權限。假設有一個特定角色需要管理樹系的 DNS 記錄。請勿針對 Active Directory 相關的容器和命名內容委派權限 - 整合式 DNS；相反地，請直接運用網域中的 BUILTIN\DNS Admins 群組。此外，可以透過群組原則延伸使用者權限和其他權限，以提供給定角色管理系統之特定類別所需的其他權限。
利用委派來指派權限時，應該限制或甚至完全禁止在目錄內使用 [拒絕 ACE]。萬一發生問題時，這很難疑難排解。較好的方法是利用明確 [允許 ACE] 來授與權限給代表您角色的自訂群組。請記住，使用者定義的角色 (如 Tier4 Admins) 只擁有該角色所定義的明確權限。
繼承對 Active Directory 安全性而言很重要，它定義特定 ACL 如何套用至給定容器或子容器內的子物件。請具體指定繼承範圍，務必確保可繼承的 ACE 盡量套用到目標物件。套用到父物件的可繼承拒絕權限，其優先順序將高於套用到其上二層物件的任何可繼承拒絕權限，這是為何不建議在實際委派中使用 [拒絕 ACE] 的主要原因之一。此外，可繼承權限無法覆寫物件的明確 ACE。因此，建議您限制或禁止分層系統管理員在目錄物件上修改判別存取控制清單的能力 (方法是移除 [寫入 DACL] 權限) (請注意，物件的建立者隱含擁有這些權限)。如果系統管理員有能力變更物件的 DACL，他很可能會這麼做，這是經驗法則。請勿製造機會產生潛在的管理錯誤，讓組織對委派模型所做的努力白白浪費。
您需要使用一些工具來適當實作 Active Directory 委派模型。對大部分大型組織而言，使用內建委派精靈在目錄中指派權限是一項令人怯步的工作，充斥著發生管理錯誤的可能性。所以一定要使用自動化來確定委派模型妥善記錄而且是可支援的，萬一不小心遺失或變更設定時它還能提供修復選項。
實作委派所需的主要工具是 DSACLS.EXE，它是用於物件上操作目錄服務 ACL 的命令列工具。此工具也能夠在父物件上指定 DACL 的繼承旗標 (繼承旗標可以是：包括此物件及子物件、只包括子物件，以及可繼承權限只傳播一個層級)。如果繼承旗標設定不正確，DSACLS 命令最後會失敗，因此在使用此工具時測試很重要。以下是 DSACLS 語法的範例，是關於委派在目標示範 OU 中建立電腦物件的能力：
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS 對於物件類型有區分大小寫。這表示嘗試在 "cn=computer" 上委派 "cn=Computer" 物件類別的權限不會成功 (請參閱 [圖 3])。
圖 3 因區分大小寫而造成的錯誤
圖 3 因區分大小寫而造成的錯誤
建立某些物件需要一組特定權限。這必須與物件的 "must contain" 和 "may contain" 屬性有關。我所聽過用來解釋此概念的最佳比喻是漢堡模型。漢堡必須包含肉餅和圓形麵包才叫做漢堡。那些就是漢堡物件類別的 must-contain 屬性。小黄瓜、蕃茄醬、萵苣等項目，則是 may-contain 屬性。如果我們延伸物件類別來定義起司漢堡，必須在 must-contain 屬性的清單中加入起司。
使用者 (User) 物件也是如此的運作方式。假設我們要遵循此模型並使用下列 DSACLS 語法建立使用者 (User) 物件：
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
系統管理員在使用者物件建立期間會遇到幾項錯誤。我們需要授與在使用者物件上設定必要屬性所需的權限，包括密碼的設定。下列另一個 DSACLS 語法將概略說明。
第一步是授與 [一般讀取]/[一般寫入] 給該使用者類別的所有屬性，藉此授與寫入 must-contain 屬性的權限：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
下一步是授與變更密碼的延伸權限：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
最後一步是授與權限給 [上次設定密碼] 屬性 (Attribute) 的 [讀取屬性 (Read Property)] 和 [寫入屬性 (Write Property)]：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
在委派適當權限之後，所定義的角色將只限於管理容器之 DACL 中已定義的物件類別。就先前的電腦物件範例而言，Active Directory 使用者和電腦中的內容功能表，會限制獲委派這些權限的使用者可建立的新物件清單 (請參閱 [圖 4] 中的受限制清單)。
圖 4 新物件的受限制清單
圖 4 新物件的受限制清單
DSACLS 也可以自動化，以提供複雜的權限部署。以下是一些可用來委派權限的 DSACLS 命令，以操作給定容器內之使用者物件的共用地址屬性：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
諸如此類的範例為大部分委派模型所常見，它們可與先前定義的角色一起使用。
用於實作委派的另一個工具是 DSREVOKE.EXE，這可讓系統管理員在目錄內的物件上尋找及移除特定安全性主體的委派權限。雖然此工具非常有用，但它專屬於安全性主體，而且不會評估安全性群組內的巢狀成員資格。
除了這些命令列工具之外，我們也極力建議您使用 [使用者權限指派] 和 [受限群組] 來搭配 [群組原則]。如前所述，[使用者權限指派] 可讓 IT 系統管理員針對特定目標系統上的不同使用者群組延伸或移除低階權限 (例如從遠端存取及重新啟動系統的權限)。受限群組可用來指定及強制執行樹系內的本機和網域群組成員資格。這些工具搭配使用時提供您要自動化及實作 Active Directory 委派模型所需的一切。

總結
雖然開發 Active Directory 委派模型的工作看起來似乎很複雜，實際上非常簡單的模型就可以套用到大部分 IT 基礎結構。部署實際委派模型時，最重要的步驟之一就是定義明確角色。您應該盡量減少定義的角色數量，以利管理。要取得平衡是相當不容易的，因為太多角色會造成角色沒有全用上，太少角色則使角色劃分困難。
記住，在定義工作時，請按頻率、重要性和困難度加以分類。定義角色之後，請開發一組使用案例來幫助識別每一個角色可以或不可以執行的動作，並將測試流程自動化。仔細規劃的使用案例，可幫助您向組織內的共同關係人說明這些角色，並減少因自動化錯誤而造成的意外。
最後，採取實用的方法來開發委派模型是永遠不會錯的。記住，越簡單越容易獲得支援，一個持久耐用的委派模型才能在 Active Directory 環境內發揮優異的管理權限控管效果。
其他資源
  • Design Considerations for Delegation of Administration in Active Directory (英文)
  • Best Practices for Delegating Active Directory Administration (英文)

Joel Yoker 是 Microsoft Federal 小組的資深顧問。Joel 和 Rob 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。
Rob Campbell 是 Microsoft Federal 小組的資深技術專家。Joel 和 Rob 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。


 Windows 系統管理: 深究 Windows Vista 新增的群組原則範本
Windows 系統管理 Darren Mar-Elia

深究 Windows Vista 新增的群組原則範本
摘要:
  • 深究 ADMX
  • 編輯 ADMX 檔案
  • ADM 和 ADMX 檔案的差異
  • 建立中央存放區

在 Windows Vista 以前，您在群組原則內可設定的登錄值都是由 ADM 檔案來控制，檔案中都使用加密和專屬的語法。除了 Microsoft 在標準 ADM 檔案中隨附的登錄值以外，如果還想要控制其他登錄值，您必須學習這種
語法並建立自訂 ADM 檔案。此外，這些 ADM 檔案會連同每一個群組原則物件 (GPO) 一起儲存在您的 Active Directory® 環境中，且每一個 GPO 和伴隨的 ADM 檔案也都會複寫到網域中的所有網域控制站。
隨著 Windows Vista™ 的問市，Microsoft 向群組原則登錄範本的領域邁出一大步。Windows Vista 大幅修改了 ADM 檔案的格式 (現在稱為 ADMX) 和這些檔案的儲存方式。在本文章中，我將著重於新的 ADMX 格式，並討論這些檔案和 ADM 的差別。我也會說明 Windows Vista 環境中如何處理這些檔案的儲存方式。

ADMX 的差異
在新的 ADMX 檔案格式與舊的 ADM 格式 (在 Windows NT® 4.0 時代就已出現) 之間，最大的差別莫過於 ADMX 已採用 XML 標準來描述登錄原則設定。有幾個理由可以證明這是非常好的做法。首先，XML 的編輯工具比編輯 ADM 語法的工具更多。其次，因為 XML 已制式化，一定會更容易建立工具來讓您知道如何將正確的標記放在正確的位置上，以建立格式正確的 ADMX 檔案。制式化代表任何 XML 運用方式 (例如 ADMX 格式) 都會有書面的結構描述，來描述可用的元素和屬性，以及其組織方式。本文稍後會舉例說明。
ADMX 和 ADM 的另一項基本差異，是主要 ADMX 檔案的字串區段，會獨立放在特定語言的 ADML 檔案中。如果您熟悉 ADM 檔案，您一定知道每一個檔案的最後都有一個以 "[strings]" 標記來界定的區段，您可以在此處指派文字字串的值，也就是您使用 [群組原則編輯器] 和 [系統管理範本] 時要顯示的字串。例如，您按一下任一原則的 [解說] 索引標籤時看到的文字，就是儲存在這個字串區段內。但問題是字串儲存在 ADM 檔案內，所以，如果您要在執行不同語言的 Windows® 系統上使用該 ADM，則必須建立新的 ADM 檔案，而且必須含有該語言的字串區段。
假設某人在法文版 Windows 上想要編輯已使用英文 ADM 的 GPO，則情況會更複雜。法文管理員在群組原則編輯器中只會看到英文。為了解決這個問題，Windows Vista 將 [strings] 區段獨立放在 XML ADM 語言 (或 ADML) 檔案中。如此一來，ADML 檔案就能夠以任何支援的語言發行，且很容易支援其他新的語言，不必修改儲存原則的主要 ADMX 檔案。更重要的是，當法文管理員在他的 Windows Vista 工作站編輯 GPO 時，群組原則編輯器會偵測到目前使用的是法文版 Windows，然後自動載入該 GPO 的法文 ADML 檔案。
只要開啟資料夾 c:\windows\policydefinitions ，您就可以看到 Windows Vista 隨附的所有 ADMX 和 ADML 檔案 (請參閱 [圖 1])。
圖 1 Windows Vista 中的 ADMX 檔案
圖 1 Windows Vista 中的 ADMX 檔案
請注意，在 [圖 1] 列出的檔案上方，有一個稱為 en-us 的資料夾。這就是特定語言的資料夾，其中會包含您在 PolicyDefinitions 資料夾中所看到 ADMX 檔案的 ADML 檔案 - 就這個案例來說是英文。每一個 ADMX 各有一個 ADML 檔案。撰寫本文時，Windows Vista 預設已包含 132 個 ADMX/ADML 檔案。下列是 Windows Vista 和先前版本之間的另一項重大差異：Windows XP 建立的 GPO 通常有五個 ADM 檔案，最大的是 System.adm，內含在原則控制下的大多數 Windows 元件的原則項目。在 Windows Vista 中，Microsoft 決定按照功能將 ADMX 檔案分類 - 因此 ADMX 檔案數量變得更多。每一個 ADMX 通常只涵蓋一個 Windows 元件 (例如，控制台、DNS 用戶端、Windows 檔案總管...等等)。

深究 ADMX
稍早說過，以 XML 撰寫 ADMX 是一大進步。但有許多系統管理員並不知道怎麼撰寫 XML，更遑論以 ADMX 所用的結構描述來建立原則延伸。自行建立 ADMX 的教學課程已超出本文的範圍，我們只要瞭解一下 ADMX 如何形成。
您可以在任何文字編輯器中開啟 ADMX 或 ADML 檔案 (就算是 [Notepad] 也可以)，但編輯器一定要瞭解 XML 語法，否則沒什麼意義。我採用 Visual Studio®，因為 IntelliSense® 功能可幫我完成特定的元素。[圖 2] 顯示 Windows Vista 隨附的其中一個 ADMX 的前幾行。
Figure 2 ADMX 檔案的 XML 片段 (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
如果您不熟悉 XML，可能會覺得看起來很奇怪，但其中許多 XML 元素在所有 ADMX 檔案中都會出現。例如，policyNamespaces 元素可在 ADMX 檔案環境中用來識別這一個 ADMX 檔案。
如果您曾在舊版的 Windows 中建立自訂 ADM 檔案，您就知道有一些標記 (例如 Category、Policy、ListBox 及 ActionList) 可用來定義在 [群組原則編輯器] 中出現的原則設定。其中有許多標記一樣不變，頂多只是在 ADMX 格式上稍有變化，但因為是以 XML 來表示，所以看起來相當不同。例如，我曾撰寫一個自訂 ADM 檔案，用途是在 Windows 內啟用各種記錄來解決群組原則的問題。[圖 3] 顯示這個自訂 ADM 的一個區段。後來我將這個檔案轉換成新的 ADMX 格式，如 [圖 4] 所示。
Figure 4 轉換成 ADMX 檔案之後的 ADM 檔案 (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 自訂 ADM 檔案 (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
從各方面來說，這個 ADMX 片段內容簡潔，比同系的 ADM 更容易理解。policy 元素會指定這個原則的用途 (資料夾重新導向記錄)。以 $(string. 開頭的屬性是對應之 ADML 字串元素的參考。key 和 valuename 屬性很明顯就是指定此原則影響的登錄機碼和值。parentCategory 元素則控制這個原則在 [群組原則編輯器系統管理範本] 階層中的位置。supportedOn 元素會指出要遵守這個原則的作業系統版本，最後，enabledvalue 和 disabledvalue 元素會指定當這個原則設定為 enabled 和 disabled 時，要在登錄中放入什麼值。
這是一個相當簡單的 on/off 原則。與 ADM 語法一樣，使用 [群組原則編輯器] 就可以建立更複雜的 UI 元素。但在 ADMX 內，語法較為複雜，且需要一個 presentation 屬性來參考部分 ADML 檔案，亦即 UI 元素的 text 標籤部分。除此之外，ADMX 語法實際上沒有複雜多少。另外請注意，從 ADM 到 ADMX，有一些標記名稱也已變更。例如，在 ADM 語法中，您可以使用 "edittext" 和 "listbox" 標記。但在 ADMX 語法中，您會發現這些標記在 ADMX 檔案中變成 "text" 和 "list"。這些元素在 ADML 檔案中有對應的項目來指定伴隨出現的文字。
您可能已經知道，系統管理員可以將自訂 (舊版) ADM 檔案載入 [Windows Vista 群組原則物件編輯器] 中。人們常問我說 Microsoft 會不會提供可將自訂 ADM 檔案轉換成 ADMX 語法的公用程式。實際上，Microsoft 已經與 FullArmor Corp. 合作發佈一個免費工具，稱為 ADMX Migrator。這個工具有兩項功能。第一是可將舊的自訂 ADM 檔案轉換成 ADMX 格式 (請參閱 [圖 5]，其中顯示使用此工具來轉換我自訂之 gpolog.adm 的範例)。
圖 5 ADMX Migrator
圖 5 ADMX Migrator
第二是提供一個 ADMX 編輯器，讓您可從頭開始建立新的 ADMX 檔案。您可以從 go.microsoft.com/fwlink/?LinkID=77409 下載這個工具。

ADMX 的儲存
另外一項我想討論的變更，是 ADMX 和 ADML 檔案如何儲存才能使用。在 Windows Vista 之前的 Windows 版本中，當您編輯新的 GPO 時，ADM 檔案會從您原先執行編輯工作的本機工作站，自動複製到 Active Directory 網域內的網域控制站上，並放入 GPO 的 SYSVOL 部分。隨後，這些 ADM 便會複寫到網域中的每一個 DC，供每一個已建立的 GPO 使用。這浪費許多網路頻寬和磁碟儲存體，尤其在有數百個 GPO 的大型環境中更是如此。Windows Vista 完全顛覆這個過程。根據預設，當您從 Windows Vista 工作站建立 Active Directory GPO 時，在 [群組原則編輯器] 中出現的 [系統管理範本] 原則，會從您原先編輯 GPO 的電腦上的 c:\windows\policydefinitions 資料夾載入。
ADMX 和 ADML 檔案將不會複製到 SYSVOL - 只是在本機參考。這樣就去除 ADM 在群組原則環境上造成的儲存體和網路負擔。好戲還在後頭。Windows Vista 也支援中央存放區，也就是系統管理範本的存放庫。不論是誰編輯 GPO，這樣就能有效地控制用來編輯 GPO 的 ADMX 檔案。做法是將所有官方的 ADMX 和 ADML 檔案 (以及您建立的任何自訂檔案) 複製到網路位置上，使後來從 Windows Vista 工作站編輯群組原則時，都會參考網路上的版本，不會再參考個別本機上的版本。設定中央存放區很簡單，每一個網域只要設定一次。只要照著「建立中央存放區」資訊看板中的步驟來進行即可。

總結
相較於舊版 OS 使用的 ADM 檔案，Windows Vista 新增的 ADMX 格式實為一大進步。使用 XML 就能夠以更清楚的架構來編輯和搜尋這些檔案。將特定語言的字串移至獨立的檔案之後，編輯多語言的群組原則易如反掌，中央存放區也讓您不必再用許多份 ADM 檔案來儲存和更新所有 GPO。一切都證明學習 ADMX 是一項明智之舉。
建立中央存放區
中央存放區的建立方式非常簡單。只要遵循下列簡單步驟，即可在 Active Directory 網域中建立一個中央存放區：
步驟 1： 開啟檔案總管，巡覽至您環境中的 PDC 模擬器 DC 上的 [SYSVOL] 共用 (您可以使用任何 DC，但 PDC 角色擁有者通常是群組原則變更的焦點)。
步驟 2： 展開 [SYSVOL] 下的 [Policies] 資料夾，建立一個新的資料夾，並命名為「PolicyDefinitions」。
步驟 3： 將 Windows Vista 工作站的 C:\windows\policydefinitions 資料夾內容複製到新的 [PolicyDefinitions] 資料夾中，包括特定語言的 ADML 資料夾 (例如，英文電腦上的 [en-us])。
當 ADMX 和 ADML 檔案複製到中央存放區資料夾之後，Windows Vista 的群組原則物件編輯器就會開始參考那裡的檔案，不會再參考本機儲存的檔案了！

Darren Mar-Elia 是一位 Microsoft 群組原則 MVP，也是知名群組原則網站—www.gpoguy.com 的打造者和 Microsoft Windows Group Policy Guide (Microsoft Press，2005) 的作者之一。他同時也是 SDM Software, Inc. 的技術長和創始人。請透過 Darren@gpoguy.com 與他連絡。


 Windows 系統管理: 群組原則疑難排解指南
Windows 系統管理 Derek Melber

群組原則疑難排解指南
摘要:
  • GPO 的常見問題
  • 群組原則規則
  • GPO 問題的疑難排解
  • 疑難排解的工具

Microsoft Active Directory 已成為許多 IT 基礎結構的重要元件。Active Directory 的最重要功能之一是群組原則，群組原則可以讓系統管理員集中管理網域控制站、成員伺服器及個人電腦。
群組原則確實提供許多好處，不過有一個小小的缺點。在大型組織中設計及實作群組原則會很複雜，且萬一發生錯誤，要進行疑難排解更是困難。我將在本文中討論群組原則的構造，並示範如何進行疑難排解。看完本文，您將擁有幾乎可處理任何群組原則問題的資訊。

棘手的設定
群組原則中有許多動態的部分，尤其是與整個 Active Directory® 設計和實作的互動方面。針對許多種存取與網路問題進行疑難排解時，您若要尋找解決方案，一定要考慮到 Active Directory 和群組原則實作的基本概念。要開始疑難排解程序，先來看看可能設定錯誤的群組原則設定，再討論可能造成群組原則故障的較複雜問題。
Active Directory 系統管理員會使用系統管理範本檔案 (ADM 或 ADMX 檔案) 和群組原則物件編輯器 (又稱為 GPEdit，藉由執行 gpedit.msc 啟動)，來檢視群組原則設定。系統管理員會使用 GPEdit 來建立群組原則物件檔案 (又稱為 GPO)。GPO 會設定為套用 (或不套用) 至 Active Directory 結構中的電腦和使用者。GPO 必須遵循許多規則，才能正常運作。現在就來看看這些規則。
GPO 必須連結 建立新的 GPO 時，它不會連結到 Active Directory 中任何的節點。雖然 GPO 可以編輯和修改，但是要等到連結至節點後，才會開始影響任何物件。為了確保 GPO 已正確連結，您可以在群組原則管理主控台 (GPMC) (如 [圖 1] 所示) 中檢視資訊視窗。
圖 1 清楚顯示 GPO 連結
圖 1 清楚顯示 GPO 連結
GPO 必須以正確的物件為目標 如您所知，群組原則必須以 Active Directory 中之正確的物件為目標。但是，有時在疑難排解過程中會忽略這一點。GPO 中有兩大類別：電腦和使用者。當您設定 GPO 時，務必要注意它的目標是電腦或使用者物件。然後您就可以確認 GPO 所連結的組織單位 (OU) 中是否有正確的物件型別。
GPO 不會套用至群組 雖然您可能有此期望，不過 GPO 並不能套用至 Active Directory 安全性群組物件。GPO 設定只能設定電腦和使用者這兩種物件。GPO 不能透過群組成員資格設定物件。例如，某個 GPO 若是如 [圖 2] 中所示連結至 Finance OU，則會受到其設定影響的物件就只有 Derek 和 Frank。不論誰擁有 Marketing 群組的成員資格，在 GPO 中的設定都不會影響該群組的成員。
圖 2 Finance OU 和其中的物件
圖 2 Finance OU 和其中的物件
目標物件必須位於 GPO 的路徑中 當您察覺 GPO 設定並未正常地影響某個物件時，還有另一個很重要的設定 -- 物件必須位於 GPO 的管理領域 (SOM) 中。這表示物件必須位於 GPO 所連結的節點下 (甚至是子節點也可以)。例如，連結到 Finance OU 的 GPO 不會影響到 Marketing OU 中的任何物件，如 [圖 3] 所示。GPO 的 SOM 是從它所連結的節點開始，沿著 Active Directory 結構往下沿伸。
圖 3 OU 若在同一層級，GPO 只會套用至它所連結的 OU
圖 3 OU 若在同一層級，GPO 只會套用至它所連結的 OU
GPO 必須啟用 建立 GPO 之後，並不會自動對目標物件做任何修改。不過針對電腦和使用者的部分會先啟用。如果停用其中任一部分，就很難追查。因此，在您針對未正常套用的 GPO 進行疑難排解時，最好檢查看看是否有部分或全部 GPO 停用。檢查方式是在 GPMC 中的 [群組原則物件] | [帳戶原則] 底下查看，並檢查 GPO 狀態。
某些設定需要重新開機 GPO 設定未正常作用時，可能是因為 GPO 的固有處理之故。觸發 GPO 的定期背景重新整理時，只能處理某些 GPO 設定，無法處理全部。因此您雖然已建立好設定，但是設定可能尚未生效。有些設定歸類為幕前原則，唯有在電腦重新開機，或者使用者登出後再登入時才會套用。這種行為方式之設定的範例包括軟體的安裝、資料夾的重新導向，以及指令碼的套用。

設定的同步與非同步套用
您可以在 GPO 中設定開機時和登入時的原則套用方式。您能執行的變更包括：正在套用原則時立即提供桌面的存取，或者在讓使用者存取桌面之前必須先套用所有原則。[圖 4] 顯示每一種作業系統的預設行為。如果您想改變此行為，可以修改下列原則設定：
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 用戶端上的預設處理 (Close Figure 4)

作業系統 | 啟動 | 登入 | 原則重新整理
Windows 2000 | 同步 | 同步 | 非同步
Windows XP Professional | 非同步 | 非同步 | 非同步
Windows Server 2003 | 同步 | 同步 | 非同步
大多數系統管理員偏好同步套用原則，以確保在使用者存取桌面之前，所有原則都已套用。這可保證所有安全性和組態設定都套用之後，使用者才能執行任何工作。請注意，這不是 Windows® XP Professional 中的預設狀態，原因是要讓該系統的登入速度最佳化。

改變預設繼承
有四種不同的方法可以改變 GPO 處理的預設繼承。這些選項的功能強大，可能會造成群組原則處理行為的重大改變，因此應謹慎使用。而且這方面的疑難也很難排解。改變預設繼承的選項包括下列四種設定和組態：
  • 不要繼承原則
  • 強制 GPO
  • 存取控制清單 (ACL) 的 GPO 篩選
  • Windows Management Instrumentation (WMI) 篩選器
由於這些設定的使用率不高，因此應該很容易記錄其使用範圍。若要查明是否正在使用這些選項，請在 GPMC 中查看。不要繼承的設定是在 GPMC 中的網域或組織單位 (OU) 節點上執行。而強制 GPO、ACL 的篩選和 WMI 篩選則是會針對每個 GPO 設定。
您也可以從目標電腦執行 Gpresult 命令，了解是否有任一種設定阻止原則的套用。若要更深入了解套用的原則結果集，您可以使用 Gpresult 命令加上 /v 參數，就會提供詳細輸出。

ADM 範本的問題
當您嘗試在 [系統管理範本] 區段下設定 GPO 的設定時，所使用的是 ADM 範本。除了作業系統所附的 ADM 範本之外，您可以自訂自己的範本，在 GPO 中使用。ADM 範本中的程式碼會在群組原則編輯器的系統管理範本節點下建立資料夾和原則。不過 ADM 範本若是損毀、遺漏或未正確設定，則很可能在編輯器中看不到部分或全部的設定。以下是使用 ADM 範本時要防範的一些其他問題。
遺漏 ADM 範本 您在編輯 GPO 時若發現自訂 ADM 範本中有些設定未在編輯器中顯示，就必須將 ADM 範本匯入 GPO 中。若要匯入，只需在編輯器中的 [系統管理範本] 節點上按一下滑鼠右鍵，然後選取 [新增/移除範本] 即可。
遺漏偏好設定 自訂 GPO 中可以建立兩種設定：偏好設定和原則。原則是預設的 Microsoft 設定，全都屬於登錄中四種子機碼之一，每一個都以「Policies」文字結尾。偏好設定是「舊式」的登錄修改，不屬於四種子機碼的任一種，而且設定之後就很難改變。根據預設，這些偏好設定不會在編輯器中顯示。您必須加以啟用相關設定才能使它們顯示，這可以在工具列的 [檢視] 功能表下啟用。從 [檢視] 功能表中選取 [篩選]，然後勾選 [只顯示可以完全管理的原則設定] 核取方塊。這會立即顯示已經匯入之自訂 ADM 範本中所設定的偏好設定。

好用的工具
有許多工具可以協助您追蹤群組原則的問題。有些工具已內建在作業系統中，有些則可下載安裝。接下來我要討論適當的工具，讓您能夠選擇適合自己工作的工具。
Dcgpofix 有時候您會遇到與下列兩種預設 GPO 之一有關的問題：預設網域原則和預設網域控制站原則。如果其中一個或兩個 GPO 都損毀、已經過多次組態變更而無法修正，或者發生其他一些未知的問題，您就可以使用 dcgpofix 工具將其還原至預設狀態。此工具包含在 Windows Server® 2003 中。請勿在 Windows 2000 網域控制站上使用，如有需要，請改用 Recreatedefpol。而且請記住，如果使用此工具，所有的自訂設定都會遺失。
Recreatedefpol 此工具類似於 Dcgpofix，不過是供 Windows 2000 伺服器使用。它可以將兩個預設的 GPO 還原為最近的安裝狀態。此工具只應在損毀修復的情況下使用，請勿用於 GPO 的日常維護。您可以從這裡下載此工具 (英文)。
事件檢視器 事件檢視器有許多關於群組原則的資訊。較不方便的是，您必須檢查所有不同的記錄檔，以尋找群組原則的項目。您可以在其中找到關於原則套用、原則複寫及原則重新整理的項目，全都對您追查問題很有幫助。事件記錄檔中不一定都能找到有關特定群組原則錯誤的資訊，但是請記住，若是遇到您無法查明的問題，都可以到 TechNet 搜尋。
Gpresult 此工具只能以本機模式在目標電腦上執行，不過它提供原則結果組 (RSoP)、封鎖的 GPO、GPO 的權限，以及其他許多的相關資訊。使用此命令時只要加上 /v 參數，就會顯示影響電腦之 GPO 的相關資訊，以及與目前登入工作階段關聯之使用者帳戶的相關資訊。
Gpupdate 如果您正在實作新的 GPO 設定，或者想要確定所有 GPO 處理都已執行，則可以使用 Gpupdate 工具。這是作業系統 (Windows XP 或以上) 所附的命令列工具。執行此命令時會觸發背景重新整理，這會套用與此種重新整理相關的所有 GPO 設定。如果加上 /force 參數，即使自上次重新整理之後並沒有任何 GPO 變更，它仍會重新套用所有的 GPO 設定。在執行 Gpresult 命令之前執行此命令，是追查 GPO 問題的一種很有效的方法。
Gpotool 由於 GPO 是從最初發生 GPO 變更的網域控制站複寫到其他所有的網域控制站，因此有可能發生複寫失敗或無法有效交集。如此一來會造成不一致，或者無法正確地將變更套用至目標電腦。Gpresult 和 RSOP 等工具可以幫助判斷哪些 GPO 已套用，而此工具 (Gpotool) 則可協助您判斷每個網域控制站上的 GPO 是否一致。此工具會包含在 Windows Server 2003 Resource Kit 中，您可以從 go.microsoft.com/fwlink/?LinkId=77613 下載。
Replmon 針對從某個網域控制站複寫 GPO 到另一個網域控制站的問題進行疑難排解時，一定要知道可使用哪些工具幫助修復正常的複寫功能。因為 GPO 有兩個部分必須複寫，所以有兩個部分需要處理。第一部分是每個網域控制站上之 SYSVOL 的內容，這是由檔案複寫服務 (FRS) 控制。此一複寫並沒有太多的控制選項，只能啟用和停用服務以協助觸發複寫間隔。GPO 的另一部分儲存在 Active Directory 中，是由 Active Directory 複寫控制。藉由使用 Active Directory 站台和服務，即可在同一個 Active Directory 站台中的各網域控制站之間控制複寫作業。但是，您如果需要觸發不同 Active Directory 站台中、各網域控制站之間的複寫，則必須使用 Replmon 之類的工具。Replmon 可以跨越站台界限強制複寫 Active Directory 資料庫，而 Active Directory 站台和服務則不能。因此，儲存在 Active Directory 中的群組原則資訊如果有不符的情形時，可以使用 Replmon 觸發複寫程序，讓該資訊在每個網域控制站上交集。Replmon 會包含在 Resource Kit 和 Windows XP 支援工具中。您可以從 go.microsoft.com/fwlink/?LinkId=77614 下載。
RSOP RSOP 和命令列工具 Gpresult 很類似，它提供的圖形介面可讓使用者檢查所有 GPO 已套用的設定。RSOP.MSC 是 Windows XP Professional 和 Windows Server 2003 的內建工具。此工具使用類似於群組原則物件編輯器的格式，提供您所有已套用原則設定的結果，如 [圖 5] 所示。
圖 5 原則結果組工具
圖 5 原則結果組工具

總結
群組原則問題的疑難排解很不容易。事實上，如同本文所述，群組原則可能非常複雜。如果您要進行疑難排解，必須了解群組原則的核心架構和整體處理流程。您也必須了解更新、複寫、處理及套用 GPO 的方式。如果您清楚掌握上述所有概念，則任何群組原則問題的疑難排解就會容易許多。遵循本文提供的指導方針並適當地使用工具，您就能處理可能遇到的所有群組原則問題。

Derek Melber 是 DesktopStandard 的教育、憑證及符合性解決方案經理。DesktopStandard 是 Microsoft 完全擁有的子公司。Derek 是 Microsoft Windows Group Policy Guide (Microsoft Press，2005) 的合著者。他也寫過一系列稽核 Windows 安全性的書籍 (www.theiia.org (英文))。他的連絡方式為：derekm@desktopstandard.com。


 Windows 系統管理: 使用 MOM 來監視 Active Directory
Windows 系統管理 John Hann

使用 MOM 來監視 Active Directory
摘要:
  • Active Directory 的管理套件
  • MOM 的自訂秘訣
  • 警示調整

管理套件是 Microsoft Operations Manager (MOM) 2005 的命脈，也是讓 MOM 有別於其他管理產品的特色。MOM 使用管理套件來組合規則、報告、工作及檢視，並可將領域侷限在特定的應用程式
或服務，例如 Active Directory。Microsoft 產品小組會為所開發的應用程式建立管理套件，確保 MOM 可反映出小組深遠的產品知識。此外，您還可以自訂管理套件來符合您的 IT 環境。這樣就有規則可根據您的特定伺服器和應用程式環境來監視和管理產品。
不只是 Active Directory® 有特定的管理套件，還有各式各樣的管理套件可用來測量目錄服務的健康狀態，從 Windows Server® Base Operating System 到動態主機設定通訊協定 (DHCP)、DNS 及檔案複寫服務 (FRS) 都包括在內。我們來仔細看一遍這些管理套件，讓您更充分了解如何透過 MOM 對 Active Directory 進行端對端的管理。

DHCP 管理套件
DHCP 服務管理套件可監視在 Windows NT®、Windows® 2000 及 Windows Server 2003 中執行的 DHCP 服務。藉由監視 DHCP 來了解用戶端是否有網路連線問題是一個不錯的主意。當環境中有惡意的 (未經授權的) DHCP 伺服器在執行時，此套件也會警告您。此管理套件的下載套件中包含一本指南，其中說明規則和報告以及監視案例和部署方法。TechNet MOM 2005 網站 (microsoft.com/technet/prodtechnol/mom/mom2005) 上還有許多文件和指引等您挖掘。
執行 DHCP 服務的 Windows 版本愈新，MOM 2005 提供的管理資訊和功能就愈多。因此，Windows Server 2003 DHCP 伺服器比 Windows NT DHCP 伺服器的參考資訊更豐富。例如，在 Windows Server 2003 上執行 DHCP 伺服器時，可以監視其超級領域，但 Windows 2000 DHCP 伺服器上的 DHCP 管理套件只能監視一般領域。您可以在監視指令碼中，將要排除的領域設定為參數，就可以排除不要監視的領域。
剛才說過，DHCP 管理套件支援在 Windows NT、Windows 2000 Server 及 Windows Server 2003 上執行的 DHCP 伺服器。電腦群組都是透過公式來填入，這些公式會根據作業系統版本及伺服器是否裝載 DHCP 伺服器服務而定。
DHCP 管理套件不支援低權限的組態。「動作帳戶」代理程式必須是本機 Administrators 群組的成員。產品有支援無代理程式的監視，但不支援無代理程式組態中的工作。[圖 1] 列出 DHCP 管理套件中可用的報告。
Figure 1 DHCP Service 報告 (Close Figure 1)

All DHCP Servers
All Authorized DHCP Servers
Performance History-Active Queue Length
Performance History-Conflict Check Queue Length
Performance History-Declines per Second
Performance History-Discovers per Second
Performance History-Milliseconds per Packet (Avg)
Performance History-NACKs per Second
Performance History-Scope Free Addresses
Performance History-Scope Addresses in Use
Performance History-Superscope Free Addresses
Perfromance History-Superscope Addresses in Use
您可以從 go.microsoft.com/fwlink/?LinkId=79527 下載 DHCP 管理套件。

DNS 管理套件
「網域名稱服務」管理套件可監視在 Windows 2000 Server 和 Windows Server 2003 中執行的 DNS 伺服器。由於它是 Active Directory 整體實作健康狀態不可缺少的部分，所以使用 MOM 2005 來監視 DNS 非常重要。DNS 管理套件可監視名稱解析問題、資料庫問題、登錄問題、執行階段事件和錯誤，以及相關的效能計數器。
以 Windows 2000 Server 而言，安裝 Windows Management Instrumentation (WMI) DNS 提供者是必須的。尤其，這可讓 DNS 管理套件在 WMI DNS 名稱區中查詢資訊和測試。
電腦群組都是透過公式來填入，這些公式會根據作業系統版本及伺服器是否裝載 DNS 伺服器服務來決定群組成員資格。DNS 管理套件只支援 Windows Server 2003 上的低權限。在 Windows 2000 上，「動作帳戶」必須是本機 Administrators 群組的成員。在 Windows Server 2003 上，「動作帳戶」必須是本機 Users 和 Performance Monitor Users 群組的成員。此外，「動作帳戶」也必須有「管理稽核和安全性記錄」(SeSecurityPrivilege) 及「允許本機登入」(SeInteractiveLogonRight) 權限。[圖 2] 列出 DNS 管理套件中可用的報告。
Figure 2 DNS Service 報告 (Close Figure 2)

All Windows DNS Servers
All Windows DNS Servers by Zone
All Windows DNS Zones by Server
Microsoft® Systems Management Server (SMS) 的最有價值專家 (MVP) Marcus Oh 開發了一個測試 DNS 伺服器的指令碼，這個指令碼會呼叫 nslookup 來驗證 DNS 伺服器是否有能力解析名稱。請看一下他在 marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html 上發表的部落格文章，相信您一定會想要將這個指令碼整合到您的 DNS 管理套件中。
您可以從 go.microsoft.com/fwlink/?LinkId=79528 下載 DNS 管理套件。

FRS 管理套件
Windows「檔案複寫服務 (FRS)」管理套件可監視在 Windows 2000 和 Windows Server 2003 中執行的 FRS 服務。網域控制站會使用 FRS 來複寫登入指令碼和「群組原則」資訊。FRS 管理套件會詳述每一個網域控制站之 FRS 服務的健康狀態。
FRS 管理套件利用 Ultrasound 工具，此工具可以從 go.microsoft.com/fwlink/?LinkId=79529 取得。Ultrasound 會在每個網域控制站上建立 FRS 的 WMI 名稱區。請注意，Ultrasound 需要資料庫，且會儲存每個網域控制站上之 WMI 名稱區的資訊來監視健康狀態。FRS 管理套件利用來自 Ultrasound 的資訊來監視複本組、成員、連線、FRS 服務本身及 Ultrasound 控制器服務。
事實上，您應該將 Ultrasound 安裝在管理伺服器以外的另一部伺服器上。Ultrasound 規則會代表其他電腦來產生事件和警示。為了讓 Ultrasound 規則正確地處理資料，在每一部執行 Ultrasound 的伺服器上，您必須在 MOM 系統管理員主控台中啟用代理程式 Proxy 處理。[圖 3] 列出 FRS 管理套件中可用的四個服務報告。
Figure 3 FRS Service 報告 (Close Figure 3)

Ultrasound-Frequently Detected Issues-Most Problematic Connections
Ultrasound-Frequently Detected Issues-Most Problematic Members
Ultrasound-Frequently Detected Issues-Most Problematic Replica Set
Ultrasound-Frequently Detected Issues-Summary
與此管理套件相關的電腦群組包括在 Windows 2000 Server 和 Windows Server 2003 上執行的 Microsoft Ultrasound 1.0 伺服器和 FRS 伺服器。電腦群組皆透過公式來填入，這些公式會根據作業系統版本及伺服器是否裝載 FRS 服務來決定群組成員資格。伺服器會在安裝 Ultrasound 時填入 Ultrasound Servers 群組。
設定低權限的 FRS 管理套件時，工作將無法執行，但可支援其餘的管理套件功能。「動作帳戶」必須有 Ultrasound 資料庫的讀取權限和 GetControllerStatusForMOM001 預存程序的執行權限。FRS 管理套件可支援監視無代理程式的電腦和以代理程式管理的電腦。
您可以從 go.microsoft.com/fwlink/?LinkId=79530 下載 FRS 管理套件。

Windows Server 管理套件
Windows Base Operating System 管理套件可監視 Windows NT 4.0 Server、Windows 2000 Server 及 Windows Server 2003。Base OS 管理套件會報告網域控制站之作業系統的健康狀態，也會監視系統上的根目錄服務。此管理套件提供有關核心 Windows 服務、記憶體及處理器效能的狀態，以及磁碟可用空間和磁碟延遲的狀態。此管理套件和本文提及之其他管理套件的監視規則有些許的重疊，但它卻能夠由下而上一窺網域控制站的整體健康狀態。
[圖 4] 顯示 Base OS 管理套件中可用的報告。就像其他管理套件一樣，電腦群組也都是透過公式來填入，這些公式會根據作業系統版本而定。
Figure 4 Base Operating System 報告 (Close Figure 4)

Disk Performance Analysis
Operating System Configuration
Operating System Performance
Operating System Shutdown by Event
Operating System Shutdown by Server
Operating System Storage Configuration
Software and Applications Installations by Application
Software and Applications Installations by Instance
Software and Applications Installations by Server
Reliability-Application Failures by Application
Reliability-Application Failures by Computer
Reliability-Application Failures by Event
Reliability-Operating System Failures by Computer
Reliability-Operating System Failures by Event
Reliability-Operating System Failures by Stop Code
Performance History-Performance History
Performance History-Additional Reports
當您設定以低權限來執行 Base OS 管理套件時，在 Windows 2000 環境下，「動作帳戶」必須是本機 Administrators 群組的成員。Windows Server 2003 則會要求「動作帳戶」必須是本機 Users 和 Performance Monitor Users 群組的成員，並且必須擁有「管理稽核和安全性記錄」(SeSecurityPrivilege) 及「允許本機登入」 (SeInteractiveLog-onRight) 權限。無代理程式監視的電腦支援大部分的 Base OS 管理套件 (除了工作以外)。
您可以從 go.microsoft.com/fwlink/?LinkId=79531 下載 Base OS 管理套件。

Active Directory 管理套件
Active Directory 管理套件非常廣泛，且其規則涵蓋 Windows 2000 Server 和 Windows Server 2003。Active Directory 管理套件包含五種規則區域：用戶端監視、信任監視、複寫監視及拓撲搜索，加上涵蓋 Windows 2000 Server 和 Windows Server 2003 作業系統的規則。如稍早所述，Windows 版本愈新，可用工具就愈多，因此也就有愈多監視功能。例如，此管理套件在 Windows Server 2003 上支援信任監視，但在 Windows 2000 上不支援。
Active Directory 管理套件會建立許多群組，用來將規則套用至特定的電腦。用戶端監視規則會使用稱為 Active Directory Client Side Monitoring 的群組。您可以將已安裝 MOM 代理程式的電腦放在這個群組中來監視和管理這些規則。我在這個群組中放入一些經過代理程式授權的桌上型電腦及一些 Exchange 伺服器。Exchange Server 會廣泛使用 Active Directory，成為可能發生問題的指標。群組中的桌上型電腦則可協助您判斷一般使用者的體驗。用戶端監視規則會利用指令碼來測試對網域控制站的連線、透過 LADP 來查詢，以及報告連線是否失敗。請注意，用戶端監視規則僅適用於由代理程式管理且已啟用 Proxy 的電腦，不適用於網域控制站。
信任監視規則會使用稱為 Active Directory Trust Monitoring 的群組。Windows Servers 2003 電腦會放在這個群組中來測試信任度。Windows Server 2003 含有 WMI 名稱區可監視信任度。這些規則會運用指令碼來查詢 WMI 名稱區。偵測與其他網域的信任關係發生錯誤時，這些規則會發出警示。
有許多適用於 Windows 2000 Server 或 Windows Server 2003 的 Active Directory 管理套件規則。這些規則描述這兩個作業系統實作 Active Directory 的差異。不過，大部分的 Active Directory 管理套件都會在這兩個作業系統的合併規則中。其中部分規則會包含指令碼，可用來測試網域控制站之間的連線能力、驗證彈性單一主機操作 (FSMO) 角色持有者、目錄資訊樹狀結構 (DIT) 資料庫大小、驗證「群組原則」處理、認知一致性檢查程式 (KCC) 檢查，以及進行站台間訊息處理服務的測試。
複寫監視是 Active Directory 管理套件的核心元件。預設有 Active Directory Replication Latency Data Collection - Sources 和 Active Directory Replication Latency Data Collection - Targets 這兩個群組，可讓您設定專門用來報告複寫監視的網域控制站。資料收集群組的每一個成員都會計算出複寫延遲。效能計數器中會填入更新複製至每一個群組成員所需的時間。如果企業整體的複寫延遲超過定義的閾值，則會計算並報告此複寫延遲 (並產生警示)。請注意，Windows 2000 Server 上必須安裝複寫監視的 WMI 名稱區。
Active Directory 管理套件中的拓撲探索會用來建立實作的圖表。這些有用的圖表可以匯出到 Microsoft Office Visio®。MOM 會即時建立這些圖表，讓您在短短幾秒內建立最新的版本。
在 MOM 2005 操作員主控台的「圖表檢視」下，有三個 Active Directory 管理套件圖表。「連線中斷物件」圖表 (請參閱 [圖 5]) 會顯示任何在錯誤狀態下的連線。如果沒有連線錯誤，則此圖表可以是空白。
圖 5 「圖表檢視」中會反白顯示「連線中斷」
圖 5 「圖表檢視」中會反白顯示「連線中斷」
「連線物件」圖表會反白顯示 DC 之間的連線。「站台連結」圖表會顯示每一個 Active Directory 站台，其中涵蓋此站台的相關網域控制站以及所連線站台的連結。
因為 MOM 為這些檢視建立的圖表是動態的，所以您可以將圖表匯出到 Visio 來輕鬆編輯和自訂。例如，[圖 6] 顯示在 Visio 中編輯的「站台連結」圖表。
圖 6 在 Visio 中編輯站台連結圖表
圖 6 在 Visio 中編輯站台連結圖表
[圖 7] 列出 Active Directory 管理套件中可用的報告。[圖 8] 顯示與此管理套件關聯的電腦群組。如您所見，Active Directory 電腦群組都是由明確的成員資格來填入；Windows 電腦群組則都是根據作業系統的版本和機器是否為網域控制站而填入。
Figure 8 電腦群組 (Close Figure 8)

Active Directory Client-Side Monitoring
Active Directory Replication Latency Data
Collection-Sources
Active Directory Replication Latency Data
Collection-Targets
Active Directory Trust Monitoring
Windows 2000 Server Domain Controllers
Windows Server 2003 Domain Controllers
Figure 7 Active Directory 報告 (Close Figure 7)

AD Domain Controller
AD Role Holders
AD Replication Connection Objects
AD Replication Site Links
AD DC Disk Space
AD Domain Changes
AD Machine Account Authentication Failures
AD Replication Bandwidth
AD Replication Latency
Active Directory 管理套件在 Windows Server 2003 網域控制站上可以設定為低權限。此管理套件不支援無代理程式的監視。在 Windows 2000 Server 上，「動作帳戶」代理程式必須屬於 Domain Admins 或本機 Administrators 群組。Windows Server 2003 網域控制站上的「動作帳戶」代理程式必須有額外的權限，才能設定為低權限 (額外權限包括 Users 和 Performance Monitor Users 群組中的成員資格、事件記錄檔的存取權限，以及 SeSecurityPrivilege、SeAuditPrivilege 和 SeInteractiveLogonRight 權限)。此外，還需要下列存取權限：對 Active Directory 中的 CN=MomLatencyMonitors 容器執行複寫監視所需的完整權限、對 NTDS.dit 資料庫和記錄檔所在目錄的讀取權限，以及對下列登錄機碼的讀取權限：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
請注意，如果您在 Windows Server 2003 中監視信任，則 AD Monitor Trusts 指令碼會要求「動作帳戶」代理程式必須有 Domain Admin 或 Administrators 群組成員資格。
您可以從 go.microsoft.com/fwlink/?LinkId=79540 下載 Active Directory 管理套件。

自訂 Active Directory 的 MOM
必須設定 Active Directory 管理套件，否則主控台內會塞滿警示。網域控制站重新啟動時是 Active Directory 管理套件最繁忙的時刻，每一個可能的警示幾乎都在此時觸發。不幸的是這種情況很難停止。最好的辦法是利用 MOM 的「維護模式」來控制預期維護時段內的警示。「維護模式」的目的是要自動解決網域控制站的警示，避免塞滿主控台。
請記得將用戶端電腦和適當的伺服器放在 Active Directory Client Side Monitoring 群組內，以完成設定。與此群組關聯的規則將有助於判斷 FSMO 的健康狀態和連線能力。
有些效能規則會使用閾值來繫結至 FSMO，並使用 LDAP、PING 及 DNS 來驗證連線能力。這些規則都位於 Active Directory Availability 效能規則內。您應該設定警示嚴重性來自訂這些規則所使用的閾值。例如，FSMO 繫結使用以秒為單位的屬性值。每一個 FSMO 角色的效能規則都採用這種警示建立方法。
很重要的一點是，您必須了解 [狀態規則的警示嚴重性計算] 設定的運作方式。此對話方塊會使用 If-Else 條件來決定屬性值，再據以設定警示嚴重性 (請參閱 [圖 9])。當規則收集 AD Op Master Response 指令碼所建立的 Last Bind 效能計數器時，將根據這些規則所設定的條件閾值來檢查此計數器。您必須針對您的環境來設定這些不同的警示等級。
圖 9 設定警示嚴重性規則
圖 9 設定警示嚴重性規則
回顧一下每個網域控制站的複寫排程。如果指定網域控制站的排程不同於其他網域控制站，將會扭曲複寫延遲結果，並導致您設定較高的閾值。您必須設定複寫指令碼的參數，以符合您特定環境的需求。請注意，當任何網域控制站關閉或發生複寫問題時，這些群組中的其他每一個網域控制站都可以報告此網域控制站發生複寫失敗狀況，就算不是直接的複寫協力電腦也一樣。因此，即使有問題的網域控制站進入「維護模式」，其他網域控制站仍然可以報告複寫失敗。
複寫監視是 Active Directory 管理套件中最需要注意的項目。在環境中執行管理套件必須經過幾週之後，才能看出如何發出警示。在看出某種趨勢之後，請利用報告來描述延遲，並適當地調整閾值。
最後，請善用 Alert Tuning Solution Accelerator (英文) 提供的指引。

展望未來
MOM 2005 和 Active Directory 管理套件可讓您更有效地監視組織的 Active Directory 實作。利用 Active Directory、DHCP、DNS、FRS 及 Windows Server Base OS 管理套件，您可以充分監視基礎結構的大部分問題，保護 Active Directory 基礎結構的健康狀態，當然還有您的使用者。利用報告資料倉庫內收集的大量資料，您可以分析效能和事件資料來協助決定容量計劃和效能趨勢。
如需本文中所討論的管理套件及其他許多管理套件，請參閱 Management Pack Catalog (英文)。
Active Directory 管理套件的下一個更新版本將包含一些閾值的常用修正和調整。下一版產品 (稱為 System Center Operations Manager 2007) 中將會有更吸引人的新功能，包括可從單一組態群組中監視多個樹系、可定義網域控制站的群組 (各群組之間會有各自預期的複寫延遲)，以及可監視在下一版 Window Server 上執行的網域控制站。如需詳細資訊，請造訪 MOM 網站 microsoft.com/mom

John Hann 從 MOM 2000 開始使用 MOM，並在 2004 年成為 MOM MVP。John 會定期為 MyITForum.com、MOMCommunity.com 及 LearnMOM.com 撰寫文章。您可以透過他的部落格 (英文) 與他聯繫。


 Windows 系統管理: 在安全的環境中遊戲
Windows 系統管理 Matt Clapham

在安全的環境中遊戲
摘要:
  • 寫入保護資料夾和登錄機碼
  • 複製保護失敗
  • 防火牆問題
  • 企業客戶問題

我白天在 Microsoft 擔任安全性專案經理工作。此外，我也經常為 TechNet Magazine 撰寫安全性文章。不用說，我當然非常重視安全性。不過我也有其他興趣
。在閒暇時，我喜歡玩 Windows® 架構的遊戲。我特別愛玩射擊、模擬訓練、角色扮演和即時策略等類型的遊戲。不過這裡還有個問題。就和我的朋友 Jesper Johansson 及 Aaron Margosis 一樣，如非必要，我拒絕以系統管理員身分執行遊戲。有部份原因是為了確保自己在網路遊戲中的失敗，是因為技巧不足，而不是因為有人蓄意植入 Rootkit 所產生的影響 (請參閱「資源」資訊看板所列出的 Quake 3 Buffer Overflow Advisory)。
我非常在意這一點，因此經常無法玩最新最熱門的遊戲 (請參閱 [圖 1])。如果在系統管理員帳戶中安裝和更新之後，仍無法在小型企業伺服器 (SBS) 聯合網域上以限制權限的使用者帳戶 (LUA) 執行遊戲，我會立刻移除該遊戲。如此粗劣的工程技術不值得使用，我也不缺遊戲可玩。我承認這聽起來或許比較極端，但我非常堅持不妥協。不過我倒是不反對為了高品質的休閒遊戲，而接受一些小缺點，這裡所要討論的就是這個部份。現在就讓我和大家分享一些個人所遇到的遊戲相關問題，以及我找出的對應解決方法。要迅速瀏覽最佳方式的摘要內容，請看資訊看板中的「以限制權限使用者身分玩遊戲的秘訣」。
圖 1 執行手動更新的檔案存取問題
圖 1 執行手動更新的檔案存取問題

常見問題
此權限問題十分常見。事實上有許多不同的遊戲和其他類型的程式，都需要使用系統管理員權限才能正確執行。請參考知識庫文件 Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account (請參閱 support.microsoft.com/kb/307091)。其中列出近 200 種無法以限制權限使用者身分執行的遊戲和應用程式，其中也包括幾個 Microsoft 的程式。
我要澄清的是，我並不認為需要系統管理員權限才能安裝或 (手動) 更新遊戲是個問題。在我們有能力於 Windows 上製作每位使用者的安裝常式之前，這是必然的現象。這一天遲早會來，但現在時候未到。然而遊戲一旦安裝和更新完成，就應該可以在系統上由任何一位使用者操作，即便是限制權限的使用者也沒問題。
嘗試寫入保護資料夾和登錄機碼 我最常見的問題，是因為遊戲嘗試寫入保護資料夾或登錄機碼，而在啟動或遊戲中失敗 (這是許多 Windows 架構應用程式常發生的問題)。在預設情況下，只有系統管理員 (以及可替代的進階使用者) 可以寫入某些資料夾 (例如 %PROGRAMFILES%) 以及登錄區 (如 HKEY_LOCAL_MACHINE)。因此所造成的錯誤較為顯而易見：「錯誤 42：無法於 C:\Program Files\CoolGamesInc\NewestFPS\Logs\ 寫入記錄檔」或「遊戲並未正確安裝，請重新安裝並重新啟動」。我也曾經在遊戲中途看過這樣的例子，例如在儲存進度的過程中出現錯誤訊息。有時候遊戲作者至少會提醒使用者，目前的遊戲需要使用系統管理員權限才能運作，這是我玩神話世紀 (Age of Mythology®) 所遇到的經驗。大型多人線上遊戲 (MMOG) 經常會出現權限問題，因為這種遊戲經常自行更新，而其自我更新的方式特別刁鑽，較難以技術方式解決問題。在執行 EVE 線上試用版時，我發現它不僅將記錄檔放在錯誤的位置，還嘗試於安裝資料夾中自我更新遊戲內容資料。
複製保護失敗 我第二常見的遊戲啟動失敗原因，是由於遊戲內建複製保護 (或其他反盜版功能) 無法在限制權限使用者身分下運作。有可能是驅動程式無法正確啟動，或者未執行某些背景服務。我最常見的典型範例，就是遊戲要求使用者插入磁片，即使要求的磁片已放入磁碟機內仍出現相同訊息。我也看過某些遊戲表示必須具備系統管理員權限，因為它誤以為只有系統管理員才能正確執行複製保護檢查。最糟的情況則會出現不正確、荒謬的錯誤訊息，而且在該遊戲的支援網站上並無參考內容。
要求防火牆例外失敗 可於區域網路或網際網路上參與的多人遊戲十分常見，Windows XP Service Pack 2 (SP2) 新增了一個警告訊息，藉以告知使用者應用程式何時嘗試接聽網路。我也因此觀察到下一個常見的問題：需要防火牆例外，但是不會要求在安裝時期加入此例外的遊戲。既然限制權限使用者無法變更防火牆組態設定，在缺少某些由系統管理員執行的組態設定情況下，根本無法補救此警告 (請參閱 [圖 2]) 的問題。更糟糕的是，有時候問題並不明顯，因為警告出現在 Windows shell，而不是在遊戲介面中。事實上，我通常要到離開遊戲之後，才發現這些錯誤訊息。
圖 2 遊戲受到防火牆設定的阻擋時
圖 2 遊戲受到防火牆設定的阻擋時
企業客戶問題 我發現另一個問題雖然和限制權限使用者並無直接關係，但仍舊值得討論。我以小型企業方式來執行家用電腦環境 (我在此不多加贅述，詳情可參閱以下文件 Master Your Domain:Build a Corporate Network at Home，這是由我和 Jesper Johansson 為 2006 年十月號 TechNet Magazine 所撰寫的文章。使用 SBS 2003 (R2)，我建立完整的 Windows 網域，其中 [我的文件] 資料夾重新導向伺服器共用。這就是我發現最後一項常見問題的過程：無法處理企業客戶的遊戲。
我發現神話世紀 (Age of Empires® III, AoE3) 的一項雙重致命傷。一直到開發團隊名錄之前，遊戲在限制權限使用者身分下都能正確啟動和執行。然而我發現劇情的載入速度變慢，因為有許多記錄資料透過網路寫入。此外，在我每次離開遊戲之後，AoE3 就會遺失我的組態設定、已儲存遊戲，以及遊戲進度。這些檔案顯然都存在 [我的文件] 資料夾中，但遊戲卻無法載入。這的確令人失望，尤其考量到 AoE3 較過去同系列舊版本更適用 LUA。
我曾看過一個遊戲至少會告知此類企業客戶議題。在我嘗試神鬼寓言：失落的章節 (Fable®:The Lost Chapters™) 時，這個遊戲很體貼的告訴我，這裡不支援遠端 [我的文件] 資料夾，然後才優雅的結束程式。我讚揚開發小組找出不支援條件並將其排除在外的精神。不過，遊戲特地停止使用者的舉動的確有點奇怪，尤其當遊戲只想在 [我的文件] 資料夾中放置幾百萬位元組 (MB) 資料的情況下。

簡易解決方案
我已經在難以計數的遊戲中看過這些問題無數次。幸好大多數的問題都有方便的因應措施。我最喜愛的修復方式，就是直接中止整個遊戲，切換到其他發行者出版的同類型 LUA 就緒遊戲。這個方法聽起來也有些極端。在剛剛花了 60 塊美金買新遊戲之後，這也不是最佳解決方案。況且我也不能退貨，因為盒子已經開封了。就讓我們來看看該如何修復這個已經入手的遊戲吧。以限制權限使用者身分玩遊戲的秘訣
  • 升級到 Windows Vista。
  • 在購買前先試用。如此一來，就能看出完整版的 LUA 問題。
  • 參考程式清單中已知在 LUA () 下執行會產生問題的程式。
  • 尋找有 Designed for Windows 標籤的遊戲。
  • 安裝後先更新遊戲，再以限制權限使用者身分執行。
  • 當您發現遊戲無法以限制權限使用者身分運作時，請向發行者以及公司的技術支援服務部門表達您的疑慮。
  • 如有必要，可使用系統本機進階使用者帳戶登入。

修復複製保護問題 首先，我們要對付複製保護驅動程式的問題。複製保護系統已經存在，但這並不表示他們可以阻止非系統管理員執行遊戲！大多數遊戲使用 Macrovision's SafeDisc 複製保護機制，也就是安裝驅動程式來檢查是否為正版遊戲磁碟。在預設情況下，驅動程式組態設定為視需求啟動 (這是限制權限的使用者無法執行的功能)。Microsoft 和 Macrovision 都提供修復程式，但我發現另一個因應措施：
  1. 使用系統管理員帳戶開啟 [裝置管理員]。
  2. 到 [檢視] 功能表中，選取 [顯示隱藏裝置]。
  3. 展開 Non-Plug and Play Drivers 節點。
  4. 開啟 Security 或 SecDrv 驅動程式的屬性 (請參閱 [圖 3])。
  5. 將啟動類型變更為 [自動]。
圖 3讓複製保護正確執行
由於驅動程式現在於電腦開機同時啟動，因此使用者只要插入磁碟，即可隨時執行遊戲。
修復檔案系統和登錄存取問題 假定可自由存取檔案系統或登錄的任何部份，這不僅發生在遊戲軟體中，而是許多新、舊程式都有的常見問題。Aaron Margosis 的文章 Problems of Privilege:Find and Fix LUA Bugs 即深入探討各種導致要求系統管理員權限相關問題的解決方案。
存取問題或許較難追蹤，不過一旦識別出必要的檔案、資料夾和登錄機碼組合，就能直接放寬存取控制清單 (ACL) 以允許使用者玩遊戲。我曾經成功使用以下方式：
  1. 從 microsoft.com/technet/sysinternals 取得最新版本的 Filemon 和 Regmon。
  2. 以系統管理員身分執行工具，並且要求開始收集記錄。
  3. 以系統管理員身分先玩幾分鐘，執行最常見的工作 (開始新戰役、儲存遊戲、主導網路遊戲等等)。
  4. 過濾 Filemon 和 Regmon 的結果，以專注於受測試遊戲的存取功能。
  5. 視需要放寬有問題的資料夾和登錄機碼的 ACL。
  6. 以非系統管理員身分執行遊戲，以確定現在可以開始運作。
提醒您在放寬 ACL 時請注意：請勿放的太寬 (例如 Everyone—Full Control) 或者設定太高的層級 (如 HKEY_CLASSES_ROOT)。此外最好能避免變更系統資料夾的任何使用權限，如 like %SYSTEMROOT% 和 %PROGRAMFILES%，以避免完全破壞 Windows，或者讓系統處於不安全的狀態。
另一項可能的因應方式，是以系統本機進階使用者身分執行遊戲。這不是我的首選方式，但利用系統本機的身分可以在發生錯誤時，將影響範圍侷限在單一工作站內。我發現對於大多數只有以系統管理員身分才能正常運作的遊戲，這個解決辦法皆可適用。
另外，我還發現以系統管理員身分短暫執行遊戲，是讓遊戲執行自我更新的好辦法。我通常以系統管理員身分執行遊戲，呼叫其更新選項，然後離開遊戲並且回到限制權限的使用者帳戶中，再真正開始玩遊戲 (值得一提的是，Windows Vista™ 可以讓限制權限的使用者更新應用程式，並假設修補程式是由原發行者指派)。
Windows Vista 亦可幫助遊戲和其他應用程式解決檔案和登錄存取等問題。在預設情況下，由限制權限使用者執行的程式會啟動虛擬化作業 Shim，重新將導向錯誤的檔案和登錄存取導向使用者指定的快取。我個人曾看過以 Windows 9x era 設計的遊戲 (例如終極戰區 (The Neverhood)) 無法在 Windows XP 中正確執行 (由於使用權限的緣故)，但是卻能以預設 Shim 在 Windows Vista 中正常運作。我期待能在 Windows Vista 上測試其他有問題的遊戲，不過我有預感大概很難找到 Windows Vista 無法正常 Shim 的遊戲。
修復防火牆問題 防火牆問題在一開始安裝遊戲時最容易解決。不過，如果遊戲安裝程式不夠強，無法要求和設定必要的防火牆調整，我這裡有個方法也能夠達到相同目的：
  1. 以系統管理員身分登入。
  2. 開啟 [Windows 防火牆] 控制台。
  3. 選擇在防火牆例外清單中新增程式。
  4. 從清單中選取遊戲，或者根據提示瀏覽並找出遊戲執行檔。
將遊戲執行檔新增到防火牆例外清單之後，我就能確保遊戲可存取任何正常運作所需要的連接埠。更多遊戲接踵而來!
修復企業客戶的問題 企業客戶在執行遊戲時所遇到的問題，將隨著時間消失。隨著寬頻網路的普及，有愈來愈多家庭使用多部電腦，而且也有更多使用者在家中執行 SBS。不過就現階段而言，仍需要解決方案。
以我的個案來說，我發現系統本機 LUA 可以解決重新導向 [我的文件] 問題。神話世紀 (Age of Empires III) 和神鬼寓言：失落的章節 (Fable:The Lost Chapters) 兩個遊戲，都能以限制權限使用者身分正常運作，只要確定 [我的文件] 資料夾並未重新導向至網路資料夾中即可。資源
  • Quake 3 Buffer Overflow Advisory
  • Windows Vista Application Development Requirements for User Account Control Compatibility
  • Applying the Principle of Least Privilege to User Accounts on Windows XP
  • Aaron Margosis’ LUA Buglight tool
  • Standard User Analyzer
  • Master Your Own Domain:Build a Corporate Network at Home
  • Problems of Privilege:Find and Fix LUA Bugs
  • Certain Programs Do Not Work Correctly if You Log On Using a Limited User Account

結論
我強烈建議以限制權限使用者身分執行，這樣您才能充份運用非系統管理員執行的各項優勢。在企業連結、權限極小的環境下玩遊戲，的確不太容易，但絕非不可能。多年來，我發現有許多各種類型的遊戲，都能以限制權限使用者身分正常執行。另外我也發現諸多修復方式，都能讓各種遊戲正確運作。同時在 Windows Vista 的虛擬化作業下，不可能在 Windows XP 中以限制權限使用者身分玩的遊戲，又再度可以正常運作了。

Matt Clapham 是 Microsoft 的安全性專案經理，目前積極參與西雅圖 IT 安全性社群，同時也是 IT 籌備專案「風險管理」小組的成員。


 編輯的話: 揭開面紗
編輯的話
揭開面紗

WINDOWS VISTA 即將 在 2007 年強烈衝擊企業 IT 部門。根據 InformationWeek 最近一份 IDC 報告中預估，美國今年就會受到 Windows Vista 的直接影響，產生 100,000 個 IT 工作機會。今年全球約有 9 千萬台新機器安裝 Windows Vista 系統，到明年則預估有百分之八十的新機器，將預先安裝 Windows Vista 系統後，再出貨到各企業機構。在這個時候，您必須決定是否要在您的企業中部署這套作業系統。我們會從中提供協助。
本月的 TechNet Magazine 將展開一系列主題，深入探討 Windows Vista 的主軸 -- 也就是核心 (Kernel)。事實上，Windows Vista 具備一些不錯的新使用者體驗功能，但那可不是移轉到新系統的主要誘因。核心就像是作業系統的心臟，而 Windows Vista 核心運作方式也有顯著的改進。
這個世界上有誰比 Mark Russinovich 更適合撰寫此類變更內容，又有誰比他更瞭解 Windows 核心?他和 David Solomon 共同撰寫的 Windows Internals 一書，已成為所有想揭開 Windows Vista 神秘面紗的人士的最佳資源。
本月，Mark 將告訴我們 CPU 配置的相關改進之處，這是讓桌面應用程式的回應速度更快的原因。此外也說明 Windows Vista 如何在核心層級中增進多媒體效能。本文亦探討 Windows Vista 內部 I/O 模型的重要變更，其中包括檔案架構的符號連結、取消同步 I/O 作業的新功能 (對我而言，這是最主要的變更)，以及 I/O 優先順序概念。請務必在為您的企業評估 Windows Vista 效用時，閱讀 Mark 這篇詳盡的文章。
當然還有許多日常工作需要進行，我們也會幫助您完成這些作業。本期還探討管理範疇，包括在 Active Directory 中委派授權、Windows Vista 中的新群組原則樣板、群組原則疑難排解，以及使用 MOM 監控 Active Directory 等相關文章。
最後，若您喜歡玩遊戲「卻又」擔心安全問題，那麼一定要看看我們在安全環境中遊戲的功能。俗話說的好，「只會用功不玩耍，聰明孩子也變傻」。-- JOSHUA TRUPIN

感謝下列 Microsoft 技術專家： Matt Ayers、Eugene Bak、Vijay Bharadwaj、Michael Fortin、David Hicks、Khushru Irani、Mehmet Iyigun、Arun Kishan、Mark Lawrence、Pavel Lebedynskiy、Ben Mickle、Michael Murgolo、John Orefice、Ravisankar Pudipeddi、Jeffrey Richter、David Solomon、Jim Truher、Landy Wang 以及 Andy Zeigler。


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

移動您的資料
SQL Examiner Bundle
www.sqlaccessoter/ind.com (英文)
不論您在公司擔任什麼職位 -- DBA、開發人員、業務專員，或身兼數職 -- 只要您有使用 SQL Server™，就應該曾經在各種環境之間移動資料，並且必須確保資料的完整性，同時還要保持完整的資料結構。SQL Server 當然有許多內建的複寫和同步處理功能。不過若是您想知道自己的 QA 資料庫是否可完全符合您的開發資料庫，則像 TulaSoft 的 SQL Examiner Bundle 工具，就可以為您節省時間與精力。
只要按幾下滑鼠，應用程式就能從兩個資料庫執行個體之間，找出資料庫結構或資料本身的差異。您只要指定應用程式以及要檢查的資料庫即可。SQL Examiner Bundle 恰如其名，其中集聚了兩個應用程式：SQL Examiner 和 SQL Data Examiner。SQL Examiner 會檢視資料庫結構，而 SQL Data Examiner 則會檢視所有資料，並指出所有差異。
SQL Examiner 會檢查和比較資料庫執行個體中所有內容，從資料表和預存程序，到全文檢索目錄和 XML 結構描述集合。至於使用 SQL Server 2005 的人，也可以比較 Common Language Runtime (CLR) 組件。完成資料庫的比對之後，SQL Examiner 還可以讓您選擇要同步處理哪些資料庫物件，以及同步處理的方向。
使用 SQL Examiner 檢查並比較您的資料庫
使用 SQL Examiner 檢查並比較您的資料庫
有一項很炫的功能，就是應用程式會產生 SQL 指令碼來建立物件，並且會指出資料庫之間所產生指令碼的差異。這在執行建立指令碼或移轉指令碼來建立目標資料庫結構失敗時，非常好用，因為可以指出錯誤之處 (您一定會驚嘆：「噢，原來那就是我漏掉叢集索引的地方！」)。您可以個別執行產生的指令碼、將這些指令碼儲存起來稍後執行，或者也可以按一下 [同步處理 (Synchronize)] 按鈕，讓應用程式為您完成所有作業。
另一項不錯的功能，是可以選擇是否要在比較中新增排除項目，例如忽略註解、觸發程序、索引或者物件的擴充屬性。檢查結構比較之後，SQL Data Examiner 可以讓您檢視資料，查看所有差異之處。您可選擇要比較哪些資料表，也可以選擇要比較這些資料表中的哪些資料行。完成資料表的比對之後，您就可以看出有哪些資料列相同、哪些則不同，以及有哪些僅存在於單一資料庫中。
與 SQL Examiner 一樣，SQL Data Examiner 可以讓您只要按一個按鈕，就能夠同步處理資料表，或者選擇要傳送的資料以及傳送的方向。這兩個應用程式都能夠讓您將所有設定儲存為專案，才不用每次重新建立工作。這兩個應用程式可以分開購買，但根據我個人的經驗，您一定兩個都會要。
價格： 單一使用者授權為 $299.95 美元。

搜尋重複的檔案
zsDuplicateHunter (Professional Edition)
Zizasoft (英文)
若您的工作包括桌上型電腦的管理，那麼您一定遇過使用者發生電腦儲存空間「不夠」的情形。調查之後顯示，使用者每次編輯文件之後，就會複製一個複本，即使您已經提供使用者專用的 Network Attached Storage (NAS) 系統來備份檔案。或者，您的記錄伺服器因採用批次處理來重複大量記錄，而佔用了所有配置的伺服器空間。這些問題可能的解決辦法就是 zsDuplicateHunter Professional Edition，這個是一個以 Java 為基礎且可於 Windows®、Linux 或 Mac OS X 上執行的重複檔案搜尋工具。
此應用程式可讓您輕鬆搜尋磁碟機、目錄或網路共用，並且找出可能重複的檔案。此應用程式不僅會進行名稱比對，還能夠以檔案大小、檔案總和檢查碼，甚至於檔案摘要來將檔案分組，以確保您清理的檔案確實是不同的。此外，您無須永久刪除重複的項目。應用程式為預防萬一，可讓您將所有標示為重複的項目移動至指定資料夾。
還有一項不錯的功能，是 [保留本資料夾的檔案，刪除其他位置的重複項目 (Keep Files in this Folder, Delete Duplicates Elsewhere)] 選項，這可以讓您選擇要保留的來源目錄，並刪去磁碟上所有其他重複項目。在搜尋結果中，您也可以連按兩下任一檔案，以便使用關聯的檔案檢視器開啟該檔案、進行排序，以及篩選出您要的結果。另一項好用、IT 專家級的功能，是您可以針對應用程式在尋找重複項目時，所佔用的記憶體進行微調。此外，您還可以停用隱藏或系統檔案的搜尋，以確保不會刪掉任何不該刪除的檔案，或者刪掉由作業系統或其他應用程式所使用的檔案，達到更萬全的保護。
Professional Edition 還支援搜尋結果集的細微篩選，讓您套用規則運算式精確找出要刪除的檔案。
價格： 單一使用者授權為 $39.95 美元。

隨身攜帶應用程式
MojoPac
www.mojopac.com (英文)
若您經常遊走於不同環境中，卻又很想念您特別偏好的應用程式和桌面設定，或者您就是不喜歡在別人的桌面上留下自己的足跡，不妨看看 RingCube Technologies 所製作的 MojoPac。
先撇開這怪怪的名字不說，MojoPac 可以讓您將任何 Windows XP 系統 (Home、Professional、Media Center 或 Tablet) 上的所有設定和應用程式，存入可透過 USB 2.0 連接到主機系統的 USB 硬碟或其他個人媒體裝置 (例如 Zune 或 iPod，或者儲存空間大的手機)。在撰寫本文期間，尚無法支援 Windows Vista™ 和 Windows 2000 主機，不過產品網站上的文件已表示很快就會推出支援這些作業系統的升級版本。
用 MojoPac 隨身攜帶系統設定
用 MojoPac 隨身攜帶系統設定
目前 MojoPac 需要使用主機系統的管理員權限，但尚在開發中的 2.0 版將可支援限制權限的使用者模式。基本上，此工具會介入於主機作業系統和儲存體裝置之間，將應用程式安裝到可攜式裝置之後第一次啟動時，MojoPac 會觸發初始 Windows 帳戶設定，在 MojoPac 裝置上為您的 MojoPac 使用者設定個人組態。
一旦開始運作，就可以輕鬆在主機系統和 Mojo 系統之間切換：只要按一下螢幕上方的工具列 (可以最小化)。在 MojoPac 已啟動的情況下，可以用平常的方式將應用程式安裝到 Mojo 裝置中。此外，只要您遵循讀我 (Readme) 文件中的重要警告，將程式安裝到預設目錄，應該就沒有問題了。
總而言之，MojoPac 對於經常出差在外但希望隨時使用個人組態的 IT 專家而言，是一項重要的工具。例如，您只要將所有的系統公用程式、封包偵側程式 (Packet Sniffer) 以及流量監視器都放入 MojoPac，即可從公司的任何一台 PC 進行疑難排解，完全不留痕跡。
價格： 單一使用者授權為 $49.99 美元。

書評
Administrator’s Guide to SQL Server 2005
www.aw-bc.com (英文)
有愈來愈多的 IT 團隊發現 SQL Sever 2005 有優異的威力和廣泛的功能。從豐富的 XML 資料支援、SQL Server Integration Services (SSIS)，到 SQL Server 2005 Service Broker，應用程式加入了許多好用的增強功能。為了幫助您開始邁向升級之路，或者有效管理您最近部署的 SQL Server 2005 執行個體，Buck Woody 撰寫了極為出色的參考指南 -- Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional，2006)。
本書和其他市面上的參考文件不同，其中是以簡潔、實用的方式深入探討如何有效管理新的伺服器平台。書中一開始就先告訴您，如何將基礎架構調整為符合應用程式需求的適當大小，同時也說明哪些 SQL Server 版本適合在哪些情境下使用。在這裡，您也可以了解如何建構優良的基礎架構，以確保後續安裝過程中不會發生可避免的效能瓶頸。
本指南接著還描述 SQL Server 提供的各種工具，例如增強的 SQL Server Profiler 以及全新的 SQL Server Management Studio。您也可以深入探究維護與自動化工作，了解如何根據伺服器的特徵和使用模式進行成長規劃，以及如何為您的系統擬定適當的維護計劃。
在安全性的章節中，您也可以探索如何保障環境的安全性，包括網路、硬體、作業系統及 SQL Server 執行個體。在這裡，您還可以一探新平台所提供的加密、憑證和金鑰管理服務。
另一章節則說明如何根據您的系統需求，打造確保系統維持高可用性的各種機制。您將可以進而研究叢集、資料庫鏡像、複寫和記錄傳送等方式，以達到您對於系統可靠性的需求。虛擬化技術已成為不需要額外硬體負擔即可達到高可用性的絕佳方式，因此本書亦會逐步說明如何使用 Microsoft Virtual Server 建立雙節點叢集。
有關 SSIS 的章節中不但說明如何使用新的工具 (和 DTS 說再見!) 來發展和部署擷取、轉換和載入 (ETL) 功能，還介紹如何使用各項服務來建立監視、電子郵件通知及備份工作。
最後幾個章節則探討全新 SQL Server 平台所提供的報告及分析服務 (Reporting Service 及 Analysis Service)。這裡會提到報告的設計與建立、報告系統的管理，以及維護分析服務部署的相關作業。
總而言之，Administrator’s Guide to SQL Server 2005 是管理、監視與升級到 SQL Server 2005 的快速入門寶典。
價格： $49.99 美元。


 SQL 問題與解答: 資料庫大小、鏡像、標示的交易...等等
SQL 問題與解答
資料庫大小、鏡像、標示的交易...等等
由 Nancy Michell 編輯

移動叢集
問：我需要將一個 SQL Server 2000 叢集移轉到新的 IP 位址，包括底下的實體伺服器以及 Windows® 叢集和 SQL Server™ 叢集。我是否需要重建整個解決方案？
答：不用，您只需要執行 SQL Server 安裝程式，並修改 IP 位址即可。本篇知識庫文件內有執行方式的說明。

資料庫大小
問：我的生產環境中採用 SQL Server 2000 SP4，其中包含：使用近 10GB 空間的關鍵資料庫、SIMPLE 復原模型、佔用 9,850MB 的主要檔案，以及 88MB 的交易記錄檔。資料庫的備份也有將近 10GB。我是否應該縮減資料庫的大小，以獲得更佳的效能？如果是，我應該使用 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE？遺憾的是，我沒有非尖峰時段可執行這項維護工作。
答：DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 只有在資料庫歷經多次刪除和更新之後會縮小資料量時，才會有所助益。我好奇的是，您為什麼要考慮這個問題呢？現在每 10 GB 的磁碟空間價格大約只要 $20 美金。再增添 100GB 左右的磁碟空間讓系統運用，不是更理想嗎？空間愈分為片段，效能就愈趨下降，但如果您無法進行維護，就沒有太多選擇。有的人在這種情況下會使用資料庫的第二份複本。他們會透過複寫的方式保持一份最新的備份，然後針對備份複本進行維護，最後再將應用程式切換到備份上執行。這顯然需要變更一些程式碼，並且無法使用 SIMPLE 復原模型 (需要改為 FULL 或 BULK_LOGGED)，不過就長遠來看，可能是不錯的解決方案。

升級與效能
問：我需要將兩個應用程式從 SQL Server 2000 移轉到 SQL Server 2005。我該如何避免在升級過程中影響效能？
答：一般而言，下列情形都可能在升級時導致效能降低，因此請盡量避免：
  1. 您在升級至 SQL Server 2005 之後，尚未重建統計資料。
  2. 您有 JOINS 和 WHERE 子句，其中會比較兩種不同的資料型別，因而導致效能不良，這尤其在伺服器原來執行的是 SQL Server 2000 SP3 (含) 以前的版本 (請參閱 support.microsoft.com/kb/271566/)。
  3. SQL Server 2005 執行個體的組態有誤；記憶體、Address Windowing Extensions (AWE)、驅動程式...等等的組態不正確。執行 SQL Server 2000 的電腦已經過調整，但是執行者已離職且沒有記載相關的變更，因此從未在 SQL Server 2005 執行個體中完成相對的調整。
  4. 硬體出問題。購買新硬體的原因，通常是要讓宣傳單看起來更耀眼，但實際使用上卻不如預期。
讓 SQL Server 執行個體進入生產階段之前，必須先建立效能基準線，才能確定您所預期的效能可以實現。這樣就能排除基礎結構方面的問題。您必須查看 Perfmon 計數器，例如磁碟、I/O 及記憶體，並且和執行個體之間進行比較。

資料庫鏡像
問：我有使用資料庫鏡像，而想要啟用 READ_COMMITTED_SNAPSHOT 資料庫選項。我在鏡像設定完成之後嘗試啟用該選項時，出現了例外狀況，其中表示 db 正處於鏡像工作階段所以無法執行命令。
答：這是由於設定 READ_COMMITTED_SNAPSHOT 選項之後需要重新啟動資料庫，才能生效。因此，您必須中斷鏡像階段、設定選項，然後重新啟動資料庫。這些步驟完成之後，您就可以重新建立鏡像。鏡像資料庫在建立工作階段之後會偵測到設定的選項，並於萬一需要容錯移轉時套用。

問：我嘗試安裝同步鏡像，卻得到 1418 錯誤。執行 Netstat -ano 顯示 SQL Server 正在所有伺服器的正確埠上接聽。但是在我嘗試啟動鏡像時，卻出現錯誤訊息。到底是怎麼回事呢？
答：其中一個可能性，是您的防火牆封鎖了通訊管道；這是相當常見的問題，您應該進一步檢查探討。請參閱下列白皮書的詳細說明：Troubleshooting Database Mirroring Setup (英文) 以及 MSSQLSERVER_1418 (英文)。
只要記住，這個問題並非僅針對非同步鏡像。事實上也有可能發生在同步鏡像。
您看到的錯誤訊息 (「伺服器網路位址 "%.*ls" 無法連上或不存在。請檢查網路位址名稱，然後重新發出命令」) 是正確的。通常並非遠端夥伴不存在，只是找不到遠端夥伴而已。
如果遠端夥伴已關閉、未接聽該埠，甚至於結束點已關閉 (可能由於夥伴無法以相同的加密機制進行交涉，或者有其他的驗證問題)，就有可能發生這樣的狀況。此外，亦有可能是夥伴遭到封鎖，這可能是由發出命令之夥伴的防火牆所導致。
可能需要排除的其他問題，包括資料來源名稱 (DSN) 以及名稱解析問題。一般建議使用完整的網域名稱。總之，雖然問題經常是防火牆造成的，但還是要記住有許多其他潛在原因。

問：我想使用 SQL Server 2005 鏡像功能；不過我聽說在多重應用程式連接到同一 SQL Server 執行個體的多個資料庫時，不建議使用鏡像。這是正確的嗎？
答：其實要看每個應用程式究竟使用自己的資料庫、跨資料庫，又或者是以分散式交易協調器 (Distributed Transaction Coordinator，DTC) 交易而定。如果使用跨資料庫交易，那麼鏡像可能造成邏輯上的不一致，而無法以預期的方式認可交易。有關這類情況所導致的結果以及詳細說明，請參考此文件 (英文)。
如果多重應用程式使用多個資料庫，而每個應用程式都有自己的資料庫，那麼鏡像就不會造成這些問題。

標示的交易
問：「標示的交易」究竟是什麼？若一個資料庫是 SQL Server，另一個是 Oracle，這樣是否還能使用標示的交易？
答：交易的標示是 DBA 定期的工作，就是在所有記錄的相同位置放入標記。這項動作只要結合還原資料表至交易標記的能力，即可讓您將所有資料庫還原至同一時間點。這樣的作法十分痛苦，因為您必須還原所有相關資料庫，而所有資料庫中的資料都會遺失，因此您必須確保自己別弄丟記錄檔，才能避免這種情況發生。標示的交易是 SQL Server 專屬的功能，因此若是您的分散式交易中包括 SQL Server 以外的其他資料庫，這些資料庫就無法加入交易標記。一般而言，只有極少數的分散式資料庫系統使用交易標記。他們只會把交易記錄的遺失視為災難事件，需要大量手動作業才能復原。

Access-To-T-SQL 轉換工具
問：針對預存程序，是否有現成的自動化轉換工具可將 Access™-SQL 轉換到 T-SQL？
答：請嘗試 SQL Server Migration Assistant (SSMA) for Access，您可以從此處下載 (英文)。其中還有 SQL Server Migration Assistant for Oracle、SQL Server Migration Assistant for Sybase 以及 Migrating Informix Databases to Microsoft® SQL Server 2000。
若要從 Access 升級至 SQL Server，您可使用 Office Upsizing Wizard，不過 [圖 1] 所顯示的 SSMA for Access 有更多功能，包括轉換評定報告以及網路掃描。SSMA for Access 亦可修正許多目前 Office Upsizing Wizard 無法正確處理的問題。
圖 1 SQL Server Migration Assistant for Access
圖 1 SQL Server Migration Assistant for Access

非叢集索引
問：我有一個資料表，其中的主索引鍵是由兩個 GUID 組成 (假設為 GUID1 和 GUID2)。我已經針對 GUID1 和 GUID2 建立唯一的叢集索引。現在為了要提升效能，我想在 GUID2 及 GUID1 上建立第二個非叢集索引。請問如果我宣告索引是唯一的，是否會降低效能？
答：宣告非叢集索引是唯一的，對效能並不會有負面的影響。事實上，這樣做會減少索引樹狀結構的層級。
非叢集索引宣告為非唯一時，資料列定位器會附加至根頁面和非分葉頁面中、索引項目的索引鍵部分。如此一來，就能方便刪除和更新索引項目，以避免出現重複的索引鍵項目時掃描同義字鏈結 -- 而是可藉由索引鍵加上定位器的系統搜尋作業，找出要變更的特定項目。結果是這些項目的長度會增加 (就您所選擇的叢集索引鍵而言會相當長)。因此，根頁面和非分葉頁面自然會更快速的填滿。如果索引是唯一的，就應該用這樣的方式宣告之。
重點是，不論資料表是否有叢集索引，任何資料表上未宣告為唯一的非叢集索引，都會將定位器附加至根頁面和其他非分葉頁面的索引項目上。
此外，如果您使用 int 識別項資料行做為代理 (Surrogate) 索引鍵，然後加上兩個唯一的索引鍵 (GUID1，GUID2) 以及 (GUID2，GUID1)，這樣就十分有機會能夠改善效能，因為索引中會有 4 位元組的叢集索引鍵，而不是 32 位元組的叢集索引鍵。

更新鎖定
問：我的預存程序結構如下：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
此預存程序只允許一位呼叫者取得鎖定，其他呼叫者必須等待。請問我是否能藉由減少隔離等級，達到相同的目的？
READ COMMITTED 似乎才是正確的隔離等級，因為此交易只有一項查詢，而且如果有其他交易也在更新相同的記錄，此交易就必須等待其他交易完成。這是正確的嗎？
答：造成其他呼叫者等待的並不是範例中的可序列化設定，而是更新作業本身。沒錯，您可以將隔離等級設定為 READ COMMITTED，這樣更新作業就會在其使用的索引上採用更新鎖定。這會導致其他程序在執行相同陳述式時發生問題，因此他們會進行封鎖，直到更新完成 (如果更新是唯一的陳述式，那麼您也不需要明確交易；每個陳述式若不屬於外顯，則都會隱含在自己的交易中)。
然而，若 UPDATE 陳述式中的 WHERE 子句沒有找到符合的資料列，則使用可序列化的隔離等級，就會導致這類資料列無法於其他交易中進行插入或修改。如果您以 READ COMMITTED 隔離等級執行 UPDATE，就不會發生上述情況，且其他交易就可以引入符合更新的資料列。倘若預存程序碼和您提供的程式碼相同，則採取上述任一 (可序列化或交易) 動作都沒有意義；只要直接執行更新即可。

感謝下列 Microsoft IT 專家提供其技術專業知識： Gaurav Aggarwal、Anthony Bloesch、Todd Briley、Shaun Cox、Roberto Di Pietro、Michael Epprecht、Kevin Farlee、Umachandar Jayachandran、Chuck Ladd、Kaloian Manassiev、Luciano Moreira、Ward Pond、Mark Prazak、Arunachalam Thirupathi、Roger Wolter、Clement Yip 及 Frankie Yuen。


 公用程式焦點: Group Policy Inventory
公用程式焦點
Group Policy Inventory
Greg Steen
下載本文程式碼: GPInventory.exe (150KB)

如果您不進行追蹤的話， 要怎麼知道您有哪些資源？隨時隨地掌握詳細的盤點資料，可以讓您在預算會議和年度稽核的時候，節省許多時間和困擾。因為高層主管一定會想知道誰擁有什麼、為什麼需要，還有全面升級的代價。
有一個可以協助您掌握這一切的工具，稱為 Group Policy Inventory (GPInventory.exe)，此工具包含在 Windows Server® 2003 Resource Kit 中。此程式可以讓您透過使用者原則結果組 (Resultant Set of User Policy，RSOP) 及 (或) Windows® Management Instrumentation (WMI) 查詢，從多重遠端主機上查詢與擷取系統資訊，如圖所示。一點也不令人驚訝的是，該程式可以輕易擷取群組原則資訊，同時還能夠有效率地取得詳細的系統資訊，例如已安裝的應用程式、處理器名稱和速度，或已安裝的 Hotfix 清單。而且還不止這些呢！由於這是 Windows Server 2003 Resource Kit 的一部分，所以完全免費。
圖 1 使用 GPInventory 蒐集資訊
圖 1 使用 GPInventory 蒐集資訊
GPInventory.exe 的用途很廣泛。例如，如果您需要驗證保固狀態，可以直接透過網路蒐集電腦的序號或服務編號，不再需要親自跑到各個電腦的實際位置。或者，如果您要了解實驗室的某一部電腦目前是否正在使用中，也可以直接從您的座位上查詢已登入系統的使用者。如果您有架設 Blade 伺服器，而且影像會定期更新 (例如，以清除並還原 QA 環境)，就可以查詢電腦的安裝日期，以驗證上一次套用影像的時間。
GPInventory 也很容易使用。只要指向目標檔案 (其中包含您要進行盤點的電腦清單)、選取要執行的查詢項目，然後針對清單進行處理即可。工具會透過網路連線到清單上的每一部電腦，並進行查詢。如果您要執行快速查詢，也可以直接從 Active Directory® 選取目標電腦，然後從 [查詢] 功能表中選取要執行的查詢動作。
若要針對某一部電腦執行 RSOP 查詢，您需要有產生原則結果組 (登入) 權限 (根據預設，網域系統管理員和委派系統管理員都擁有此權限)。WMI 查詢則需要遠端電腦的系統管理權限，除非您使用 WMI Control MMC 嵌入式管理單元，從 root\cimv2 名稱區將啟用帳戶和遠端啟用權限授與其他使用者。
執行查詢之後，您可以將結果儲存為以定位鍵分隔的文字檔案，或儲存為 XML 檔案。這兩種檔案格式都可以匯入 Microsoft® Excel® 進行分析。您可以進行排序然後套用自動篩選來尋找詳細資料。
GPInventory 還可以從命令列執行，因此，您可以輕易設定排定的工作，來查詢系統資訊並直接將結果儲存到 XML 檔案中，完全不需要 GUI 的介入。這對於需要長時間執行的查詢非常好用，因為如此可以在下班時間執行。
此工具有內建一組 RSOP 和 WMI 查詢，但是您可以新增、編輯和更新查詢檔案，來建立自訂清單。內含的說明文件可以告訴您如何在查詢清單 XML 檔案中定義新的查詢。
針對所有在網路上執行 Windows 系統的電腦，GPInventory.exe 是一項蒐集資訊的便捷工具，無論是要進行盤點、查詢群組原則或系統狀態資訊，都能夠輕鬆完成。您可以在我們網站的下載區段 (英文) 找到 Group Policy Inventory 工具的連結。

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


 The Cable Guy: Windows 中的 QoS 支援
The Cable Guy
Windows 中的 QoS 支援
Joseph Davies
本文有一部分是根據 Windows Server "Longhorn" 搶鮮版所撰寫。本文包含的所有資訊均有可能變更。

Quality of Service (QoS) 包含一組技術，利用這組技術就能夠以合乎成本效益的方式來管理網路流量，以加強使用者在家庭和企業環境中的體驗。QoS 技術可讓您測量頻寬、偵測不斷變化的網路情況 (例如頻寬的擁塞或可用性)，
以及排定優先順序或調節流量。例如，套用 QoS 即可優先傳遞不能等待的流量 (例如語音或視訊應用程式)，以及控制對可延遲之流量 (例如大批資料傳送) 的影響。若要提供 TCP/IP 流量的優先傳遞，需要主機和網路基礎結構裝置的支援。本專欄會說明使用 QoS 搭配 Microsoft® Windows® 架構主機的一些方法。
定義 TCP/IP 網路之 QoS 的主要問題，就是如何指定及提供 IP 流量的優先傳遞。雖然原始的 RFC 791 for IP 定義了服務類型 (TOS) 欄位，能夠指定優先順序、延遲、輸送量、可靠性及成本特性，不過 IP 基本上是傳輸效益最佳化的資料包架構封包交換技術，通常處理每個封包的方式都相同，並且以先到先處理為基礎。

設定優先傳遞
若要提供優先傳遞服務，可以採取幾種做法。您可以設定網路基礎結構針對標記的流量提供特殊處理，再讓傳送主機標記其連出流量。或者，可以讓傳送主機動態地安排網路基礎結構，根據其連出流量的特性 (例如位址及連接埠號碼) 提供特殊處理。
針對 TCP/IP 流量，您可以使用幾種不同的方法提供優先傳遞。例如，在 Ethernet 的網路介面層，IEEE 802.1p Tagging 會在 Ethernet 框架的虛擬區域網路 (VLAN) 標頭中使用 3 位元 Priority 欄位，標記由主機傳送的優先傳遞框架。VLAN 標頭會放在 Ethernet 標頭內，在 Source Address 欄位與 Length 欄位 (IEEE 802.3 框架) 或 EtherType 欄位 (Ethernet II 框架) 之間。
若要在傳送主機上實作 802.1p Tagging，網路介面卡和裝置驅動程式都必須支援 802.1p，而且網路介面卡要啟用 802.1p 支援。通常您可以從網路介面卡驅動程式屬性的 [進階 (Advanced)] 索引標籤啟用 802.1p 支援。乙太網路交換機也必須啟用 802.1p 支援。
在 IEEE 802.11 無線的網路介面層，Wi-Fi Multimedia (WMM) 的 Wi-Fi 聯盟 (Wi-Fi Alliance) 憑證會定義優先排序網路流量的四個存取類別。這幾個存取類別分別是 (從最高到最低優先順序排列) 語音、視訊、傳輸效益最佳化及背景。主機若要支援 WMM 排定優先順序，則無線網路介面卡及其驅動程式都必須支援 WMM。無線存取點 (AP) 必須啟用 WMM。
您可以在網際網路 (Internet) 層使用差異服務，並在 IP 標頭中設定差異服務代碼點 (Differentiated Services Code Point，DSCP) 的值。根據 RFC 2472 中的定義，DSCP 值是 IP version 4 (IPv4) TOS 欄位和 IP version 6 (IPv6) Traffic Class 欄位的高階層 6 位元。
新的企業路由器大多數都支援 DSCP 流量區分，可是通常預設是停用的。在轉送過程中，具備 DSCP 功能的路由器會讀取 DSCP 值，並會將封包放入特定的佇列中。舉例來說，您可以設定路由器根據您定義的 DSCP 值，將轉送的封包放入高優先、傳輸最佳化或低於傳輸最佳化的佇列。透過設定佇列和 DSCP 值，標有 DSCP 的流量可有不同等級的服務。例如，關鍵型網路流量會優先轉送，而且不會受其他低優先的大量資料流量所延遲。WMM 規格會定義 WMM 存取類別與 DSCP 值之間的對應。具有 WMM 功能的無線 AP 會讀取 DSCP 值，並根據其存取類別處理流量。
在網際網路 (Internet) 層，您也可以使用資源保留通訊協定 (Resource Reservation Protocol，RSVP)，這是 RFC 2205 中定義的訊號處理通訊協定。主機可以使用此通訊協定，嘗試保留網路至端點的頻寬。不過，網路上並未普遍部署 RSVP，而且 Windows XP、Windows Server® 2003、Windows Vista™ 或下一版 Windows Server 代碼為 "Longhorn" (目前測試中) 目前都不支援 RSVP。
若要傳送標記為優先傳遞的封包，應用程式或作業系統元件必須能夠指定 802.1p 優先順序的值或 DSCP 值的值。下列區段會說明 Windows 元件或 Windows 架構的應用程式如何指定 TCP/IP 流量之 Ethernet 框架或 DSCP 值的 802.1p 優先順序。

Windows XP 與 Windows Server 2003 中的 QoS
Windows XP 和 Windows Server 2003 都有提供為流量指派 QoS 參數的 API。應用程式開發人員可以使用 Windows 通訊端 (Winsock) 和 Generic QoS (GQoS) API，在應用程式層級針對每個通訊端套用 QoS 參數。網路系統管理員可以使用為了呼叫流量控制 (Traffic Control，TC) API 所撰寫之流量管理工具，在主機層級套用 QoS 參數。
您可以使用 Winsock 和 IP_TOS 通訊端選項，設定通訊端之傳出封包的 DSCP 值。不過，TCP/IP 堆疊預設會忽略 IP_TOS 通訊端選項。若要使用 IP_TOS 通訊端選項，必須先在下列登錄機碼底下，建立及設定 DWORD 登錄值 DisableUserTOSSetting=0 (請參閱 [圖 1])：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
圖 1 設定 DisableUserTOSetting 的登錄值
圖 1 設定 DisableUserTOSetting 的登錄值
您必須重新開機，這個登錄設定才會生效。
若要指定流量的 DSCP 值，但是不使用 IP_TOS 通訊端選項，則可以使用 GQoS API。GQoS 是 Windows Sockets 2.0 (Winsock2) 的一部分。大多數具備 QoS 能力的應用程式都會使用 GQoS API 在 Windows 中叫用 QoS 功能。Windows XP Service Pack 2 (SP2) 中的 GQoS 允許應用程式設定 DSCP 值，以及調節其輸出流量。若要在執行 Windows XP SP2 的電腦上設定 802.1p 優先順序，您必須使用 TC API。
TC API 提供流量控制機制的存取，這些機制可管理本機主機上的網路流量。它允許直接控制 DSCP 值、802.1p 標記和節流閥速率。網路系統管理員可以使用流量管理程式，代替不具備 QoS 功能的應用程式直接叫用 TC API。由於 TC API 的層級比 GQoS API 更低，因此需要系統管理員層級的權限。
不同於 GQoS API，TC API 允許來自同一傳送主機的多個應用程式流量，聚集到單一 QoS 流程中。在此聚集過程中，可以藉由流量之來源與目的地 IP 位址、來源與目的地連接埠，以及通訊協定 (TCP 或 UDP) 的組合，來識別流量。例如，不論由主機上的哪一個應用程式傳送，凡是到特定目的地 IP 位址的所有流量，都可以包含在任何來源連接埠與目的地連接埠的單一 QoS 流程中。而 GQoS API 則允許應用程式自己定義透過通訊端傳送之資料的 QoS 處理方式。
若要支援 QoS 功能，Windows XP 和 Windows Server 2003 架構的電腦必須安裝 QoS 封包排程器元件，並從 [網路連線] 資料夾的網路連線屬性中啟用 (請參閱 [圖 2])。執行 Windows XP 的電腦上，預設會安裝及啟用 QoS 封包排程器元件 (Psched.sys)。封包排程器元件可以安裝在 Windows Server 2003 上。
圖 2 設定 QoS 封包排程器
圖 2 設定 QoS 封包排程器

Windows Vista 和 Windows Server "Longhorn" 中的 QoS
Windows Vista 和 Windows Server "Longhorn" 中的 QoS 支援已經加強及簡化。IT 人員現在可以使用原則式的 QoS 來設定 DSCP 值，以及控制應用程式傳送速率，不必再使用 API 或修改現有的應用程式。而針對開發人員，則支援 GQoS 和 TC API，雖然未來的 Windows 版本並不打算支援這些 API。此外，也移除了 IP_TOS Winsock 選項。為了在升級或未來的應用程式中取代 GQoS 和 TC API，並且簡化 QoS 支援，Windows Vista 和 Windows Server "Longhorn" 都支援新的 QoS2 API，也稱為高品質 Windows 音訊/視訊體驗 (Quality Windows Audio-Video Experience，qWAVE)。
Windows Server "Longhorn" 和 Windows Vista 中的原則式 QoS 可以讓您提供更佳的一般使用者體驗、控制頻寬成本，或與頻寬提供者或商務部門協商更細微的服務層級。無論應用程式為何，您都可以跨整個 Active Directory® 基礎結構，來集中管理執行 Windows Vista 或 Windows Server "Longhorn" 的電腦網路頻寬。因為流量管理是發生在應用程式層級之下，所以管理原則式 QoS 流量並不需要修改現有的應用程式。
Windows Server "Longhorn" 和 Windows Vista 中的原則式 QoS 設定，可以讓您根據下列情況來設定連出流量的優先順序或管理其傳送速率：
  • 傳送應用程式 (可執行檔路徑與名稱)
  • 來源或目的地 IPv4 或 IPv6 位址或位址首碼
  • 通訊協定 (TCP、UDP 或兩者)
  • 來源或目的地連接埠或連接埠範圍 (TCP 或 UDP)
QoS 原則會套用到與 Active Directory 容器 (如網域、站台或組織單位 (OU)) 相連結之使用者登入工作階段或屬於群組原則物件 (GPO) 的電腦，或者可能套用至安全性群組。屬於群組原則的 QoS 原則，會建置在您現有的 Active Directory 管理基礎結構上。
原則式 QoS 可以讓您定義流量的優先順序。您可以設定 QoS 原則，將輸出 IPv4 或 IPv6 流量標上特定的 DSCP 值。您也可以管理輸出流量的頻寬使用情形。您可以設定具有輸出流量節流閥速率的 QoS 原則。有了節流閥，QoS 元件就可將合計的連出網路流量限制在指定的速率。針對電腦，您可以管理輸入流量的頻寬使用率，透過進階設定來指定 TCP 流量的輸入輸送量，方法是設定 TCP 接收視窗大小的最大值。
在 Windows Vista 和 Windows Server "Longhorn" 中，都預設安裝並啟用 QoS 封包排程器。Pacer.sys 元件是新的網路裝置介面規格 (Network Device Interface Specification，NDIS) 6.0 輕量型篩選器驅動程式，它可控制原則式 QoS 的封包排程以及具備 QoS 功能的應用程式流量。Pacer.sys 取代了 Windows XP 和 Windows Server 2003 中的 Psched.sys。
若要在您的內部網路部署原則式 QoS，請設定使用者或電腦式的 QoS 原則，並將這些原則套用至適當的 Active Directory 容器。Windows Vista 或 Windows Server "Longhorn" 架構的電腦會在更新使用者設定或電腦設定群組原則時，下載及套用其原則式 QoS 設定。
由於資料和音訊/視訊 (AV) 應用程式共用網路的情形越來越多，因此需要 QoS 方案，以便時效性較高的 AV 流量能優先於資料流量處理。此外，無線網路的應用也日漸普及，這也增加了對於等待時間和頻寬較為敏感之應用程式的執行難度。
Windows Vista 中的 qWAVE 功能提供 QoS 相關軟體模組的集合，這些模組可處理 AV 應用程式和無線網路帶來的網路難題。qWAVE 已與 QoS 子系統整合，並使用許多網際網路和網路介面層封包優先權技術。qWAVE 可同時支援多種 AV 串流 (需要 QoS 的即時資料流) 和資料流 (傳輸最佳化流程，例如電子郵件或檔案傳送)。
qWAVE 技術可以偵測及監視 LAN 頻寬、探索網路的 QoS 功能，以及提供分散式的許可控制，以便公平且一致地使用網路頻寬。這些技術能實現進階的 AV 串流技術，讓應用程式得以動態地適應變化的網路情況，且開發人員只能經由 QoS2 API 使用。
Windows Vista 和 Windows Server "Longhorn" 中的 QoS2 API 取代了 GQoS API 和 IP_TOS Winsock 選項，您應該會發現它比 GQoS API 更容易使用。

其他相關資訊
如需 QoS 的詳細資訊，TechNet 上有豐富的參考資料。建議您從 Microsoft Quality of Service 網站 (英文) 做為起點。另外也建議您查看 Windows Core Networking 部落格 (英文) 的 QoS 區段。

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


 Windows PowerShell: 一次編寫一行指令碼
Windows PowerShell
一次編寫一行指令碼
Don Jones

我在前面幾個專欄中一直強調 Windows PowerShell 是個殼層。它的使用是互動式的 – 這和您可能早已熟悉的 cmd.exe (或命令提示字元) 殼層差不多，但是 Windows PowerShell 還可以支援指令碼語言，這種語言比 cmd.exe 的批次語言還要強，而且
與 VBScript 等語言一樣強，或甚至更強。不過，Windows PowerShell™ 屬於互動式殼層的事實，使得指令碼非常容易學習。事實上，您可以在殼層中互動式地開發指令碼，因此能夠一次編寫一行指令碼，並立即看到創作的成果。
這種反覆式的指令碼編寫技巧也更容易偵錯。由於您馬上能看到指令碼的結果，因此如果出現非預期的結果，可以很快地修正。
我將在本專欄中逐步解說 Windows PowerShell 中之互動式指令碼的範例。我會建立一個從文字檔讀取服務名稱，並將每個服務的啟動模式設定為停用 (Disabled) 的指令碼。
我希望您能從逐步解說中得到的概念，就是一次只要建置一小段 Windows PowerShell 指令碼，不要想一次完成一大堆指令碼。您可以將任何需要完成的管理工作分成多個片段，然後思考如何讓每個片段能夠獨立完成作業即可。因為 Windows PowerShell 會提供將這些片段繫結在一起的極佳方式，您很快就會看到。而且您也會發現，一次處理一個小片段，會使整個指令碼的開發更容易。

從檔案讀取名稱
在 Windows PowerShell 中，要想出如何讀取文字檔會很令人沮喪。如果我執行 Help *file*，得到的只是 Out-File cmdlet 的說明，這會傳送文字至檔案，而非從檔案讀取文字。一點用處都沒有！不過，Windows PowerShell cmdlet 名稱確實遵循一定的邏輯，讓我可以有發揮的空間。Windows PowerShell 擷取資訊時，cmdlet 名稱通常會以 Get 開頭。因此我執行 Help Get* 以顯示這些 cmdlet，再捲動清單以找到 Get-Content。似乎有點希望了！於是我執行 Help Get-Content，以查看此功能的詳細資訊 (請參閱 [圖 1])，看起來似乎能夠滿足我的需求。
圖 1 執行 Help Get-Content 以取得詳細資訊
圖 1 執行 Help Get-Content 以取得詳細資訊
Windows PowerShell 幾乎將一切都當成物件處理，就連文字檔也不例外。文字檔在技術上是許多行的集合，檔案中的每一行都可算是獨立的物件。因此，如果我建立一個名為 C:\services.txt 的文字檔，並在檔案中填入服務名稱 (每個名稱都放在檔案中單獨的一行)，Windows PowerShell 就可以使用 Get-Content cmdlet 個別讀取這些名稱。由於此逐步解說的構想是要示範如何互動式地開發指令碼，因此讓我只先執行 Get-Content，然後提供我的文字檔名稱，看看會有什麼結果：
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
和預期的一樣，Windows PowerShell 會讀取檔案，並顯示名稱。當然，我要的並非只顯示名稱，不過我現在知道 Get-Content 的運作方式正是我要的。

變更服務
下一步就是要變更服務的啟動模式。我同樣先試著找出正確的 cmdlet。所以我執行 Help *Service*。結果傳回一份簡短的清單，而唯一能符合我需求的，似乎只有 Set-Service cmdlet。我想要測試這個 cmdlet，以確定將其加入到指令碼之前，我已了解其運作方式。執行 Help Set-Service 顯示 cmdlet 應有的運作方式，而我所執行的小測試隨之確認：
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

將各部分結合
現在我必須將可從檔案讀取服務名稱的能力和 Set-Service cmdlet 結合，這時就是 Windows PowerShell 強大的管線功能發揮作用的時候了。透過管線即可傳遞第一個 cmdlet 的輸出做為第二個 cmdlet 的輸入。管線會傳遞完整的物件。如果將多個物件的集合放入管線中，每個物件會透過管線個別傳遞。這表示 Get-Content 的輸出 (記住，這是多個物件的集合) 可以透過管線傳遞至 Set-Service。因為 Get-Content 傳遞的是集合，所以集合中每個物件 (或文字行) 會個別透過管線傳遞至 Set-Service。結果就是系統會針對我文字檔案中的每一行，執行一次 Set-Service。命令的內容如下：
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
以下是執行過程：
  1. Get-Content cmdlet 執行，讀取整個檔案。檔案中每一行都當成唯一的物件處理，全部一起構成物件集合。
  2. 物件集合透過管線傳遞至 Set-Service。
  3. 管線針對每個輸入物件，執行一次 Set-Service cmdlet。在每次執行時，輸入物件 (亦即服務名稱) 都會當成 cmdlet 的第一個參數傳遞至 Set-Service。
  4. Set-Service 會執行，使用輸入物件做為其第一個參數，以及其他任何指定的參數，在此例中是 -startuptype 參數。
有趣的是，我的工作至此實際上已經完成，但是我連指令碼都還沒編寫。要在 Cmd.exe 殼層中完成同樣的動作會很困難，而若是使用 VBScript，則要編寫幾十行的程式碼。但是 Windows PowerShell 在一行中就處理了一切動作。不過我還沒全部完成。您可以看到，我的命令並未提供許多狀態輸出或回應。雖然看得出來沒有發生什麼錯誤，卻也很難看到是否真的有執行任何作業。即然我已經掌握完成工作所需的功能，即可開始編寫指令碼，讓它好好發揮一下。
Windows PowerShell Prompt Here，作者 Michael Murgolo
最普及 (也是我最愛之一) 的 Microsoft® PowerToys for Windows® 之一，就是 [在此處開啟命令視窗 (Open Command Window Here)] 工具。[在此處開啟命令視窗] 包含在 Microsoft PowerToys for Windows XP 或 Windows Server® 2003 Resource Kit 工具中，可讓您在 Windows 檔案總管中的資料夾或磁碟機上按一下滑鼠右鍵，即開啟指向該資料夾的命令視窗。
我在學習 Windows PowerShell 時，發現自己希望它也有相同的功能。因此我從 Windows Server 2003 Resource Kit 工具中擷取了 [在此處開啟命令視窗] 的安裝 .inf 檔案 cmdhere.inf，並進行修改以建立 [在此處開啟 Windows PowerShell 提示 (Windows PowerShell Prompt Here)] 的內容功能表。這個 .inf 檔案包含在此資訊看板所在之原始部落格貼文中 (可從 leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx 存取)。若要安裝工具，只要在 .inf 檔案上按滑鼠右鍵，再選取 [安裝] 即可。
我在建立此工具的 Windows PowerShell 版本時，發現原始版有錯誤 -- 如果解除安裝 [在此處開啟命令視窗] 工具，會留下一個無作用的內容功能表項目。因此，我提供了更新版的 cmdhere.inf，也可從原始部落格貼文下載。
這兩種 PowerToy 都利用一個現象，那就是這些內容功能表項目都是在與 Directory 和 Drive 物件型別關聯的登錄機碼下設定。其方式和內容功能表與檔案類型關聯的方式一樣。例如，您若在 Windows 檔案總管中的 .txt 檔案上按滑鼠右鍵，清單上方提供您許多動作 (例如開啟、列印及編輯)。為了要了解如何設定這些項目，讓我們來看看 HKEY_CLASSES_ROOT 登錄區。
如果您開啟登錄編輯程式並展開 HKEY_CLASSES_ROOT 分支，會看到針對檔案類型命名的機碼，例如 .doc、.txt 等等。如果您按一下 .txt 機碼，會看到 (預設值) 是 txtfile (請參閱 [圖 A])。這是與 .txt 檔案關聯的物件型別。如果您捲動並展開 txtfile 機碼，再展開其下的 shell 機碼，會看到針對 .txt 檔案之內容功能表項目命名的機碼 (您不會看到全部的項目，因為還有其他方法可以建立內容功能表)。每個項目底下會有一個 command 機碼。command 機碼下的 (預設值) 就是您選取該內容功能表項目時，Windows 會執行的命令列。
cmd 提示和 Windows PowerShell 提示都使用此技巧來設定 [在此處開啟命令視窗] 和 [在此處開啟 Windows PowerShell 提示 (Windows PowerShell Prompt Here] 內容功能表項目。磁碟機和目錄沒有關聯的檔案類型，但是 HKEY_CLASSES_ROOT 底下有與這些物件關聯的 Drive 和 Directory 機碼。
圖 A 內容功能表項目是在登錄中設定
圖 A 內容功能表項目是在登錄中設定

Michael Murgolo 是 Microsoft Consulting Services 的資深基礎結構顧問。他專精的領域包括作業系統、部署、網路服務、Active Directory、系統管理、自動化及修補檔案管理。

互動式地編寫指令碼
我要做的一件事，是針對 C:\services.txt 中列出的每個服務，執行多次 cmdlet。這樣我就可以輸出服務名稱和我要的其他任何資訊，以便追蹤指令碼的進度。
我在前面使用管線從某個 cmdlet 傳遞物件到另一個 cmdlet。不過，這次我要使用更像指令碼的技巧，稱為 Foreach 建構 (我在上個月的專欄介紹過)。Foreach 建構可以接受物件集合，並且會針對集合中的每個物件執行多重 cmdlet。我指定一個變數，此變數在每次迴圈時代表目前的物件。例如，建構的開頭可能是這樣的：
foreach ($service in get-content c:\services.txt)
我還是執行相同的 Get-Content cmdlet 以擷取文字檔案的內容。但這次我要求 Foreach 建構針對 Get-Content 傳回的物件集合執行迴圈。於是建構針對每個物件執行一次迴圈，並將目前的物件放在變數 $service 中。現在我只需指定要在迴圈中執行的程式碼。我會先嘗試複製原先的單行命令 (這樣可減少複雜性，並保證不會漏掉任何功能)：
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
這段程式碼值得討論一下。請注意，我在 Foreach 建構第一行的結尾使用的是左大括弧 ({)。左大括弧和右大括弧之內的任何內容都視為在 Foreach 迴圈內，會針對輸入集合中的每個物件執行一次。請注意，我輸入 { 再按下 Enter 之後，Windows PowerShell 的提示字元即變成 >> (請參閱 [圖 2])。這表示它知道我已開始某種建構，而它正在等候我完成。接著我輸入我的 Set-Service cmdlet。這次我使用 $service 做為第一個參數，因為 $service 代表從我的文字檔案讀取的目前服務名稱。我在下一行使用右大括弧 (}) 結束建構。連按兩次 Enter 之後，Windows PowerShell 馬上執行我的程式碼。
圖 2 Windows Powershell 知道建構已開始
圖 2 Windows Powershell 知道建構已開始
沒錯，就是馬上。我輸入的內容很像指令碼，但是 Windows PowerShell 實際上是立即執行，並未儲存在任何文字檔案中。現在我要重新輸入全部內容，並新增一行程式碼以輸出目前的服務名稱：
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
請注意，我要求它顯示一些內容，並使用雙引號括住要顯示的內容。雙引號告訴 Windows PowerShell 這是字串或文字，而非其他命令。但是，當您使用雙引號 (相對於單引號) 時，Windows PowerShell 會掃描文字字串，判斷是否有任何變數。如果找到任何變數，會以變數的實際值取代變數名稱。因此，它在執行此程式碼時，您可以看到顯示的是目前的服務名稱。
不過這仍然不是指令碼！
我到目前為止都互動式地在使用 Windows PowerShell，這是立即看到我編寫內容結果的一個很好的方式。不過，每次需要重新輸入這些程式碼是很煩的。這就是 Windows PowerShell 也可以執行指令碼的原因。事實上，Windows PowerShell 指令碼的行為就是很單純地在「輸入」指令碼：Windows PowerShell 基本上只是讀取指令碼文字檔案，並「輸入」它找到的每一行，完全和您手動輸入各行一樣。這表示我到目前為止所做的一切都能貼入指令碼檔案中。因此，我要使用筆記本建立一個名為 disableservices.ps1 的檔案，並貼入下列內容：
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
我將此檔案放在名為 C:\test 的資料夾中。接下來我要試著從 Windows PowerShell 中執行此檔案：
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
噢喔。哪裡出問題了？Windows PowerShell 搜尋 C:\test 資料夾，但是找不到我的指令檔。原因何在？由於安全性的限制，Windows PowerShell 的設計是不會從目前資料夾執行任何指令碼，藉此防止任何指令碼劫持作業系統命令。例如，我不能建立名為 dir.ps1 的指令碼，讓它覆寫正常的 dir 命令。如果我需要從目前資料夾執行指令碼，必須指定相對路徑：
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
接下來該怎麼辦？它還是不能正常動作。我的路徑正確，但是 Windows PowerShell 表示它無法執行指令碼。這是因為，Windows PowerShell 預設是無法執行指令碼的。這也是安全防護措施，它的設計是要防止我們在 VBScript 所遇到的問題。根據預設，惡意指令碼無法在 Windows PowerShell 中執行，因為依預設是無法執行任何指令碼的。若要執行我的指令碼，我必須明確變更執行原則：
PS C:\test> set-executionpolicy remotesigned
RemoteSigned 執行原則允許未經簽署的指令碼從本機電腦執行，下載的指令碼還是需要經過簽署才能執行。AllSigned 是一個更好的原則，它只會執行已經由受信任的發行者發行之憑證數位簽署過的指令碼。但是我手邊並沒有憑證，因此無法簽署我的指令碼，所以 RemoteSigned 是合理的選擇。接下來要再嘗試執行我的指令碼：
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
我要指出，我們所使用的 RemoteSigned 執行原則並不是最理想的選擇，只是合理的選擇而已。因為還有其他更好的解決方案。取得程式碼簽署憑證、使用 Windows PowerShell Set-AuthenticodeSignature cmdlet 簽署我的指令碼，以及將執行原則設定為更安全的 AllSigned 原則，才是比較安全的做法。
還有另一個原則 - Unrestricted，您一定要避免使用這個原則。此原則允許所有指令碼 (甚至來自遠端位置的惡意指令碼) 毫無限制地在您的電腦上執行，可能讓您冒著極大的風險。因此，不論是任何原因，建議您都不要使用 Unrestricted 原則。

立即結果
Windows PowerShell 中的互動式指令碼處理功能可讓您很快地建立指令碼原型，甚至只是指令碼的一小段。您可以立即得到結果，因此能夠很容易修改指令碼，得到您真正想要的結果。當您完成後，可以將程式碼移到 .ps1 檔案中使其成為永久可用的指令碼，以便在未來隨時存取。另外請記住：最理想的是，您應該數位簽署這些 .ps1 檔案，以保持 Windows PowerShell 的 AllSigned 執行原則設定，這是允許指令碼執行的最安全原則。

Don Jones 是 SAPIEN Technologies 的指令碼語言大師，也是 Windows PowerShell:TFM 的共同執筆者 (請參閱 www.SAPIENPress.com (英文))。Don 的連絡方式為：don@sapien.com。


 嗨，Scripting Guy！: 對於追車... 還有 XML 的迷戀
嗨，Scripting Guy！
對於追車... 還有 XML 的迷戀
Microsoft Scripting Guys
下載本文程式碼: HeyScriptingGuy2007_02.exe (150KB)

「我也不知道 為什麼我的狗一直要追車子」，相信大家都知道這個老掉牙的笑話。「因為，萬一牠真的逮到一部車子之後又能怎樣呢？」
問的好，但這是 Scripting Guys 無法回答的問題。除非逮到車的，剛好是住在我們巷口的 Lucy。我們都知道「牠」一定會趁機駕車去搶劫便利商店，並開車逃離現場。而且，根據家門前車道上的狀況，我們深信她這一路上必定是一路逃亡，不曾下車方便 (如果您聽懂我們話中含意的話)。
如果我們要將這老掉牙的笑話套用在現今的高科技時代，就可以說：「我也不知道為什麼我們的系統管理員一直要學 XML。因為，萬一她真的學會之後又能怎樣呢？」
注意囉，我們只有說我們要嘗試將老掉牙的笑話套用在當下的事件上，並沒有說會很好笑呀。
老實說，XML 技術可能真的被吹捧得太過頭了，至少在系統管理方面的確有不足之處。事實上，許多系統管理員這麼久以來也都過得好好的，完全不需要撰寫指令碼與 XML 檔案互動，而且近期內也不會有太大的變化。
話雖如此，但確實是有越來越多應用程式開始採用 XML 做為儲存資料的標準架構。原因很簡單。XML 資料檔案只是盛裝打扮過的文字檔，所以不但易於建立、可跨平台、而且不需要使用複雜 (更別提昂貴) 的資料庫程式。您有作業系統以及文字編輯器嗎？有的話就可以建立 XML 資料庫囉。
這也代表系統管理員至少可以在此方面運用 XML：撰寫指令碼來查詢 XML 檔案，把檔案當做全功能的資料庫使用。如此一來，Scripting Guys 便成為適合提供小秘訣的最佳人選了。
說得好。我們猜想，Lucy 一定正忙著在別人家的花園裡挖洞，才沒這閒工夫來寫 XML 的專欄。
讓我們先來看一個簡單的 XML 檔案 (請參閱 [圖 1])，其中的資料庫檔案包含四組指令碼，用於＜嗨，Scripting Guy！專欄＞。
Figure 1 嗨，Scripting Guy！以 XML 撰寫指令碼 (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
如您所見，這是一個蠻簡單的小檔案。每一組指令碼都置於個別的 <Script> 標記之下。從現在開始，讓我們將這些指令碼稱做記錄。您想的沒有錯 -- 真正的 XML 迷絕對不會將這些項目稱為記錄。但是沒關係啦；我們的目標只是要讓您了解如何將大家都熟悉的技巧 (資料庫的查詢)，套用到新的、不同的資料來源。我們是想說先專注於如何達成目標，以後有機會再回來討論這個主題，並介紹正確的術語。
好，讓我們回到所謂的記錄。每一筆記錄都包含下列欄位：<Category>、<Subcategory>、<Keyword>、<Title> 及 <URL>。
看來您並不覺得這有什麼了不起。或許我們應該讓您看看另一個指令碼，其中可以開啟這個 XML 檔案並以 Echo 傳回下列內容：
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
請注意：這些標記名稱有區分大小寫。它必須是「/Repository/Script」，而不是「/repository/script」或「/REPOSITORY/SCRIPT」。
雖然這也沒什麼了不起的。但這就是重點啊：其實這並沒有您想像的那麼難。
如您在程式碼中所見，我們一開始會建立 Microsoft.XMLDOM 物件的執行個體，亦即用來處理 XML 檔案的 COM 物件。然後我們將 Async 屬性設定為 False；這可以確保整個檔案會先讀取到記憶體中，才將控制權交回給指令碼。接著我們使用 Load 方法來讀取 C:\Scripts\Scripts.xml 檔案：
xmlDoc.Load("C:\Scripts\Scripts.xml")
一旦檔案載入記憶體之後，我們就可以使用 selectNodes 方法來選取資料庫中的特定記錄：
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
請仔細看一下傳遞給 selectNodes 的參數。其實這代表 XML 檔案中的路徑。我們的 XML 檔案具有下列結構：
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
您是否想問：我需要知道這些嗎？簡單來說，有需要！使用 XML 檔案時，結構很重要。例如，我們要如何存取記錄的個別屬性？其實很簡單：我們只要存取 <Repository> 標記，然後存取 <Script> 標記，再存取個別的屬性標記即可。您猜發生了什麼事？這個路徑和我們為 selectNodes 指定的參數是一樣的。我們只要在路徑後面加上 /*，這代表「選取這些記錄的所有屬性」。換句話說，傳回的集合將包含資料庫中所有記錄的所有屬性 -- 這和 Windows® Management Instrumentation (WMI) 中的 "Select * From" 查詢有異曲同工之妙。
請注意，先試用範例指令碼，您就會知道我們的意思了。
指令碼的其餘部分很簡單；我們只設定了一個 For Each 迴圈來瀏覽整個集合，然後再以 Echo 傳回每個項目和每個屬性的 Text 屬性：
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
這比追車子更容易吧。
不過您想的沒錯：如果我們只是要以 Echo 傳回整個檔案的內容，根本就不需要用到 XML，僅需要使用 FileSystemObject 即可 (雖然這會稍微複雜一點，但只有一點點喔)。我們的用意是要讓您驚訝一下，讓您同意「哇，原來 XML 真的還蠻好用的」，但顯然我們未能到達那個階段。
讓咱們來想個辦法。在第一個指令碼中，我們傳回了所有記錄的所有屬性值。這沒問題，但是如果我們只想傳回指令碼的標題呢？這辦得到嗎？讓我問一下，請稍候片刻...
好，根據 Lucy 的說法，我們只需要修改 selectNodes 命令，將想要的屬性加到路徑的後面即可。也就是：
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
原來我們之前會傳回所有屬性，是因為我們使用了 * 萬用字元，而現在這樣就只會傳回 Title 屬性。原因何在？因為這是我們唯一要求傳回的屬性值。
請注意，最棒的是：XML 可以根據您的詳細要求提供回應。這下要請 Lucy 別傷心，因為我們已經開始認為 XML 才是人類最忠實的夥伴。
而且您當然可以傳回一個以上的屬性。舉例而言，下列修改過的命令就會同時傳回 Title 和 URL 屬性：
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
我承認，雖然語法看起來有些怪異，但是習慣之後就沒什麼了。首先，我們指定路徑的父項部分，跟之前一樣：
    /Repository/Script/
然後我們再新增一組括號，並在其中指定要傳回的屬性 (請注意，我們使用縱線字元 (|) 來分隔個別的屬性)。也就是：
    (Title | URL)
我們說過，雖然看起來有些怪異，但的確有效。
而且您可以傳回的屬性並不侷限於兩個而已。只要您願意一直加入縱線分隔字元，就可以隨心所欲傳回想要的屬性。舉例而言，要傳回三組屬性的命令 (Title、URL 及 Keyword) 如下：
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
很酷吧？
至少我們認為很酷。您還真難說服。但再一次的，您說的沒錯：我們目前只有在資料庫中擷取所有記錄的資訊而已。然而，這樣就已經不錯了。因為有時候，這就可以滿足您要完成的作業。另一方面，我們有時候 (其實是經常) 只想擷取記錄其中一個子集的資訊。舉例而言，我們可能只想要得到等於 databases 的 Keyword 之指令碼相關資訊。方法是使用如下的查詢：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
我知道，語法看起來有點怪。往好的方面想，語法其實很簡單明瞭。指定父項路徑之後，我們只要將 "Where" 子句 (例如：其中 x 等於 y) 放在方括內即可，如下所示：
/Repository/Script [Keyword = ‘databases’]
您可能已經看出來，我們的 Where 子句同等語法會告訴指令碼「只傳回 Keyword 屬性等於 databases 的項目」。請注意，databases 必須包含在單引號之間。這不但是好的習慣，更是必要的格式。如果篩選條件的關鍵字包含在雙引號之間，嘗試執行指令碼時就會發生語法錯誤。
請注意，為什麼不能這麼做？因為整個查詢字串—"/Repository/Script [Keyword = ‘databases’]"—已經包含在雙引號之間 (您應該記得吧)。
當然，您在篩選資料時，不僅可以使用等號 (=)，還可以使用大於 (>) 或小於 (<) 符號，以及大家最愛的小於或等於 (<=) 和大於或等於 (>=) 符號。您也可以在符號前面加上驚嘆號，即可變成否定篩選條件。舉例而言，下列命令就會傳回所有 Keyword 不等於 databases 的指令碼 (請注意 != 的使用)：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
等一下：誰膽敢說「可以設定篩選條件就了不起喔？我看一定沒辦法既設定篩選條件又指定要傳回的屬性吧」？當然沒問題：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
如果一切正常，此命令應該會傳回所有指令碼有 Keyword 是 databases 的 Title 屬性。讓我們看看是否真的可行：
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
結束前，讓我們再探索一個命令吧。雖然我們已經有相當程度的進展，可是系統可能還是會傳回過多的記錄。因為上述的命令其實會同時傳回 Microsoft® Access® 指令碼以及 Microsoft SQL Server™ 指令碼 (原因何在？因為這些指令碼都有 Keyword 是 databases)。如果我們想要把傳回的資料限制為 Keyword 有 databases 同時 Subcategory 是 Microsoft SQL Server 的指令碼，該怎麼做？可以使用多重準則進行篩選嗎？
這還用說：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
基本的語法都一樣，我們只是分別使用兩個準則 (亦即 Keyword = ‘databases’ 和 Subcategory = ‘Microsoft SQL Server’)，然後再以 AND 運算子將兩者連接。
請注意，您沒有錯，確實可以：透過這個小小的 XML 檔案，我們可以要求 Subcategory 等於 Microsoft SQL Server 的所有指令碼。但只有那樣不夠好玩，而且也沒有教育價值。
您也可以使用 OR 子句。舉例而言，如果我們有一堆 Microsoft Office 指令碼，其中包括 Subcategory 等於 Microsoft Excel®、Microsoft PowerPoint®、Microsoft Outlook®...等等。我們是否可以僅傳回 Subcategory 為 Microsoft Word 或 Microsoft Access 的資料？當然可以：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
這樣是不是像樣多了？或許我們這個專欄無法立即改變您的一生；但還是有機會讓您在未來發揮查詢 XML 檔案的技巧。學與不學當然需要由您自行選擇：您可以趁機學習一些基本的 XML 技巧，或是把時間用來追車。這之間的輕重由您自己決定 (萬一您選擇後者，而且剛好碰上住在巷口的狗狗 Lucy，麻煩轉告牠 Scripting Guys 跟牠問好，並請牠不要來我們的花園光顧！)。
嗨，Scripting Guy！- 天天樂翻天
您剛剛閱讀的是本月的＜嗨，Scripting Guy！專欄＞，相信您也會同意這是一篇偉大的技術文章。您甚至可能會說：這是至今最偉大的出版品。此外，您一定也是一直守在信箱旁邊，迫不及待想要收到下一期的 TechNet Magazine，才能夠閱讀更多類似這樣的文章，是吧。
那您在等什麼呢？想要進一步認識住在巷口的 Lucy 狗狗，或是閱讀 Scripting Son 最新的指令碼佳作嗎？您有聽說去年的 Turducken Bowl 結果嗎？只要您閱讀每天出刊的＜嗨，Scripting Guy！專欄＞(沒錯，是每天出刊喔)，就可以得知這些重要資訊。週一到週五 (當然要扣除國定假日和 Scripting Guy 度假期間)，您都可以閱讀到高中籃球賽事、大學美式足球賽事和籃球賽事，偶而還會來個當地氣象報告喔 (我必須承認，所謂的「當地」僅適用於 Redmond 的居民，但是話又說回來，Redmond 的居民們都不在乎氣象耶)。
不但如此，您每日還有可能會學習到指令碼的一些技巧。沒錯，在這多采多姿的內容中，的確還會有如何撰寫指令碼的資訊喔。在每一個專欄中，Scripting Guys 也會回答由 (應該是) 真人提出的問題。您可以閱讀每日專欄中的這些資訊，網址為 microsoft.com/technet/scriptcenter/resources/qanda。對了，由於他們已經回答過數以百計的問題，所以封存檔案中有大量的資料，而這也是絕佳的指令碼資訊來源 (請參閱 microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx (英文))。
您是否有問題想要問 Scripting Guys？只要將問題傳送到 scripter@microsoft.com，就有微乎其微的機率會收到答覆 (相對的，如果您沒有將問題傳送給他們，就絕對不會收到答覆，所以還是要把握機會。這和樂透不一樣，這不用錢，而且您接收到答覆的機率會比中頭獎還要高喔)。

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


 安全性監控: 部署 EFS：第一篇
安全性監控
部署 EFS：第一篇
John Morello

大家一定聽過因為筆記型電腦遭竊或弄丟而遺失私人或機密資料的報導。筆記型電腦遺失的情形屢見不鮮。隨著身分盜用情形猖獗和法規日趨嚴格，行動式運算系統的整體資料保護也愈來愈重要。
有一種辦法是利用 Windows® (自 Windows 2000 之後) 的加密檔案系統 (EFS)，此系統提供內建的、高效能的磁碟加密。EFS 與 Windows 檔案總管的密切整合，讓使用者幾乎感覺不到正在使用的檔案已經加密。此外，EFS 也同樣適用於原生的 Windows 驗證和存取控制技術，使用者不需為了存取資料而牢記個別密碼。最後，為了提防使用者無法取得他的加密金鑰 (例如使用者設定檔被刪除或損毀，或遺失智慧卡)，EFS 還可提供管理選項來回復資料。
EFS 會針對受保護的資料採用 Windows 內建的加密技術，來產生、儲存及部署增強式加密金鑰。在 Windows XP Service Pack 1 (SP1) 和較新的版本中，EFS 採用具 256 位元金鑰的「先進加密標準」(AES) 演算法來加密磁碟上的資料。這些對稱金鑰會再經過非對稱 (RSA) 金鑰組的保護。EFS 會以 AES 金鑰來加密每一個檔案，再以使用者的 RSA 金鑰來加密這個金鑰，最後將結果儲存在檔案中。如需 EFS 加密的詳細資訊，請參閱「EFS 資源」資訊看板。我暫且不將重點放在 EFS 的技術基本原理上，而是要討論如何將 EFS 部署和運用在您的環境中。因此，本文章假設您已有 EFS 加密的觀念。

淺談 EFS 安全性
有些應用程式宣稱有能力破解 EFS 加密。這些應用程式實際上都不是破解 AES (或資料加密標準 (DES) 或擴充型資料加密標準 (DESX)) 加密的密碼文字，只是以暴力法破解使用者的密碼來取得使用者的 EFS 私密金鑰。請注意，EFS 加密中用來產生和保護加密資料的私密金鑰，是採用「資料保護」API (DPAPI)。DPAPI 以使用者憑證的衍生物來保護資料，所以結論是唯有使用者的密碼夠強，以 EFS 來保護資料才有用。現在有了 Windows Vista™，您可以將 EFS 加密憑證儲存在智慧卡上，使情況為之改觀，大幅提升以 EFS 保護之資料的相對安全性。
密碼需要多長，才足以抵抗這些攻擊？以當今的硬體能力和現代的密碼攻擊演算法來說，最好使用 11 個字元以上的密碼 (更正確的說法是「複雜密碼」)。11 個字元以上的複雜密碼較能抵抗目前最先進的攻擊法，包括預先計算的雜湊攻擊 (例如 Rainbow Table；如需詳細資訊，請參閱「資源」資訊看板中列出的部落格文章：Why you shouldn't be using passwords of any kind on your Windows networks (英文))。

究竟要不要使用 PKI？
大家都以為 EFS 一定要公開金鑰基礎結構 (PKI) 才行，這是最常見的誤解。只要組織裡有 PKI，EFS 就很容易整合和利用 PKI，但這絕非必要。也就是說，是否在 EFS 部署中使用 PKI，將影響未來許多的部署決策，所以事先要經過調查。
PKI 和 EFS 一起使用的主要好處，在於可以備份和復原金鑰。雖然 EFS 可獨自讓系統管理員執行資料復原，但只有配合 PKI 時才能自動復原金鑰，也只有以 Windows Server® 2003 Enterprise Edition 做為憑證授權單位 (CA) 時才有此能力。在資料復原過程中，無法取得加密金鑰的使用者可以將加密資料提供給一位指定的系統管理員，稱為「資料修復代理」(DRA)，此人可將資料解密，再傳回給使用者，或重新加密做為新的私密金鑰。DRA 就像使用者加密過程的追蹤者一樣，會將使用者以這個金鑰加密的所有資料也都會以一份 DRA 金鑰來加密。因此，當使用者遺失金鑰時，DRA 可以介入以取得密碼文字資料，並套用 DRA 金鑰來加密 (或重新加密)，然後將資料傳回給使用者。DRA 的方法很好，但如果使用者加密的資料量很大，或沒有本機 IT 人員可擔任 DRA，則可能不易管理。
另一方面，金鑰復原會要求 CA 在金鑰建立過程中必須備份使用者的加密金鑰，並將該金鑰複本安全地儲存在 CA 的資料庫中。此後，當使用者無法存取加密檔案時，CA 系統管理員只要進入這個資料庫，就可以取得使用者的金鑰。屆時，使用者馬上就能再次存取他的資料，不必再由 DRA 去復原資料。在這種做法下，金鑰復原速度更快、更有效率。不過，請注意，即使是使用金鑰復原，最好都能有 DRA 提供備援機制，以防金鑰遺失情形發生。這樣也方便大型組織建立分散式復原系統，本機 IT 系統管理員直接就能復原使用者的資料，不必再麻煩 PKI 系統管理員小組。
PKI 和 EFS 一起使用的另一項好處，是更容易共用加密檔案。回想一下，EFS 並不限於用在筆記型電腦系統上；在實體電腦的安全性無法保證的任何情況下，也同樣很有價值。在這些情況下，多位使用者可能同時需要存取相同的加密資料。雖然 Windows 對加密檔案的共用支援稍嫌不足，只能共用個別檔案，不能共用目錄，但還算是很實用的工具。為了提供共用 EFS 檔案的功能，共用檔案的使用者必須取得對方的公開金鑰 (如果這些使用者已將有效的 EFS 憑證發行到他們在 Active Directory® 中的帳戶，此時最容易取得)。雖然可以手動來執行這項發行動作，但使用以「企業 (Enterprise)」(Active Directory 整合) 模式安裝的 Windows CA 可讓整個過程完全自動化。

EFS 金鑰管理
如果您有 Windows Server 2003 的 PKI 可用，則使用者 EFS 憑證的產生就很簡單。Windows Server 2003 CA 提供一套預設的憑證範本，包括「基本 EFS」這個範本。但這只是第 1 版的範本，且尚未支援金鑰備份。因此，在您的 CA 上提供此範本之前，您可以複製範本來建立新的第 2 版範本 (例如，命名為「具金鑰備份的 EFS」，如 [圖 1] 所示)。在這個新的範本上，移至 [要求處理] 索引標籤，並選取選項來備份使用者的加密金鑰。請注意，在啟用這個選項之前，必須先在 CA 上適當地設定金鑰備份。在資源區段中，整個過程有很好的逐步解說。您也應該設定這個範本來取代「基本 EFS」範本，確保用戶端使用這個新版本 (請參閱 [圖 2])。
圖 1 具金鑰備份的 EFS
圖 1 具金鑰備份的 EFS
圖 2 取代基本 EFS 範本
圖 2 取代基本 EFS 範本
接下來，您必須在範本上設定適當的權限，只開放註冊權限給適當的使用者。第一次使用 EFS 時，因為 Windows 中的 EFS 元件會自動要求憑證，您通常不必讓使用者自動註冊 EFS 範本。實際上，除非您確定所有自動註冊的使用者都一定會使用 EFS，否則我建議不要啟用 EFS 憑證的自動註冊。[圖 3] 顯示 EFS 註冊設定。發行憑證給不可能使用 EFS 的使用者只會徒增 CA 資料庫的大小，有害無益。雖然 CA 資料庫本身沒有大小限制，但隨著您發行的憑證愈多，就會變得愈難以管理 (尤其是透過 Microsoft Management Console，MMC)。
圖 3 設定 EFS 使用者權限
圖 3 設定 EFS 使用者權限
最後，如果您需要支援加密檔案的共用，您可以讓 CA 自動將使用者的憑證發行至 Active Directory。
在 CA 上適當地設定範本之後，當使用者第一次以 EFS 來加密檔案時，他將從 CA 取得憑證，而 CA 也會自動備份這個私密金鑰。

DRA 金鑰管理
如果您已有 PKI，則接下來的問題是要決定是否使用 CA 產生的 DRA 憑證。為何不要使用 PKI 的 DRA 憑證？假設發行 CA 的憑證有效期限非常短 (兩年以內)。該 CA 將無法發行有效期超過本身期限的任何憑證，這表示您的 DRA 憑證最多只有兩年的使用期限。這樣會造成資料復原情形更為複雜。下列案例說明這個假設性範例。
  1. 有一位使用者在 2006 年 1 月時將一個檔案加密；經由「群組原則」推入至她機器上的 DRA 憑證會有兩年的使用期限 (2008 年 1 月到期)。
  2. 該使用者繼續使用 EFS 來加密新的檔案。
  3. 在 2008 年 1 月，DRA 憑證到期，系統管理員透過「群組原則」推入新的憑證。
  4. 此後，任何加密作業都採用新的 DRA 憑證 (包括她開啟的任何以舊 DRA 加密的檔案；儲存檔案時會採用新的 DRA)，但她後來未接觸過的任何檔案仍然只由舊的 DRA 來保護)。
  5. 有一天，使用者不小心毀損她的設定檔，需要復原資料。
  6. IT 系統管理員現在必須有兩組 DRA 憑證：新的一組是針對步驟 3 之後接觸過的任何檔案，舊的一組是針對那時之後就未接觸的任何檔案。
雖然 IT 系統管理員可以在步驟 3 之後執行指令碼，以新的 DRA 來更新所有檔案 (使用 cipher.exe /u)，但整個過程相當耗時。更明確地說，如果修復原則包含過期的 DRA 憑證，則 EFS 元件就不允許任何新的加密作業，但這不表示 DRA 金鑰組在超過到期日之後就毫無用處。以過期的 DRA 金鑰組來加密的舊檔案，當然還是可以用這些金鑰組來復原。因此，切勿捨棄有效存留期已過的 DRA 金鑰組；不是用不到，只是時候未到。
基於這些理由，對於 CA 憑證使用期限很短的環境，建議採用期限較長的自行簽名 DRA 憑證。cipher 公用程式有一個參數 (cipher.exe /r) 可自動建立存留期長達 100 年的 EFS 修復代理金鑰組 (請參閱 [圖 4])。這個金鑰組的憑證可以附加至群組原則物件 (GPO)，並做為整個組織的 DRA。因為 EFS 元件不會檢查 DRA 憑證的信任鏈結，就算不變更系統上的「受信任的根憑證授權單位」清單，這些自行簽名憑證也一樣沒有問題。姑且不論組織的 CA 使用期限有多長，我建議至少建立一個長期的 DRA 憑證並附加至網域 GPO。這是後援的資料復原選項，萬一其他所有選項都失敗，就可派上用場。如果您在沒有 CA 金鑰備份的情況下使用 CA 產生的 DRA 金鑰，這更是不可或缺。萬一洩露 DRA 憑證，您可以用新的憑證來更新 GPO，並使用剛才提到的 cipher.exe /u 來更新檔案。
圖 4 執行 Ciquer /R
EFS 資源
如需 EFS 特性和最佳做法的詳細資訊，請瀏覽下列網站。
  • Why you shouldn’t be using passwords of any kind on your Windows networks (英文)
  • Implementing Key Archival Walkthrough (英文)
  • Encrypting File System in Windows XP and Windows Server 2003 (英文)

KRA 和 DRA 的部署
金鑰備份可讓 CA 系統管理員代替使用者來復原委付的加密金鑰。顯然，這是一種非常敏感且強大的功能，因為在組織內的任何資料，只要用到 CA 所簽署的金鑰，就可以被 CA 系統管理員解密。因此，必須謹慎處理金鑰的備份和復原，只有極少數值得信賴的安全人員才應該獲得這種權限。基於金鑰復原的機密性質，如果您想以此做為重獲 EFS 加密資料的主要機制，則傳給 CA 管理小組的復原要求一定要明確定義授權程序。一定要仔細檢查要求之後，才能開始進行復原程序。實際復原金鑰之後，應該透過安全的方法來提供給使用者 (換言之，不要透過電子郵件)，因為復原的金鑰已有能力存取使用者所有以 EFS 保護的資料。
金鑰修復代理或 KRA 金鑰會由 CA 系統管理員來產生和保存，不會透過「群組原則」公告。實際上，EFS 本身並無法判斷所使用的金鑰是否已封存，只會一如往常地執行加密作業。此外，在 CA 上建立的 KRA 金鑰絕不可能只供 EFS 使用。使用金鑰備份的 CA 會在 CA 等級上附加 n 個 KRA 金鑰，用來保護 CA 備份的任何金鑰。這些金鑰可能用於 EFS、安全電子郵件，或其他需要加密的任何憑證用途。KRA 金鑰應該由各金鑰修復代理來妥善保存，且至少要有兩個 KRA，以防其中一個金鑰遺失。
當系統管理員在新建立的網域中第一次登入網域控制站時，將會使用 DC 上的系統管理員設定檔中儲存的自行簽名憑證和金鑰組，在網域等級上建立預設的修復原則。此 DRA 憑證的有效存留期為三年。建議移除這個預設的憑證，並取代為更長期的自行簽名憑證或 PKI 發行的憑證。如果不移除這個預設的自行簽名憑證，則自建立之日起的三年內，EFS 將不會加密整個網域中的新檔案。這是因為憑證已過期，當修復原則包含過期的 DRA 憑證時，EFS 將禁止加密任何後續的資料。雖然可以在沒有修復代理原則的情況下操作 Windows XP 及更新版的系統，但這樣極為不妥。如果這樣做，萬一使用者因故無法存取他的加密金鑰，也無法將金鑰復原，則會永遠失去他的所有資料，無法挽回。
我說過，DRA 金鑰可以是自行簽名或由 CA 發行。在大多數情況下，兩者兼用最佳，整個企業至少要有兩個長期的自行簽名 DRA 做為最終的修復代理。因為 DRA 憑證也是透過群組原則物件來部署，所以繼承能力和其他 GPO 一樣。換句話說，標準的本機、網站、網域、組織單位 (OU) GPO 累加和應用演算法 (控制其他 GPO 設定的運用) 也都適用於 DRA。因此，組織可以輕易地對 DRA 採取分層做法，亦即 IT 中心小組對整個企業擁有 DRA 存取權限，但本機 IT 小組也有各自的責任範圍。這在分散各處的大型組織中極具價值，因為不必再為了復原資料而透過 WAN 連結傳送大量的加密資料。[圖 5] 顯示常見的多層 DRA 部署。
圖 5 多層 DRA 部署
圖 5 多層 DRA 部署
在這個案例中，Baton Rouge OU 的使用者到最後每一個加密檔案都會有六個 DRA：其中兩個來自他的本機系統管理員、兩個來自 North America IT 小組、兩個來自網域等級。因此，萬一使用者無法存取他的加密資料，則可由位於 Baton Rouge 的本機 DRA 或 North America IT 小組的 DRA 來復原。在最遭的情況下，萬一這四個 DRA 都不在，還有網域等級 DRA 可接手來復原資料。不論由哪個 DRA 執行復原，整個過程在本質上都一樣。首先，使用者要提供資料給 DRA。DRA 必須採取必要的步驟，確認請求合法且來自真正的資料擁有者。確認之後，DRA 會載入 DRA 憑證、將資料解密 (通常建議重新加密)，然後再將資料傳回給使用者。有些組織也會選擇執行本機復原，由 DRA 實際拜訪有問題的使用者，將他的 DRA 金鑰組載入設定檔中，然後將資料解密並移除金鑰組。之後，使用者會取得純文字格式的資料，且可以用新的金鑰來重新加密。請注意，這種做法很不安全，因為 DRA 金鑰組會複製 (暫時) 到本機電腦上，但的確可以節省一些時間，尤其在必須復原大量資料時，這樣或許值得。
請注意，如果是透過金鑰備份和復原的方式來協助使用者復原，則復原要求的處理方式和這個過程截然不同。完全不用 DRA，使用者將向 CA 系統管理員提出金鑰復原要求，此人必須檢查要求，然後進入備份處來取得使用者的私密金鑰。接著要將這個私密金鑰安全地送到使用者手上，例如放在安全網站上供他下載 (如果使用者在 Windows Vista 中使用智慧卡來儲存 EFS 金鑰，則應該一併重新發行此金鑰)。當使用者將這個金鑰載入他的設定檔之後，立刻就能存取他的所有加密資料。
因為 DRA 和 KRA 金鑰組都可以將機密資料解密，所以一定要妥善保管。DRA 和 KRA 金鑰組不應該儲存在系統管理員的一般桌面設定檔中 (用來執行日常工作的設定檔)。這些金鑰組應該安全地儲存在離線磁片、光碟或快閃媒體上，然後存放在真正安全的位置。以後需要復原時，修復代理就可以將這個媒體中的金鑰組載入復原工作站內、執行復原作業，然後移除金鑰組。機密需求特別高的組織會指定專用的工作站來負責復原，以進一步提高這些金鑰組的安全性，但並非所有組織都有這種需求。

下期預告
我現在已討論過 EFS 計劃的金鑰管理、資料復原及 Active Directory 方面的問題，在下個一月，我將在本主題的第二篇中探討用戶端的部署問題。涵蓋的主題將包括透過「群組原則」來控制 EFS 使用方式、選擇要加密的對象、透過登入指令碼來自動加密，以及有哪些用戶端增強功能可讓 Windows 檔案總管更容易處理以 EFS 保護的資料。

John Morello 以最優異的成績畢業於 LSU，且已在 Microsoft 工作六年，擔任過各種角色。身為資深的顧問，他曾為美國財星前 100 大 (Fortune 100) 企業及民間和國防部門設計安全解決方案。他目前擔任 Windows Server 小組的專案經理，負責開發安全性和遠端存取技術。


 桌面檔案: 擴充 Windows PE
桌面檔案
擴充 Windows PE
Wes Miller

早在我們五年前發行 Windows PE 之前，迫不及待的客戶就已經要求我們提供更多的功能。可惜的是，Windows PE 的設計並不像 Windows XP Embedded 那樣，能夠加入更多的作業系統層，輕易地進行擴充。當然，Windows PE 必須要有基本的
Win32® 支援 (以便讓大部分的 Windows® 應用程式都能執行)，以及網路和大型存放裝置支援 (以便透過網路通訊，並且能夠安裝 Windows)。但是即使從一開始，我們就想要限制殼層；藉由使用 cmd.exe 代替傳統的 Windows 檔案總管殼層，我們限制了 Windows PE 環境能夠執行的作業，更重要的是，如此一來，預設的環境就能輕易使用指令碼編寫所有自動化的工作。
所以您還是可以擴充 Windows PE，但是必須記住它是有所限制的。如果您的應用程式需要 [圖 1] 所列的任一種技術 (此清單並不完整)，則可以預期應用程式將無法運作或不能正常運作。
Figure 1 缺少的 Windows API (Close Figure 1)

.NET Framework (任何版本)
Active Directory® Services Interfaces (ADSI)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (含 .NET 之前的版本)
需要 Windows 原始未安裝之架構的任何可執行檔類型。
Windows 檔案總管或 Internet Explorer
Windows Media® Player
SAPI、MAPI、TAPI (分別是 Windows Speech、Mail、Telephony API)
要是您不知道應用程式依存的技術，就必須查明。但是要如何知道呢？我們當初在發行之前，由於想要讓 ADO、HTML 應用程式 (HTA) 及 Windows Script Host (WSH) 元件都能在 Windows PE 下執行，所以也遇到相同的問題。不過請注意，本文雖然為您介紹追蹤這些依存性的方法，但是使用者授權合約 (EULA) 並不允許在 Windows PE 影像檔中加入 MKIMG 命令未包含的任何 Windows 二進位檔。您必須先向 Microsoft 取得授權增補合約，才能在您的環境中實作這一類變更。

認識依存性
如果您在記事本中打開某個應用程式的 .inf 檔案並仔細檢查，將可了解許多資訊。事實上，這往往是最容易理解應用程式及了解其依存性的方式。就 Windows PE 而言，重點是它極為簡化，因此您必須偵錯許多層的依存性，包括應用程式本身的直接依存性和可能產生的每一個依存性，才能讓應用程式穩定、可靠地執行。基本上，如果您不夠仔細，可能會產生一系列的依存性問題。只要無意間 (或特意) 加入幾個元件，您的影像大小和複雜性就可能大幅增加。
如果您有描述應用程式的 .inf 檔案，則可以尋找 .inf 加入您系統中的登錄機碼和檔案，得到依存性的線索。請尋找 CopyFiles 和 AddReg 區段。這些項目會指向應用程式、DLL 及您的應用程式依存的其他檔案。Windows PE 的三個增益集 (ADO、HTA 及 WSH) 當中，WSH 是最容易建立的。因為舊版的 Windows 仍然能夠使用可轉散發版本的 WSH，而且 Windows 中現在仍內建了執行 WSH 檔案關聯的 .inf (位於 %windir%\inf\wsh.inf)，因此將其安裝到 Windows PE 相對而言很容易。

Orca 和快照
如果討論的應用程式是以 Microsoft® Installer (MSI) 檔案的形式散發，您有兩種方法可以找出依存性。如果您很熟悉 MSI，可以使用 Orca (編輯 Windows Installer 檔案的工具，隨附在 Windows Server® 2003 R2 Platform SDK 中散發：go.microsoft.com/fwlink/?LinkId=77941) 來檢視。您也可以安裝想要使用之元件的 MSI，以執行檔案和登錄機碼的變更分析。您可以先傾印登錄、安裝應用程式、然後再次匯出登錄，接著針對登錄執行 WinDiff (請參閱「使用 WinDiff」資訊看板)。所得結果可做為必須對登錄進行變更的範本。問題在於變更的數量可能讓人傷透腦筋。不過，您手邊若沒有 .inf 可參考 (或應用程式的作者可詢問)，這可能是最佳的選項。
您可能已熟悉應用程式快照的流程。基本上，這和您要讓應用程式正常執行所進行的變更分析相同。Microsoft 以前有隨附 Windows 2000 散發執行此工作的工具，但是該工具不能在任何較新版的 Windows 中使用。許多商業應用程式 (安裝重新封裝器) 和一些免費的公用程式，都可以執行此工作。其中的一個方案會安裝包含 WinDiff 的 Platform SDK (請參閱上一段落中的連結)。請注意，若要執行 WinDiff 進行比較，最好是將應用程式安裝在 Windows Server 2003，Service Pack 1 (SP1) 上，因為這是您應該使用的 Windows PE 版本 -- 亦即根據 Standard Edition 或 Enterprise Edition (含 SP1) 建置的 Windows PE 1.6。在 Windows Server 2003 上執行此工作，其環境最接近 Windows PE 環境 (很顯然您不能在此處執行 MSI)。請遵循「使用 WinDiff」資訊看板中的步驟。
這將會告訴您許多已變更的資訊。可惜的是，沒有很容易的方法可以從登錄匯出變更的資訊，或透過擷取檔案的方式來建立參照資料，以安裝您的應用程式。您必須手動併入變更。第一版的 Windows PE 就是在這方面遇到一些最棘手的問題。要讓 HTA 元件正常工作很複雜，因為 Microsoft 中沒有這些元件的定義 (Internet Explorer® 之外)。藉由比對差異，我們才能夠加入足夠的 HTA 支援，使其能正常運作。雖然這些機碼可以手動加入 Windows PE 登錄中，但建議您在 Windows PE 啟動之後再加入機碼。您可以檢查 OC.bat 和 OC2.bat 檔案，它們是用來安裝 HTA、WSH 及 (或) ADO 支援到 Windows PE 中的檔案 (透過 Windows PE 建置工具所包含的 buildoptionalcomponents.vbs 指令碼)。

實用的工具
即使在釐清直接依存性之後，往往還是找不到您的應用程式所依存的所有二進位檔。例如，您無法知道它在執行某件工作時，是否需要另一個 DLL 或 OCX。那麼要怎樣才能知道呢？Sysinternals 著名的 Mark Russinovich (現在是 Microsoft 的技術研究員) 撰寫了一個名為 listdlls 的便利公用程式，專門執行此工作。Listdlls 可以從 microsoft.com/technet/sysinternals/utilities/ListDlls.mspx 下載。使用時請執行 listdlls.exe > dlls.txt 命令，然後檢查其輸出即可。[圖 2] 顯示 listdlls 針對自己執行的輸出。您可以將此清單和 Windows PE 所包含的 DLL 與 OCX 檔案做個比較，判斷是否有您所有應用程式的依存性 (就 listdlls 而言，已全部列出)。針對 Windows PE 中的 HTA 支援，listdlls 可以識別其他方式無法發現的依存性，這當初是一大關鍵。
圖 2 Lisdlls 針對自己執行的輸出
圖 2 Lisdlls 針對自己執行的輸出
但是有列出的 DLL，並不一定代表應用程式需要該 DLL 才能運作。例如，您若是載入記事本，將會看到它有載入 uxtheme.dll。Windows PE 當中並沒有此 DLL，事實上，由於沒有使用 Windows 佈景主題，因此永遠不會載入。困難的是如何判斷 listdlls 顯示的 DLL 中，哪些才是您真正需要的，哪些又是 Windows 需要時所載入的；這需要許多從錯誤中嘗試的重複過程，或是您必須非常熟悉 Windows 的低層級知識 (關於這方面的資訊，我推薦 Mark Russinovich 和 David Solomon 合著的 Microsoft Windows Internals，Fourth Edition (Microsoft Press®，2004) 一書。
事實上，Mark 在免費的 Process Explorer (用來取代 Windows 工作管理員) 當中，就包含了此功能。在我看來，差別在於 listdlls 所建立的輸出較容易用於編寫指令碼以及尋找和收集遺漏的依存性。
請注意，即使您已將 DLL 加入影像中，還是需要執行一些其他的工作。也就是說，DLL 類型有兩種：需要登錄和不需要登錄的。這兩者很難分辨，只能靠嘗試登錄來區分。若要登錄 DLL (或 OCX)，請執行 regsvr32 dllname.dll。如果 DLL 運作正常，就會顯示一個對話方塊，告訴您 DLL 已登錄。否則會顯示一個訊息或對話方塊，告訴您 DLL 登錄失敗，或者 DLL 無法登錄。我們在開發 Windows PE 的 HTA 和 ADO 的選擇性元件時，發現 DLL 在執行登錄時需要可寫入的儲存體，以便暫時寫入安裝用的 .inf 檔案，或記錄一些其他依存性 (例如，需要的特定目錄)。這在以前的 Windows PE 中通常會失敗。幸好這一類工作在 Windows PE 2.0 裡都能正常運作，因為預設提供了塗銷空間。
Mark 所建立並在最近發行的第三個工具名為 Process Monitor。Process Monitor 可以視為 Regmon 和 Filemon 的超集合，但提供比任一者還要多的詳細資訊，並加入了全新的處理程序通訊層。此一功能強大的工具可幫助您疑難排解 Windows 中的應用程式，並幫助您回答 DLL 真正的相互依存性問題。請按此處下載 (英文) Process Monitor。

移除 Windows PE 檔案
除了可在 Windows PE 加入新功能之外，另一個常見的要求是如何讓 Windows PE 更精簡的說明。您可以採取一些步驟，幫 Windows PE 瘦身。具有合法授權的 Windows PE 應包含建置工具的集合和一些文件。其中一份文件是名為 winpe.chm 的說明檔。如果開啟這個檔案，閱讀「Windows 預先安裝環境使用者手冊」區段，應該就可看到「縮減 Windows PE 的大小」這個主題。此區段會列出可以安全移除的一些檔案集合 (假設您不需要這些檔案)。關於可移除檔案的區段共有三個：
  • 字型檔案一律可以安全地移除。
  • 網路相關的 .inf 檔案和公用程式可以移除，但是唯有您完全不打算在網路上使用您的組建時才可這麼做。
  • 命令列公用程式不可移除。除非您明確知道檔案的功能和移除的後果，否則不建議您移除其中任何檔案。
您決定好哪些檔案可以安全地移除之後，只需編寫批次檔或其他指令檔，並在 mkimg.cmd 完成建置之後，從 Windows PE 組建移除這些檔案。

修改 Windows PE 的登錄
您可以看到我們刻意選擇在組建時不安裝選擇性的元件。雖然這代表在執行階段需要多一點的時間，但是我們就不必為如何將這些元件放回 Windows PE 來傷腦筋 -- 因為我們當時不會有時間做這些，所以很可能會造成這些元件完全被放棄。但是您若是要變更登錄 (例如當您的應用程式登錄有所變更而需要加入其中的差異)，或者想要編輯用來保持應用程式正常運作的機碼時，該怎麼辨？使用 [圖 3] 中所示的 regedit 即可輕易完成。請遵循下列步驟：
  1. 執行 regedit，然後選取 HKEY_LOCAL_MACHINE Hive。
  2. 選取 [檔案] | [載入 Hive 控制檔]，然後瀏覽至您的 Windows PE 組建位置。從 I386\System32\ (如果這是您放在硬碟上的影像，則是 MiniNT\System32) 底下選取 setupreg.hiv。
  3. 輸入 Hive 的暫存名稱，例如 WinPE，然後瀏覽至 HKLM 底下的該節點。
  4. 照著修改此機碼。有趣的是，請注意此節點實際上是和一般 Windows 安裝上的 HKLM\System 節點一樣。
  5. 修改完成之後，請選取在步驟 3 建立之 HKLM 底下的機碼 (這一步一定要做對，否則可能會損害您的系統)。
  6. 選取 [檔案] | [Hive 解除載入...]，並於 [是] | [否] 對話方塊確認，每次都要確定您解下登錄，因為鎖定登錄會造成 Windows PE 無法建置成功。
圖 3 開啟 Windows PE 的登錄
圖 3 開啟 Windows PE 的登錄
遵循這些步驟，即可修改 HKLM\System。I386\System32 底下還有另外兩個機碼可讓您修改登錄的其他部分：DEFAULT 是使用者的預設 Hive (即使您在使用 Windows PE 時是使用 SYSTEM 執行也一樣)，而 SOFTWARE 則是和 HKLM\Software 相同。一如往常，修改登錄一定要小心，而且只在必要時才修改。
現在您已經有所了解，應可幫助您開始將自己喜愛的疑難排解或修復工具移到 Windows PE 上。下個月我將要討論 PSTools 套件，這也是 Mark Russinovich 所撰寫、一套非常實用的系統管理工具集合。
使用 WinDiff
WinDiff 可以幫助您找出應用程式的依存性。只要遵循下列步驟就能成功安裝及執行：
  1. 準備系統以供安裝，您應該要盡量縮短初始和最終快照之間的時間，並避免檔案或登錄的變更。
  2. 開啟命令提示字元視窗，然後執行 reg export HKLM C:\HKLM1.reg，即可完整匯出 HKEY_Local_Machine 登錄 Hive。
  3. 執行 dir C:\*.* /S > C:\C1.txt 以執行 C: 磁碟機 (假設 C: 是您的系統磁碟機) 上面所有檔案的完整傾印。
  4. 安裝您的應用程式，然後設定所有相關設定。
  5. 執行 reg export HKLM C:\HKLM2.reg。
  6. 執行 dir C:\*.* /S > C:\C2.txt。
  7. 開啟 WinDiff 並選取 [檔案 (File)] | [比較檔案... (Compare Files...)]，然後從第一個 [開啟檔案 (File Open)] 對話方塊中選取 HKLM1 .reg，再從第二個對話方塊中選取 HKLM2.reg。
  8. 您應該會看到一則紅色訊息，表示何者較新。這需要一些時間，因為 HKLM 的匯出檔案可能很大，所以請耐心等候。
  9. 按兩下紅色文字以展開差異。
  10. 您可以勾選 [選項 (Options)] | [只顯示右邊的行 (Show Right-Only Lines)]，設定要在比較中顯示的項目。這會讓第二個檔案中只顯示新增的行 (因此只會顯示新檔案和新登錄機碼)。
請注意，您可能需要使用 [搜尋 (Find)] 功能，才能找出與您的應用程式相關的機碼。在 [圖 A] 和 [圖 B] 中，您可以看到我所建立之虛構應用程式的檔案和登錄變更。幸好，WinDiff 提供複製和貼上的功能。若要使用這些功能，只要按一下 !> 行，再選取所要的行即可。
圖 A WinDiff 的項目
圖 A WinDiff 的項目
圖 B WinDiff 中的特定機碼
圖 B WinDiff 中的特定機碼

Wes Miller 任職於德州奧斯丁的 Pluck 公司 (www.pluck.com)，擔任開發經理。Wes 之前任職於同樣位在奧斯丁的 Winternals Software，以及在 Microsoft 擔任 Windows 的專案經理與產品經理。Wes 的連絡方式為：technet@getwired.com。


 現場筆記: 就是無法使用
現場筆記
就是無法使用
R'ykandar Korra'ti

「不知道耶， 就是會一直斷線。」
「有沒有固定的發生時間？發生時，您是否在進行特定的作業？或是用到某一部特定的電腦？」
「沒都有。我一下可以上線，一下又會斷線。隨時會發生，而且毫無預警！」
「這樣我根本毫無頭緒，您知道嗎？拜託！請想清楚一點，總會有些跡象嘛。」
「我已經告訴您我所知道的一切。我就是會不定時斷線呀。您能幫忙解決問題嗎？」
於是，我只能告訴她我會進一步調查。路由器記錄檔中也看不出跡象，但是偶而流量就會大減，證明確實有發生問題，但是每次都只是一、兩分鐘，之後就會恢復正常。沒有任何錯誤、沒有固定的模式，只是偶而流量會中斷。真是奇怪。還好，幸運的事情發生了：
鈴...鈴... 連接在 DSL 線上的電話機剛好響起。
嘰...嘟... 然後我們的 IP 連線就斷線了。
我心裡想：不可能吧。但是，事實上這就是造成問題的原因：只要有人撥打 DSL 的電話號碼 (應該沒有人會撥打這個號碼，而且不應該會有人知道我們網路線用的電話號碼)，我們的網路連線就會中斷。電信公司一向強調的優勢 - 亦即不用擔心網路會輕易中斷的問題 - 卻在剎那間毀滅。
而且我們離他們的機房才 900 英呎而已，不應該會發生這樣的情形。於是我檢查了所有的纜線、重設所有設備，甚至把所有的接頭都清理過 (以防萬一)。但是，仍舊發生一樣的問題。因此我打電話給電信公司。「您知道嗎？您們當初說網路連線絕對不會受到來電影響的保證，如今已經破滅了耶。我們的連線會輕易被電話行銷人員的來電阻撓耶。」
或許是線路的問題...
隔天來了一位技師，他的測試顯示我們的訊號強度有如遠離交換所機房 3,000 英呎般的微弱，也就是說，輕微的干擾就會中斷我們的連線。最後我們發現，當初為整個社區佈線的時候，所有的電話線都串連在一起，亦即每一個線路都串連到每一棟大樓，以便在安裝新的網路時不必重新拉線。這對於類比的語音線路沒有影響，但是就 DSL 的需求，結果卻會造成端點與機房的距離變成串連線路的總長度，導致訊號的強度大幅衰退。
幸好，此問題有個便捷的解決方法。我們線路的所有串連支線都被拆除，而且還在拆除點加上註釋標籤：「請勿連接。DSL 線路使用中。」好了！這下我們的網路訊號強度就真的只有 900 英呎的距離，馬上大幅提升了許多，而且更重要的是，完全不會因為來電而中斷。
這個故事的寓意：千萬不要假設網路連線的問題都是難以理解或一定是軟體造成的。有時候只是線路的問題。安裝之後，一定要請電信公司的人員來檢測 DSL 的實際訊號強度，即使他們告訴您一定沒問題；因為我們根本沒有辦法知道是否有其他線路架構上的問題在搗蛋。絕對要堅持，不要仰賴他們所說的什麼機房距離。您根本不清楚線路的佈局會不會有問題，而且連他們可能也不知道呢。最保險的做法就是確定一下。何況他們擁有所需的工具和技術 - 讓他們好好發揮用處。這樣才能讓自己安心。以防萬一您的 DSL 電話號碼被電話行銷組織給盯上。

R'ykandar Korra'ti 是一個小型合作式網際網路服務提供者 (ISP) 的郵件管理員，她和夥伴 Anna 住在美國的西雅圖附近。她之前在 Microsoft 擔任產品郵寄工作，但目前正在考慮是否要念研究所，她希望能夠研究一個前無古人、後無來者 (因此研究所課程尚未命名) 的難以理解領域。認同她這種想法的教授們若要與她連絡，請將郵件寄至 darako@murkworks.net。


 Windows 機密文件: 幾家歡樂幾家愁
Windows 機密文件
幾家歡樂幾家愁
Raymond Chen

當您插入 CD 或 DVD 光碟片時 ，殼層 (Shell) 就會「嗅出」光碟片上包含哪一種內容類型。這項判斷會提供相關的指引資訊給殼層，以決定應執行的自動播放動作。至於系統「嗅出」內容的具體流程，尚未記載於任何說明文件中，因為這屬於啟發式的技術，未來如果找出更優異的演算法就會予以變更。
如果將演算法記載到說明文件中，就會產生契約效應，如此一來，演算法就無法在後續的版本中進行調整。因此，官方的說法是演算法的規格尚未指定。
如果您有撰寫過 SDK 的說明文件，就知道所謂的說明文件等於一份合約。因為一旦您記載某項產品的行為，就無法進行變更。否則仰賴該產品行為的使用者就會說：「嘿，當初說明文件中不是這樣寫的，您這等於是在遊戲開始之後才在更改遊戲規則耶。」
法律責任撇清了之後，讓我們以極度簡化的方式，了解一下 Windows® XP Service Pack 2 (SP2) 如何針對沒有 autorun.inf 檔案的資料 CD 和資料 DVD 進行分類 (未來的 Service Pack 以及未來的 Windows 版本可能會採取不同的行為)。我之所以用「極度簡化」，是因為實際的演算法是以 61 個步驟的決策表所組成，其中會考慮更多、更細膩的資訊，例如前景應用程式是否有回應 [查詢是否取消自動播放功能] 的通知、是否正在執行全螢幕的程式，甚至於這是否為剛剛裝上擴充槽或剛剛從擴充槽卸除的筆記型電腦。而我則只要探討內容分類步驟。
首先，殼層會檢查使用者是否已針對所有內容類型指定 [不要有任何動作]。如果是，就沒有必要再進行判斷。於是不會有任何動作。
否則，殼層就需要採取行動。它會檢查光碟上深達四層目錄的每個檔案，並根據察覺的類型將檔案歸類成下列類別之一：影像、音樂、影片。
無法歸類到上述類別的檔案，都會被忽略。如果所有檢查過的檔案都屬於同一個類別 (舉例而言，如果光碟上的所有檔案都是音樂檔)，這就會建立光碟的類型。如果找到一個以上的類別，則會將光碟定義為有混合的內容。
這代表只要您的音樂光碟有專輯圖片，即使整張 CD 都是音樂檔案，Windows XP SP2 也會將它視為有混合的內容。這就是為什麼演算法未來可能需要進行調整。假設未來有更改演算法，亦即我們決定有很多 MP3 和少數幾張圖片的光碟，不應該被判斷為有混合的內容。然後某家公司的 CD 可能會有很多音效檔案及少數圖片，這家公司當然希望 CD 可以偵測為有混合的內容。但是由於演算法的改變，CD 會錯誤地分類成音樂。如此一來，這家公司就會不滿。但到底誰應該為此問題負責？這家公司是否不應該過度依賴此演算法？還是應該要怪 Windows，因為其中的演算法有所變更？
您瞧，Windows Vista™ 中的演算法就變了 - 雖然只是很小的改變。Windows Vista 中會先執行數個檢查，看看是否有特定的光碟內容配置。舉例而言，如果光碟的根目錄有「DCIM」資料夾，就會假設其中都是數位相片。會不會有人注意到這一點，就讓我們拭目以待吧。

Raymond Chen 的網站 The Old New Thing (英文)，以及採用相同標題做為書名的書籍 (Addison-Wesley，2007)，都有關 Windows 的歷史和 Win32 程式設計。Raymond 對於太陽的長相很好奇。