 TechNet Magazine April 2007

TechNet Magazine April 2007

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

本期內容：將我們深入討論的 Windows Vista 核心新增功能做一個總結。在這最後一篇，我們討論的是與可靠性、修復性和安全性有關的變更和新功能。

Mark Russinovich Windows 系統管理: 嚴重損壞修復：Active Directory 使用者和群組

Active Directory 的資料修復可能非常複雜，但您一定要有修復計劃。我們將示範 Active Directory 如何儲存、刪除、還原及複寫物件，下次不小心刪除使用者或群組成員資格時，您就可以做好萬全準備。

Gil Kirkpatrick Windows 系統管理: 為何 Windows XP Embedded 對您很重要

您可能不知道，Windows XP Embedded 對組織的 IT 陣容有多大的補強作用。看看 Windows XP Embedded 如何減輕管理工作量、節省成本及提高安全性。

Don Jones 管理: 使用 System Center Capacity Planner 預先規劃

硬體不足會造成回應時間不佳，但是硬體太多卻又會浪費預算和管理資源。了解如何使用 System Center Capacity Planner (系統中心容量規劃程式) 模擬出網路的模型，並且準確地估計您的基礎結構需求。

John Savill 管理: 使用 SMS 進行進階用戶端清查

Microsoft Systems Management Server 2003 中原已收集了許多資訊，但是並未收集您所需的一切。了解如何有效組合指令碼、WMI 及 SMS 知識，來幫助您擴大 SMS 的清查，以收集及報告幾乎任何資訊片段。

Wes Dobry 管理: 使用 SMS 2003 R2 部署自訂軟體更新

Systems Management Server 2003 R2 可讓您透過受管理的更新功能，部署自訂更新。探索兩項新工具：Inventory Tool for Custom Updates (自訂更新清查工具) 和 Custom Updates Publishing Tool (自訂更新發佈工具)，看看他們如何幫助您部署個人的更新，以及協力廠商開發人員所提供的更新。

Steve Rachui 編輯的話: 我們可能需要更正…

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

Greg Steen SQL 問題與解答: 重建索引、磁碟佇列長度及其他

Edited by Nancy Michell 公用程式焦點: Autoruns

在系統啟動時自動執行的大量應用程式，可能是一連串麻煩的禍源。但是有了 Autorun，您就可以調查每個自動執行的應用程式，以便疑難排解衝突、追蹤惡意程式碼和釋放系統資源。

Lance Whitney The Cable Guy: Windows Vista 的無線群組原則設定

探索如何使用「群組原則」功能，集中設定並散佈無線網路設定到 Active Directory 網路中的所有電腦上。

Joseph Davies Windows PowerShell: 資料的篩選與格式化

Windows PowerShell 提供各種資料的方便存取。但是，這些未經處理的資料並無法供一般的商業用途使用。本文將讓您了解如何利用篩選、指定屬性及套用格式，以自訂您收集的資料。

Don Jones 嗨，Scripting Guy！: 輕鬆自在管理本機使用者和群組

每個人似乎都有相同的疑問。現在就由 Scripting Guy 告訴您如何使用指令碼來管理本機使用者和群組。

The Microsoft Scripting Guys 安全性監控: 資訊安全設定精靈

資訊安全設定精靈提供有效的方法，來保護數以千計分散在眾多不同地理位置之伺服器的安全性。本文提供您需要的詳盡資訊來強化您的伺服器，並根據伺服器所扮演的角色來降低被攻擊的風險。

John Morello 桌面檔案: x64 的面貌

讓我們看看 Windows XP 及 Windows Server 2003 在 x64 系統上的實作情況，了解可能遇到的部署優勢與障礙。熟悉 Windows Vista x64 支援、移轉和部署。

Wes Miller Inside Microsoft.com: 使用 Active Directory Federation Service

Microsoft 有位商務夥伴們提供一個外部網路，此外部網路需要每一位外部網路使用者都有唯一的網域帳戶。瞭解 Microsoft 計劃如何使用 Active Directory Federation Service，在簡化管理流程的同時，提昇使用者體驗。

Jim Guthrie 現場筆記: 學習之樂 (與苦)

當最早開始採用新技術的雀躍感逐漸褪去，別忘了，知識讓技術更容易使用和支援。身為 IT 專業人員，我們必須挺身試驗新產品。您可能會有出乎意料的收穫。

Mark D. Scott Windows 機密文件: 錯誤的威力

您為什麼會想要開啟錯誤 (Bug)？因為某些應用程式其實必須依賴作業系統上的錯誤才能執行。如果修正錯誤，應用程式反而無法運作。

Raymond Chen


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

深入探索 Windows Vista 核心：第三篇
摘要:
  • 可靠性
  • 修復性
  • 安全性

這一系列的文章到目前為止所涵蓋的 Windows Vista 核心增強功能，都與處理程序、I/O、記憶體管理、系統啟動、關機和電源管理有關。這是第三篇，也是最後一篇，
我將著重於可靠性、修復性和安全性等領域的功能和改進。
在這一系列的文章中，有一項功能我沒有談到，即使用者帳戶控制 (User Account Control，UAC)，它是由數種不同的技術所構成，包括舊版應用程式的檔案系統和登錄虛擬化、同意提高權限來存取管理權限，以及 Windows® Integrity Level 機制，該機制可隔離以管理權限執行的處理程序與使用相同帳戶執行的較低權限處理程序。我將在未來的 TechNet Magazine 中深入探討 UAC 內部資訊。
Windows Vista™ 改進了系統的可靠性，並透過一些新功能和增強功能來提升您診斷系統和應用程式問題的能力。例如，核心的 Windows 事件追蹤 (Event Tracing for Windows，ETW) 記錄程式會保持作用中狀態，並在循環緩衝區中產生檔案、登錄、中斷和其他活動類型的追蹤事件。發生問題時，新的 Windows 診斷基礎結構 (Windows Diagnostic Infrastructure，WDI) 可擷取緩衝區的快照，並在本機上分析它，或將它上載至 Microsoft 支援中心進行疑難排解。
新的 Windows 效能和可靠性監視器可協助使用者了解發生的錯誤 (例如毀損/當機和懸置) 與系統設定變更之間的關係。功能強大的系統修復工具 (System Repair Tool，SRT) 取代了修復主控台，以進行無法開機系統的離線修復。
有三個領域仰賴系統的核心層級變更，因此值得在本篇文章中仔細探索：核心交易管理員 (Kernel Transaction Manager，KTM)、改進的毀損/當機處理，以及舊版的系統。

核心交易管理員
在軟體開發領域中，比較瑣碎的一環是錯誤狀況的處理。尤其是在執行高階作業的過程中，如果應用程式已完成一項或多項子作業而導致檔案系統或登錄變更時，更是如此。例如，應用程式的軟體更新服務可能進行了數項登錄更新、取代了其中一個應用程式可執行檔，然後在嘗試更新第二個應用程式可執行檔時遭到拒絕。如果該服務不想使應用程式處於不一致的狀態，就必須追蹤所做的一切變更，並妥當地進行復原。錯誤修復碼的測試很困難，通常會省略，因此修復碼中的錯誤可能導致前功盡棄。
針對 Windows Vista 撰寫的應用程式，可以利用核心交易管理員結合 NTFS 的新交易支援功能及登錄資訊，輕鬆獲得自動錯誤修復能力。當應用程式想要做一些相關的變更時，可以建立分散式交易協調器 (Distributed Transaction Coordinator，DTC) 交易和 KTM 交易控制碼，或直接建立 KTM 控制碼，並使檔案和登錄機碼的修改與交易產生關聯。如果所有變更都成功完成，應用程式會認可該交易並套用變更，但在這之前，應用程式可隨時回復交易及捨棄變更。
另一項好處是，在交易認可之前，其他應用程式不會看到該交易所做的變更，而且在 Windows Vista 和即將推出的 Windows Server® (代號 "Longhorn") 中使用 DTC 的應用程式，可以與 SQL Server™、Microsoft® 訊息佇列伺服器 (Microsoft Message Queue Server，MSMQ) 及其他資料庫協調其交易。因此，使用 KTM 交易的應用程式更新服務，絕對不會讓應用程式處於不一致狀態。這就是 Windows Update 和系統還原兩項服務都使用交易的原因。
KTM 是交易支援的核心，可讓交易資源管理員 (例如 NTFS) 和系統登錄針對應用程式所做的特定變更進行更新協調。在 Windows Vista 中，NTFS 會使用一個稱為 TxF 的延伸模組來支援交易。系統登錄則使用類似的延伸模組，稱為 TxR。這些核心模式資源管理員會與 KTM 共同協調交易狀態，就像使用者模式資源管理員會使用 DTC 在多個使用者模式資源管理員之間協調交易狀態一樣。其他廠商也可以使用 KTM 來實作他們自己的資源管理員。
TxF 和 TxR 均定義一組新的檔案系統和登錄 API，它們與現有的類似，只不過它們還包括了交易參數。如果應用程式想要在交易中建立檔案，它會先使用 KTM 建立交易，然後將產生的交易控制碼傳遞至要建立新檔案的 API。
TxF 和 TxR 均仰賴一般記錄檔系統 (Common Log File System，CLFS) (%SystemRoot%\System32\Clfs.sys) 的高速檔案系統記錄功能，這是在 Windows Server 2003 R2 所引進的。TxR 和 TxF 在認可交易之前，會使用 CLFS 持續儲存交易狀態的變更。這可讓它們在即使發生電源中斷時，亦可提供交易修復和可靠性。除了 CLFS 記錄檔之外，TxR 還會在 %Systemroot%\System32\Config\Txr 中建立一組相關記錄檔，來追蹤系統登錄檔的交易變更 (如 [圖 1] 所示)，並對每一個使用者登錄 Hive 建立個別的記錄檔。TxF 會將每一個磁碟區的交易資料儲存在磁碟區的一個隱藏目錄中，稱為 \$Extend\$RmMetadata。
圖 1 系統登錄 Hive TxR 記錄檔
圖 1 系統登錄 Hive TxR 記錄檔

增強式毀損/當機支援
當 Windows 發生無法修復的核心模式錯誤時 -- 不論是由於不良的裝置驅動程式、硬體故障或作業系統所造成 -- 它都會在顯示著名的藍色螢幕之後嘗試中止系統，以防止磁碟資料毀損，並將部分或全部實體記憶體寫入毀損傾印檔 (如果已設定這麼做的話)。傾印檔很有幫助，因為您在毀損/當機後重新開機時，Microsoft Online Crash Analysis (OCA) 服務會提議分析該檔來尋找根本原因。您也可以使用 Microsoft Debugging Tools for Windows 自行分析。
不過在舊版的 Windows 中，要等到工作階段管理員 (%Systemroot%\System32\Smss.exe) 處理程序將分頁檔初始化之後，才能啟用毀損傾印檔的支援。這表示在那之前發生的任何重要錯誤只會導致藍色螢幕的出現，但不會有傾印檔。由於大部分裝置驅動程式的初始化都是發生在 Smss.exe 啟動之前，因此在開機初期毀損/當機時，會因為無法導致毀損傾印而使原因的診斷變得非常困難。
Windows Vista 會在所有開機啟動裝置驅動程式初始化之後但在載入系統啟動驅動程式之前，將傾印檔支援初始化，以縮減無法產生傾印檔的時間。此變更讓您萬一在開機程序初期發生毀損/當機，系統也可以記錄毀損傾印檔，讓 OCA 幫助您解決問題。不僅如此，Windows Vista 還會將資料儲存到以 64KB 區塊為單位的傾印檔，而舊版的 Windows 只會使用 4KB 區塊寫入。此變更提供了更大的傾印檔，且寫入速度快了 10 倍。
應用程式的毀損/當機處理在 Windows Vista 中也進一步獲得改善。在舊版的 Windows 中，當應用程式毀損/當機時，會執行一個無法處理的例外狀況處理常式。此處理常式會啟動 Microsoft 應用程式錯誤報告 (Application Error Reporting，AER) 處理程序 (%Systemroot%\System32\Dwwin.exe) 以顯示對話方塊，指出該程式已毀損/當機，並詢問您是否要將錯誤報告傳送至 Microsoft。不過，如果在毀損/當機期間，該處理程序的主執行緒堆疊受損，當無法處理的例外狀況處理常式執行時，會導致核心終止該處理程序、程式視窗會立刻消失，而且不會出現錯誤報告對話方塊。
Windows Vista 則是將錯誤處理從毀損/當機處理程序的內容中，轉移至 Windows 錯誤報告 (Windows Error Reporting，WER) 這項新服務。此服務是由服務主機 (Service Hosting) 處理程序內的 DLL (%Systemroot%\System32\Wersvc.dll) 實作。當應用程式毀損/當機時，它仍然會執行無法處理的例外狀況處理常式，但該處理常式會傳送訊息至 WER 服務，而此服務將啟動 WER 錯誤報告處理程序 (%Systemroot%\System32\Werfault.exe) 來顯示錯誤報告對話方塊。如果堆疊已受損且無法處理的例外狀況處理常式毀損/當機，則處理常式會再度執行，並再度毀損/當機，直到耗盡該執行緒的所有堆疊 (臨時記憶體區)，此時核心會介入並將毀損/當機通知訊息傳送至該服務。
您可以在 [圖 2] 和 [圖 3] 中看到這兩種方式的對照，這兩個圖顯示會造成毀損/當機的測試程式 Accvio.exe 在 Windows XP 和 Windows Vista 上的處理程序關係，並在其中用綠色反白的方式標示出錯誤報告的處理程序。新的 Windows Vista 錯誤處理架構表示程式不會在 Microsoft 未有機會取得錯誤報告以協助軟體開發人員改進其應用程式之前自動終止。
圖 2a Windows XP 中的應用程式錯誤處理
圖 2a Windows XP 中的應用程式錯誤處理
圖 2b
圖 3a Windows Vista 中的應用程式錯誤處理
圖 3a Windows Vista 中的應用程式錯誤處理
圖 3b

磁碟區陰影複製
Windows XP 引進一種技術，叫做磁碟區陰影複製，可產生磁碟區的時間點快照集。製作備份的應用程式可以使用這些快照集來產生一致的備份映像，但快照集通常會隱藏起來，而且只會在製作備份的期間保留。
快照集實際上並非磁碟區的完整備份，而是磁碟區較早的檢視，其中是由即時磁碟區資料加上上一次產生快照集之後所變更的磁碟區所組成。磁碟區快照集提供者驅動程式 (%Systemroot\%System32\Drivers\Volsnap.sys) 會監視以磁碟區為目標的作業，並在容許磁區變更之前建立磁區的備份，然後將原始資料儲存在該磁碟區的系統磁碟區資訊目錄內、與快照集相關聯的檔案中。
Windows Server 2003 藉由共用資料夾陰影複製功能，向伺服器的系統管理員以及用戶端系統的使用者公開了快照集的管理。此功能啟用了持續性快照集，讓使用者可透過檔案總管內容對話方塊上的 [舊版] 索引標籤，存取其位於伺服器檔案共用中的資料夾和檔案的快照集。
Windows Vista 的舊版功能對所有用戶端系統提供此支援，並且會自動建立磁碟區快照集 (通常一天一次)，您可以透過檔案總管內容對話方塊，使用共用資料夾之陰影複製所使用的相同介面來存取快照集。這可讓您檢視、還原或複製您可能不小心修改或刪除的舊版檔案和目錄。雖然在技術上不算是新技術，但磁碟區陰影複製的 Windows Vista 舊版功能實作，在用戶端桌面環境中最佳化 Windows Server 2003 當初的實作。
Windows Vista 也利用磁碟區快照集來統一使用者和系統資料保護機制，避免儲存冗餘的備份資料。當應用程式的安裝或設定變更造成不正確或非預期的行為時，您可以使用 Windows XP 的系統還原功能 (在 Windows NT® 系列作業系統中所引進)，將系統檔案和資料還原至建立還原點時的狀態。
在 Windows XP 中，系統還原會使用檔案系統篩選器驅動程式 (可在檔案層級查看變更的一種驅動程式)，在系統檔案變更時建立系統檔案的備份。在 Windows Vista 上，系統還原會使用磁碟區快照集。當您使用 Windows Vista 中的系統還原使用者介面回到還原點時，實際上您是在從與還原點相關聯的快照集，將修改過之系統檔案的舊版複製到即時磁碟區。

BitLocker
Windows Vista 是目前最安全的 Windows 版本。其中除了納入 Windows Defender 反間諜軟體引擎之外，Windows Vista 還引進了數種安全性和深度防禦功能，包括 BitLocker™ 完整磁碟區加密、核心模式程式碼的程式碼簽署機制、受保護的處理程序、位址空間隨機載入 (Address Space Load Randomization)，以及對 Windows 服務安全性和使用者帳戶控制的改進。
作業系統只能在作用中狀態下實施其安全性原則，因此，您必須採取其他防護措施，以避免系統的實體安全受到危害，以及避免他人可從作業系統以外的管道存取資料。像 BIOS 密碼和加密之類的硬體防護機制，是一般用來防止未經授權存取的兩種技術 (尤其是在最可能遺失或遭竊的筆記型電腦上)。
Windows 2000 引進了加密檔案系統 (EFS)，在 Windows Vista 的化身中，EFS 還包括許多對舊版實作的改進，其中包括效能的增強、對加密分頁檔的支援，以及將使用者 EFS 金鑰儲存在智慧卡上的功能。不過，您不能使用 EFS 金鑰來保護系統機密區域的存取，例如登錄 Hive 檔案。例如，如果群組原則容許您即使未連接到網域也可以登入筆記型電腦，表示您的網域憑證檢查器已快取在登錄中，所以攻擊者可利用工具取得您的網域帳戶密碼雜湊，並透過密碼破解程式來取得您的密碼。有了密碼便可以存取您的帳戶和 EFS 檔案 (假設您未將 EFS 金鑰儲存在智慧卡上)。
為了使整個開機磁碟區 (含有 Windows 目錄的磁碟區) 更容易加密，包括其所有系統檔案和資料，Windows Vista 引進一種完整磁碟區加密功能，稱為 Windows BitLocker 磁碟機加密 (Windows BitLocker Drive Encryption)。與 NTFS 檔案系統驅動程式實作並在檔案層級操作的 EFS 不同，BitLocker 是使用完整磁碟區加密 (FVE) 驅動程式在磁碟區層級進行加密 (%Systemroot%\System32\Drivers\Fvevol.sys)，如 [圖 4] 所示。
圖 4 BitLocker FVE 篩選器驅動程式
圖 4 BitLocker FVE 篩選器驅動程式
FVE 是一個篩選器驅動程式，因此，一旦開始啟用 BitLocker，它就會自動查看 NTFS 傳送至磁碟區的所有 I/O 要求，使用指派給該磁碟區的完整磁碟區加密金鑰 (FVEK) 將寫入的區塊加密，並將讀取的區塊解密。根據預設，磁碟區會使用 128 位元 AES 金鑰和 128 位元 Diffuser 金鑰進行加密。因為加密和解密是發生在 I/O 系統的 NTFS 之下，所以 NTFS 會以為磁碟區未加密，NTFS 甚至不需要知道已啟用 BitLocker。不過，如果您嘗試從 Windows 以外讀取磁碟區的資料，它看起來會像是隨機資料。
FVEK 會以磁碟區主要金鑰 (VMK) 加密並儲存在磁碟區的特殊中繼資料區域內。當您設定 BitLocker 時，視系統的硬體功能而定，有一些選項可供您選擇保護 VMK 的方式。如果系統含有符合 1.2 版 TPM 規格的可信賴平台模組 (TPM)，並且有相關聯的 BIOS 支援，您就可以使用 TPM 加密 VMK，讓系統使用儲存在 TPM 的金鑰和儲存在 USB Flash 裝置上的金鑰來加密 VMK，或者使用 TPM 儲存的金鑰和您在系統開機時輸入的 PIN 來加密此金鑰。對於沒有 TPM 的系統，BitLocker 可讓您使用儲存在外接式 USB Flash 裝置上的金鑰來加密 VMK。無論如何，您將需要未加密的 1.5GB NTFS 系統磁碟區，即儲存開機管理程式和開機設定資料庫 (BCD) 的磁碟區。
使用 TPM 的優點是，BitLocker 會使用 TPM 功能來確保它不會將 VMK 解密，如果 BIOS 或系統開機檔在啟用 BitLocker 之後有變更過，它會將開機磁碟區解除鎖定。第一次將系統磁碟區加密之後，每次執行上述任何元件的更新時，BitLocker 便會計算這些元件的 SHA-1 雜湊，並在 TPM 裝置驅動程式 (%Systemroot%\System32\Drivers\Tpm.sys) 的幫助之下，以 TPM 的不同平台設定暫存器 (PCR) 儲存每一個雜湊，稱為度量。然後，它會使用 TPM 密封 VMK，這是使用儲存在 TPM 中的私密金鑰為 VMK 加密的一項作業，而 BitLocker 會把儲存在 PCR 的值連同其他資料一起傳遞至 TPM。然後 BitLocker 會將密封的 VMK 和加密的 FVEK，都儲存在磁碟區的中繼資料區域中。
當系統開機時，它會測量自己的雜湊和 PCR 載入程式碼，並將雜湊寫入至 TPM 的第一個 PCR。然後，它會雜湊 BIOS 並將該度量儲存在適當的 PCR 中。接著會由 BIOS 雜湊開機程序的下一個元件，即開機磁碟區的主開機記錄 (MBR)，此處理程序將繼續進行，直到完成作業系統載入程式的測量為止。每一個後續執行的程式碼片段，各負責測量它載入的程式碼，並將測量結果儲存到 TPM 中的適當暫存器。最後，當使用者選取開機的作業系統時，開機管理程式 (Bootmgr) 會從磁碟區中讀取加密的 VMK，並要求 TPM 將它解除密封。唯有當所有測量結果都與密封的 VMK 一樣時 (包括選用的 PIN)，TPM 才能順利將 VMK 解密。
您可以將此配置想像成一個驗證鏈，即開機程序中的每一個元件都會向 TPM 描述下一個元件。唯有當所有描述都符合其原始描述時，TPM 才會洩露它的秘密。因此，即使磁碟被移到另一個系統中、使用不同的作業系統開機，或開機磁碟區上的未加密檔案可能洩漏時，BitLocker 也會保護加密的資料。

程式碼完整性驗證
以核心模式裝置驅動程式實作的惡意程式，包括 rootkits 在內，會在與核心相同的特殊權限層級上執行，因此最難以識別和移除。這種惡意程式會修改核心和其他驅動程式的行為，使自己幾乎成了隱形。Windows Vista 核心模式程式碼的程式碼完整性功能，亦稱為核心模式程式碼簽署 (KMCS) 功能，只允許下載由特定憑證授權單位 (CA) 驗證過其資格的開發者所發佈並具備數位簽章的裝置驅動程式。根據預設，在 Windows Vista 64 位元系統上會強制實施 KMCS。
因為憑證授權單位的服務需要收費，並且會執行基本背景檢查 (例如公司諮詢調查)，因此要產生在 64 位元 Windows Vista 上執行的匿名核心模式惡意軟體難上加難。此外，有更多機制可以在萬一惡意軟體瞞過驗證處理程序時留下線索，當受入侵的系統上發現到惡意軟體時，便可追蹤到惡意軟體的作者。KMCS 也有次要用途，例如當懷疑驅動程式可能有問題而導致客戶系統毀損時，它會提供 Windows Online Crash Analysis 小組聯絡資訊，還有它會解除鎖定高畫質多媒體內容，這點我將會在稍後說明。
KMCS 使用 Windows 已運用了十年以上的公開金鑰加密技術，並要求核心模式程式碼要包含由信任的憑證授權單位之一產生的數位簽章。如果發行者送出驅動程式給 Microsoft Windows Hardware Quality Laboratory (WHQL)，且該驅動程式通過可靠性測試，則 Microsoft 即成為簽署程式碼的憑證授權單位。大部分發行者會透過 WHQL 取得簽章，但是當驅動程式沒有 WHQL 測試程式、發行者不想將驅動程式送至 WHQL 測試，或該驅動程式是在系統啟動初期就載入的開機啟動驅動程式時，發行者就必須自行簽署程式碼。若要這麼做，發行者必須先從 Microsoft 認定為可信任的核心模式程式碼簽署授權單位，取得程式碼簽署憑證。然後作者需要以數位方式雜湊程式碼，並以私密金鑰將它加密後簽署雜湊，然後在程式碼中加入憑證和加密雜湊。
當驅動程式試圖載入時，Windows 會使用儲存在憑證中的公開金鑰，將程式碼包含的雜湊解密，然後驗證該雜湊是否符合程式碼包含的雜湊。憑證的真實性也是以相同方式檢查，但是會使用 Windows 包含的憑證授權單位公開金鑰。
Windows 也會檢查相關聯的憑證鏈，最高達到內嵌於 Windows 開機載入程式和作業系統核心的根憑證授權單位之一。請勿嘗試在實際執行的系統上載入未簽署的 64 位元驅動程式，因為 64 位元 Windows Vista 的作法與 Plug and Play Manager 不同，不會在載入的驅動程式沒有可確認它已通過 WQHL 測試的簽章時顯示警告對話方塊，而是每當它阻擋未簽署的驅動程式載入時，只會直接在幕後自動將事件寫入程式碼完整性應用程式事件記錄檔，如 [圖 5] 所顯示。32 位元 Windows Vista 也會檢查驅動程式簽章，但允許未簽署的驅動程式載入。這是因為阻擋這些驅動程式會造成 Windows XP 系統無法升級，這些系統需要當初已載入至 Windows XP 的驅動程式，而且也才能支援目前只有 Windows XP 驅動程式的硬體。不過，當 32 位元 Windows Vista 載入未簽署的驅動程式時，也會將事件寫入程式碼完整性事件記錄檔中。
圖 5 嘗試載入未簽署之驅動程式的事件
圖 5 嘗試載入未簽署之驅動程式的事件
由於程式碼的簽署一般是用來標示程式碼為已通過嚴格測試的正式版，所以發行者通常不會想要簽署測試程式碼。因此，Windows Vista 包含一種測試簽署模式，您可以利用 Bcdedit 工具 (描述於我在 2007 年 3 月發佈的 TechNet Magazine 文章) 來啟用及停用此模式，此工具會載入以內部憑證授權單位產生的測試憑證數位簽署過的核心模式驅動程式。此模式是給程式設計師在開發程式碼時使用的。當 Windows 處於此模式時，它會在桌面上顯示記號，如 [圖 6] 所示。
圖 6 Windows Vista 測試簽署模式
圖 6 Windows Vista 測試簽署模式

受保護的處理程序
新一代多媒體內容，如 HD-DVD、BluRay 和進階存取內容系統 (Advanced Access Content System，AACS) 授權的其他格式，在未來幾年會變得更為普遍。Windows Vista 包含一些統稱為受保護媒體路徑 (Protected Media Path，PMP) 的技術，AACS 標準需要這些技術才能播放此種內容。PMP 包括受保護使用者模式音訊 (Protected User-Mode Audio，PUMA) 和受保護視訊路徑 (Protected Video Path，PVP)，它們共同提供音訊和視訊驅動程式以及媒體播放應用程式的機制，以防止未授權軟體或硬體擷取高畫質內容。
PUMA 和 PVP 定義音訊和視訊播放程式、裝置驅動程式及硬體專用的介面和支援，但 PMP 也仰賴 Windows Vista 引進的一般核心機制，稱為受保護的處理程序。受保護的處理程序是以標準 Windows 處理程序建構為基礎，此建構會封裝執行中的可執行檔映像、它的 DLL、安全性內容 (用來執行此處理程序的帳戶和其安全性特殊權限) 及在處理程序內執行程式碼但會防止特定存取類型的執行緒。
標準處理程序會實作一個存取控制模型，以提供處理程序的擁有者和具有偵錯程式特殊權限的系統管理帳戶完整存取權。完整存取權可讓使用者檢視及修改處理程序的位址空間，包括對應至處理程序的程式碼和資料。使用者也可以將執行緒插入至處理程序。這些存取類型與 PMP 的需求並不一致，因為它們允許未授權的程式碼存取高畫質內容，以及儲存在播放此內容之處理程序中的數位版權管理 (Digital Rights Management，DRM) 金鑰。
受保護的處理程序會限制存取範圍，僅允許一組有限的資訊介面和處理程序管理介面，包括查詢處理程序的映像名稱及終止或暫停處理程序。但是核心使受保護的處理程序的診斷資訊可透過一般處理程序查詢功能取得，這些查詢功能會傳回關於系統上所有處理程序的資料，因此並不需要直接存取處理程序。只有其他受保護的處理程序才能夠存取媒體，以防媒體受到危害。
此外，為了防止造成內部危害，所有載入至受保護處理程序的可執行檔程式碼，包括可執行檔映像和 DLL 在內，都必須由具有受保護環境 (PE) 旗標的 Microsoft (WHQL) 簽章，如果是音訊轉碼器，則必須由具有來自 Microsoft 之 DRM 簽署憑證的開發人員簽章才行。由於核心模式程式碼可取得任何處理程序的完整存取權，包括受保護的處理程序在內，且 32 位元 Windows 允許未簽署之核心模式程式碼的載入，所以，核心會提供 API 給受保護的處理程序，以查詢核心模式環境的「潔淨度」，唯有未載入未簽署的程式碼時，它才會利用查詢結果將優質內容解除鎖定。
識別受保護的處理程序
目前沒有可以特別識別受保護處理程序的 API，但您可以根據可用的有限資訊以及即使從系統管理帳戶也無法對它們進行偵錯的方式，進行間接識別。Audio Device Graph Isolation 處理程序 (%Systemroot%\System32\Audiodg.exe) 是用來播放以 Content Scramble System (CSS) 編碼的 DVD，它在 [工作管理員] 窗格中可識別為受保護的處理程序，這是因為 [工作管理員] 無法取得它的命令行、虛擬化及資料執行防止狀態，即使是以系統管理權限執行也一樣。
在 [工作管理員] 中檢視 audiodg 受保護處理程序
在 [工作管理員] 中檢視 audiodg 受保護處理程序

位址空間隨機載入
儘管有資料執行防止和增強型編譯器錯誤檢查之類的功能，惡意軟體作者仍然繼續找到緩衝區溢位弱點，讓他們能夠感染各種網路處理程序，例如 Internet Explorer®、Windows 服務及協力廠商應用程式，而得以入侵系統。不過，一旦他們感染了處理程序之後，就必須使用 Windows API 完成其終極目標，亦即讀取使用者資料，或修改使用者或系統設定來建立永久身分。
連接應用程式與 DLL 匯出的 API 進入點，通常是由作業系統載入程式進行處理，但是此類型的惡意軟體病毒將無法利用載入程式的服務。舊版的 Windows 上並無法避免惡意軟體造成問題，因為不論是哪一版的 Windows，系統可執行檔映像和 DLL 一律載入至相同位置，因此惡意軟體可以輕鬆假設 API 是位於固定位址。
Windows Vista 位址空間隨機載入 (ASLR) 功能，會使惡意軟體無法得知 API 的位置，因為每次系統開機時，會將系統 DLL 和可執行檔載入至不同的位置。在開機程序初期，記憶體管理員會從使用者模式位址空間頂端的 16MB 區域中的 256 個 64KB 對齊位址之一的偏差，挑選隨機的 DLL 映像載入。隨著映像標頭具有新動態重新定位旗標的 DLL 載入到處理程序中，記憶體管理員會從映像載入偏差位址開始往下，將它們封裝到記憶體中。
已設定旗標的可執行檔也會採取類似的處理方式，在其映像標頭所儲存的基本載入位址的 16MB 內的一個隨機 64KB 對齊點載入。此外，如果給定的 DLL 或可執行檔被所有使用它的處理程序卸載之後又再度載入，記憶體管理員會重新選取一個隨機位置來載入。[圖 7] 顯示 32 位元 Windows Vista 系統的範例位址空間配置，其中包含會由 ASLR 挑選映像載入偏差和可執行檔載入位址的區域。
圖 7 ASLR 對可執行檔和 DLL 載入位址的影響
圖 7 ASLR 對可執行檔和 DLL 載入位址的影響
唯有具有動態重新定位旗標的映像，包括所有 Windows Vista DLL 和可執行檔在內，才會重新定位，因為如果移動舊版映像會導致內部錯誤，畢竟開發人員對於其映像載入位置當初有固定的假設。Visual Studio® 2005 SP1 新增了設定旗標的支援，使協力廠商開發人員也可以充分利用 ASLR。
將 DLL 載入位址隨機化為 256 個位置之一，雖然不能完全杜絕惡意軟體猜出 API 的正確位置，但是可以嚴重妨礙網路蠕蟲的傳播速度，並且可防止只會嘗試感染系統一次之惡意軟體的運作。此外，ASLR 的重新定位策略還有第二項優點，即位址空間比舊版的 Windows 更緊密壓縮，這不僅可為連續記憶體配置製造更大的可用記憶體區域，還可以減少記憶體管理員為追蹤位址空間配置而配置的分頁表數目，並且可使轉譯對應緩衝區 (Translation Lookaside Buffer，TLB) 的失誤減至最少。

服務安全性的改進
Windows 服務是惡意軟體的理想目標。因為許多服務都提供透過網路存取的功能，這可能使系統曝露在遠端存取的攻擊之下，而且大部分服務是以比標準使用者帳戶更高的特殊權限來執行，萬一它們受到惡意軟體入侵，將提供機會提高本機系統的特殊權限。因此，Windows 開始隨著 Windows XP SP2 所做的變更演進，將指派給服務的特殊權限及存取權減少為只限於其角色需要的那些權限。例如，Windows XP SP2 推出的本機服務和網路服務帳戶，如今只包括本機系統帳戶的部分特殊權限子集 (先前的服務一律以此帳戶的完整權限執行)。這可在萬一攻擊者破解服務時，將可運用的存取權減至最少。
見識 ASLR 的運作
您可以在兩個不同的開機工作階段中，使用像 Process Explorer from Sysinternals 之類的工具來比較處理程序的 DLL 載入位址，如此即可見識到 ASLR 的作用。這兩個擷取畫面是從兩個不同的工作階段產生的，第一個是 Ntdll.dll 載入至檔案總管的位址 0x77A30000，後來則載入至位址 0x77750000。
ntdll.dll 載入不同的基本位址
ntdll.dll 載入不同的基本位址

在前一篇文章中，我描述過服務如何與使用者帳戶分開，在自己的工作階段中執行，但 Windows Vista 更擴大使用其最低權限原則，進一步減少指派給大部分服務的檔案、登錄機碼和防火牆連接埠的特殊權限和存取權。Windows Vista 定義了一個新的群組帳戶，稱為服務安全性識別元 (SID)，每一項服務都會有唯一的 SID。服務可對其資源設定權限，以限定只有它的服務 SID 有存取權，如此一來，當服務被破解時，可防止以相同使用者帳戶執行的其他服務也具有存取權。使用 sc showsid 命令並在其後提供服務名稱，即可看到服務的 SID，如 [圖 8] 所示。
圖 8 檢視服務的 SID
圖 8 檢視服務的 SID
服務 SID 可保護對特定服務所擁有之資源的存取權，但根據預設，服務對於執行它們的使用者帳戶可存取的所有物件仍然具有存取權。例如，以本機服務帳戶執行的服務，可能無法存取在不同處理程序中，以本機服務執行的另一個服務所建立的資源，該服務已使用參照服務 ID 的權限保護其物件，不過，它仍然可以讀取及寫入本機服務 (以及本機服務所屬的任何群組，如服務群組) 具有權限的任何物件。
因此，Windows Vista 引進了一個新的限制服務類型，叫做寫入限制服務，它只允許服務對於可存取其服務 SID、Everyone 群組和已指派給登入工作階段之 SID 的物件具有寫入權。為了達成此目的，它使用限制的 SID，這是曾經在 Windows 2000 引進的 SID 類型。當開啟物件的處理程序屬於寫入限制的服務時，存取檢查演算法就會變更，因此無法使用尚未以限制和無限制形式指派給處理程序的 SID 來授與處理程序對物件的寫入權。您可以使用下列命令來了解服務是否受限制：
sc qsidtype [service]
此外還有另一項變更，可以使服務輕易防止以相同帳戶執行的其他服務，存取前者所建立的物件。在舊版的 Windows 中，物件的建立者也是物件的擁有者，擁有者有能力讀取及變更其物件的權限，讓他們對其擁有之物件具有完整存取權。Windows Vista 則引進了新的擁有者權限 SID，此 SID 若存在於物件的權限中，可限制擁有者對其擁有之物件的存取權，甚至移除設定及查詢權限的權利。
Windows Vista 中的服務安全性模式的另一項增強功能，可讓服務開發人員確實指定服務在系統上註冊時需要操作的安全性特殊權限。例如，如果服務需要產生稽核事件，它可以列出稽核特殊權限。
當服務控制管理員啟動一項處理程序來裝載一項或多項 Windows 服務時，會為處理程序建立只包含服務在處理程序中所需之特殊權限的安全性權杖 (列出處理程序使用者帳戶、群組成員資格和安全性特殊權限的核心物件)。如果服務指定的特殊權限無法供執行該服務的帳戶使用，則該服務將無法啟動。例如，在本機服務帳戶處理程序中執行的任何服務，如果都不需要偵錯程式特殊權限，服務控制管理員就會從處理程序的安全性權杖中移除該特殊權限。因此，如果服務處理程序受到破解，惡意程式碼將無法利用在處理程序中執行的服務未具備的特殊權限。sc qprivs 命令可報告服務所要求的特殊權限。

結論
以下是我對這三篇 Windows Vista 核心變更文章的總結。我必須先聲明，還有一些我並未討論到或提及的功能和改進項目，例如適用於應用程式開發人員的新工作者執行緒集區、新的同步處理機制 (例如共用讀取器/寫入器鎖定機制)、服務執行緒標記、對線上 NTFS 磁碟檢查和磁碟區調整大小功能的支援，以及一個叫做進階本機程序呼叫 (Advanced Local Procedure Call，ALPC) 的新核心 IPC 機制。如需這些功能和其他功能的詳細資訊，請參閱下一期的 Windows Internals (預定將在 2007 年年底之前發行)。
檢視寫入限制服務
Windows Vista 上只有一項服務裝載處理程序會裝載限制的服務，您可以使用像 Process Explorer 之類的處理程序檢視工具來識別它，其中會含有下列命令行：
svchost -k LocalServiceNoNetwork
設定為在此處理程序中執行的服務包括：基礎篩選引擎、診斷原則服務、Windows 防火牆、效能記錄及警示，以及 Windows Media® Center Service Starter。
此畫面顯示基礎篩選引擎服務 SID 的文字形式 (NT SERVICE\BFE)，第一次列出時含有限制旗標，再次列出時沒有限制旗標，因此，處理程序對該帳戶可存取的資源具有存取權。不過，對於本機服務帳戶一般可存取的其他物件，它不一定有存取權。例如，由於 NT AUTHORITY\SERVICE 帳戶沒有出現在具有限制旗標的處理程序權杖中，所以該處理程序將無法修改只授與寫入權給該帳戶，而不授與寫入權給權杖中含有限制旗標的其他帳戶的物件。
在此處理程序中執行的服務也有特殊權限的限制，因為列示在內容對話方塊底端的特殊權限，僅為本機服務帳戶可用之特殊權限的子集。
服務的 SID 旗標
服務的 SID 旗標

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


 Windows 系統管理: 嚴重損壞修復：Active Directory 使用者和群組
Windows 系統管理 Gil Kirkpatrick

嚴重損壞修復：Active Directory 使用者和群組
摘要:
  • 複寫和物件連結的運作
  • 使用 NTDSUTIL 進行備份及還原
  • 授權及未經授權的還原

Active Directory 是 Windows 網路中最重要的服務之一。為了避免停機及失去生產力，您一定要備妥有效的嚴重損壞修復計劃來解決與 Active Directory 相關的問題。這一點聽起來理所當然，但是，
有很多系統管理員對於其中一個最常見的 Active Directory® 失敗狀況卻缺乏因應計劃，真令人匪夷所思：意外刪除資料。
意外刪除物件是服務失敗最常見的其中一個根本原因。當我舉辦研討會和會議時，通常會問到誰曾經因為意外刪除資料而造成 Active Directory 失敗。而每一次幾乎每個人都舉手。
若要了解資料修復為何如此複雜，首先您需要對下列問題有所了解：Active Directory 如何儲存及複寫物件，它如何刪除物件，及授權和未經授權的還原如何運作。

儲存物件
Active Directory 是一個特殊物件資料庫，它實作 X.500/LDAP 資料模型。資料存放區 (稱為目錄資訊樹狀結構 (Directory Information Tree，DIT)) 是以可延伸儲存引擎 (Extensible Storage Engine，ESE) 為基礎，它是一個索引循序存取方法 (ISAM) 資料庫引擎。從概念來看，Active Directory 會將 DIT 儲存在兩個資料表中：資料表 (它包含實際的 Active Directory 物件和屬性) 和連結資料表 (它包含物件之間的關係)。
每一個 Active Directory 物件都是儲存在資料表的個別資料列中，且每一個屬性一個資料行。資料表包含儲存在網域控制站 (DC) 上之所有複本的所有項目。在一般 DC 上，資料表包含網域 NC (命名內容) 的項目、設定 NC 和架構 NC。在通用類別目錄上，資料表包含樹系中每一個物件的項目。
Active Directory 會使用分辨名稱標記 (DNT) -- 32 位元整數 -- 來唯一識別資料表中的每一個資料列。用來內部參照物件的 DNT 比其他識別碼小很多，如分辨名稱 (DN) 和 objectGUID (16 位元組二進位結構)。但是與 objectGUID 不同，DNT 是本機識別碼，每一個 DC 上的 DNT 都不一樣。

Active Directory 如何連結物件
Active Directory 管理 DIT 中各物件之間的兩種關係：父系-子系關係 (亦稱為容器關係) 和參照關係 (亦稱為連結關係)。為了實作父系-子系關係，Active Directory 會在資料表中儲存另一個資料行，叫做父系分辨名稱標記 (PDNT)。此資料行一律包含物件父系的 DNT。
Active Directory 中的每一個屬性都是由 Active Directory 架構容器中的 attributeSchema 物件所定義。Active Directory 中的某些屬性是定義為連結屬性，由 attributeSchema 物件之 linkID 屬性中的偶數、非零值決定。連結屬性會在目錄的物件之間建立關係，且可以是單一值或多重值。群組物件的成員屬性是多重值連結屬性的一個範例 -- 它會在群組物件及其成員物件之間建立連結。
雖然看起來，群組的成員屬性包含成員的 DN (例如，如同 [Active Directory 使用者及電腦] 嵌入式管理單元所顯示)，但這並不是 Active Directory 儲存它們的方式。當您將成員物件的 DN 新增至群組的成員屬性時，Active Directory 會儲存物件的 DNT，而不是它的 DN。由於 DNT 不變，即使物件重新命名，您也可以重新命名使用者物件，而且 Active Directory 不必將系統中的所有群組進行排序，也可以更新每一個成員屬性的 DN。這就是 Active Directory 在 DIT 內維護參照完整性的方式。[圖 1] 顯示資料表與連結資料表之間的關係 (簡化的表示)。這些資料表顯示三個使用者物件 (Molly Clark、Alexander Tumanov 和 Makoto Yamagishi) 全部都是資深工程師群組的成員。
Figure 1 資料表和連結資料表之間彼此如何關聯 (Close Figure 1)

資料表 |  |  |
DNT | PDNT | 物件類別 | Cn
14529 | 14401 | organizationalUnit | 工程師
14530 | 14529 | 群組 | 資深工程師
14531 | 14529 | 使用者 | Molly Clark
14532 | 14529 | 使用者 | Alexander Tumanov
14533 | 14529 | 使用者 | Makoto Yamagishi
連結資料表 |  |  |
屬性 | DNT | 前導連結 |
成員 | 14530 | 14531 |
成員 | 14530 | 14532 |
成員 | 14530 | 14533 |
這些連結稱為前導連結。同樣地，Active Directory 也提供後置連結屬性。這些提供從連結的目標物件參照回到參考它的物件，即含有前導連結的物件。使用者和群組的 memberOf 屬性就是後置連結屬性的範例。說明後置連結屬性的 attributeSchema 物件含有 linkID 值，此值會比相對應的前導連結屬性的偶數 linkID 值大 1。例如，Windows Server® 2003 R2 架構中的成員屬性含有 linkID 值 2；做為後置連結的 memberOf 屬性含有 linkID 值 3。如需詳細資訊，[圖 2] 提供了連結屬性的清單，根據預設，這些屬性會定義在 Windows Server 2003 R2 架構中。
Figure 2 Windows Server 2003 R2 架構中的連結屬性 (Close Figure 2)

前導連結屬性 | linkID | 後置連結屬性 | Linked
成員 | 2 | memberOf | 3
manager | 42 | directReports | 43
owner | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
後置連結屬性一律為多重值，而且由 Active Directory 自動維護。事實上，您不能直接修改後置連結屬性。雖然看起來，您可以透過 Active Directory 使用者及電腦 MMC 嵌入式管理單元修改使用者或群組的 memberOf 屬性，但此嵌入式管理單元實際上是修改相對應群組的成員屬性，而且由 Active Directory 在幕後更新 memberOf 屬性。因此，您不需要對使用者物件具有權限，也可以將使用者新增至群組；實際上您只是修改群組物件的成員屬性。因為每一個 DC 都是在本機管理其後置連結屬性，所以後置連結的變更絕對不會複寫。只會複寫前導連結屬性的變更，例如群組的成員屬性。
在一般 DC 上，資料表包含網域物件的項目，以及來自設定容器和架構容器的物件。但有些群組類型可以包含位於另一個網域中之物件的參照。Active Directory 如何儲存不在其資料表內之物件的 DNT？答案就在於基礎結構主機 FSMO (彈性單一主機操作) 角色擁有者及所謂的虛設物件。

虛設的物件
當您將成員從一個網域新增至另一個網域的群組時，Active Directory 會在資料表中自動建立一個特殊物件，稱為虛設的物件，它包含 objectGUI、objectSid 和新成員的 DN。這會提供一個可儲存在群組之成員屬性中的 DNT。如果網域控制站是通用類別目錄，則不需要建立虛設的物件，因為在它的資料表中，樹系中的每一個物件都已經各有一個項目。
保留基礎結構 FSMO 角色的 DC 會根據通用類別目錄，定期檢查其資料表中的項目，當它發現有物件被移動、重新命名或刪除時，就會更新資料表中的虛設物件，並將這些變更複寫到網域中的其他 DC。而且因為是參照計數，所以基礎結構主機也可以移除網域中任何前導連結屬性不再參照到的虛設物件。
虛設的物件可讓 DC 管理該樹系內其他網域中之物件的參照，但前導連結屬性還可以參照該樹系之外的物件 (例如，在受信任的網域中)。在此情況下，Active Directory 會在網域 NC 的 CN=ForeignSecurityPrincipals 容器中建立一個稱為外部安全性主體 (FSP) 的物件。FSP 包含外部物件的安全性識別元 (SID) 和可在外部網域中識別該物件的其他屬性，但沒有程序可確保 FSP 保持最新狀態。為了資料修復的目的，我們會將 FSP 視為其他 Active Directory 物件來處理。

刪除物件
此處，我的重點主要是在於還原使用者及其群組成員資格。不過，相同原則適用於修復其他連結屬性。
當 Active Directory 刪除物件時，它不會從 DIT 中實際刪除物件。相反地，它會將物件的 isDeleted 屬性設為 True，使物件標示為已刪除，如此會使一般目錄作業看不見該物件。Active Directory 會移除未指定要儲存的所有屬性，如架構所定義，並將物件的相對分辨名稱 (RDN) 變更為 <old RDN>\0aDEL:<objectGUID>。然後它會將該物件移到 NC 的 CN=Deleted Objects 容器中 (設定 NC 中有一些物件類別，Active Directory 並未將它們移到 Deleted Objects 容器中)。Active Directory 會移除已刪除物件所保留之其他物件的任何前導連結，這會減少它們在連結資料表中的參照計數。如果有其他物件包含目前已刪除之物件的前導連結，Active Directory 也會一併移除那些連結。
產生的物件稱為刪除標記。Active Directory 會將此刪除標記複寫到其他 DC，該處也做了相同變更。請注意，Active Directory 不會複寫參照已刪除物件的前導連結中的變更。每一個 DC 會在本機進行相同變更，因此不需要複寫它。這是修復群組成員資格的結果，我將在本文稍後討論。
Active Directory 會在 DIT 中維護有刪除標記的物件，正如 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 物件之 tombstoneLifetime 屬性所做的決定。每一個 DC 上的廢棄項目收集程序會移除比所設定的刪除標記存留時間更舊的刪除標記。根據預設，刪除標記存留時間在 Windows® 2000、Windows Server 2003 和 Windows Server 2003 R2 是 60 天。在 Windows Server 2003 SP1 是 180 天。
刪除標記存留時間與還原程序有很大的關係。您不能使用比刪除標記存留時間更舊的備份進行還原。因為已從網域中刪除並進行廢棄項目收集的物件不再具有刪除標記，所以刪除作業絕不會重新複寫至已還原的 DC。已刪除的物件將保留在還原的 DC 上做為延遲物件，已還原的 DC 將不會與網域中的其他 DC 正確交集。

複寫物件
每當網域控制站執行任何類型的更新作業時 (例如新增物件或修改屬性)，DC 會將唯一 64 位元的數字指派至更新作業，稱為更新序號 (USN)。Active Directory 會使用 USN 標記更新的物件和屬性，以協助判斷是否需要複寫它們。
Active Directory 是以一個屬性接著一個屬性的方式來複寫物件。亦即，如果您修改物件的屬性，Active Directory 則只會複寫該屬性，而非整個物件。為了達到此目的，Active Directory 會使用複寫中繼資料來追蹤它對每一個屬性所做的變更。屬性的複寫中繼資料包括：
  • 本機 USN，會識別本機 DC 上的變更作業。
  • 引發變更之 DC 的 invocationID (尤其是 DC 相對應之 nTDSSettings 物件的 invocationID 屬性)，會識別網域控制站上的特定 DIT。
  • 存在於引發的 DC 上之原始作業的 USN。
  • 包含關於引發的變更何時進行之 DC 系統時間的時間戳記。
  • 32 位元循序版本號碼，每次值變更時都會增加。
當目標 DC 從來源 DC 協力電腦要求變更時，它會傳送上次成功複寫之變更的 USN 給來源 DC，並附上最新的複寫資訊，其中包括目標 DC 所見過、有複寫 NC 複本的每一個 DC 中，最大的引發 USN。來源 DC 會利用此資訊，只傳送目標 DC 尚未見過的更新內容給目標 DC。
當目標 DC 處理連入屬性更新時，它會檢查每一個屬性的版本號碼。如果連入屬性的版本號碼大於 DC 已有的屬性版本，DC 就會儲存連入值。如果連入屬性的版本號碼等於 DC 已有的版本，則 DC 會比較時間戳記並使用含有最新時間戳記的屬性。如果時間戳記一樣，目標 DC 就會選擇含有最大 invocationID 的值。這樣可保證每一個 DC 最後會選定每一個複寫屬性的相同值。

連結值複寫
在 Windows 2000 中，Active Directory 複寫多重值屬性的方式與單一值屬性相同。這對大型、動態群組物件造成問題，因為其多重值成員屬性在不同 DC 上會經常變更。如果系統管理員將使用者新增至某個 DC 上的群組，而另一個系統管理員又在複寫延遲視窗內新增不同的使用者至另一個 DC 上的群組，則 Active Directory 會選擇後來的新增而完全失去稍早的新增。Microsoft 在 Windows Server 2003 中使用一個稱為連結值複寫 (LVR) 的程序來解決此問題。
在 Windows Server 2003 樹系功能層級或過渡樹系功能層級上，Active Directory 會分開複寫多重值前導連結屬性的個別值，每一個值有它自己的複寫中繼資料。這樣可有效解決在 Windows 2000 所發現的問題，亦即幾乎同時更新不同 DC 的群組成員資格會造成資料遺失。
不過，有一點要注意。提高樹系功能層級不會自動以新的複寫中繼資料來修正現有的多重值連結屬性。只有在提高樹系功能層級之後新增的值才會含有新的中繼資料。這對於修復群組成員資格有重大影響，稍後您就會看到。

備份
Windows 包括一個非常基本的 NTBACKUP 公用程式，這可用來執行 DC 的系統狀態備份。網域控制站的系統狀態包括其登錄、SYSVOL、Active Directory DIT 檔案和重要系統檔案。大部分協力廠商備份公用程式也都有備份及還原 DC 之系統狀態的能力。
若要執行系統狀態備份至磁碟檔案，請使用下列命令：
NTBACKUP backup systemstate /F “<filename>”
其中 <filename> 是要建立的備份檔案名稱，且應該使用 .bkf 副檔名。

執行未經授權的還原
從備份中還原已刪除的 Active Directory 物件是兩個步驟的程序。首先，您要使 DC 重新開機成目錄服務還原模式 (DSRM)，然後使用 Windows NTBACKUP 公用程式或同等的協力廠商產品，從系統狀態備份中還原整個 Active Directory DIT。此程序將覆寫整個 DIT。
將 DC 啟動為 DSRM 有兩種方式。如果您可以存取 DC 的系統主控台，請關閉後再重新啟動 DC，當出現提示時請按 F8，以顯示 Windows 開機功能表。從功能表中選取 [目錄服務還原]，並輸入 DSRM 密碼。
如果您是從遠端管理伺服器，則無法存取 Windows 開機功能表。不過，您可以從 [我的電腦] 中選取 [內容]，按一下 [進階] 索引標籤，並按位於 [啟動及修復] 下的 [設定] 按鈕，來變更系統開機選項。按 [系統啟動] 區段中的 [編輯] 按鈕來編輯 boot.ini 檔案，並將 /SAFEBOOT:DSREPAIR 參數新增至行尾，如 [圖 3] 所示 (如需有關 boot.ini 參數的詳細資訊，請參閱 microsoft.com/technet/ sysinternals/information/bootini.mspx)。
圖 3 設定 DSRM 的開機選項
圖 3 設定 DSRM 的開機選項
當您重新啟動伺服器時，它會進入 DSRM。記住，如果您要在正常模式下重新啟動 DC，您必須從 boot.ini 中移除 /SAFEBOOT 參數。
使用 DSRM 密碼登入之後，請再次使用 NTBACKUP 命令還原系統狀態備份，但是不要指定任何參數 (您不能在命令列使用 NTBACKUP 來執行還原)。當精靈出現時，請選取 [還原檔案及設定]，並按一下 [下一步]。然後選取備份檔案，並勾選 [系統狀態] 方塊，如 [圖 4] 所示。
圖 4 使用備份或還原精靈來還原系統狀態
圖 4 使用備份或還原精靈來還原系統狀態
如果此時您要將 DC 啟動回到正常模式，Active Directory 複寫程序會使已還原的網域控制站再度與網域中的其他 DC 同步處理，且所有已還原的資料會被目前的資料覆寫。很顯然，這並不是您的目標。您只是需要一種方式能夠強制要還原的物件複寫到網域中的其他網域控制站以外。

執行授權還原
NTDSUTIL 也會在備份日期和還原日期之間，每天將每一個屬性的版本號碼增加 100,000。除非有屬性在一天內更新超過 100,000 次 (不太可能發生的情況)，否則已還原屬性的版本號碼將遠大於其他 DC 所保留的版本號碼，而系統授權還原的物件將複寫到其他 DC。其他未經授權而從備份中還原的物件，最後將被其他網域控制站的現有資料覆寫。
在完成未經授權的還原之後，但在重新啟動為正常模式之前，您使用 NTDSUTIL 程式來執行要修復之物件的授權還原。話雖如此，但系統授權還原物件其實沒有「還原」它；它只是確保 Active Directory 會將該物件複寫到其他 DC。為了達到此目的，NTDSUTIL 會指派下一個可用的 USN 給物件屬性的本機 USN。這使得下次複寫協力電腦進行同步處理時，該物件會傳送到複寫協力電腦。若要還原單一物件，請確定 DC 在 DSRM 中啟動，並遵循下列步驟進行：
  1. 開啟命令視窗並輸入：
    ntdsutil
  2. 在 ntdsutil 提示字元中輸入：
    authoritative restore
  3. 在 authoritative restore 提示字元中輸入：
    restore object “<DN of object to be restored>”
    例如，如果您想要從 DRNET 網域的 Eng OU 中還原 Molly Clark 帳戶，請輸入：
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    如果您想要系統授權還原整個目錄的子樹狀目錄，例如 OU，則請輸入：
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    (NTDSUTIL 也提供還原資料庫命令，能夠以系統授權還原整個網域、設定及架構 NC。還原整個網域太危險，我不建議您使用該選項。如果您需要還原整個網域，應該還原一個網域控制站，然後重新升級網域中的其他 DC，如 "Planning for Active Directory Forest Recovery" 所述)。
  4. 當系統出現提示時，請確認授權還原應增加個別物件及其屬性的版本號碼。
  5. 結束 ntdsutil (您需要輸入 quit 兩次)。
  6. 將 DC 重新啟動為正常 Active Directory 模式。
下次 DC 使用其協力電腦複寫時，您還原的使用者物件將複寫出來。但是還原使用者物件只是問題的一半。當您引進像群組及其成員之間的那些物件連結時，情況更為複雜。您在還原前後可能要面對一些基本問題，我將在下面幾節加以說明。
首先，讓我們複習一下，在刪除含有後置連結的物件時會發生什麼情況。假設您刪除的使用者物件是一個或多個群組的成員。每一個含有此使用者物件複本的網域控制站會將它轉換成標記，並從連結資料表中移除所有參照，因此會從該使用者網域的所有群組成員資格中移除使用者物件。(請記住，從群組成員資格中移除使用者並非複寫變更，因為每一個 DC 都會在本機更新群組成員資格。群組之成員屬性的版本號碼和本機 USN 會保持不變)。不久之後，虛設的物件將從其他網域的連結資料表中移除，同樣地，也不會更新群組之成員屬性的複寫中繼資料。
當您未經授權還原該使用者網域中之網域控制站上的 DIT 時，您會修復使用者物件以及該網域內群組中的所有群組成員資格，因此還原的 DC 本身是一致的。在使用 NTDSUTIL 公用程式以系統授權還原使用者之後，該使用者物件會複寫到該網域中的所有其他 DC。
但是因為網域中目前群組的複寫中繼資料不變，所以還原的 DC 上之群組的成員屬性會與其他 DC 上的那些群組成員屬性不一致。而且無法使它們在一般狀態下產生交集。因此，使用者的成員資格將不會在網域的其他 DC 上還原。

問題：網域內的群組成員資格不還原
系統授權還原使用者物件未修復使用者的群組成員資格。為什麼？因為成員資格關係是使用群組物件的成員屬性 (前導連結)，而不是使用者的 memberOf 屬性 (後置連結) 來儲存及複寫。問題是如何找到使用者的舊群組成員資格，而找到它們之後，又該如何適當地修復它們。
Microsoft 對於修復使用者之群組成員資格的程序做了累加式改進，因此，您使用的技巧要視您所執行的 Active Directory 版本而定。下列區段主要適用於 Windows 2000 Active Directory。
判斷使用者的舊群組成員資格很簡單：只要檢查已還原 DC 上的後置連結屬性 -- 在此案例中，即使用者物件的 memberOf 屬性。memberOf 屬性將包含使用者之網域中的本機群組和通用群組的所有成員資格。您可以使用 Active Directory 使用者及電腦 MMC 嵌入式管理單元 (ADUC)，或使用 Windows Server 所附的 LDIFDE 公用程式，來列出已還原使用者的群組成員資格。
下列 LDIFDE 命令列將列出 DRNET 網域中 Molly Clark 所屬的群組，並將結果儲存在 output.ldf 檔案中：
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
請注意，您必須將 DC 啟動為正常模式才能使用 LDAP 工具，同樣地，您必須停用輸入複寫；否則您還原的資料會被覆寫。停用輸入複寫最簡單的方式是使用 REPADMIN 命令：
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
其中 <dcname> 是您要還原至的 DC 名稱。當您完成時，請不要忘記重新啟用複寫，請使用 –DISABLE_INBOUND_REPL。
如果您只要修復少數使用者，則只要使用 ADUC 手動地將使用者新增回到群組，這非常容易。如果您要修復很多使用者，有一些工具可讓您自動執行部分程序。Microsoft GROUPADD 公用程式 (可從 Microsoft 產品支援服務取得) 可以接受您建立的 LDIF 檔來列出使用者的舊群組成員資格，然後產生 LDIF 檔來重新建立那些成員資格。例如，您可以使用這個 GROUPADD 命令來處理我們在先前的 Molly Clark 範例中所建立的 LDIF 檔：
C:\> groupadd /after_restore output.ldf
這個命令將使用 groupadd_<domain>.ldf 這個名稱，為 Molly Clark 具有群組成員資格的每一個網域建立新的 LDIF 檔 (其中 <domain> 是即將更新群組之網域的完整網域名稱)。您可以使用下列命令匯入上面所建立的 LDIF 檔：
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
使用 Windows Server 2003，Microsoft 改進了 NTDSUTIL 以利用在成員屬性中出現的其他中繼資料來支援連結值複寫 (LVR)。如果還原的使用者物件已經是網域中任何群組的成員，且該使用者的群組成員資格已與 LVR 中繼資料一起儲存，則 NTDSUTIL 會增加該成員屬性之對應值的版本號碼，而造成還原的成員資格複寫出來。
Windows Server 2003 SP1 版本的 NTDSUTIL 納入 GROUPADD 功能，且當它執行使用者物件的授權還原時，會自動建立 LDIF 檔。[圖 5] 顯示 NTDSUTIL 的新版本，而 [圖 6] 顯示自動建立之 LDIF 檔的內容。
Figure 6 NTDSUTIL 建立之 LDIF 檔的內容 (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
圖 5 具有內建 GROUPADD 功能的新 NTDSUTIL
圖 5 具有內建 GROUPADD 功能的新 NTDSUTIL
如果您要還原包含許多使用者和群組的整個 OU，以手動方式將使用者新增回到其群組會是相當繁瑣的工作。修復已還原群組成員資格的另一種方式是由系統授權還原群組本身。
不過，使用系統授權還原群組有兩個問題。第一個問題很明顯：如果您還原群組，該群組內的成員資格將回復至當初備份時的狀態。這表示自從上次備份之後，您對該群組所做的任何變更都必須重新套用至該群組。第二個問題比較微妙一點，且與 Active Directory 複寫工作有關。在授權還原使用者和群組之後，其複寫出來的順序不定。如果群組物件複寫到 DC 時，是在已還原的使用者物件之前，則複寫的網域控制站將從群組中自動移除該使用者參照，因為使用者物件尚未存在於該 DC 上。當使用者物件稍後複寫進去時，將不會新增至該群組。
此問題最簡單的解決方案是再次執行群組的授權還原。在執行第一次授權還原之後，重新啟動為正常模式，並確定複寫正確執行。然後重新啟動回到 DSRM 並執行 NTDSUTIL，以執行使用者所屬之群組的授權還原。這樣可保證您啟動回到正常模式時，該使用者物件會在參照它的群組物件複寫之前先複寫出來。

問題：其他網域內的群組成員資格不還原
「這個使用者是哪些群組的成員？」，這個問題其實不像我所描述地那麼簡單。您要還原的使用者可能是網域本機群組及其他網域之萬用群組的成員，當您執行未經授權的還原時，不會還原那些群組成員資格。因此，您如何得知該使用者屬於其他網域中的哪些群組？答案就在通用類別目錄中。通用類別目錄中除了它自己的網域資料，還包含樹系中其他網域之資料的唯讀複本。
若要利用通用類別目錄的全樹系資料，您必須在通用類別目錄上執行未經授權的還原，這表示一開始您必須先備份通用類別目錄。現在，當您執行 LDIFDE 來識別該使用者的群組成員資格時，可以在其他網域中找到該使用者的萬用群組成員資格。
當您列出要修復之使用者的群組成員資格時，請連接到通用類別目錄埠 3268 而非預設的 389，並指定樹系的根網域做為搜尋的基礎。LDIFDE 將顯示已修復之使用者的群組成員資格，包括該樹系中所有網域之萬用群組中的成員資格。以下是做法：
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
如果您在通用類別目錄上執行 GROUPADD 或新的 NTDSUTIL，您會為使用者網域產生一個 LDIF 檔，並為已還原使用者所屬萬用群組成員的每一個網域產生一個 LDIF 檔。當您匯入這些 LDIF 檔時，會還原該使用者的所有群組成員資格。幾乎全部 -- 這會帶領我們進入下一個問題。

問題：修復其他網域中的網域本機群組成員資格
Windows Active Directory 環境中有三種群組。通用群組可以只包含相同網域的成員，但也可以做為其本身網域中的網域本機群組內及樹系中其他網域的成員。通用群組的成員屬性不會出現在通用類別目錄中，但這不會構成問題，因為通用群組只包含其本身網域的成員。萬用群組可以包含任何網域的成員，並且可以做為樹系中其他萬用群組及其本身網域中的網域本機群組和樹系中其他網域的成員。萬用群組的成員屬性會複寫到通用類別目錄中。網域本機群組可以包含樹系中任何網域的成員，但不可以做為其他網域中群組的成員。更重要的是，和通用群組的成員屬性一樣，網域本機群組的成員屬性也不會出現在通用類別目錄中。結果變成無法輕易修復其他網域中之網域本機群組的使用者成員資格。
在 Windows Server 2003 SP1 之前，修復外部網域的網域本機群組成員資格的唯一方式，就是還原每一個網域中的 DC，以手動方式搜尋網域資料中有包含已還原使用者的任何網域本機群組，然後將該使用者新增回到您識別的群組中。在含有很多網域的大型環境中，此方式太過耗時。
Windows Server 2003 SP1 版本的 NTDSUTIL 可以幫忙。當您在網域控制站上執行 NTDSUTIL 時，該公用程式會建立一個文字檔，其中包含已還原使用者物件的 DN 和 GUID。然後，針對每一個外部網域，您可以未經授權地還原單一 DC，將該文字檔複製到 DC，並執行 NTDSUTIL 來產生新網域特有的 LDIF 檔，它會將已修復的使用者新增回到其所屬的網域本機群組。
為了達成此目的，請在每一個外部網域的 DC 上執行下列步驟：
  1. 將外部網域的 DC 啟動為 DSRM。
  2. 使用 NTBACKUP 還原 DIT 的複本，其中包含已還原使用者的群組成員資格。
  3. 將 NTDSUTIL 建立的 .txt 檔複製到目前的 DC。
  4. 開啟命令視窗並輸入 ntdsutil。
  5. 輸入 authoritative restore。
  6. 輸入 create LDIF file(s) from <file name> (其中 <file name> 是文字檔的名稱)。
  7. 輸入 quit 兩次以結束 ntdsutil。
  8. 將 DC 重新啟動為正常 Active Directory 模式。
  9. 輸入 ldifde –i –f <ldif filename> (其中 <ldif filename> 是您剛才建立之 LDIF 檔的名稱)。
現在您已還原所刪除使用者的所有群組成員資格。

逐步進行
修復 Active Directory 使用者及其群組成員資格很複雜，尤其在多網域環境中更是如此。正確修復群組成員資格所需的特定步驟，會視您執行的 Windows 版本而定。
如果您是執行 Windows 2003 SP1，請採取下列步驟：
  1. 將 GC 啟動為 DSRM，並使用包含已刪除使用者的備份，執行系統狀態還原。
  2. 使用 NTDSUTIL 執行已刪除使用者的授權還原。NTDSUTIL 會建立包含已還原物件 DN 和 GUID 的文字檔，以及一個或多個 LDIF 檔，來還原使用者的群組成員資格。
  3. 使用 LDIFDE –i –f <LDIF filename> (其中 <LDIF filename> 是在步驟 2 建立之 LDIF 檔的名稱)，在目前網域和其他網域中匯入群組成員資格。
  4. 將通用類別目錄重新啟動為正常模式。
  5. 在每一個外部網域的 DC 上，啟動為 DSRM 並使用包含已還原使用者之群組成員資格的備份，執行系統狀態還原。
  6. 使用 create ldif files 命令執行 NTDSUTIL。
  7. 將 DC 重新啟動為正常模式。
  8. 使用 LDIFDE –i –f <filename> (其中 <filename> 是在步驟 6 建立之 LDIF 檔的名稱)，在外部網域中還原群組成員資格。
  9. 此時，您可以選擇使用 REPADMIN /syncall 強制複寫。
如果您是執行沒有安裝 SP1 的 Windows Server 2003 版本，或是執行 Windows 2000，則還需要一些其他步驟。由於舊版的 NTDSUTIL 不會建立 LDIF 檔，請使用 GROUPADD 公用程式建立它們。其程序如下：
  1. 將通用類別目錄啟動為 DSRM，並使用包含已刪除使用者的備份，執行系統狀態還原。
  2. 停用 NIC 或拔除纜線以防止輸入複寫。
  3. 將通用類別目錄重新啟動為正常模式。
  4. 使用 LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf，傾出分辨名稱為 <dn> 之使用者的成員資格。
  5. 使用 GROUPADD /after_restore membership.ldf 建立 LDIF 檔。
  6. 使用 LDIFDE –i –f <filename> (其中 <LDIF filename> 是在步驟 5 以 GROUPADD 建立之 LDIF 檔的名稱)，在目前網域和其他網域中匯入群組成員資格。
  7. 使用 REPADMIN /options <dcname> -DISABLE_INBOUND_REPL，重新啟用輸入複寫。
  8. 在每一個外部網域的 DC 上，啟動為 DSRM 並使用包含已還原使用者之群組成員資格的備份，執行系統狀態還原。
  9. 將 DC 重新啟動為正常模式。
  10. 使用 LDIFDE –i –f <filename> (其中 <filename> 是在步驟 5 以 GROUPADD 建立之 LDIF 檔的名稱)，在外部網域中還原群組成員資格。
  11. 此時，您可以選擇使用 REPADMIN /syncall 強制複寫。
現在，未安裝 SP1 之 Windows Server 2003 環境唯一剩下的問題，是如何為已還原的使用者修復外部網域本機群組成員資格。您唯一的選擇是以手動方式還原網域本機群組成員資格，或從備份中還原 DC 並由系統授權還原網域本機群組。

結論
雖然您很容易從 Active Directory 中意外刪除使用者或甚至是 OU，但是要正確修復已刪除的使用者及其群組成員資格卻非常複雜，既耗時又容易出錯。若要確保您可以從這些嚴重損壞中盡快修復，您必須了解物件連結、複寫、刪除和授權還原的運作原理。
您認為自己初次在實際執行環境中嘗試時就可以正確執行所有步驟嗎？若要確保下次您必須修復 CEO 的使用者物件時已做好萬全準備，請備妥修復已刪除物件的書面計劃。而且，在實際資料上進行此計劃之前，請務必至少實作該計劃一次或兩次。您的老闆 (和 CEO) 一定會非常感激。
其他資源
  • 如何還原 Active Directory 中已刪除的使用者帳戶及其群組成員資格
  • Microsoft 產品支援服務
  • Step-by-Step Guide to Managing Active Directory

Gil Kirkpatrick 是 NetPro 的技術長，他從 1996 年開始開發 Active Directory 軟體。他與來自 HP 的 Guido Grillenmeier 共同提供大受歡迎的 Active Directory Disaster Recovery 工作室。Gil 也是 Directory Experts Conference (www.dec2007.com) 的創辦人。


 Windows 系統管理: 為何 Windows XP Embedded 對您很重要
Windows 系統管理 Don Jones

為何 Windows XP Embedded 對您很重要
摘要:
  • Windows XP Embedded 的內容
  • 特殊硬體選項
  • 自訂 Windows XP Embedded

Windows XP Embedded 是 Windows 的元件化版本，通常會讓人聯想到消費者電子裝置，例如機上盒或電子設備。但 Windows XP Embedded 在組織的資訊科技陣容當中，也可能應該佔有一席之地。雖然它不一定是每一位使用者的最佳
解決方案，但在某些特定的案例中，它可以減輕管理工作量、可以提供更便宜且更袖珍的硬體設備，以及實現更佳的安全性。

什麼是 Windows XP Embedded？
Windows® XP Embedded 是三個小型 Windows 版本的其中之一，另外兩個是 Windows Embedded CE 和 Windows Embedded for Point of Service。在內嵌式 (Embedded) Windows 作業系統中，只有 Windows XP Embedded 提供 Windows XP Professional 用戶端電腦的完整功能 (至少可具備完整的功能)。它是以 Windows XP Professional Service Pack 2 (SP2) 為基礎；不過，Windows XP Embedded 與一般 Windows XP 不同之處，在於其中的大幅模組化。Windows XP Embedded 並沒有所謂的標準安裝映像。相反地，您需要使用一種叫做 Windows Embedded Studio 的工具組，來為您要建置的裝置建立自訂的 Windows XP Embedded 環境，該環境只會包括您的裝置需要的功能。如果您不需要 DirectX® 或 Windows 檔案總管，就不要安裝它們。如此的模組化表示您建置及部署的每一個 Windows XP Embedded 映像，將具有更少的零組件，也就是說，管理工作量將會更少，安全性會更高，並且可以在成本更低廉的硬體上執行。有些可用的選項可在 Target Designer (Windows Embedded Studio 的一部分) 中見到，如 [圖 1] 所示。
圖 1 在 Target Designer 中選取元件
圖 1 在 Target Designer 中選取元件

在企業環境中佔有一席之地
有愈來愈多的使用者案例，都很適合使用 Windows XP Embedded 裝置。例如，假設公司設立大型客服中心。在許多情況下，客服中心人員只需要一兩個內部開發的應用程式及 Web 瀏覽器。他們只會用到電腦的部分功能，因此，Windows XP Embedded 可讓您縮減功能，直到剩下需要的功能。功能的減少表示可以降低發生失誤或安全性攻擊的可能性。
因為 Windows XP Embedded 裝置的功能有限，所以能夠在功能較低但也較便宜的硬體上執行。有許多製造商在生產使用低耗電、與 Intel 處理器規格相容的主機板。這些主機板非常袖珍、使用極少的電量，甚至不使用風扇，因為它們執行時不會產生太多熱能。它們很適合使用於只執行有限應用程式的小型內嵌式裝置。

Windows XP Embedded 的特殊超能力
Windows XP Embedded 提供一些極珍貴的選項，是完整版 Windows XP 所沒有的。其中包括 Enhanced Write Filter (EWF) 和 Hibernate Once, Resume Many (HORM)，這兩者均可簡化 Windows 管理工作。EWF 是一個選用元件，您可以將它加入 Windows XP Embedded 部署中，使指定的磁碟區成為唯讀。任何指向此磁碟的寫入活動都會轉向覆疊，它可能位於另一個磁碟上，甚至在記憶體中。作業系統本身會把 EWF 覆疊及其父磁碟區當成單一裝置，表示它看起來就像是一般磁碟區一樣。然而背地裡，父磁碟區實際上並未改變；只有 EWF 覆疊才有變更。這樣做有一些好處。假設將 Windows XP Embedded 映像部署到 Compact Flash (CF) 卡 (Windows XP Embedded 映像可以小到只有 5MB，通常只會佔用大約 200MB，因此 CF 的儲存空間綽綽有餘)。此 CF 卡可以插入轉接器並連接到主機板的 IDE 連接器，使 CF 卡像一般硬碟一樣。現今的 CF 卡寫入能力有限 (大約可允許 100,000 次寫入)，因此 EWF 可用來使 CF 磁碟區成為唯讀。假設將 EWF 覆疊放到 RAM 中的情況：如果使用者犯了錯，只要關掉機器即可。EWF 覆疊及對機器所做的任何變更，就會立刻消失。當您重新開機時，會回到 CF 卡儲存的起始點。您也可以對 CD 或 DVD 映像使用相同的設定；由於那些媒體類型在本質上是唯讀的，所以 EWF 會將任何寫入活動擷取到覆疊上。即使覆疊是儲存在小型內部硬碟上，也可以保證原始開機磁碟區 (在 CD 或 DVD 上) 不變；如果您需要將機器重設回其原始組態，只要清除 EWF 覆疊即可。
顧名思義，HORM 可讓機器休眠一次，然後不斷地從該休眠點繼續執行。電腦的開機速度會非常迅速。只要設定電腦並啟動所需的應用程式，然後將它休眠。此後，每當您打開機器時，只需要等幾秒鐘就可以讓一切按部就班地執行。

建置 Windows XP Embedded 映像
Microsoft 有一個 Embedded Partner 計劃，包含許多專精於使用 Windows XP Embedded 的公司 (您可以在下列 Windows XP Embedded 首頁找到公司名單：microsoft.com/embedded)。不過，就像許多提供預建映像 (其中會包括公司的應用程式和特定組態) 給一般 PC 製造商的公司一樣，您可以建置自己的 Windows XP Embedded 映像，然後與您的 Embedded Partner 分享，以納入您的完整小型系統中。可安裝在 Windows XP Professional 上的 Windows Embedded Studio，可用來建置及管理 Windows XP Embedded 映像。
若要使用此工具組，請先在您打算要用於 Windows XP Embedded 系統的硬體上安裝完整的 Windows XP Pro 版本。這可讓您使用完整 Windows XP 安裝程序，使所有硬體都能夠正常運作。然後，安裝 Windows Embedded Studio。這通常會安裝用來管理內嵌式映像的資料庫，但該資料庫實際上可安裝在別處，以中央儲存庫的方式運作。接下來，您會執行一個叫做 Tap.exe 的命令列公用程式，它會新建一個可供 Windows XP Embedded 使用的特殊元件。一般而言，元件會封裝功能，例如媒體播放程式、檔案系統或其他自訂應用程式；在此案例中，您會建立一個包含特定系統所需之硬體裝置驅動程式的元件。此步驟必須在目標硬體上完成，使該工具可以偵測及併入適當的硬體驅動程式。
接下來，您要執行 Windows XP Embedded Component Designer 並匯入 Tap.exe 公用程式所建立的元件套件。如 [圖 2] 所示，Component Designer 會讀取裝置資訊並組合完整的 Windows XP Embedded 元件，使其成為新的 Windows XP Embedded 映像的基礎。這樣可大幅簡化指定平台所需要的裝置驅動程式的判斷流程。建立該元件之後，您可以使用 Component Database Manager 將新元件匯入 Windows XP Embedded 元件資料庫中，這是儲存所有已知 Windows XP Embedded 元件的儲存庫。資料庫中有了該元件之後，就可以供 Windows XP Embedded 映像使用。
圖 2 Component Designer
圖 2 Component Designer
如此一來，您就可以使用 Windows XP Embedded Target Designer (這是進行大部分實際工作所需的工具)，開始建立新的目標組態。如 [圖 1] 所示，您將新增任何需要的元件，以建立裝置需要的功能集。您還需要新增一些 Windows 核心元件，例如 Windows 檔案總管 (如果裝置需要圖形 Shell 的話)、NTFS 檔案系統 (或 FAT32)、NT 載入器、語言支援、使用者介面核心...等等。根據預設，有超過一萬個元件可供使用。
您也可以預先設定每一個元件的設定。例如，使用者介面核心元件可自訂為在 Windows [開始] 功能表、桌面及其他位置顯示特定項目。自訂每一個元件的設定，可確保每一個裝置都預先設定為符合您的需求 (請參閱 [圖 3])。
圖 3 自訂設定
圖 3 自訂設定
Windows XP Embedded 映像最棘手的地方是依存性。例如，您在新增 DirectX 元件至映像時不得不同時加入其他幾個元件，以提供 Windows 的核心圖形處理功能。所有依存性的追蹤可能會很困難，尤其是針對大型且複雜的映像，因為其中可能涉及數千個依存性。這是 Component Database 的工作。只要在 Target Designer 內按 F5，它就會掃描您所新增的每一個元件，並自動新增您列出的元件所需的任何依存性。[圖 4] 顯示進行中的掃描；這是一個重要的步驟，也是讓 Windows XP Embedded 能夠高度模組化的原因。若 Target Designer 內沒有此內建智慧，將很難順利建立包含所有正確依存性的映像。
圖 4 依存性檢查
圖 4 依存性檢查
在新增所有元件及其依存性之後，您就可以建置 Windows XP Embedded 映像。映像是指需要複製到 Windows XP Embedded 裝置的開機磁碟區檔案。您不需要任何特殊工具就可以部署它們 (不過，Windows XP Embedded 工具組有包括一個遠端開機伺服器，其功能類似遠端安裝服務；它可讓 Windows XP Embedded 映像部署至裸機硬體)。完成這些步驟之後，您就可以看到映像到底有多大。我建立了一個很基本的映像，其中包括檔案總管殼層和一些應用程式 (例如 [記事本] 和 [小畫家])，而所建立的映像其實不到 90 MB 。當然，多數使用者對於只能執行 [記事本] 和 [小畫家] 的裝置可能並不感興趣，但這說明了具有特定工作目標之映像真的可以很小。

Windows XP Embedded 與 Windows XP
Windows XP Embedded 絕不是一個刪減功能的作業系統。Microsoft 所提供的預先封裝元件，可讓執行 Windows XP Embedded 的電腦具有很多與完整版 Windows XP 相同的功能。其中包括可安裝 DirectX 9.0c、Microsoft® .NET Framework、Windows Media® Player 10...等等的選項。您也會看到許多適用於開發人員的文件，其中說明如何建置自訂元件，例如可取代檔案總管的自訂殼層，讓您能夠針對特定的 Embedded 裝置建立一個量身訂做的環境。
不過，Windows XP Embedded 也無法提供完整 Windows XP Pro 版本所包含的每一項功能。例如，Windows 檔案保護 (WFP) 就不包含在 Windows XP Embedded 中；其中也不包括一些方便使用的功能，例如 Windows XP 導覽、初始歡迎畫面及協助新手設定電腦的精靈或 Windows 安裝程式。Windows XP Embedded 不會利用 Windows 產品啟用功能 (Windows XP Embedded 映像是使用 Windows Embedded Studio 工具內的執行階段產品金鑰來啟動)。最值得注意的是，Windows XP Embedded 完全不使用 Windows Update，不過它可以在環境中使用 Microsoft Software Update Services 伺服器。最後，Windows XP Embedded 也沒有 Windows XP Pro 所包含的 MSN® Explorer。
展望未來，Windows XP Embedded 仍會為豐富的軟體開發繼續進化：現在 Feature Pack 2007 已經上市，其中新增了如 USB 開機等的新功能，以及 EWF 的增強功能，讓新的檔案能夠認可至父磁碟區而不需要認可整個覆疊，還有對 NTFS 壓縮的支援...等等。這些增強功能將繼續在 Windows XP Embedded 作業系統中增加彈性和選項，使它與 Windows XP Professional 的功能集越來越能夠並駕齊驅。

改用內嵌式
內嵌式系統雖然比傳統 Windows XP 系統多了一些建置工作，但在特定的狀況下可提供重大優勢。雖然功能減少，但 Windows XP Embedded 系統可支援體積更小、耗電量更低的硬體裝置，使裝置更容易維護、更容易維修，而且可大幅降低成本。低耗電量也有助於減少水電費和散熱量，使精簡化工作區的設計和規劃更有彈性。除了 Windows XP Embedded 的預定用途 (消費性裝置、醫療保健器材、電子資訊站及其他您想像不到的地方) 之外，這個內嵌式作業系統在您的企業中可能也值得佔有一席之地。

Don Jones 是 SAPIEN Technologies 的專案服務總監，也是 Windows PowerShell:TFM (SAPIEN Press) 的作者之一。請透過 Don 的網站連絡他：www.ScriptingAnswers.com。


 管理: 使用 System Center Capacity Planner 預先規劃
管理 John Savill

使用 System Center Capacity Planner 預先規劃
摘要:
  • SCCP 基本知識
  • 建立新模型
  • 微調模型
  • 模擬實際使用情形

當今的基礎結構元件對於其所支援的企業營運是非常重要的。但是，隨著使用者數目的增加和公司營運的多元化，要準確地估計執行元件之伺服器的大小和
數量也越來越困難。硬體不足會造成一般使用者的回應時間不佳，而硬體太多則是會浪費預算並且造成額外的管理負擔。因此 Microsoft 開發了 System Center Capacity Planner (SCCP) 2006。
整體而言，SCCP 可以讓您輸入網路拓樸 (位置、連線速度、延遲)、要使用的軟體與硬體，以及用法設定檔 (例如傳送的訊息數目) 等的相關資訊。然後 SCCP 會模擬不同的負載，來分析硬體和網路元件的使用率。此模型有助於評估建議的系統組態，在實際執行後是否能滿足您的服務需求。
SCCP 不需要在任何特定伺服器上執行或執行網路測試，它本質上是一個模擬工具，能夠針對模型中的環境執行案例測試。SCCP 的實際系統需求不高：Windows® XP (含 Service Pack 2 (SP2))、Windows Server® 2003 或 Windows 2000 (含 SP4)，再加上 Microsoft® .NET Framework 2.0。新一代的 SCCP 應該能與 Systems Management Server (SMS) 和 Microsoft Operations Manager (MOM) 更緊密的接合，而且能夠將部分資訊的收集自動化，因為 MOM 已經收集有關伺服器使用率的資訊，而 SMS 則已經有維護硬體組態的資訊。
SCCP 2006 的安裝很簡單，標準安裝精靈只需要您接受授權合約和確認安裝資料夾。安裝好產品之後，會在 [所有程式] 功能表中新增捷徑。您第一次啟動 SCCP 時，可從 Microsoft Capacity Planner 歡迎畫面中，存取容量規劃程式的三個元件 (共四個)，如 [圖 1] 所示。
圖 1 啟動容量規劃程式工具
圖 1 啟動容量規劃程式工具
模型精靈 (Model Wizard) 會詢問關於所要之環境的問題，以建立系統架構模型 (System Architecture Model，SAM)。SAM 包含詳細的位置、使用者、網路、使用狀態及硬體。
模型編輯器 (Model Editor) 可以微調及修改先前透過精靈或編輯器建立的 SAM。您可以在這裡驗證模型、顯示模擬的使用情形，以及測試其他狀況，例如郵件伺服器的額外負載或遠端使用者的存在。
容量規劃程式附有許多針對 SAM 可用之預先定義的硬體類型。但是，您若有不同需求，硬體編輯器 (Hardware Editor) 可以支援硬體組態的自訂定義。
選取模型時，容量規劃模擬程式 (Capacity Planner Simulation) 允許針對選取的模型執行各種測試，以判斷其在實際環境中執行的可行性。
檢查元件及各元件互相操作的最佳方式，是實際使用工具。我會先從精靈開始，執行模擬，然後新增自訂硬體以微調架構模型。我在此逐步解說中處理的是 Exchange 環境，但是 MOM 的程序與此類似。

建立新模型
想要在規劃的基礎結構上執行驗證或「假設 (What If)」狀況，甚至只是想要執行目前部署之基礎結構的狀況，您必須先向 SCCP 描述環境。很可惜，您在目前版本中不能只進行網路的掃描。而是必須以實際位置和各位置間的連線類型、伺服器、信箱及使用者的位置來詳細描述基礎結構，並且詳細說明使用者將如何使用環境。
此工具有一些限制，在使用者指南中有詳細的說明。例如，Exchange 模型中只支援一個樹系。這表示不會建立外部樹系中之網域的模型，並且會假設任何前端伺服器的通用類別目錄和信箱存放區都位於同一個站台中。最多只能建立 100 個站台的模型，其中可以有 10 個中樞站台，最多 300 部伺服器電腦，而且只支援 Outlook® 2003 用戶端 (Web 或本機)。好消息是 SCCP 在中央/中樞位置最多支援 49,999 個用戶端，在分支位置最多支援 10,000 個。Exchange 功能 (例如 ActiveSync®) 和 Outlook Mobile Access 連線都不支援，也不支援 POP 和 IMAP 等舊版連線選項。備份與還原作業造成的使用率並不計算在內，叢集設定也一樣；不過，容量規劃程式有必要的選項，可以準確地建立日常郵件使用情形的模型。
若要從 [歡迎使用] 頁面開始逐步解說，請選取 [使用模型精靈建立模型 (Create a model with the Model Wizard)]，並描述要建立之模型的基礎結構。我將要建立一家公司，該公司有三個位置 -- 中央位置在 Dallas 以及兩個在 Houston 和 Austin 的分公司 -- 每一個位置都有許多本機電子郵件使用者。每個位置不一定有自己的伺服器，因此我提供電子郵件使用者的數目和類型；SCCP 就會計算哪些位置應有本機 Exchange 伺服器，以及哪些使用者將從遠端存取 Exchange 伺服器。
建立企業基礎結構的基本模型之後，精靈會詢問中央和分支站台的數目、站台之間的連線，以及可用於訊息傳遞的頻寬百分比。精靈會進行大致的設定；稍後我可以微調精靈所建立的模型，更細微地設定個別的連結。在此範例中，我可以確認一個中央辦公室和兩個分支站台 (請參閱 [圖 2])。分支和中央站台之間有 T1 連線，一半的頻寬可用於訊息傳送。我只有一個中央站台，因此不必設定中央站台之間的速度。
圖 2 設定 WAN 拓樸與連線頻寬
圖 2 設定 WAN 拓樸與連線頻寬
精靈的下一個視窗會詢問分支位置的使用者數目、電子郵件用戶端數目 (使用快取模式的 Outlook 2003 或 Outlook Web Access)，以及中央站台的使用者數目。這也是非常高層級的資訊，稍後同樣可使用模型編輯器 (Model Editor) 微調。在此例中，我定義每個分支有 200 位使用者，而中央辦公室有 500 位使用者，全都使用快取模式的 Outlook。
精靈有三個預設的郵件使用層級：高、中及低。每個層級都假設一種不同的平均信箱大小、傳送與接收的郵件數目，以及每一電子郵件的平均大小。如果內建類型全都不符合您組織預期的使用模式，則可以針對四個不同的使用特性，設定個別的值。
下一步是設定硬體喜好設定，如 [圖 3] 所示。SCCP 最多允許指定三種可能的 CPU 組態，這些將用於建立各種伺服器角色的硬體模型。CPU 組態的範圍從單處理器 1 GHz Pentium III Xeon 一直到四處理器 3.66 GHz Xeon MP。Exchange 2003 包含許多角色，分別為：Mailbox Store (信箱存放區)、Bridgehead (橋接頭)、Front End (前端)，加上額外的 Active Directory® Global Catalog (通用類別目錄)。如果使用率允許，有選項可以將角色合併到較少的伺服器上。如果未指定伺服器合併，則即使使用率不高，仍會為每個角色設定在不同的伺服器上。允許 SCCP 合併會提供最佳的結果。
圖 3 設定伺服器的硬體設定檔
圖 3 設定伺服器的硬體設定檔
最後，可以根據介面、大小及速度，選取可用的磁碟類型。不需要磁碟數目；容量規劃程式會為我計算數目。規劃程式也可以指定存放區域網路 (SAN)，不過目前還沒有建立叢集的能力。
精靈的下一步是計算模型的摘要，摘要中顯示 SCCP 計算為最佳的伺服器數目、每個伺服器的角色，以及處理器、記憶體和磁碟組態等詳細資訊。如果選取了 SAN，也會顯示出來。
請注意，只因為我選取了多個位置，因此很可能只顯示部分位置的伺服器。這是因為 SCCP 確定某些位置的本機 Exchange 伺服器並不是最理想的，反而透過遠端 Exchange 信箱伺服器可以提供更好的信箱服務，如同我在 [圖 4] 中的範例所示。在此案例中，有 400 位使用者的分公司並沒有本機 Exchange 信箱存放區，而是合併到 Dallas 位置中的單一 Exchange 信箱存放區伺服器，該處現在顯示的是 500 個使用者。
圖 4 初始容量規劃評估的摘要
圖 4 初始容量規劃評估的摘要
執行到此，我隨時可以在精靈中按一下 [上一步 (Back)] 和 [下一步 (Next)] 按鈕來修改答案及微調模型摘要 (或者直接在左邊導覽窗格中按一下精靈的各頁面)。對於組態滿意之後，我便按一下 [模型摘要 (Model Summary)] 頁面上的 [完成 (Finish)] 按鈕。這會在模型編輯器 (Model Editor) 中開啟模型，您可以在其中進行更細微的設定。

微調模型
模型精靈 (Model Wizard) 是建立基礎模型的一個好用工具。但是，除非各個位置全都相同並平均分配資源，否則很可能需要進行部分自訂作業，才能真正做為計算使用率的基礎。各位置有不同數量的使用者，或者可能是各種郵件用戶端的組合 (例如部分是 Outlook 2003 快取，部分是 Outlook Web Access (OWA))，這是很正常的。雖然無法在模型精靈中達到這麼詳細的程度，不過可以透過模型編輯器設定。如果想要評估修改各環境層面所造成的影響，例如增加更多的位置或使用者類型，這套工具是很有用的。
[圖 5] 中顯示的模型編輯器會以 .sam 檔案儲存及擷取模型，這種檔案是此工具的專用格式。不論執行任何操作，在進行重要變更之前將模型儲存至檔案，並使用描述性名稱以確保不會遺失任何工作中的模型，這是很好的習慣。[檔案 (File)] 功能表中的 [匯出 (Export)] 功能表，可以產生 Excel® 格式的摘要報表和 Visio® 的拓樸圖。
圖 5 在模型編輯器中調整 SAM 設定
圖 5 在模型編輯器中調整 SAM 設定
模型編輯器 (Model Editor) 的左窗格中是一個基本的導覽區域，其中有選項可以檢視全域拓樸、站台拓樸或模型摘要。[全域拓樸 (Global Topology)] 會以站台觀點顯示架構模型，包含網際網路等更多的網路。[站台拓樸 (Site Topology)] 會顯示所選取站台或網路的相關資訊。[模型摘要 (Model Summary)] 會顯示環境的文字摘要，其內容和您在模型精靈 (Model Wizard) 執行完畢時看到的內容一樣。
不論選取哪一個選項，詳細資訊都會顯示在模型編輯器 (Model Editor) 的中間窗格。右窗格具有 Windows Server 2003 R2 包含之新版 Microsoft Management Console (MMC) 的特質，是一個「動作」區域，其中分成兩個子區域：上半部會根據目前的檢視或所選取物件而變更的線上即時動作，下半部則包含一直都套用的一般動作。下半部的動作可以讓我新增站台、編輯使用者的用法設定檔，以及 (好玩的部分) 執行模擬。
使用模型編輯器 (Model Editor) 的中間窗格時，所有的項目都是可選擇的。選取項目之後，除了目前的項目動作會根據選取的物件變更之外，我還可以進一步查看物件的詳細資料。例如，在某個站台上按兩下就會切換到 [站台拓樸 (Site Topology)] 檢視，顯示該站台之模型物件的詳細資料。因此，由本機提供服務的站台會顯示該位置的一或多部伺服器、網路及使用者。然後，可以再按兩下選取的物件，以檢視物件的詳細內容，再依需要修改內容。
連接各站台的線條代表各位置間的網路，可以編輯以設定準確的網路數據。例如，我可以指定不同的上傳和下載頻寬速度，以及可用的頻寬百分比。我也可以設定連線延遲，這是通訊穩定性的一個很重要屬性。其他常見變更包含其他使用者類型的新增。在此案例中，假設我的中央位置提供 Outlook Web Access 和 Outlook 2003 用戶端的混合服務。在 Dallas 的 [站台拓樸 (Site Topology)] 檢視中開啟 Dallas 之後，我會選取 [新增用戶端設定檔 (Add A Client Profile)]，並新增 OWA 使用者的資訊，資訊中會包含 OWA 用戶端將使用的伺服器、使用者將連接的來源網路，以及使用者可使用的頻寬，如 [圖 6] 所示。
圖 6 在模型中新增及修改項目很容易
圖 6 在模型中新增及修改項目很容易
等到 SAM 已貼切地反映現有的或規劃的基礎結構之後，儲存及命名組態以確保可以容易地識別做為未來任何修改的起點。我想要在這裡執行模擬，以獲得模型在目前組態設定下之執行效能的基準。我可以根據基準修改模型以測試各種「假設」狀況，例如新增站台和使用者、新增或移除伺服器、新增使用者至位置，或者變更連線或電子郵件用戶端的類型。以這些新項目更新模型之後，我可以執行另一次模擬，看看新組態的效果。

模擬實際使用情形
執行模擬很簡單，只要按一下模擬動作的 [執行 (Run)] 或工具列按鈕。首先會執行模型的健全狀態檢查：執行模擬之前，會顯示模型中的任何瑕疵。例如，若是在先前沒有 OWA 用戶端的模型中新增 OWA 用戶端，而且未設定 Front End (前端) 伺服器，就會顯示錯誤訊息，通知您 Front End (前端) 伺服器不存在。如果模型中沒有瑕疵，就會在執行模擬時顯示狀態。
模擬完成之後，會產生包含所有元件使用情形之詳細資訊的報表，並且開啟 [模擬結果 (Simulation Results)] 檢視。最初會顯示摘要檢視，提供 CPU、存放區及連線連結等使用率最高的詳細資料 (這些是常見的瓶頸導因)，以及最長的交易和延遲時間，這些可能影響一般使用者的經驗。選取模擬結果左窗格中的連結，即可檢視伺服器、SAN、本機與外部連線的詳細資料，如 [圖 7] 所示。
圖 7 簡單模型的模擬結果摘要
圖 7 簡單模型的模擬結果摘要
將滑鼠指標放在各圖形上，例如瓶頸 (Bottleneck) 分析，就會顯示造成該瓶頸的伺服器和伺服器的屬性。請注意左窗格中的 [閾值 (Threshold)] 設定。這個類別可以讓我針對使用率來設定系統發出警告之前的閾值，是很實用的功能。
詳細的模擬報表之所以好用，不只在於幫助評估硬體採購決策，還在於能顯示訊息傳送應用程式將使用的網路資源量。例如，針對使用較慢 WAN 連線的使用者，此報表會提供連結是否夠快的指示。如果不夠快，我可以查明各位置間的連線速度是否必須升級，或者是否應增加本機信箱存放伺服器，只要修改模型然後重新執行模擬，即可取得符合特定條件的結果。同樣地，如果伺服器全都以 5% 的 CPU 使用率在執行，我就可以降低伺服器的規格。有了可輕易修改模型和重新執行模擬的能力，我實際上可以任意地實驗不同的解決方案選項。有了所有測試狀況的準確數據，我就可以自信地出席預算及規劃會議。

結論
我只提供 SCCP 可以如何讓您模擬及分析 Exchange 部署的概觀。請記住，SCCP 也能針對 MOM 執行相同的模型和模擬作業。SCCP 目前已包含在 MSDN® Premium 或 TechNet Plus 中，可供下載。 ¦

John Savill 是 Geniant 的技術基礎結構總監。他是 CISSP，Windows Server 2003 的安全性與訊息 MCSE、八次榮獲 MVP，以及 Krav Maga 的講師。他也是 Packt Publishing 出版之 Windows Server 2003 Active Directory Design and Implementation 的作者。


 管理: 使用 SMS 進行進階用戶端清查
管理 Wes Dobry

使用 SMS 進行進階用戶端清查
摘要:
  • 使用 SMS 2003 硬體清查代理程式 (SMS 2003 Hardware Inventory Agent)
  • 使用 MIF 檔案擴大清查
  • 動態與靜態 MOF 檔案
下載本文程式碼: DobrySMSInventory2007_04.exe (152KB)

每個系統管理員都會遇到這樣一種情況，就是上司所要求的資訊，必須千辛萬苦才能收集到。不過您可以想像一下，若是做個主動的系統管理員，
提早收集此一資料的情況：您將可以立即提供資訊給上司，因而避免不必要的停工、避免加班的工時，甚至還可以為公司節省大量的金錢。您可能成為令人佩服的英雄。
Microsoft® Systems Management Server (SMS) 2003 現成已收集極大量的資訊。但是它並沒有收集一切。例如，SMS 2003 預設並不會報告本機群組及其成員，或者本機使用者及其屬性。假設技術人員將 Domain Users，甚至 (更糟) 將 Everyone 放入其所使用之每一個系統上的 [本機系統管理員 (Local Administrators)] 群組中，那麼缺少這些資訊就可能發生問題。或者，假設某公司不知道其防毒/反間諜解決方案中的本機檔案和資料夾排除清單的內容。等到某一位 IT 員工發現使用者將 c:\*.* 加入排除清單中，就已經成為大問題。
將指令碼、Windows® Management Instrumentation (WMI) 及 SMS 知識適當地組合，可以擴大 SMS 的清查功能，幾乎可包含任何資訊片段。這可以使用 MIF (Management Information Format) 和 MOF (Management Object Format) 檔案做到。

進行清查
組織可以利用 SMS 執行自訂部署、監控目標及維護部署的系統。藉由擴展 SMS 的清查功能，您就可以建立及管理更細膩的自訂目標。例如，您可以將公司的安全性原則部署至已有使用者修改原則的系統，以強制執行公司的本機安全性原則。您也可以停用未核准的本機使用者帳戶，並移除無關的本機系統管理員。
當然，組織也依賴 SMS 以取得及時的用戶端系統詳細資訊。擴展清查功能可以讓您建立包含完全自訂資訊的報表，這些自訂資訊在您純綷依賴預設清查功能時並不容易取得。而且資訊也可以很細微。例如，您可以建立一份報表，報表中包含具有指向特定伺服器陣列之特定登錄機碼的系統計數。這會允許系統管理員大概地估算在任一特定時間，有多少用戶端指向每個陣列。同樣地，安全性小組可以檢查並了解網路上有哪些系統正在執行已知為間諜軟體的特定處理程序。
MIF 和 MOF 檔案的價值在於只要稍微轉譯，幾乎可從任何來源輸入資訊的能力。只要是文字的資訊，就可以使用 MOF 檔案操控資訊並放入 WMI 中，或者以 MIF 檔案的形式收集，並轉送至下一個硬體清查週期。執行清查擴展需具備 VBScript 或 JScript® 以及要收集之資訊的相關知識。考慮到幾乎任何資訊都可以收集，此必備知識的範圍可能從 WMI 到進階 SQL 知識。當然，不論您收集何種資訊，都一定要了解 SQL，因為等到要針對收集的資料產生報告時，您就需要此知識。

清查的運作方式
SMS 包含兩種清查程序：硬體與軟體。軟體清查只有檔案的資訊，例如檔案所在位置、檔案的版本、檔案大小及其他檔案屬性等相關資訊。但是，軟體清查程序也允許您收集檔案，並將檔案儲存在站台伺服器上。
硬體清查的擴展很容易，因為硬體清查包含最大量的系統相關資訊。硬體清查中的資訊主要是衍生自 WMI、登錄和系統 BIOS。
硬體的清查會根據 SMS 2003 上的硬體清查代理程式 (Hardware Inventory Agent) 站台中設定的時程收集。設定可以頻繁到每分鐘收集一次，或者幾個月才收集一次。通常您要找出一個平衡點，以管理所需的最快速率收集此資訊，但是又不致於造成網路、站台伺服器、管理點或用戶端的負擔。
硬體清查代理程式最初安裝時，會編譯 sms_def.mof 檔案。檔案中包含 SMS 初始收集的所有資訊。編譯此檔案時，會在 WMI 中建立硬體清查代理程式所需的一切 SMS 名稱區和相關的類別。其中大部分都位於 \\.\root\CIMv2\SMS 名稱區中。安裝之後，硬體清查代理程式會檢查大多數的類別以建立資訊，然後再將資訊傳送至管理點，最後傳送至站台資料庫。

MIF 檔案
除了從這些 WMI 類別取得資訊以外，硬體清查代理程式還會在 NOIDMIF 和 IDMIF 集合資料夾中尋找 MIF 檔案。代理程式在這些位置中找到的任何 MIF 檔案，都會處理到下一次的硬體清查中。
MIF 檔案提供最容易擴展 SMS 硬體清查的方式。MIF 檔案有兩種 -- NOIDMIF 和 IDMIF 檔案。這些檔案是類似 XML 的靜態檔案，幾乎可以包含使用者想要放入 SMS 資料庫中的任何資訊。檔案可以使用建立普通文字檔案的任何方式建立。因此，這些檔案可以使用大多數的指令碼語言建立，或者純綷以人工的方式建立。
MIF 檔案通常是在資訊未包含在登錄或 WMI 中，或者必須手動輸入資訊等情況下使用。例如，可以在您的硬體部署小組提交新系統時建立這些檔案。部署技術人員可以巡覽到系統上的 HTML 應用程式，然後輸入要用於更新資產管理資料庫的所有資產資訊。應用程式就會動態建立 NOIDMIF 檔案，並允許技術人員將檔案下載至 NOIDMIF 檔案集合資料夾。這個 NOIDMIF 檔案可以包含技術人員輸入的所有資訊，而且會加入 SMS 資料庫中。
NOIDMIF 和 IDMIF 檔案只有少許的差異。IDMIF 檔案包含唯一的標頭，標頭中會提供架構資訊和唯一識別碼。IDMIF 檔案可用於將非系統裝置當成其自己的實體加入 SMS。例如，可以使用指令碼在 SMS 中建立實際上是印表機的系統，並將這些系統的相關資訊寫入 SMS 資料庫中。
NOIDMIF 和 IDMIF 檔案儲存在登錄機碼指定的標準位置中。這些位置通常是 %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF 和 ...\IDMIF (假設 SMS 代理程式安裝在預設位置)。如果代理程式安裝在自訂的位置，MIF 目錄應該是在 %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF 和 ...\IDMIF。但是若不確定這些目錄的位置，可以在下列登錄機碼中找到確切的位置：
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
不論收集的是何種資訊，MIF 檔案的格式一律相同。請看 [圖 1] 中顯示的 MIF 檔案，您會看到檔案是由包含多個群組和每個群組之單一屬性的單一元件組成。雖然您不需要一個以上的群組或屬性項目，不過所有區段都是必要區段。您可以把 MIF 檔案中的每個群組看成是硬體清查中已命名區段之資料中的一列，而群組中每個屬性都是該列中的一欄。
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
[圖 2] 中顯示的範例 LocalAdmin.vbs 是一個相當簡單的 VBScript。它會查詢 NOIDMIF 目錄、如果有現有的暫存 MIF 檔案則會刪除檔案、建立暫存 MIF 檔案、遞迴地將利用簡單 WMI 查詢收集的資訊寫入檔案、刪除 NOIDMIF 集合資料夾中存在的 MIF 檔案，最後再將暫存的 NOIDMIF 移到 NOIDMIF 集合資料夾中。
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
儘管 MIF 檔案提供容易擴展 SMS 硬體清查的方式，不過在使用時仍要考慮一些問題。MIF 是在每個硬體清查週期處理。不過因為這些檔案必須建立、收集、分析，最後再放入清查中，所以 MIF 中包含的資訊最多會延遲一個硬體清查週期，才會在清查中顯示。這表示某家公司的硬體清查週期若是一天，其站台資料庫中的資料最多可能延遲兩天。因此，您必須仔細考慮何時通告建立 MIF 檔案的程式，以及硬體清查週期何時執行。
假設名為 Contoso 的公司，其清查週期是一天，在午夜執行。VBScript 在星期一的 1:00 AM 執行，建立包含 Rootkit 掃描程式之輸出的 NOIDMIF 檔案。此輸出會在午夜收集，並向管理點報告。然後 Contoso SMS 系統管理員於星期三晚上 10:00 PM 左右檢查資訊時，會發現資訊已是 45 小時前的資訊。這是因為 SMS 系統管理員並未考慮到何時通告用於建立 NOIDMIF 檔案的程式。

MOF 檔案
MOF 檔案比 MIF 檔案複雜。而且這種檔案優於 MIF，因為它會直接將其資訊輸入到 WMI 中，並成為硬體清查代理程式之標準資料收集程序的一部分。因此，您不必一再地通告 VBscript 以取得資訊，這可以節省時間和麻煩。您只需在每部電腦通告一次 MOF，它就會編譯。
MOF 檔案還有一個優點，就是資訊可保持和硬體清查之其餘資訊一樣新的狀態。硬體清查代理程式每次經歷其週期時，都會查詢 MOF 檔案中詳述的類別和提供者，並且迅速傳回資訊。如果您需要盡快取得資訊，只要執行包含您的 MOF 檔案和 VBScript 的封裝，即可馬上開始硬體清查。在短短的一個通告程式原則週期中，就可取得您需要的資訊。
MOF 檔案分成三類：現有的 WMI 類別與名稱區的 MOF 檔案、具有現有 WMI 提供者之額外類別的 MOF 檔案，以及沒有 WMI 提供者之額外類別的 MOF 檔案。
MOF 檔案包含兩個部分。第一部分是名稱區定義區段。WMI 提供者資訊就是在此識別。第二個區段包含 SMS 報告屬性。這個區段會告訴硬體清查代理程式應在何處尋找及處理前述 WMI 類別中包含的資訊。由於 MOF 檔案會直接處理 WMI，因此我建議您若是打算使用這些檔案，請花一點時間研究 Microsoft WMI Software Development Kit (SDK) (如需詳細資訊，請參閱 go.microsoft.com/fwlink/?LinkID=83121)。
上述的每個 MOF 檔案分類都可以是靜態或動態的。例如，如果您讓公司的建置程序編譯包含誰組建了系統、所使用的伺服器組建、初始組建版本為何、組建電腦的日期...等等相關資訊的 MOF 檔案，您擁有的就是靜態 MOF 檔案。這些資訊永遠不必更新，因此資訊可以直接放入 MOF 檔案中，並使用 mofcomp.exe 編譯到 WMI 中。在此之後，必須在站台伺服器上的 sms_def.mof 檔案中加入群組和類別資訊，才能擴展硬體清查代理程式所檢視的區域。
動態 MOF 檔案類似於靜態 MOF 檔案，差別在於它不會直接將收集的資訊寫入 WMI，而是會透過 WMI 提供者收集資料。WMI 提供者是一個外掛程式，其中允許應用程式或服務直接輸入資訊至 WMI。這個提供者允許動態存取 WMI 和系統的其他區域，例如登錄、檔案位置及 Windows Installer 資訊
在使用 MOF 檔案方面，增強硬體清查功能最容易的方式，就是讓清查作業包含更多已存在於 WMI 中的類別目錄資訊。執行方式是擴充 sms_def.mof 或開啟目前已停用的其他報告類別。sms_def.mof 檔案位於 \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv 資料夾中。公司中所有的裝置將會於下一個電腦原則週期取得新的 sms_def.mof，並開始收集和報告資訊。
以困難度而言，下一項是使用現有的 WMI 提供者，但是建立新的類別。這種方法的範例顯示於 [圖 3] 中。此範例中使用了內建的登錄提供者來建立 CU_Desktop 類別，其中具有會查詢本機裝置之 HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper 的動態內容。在用戶端上編譯此 MOF 檔案後，必須將 SMS_Def_Extension.mof (請參閱 [圖 4]) 中包含的資訊附加到 sms_def.mof。這個檔案包含 SMS 是否應針對其建立報告、群組名稱、類別識別碼、硬體清查代理程式應在 WMI 中檢查哪個類別以尋找要報告的資訊，以及實際值等相關資訊。
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
MOF 檔案也能夠存取系統上預設未包含之 WMI 提供者所提供的資訊。在用戶端上編譯 MOF 檔案，以及在擴充 sms_def.mof 之前，必須先散佈及安裝 WMI 提供者，才能使用這些提供者。

結論
MIF 和 MOF 檔案是快速和大量收集資訊的強大工具。這些檔案格式提供不必直接修改資料表即可輕易將資訊引入 SMS 資料庫的架構。只要想像力夠，幾乎可以清查及報告任何資訊。更理想的是，可以有效避免問題，因為系統管理員可以主動地收集必要的資訊。
要了解 MIF 和 MOF 檔案需要一點時間。不過有一些不錯的資源可以協助您學習如何使用這些檔案。首先建議閱讀 WMI 文件和 SDK，以及 Systems Management Server 2003 Operations Guide。只要您用心了解這些概念，將會發現擴充的 SMS 清查功能帶給您的收穫遠多於您的付出。

Wes Dobry 居住於佛羅里達州的奧蘭多，擔任當地一家大型保健公司的顧問和網路系統管理員。他的連絡方式為：wesdobry@wesdobry.com。


 管理: 使用 SMS 2003 R2 部署自訂軟體更新
管理 Steve Rachui

使用 SMS 2003 R2 部署自訂軟體更新
摘要:
  • SMS 2003 R2 的全新更新管理功能
  • Custom Updates Publishing Tool
  • Inventory Tool for Custom Updates

您需要針對個人系統部署自訂更新，例如特殊硬體或商務應用程式時，一定無法獲得像 Windows Update 那樣的受管理和自訂化程序的優勢。至少過去從未有這樣的經驗。現在，有了 Systems Management
Server (SMS) 2003 R2，您將可以使用這些更新管理功能，來部署個人的自訂更新。SMS 2003 R2 中有幾項新功能，包括 Device Management Feature Pack 的更新、Operating System Deployment (OSD) 功能套件的連結，以及多項可增強安全性監視器的功能。產品中具有弱點評定的掃描工具，這是瞭解潛在系統和網路弱點的重要方式，例如 OS 組態設定、使用者密碼、IIS 及 SQL Server™ 組態設定等的弱點。其中還包括 Inventory Tool for Custom Updates (ITCU) 以及 Custom Updates Publishing Tool (CUPT)。我將在本文中針對上述兩種工具進行說明，以協助您更輕鬆、有效地部署個人自訂更新。

Custom Updates Publishing Tool
在您安裝和使用 SMS 2003 R2 之前，階層架構 (包括用戶端) 必須先更新為 SMS 2003 Service Pack 2 (SP2)。若要使用 CUPT，您必須升級至 Microsoft® Management Console (MMC) 3.0。 您無須將 CUPT 安裝在 SMS Site Server 上，但至少必須將其安裝在 Windows® XP 上，並且需要 SQL Server 2005 來裝載其資料庫；若沒有 SQL Server 2005，則必須安裝 SQL Server Express Edition。CUPT 是在 SMS 系統中採用和管理自訂更新的關鍵，同時也具備在 SMS 中發行之前，先針對已建立目錄進行測試的功能。
自訂更新有兩種類型：由協力廠商提供其軟體產品的更新，以及針對特定環境於內部建立的專屬更新。CUPT 是用來同時管理這兩種更新類型的工具。使用協力廠商提供的自訂更新較為簡便，因此我們就從這裡開始說明。在撰寫本文的同時，有三家公司正在推出更新目錄，可用來掃描並發佈適當的 SMS 修補程式：Adobe、1e 及 Citrix。若要檢視參與的公司名單，請選取自訂更新協力廠商/合作夥伴的目錄，如 [圖 1] 所示。
圖 1 CUPT 使用狀況
圖 1 CUPT 使用狀況
若要使用協力廠商/合作夥伴提供的更新，只需下載目錄並新增至 SMS 即可。首先下載您需要的更新，然後選擇 [動作 (Action)] 功能表上的選項以匯入更新。精靈會要求提供您所下載的 .cab 檔案位置。精靈完成之後，新的更新會出現在 CUPT 中，以便進一步設定，並發行至 SMS Site Server。不過請注意，每項需要的更新都必須先設定發行旗標。若更新未設定旗標，則執行發行要求時不會將其包括在內。您可以一次設定大量的旗標，如 [圖 2] 所示。請注意，最右邊的資料行必須啟用旗標，才能發行該更新。
圖 2 設定發行旗標
圖 2 設定發行旗標
您可以視需要，進一步自訂每個下載的更新。如果要這麼做，請選取更新並選擇 [編輯 (Edit)] 即可。不過，自訂更新時要特別小心，因為不當的設定會導致非預期且無法令人滿意的結果。
設定更新的旗標之後，就可以開始發行。您可以發行至外部 .cab 檔案以便稍後使用，或者與 SMS 站台資料庫同步處理選取的更新以便立刻使用。若要與 SMS 站台資料庫同步處理，您必須提供設定資訊，例如 Site Server 名稱和套件來源路徑 (請參閱 [圖 3])。
圖 3 同步處理資訊
圖 3 同步處理資訊
您可以反白顯示 [自訂更新 (Custom Updates)] 節點，然後從 [動作 (Action)] 功能表上選擇 [設定 (Settings)]，即可找到這個畫面。在提供可存取的站台伺服器名稱，以及指向 Inventory Tool for Custom Updates 的來源目錄路徑之後，站台碼和狀態就會更新。
同步處理選項設定完成之後，CUPT 即備妥與 SMS Site Server 同步處理。若要執行同步處理，請從 [動作 (Action)] 功能表中選取發行更新選項。這會啟動發行精靈。若要發行更新至 SMS 資料庫以便立刻使用，請確認已選取與 Systems Management Server 站台資料庫 (Site Database of Systems Management Server) 同步處理的選項。幸好這個步驟有視覺上的協助：若尚未設定同步處理，則此選項會變成灰色。
精靈完成之後，即可於 SMS 系統管理主控台進行自訂更新。啟動 Distribute Software Updates Wizard 即可選擇處理任何可用的自訂更新。
現在您已瞭解如何使用協力廠商之產品的更新，然而若無現成的預先封裝更新可用時，該如何為廠商提供的軟體自訂更新呢？這就是 CUPT 發揮功效的地方。有了 CUPT，您可以建立目標準則完整的自訂更新，以應付幾近所有情況。
建立自訂更新並不難，但系統管理員必須瞭解如何修補軟體、判斷修補之適用性的條件，以及更新所需的目標規則。目標規則與更新建立程序是分開的。只要選取 [動作 (Action)] 功能表的 [管理規則 (Manage Rules)] 選項，即可看到規則。
自訂更新的建立，必須藉由選取 [動作 (Action)] 功能表的 [建立更新 (Create Update)] 項目來啟用，這會啟動精靈，讓您輸入自訂更新的各項細節。建立自訂更新的詳細內容已超出本文的討論範圍，不過我將選擇其中一個已匯入自訂協力廠商更新的屬性，以協助您了解建立個人更新時應填入的每個欄位，做為示範。已設定完成的協力廠商更新屬性，顯示於 [圖 4]。
圖 4 協力廠商更新屬性
圖 4 協力廠商更新屬性
使用自訂更新建立程序，您不僅可以建立更新，還能設定將軟體發佈至用戶端系統。雖然這是可行的，但請注意，這並非建議的方法，也不是 CUPT 的預定用途。

Inventory Tool for Custom Updates
ITCU 是全新的清查工具，可配合自訂更新目錄使用。ITCU 和過去的掃描工具一樣，可以建立自訂集合、套件和廣告，以便於企業中為 SMS 用戶端部署掃描工具。ITCU 也和過去的掃描工具相同，能夠從可存取 SMS 發佈點擷取目錄 (亦即自訂更新目錄)、根據目錄資料執行掃描、將掃描結果插入 Windows Management Instrumentation (WMI)，以及透過硬體清查報告結果。掃描程序的主要差異，在於其中使用的目錄。
SMS 2003 R2 推出後，為現有 SMS 安全性功能新增了一項強大的工具。過去系統管理員從未能夠利用現有 SMS 基礎結構，修補協力廠商與自訂應用程式。SMS R2 可說是修補管理員的福音。
所以從現在起，您有兩種工具可以處理非 Microsoft 的軟體更新。CUPT 和 ITCU 所提供的管理性與方便性，將確保您的自訂更新可以和現有的 Windows Update 一樣順利運作。
更新管理資源
  • TechNet：更新管理
  • 網路廣播：IT's Showtime - SMS 2003 R2
  • Microsoft 修補程式管理十大原則

Steve Rachui 在 Microsoft 的產品支援服務團隊中，擔任系統管理支援高階工程師 (Manageability Support Escalation Engineer)。他從 SMS 1.2 版就開始支援 SMS。Steve 的聯絡方式為 steverac@microsoft.com。


 編輯的話: 我們可能需要更正...
編輯的話
我們可能需要更正...

印刷品和網頁最大的差異， 就是印刷品一旦出版就無法進行修改。如果要更新放在網路上的資訊，則只需要上線修改檔案。這是最睿智的做法。
印刷品需要完全不同的處理方式。我們將資料送去印刷之後，就是一條不歸路。每次都會送出數十萬份的印刷品，而且其中的資訊將會一直在您的書架上保持不變，直到時間的永遠 (或者直到您要搬家而清理舊印刷品為止)。此外，印刷品呈現了漸進式的發展，您也知道最新的出版品會包含最新的新聞和文章。
現在我們在出版印刷品之後，也會將整個雜誌的內容放到網路上，但是這卻製造了新的問題。從進行線上搜尋的使用者的角度而言，所有網站上的內容都同時可供使用。但是，使用者如何才能知道他們檢閱的是否為最新的內容？
為了要解決這個問題，我們在數年前規劃了一項修訂政策，讓印刷品以及線上內容都能夠為讀者提供更優異的資訊。在 TechNet Magazine 更正頁面上，您將可以看到所有文章在出版後所做的修改以及相關說明。我們會將每一篇文章的更新歸類為下列五種原因之一：技術性 (Technical)、編輯性 (Editorial)、新資訊 (New Information)、時效性 (Out-Of-Date) 及安全性 (Security)。
舉例而言，在 2006 年 5 月出版的 Techniques for Simplifying Desktop Image Creation 文章中，曾經提及在出版時尚未上市的工具，稱為 CNIC。後來當 CNIC 上市之後，我們便在「更正頁面」中加入一項更新說明，同時在文章中加入「編輯性的更新 (Editor's Update)」並張貼在網路上。只要按一下該「編輯性的更新」連結，即可檢閱新增的資訊。
如您所見，雖然 TechNet Magazine 的印刷品每個月會由全新一期的雜誌取代，我們的修訂政策也能夠確保線上的所有文章都保持在最適用的狀態。-JOSHUA TRUPIN

感謝下列 Microsoft 技術專家： Luis Botero、Derek Del Conte、John Doyle、David Feldman、Scott Hinsley、Jesper Johansson、Brian Mohr、Michael Murgolo、John Orefice、Mark Russinovich、Matt Steele、Fergus Stewart、Jason Stolarczyk、Jim Truher 及 Alan von Weltin。


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

檔案和目錄的同步處理
Allway Sync
allwaysync.com

無論您從事哪種 IT 工作，可能都要花費許多時間在不同位置之間移動檔案和目錄，像是從桌面移至 USB 隨身碟或在網路上的伺服器之間移動。通常保持這些目錄間的同步狀態是很重要的，這樣可避免建立不必要的複本，而且也可以確保使用的是最新的檔案版本。有時候您可能需要同步處理多部機器上的檔案和目錄，譬如在一組 Web 伺服器上部署靜態 XML 或 HTML 檔案的情況。Usov Lab 推出的 Allway Sync 這項工具對於處理這些類型的工作非常好用。
Allway Sync 能夠真正提供 N-向的同步處理功能，從單向的檔案和目錄複製到多重目錄的雙向選項。這個應用程式不僅能讓本機磁碟與網路資源保持同步狀態，也支援卸除式裝置 (例如 USB 隨身碟和可重複燒錄光碟機) 的自動同步處理。您可以設定讓 Allway Sync 在裝置連接到電腦時自動啟動。
其他有關同步化的自動啟動選項還包括偵測到檔案變更時啟動、登入或登出時啟動、啟動 Allway Sync 時啟動，以及根據指定的時間間隔啟動。您甚至可以透過應用程式的 GUI，連結同步處理與排定的工作。
使用 Allway Sync 同步處理檔案和資料夾
使用 Allway Sync 同步處理檔案和資料夾
在應用程式的本機資料庫中，會追蹤所有檔案的修改和刪除動作，而且 Allway Sync 有許多選項可用來追蹤已修改檔案的版本以及刪除衝突的檔案，其中包括永久移除項目、將項目移至資源回收筒或移到指定的資料夾。
您可以針對每個工作指定多個包含或排除的篩選條件，藉此取得所需的檔案並忽略不需要的檔案。您可以自訂在出現警告或錯誤時，要 Allway Sync 執行的動作，並且針對每種警告或錯誤類型設定不同的動作。例如，您可以選擇在發生錯誤事件時自動重試複製動作，而且不只可以設定自動重試的次數，還可以設定重試間的延遲時間，以便配合網路延遲或短期的連線問題。
您可以設定應用程式記錄功能的冗贅 (Verbosity) 等級，以確保能收到有關工作的詳細資訊。應用程式設定可透過 XML 匯入及匯出，因此很容易備份這些設定或是將設定傳送到另一部電腦。此外，應用程式也提供一個有趣的功能，讓好奇的使用者可以檢視簡單的使用統計資料視窗 (從 [說明] 功能表存取)。這個方便的工具讓同步處理檔案的工作變得無比輕鬆，而且價格實在，很值得採用。
價格：個人使用免費。商業使用為 $29.99 美元。

對應和監視您的網路
LANState Pro
10-strike.com/lanstate

在主動式 IT 作業環境中，特別注重快速存取網路資源的狀態及可用性的能力。當問題發生時，您必須搶先一步知道這個消息。10-Strike Software 推出的 LANState Pro 是一項便利的網路對應工具和監視器，可為 Windows® 網路提供快速的視覺化效果與 LAN 管理功能。
啟用此應用程式以監視網路時，您可以選擇網路對應精靈 (Network Mapping Wizard)，它可讓您掃描網路上的芳鄰或相關主機的 IP 位址範圍。您也可以手動新增主機。一旦建立網路對應之後，LANState 會自動開始進行您設定的狀態檢查，例如 TCP 連接埠檢查或 ICMP Ping 檢查。有回應的主機會以顏色標示，而無回應的主機則會變灰色。接著您可以將對應安排至適合您組態的邏輯群組，也可以變更任何視覺元素和新增內容描述等等。
使用 LANState Pro 建立邏輯網路群組
使用 LANState Pro 建立邏輯網路群組
繪圖和編輯工具有點粗糙，但完成對應後，您可以將結果儲存到檔案，無須重新建立。除了 TCP 連接埠及 ICMP Ping 檢查之外，您也可以讓 LANState Pro 檢查資料夾或檔案是否存在、檔案大小，或是在設定的間隔與逾時的情況下，有多少可用的磁碟空間。以滑鼠右鍵按一下主機即可叫出內容功能表，您可以在其中看到更多遠端主機的系統資訊，還可以執行追蹤路由 (Trace Route)、傳送 Ping、執行預設檢查或傳送網路訊息。
系統資訊檢視所顯示的範圍從 NIC MAC 位址和繫結 IP 位置到網路共用、服務及本機帳戶，應有盡有。大部分的作業系統層級資訊都需要適當權限和遠端系統上有開放連接埠，不過您從 RPC 呼叫就可以獲得不少的資料。如果您具有相關權限，也可以傳送遠端開機和關機訊號到遠端主機。
價格：單一使用者授權為 $249.95 美元。

命令列指令碼
書評
www.syngress.com

互動式精靈和組態 GUI 的確可以簡化複雜的工作。但如果您是 IT 專業人員，這些介面反而會拖累您的速度，而且不一定會為手邊的工作提供足夠的細節或控制能力。幸好，使用命令列介面 (CLI) 往往都可以達到較細膩程度的控制能力。只要熟悉了 Windows 隨附的工具，並學會如何自訂命令提示來簡化管理工作，就能節省時間、提高效率和增強精準的控制能力。Pawan K. Bhardwaj 所著之 How to Cheat at Windows System Administration Using Command Line Scripts (Syngress Publishing，2006) 可協助您精通 CLI 和 OS 公用程式。
本書將引導您如何自訂命令 Shell 的作業，所採取的方法是使用批次檔進行自動化與批次處理，並使用排程工作的 CLI 管理功能。當您讀熟這些章節後，這本書便會介紹隨附在 Windows 作業系統中，可協助您管理磁碟、檔案和目錄的公用程式。您也將清楚認識 Directory Services 命令 (例如 DSQuery 及 DSMod) 的概觀，結合使用這些命令與前幾章所學的批次處理技巧，將可大幅節省管理大型目錄結構所需的時間。
您還會學到如何操控 Windows 網路命令 (從 Netstat 到 Pathping)，並熟悉遠端連線工具 (例如 TFTP、RSH 及 RCP) 的概觀。同樣地，結合使用這些工具與您在本書第一章所學的自動化及排程工作的技巧，一定能提高您的生產力。總而言之，雖然本書不算是完整的 Windows 公用程式參考書，但您會發現 Bhardwaj 的這本書對您助益良多。
價格：直接售價 $39.95 美元。

硬體可靠性測試
BurnInTest
passmark.com/products/bit.htm

無論您是從事訂製電腦的生產、正在執行用戶端的硬體元件更新，或只是要建置新的超級系統管理桌上型電腦裝置，在提供新元件給使用者之前，先確認這些元件的執行可靠性是很重要的。PassMark Software 推出的 BurnInTest 可以滿足這項需求，這個工具會針對您指定的元件執行多個不同的壓力測試，藉此確保交貨的元件不會發生失敗情況。
正如所有預燒 (Burn-In) 軟體測試一樣，應用程式會試著「操練」硬體，加重選定系統元件的負荷，利用這種方式來模擬在短時間內完成長活動週期的情況。其用意是在提供系統或裝置之前，預先發掘潛藏的錯誤。BurnIn Test 可讓您測試任何項目：從 CPU 及圖形卡記憶體到硬碟機和 CD 燒錄機。
使用和設定此應用程式的步驟很簡單，您可以變更特定組態中，各個元件單位測試的工作量 (Duty Cycle) 和喜好設定。設定好測試組態後，可以儲存您的喜好設定以供下次使用，如此可加快往後您需要再執行此測試作業的速度。
每個測試都有可設定的工作量 (Duty Cycle)，因此您可以為測試的各個元件設定從 1 到 100 的負載值。例如，您可以測試 CPU 數學運算在 75% 負載之下的效能，同時測試系統記憶體在 95% 負載之下的情況。您也可以讓 BurnInTest 在指定的分鐘數之後或運算週期之後停止。
此應用程式可讓您最多同時測試 20 個硬碟機、軟碟機和/或光碟機，因此您可以在送交這些硬體到用戶端環境之前，先進行這些磁碟機/光碟機的批次測試。在升級系統元件時，這個動作能夠節省非常多時間，因為您可以一次測試多個新元件，而無須個別測試每一部系統。我喜歡這個程式適用 SMART 參數檢查。
Professional Edition 支援 USB 2.0、平行埠及序列埠的各種回送測試 (硬體反向迴圈裝置可從 PassMark 購得)。這個 BurnInTest 版本可以從光碟機或 USB 隨身碟執行，如此一來，可減少應用程式對於所測試系統的影響，進而增添測試結果的公信力。
價格：Professional Edition 為 $49 美元；Standard Edition 為 $24 美元。

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


 SQL 問題與解答: 重建索引、磁碟佇列長度及其他
SQL 問題與解答
重建索引、磁碟佇列長度及其他
由 Nancy Michell 編輯

問：如何重建 SQL Server 索引？我想知道 DBCC DBREINDEX 為什麼佔用我所有的磁碟空間，以及當命令失敗時，為何沒有釋出空間。我的資料庫大小是 90 GB，而最大的資料表是 70 GB。
當我執行 DBCC DBREINDEX 時，DBCC DBREINDEX 佔用所有的可用磁碟空間，只剩下 10% 的可用空間，而且命令失敗。雖然起初的資料庫檔案是 90 GB，但是當 DBCC 命令失敗時，資料庫檔案成長至 160 GB，而且也未釋出額外的 70 GB；為了收回這些空間，我必須手動壓縮資料庫好幾次。
如果命令確實執行了，那麼資料庫檔案的大小仍是 160 GB，不過自動壓縮會在幾小時後自動釋出空間。我可不可以改用磁碟重組來取代 DBREINDEX 以減少佔用的空間呢？我沒有叢集索引，而且使用的是簡單復原模式。
答：簡單來說，索引可藉由建構一個新的索引複本，然後刪除舊索引來重建。這表示在短暫的一段時間內，基本上會同時存在索引的兩個複本。建構新索引所需的資料庫檔案空間與原始索引一樣多，此外，如果重建需要排序作業，則此排序作業還需要額外的 20% 的索引大小。
因此，在最糟的情況下，重建索引所需的空間是舊索引大小的 1.2 倍。萬一資料庫檔案的可用空間不足，檔案大小就必須隨著作業進行而成長。如果並未啟用自動成長，或是磁碟區上的空間不足，就有可能造成無法提供足夠的可用空間，此時重建作業便會失敗。
無論作業失敗與否，配置給資料庫檔案的額外空間在重建作業完成後都不會釋出。因為系統會假設這些空間將用於一般資料庫作業。
由於演算法的運作方式，執行壓縮 (手動或自動) 幾乎可保證一定會建立索引片段。如需詳細資訊，請參閱 SQL Server Storage Engine。如果資料庫需要可用空間來進行一般作業時，自動壓縮對於效能而言特別不利，因為您可能會落入反覆的自動成長和自動壓縮循環，這會造成分散程度及效能的極大破壞。
使用 DBCC INDEXDEFRAG (或 SQL Server™ 2005 中的 ALTER INDEX ... REORGANIZE) 的好處是，它幾乎不會使用額外的資料庫檔案空間，但是可能需要花較長的時間，而且會產生比索引重建多出許多的交易記錄。無論使用什麼復原模式，都一定會完整記錄 DBCC INDEXDEFRAG，而索引重建在簡單復原模式下卻會使用大量記錄。每種方法的優缺點各有不同，詳盡內容請參閱 SQL Server Index Defragmentation Best Practices 白皮書。
在決定要如何修復分散問題之前，應先確認是否需要修復分散。視使用索引的作業類型而定，分散可能根本不會影響到效能，因此進行修復只是浪費資源。上述白皮書會提供更深入的解析。
重點：確認選擇最適合您環境的移除分散方法，而且移除分散的確有助於查詢效能。

問：我已經成功在兩個 SQL Server 2005 執行個體之間設定資料庫鏡像。我的應用程式是使用 SQL Server 登入來連接到 SQL Server，並且是使用 ADO 與 SQL Native Client 建置而成。我的連接字串和連接設定指定正確的資訊，包括適當的容錯移轉夥伴。我也在鏡像伺服器上建立了與主體伺服器一樣的所有相同登入。在測試資料庫失敗時，鏡像順利擔任起主體角色，而且 SQL Server 執行個體看起來一切正常 (我甚至都能使用自己的 Windows® 登入連接到鏡像)。但是，應用程式重新連線時會失敗並出現下列錯誤：
Cannot open database "<db name>" requested by the login. The login failed.
登入似乎並未與新的主體 (原本的鏡像) 資料庫中的使用者建立關聯。我執行 sp_change_users_login 來同步處理資料庫的使用者與登入，結果出現的訊息說明已經修復多個被遺棄使用者。接著我的應用程式就能順利重新連線到新的主體伺服器。我試了好幾次容錯移轉，每次都出現相同的行為模式 -- 登入與使用者之間的關聯會遺失。
有沒有辦法能夠設定鏡像又不會發生這個問題呢？
答：有的。問題的原因在於，雖然登入名稱相同，但每部伺服器上的 SQL Server 登入的安全性識別元 (SID) 並不相符。這對 Windows/網域使用者/群組的登入不會有影響，因為這些登入的 SID 是根據使用者/群組的網域 SID 而建立，因此無論將使用者/群組新增到哪個 SQL Server，同一個特定使用者/群組的 SID 也會一樣。
若要免除 sp_change_users_login 同步處理這個步驟，您在鏡像伺服器上建立的 SQL Server 登入不僅需要使用相同名稱，而且還要使用與主體伺服器上一樣的 SID。您可以在鏡像伺服器上建立登入時使用 CREATE LOGIN 陳述式中的 SID 規格來完成這項作業，如下所示：
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
藉由查詢 sys.sql_logins 目錄檢視，即可讓您從主體伺服器擷取每個登入的 SID。[圖 1] 顯示的查詢範例，會針對指定伺服器上的每個 SQL Server/Windows 登入，產生實際的 CREATE LOGIN 陳述式。
Figure 1 產生 CREATE LOGIN 陳述式 (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

問：我的平均磁碟佇列長度應該是多少？例如，假設存放區域網路 (SAN) 上有 20 個獨立的實體磁針且使用 RAID 01 設定，這樣該如何計算平均磁碟佇列長度？計算方式應該是平均磁碟佇列長度除以 20 或平均磁碟佇列長度除以 2？
答：首先，您應該先檢查磁碟延遲，而不是花時間計算 SAN 環境中的平均磁碟佇列長度。但實際情況還是端看您想要的是什麼。原因馬上揭曉。
這個計數器 (來自 Perfmon) 的說明如下：「平均磁碟佇列長度是指在取樣間隔期間，針對選定磁碟佇列的讀取和寫入要求兩者的平均數目」。這可以是實體磁碟或邏輯磁碟計數器，因此您取得的數字會視提供基礎儲存體給作業系統的方式而定。
讓我們來看看您的情況。您在 RAID 01 設定中有 20 個磁針，這表示他們已經過等量和鏡像處理 (或是先鏡像再等量處理，實際情況取決於 01 或 10 的讀取方式而定)。您的存放陣列的關鍵點在於，等量磁碟區中有 10 個磁針。
但是我缺乏一些關鍵資訊，例如等量大小、寫入大小，以及您發出的 I/O 類型 (讀取、寫入、循序或隨機)。
暫且不管這些遺漏的資訊，如果平均磁碟佇列長度顯示 10，那麼作業系統便會佇列 10 個 I/O 到磁碟陣列。理論上，可能是一個 I/O 分別到等量中的 10 個鏡像集，也可能是 10 個 I/O 全都到同一個磁碟。您無法得知實際情況究竟如何。
這也就是為什麼需要那些遺漏的資訊。假設您的等量大小是 64 KB，寫入大小是 8 KB，而且您打算進行大量的循序寫入。這是典型的 SQL Server 儲存活動情況。此時，很有可能其中八個 I/O 都進入第一個磁碟，而其餘兩個 I/O 則進入下一個磁碟。因此，如果您試著算出這個案例中每一磁碟的磁碟佇列長度，則第一個磁碟是 8，第二個磁碟是 2，至於陣列中其餘八個磁碟則是 0。
現在讓我們改變這個案例的條件，假設等量大小是 8 KB，寫入區塊大小是 64 KB，並且讓磁碟佇列程度保持為 10。此時，各個 64 KB 區塊會分散到 8 個磁碟上，因此一個 I/O 會寫入 8 個磁碟，而 10 個佇列的 I/O 會以 80 個磁碟寫入，分散在陣列中所有的 10 個磁碟上。若您想要計算陣列中各個磁碟的磁碟佇列長度，結果會是陣列中的每個磁碟分別為 8。
讓我們務實一點，將另一層不確定因素加入這個討論中。在大部分的情況下，SAN 儲存體會使用以下工具來連線到伺服器：伺服器中的一或多個 HBA、連接 HBA 與 SAN 的一些光纖、SAN 前端的一些連接埠，可能還會在伺服器與 SAN 之間的光纖中使用某種光纖交換器。接著涉及到 SAN 內匯流排的內部架構，以及磁碟如何連接至 SAN 前面的連接埠。
您在 Perfmon 中看到的任何佇列，都可能是高度延遲的徵狀，也可能表示在作業系統測量其磁碟佇列長度與資料寫入磁碟表面之間，在各點上的佇列。這就是為什麼您應該檢查延遲，並且根據此延遲數據而非平均磁碟佇列長度來做決定。

問：我使用交易式複寫，我知道在訂閱者端的資料表中，有很多資料列被手動變更，因此，當發行者嘗試更新在訂閱者中已經不存在的資料列時，我便會收到錯誤。
我需要知道有沒有辦法透過複寫，只重新初始化發行者的這一個資料表，而不要再重新套用整個快照集。我研究了一下 tablediff 函式，發現它似乎可以執行我所需的工作，但我還想知道這個函式如何與複寫互動。
例如，tablediff 是否會擷取發行者資料表的即時快照 (snapshot-in-time)，然後比較此快照與訂閱的對等部分？此外，我是否需要停止複寫，以便使用 tablediff 公用程式來確保資料一致性？還有什麼我必須注意的？
答：首先，tablediff 並不會照實擷取發行或訂閱資料表的快照。就您的特定情況來看，有幾個方案可以參考。
第一個就是暫時停止複寫，並執行公用程式。如果您擔心使用者嘗試修改資料，可以使用 -sourcelocked 和 -destinationlocked 參數，這兩個參數會在公用程式的執行期間，對雙方資料表採取獨佔鎖定。如果不願意這麼做，另一個選擇是查看 -rc 和 -ri 參數，並保持複寫的執行。這樣會執行一次 tablediff，然後在偵測到錯誤時連續執行 tablediff，以排除可能因複寫傳播延遲而產生的錯誤。但是套用此方法時請小心，視您的複寫延遲而定，可能會無法擷取所有在訂閱者端變更的資料列。

感謝下列 Microsoft IT 專家的技術協助： Sunil Agarwal、Chad Boyd、David Browne、Gilles Comeau、Emmanuel Dreux、Amanda Foote、Matt Hollingsworth、Paul Mestemaker、Uttam Parui、Paul Randal、Dennis Tighe 及 Steven Wort。


 公用程式焦點: Autoruns
公用程式焦點
Autoruns
Lance Whitney
下載本文程式碼: Autoruns (490KB)

執行 Windows® 的一般個人電腦會在開機時載入各種項目，包括檔案、驅動程式、工作及服務。有時候，您很可能需要檢視或停用某些啟動項目，以便疑難排解啟動衝突、依照自動啟動順序追蹤惡意程式碼、縮短 Windows 啟動時間，或是釋放記憶體和系統資源。
系統設定公用程式 (msconfig.exe) 可讓您檢視和停用一些啟動檔案和服務，但還是有不少它無法管理的項目：工具列、瀏覽器協助程式物件、Windows Explorer 殼層延伸。而且，msconfig 無法提供關於這些項目的詳細資訊。若要尋找更好的方法來檢視及管理啟動時載入的所有項目，不妨考慮 Sysinternals 推出的 Autoruns。
由 Mark Russinovich 和 Bryce Cogswell 共同撰寫的 Autoruns 是一個免費的公用程式，它能顯示執行 Windows 的 PC 上的所有啟動項目 (亦稱為映像)。您可以檢視儲存在啟動資料夾、登錄和其他可能隱藏映像之區域中的所有映像 (請參閱 [圖 1])。
圖 1 使用 Autoruns 檢視啟動項目
圖 1 使用 Autoruns 檢視啟動項目
Autoruns 會顯示每個映像的名稱與位置。如果是檔案，它會顯示目錄路徑；如果是登錄項目，則會顯示特定的機碼。Autoruns 也提供發行者名稱，以及以項目版本資料為主的簡短描述。按兩下項目即可開啟其目錄或登錄機碼；按一下滑鼠右鍵則會開啟包含更多選項的快顯功能表，包括 [內容 (Properties)] 命令，這個命令會顯示內含完整版本資訊的標準 [檔案內容 (File Properties)] 視窗。[包含空的位置 (Include Empty Locations)] 這個選項可顯示 PC 的所有啟動區域，無論目前其中是否有任何項目。您也可以選取 PC 上的其他使用者帳戶，來查看其啟動環境。
您可以利用 [確認 (Verify)] 命令來檢查項目的數位簽章，這個命令會查詢網站的憑證撤銷清單 (CRL)，藉此確定映像是否經過數位簽章，以及簽章是否有效。另一個 [隱藏已簽署的 Microsoft 項目 (Hide Signed Microsoft Entries)] 選項則會排除已經由 Microsoft 簽署的項目，好讓您專心檢查其他廠商的映像。
整份啟動項目清單可以匯出到文字檔 -- 如果您想要停用項目，並且需要環境變動啟動之前的快照，這個功能就很實用。您可以藉此比較匯出的文字檔與修改過的啟動設定，以檢視變更情況。
以下是 Autoruns 包含的其中一些啟動類別：
登入 包括使用者與所有使用者的啟動資料夾，以及在登錄中找到的執行 (Run) 機碼。
檔案總管 包括檔案總管殼層延伸、工具列和 Active Setup 設定為執行的清單。
Internet Explorer 包括瀏覽器協助程式物件和 Internet Explorer® 的工具列及延伸。
LSA 提供者 包括本機安全性授權 (Local Security Authority，LSA) 驗證、通知及安全性封裝。
在 Autoruns 中，您可以永久刪除某個啟動項目，也可以只停用它。[線上搜尋 (Online Search)] 選項會協助您尋找可以安全停用的項目。這個選項會在網際網路上搜尋描述項目或類別的網頁，並建議您是否可從啟動中移除該項目或類別。當您停用項目時，Autoruns 會將該項目移至登錄或硬碟中的備份位置。
Autoruns 可以在所有 Windows 版本之下執行，包括 64 位元版本的 Windows XP 和 64 位元版本的 Windows Server® 2003。歡迎至 microsoft.com/technet/technetmag/code07.aspx 下載。

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


 The Cable Guy: Windows Vista 的無線群組原則設定
The Cable Guy
Windows Vista 的無線群組原則設定
Joseph Davies
此專欄中所包含的 Windows Server "Longhorn" 測試版相關資訊有可能變更。

身為系統管理員，若能集中設定並散佈無線網路設定到 Active Directory 網路中的所有電腦上，您的工作或許會輕鬆一些。好消息，Windows 可支援用於電腦組態設定的特殊群組原則延伸模組，正好可以達到上述目標。這
稱為無線網路 (IEEE 802.11) 原則延伸模組，執行 Windows Vista™、Windows® XP、Windows Server® 2003，以及代號為 "Longhorn" 的最新 Windows Server 版本等系統的電腦，皆可支援此延伸模組。
以下是它的運作方式。不論是要加入網域的電腦，或者是在您啟動電腦的時候 (之後每次啟動時仍會持續使用設定)，上述作業系統都會自動下載並套用此群組原則延伸模組中的無線網路設定。您可以從下列群組原則物件編輯器嵌入式管理單元的節點，設定網域群組原則物件的無線網路原則：[電腦設定] | [Windows 設定] | [安全性設定] | [無線網路 (IEEE 802.11) 原則]。
[圖 1] 顯示代號為 "Longhorn" 的 Windows Server 網域或 Windows Server 2003 網域之無線網路 (IEEE 802.11) 原則節點的位置，其中的架構已使用 802.11Schema.ldf 和 802.3Schema.ldf 架構延伸檔案進行延伸 (詳細說明位於 microsoft.com/technet/network/wifi/vista_ad_ext.mspx)。
圖 1 無線網路 (IEEE 802.11) 原則節點
圖 1 無線網路 (IEEE 802.11) 原則節點
根據預設，系統沒有無線網路 (IEEE 802.11) 原則。若要建立新原則，請用滑鼠右鍵按一下主控台樹狀目錄中的 [無線網路 (IEEE 802.11) 原則]，然後按一下 [建立新的 Windows XP 原則]，或者按一下 [建立新的 Windows Vista 原則]。針對每一種原則類型，您只能建立單一原則。但每個原則中可以包含多重無線網路設定。
Windows XP 原則的原則設定，與我之前在 2003 年 7 月份專欄中所描述的內容十分相似。不過非廣播式無線網路、Wi-Fi 保護的存取 2 (Wi-Fi Protected Access 2，WPA2) 驗證方法，以及 WPA2 驗證的快速漫遊設定，都有新的選項可用。若要支援這些新設定，執行 Windows XP Service Pack 2 (SP2) 的電腦必須安裝 Windows XP SP2 的無線用戶端更新程式，這可從下列網址下載：support.microsoft.com/kb/917021。
Windows Vista 無線原則包括 Windows Vista 和 Windows Server "Longhorn" 無線用戶端專屬的原則設定。若這兩種無線原則類型皆已完成設定，則 Windows XP 無線用戶端以及 Windows Vista 無線用戶端都僅會使用各自的原則設定。若 Windows Vista 的原則設定不存在，Windows Vista 無線用戶端就會使用 Windows XP 的設定。本文說明可以利用 Windows Vista 無線原則進行設定的項目。
在 Windows Vista 無線網路原則的 [一般] 索引標籤上，您可以設定原則的名稱和描述，指定是否啟用 WLAN AutoConfig 服務，並以喜好的優先順序列出與設定無線網路設定檔及其中的設定項目 (請參閱 [圖 2])。您也可以選取設定檔並按一下 [匯出]，將設定檔匯出為 XML 檔案。若要匯入 XML 檔案做為無線設定檔，請按一下 [匯入] 並指定檔案位置。
圖 2 無線網路原則內容
圖 2 無線網路原則內容
[圖 3] 顯示 Windows Vista 無線網路原則的 [網路權限] 索引標籤以及其中的預設設定。此索引標籤是 Windows Vista 的新功能，可讓您依名稱指定無線網路，並可允許或拒絕這些網路的存取。例如，您可以建立包含無線網路名稱的允許清單，又稱為服務組識別元 (SSID)，其中皆為允許 Windows Vista 無線用戶端連接的無線網路。對於需要管理組織內的筆記型電腦能夠連接之特定無線網路集合 (其中可能包括組織的無線網路以及網際網路服務提供者) 的網路管理員而言，這項功能非常好用。
圖 3 [網路權限] 索引標籤
圖 3 [網路權限] 索引標籤
使用拒絕清單，即可以根據名稱指定不允許無線用戶端連接的無線網路集合。這可以有效防止受管理的筆記型電腦連接到其他在接收範圍內的無線網路，例如當組織位於大樓中某一層樓，而毗鄰樓層的其他組織也有使用無線網路。您也可以使用拒絕清單，有效防止受管理的筆記型電腦連接到已知的不安全無線網路。若要建立清單，或者要指定允許或拒絕個別無線網路，請按一下 [新增] 以依名稱加入無線網路，然後指定允許或拒絕該網路的存取。
在 [網路權限] 索引標籤上，亦有可防止連接到臨機操作或基礎架構模式之無線網路的設定。您也可以允許使用者檢視已設定為拒絕的無線網路清單，並且讓任何使用者建立所有使用者設定檔。所有使用者設定檔可用來讓任何具有電腦帳號的使用者，連接到特定的無線網路上。若停用此設定，則只有 Network Administrators 群組或 Network Operators 群組可以在電腦上建立所有使用者無線設定檔。

無線網路設定檔內容
若要從 Windows Vista 無線原則的 [一般] 索引標籤管理無線網路設定檔，請選取現有設定檔並按一下 [編輯] 或 [新增]，然後指定新的無線設定檔是否為臨機操作或基礎架構模式的無線網路。
若要建立新的無線設定檔，請先在 [連線] 索引標籤上命名設定檔，再建立適用的無線網路清單 (請參閱 [圖 4])。您可以在 [網路名稱 (SSID)] 中輸入名稱並按一下 [新增]，以加入新名稱。您也可以指定使用此設定檔的無線用戶端是否可以在進入接收範圍內時，自動嘗試連接到設定檔中所列出的無線網路 (這還要視 Windows Vista 原則中 [一般] 索引標籤的無線設定檔清單喜好順序而定)。此外，您可以指定如果接收範圍內出現優先順序更高的無線網路，是否要自動中斷目前的無線網路，以及指定此設定檔的無線網路是否為非廣播網路 (亦稱為隱藏網路)。
圖 4 [連線] 索引標籤
圖 4 [連線] 索引標籤
在 [安全性] 索引標籤中 (如 [圖 5] 所示)，您可以設定該設定檔的無線網路驗證和加密方法。加密方法會視您選擇的驗證方法而定。每一種方法的選項均列於 [圖 6] 中。
Figure 6 安全性方法 (Close Figure 6)

驗證方法
Open
Shared
Wi-Fi Protected Access (WPA)-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Open with 802.1X
加密方法
Wired Equivalent Privacy (WEP)
Temporal Key Integrity Protocol (TKIP)
Advanced Encryption Standard (AES)
圖 5 [安全性] 索引標籤
圖 5 [安全性] 索引標籤
若您選取 WPA-Enterprise、WPA2-Enterprise 或者 Open with 802.1X 作為驗證方法，您也可以設定網路驗證方法 (可延伸的驗證通訊協定 [EAP] 類型)、驗證模式 (使用者重新驗證、電腦驗證、使用者驗證或來賓驗證)、放棄驗證之前允許嘗試驗證的失敗次數，以及是否為後續連線快取使用者資訊。最後一項設定會指定當使用者登出時，使用者認證資料即自登錄中移除。如此一來，當下一位使用者登入時，提示中才會要求輸入認證資料 (例如使用者名稱和密碼)。
若要設定 WPA-Enterprise、WPA2-Enterprise 或者 Open with 802.1X 的進階安全性設定，請按一下 [進階]。[圖 7] 顯示預設進階安全性設定的對話方塊。
圖 7 進階安全性設定對話方塊
圖 7 進階安全性設定對話方塊
在 IEEE 802.1X 區段中，若初始 EAPOL-Start 訊息沒有回應時，您可指定已傳送 LAN (EAPOL)-Start 訊息的後續 EAP 數量；而在之前傳送的 EAPOL-Start 訊息沒有回應時，您可指定重新傳輸 EAPOL-Start 訊息的時間間隔。您也可以設定驗證用戶端從驗證者收到驗證失敗指示之後，驗證用戶端無法執行任何 802.1X 驗證活動的時間，以及在起始端對端 802.1X 驗證程序之後，驗證用戶端重新傳輸 802.1X 要求之前必須等待的時間間隔。
單一登入 (SSO) 可讓您設定使用者登入與 802.1X 驗證的相對時機，並且在 Windows 登入伺服器上整合使用者登入與 802.1X 驗證認證。在 SSO 區段中，可以設定於使用者登入程序之前或之後立即執行無線驗證，並於程序開始前指定連線延遲的秒數。若驗證方法需要使用者輸入其他認證資料，您也可以指定是否要提示使用者在其他欄位中輸入資料，以及顯示這些欄位的時間長度，並決定此設定檔的無線網路是否針對電腦或使用者驗證使用不同的虛擬 LAN (VLAN)。
在快速漫遊區段中，您可以設定成對主鑰 (PMK) 快取以及預先驗證選項。快速漫遊區段只有在選取 WPA2-Enterprise 作為驗證方法時才會出現。使用 PMK 快取時，無線用戶端和無線存取點 (AP) 會快取 802.1X 驗證結果。因此，當無線用戶端漫遊回到用戶端已通過驗證的無線 AP 時，存取速度會更快。您可以設定 PMK 快取中保留項目的時間上限，以及要保留的項目數量上限。使用預先驗證時，無線用戶端可於接收範圍內的其他無線 AP 先執行 802.1X 驗證，同時保持目前無線 AP 的連線狀態。若無線用戶端漫遊至已預先驗證的無線 AP，則會大幅減少存取時間。您可以設定嘗試預先驗證無線 AP 的次數上限。
如需 Windows 無線支援的詳細資訊，請參閱 microsoft.com/wifi。如需 Windows 群組原則的詳細資訊，請參閱 microsoft.com/gp 網站所提供的資源。

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


 Windows PowerShell: 資料的篩選與格式化
Windows PowerShell
資料的篩選與格式化
Don Jones

毫無疑問地，您不必花費太多心力，Windows PowerShell 就能傳回許多寶貴的資訊。例如，以簡單的 Get-WMIObject Cmdlet 為例，這個 Cmdlet 可用於傳回本機電腦上的服務清單。預設檢視中會列出正在執行之服務的狀態、名稱及啟動模式，
這基本上是 [服務] 主控台的命令列檢視。Windows PowerShell™ 只是讓它更容易使用。
不過除了預設檢視中顯示的內容之外，還有其他許多可供服務使用的實用資訊。試試執行以下的命令：
$s = get-wmiobject win32_service
$s[0] | gm
命令的第一行會傳回所有服務的集合 (或者更具體地說，Windows® Management Instrumentation (WMI) 中 Win32_Service 類別的所有執行個體)，並將其儲存在 $s 變數中。第二行會取得集合中的第一個服務 (序數零，在方括弧中指示)，並透過管線傳送到 Get-Member Cmdlet (我使用其別名縮寫：gm)。產生的輸出會顯示該資料類型可用的所有屬性和方法。我決定使用 WMI 中的 Win32_Service 類別，而非 Windows PowerShell 中的內建 Get-Service Cmdlet，因為 WMI 實際上比 Microsoft® .NET ServiceController 物件顯示更多的資訊，包括 StartName 屬性。該屬性會告訴我執行服務之使用者帳戶的名稱。您可以如下所示檢查單一執行個體的名稱，例如第一個：
PS C:\> $s[0].StartName
LocalSystem
不過，根據服務在集合中的序數來參照服務，並不是很實用的方法，因為服務並非以任何特定順序排列 (服務通常是照字母列出，不過並非一律如此)。就管理的觀點而言，您最感興趣的應該是所有服務的清單，以及用來登入服務的每個帳戶。這很方便進行如相容性稽核的作業。所以我們先來看看 WMI 預設提供的內容。我會使用 Get-WMIObject 簡短的別名：gwmi (請參閱 [圖 1])。
Figure 1 使用 gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
這很明顯只是一個範例，不過您可以看到輸出並不是很適合管理報告。我想要知道的是服務的名稱和 StartName，也就是執行服務的帳戶。我也希望報表的格式更容易閱讀，而不是像這種不容易讀的清單。這就是 Windows PowerShell 傑出的格式化與資料篩選 Cmdlet 發揮作用之處。

取得您需要的資料
我要先從篩選 Get-WMIObject 中的資料開始，以便顯示我想要的屬性。完成這項工作的最佳方式，是使用 Windows PowerShell Select-Object Cmdlet 或其簡單的別名：select。Select 的設計是要接受物件的集合 -- 例如 Get-WMIObject 傳回的集合，並且只顯示這些物件中我們想要的屬性。這表示我可以透過管線傳送 gwmi 的輸出到 select，並指定我想要的兩個屬性。[圖 2] 顯示此結果，其中包含已格式化為表格的 Name 和 StartName 屬性。
圖 2 在表格中只檢視 Name 和 StartName 屬性
圖 2 在表格中只檢視 Name 和 StartName 屬性
但是，如果我是為了相容性稽核產生這份報表，那麼包含的資訊就太多了。有些服務已停用，因此對閱讀輸出的人來說，停用的服務理論上使用哪個帳戶並不重要。所以，我要排除啟動類型為 Disabled (停用) 的所有服務，這是 Win32_Service 類別的 StartMode 屬性。
Windows PowerShell 會使用 Where-Object Cmdlet 或其簡短別名：where，來執行物件的篩選。Where Cmdlet 會接受輸入物件的集合，並且在 ScriptBlock 中評估每一個物件，以根據定義的準則決定每個物件是否應在 Cmdlet 的輸出中顯示。符合準則的每個物件會產生一個 True 比較，並包含在輸出中；產生 False 值的物件則不會包含在內。
因此，我決定我只想要其 StartMode 屬性等於 Disabled 的物件。以 Windows PowerShell 的表現方式，評估的程式碼如下所示：
$object.StartMode –eq “Disabled”
當然，$object 只是一個例子。我並非真的在撰寫指令碼，所以沒有名為 $object 的變數。不過，在 where 使用的 ScriptBlock 中，我確實使用了名為 $_ 的特殊變數，該變數代表 Cmdlet 目前正在評估的物件。因此我的 where ScriptBlock 看起來可能如下：
$_.StartMode –eq “Disabled”
要測試它很容易：
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
當然，此一快速測試的輸出會恢復以預設清單的樣式顯示。而且為了節省空間，我在這裡只包含一個服務。但是您會注意到，此輸出和我要的結果是顛倒的。我包含了停用的服務，而非排除這些服務。這是因為我的 ScriptBlock 顛倒了：我必須包含 StartMode 不等於 Disabled 的所有服務，如以下修改過的範例所示：
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
這樣好多了！即然輸出只包含我真正有興趣的服務，我可以再次透過管線將輸出傳送至 select，並且只指定我想要的屬性：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
透過管線從某個 Cmdlet 傳送資料至另一個，再到另一個 Cmdlet 的此一動作，真正說明了 Windows PowerShell 的功能。我仍然沒有撰寫指令碼，不過我已在很大的資料集內篩選出我想要的輸出。

正確的外觀
您應該記住 select 的輸出只是一群物件。當我使用 Windows PowerShell 擷取已適當格式化的表格時，實際上是 PowerShell.exe 在呈現這些物件。換言之，Windows PowerShell 知道我 (只是人類) 看不到物件，因此它以文字來呈現物件。在此情況下，它會將物件呈現為表格，每一欄顯示一個屬性，如 [圖 2] 中所示。
這對我的稽核用途已經足夠。但是也可能不夠。每個人都有不同的需求，而 Windows PowerShell 並無法知道您的特定需求為何。於是會提供您工具，讓您以最適合的方式將輸出格式化。其中有四個內建的 Cmdlet -- Format-List、Format-Custom、Format-Table 及 Format-Wide -- 這些 Cmdlet 的設計是要接受物件的集合 (例如 select 傳回的集合)，並以各種方式將這些物件格式化。Format-Table 基本上是 Windows PowerShell 已用來將我的 select Cmdlet 輸出格式化的 Cmdlet。為了呈現不同的外觀，讓我們試試 Format-List：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
結果有點像這個範例：
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
根據預設，Format-Wide Cmdlet 的設計是要產生每個物件之第一項屬性的多欄清單。以這一行為例：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
它會產生服務名稱的清單，這不是我要的。輸出缺少 StartName (請參閱 [圖 3])，這是我的稽核報表中需要的一項重要資訊。
圖 3 使用 Format-Wide Cmdlet 顯示的輸出缺少重要資訊 -- StartName
圖 3 使用 Format-Wide Cmdlet 顯示的輸出缺少重要資訊 -- StartName
因為我只處理兩個屬性，所以不論是 Format-Table 或 Format-List 都是可接受的。但是，稽核者並不會樂於在畫面上看此一資訊。她很可能比較容易接受其他檔案類型。

匯出資料
那麼稽核者可能想要如何檢視資料呢？將服務清單和登入名稱輸出至 CSV (逗點分隔值) 檔案應該就夠了，因為接著可以很容易在 Microsoft Excel® 中開啟檔案。若要建立 CSV 檔案，只要透過管線將輸出傳送至 Windows PowerShell Export-CSV Cmdlet 即可：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
當然，在今日的環境中，CSV 似乎有點過時了。可能您的稽核者會希望以內部伺服器上的網頁來顯示資料。若要使用此方式，請先利用 ConvertTo-HTML Cmdlet 將輸出轉換為 HTML：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
原始的 HTML 很難檢視，因此您必須將輸出寫入檔案：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
在 [圖 4] 中顯示的結果是正確格式化的 HTML 網頁，不需修改就能發佈到任何 Web 伺服器上。
圖 4 以格式化的 HTML 網頁顯示的輸出
圖 4 以格式化的 HTML 網頁顯示的輸出

只要恰當的資訊
Windows PowerShell 可以讓您快速存取各種的管理資料。但是，原始資料不一定有實用的商業意義。
藉由篩選資料 (使用 where)、選擇所要的物件屬性 (使用 select)，以及套用適當的格式化選項 (例如 Format-Table 或 Format-List)，即可輕鬆且快速地將此管理資料轉換為有用的資訊。然後，將資料匯出成容易共用的檔案格式，就可以將此資訊傳送到您的桌面以外的地方，與您組織中的其他人交流這些寶貴的資訊。

Don Jones 是 SAPIEN Technologies 的專案與服務總監，也是 Windows PowerShell:TFM (SAPIEN Press) 的作者之一。請透過 Don 的網站連絡他：www.ScriptingAnswers.com。


 嗨，Scripting Guy！: 輕鬆自在管理本機使用者和群組
嗨，Scripting Guy！
輕鬆自在管理本機使用者和群組
Microsoft Scripting Guys
下載本文程式碼: HeyScriptingGuy2007_04.exe (151KB)

我要如何管理檔案和資料夾中的安全性描述元？

您相信嗎， 過去 (當然是很久很久以前)，Scripting Guy 也曾經沒這麼聰明。我們知道這令人難以置信，但是...您說什麼？沒那麼難相信？還有，您說沒那麼久以前是什麼意思？好，讓我來解釋清楚。顯然您看到的是其中一位 Scripting Guy 作者前幾天在安裝新電視時所發生的窘境啦。
不過根據他的說法，這位 Scripting Guy 辯稱安裝新的電視並不是火箭科學；事實上這遠比火箭科學還複雜許多。接上電視機就需要三條視訊纜線和一對音訊纜線；除此之外，您還要接上 VCR、DVD 播放機和 Xbox®，而且還得輸入好幾組「萬用」遙控裝置的設定碼，才能一併控制上述所有器材。比較起來，要在火星運行軌道上架設衛星實在太簡單了。
厲害的是，Scripting Guy 確實地把所有連接線都正確裝上了。不過當他開啟所有器材時，卻沒有任何反應。他盡責地再三重複確認每一條連接線，還閱讀了所有使用手冊，甚至上網確認是否有遺漏的資訊，但卻完全找不出問題。正當他打算奉獻一台 MP3 播放機給電子之神以求神助時，他突然發現自己忘了最重要的步驟：就是把視訊盒上的訊號線接到牆上的插座。
請注意： 您或許認為，連接 Scripting Guy 家中的器材之所以如此困難，或許是因為他的器材太多了。事實上，這位 Scripting Guy 也同意這樣的說法。不過 Scripting Guy 每次家中投票決定是否要添購更多東西時，他都以 2-0 的票數被駁回。沒錯，不是 2-1，是 2-0。基於某些因素，在 Scripting Guy 的家庭中，老爸的票總是無法計入，而且連申訴的管道也沒有。
回答您的下一個問題：是的，他努力過了。但目前為止，聯合國仍拒絕派遣選舉監察員到 Scripting Guy 的家。
當然，現在回想起來，Scripting Guy (尤其是那位安裝新電視的) 並不是笨，而是太天真。例如，在他們規劃 Microsoft® Windows® 2000 Scripting Guide 時，就針對書的章節設計方式向多位專家詢求協助。其中一個未獲青睞的章節，是有關如何管理本機使用者和群組。「管理本機使用者和群組？!」專家這麼回答。「為什麼要考慮這個問題？誰會在乎如何管理本機使用者和群組？」
事實上，我們對此決定十分懊惱，因為我們後來發現每個人 (除了公司內部的「專家」們之外) 都十分重視本機使用者和群組。我們每週都會收到大量的電子郵件，詢問如何在本機群組內新增使用者、如何從本機群組刪除使用者，以及如何變更電腦上本機系統管理員的密碼。
雖然 Script Center 的指令碼存放庫確實有某些範例指令碼可示範如何執行這些作業，但大多數的指令碼都僅能針對單機作業。這還不夠好：大家還想知道如何在多部機器上同時運作。只在一部電腦上變更本機系統管理員的密碼嗎？實際點吧，各位 Scripting Guy -- 我們希望作業能夠一次套用到所有電腦、組織單位中的所有電腦、或者是所有郵件伺服器上，甚至於...您懂了吧。
別忘了，事實上 Scripting Guide 早在 2003 年發行，意思是說，我們已經有近四年的時間受到相同電子郵件訊息的圍剿發問。某位 Scripting Guy 最近也表示，「有另一位讀者詢問如何才能在 Excel® 試算表中讀取電腦名稱，並且變更每部電腦上的本機系統管理員密碼，我們到底該怎麼做才能解決這個問題？」
我們花了四年的時間，終於找出答案。[圖 1] 顯示出確切的解決方法。
Figure 1 我們終於找出答案 (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
請注意： 如您所見，我們之所以花四年的時間才完成這份指令碼，並不是因為很難寫，而是因為我們在做任何事情時，都需要花這麼多的時間才能完成。這就是為什麼您絕對不容錯過 Scripting Guy 的新年派對，畢竟您永遠不知道明年的派對何時才會舉行，甚至是否有機會舉行。
這個指令碼可以從試算表中取得電腦名稱，然後變更每部電腦上的本機系統管理員密碼。若要執行這項神奇的功能，我們從最簡單的方式開始，先假設您的試算表十分簡單、規模不大，如 [圖 2] 所示 (如果沒有試算表，請現在建立)。
圖 2 需要更改密碼的電腦清單
圖 2 需要更改密碼的電腦清單
如圖所示，這並無特別之處。在第 1 欄 (欄 A) 中，我們列出所有需要變更密碼的電腦名稱。在第 2 欄 (欄 B) 中，我們僅追蹤每部電腦最後一次變更系統管理員密碼的日期和時間。這樣就可以讓您輕鬆地監控系統管理員密碼是否全部一致。
至於指令碼本身，我們先使用 On Error Resume Next 陳述式。我們通常不會在指令碼中包括錯誤處理方式。這並不是因為我們反對錯誤處理；而是因為我們都儘可能將指令碼維持在最簡短、易懂的狀態。不過在此情況下，有必要使用 On Error Resume Next 陳述式。畢竟我們的指令碼將會嘗試連接多部不同的電腦。如果其中有一部電腦已關機，您知道會發生什麼後果嗎？反正只要有錯誤處理程序，就不會有問題。當然，雖然會產生錯誤，但指令碼可以不理會這些錯誤，並繼續執行。如果沒有錯誤處理，結果就會像 Scripting Guy 第一次打開新電視一樣：什麼都沒有。
接下來，我們會利用以下程式碼片段來建立 Excel.Application 物件的執行個體，在畫面上顯示出 Excel 執行個體，並開啟試算表 C:\Scripts\Test.xls：
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
最後一項工作也很重要，我們要將值 2 指派給名為 i 的計數器變數。這個變數可以用來記錄目前在試算表中所在的資料列。
請注意： 這麼一來，i 為什麼要指派為值 2 呢？其實很簡單：如果您仔細看看試算表，您會發現資料其實是從資料列 2 開始。資料列 1 只是標頭資料列。
知道了吧？我們或許對連接 YPbPr1 纜線不太在行，但我們確實懂得如何編寫指令碼。
至少有些時候是這樣啦。
現在我們準備好開始工作了。首先，要設定並執行 Do Until 迴圈，直到欄 1 內遇到空的儲存格為止。沒錯，這個意思就是說，不論如何，都不能在欄 1 留下空白列。如果您的指令碼遇到空白列，就會假定已經到達資料底部，並結束迴圈 (和指令碼)。與其用其他辦法解決這個問題，倒不如直接避免試算表中的額外空白列。
在迴圈內，一開始我們會先將第 i 列、第 1 欄之儲存格的值指派給名為 strComputer 的變數 (切記，第一次執行迴圈時， i 等於 2；因此，我們要處理的是第 2 列、第 1 欄之儲存格的值)。接下來我們將使用這行程式碼，建立物件參照 (objUser) 到由變數 strComputer 代表的電腦本機系統管理員帳戶：
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
這個指令碼若是有任何錯誤，問題就會在這裡發生。例如，假設我們遭遇網路問題、或是電腦已關機，或者假設其中一位 Scripting Guy 把 DVD 播放器的線路接錯了，導致整個美西地區大停電。倘若發生上述任何一項事件，我們將無法連上電腦。這就是為什麼我們要立即檢查 VBScript Err 物件的值：
If Err = 0 Then
若 Err 物件等於 0，表示我們可以正確無誤的連接到電腦上 (並可連接系統管理員帳戶)。若 Err 等於 0 以外的任何值，則只有一個答案：嘗試連接失敗。在這種情況下，我們根本沒必要嘗試變更電腦上的密碼；因為如果無法連接，當然也沒辦法變更密碼。
假設一切順利，沒有發生任何錯誤，我們接下來就可以執行以下兩行程式碼：
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
在第一行，我們使用 SetPassword 方法指派新密碼 (egTY634!alK2) 到本機系統管理員帳戶 (沒錯，我們知道：您不應該使用兒女的名字做為密碼)。第 2 行接著會將目前的日期和時間 (使用 VBScript Now 函數) 寫入第 i 列、第 2 欄的儲存格。請注意我們只有在能夠實際連接到遠端電腦，並可變更密碼時，才會更新 Password Changed 資料行。若我們無法連接電腦，則其對應的 Password Changed 欄位永遠無法更新，這就是我們分辨哪些作業成功，哪些作業失敗的方法。
這是什麼意思呢？也就是說，第一次執行迴圈時，我們的試算表看起來會像 [圖 3] 所示。
圖 3 重設第一個密碼之後的電腦清單
圖 3 重設第一個密碼之後的電腦清單
電腦 1 討論夠了。現在我們只需要稍微整理一下就能繼續：
Err.Clear
i = i + 1
上面的程式碼雖然簡短，但是這兩行程式碼都非常重要 (說的好像 Scripting Guy 會寫出不重要的程式碼似的)！第一行會將 Err 物件重設為 0。若並未發生錯誤，這就是重複的多餘動作；畢竟在該情況下，Err 已經為 0。不過要是真的發生錯誤，Err 就會等於 0 以外的值。在這種情況下，我們一定要手動重設 Err 物件。為什麼呢？因為這是 Error 物件：它只會記錄錯誤，不會記錄成功。舉例來說，我們假設電腦 1 發生問題而無法連接。為了方便討論，我們假定這個問題導致 Error 物件被設定為 99。
現在進一步假設我們繼續執行迴圈，並且成功連上電腦 2。您認為現在 Err 的值會是多少？沒錯：無論如何，Err 都還是設為 99。這是由於 Err 物件值只有在錯誤發生時才會變更；不過如果沒有發生錯誤，Err 物件會永遠維持目前的值。
這對我們而言是否有影響？我想應該有。畢竟就技術而言，只要成功連接電腦，我們就不會變更電腦上的密碼；相反的，只有在 Err 等於 0 的時候才會變更密碼。因此 (等我們拿計算機算一下...沒錯，我們是對的)，這會有影響：因為 99 不等於 0 (當然，只有 Scripting Guy 的家庭投票，才會發生 Scripting Guy 老爸投下的 99 票加起來還是等於 0 票的事)。這一點之所以對我們有所影響，是因為即使我們連接到電腦 2，Err 仍不等於 0。也因為 Err 不等於 0，我們就無法嘗試變更本機系統管理員的密碼。
換言之，如果 Err 的值改變，您必須將該值重設為 0；否則從此以後您的指令碼將誤認為有錯誤發生。您要如何將 Err 物件重設為 0 呢？沒錯：只要呼叫 Err.Clear 即可。
接下來，我們將 i 的值加 1。為什麼？第一次執行迴圈時，變數 i 等於 2；這是因為我們要連接到第 2 列、第 1 欄所列出的電腦。第二次執行迴圈時則希望連接到第 3 列，第 1 欄所列的電腦。既然 i 用來指向要處理的資料列變數，那麼就必須讓 i 等於 3。每個人都知道 2 + 1 = 3 (幸好我們手上還有計算機，對吧)。唯有如此才能繼續執行迴圈，並於試算表內所列出的下一部電腦上重複此程序。
這樣似乎蠻不錯，但我們已不再像過去那麼天真；我們清楚的知道，這個指令碼本身將繼續引來大量的電子郵件。大家會這麼說：「Excel 那一招很好用，但我還是需要為 OU 內的所有電腦或文字檔內列出的所有電腦變更本機系統管理員的密碼。或許我也可以快顯出電腦清單，並且從清單方塊中選取。或者，我真正想做的是...」
別緊張，您的願望就是 Scripting Guy 的使命 (只要您願意等候四年的時間，您的願望就會實現)。其實我們已經在 Script Center 發佈了大量多部電腦樣板，這些樣板可以讓您輕鬆針對多部電腦執行指令碼。例如，假設您想變更 OU 內之所有電腦的本機系統管理員密碼。沒問題啦。針對 OU 內之所有電腦執行指令碼的樣板如 [圖 4] 所示。
Figure 4 針對 OU 執行指令碼 (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
看到樣板中標示為「Insert your code here」的區段了嗎？您只需要刪除該區段中的範例程式碼，然後以變更本機系統管理員密碼的程式碼 (您可從本專欄中複製) 取代之。換言之，就是以下列程式碼來取代範例程式碼：
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
這個範例個案並不會幫您記錄結果，但您可以自行輕鬆加入該程式碼。取代範例程式碼，然後變更連接字串 LDAP://OU=Finance,dc=fabrikam,dc=com 以指向其中一個 OU，這樣就行了。
說實話，我們其實在一年多前就已經發佈這些樣板，還以為會成為 Script Center 最受歡迎的項目。結果判斷錯誤：雖然大家每天都來信詢問如何針對多部電腦執行指令碼，樣板卻幾乎沒有人使用。我們認為應該是沒人發現這些樣板的存在。但現在您知道了。或者至少在我們告訴您之後，就知道該去何處找這些樣板：microsoft.com/technet/scriptcenter/scripts/templates。嗯，或許這就是沒人使用這些樣板的原因...
現在 Scripting Guy 不再像過去那麼天真了，這是否也表示他們不再像過去那麼遲鈍又笨手笨腳？我們不妨這麼說：不久之前，某位 Scripting Guy 決定利用週末修理家裡的東西。待星期一回到工作岡位上，他的大姆指受傷鮮血直流，而腳上也有一個傷口。
這說起來，好像也沒那麼糟啦。至少對於 Scripting Guy 而言是還好。

Microsoft Scripting Guys 為 Microsoft 做事，也就是受雇於 Microsoft。在比賽、訓練、看棒球賽 (以及其他各種活動) 之餘，他們也負責管理 TechNet Script Center。請到 www.scriptingguys.com 一探究竟。


 安全性監控: 資訊安全設定精靈
安全性監控
資訊安全設定精靈
John Morello
此專欄中所包含的 Windows Server "Longhorn" 測試版相關資訊有可能變更。

有效及持續地保護伺服器安全性是許多 IT 組織需要面對的挑戰，尤其是如果這些組織的伺服器大量分散在不同的地理位置或組織結構中時，挑戰更加艱辛。對於有經驗的系統管理員來說，強化單一伺服器的安全性相對而言還算簡單，但若要強化數十個、數百個，甚至數千個
伺服器的安全性，這個課題就困難很多。這些年來，很多組織都已經針對伺服器安全性規劃好自己內部的檢查清單或一套標準，或是參照由 Microsoft、國家標準與技術局 (National Institute of Standards and Technology) 或其他外部團體所提供的指引。雖然這份文件可以提供非常寶貴的建議，但單靠文件本身並無法讓組織實際將這些最佳作法應用在網路上。因此為了強化系統，許多組織會選擇遵照預設的安裝設定，或投入大量時間與精力來建立自己的指令碼或原則。
隨著 Windows Server® 2003 Service Pack 1 (SP1) 中的資訊安全設定精靈 (SCW) 出現，Microsoft 現在提供簡單直接且受支援的方式來強化伺服器，並根據伺服器所扮演的角色來降低被攻擊的風險。透過結合 SCW 的優點與群組原則的集中式部署和管理功能，SCW 可以因應超大型 IT 企業來彈性調整。在本月的專欄中，我將概述 IT 組織如何運用 SCW 和群組原則，以更安全和一致的方式來管理其伺服器，同時也降低部署及營運成本。

什麼是 SCW？
SCW 是選擇性元件，可透過 Windows Server 2003 SP1 系列產品之所有成員 (包括 Windows Server 2003 R2) 都提供的 [新增/移除 Windows® 元件] 控制台來安裝。系統管理員一開始可以先在目標伺服器上執行 SCW，以識別該伺服器所擔任的角色。接著 SCW 便會協助系統管理員建立安全性原則，而此安全性原則將使用最低權限配置來強化機器的安全性。換言之，SCW 可確保只啟用伺服器角色運作所需的服務、應用程式功能及連接埠；不是伺服器角色特別需要使用的項目則會停用。這個方法可降低目標伺服器被攻擊的風險。如果執行並非伺服器角色所需的服務，就會提高伺服器的淨風險，同時也無法提高伺服器能力或效能。停用這些服務能夠降低風險，而且也可能會提升伺服器效能。
雖然相較於先前的 Windows Server 版本，Microsoft 在 Windows Server 2003 已經改良了很多安全性功能來大幅降低整體被攻擊的風險，但 Windows Server 2003 不像 Windows Vista™ 以及未來的 Windows Server 版本 (代號 "Longhorn") 那樣建置在高度元件化的核心上。因此，在 Windows Server 2003 的預設安裝中，可能會有已啟用且執行中的服務，這些不一定是所有伺服器角色設定都需要的服務。例如，根據預設會啟用列印多工緩衝處理器服務，但對於做為資料庫伺服器的機器而言並非必要。

實現以角色為主的安全性
過去幾年來，Microsoft 發佈了許多安全性專題的文件，透過這些文件來協助系統管理員了解不同的伺服器角色需要哪些服務，並針對 Web 伺服器等常見角色提供預先建立的範本。但是，Windows Server 2003 Security Guide 等文件中的指引可能不容易在大型環境中實作，尤其是這類環境中所使用的應用程式往往比 IIS 或 SQL Server 基本安裝更為複雜。此外，企業使用大量的協力廠商應用程式使得情況更加棘手，這些應用程式往往會依賴多個伺服器角色，而且其中的應用程式與服務需求定義不一定完善。
SCW 的處理方式是將指南中的所有相關知識和最佳作法封裝成系統管理員導向的精靈。舉例來說，如果系統管理員要部署新的商務 (LOB) 應用程式，而此應用程式需要 SQL Server™ 與 IIS，那麼他不必再花費大量時間來整合安全性指南的建議和開發自己的自訂相依性清單。而是在伺服器上安裝該應用程式，並啟動 SCW。SCW 會偵測目前正在執行的服務，並提供一份角色清單給系統管理員來選擇適合該伺服器的角色。SCW 會根據選擇內容而產生一項原則，按照角色的相依性矩陣，此原則將停用所有不需要的服務。SCW 另外也提供選項來讓您強化登錄安全性、封鎖不需要的網路通訊，以及套用有效的稽核原則。執行 SCW 之後，系統管理員可以將 SCW 原則儲存為 XML 檔案，然後再套用到其他執行相同 LOB 應用程式的伺服器。
因此，執行 SCW 能提供傳統的手動方式所沒有的三大優點來保護 Windows Server 的安全性。首先，SCW 能讓系統管理員盡量避免 (甚至完全排除) 不斷參考產品說明文件以確認特定工作量所需的服務和設定。這些知識已內建在 SCW 中，而且經由問題導向的介面讓系統管理員更方便提供所需的詳細資料。其次，SCW 綜合了數個領域的指引，包括強化服務、降低網路被攻擊的風險、強化 LDAP 和 SMB 服務，以及鎖定 IIS。以前執行這些設定工作需要使用個別的公用程式，而每個公用程式都有它自己的介面及使用方法。最後，因為 SCW 會將設定值輸出成 XML 原則檔，可讓您「單次建立，多次套用」這個檔案。無論您是將 1 或 100 部伺服器部署為支援特定 LOB 應用程式，都能夠輕鬆套用相同的 SCW 原則到所有伺服器。如此一來，安全性設定更能維持一致性，同時也能降低營運成本。此外，如果要回復 SCW 原則也會簡單很多。

SCW 元件
雖然 SCW 具備這麼多功能和優點，但 SCW 其實是一個很簡單的工具，由下列三個主要部分組成：精靈介面、命令列介面及安全性設定資料庫 (SCD)。中小型企業的系統管理員可能只需要與精靈介面互動。而在規模較大或複雜度較高的環境中，系統管理員可以使用命令列介面來協助自動化 SCW 工作，例如將 SCW 原則轉換成群組原則物件 (GPO)。一般而言，只有想要建立自己的自訂 SCW 角色的進階系統管理員才修改 SCD。
[圖 1] 所示的精靈介面，可讓系統管理員對目標伺服器建立、編輯、套用和回復安全性設定。透過一致的工作流程，此精靈介面會提供一連串選項給系統管理員，此流程首先會檢查服務與設定，接著檢查網路連線，然後檢查安全性稽核原則，最後再檢查 IIS 設定。
圖 1 SCW 介面
圖 1 SCW 介面
SCW 命令列介面提供三個基本功能。它可讓系統管理員分析和設定多部伺服器 (本機或遠端伺服器均可)，也可以回復原則。這個介面可用來將 XML 型的 SCW 原則自動轉換為 GPO，而此 GPO 原本就能用於標準的 GPO 管理工具 (例如，群組原則管理主控台)。最後，[圖 2] 顯示的 SCW 命令列工具可用來登錄任何新的安全性設定資料庫延伸。
圖 2 SCW 命令列工具
圖 2 SCW 命令列工具
SCD 只是 XML 檔案的集合，其中會詳細說明各個 SCW 角色所需的特定服務和設定。這些檔案位於 %windir%\security\msscw\kbs 中。根據預設，SCW 會隨附數個 Windows Server 核心角色，以及 12 個預先定義的應用程式角色，包括：BizTalk®、Commerce Server、Exchange Server、Host Integration Server、Internet Security and Acceleration Server、Microsoft Identity Integration Server、Microsoft Operations Manager、Small Business Server、SharePoint® Portal Server、SharePoint Team Services、SQL Server 以及 Systems Management Server。每個角色都有自己的 XML 檔案 (請參閱 [圖 3])。每次建立新的角色定義時，其對應的 XML 檔案也會放入這個目錄中。這些檔案是標準 XML，而且可以使用任何文字檢視器或其他支援 XML 的應用程式來讀取 (請參閱 [圖 4])。
圖 3 預先定義的角色
圖 3 預先定義的角色
圖 4 角色設定檔
圖 4 角色設定檔

結合 SCW 與群組原則
SCW 本身就是很棒的工具，但是與群組原則結合使用才能完全發揮其真正的威力。從發行 Windows® 2000 起，Microsoft 就不斷強調使用群組原則來保護 Windows 伺服器的安全性，因為群組原則能提供一致、連貫且集中管理的原則應用程式。藉由將伺服器依照角色分組成不同的組織單位 (OU)，系統管理員能夠在整個企業階層而非個別機器階層部署標準安全性設定。藉由建置標準的群組原則累積和應用程式邏輯，組織可以設計分層的伺服器角色階層，如此一來，只要使用少量的主要原則就能保護數百或數千部個別伺服器的安全性。如果有特殊的伺服器角色需要使用與主要原則不同的原則，也可以針對個別伺服器在 OU 階層中建立更「高階」的角色差異原則。透過這個方式可以進行小範圍變更來啟用特定角色的功能，不需要複製整個主要原則，讓大型企業能夠集中管理原則，同時又能視需求彈性配合特定應用程式進行調整。
就這個方法而言，真正的挑戰在於如何付諸實行。當大型組織擁有許多不同的應用程式和伺服器角色時，建立正確的原則集既困難又耗時 -- 至少在 SCW 出現之前是這樣子。藉由使用 SCW 來產生原則，然後將這些原則附加到正確的 OU，無論是針對現有或將來的工作量，您都可以大幅縮短部署目錄裝載的角色型安全性所需的時間。為了更清楚說明如何在組織中推行這個方法，以下將逐步說明大型企業實作 SCW 和角色型 GPO 的過程。

企業中的 SCW
在這個範例中，我將使用虛構的 Contoso 網路。Contoso 具有一個龐大、複雜且地點分散的 IT 企業。為了降低營運成本和提高伺服器安全性，Contoso 遵照 Microsoft 指引，建立了一個根據工作量來區隔和劃分伺服器群組的角色型 OU 階層。Contoso 使用 SCW 來建立附加至這些 OU 的原則。
因為預設不會安裝 SCW，因此 Contoso 必須在自動安裝映像中特別啟用 SCW 元件。為了這麼做，Contoso 將 SCW=On 這行新增到 Unattend.txt 的 [Components] 區段。然後，使用此映像建置的所有新系統都會在安裝過程中安裝 SCW 元件。請注意，單單設定要安裝 SCW 並不會在建立原則時將原則套用到機器。
為了在安裝過程中套用預設原則，Contoso 編輯映像中之 cmdlines.txt 檔案的 [Commands] 區段，以便呼叫使用下列選項的 scwcmd：
scwcmd configure /p:ContosoBaselinePolicy.xml
文字檔與 XML 檔案都必須位於映像的 $OEM$ 目錄中。Contoso 為何要在建立期間套用基準原則，而不直接取用附加到目錄中最上層 OU 的原則呢？藉由在建立期間套用原則，Contoso 可以確保無論機器是否加入 Active Directory®，基準都能維持一致。舉例來說，如果基於測試目的而建立一個伺服器，那麼在建立過程中套用基準原則就能確保該伺服器至少會遵循組織的標準安全性原則，即使這部伺服器並未加入實際執行 Active Directory。如果伺服器之後加入 Active Directory，群組原則應用程式和優先順序演算法便會將本機設定覆寫為網域或 OU 層級的設定 (請記住，原則應用程式的優先順序分別為本機、網站、網域、OU)。
一旦安裝 SCW 之後，Contoso 就可以開始建立自己的基準原則。基準原則應該是要在角色型安全性 OU 階層之最上層部署的原則，而且通常是階層中限制最嚴格的原則。重點在於，預設設定應該盡可能維持高安全性，然後再根據伺服器角色所需的個別工作量，只開放必要的服務與連接埠。為了達到這個目標，基準原則的建立方式應該是先選擇一個單純的新建伺服器，然後新增管理工具與公用程式的標準 Contoso 堆疊，再對其執行 SCW。例如，完成 Windows 基本安裝之後，Contoso 在伺服器上安裝 (可以是手動安裝或透過 cmdlines.txt 檔案) 本身的標準防毒、備份、管理及監控工具。由於這些工具可能都會建立自己的 Windows 服務，因此建立基準原則之前先在伺服器上安裝這些工具，讓 SCW 在進行服務鎖定的階段能夠識別它們的存在。
建立伺服器之後，Contoso 開始對伺服器執行 SCW。SCW 可以在本機或遠端執行，而執行者必須是機器上的本機系統管理員群組的成員。如果從遠端執行 SCW，它可讓您指定在遠端主機上執行所使用的使用者帳戶；如果在本機執行，您可以使用 runas.exe 來設定一樣的選項。SCW 進行的第一個工作是評估正在本機機器上執行的服務，以及顯示目前已安裝的角色 (請參閱 [圖 5])。
圖 5 選取和檢視伺服器角色
圖 5 選取和檢視伺服器角色
在 Contoso 基準伺服器上不應該選取任何角色，因為該機器已經設計為高限制的狀態。選取伺服器執行的角色之後，下一步是識別所需的用戶端功能，以便啟用自動更新、Active Directory 或 FTP 用戶端等功能。對大多數的組織而言，接受 SCW 預設值 (如 [圖 6] 所示) 就能啟用重要的功能 (例如加入網域的能力)，同時禁止次要的功能 (例如 FTP 用戶端)。
圖 6 已安裝的功能
圖 6 已安裝的功能
SCW 接著會繼續執行，讓您選擇要允許執行哪些特定系統管理工具和非預設的服務。您之所以要在安裝標準 Contoso 伺服器管理堆疊後再執行 SCW，就是為了這些非預設的服務選項。安裝防毒、備份及相關應用程式之後，SCW 才會偵測到這些服務，並進而將這些服務納入 SCW 產生的原則設定中。
在服務強化區段中提出的最後一個問題是：如何處理未指定的服務。雖然在最初建立原則的機器上不執行這些服務，但是套用 SCW 原則的其他電腦可能會碰到這些服務。例如，如果將基準原則套用至裝有某個協力廠商新應用程式的新伺服器上，則由該應用程式安裝的所有服務都會根據系統管理員在此決定的選項來處理。SCW 允許系統管理員不變更服務的啟動模式，也允許他停用服務。停用服務是比較安全的選項，但應該謹慎使用，因為任何未明確允許的服務都將被禁止執行。因此，這個選項最適合用於高安全性且管理完善的環境。至於組織的其他部分，建議選擇不變更啟動模式。因此在 Contoso 範例中，將會選擇此選項。在完成服務強化部分的工作之前，SCW 會向系統管理員提出一份將更改服務的報告。
完成服務強化之後，SCW 會提供有關限制輸入網路存取的選項。正如特定角色所需的服務清單一樣，特定工作量所需的連接埠清單也包含在 SCW 的 XML 資料庫中。
系統管理員可以視需要設定其他連接埠，也可以指定個別服務的連接埠規則，如 [圖 7] 所示。針對 Contoso 基準伺服器，只應允許最基本的服務 (例如遠端桌面)。所有其他例外狀況則應該在 OU 階層裡較低層的角色型原則中設定。
圖 7 檢視和允許連接埠
圖 7 檢視和允許連接埠
SCW 接著會讓系統管理員選取登錄選項，例如簽署檔案和列印流量。同樣地，最佳作法是建議在基準設定中選擇最安全的預設值。
接下來的選擇組合涉及系統稽核原則。在大部分的系統中，最好是選取稽核成功活動這個選項；因為稽核所有活動需要密集的處理器運算，而且會在稽核記錄中產生龐大的資料量。在懷疑遭到攻擊或需要更詳細的分析時，可以在特定機器上啟用失敗稽核。
最後，SCW 會提供強化 IIS 的選項給系統管理員。這些選項類似於 IIS 鎖定工具中所提供的選項，現在已直接整合到 SCW 原則中。
完成所有步驟之後，SCW 便會提示系統管理員儲存 XML 檔案。接著必須將儲存的檔案轉換成群組原則本身能夠辨識的格式。Scwcmd.exe 是用來將儲存的 XML 檔案轉換成 GPO 的工具。要輸入的命令如下：
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
這個原則會在 Active Directory 中自動建立，且可以附加到 Contoso 角色型強化 OU 階層的最上層。
一旦將此原則套用至階層的最上層後，任何新增到 OU 階層的機器都將繼承其設定。如果新增的機器需要修改這個原則 (例如，IIS 伺服器需要執行 W3SVC 服務)，Contoso 系統管理員便要對此新的伺服器角色重新執行 SCW，將新原則轉換成 GPO，然後將 GPO 附加到包含該伺服器的全新子 OU 中。由於最靠近伺服器的 GPO 具有較高的優先順序，因此結果是所有基準設定都將維持不變，除了需要修改以啟用該 OU 所需之角色功能的伺服器之外 (請參閱 [圖 8])。
圖 8 Contoso 的原則應用程式
圖 8 Contoso 的原則應用程式
這個方法的實際功效在大型組織或需要部署很多伺服器的環境中特別顯著。初始 SCW 原則一旦建立並附加到 OU 之後，後續的伺服器只需要新增到該 OU，便會自動繼承適當的安全性原則。因此，在建立初始的原則集並將原則集新增到 Active Directory 之後，部署新的伺服器或替換現有的伺服器變得簡單又快速。

展望未來
在下一版的 Windows Server "Longhorn" 中，Microsoft 大幅提高作業系統的元件化程度，如此一來，更削減和限制了被攻擊的風險。系統管理員不再需要專注在鎖定最低預設安裝，而是使用伺服器管理員工具，在各個伺服器上新增所需的角色和工作量。伺服器管理員的運作方式與 SCW 類似，它也具有一個相依性的內部資料庫，可讓安裝程式只新增必要的個別功能來提供所需的角色服務。此外，利用大幅擴充的 GPO 控制功能集，更能增強本文所討論之使用群組原則的集中管理角色型安全性。簡言之，Windows Server "Longhorn" 將 SCW 概念提升至包含更大彈性的全新層次，甚至豎立劃時代的超強安全性標竿。
SCW 資源
下列網頁將協助您開始使用 SCW：
  • Security Configuration Wizard Documentation
  • Security Configuration Wizard for Windows Server 2003
  • Windows Server "Longhorn"

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


 桌面檔案: x64 的面貌
桌面檔案
x64 的面貌
Wes Miller

Windows XP 為 64 位元架構提供原始支援已有五年以上。但除非您是當初採用 Intel Itanium 處理器 (適用於 Itanium 的 Windows XP 與 Windows XP 同一天問世) 的先驅者之一，否則大概是最近才耳聞 Windows XP 與 Windows 的可用性
適用於 x64 系統的 Server 2003 版本 (在業界亦稱為 x86-64) 是 AMD 之 AMD64 架構和 Intel 之 EM64T 的通稱。而且如果您在去年左右買了新的電腦，很可能其中已經具備 64 位元能力，即使它目前仍是以 32 位元的方式運作 (這是最有可能的情況)。
我目前任職於德州奧斯丁的一家小型企業。由於我們其中一項產品的架構需求，我們想要利用 x64 架構一些特有的優勢，正如 Microsoft® Exchange 2007 小組一樣，他們拋磚引玉並開始推出專為 x64 架構設計的產品。同樣地，我所帶領之研發及測試小組的開發工作站、膝上型電腦、伺服器和實際執行伺服器也全面部署 Windows® XP 與 Windows Server® 2003 的 x64 版本。此外，我還在我的個人膝上型電腦上執行 Windows XP Professional x64 Edition，以便測試和偵錯我們的產品。
有趣的是，每當我提到執行 64-bit Windows (尤其是在行動系統上執行) 時，聽者往往是一臉困惑。如果對方熟悉 64 位元運算技術，那麼他們的表情會交雜著不敢置信、反感和詫異，因為大家都認為要備妥 64 位元系統使用的裝置驅動程式是很困難的一件事。在本月專欄中，我將說明如何在 x64 系統上以 64 位元模式使用 Windows XP 與 Windows Server 2003 並解釋這麼做的原因，此外還將說明可能遇到的一些部署優勢 (及障礙)。文中還將涵蓋 Windows Vista™ x64 支援、移轉和部署等層面。

前情提要
如先前所述，Windows 中的 64 位元支援是從支援 Intel Itanium 處理器開始的 (雖然 Windows 在當時已經可用於 64 位元 Alpha 處理器，但在 Alpha 上執行時，Windows 從未真的採用 64 位元模式)。Windows XP 與 Windows Vista 不支援 Itanium，因此 x64 架構目前是為 64 位元的 Windows 用戶端運算能力而準備。大部分 Windows Server 2003 版本的產品目前都適用於 x64 而非 Itanium (Itanium 的用途基本上已歸類至超高階的資料中心工作站)，我預計這種趨勢將延續至下一版推出的 Windows Server (名稱代碼 "Longhorn")。
當 Windows Server 2003 Service Pack 1 (SP1) 推出時，將提供 x64 平台上的 Windows 支援。雖然聽起來有點困惑，不過此 SP1 推出時也正是 x64 版本的 Windows XP 問世時，這表示 Windows XP 32 位元產品與 64 位元產品將分別從 Windows 內部不同的程式碼樹狀結構開枝散葉。32 位元產品目前已經有第二個 Service Pack，而 64 位元版本的 Windows XP 從技術上來說尚未達到任何 Service Pack 等級 (也可以將它視為已經整合了 Windows Server 2003 匯集的 SP1)。
若要執行 64 位元 Windows (Windows XP、Windows Server 2003、Windows Vista 或 Windows Server "Longhorn")，要滿足的需求其實都一樣。顯然，首先必須要具備擁有 64 位元能力的處理器。就 AMD 而言，這表示必須找到具備 AMD64 相容性的單核心、雙核心或四核心系統 (請參閱 amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html)。就 Intel 而言，這表示必須找到具備 EM64T 支援或 Intel 64 Architecture 的單核心、雙核心或四核心系統 (請參閱 intel.com/technology/intel64)。請注意，麻煩之處在於其中的細節。例如，Intel Core Duo 系統並不具備 64 位元能力。而 Intel Core 2 Duo 系統卻具備 64 位元能力，雖然它常被簡稱為 Centrino Duo (我的膝上型電腦就是如此)。

與 x64 為伍
一旦確定您的系統是否為 64 位元版本的 Windows 提供原始支援後，就必須處理裝置支援的問題。可惜的是，雖然 Microsoft 不斷疾呼供應商與 OEM (透過已經舉辦兩年以上的 WinHEC 研討會) 建立及認證其裝置和系統的 64 位元驅動程式，但使用 Windows x64 時可能遭遇的最大困難就是找到適當的硬體裝置或軟體。從我的經驗來看，若要在伺服器上順利執行 x64，則在所需的裝置支援不多的伺服器上進行最為順利，也最能表現 x64 的優點。
而最困難的地方在於尋找桌面系統和行動系統的驅動程式。一般而言，使用知名 OEM 提供者或從企業級元件建置的系統 (在這種情況下，商務用途可能會促使供應商或 OEM 建立和簽署具備 x64 能力的驅動程式) 會比較容易找到這些驅動程式。
幸好，使用 Windows Vista 能大幅改善這些情況。在以 x86 為主要架構、並忽略大多數硬體驅動程式可用性不足的 x64 架構的情況下，就會發生另一個情況。裝置供應商必須針對 Windows Vista 提交 x64 驅動程式以進行相容性測試。實際上不需要包含 x86 驅動程式，但包含也無妨。從概念來看，這表示某些硬體 (特別是利用 Windows Vista 新功能的裝置) 其實可能只有 x64 Windows 支援而沒有 x86 支援。
事實上，驅動程式只是您嘗試執行原本的 64 位元 Windows 時所遭遇的其中一個問題。更大的問題在於如何開始 (或如何移轉)，稍後我將加以說明。

為何採用 64 位元？
當然，AMD、Intel 和 Microsoft 並非只是一時興起而移轉至 64 位元架構。移轉成 64 位元能提供數個關鍵優勢。如 [圖 1] 所示，x64 架構所提供最重要的增強功能就是能夠處理的記憶體大幅增加，相較於 32 位元 Windows 所能處理的 4 GB，x64 架構所處理的記憶體可高達 16 TB。請注意，雖然 64 位元的指標可處理高達 16 TB 的上限，但應用程式最多只能存取大約 8 TB。
Figure 1 記憶體位址空間限制 (Close Figure 1)

位址空間 | 64 位元 Windows | 32 位元 Windows
虛擬記憶體 | 16TB | 4GB
分頁檔 | 512TB | 16TB
分頁集區 | 128GB | 470MB
非分頁集區 | 128GB | 256MB
系統快取 | 1TB | 1GB
此外，專為硬體型資料執行防止 (DEP) 而提供的 x64 版本的 Windows 也適用於具備 NX (No Execute) 支援的 x86 系統。這樣可避免 Windows 利用的硬體導向解決方案發生緩衝區溢位的情況。它會禁止從記憶體中的資料頁執行程式碼，請參閱 support.microsoft.com/kb/875352 以取得有關這個主題的詳細資訊。
x64 版本的 Windows 跟 x86 版本的 Windows 一樣，都提供多處理器或多核心 CPU 的原始支援。但是藉由在所有 Windows x64 安裝中使用單一硬體抽象層 (HAL)，排除了製作 Windows XP 系統影像時最複雜的部分，亦即無須再辛苦識別非 ACPI 或單一 CPU 系統所使用的 HAL。
基本上，做為架構的 Windows x64 可讓您使用現有的管理基礎結構和現有的 32 位元軟體 (經由模擬的方式) 再加上能夠存取超強記憶體的 64 位元軟體。事實上，移轉至 Windows x64 只有下列幾項副作用：完全不支援 16 位元應用程式 (包括具有 16 位元安裝程式的 32 位元應用程式等問題)；當應用程式在啟用硬體 DEP 的情況下無法穩定執行時可能產生的問題 (雖然可以用逐個處理序的方式來停用 DEP，而且 Windows 應用程式相容性小組夾帶了某些無法在 DEP 啟用狀態下正確執行的應用程式)；最後則是在 64 位元 Windows Vista 中，所有驅動程式都必須經過數位簽署。
上述的最後一個條件是為了防止在記憶體中竄改 Windows 核心，新手通常會運用這項技術。既然 Microsoft 鼓勵供應商優先為 x64 這個架構開發驅動程式 (好讓驅動程式通過 Windows 硬體品管測試)，理所當然地，這項必要條件應該不會像過去那麼嚴苛。
在考量 Windows for x64 系統時，另外還需要注意以下幾點。沒有任何版本的 Windows XP for x64 系統包含 Windows Media® Center Edition 或 Windows Tablet PC Edition 內附的功能。但是 Windows Vista 不同，其 x64 版本的 Windows 具有與 x86 版本相同的功能。

虛擬化
我尚未提到虛擬化這方面。我所說的並非 Microsoft Virtual PC 或 VMWare PC 虛擬化產品，而是 32 位元可執行檔的作業系統虛擬化功能。在 32 位元版本的 Windows 中，16 位元應用程式全都在 NTVDM (Virtual MS-DOS® 機器) 的環境內執行。如先前所述，在 64 位元版本的 Windows 中不支援 16 位元應用程式。相反地，大多數 Windows 的整合元件原本就會以 64 位元二進位檔的方式執行，而有些元件和許多協力廠商程式則是以 32 位元應用程式的方式執行。
Windows 會提供一個稱為 Windows On Windows (WOW) 的全新模擬層，以便這些 32 位元應用程式可看見作業系統的另一種檢視，亦即可在 32 位元版本的 Windows 上有效執行。在 WOW 之下，x86 應用程式會將 Program Files (X86) 視為單純的 Program Files。同樣地，%WINDIR%\SysWOW64 會向 x86 應用程式顯示為 %WINDIR%\System32。x86 應用程式檢視登錄機碼 HKLM\SOFTWARE\Wow6432Node 的方式就如同檢視 HKLM\SOFTWARE 節點本身一樣。
您可以利用 Process Explorer 工具來一窺虛擬化的其他層面。由於很多 32 位元應用程式都預期與整合的 32 位元 Windows 二進位檔互動，因此許多這些二進位檔會同時提供 64 位元和 32 位元的版本。只要在 Process Explorer 中另外新增一欄，您就會很清楚看見這個現象。在 [圖 2] 中，您會看到 cmd.exe 的兩個執行個體 (一個是 32 位元版本，而另一個是 64 位元版本)。請注意在反白顯示的 32 位元執行個體中，您會看到 32 位元處理序載入數個 wow64* DLL。這表示正在進行虛擬化，好讓 32 位元應用程式在 64 位元 Windows 底下運作。亦請注意，cmd.exe 的 64 位元版本和 32 位元版本所使用的工作目錄 (路徑)。
圖 2 Process Explorer 顯示 cmd.exe 的 32 位元和 64 位元版本。
圖 2 Process Explorer 顯示 cmd.exe 的 32 位元和 64 位元版本。
有關虛擬化這個主題最後一點需要考量的是：當 Windows 以原始 64 位元應用程式的方式執行 explorer.exe 時，結果有利有弊。最大的缺點是所有 Explorer 殼層延伸都必須針對 x64 重新編譯才能運作 (大部分都尚未重新編譯)。
但是 Internet Explorer® 並非如此，因為它預設會以 32 位元版本執行。這麼做的主要原因是讓目前已經用於網際網路上的大量 ActiveX® 控制項能順利地照常運作。否則，由於 64 位元應用程式無法載入 32 位元 DLL 或同處理序 (In-Process) 驅動程式，因此根本無法在 64 位元瀏覽器上載入 32 位元 ActiveX 控制項，而幾乎所有目前可用的 ActiveX 控制項都是由 32 位元 ActiveX 控制項所構成的，也就是說，將有很大一部分的網際網路內容變成無法存取。若要親身體驗一下，請嘗試在 64 位元 Windows 系統上載入 C:\Program Files\Internet Explorer\iexplore.exe，然後任意瀏覽會載入 ActiveX 控制項內容的網站 (Windows Update 網站亦可)，結果將呈現程度不一的失敗情況。Windows Update (請參閱 [圖 3]) 現在已經更新，在這種情況下將會開啟 Internet Explorer 的 32 位元執行個體。想必未來一定會更新一些 ActiveX 控制項內容，以便發揮 64 位元 Internet Explorer 的優點。但是對於目前大部分執行純 32 位元 Windows 的 Windows 系統來說，更新 ActiveX 控制項內容的必要性並不緊迫。我想短期內這點也不會改變。
圖 3 32 位元 ActiveX 控制項在 64 位元 Internet Explorer 中無法運作
圖 3 32 位元 ActiveX 控制項在 64 位元 Internet Explorer 中無法運作

Pluck 的 x64 Windows 實作情形
我在本文開頭提到我們已經開始在 Pluck 公司內部進行 x64 Windows 的轉換。我們使用三種不同的 Windows 版本來進行這項作業：Windows XP Professional x64 Edition、Windows Server 2003 Enterprise Edition x64 和 Windows Vista x64。
我們的組織夠小，因此可以在著手開發最新產品的同時，開始移轉至 Windows for x64 並善用它的優勢。這麼做能確保我們訂購的所有新硬體都支援 x64。事實上，多虧了 x64 的擴大記憶體特性與虛擬化功能，讓我們能夠依據想要的方式執行產品。我們所有的實體伺服器都是在 64 位元主機伺服器上，以 64 位元虛擬伺服器的方式執行。每個主機伺服器都包含 16 GB 的 RAM，而這些 RAM 會分攤給在該主機伺服器上裝載的虛擬伺服器 (通常是每個預備虛擬機器 (VM) 各分到 2 GB，而每個實際執行 VM 則分到 3 GB)。
藉由使用階層 1 系統和虛擬化硬體，我們就能達到接近 100 % 的裝置支援度。例如，我的膝上型電腦裝有三個不提供 x64 驅動程式的裝置。這些裝置似乎屬於背板類，並不重要，即使沒有它們，系統也能正常執行。有趣的是，雖然我的系統標有 Windows Vista Capable 標誌，安裝 Windows Vista RC1 x64 所產生的裝置支援結果也完全一樣，不過我相信供應商很快便會提供所缺乏的這些驅動程式。
因為我們使用系統的範圍主要侷限在 Microsoft Office、Visual Studio® 以及開發與建置作業所運用的其他一些工具，因此在移轉過程中不會有很多舊版應用程式造成相容性問題。雖然我們的組織中使用不少 32 位元版本的 Windows，但我們使用新硬體來開始進行 64 位元移轉，相較之下少了很多麻煩。

x64 部署和移轉
進行部署時需要考量幾項要點。Microsoft 專為 x64 架構推出特定版本的 Windows Pre-installation Environment (Windows PE)。不過，由於 x64 系統上包含 x86 同位檢查，因此您也可能想要使用 x86 Windows PE 進行部署，特別是當您使用影像處理解決方案時。如果您是使用自動安裝來部署 Windows XP，就必須選擇架構專屬的 Windows PE，例如 winnt32.exe 就必須在所部署的相同架構下執行。因為 Windows PE 沒有 32 位元相容性階層，而且 x64 底下的 winnt32.exe 屬於 64 位元應用程式，所以 32 位元 Windows 需要 32 位元 Windows PE。64 位元版本的 Windows 也是相同情況，因此它需要 64 位元 Windows PE。
遠端安裝服務 (RIS) 在這點上不太一樣，因此我們會在 Pluck 使用 RIS。從 Windows Server 2003 SP1 開始，RIS 可以部署 Windows 的 x64 及 x86 或是 Itanium 架構。當 x64 系統連線至 RIS 伺服器時，該伺服器 (依預設設定) 將提供 x86 和 x64 RISetup 或 RIPrep 影像。RIS 也可以設為僅提供 x86 影像或僅提供 x64 影像給 x64 用戶端。預設會讓您選擇此選項以便提供最好的 x64 硬體使用經驗。
您是否發現我尚未提到升級問題。這是有原因的。我不得不說，從 x86 升級整個作業系統至 x64 是很艱鉅的龐雜作業。基於這個原因，同時考慮到 Windows XP Pro x64 Edition 的部署有限，您無法從任何 x86 版本升級至 Windows XP x64，也無法從任何版本的 Windows XP (x86 或 x64) 升級至 Windows Vista x64。x64 系統上的 Windows Vista (正如它之前的 Windows XP Pro x64 Edition 一樣) 是一項僅限全新安裝的產品。因此，許多組織都只有在開始更換新硬體時，才會考慮移轉至 x64，而且許多組織對於 Windows Vista 本身也將採取類似的部署策略 (同時推動這兩項變革應該是最合理的做法)。
但這並不表示從 x86 Windows 移轉至 x64 Windows 的人員或組織找不到任何可用的工具，工具是有的。適用於 Windows XP 和 Windows Vista 的使用者狀態移轉工具 (USMT) 版本都已延伸為支援從某個 Windows 安裝移轉至另一個安裝 (相對於作業系統的 In-Band 升級)。無論如何，這是目前大多數組織用來部署 Windows 的主要方法 (清除後再重新載入，即使在同一部電腦上也一樣)，因此利用相同的機制來移轉到全新架構上的 Windows 應該不會比以前麻煩多。

結論
雖然我們的組織較小，我們採取的 x64 漸進式移轉可能比大型企業所要面對的大規模移轉作業簡單許多，但每位 IT 專業人員都必須開始考慮有一天終將移轉至 x64 架構。雖然 x86 架構和 Windows 的 x86 原始版本在未來十年內依然游刃有餘，但 x64 架構肯定是企業運算技術的明日之星。隨著 Microsoft 推出完全以 x64 能力為主的 Exchange Server 和其他產品，無論您目前是否要在 x64 系統上使用原始的 Windows XP 或 Windows Server 2003，您都應該開始了解 x64 系統可先融入您架構中的哪個部分，以及 x64 系統將如何妥善整合至您的 Windows Vista 移轉計畫。

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


 Inside Microsoft.com: 使用 Active Directory Federation Service
Inside Microsoft.com
使用 Active Directory Federation Service
Jim Guthrie

Microsoft 有為商務夥伴們提供一個外部網路，以便存取重要的內部資源。在外部網路的架構中，會要求每一位組織外部參與者都具備唯一的網域帳戶。此帳戶是由 Microsoft 員工建立與管理，而不是
由夥伴，其原因很明顯。然而，這樣雖然有其作用，但使用者在使用上可能會稍嫌不便，同時對於 Microsoft 而言，所有夥伴使用者的管理，也是耗費大量資源的重擔。
以下是外部網路的現行運作方式。當客戶或夥伴登入應用程式之後，必須輸入他的憑證。在同一個工作階段中，若該使用者決定存取不同資源，則會再次出現提示，要求輸入憑證。只要使用者不斷在各資源之間來回，就會持續出現這樣的提示。若使用者登入使用多重資源的單一應用程式，例如財務資料庫，他就必須分別獲得各個資源的驗證。這對使用者而言或許是麻煩又惱人的經驗。
幸好，只要使用 Active Directory® Federation Services (ADFS)，我們就能輕鬆解決多重驗證的問題，您也可以做到。ADFS 是促使兩個或更多組織之間互信的 Windows Server® 2003 R2 元件，可維持各組織獨立管理使用者的能力，同時允許共享多重資源。在本專欄中，我將示範 Microsoft 如何計劃使用 ADFS 來解決這個多重資源外部網路問題，以提供您實作類似解決方案時所需的資訊。不過在我詳細說明之前，請先看一下 [圖 1]，熟悉部分 ADFS 的基本詞彙。
Figure 1 ADFS 詞彙 (Close Figure 1)

詞彙 | 定義
Federation (聯盟) | 一對已建立 Active Directory 聯盟信任的領域或網域。
Federation Service Resource (FS-R) (聯盟服務資源) | 將連入驗證要求導向 FS-A 和所需資源的路由。
Federation Service Accounts (FS-A) (聯盟服務帳戶) | 提供帳戶語彙基元以便由 FS-R 進行驗證。
Federation Service Proxy (FS-P) (聯盟服務 Proxy) | 為 FS 伺服器提供隔離階層，以隔離傳入的網際網路流量。
Claim (要求) | 伺服器對於用戶端的陳述 (例如名稱、身分、金鑰、群組、權限或能力)。
Realm Discovery (領域探索) | 每一個 FS-A 都有的網域或領域，其中會存放登入憑證。領域探索 (Realm Discovery) 可判斷 ADFS 工作階段所使用的 FS-A。

ADFS 解決方案
使用者嘗試存取 ADFS 感知應用程式時，會將瀏覽器導向 Federation Service Resource (FS-R) 進行領域探索。使用者可以在此選取未來在工作階段期間要使用的憑證組合。根據用戶端選擇的領域，接下來會將使用者重新導向 Federation Service Accounts (FS-A) 伺服器。使用者會在這部伺服器接收到有效的帳戶語彙基元 (在 cookie 中)，而該語彙基元是根據使用者以 Windows Live™ ID (原為 Passport 帳戶)、Windows 整合式驗證或者 SSL 驗證等形式所輸入的憑證 (請參閱 [圖 2])。在此模型中，是由個別組織單位決定是否維持其帳戶的 Federation 伺服器。就 Microsoft 夥伴伺服器而言，這樣的做法可以減輕 Microsoft.com 管理環境中所有帳戶的負擔。當然，若您實作該責任等級，就必須仔細選取聯盟的組織，並確保這些組織都能積極管理其帳戶資訊。
圖 2 ADFS 流程
圖 2 ADFS 流程
接下來會回到 FS-R 伺服器，將帳戶語彙基元交換為資源語彙基元。在我們的組態中，此語彙基元內包含由 FS-R 執行的要求對應程序而授與使用者的完整權限清單。一旦接收到語彙基元，使用者就會取得 ADFS 感知應用程式的單次登入 (SSO) 能力，根據預設，有效期間為工作階段保持開啟的期間，或者最多 24 小時 (本時間窗口可設定)。結論是您已為這些 ADFS 感知應用程式啟用 SSO，並因此獲得更安全、更有效率的客戶體驗。若要取得 ADFS 驗證程序的逐步說明，請參閱 Matt Steele 在 2006 年 7 月的 TechNet Magazine 中發表的文章，標題為：Simplify Single Sign-on with ADFS。
為了維護 Microsoft 企業資源的安全性，我們將外部網路的網際網路部分獨立於企業之外，這表示每一部伺服器都可能具有兩個主體。我們允許企業內部使用者的單向信任，並利用伺服器提供所需保護。我們同時也為外部網路空間提供獨立的網域，以讓外部使用者存取需要的資源。
實作時的兩個主要考量，包括負載平衡以及 ADFS 原則檔的變更。不論就全域或本機層級來看，負載平衡都是一大挑戰。在實際上線的初期，我們將從 Content Delivery Network (CDN) 的夥伴 Akamai 或 Savvis 開始使用全域負載平衡，將前端 Web 伺服器叢集分成兩個區域。這樣可以為終端使用者確保系統的可用性，即使在一組區域伺服器無法使用的情況下 (發生的機率小之又小)，系統也能使用。這是根據 CDN 提供的伺服器健康狀態檢查服務，並透過容錯移轉自動化來達成。此外，我們有能力可以在未來輕鬆加入更多叢集。為了節省成本，我們的測試部署選擇不使用 CDN 服務。
在區域層級，我們將以伺服器配對的方式，透過網路負載平衡 (NLB) 叢集實現本機容錯移轉。我們並不使用任何特殊的負載平衡功能，因此可以輕鬆透過硬體來完成；不過，我們仍使用 NLB 來降低成本。此組態設定可提供穩定性，以確保在所有支援環境中有 99.9% 以上的系統可靠性。
我們所面臨的另一項挑戰，是如何確保 ADFS 原則檔 (ADFS 的骨幹) 正確發佈至整個環境中，而其變更亦可確實覆寫。為了要達到此目的，我們利用另一項 Windows Server 2003 R2 的內建功能：分散式檔案系統複寫 (Distributed File System-Replication，DFS-R)，這是全新的狀態式多重主機複寫引擎。在每一部後端伺服器上，我們啟用了 24 小時、完整網狀複寫的 DFS-R 群組成員資格。如此一來，不論在何處產生原則檔變更，都能發佈到所有的伺服器。我們只要控管誰可以變更檔案，就能夠擁有穩定、隨時可用的服務。
我們試圖確保所有變更都是透過 ADFS 嵌入式管理單元完成。不過實際上，我們發現有時候必須手動更新此檔案。在手動更新時，請務必記住 ADFS 會追蹤此檔案的版本。因此您必須遞增檔案，變更結果才能反應到環境中。
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
您也必須記住，原則 XML 檔就像所有 XML 一樣，有區分大小寫。整個原則 XML 檔中，有許多應用程式或其他 ADFS 伺服器的參考，這些都必須從伺服器逐一複製到其他伺服器上。請注意，在下列常見範例中，第一個 RevocationCheckFlags 為手動輸入，第二個則是從 UI 修改的受信任應用程式 URL：
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
為了實現更高的安全性，我們使用另一項 ADFS 元件：Federation Service Proxy (FS-P)，以確保 FS-R 維持在連入網際網路要求無法直接存取的階層。我們在 Microsoft.com 實作 Proxy 的獨特方式，是藉由使用單一 Proxy 組合，在我們的測試區域中管理多個 ADFS 環境。有趣的是，在一開始嘗試這項技術時，我們發現必須做簡易的登錄機碼修改才能達成此目的。機碼位於 HKLM\Software\Microsoft\WebSSO。只要變更此機碼內的初始目錄值，您就能在多個環境下使用 Proxy。預設為：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
若要切換環境，機碼必須變更如下：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
建立批次檔可以簡化此程序的管理方式。可惜目前 ADFS 的 MMC 嵌入式管理單元版本並不支援環境的切換，因為 Proxy 和資源或帳戶伺服器之間是一對一的關係。這是唯一可擴大運用 Proxy 伺服器的方式。結果是大幅降低了成本開銷，因為它可以限制實體伺服器的需求數量，不論您選擇裝載的環境數量之多寡。
從架構的角度來看，我們使用了虛擬機器來執行測試環境，這又是一項可節省成本的做法。此舉可排除額外購買與置放六部伺服器的必要。直到目前為止，我們仍未發現效能上的問題。但是為了達到實際生產環境的需求 (即將高出很多)，我們選擇使用效能更高的實體機器。

不僅考量 Active Directory
Microsoft.com 不僅使用 Active Directory 帳戶進行驗證，也成功整合了 Windows Live ID 帳戶。我們發現使用 Windows Live ID (WLID) 4.5，可以利用個人的 Windows Live ID 帳戶，使用自訂要求轉換來委派存取 Microsoft 資源。這是達到 SSO 驗證的極大優點，因為我們不再需要特定的網域帳戶。

其他的挑戰
我們目前所面臨的最大挑戰，是如何管理 ADFS 以共享語彙基元簽署憑證。我們目前使用標準的憑證，有效期通常為一年，之後才需要更新。更新時，每一部相關的伺服器都必須依序更新，這會嚴重影響 FS-R。聯盟數量在 15 或 20 個時還可以管理，但是我們希望能夠為至少上百個 (甚至數千個) 的規模做好準備。這代表在單一環境中就需要由全職人員負責 SSL 憑證的管理。我們有許多團隊正在尋求最佳的自動化解決方式，但尚未採取實際行動。
另一項挑戰則是並非所有應用程式都屬於 ADFS 感知應用程式。有些還需要經由程式設計，網站才能善加利用 ADFS。我們正在與 Microsoft® Office SharePoint® Services 團隊密切配合，以確保新一代的 SharePoint 可支援我們的 ADFS 實作需求。

結論
決定是否要遷移至 ADFS 模型之前，必須考量多項因素。其一是客戶將存取的資源數量。在組織之間設定聯盟信任是一項不難的工作，但卻需要花時間和精力來撰寫、檢閱及執行可接受的存取原則。因此，如果您的客戶僅需存取一項資源，您就必須判斷是否值得這麼做。然而，如果需要存取的資源數量較多，受益的程度也會提高。
如需詳細資訊，請參閱 ADFS 概觀，以及 Active Directory Federation Services：連結至聯盟式身份以及存取管理的路徑。

Jim Guthrie 任職於 Microsoft 的 Microsoft.com 營運團隊，除了參與 ADFS 的工作之外，他也是 Enterprise Portal Platform Support 小組的系統工程師。


 現場筆記: 學習之樂 (與苦)
現場筆記
學習之樂 (與苦)
Mark D. Scott

我還記得 以前每次出現新產品的心情 -- 搶先在其他人之前試用最新技術的興奮之情，反覆研究產品，了解其運作方式並加以活用。身為早期採用者，藉此獲得精闢的知識，並成為別人尋求深奧學問的對象，這些經歷讓我成長。
但不知不覺這份樂趣逐漸消失。我不曉得發生了什麼事。或許是忙到清晨三點、試著想要讓關鍵應用程式順利執行的挫敗讓我疲憊。或許就像郵件伺服器罷工時 (當時一部伺服器就夠用了) 我誤讀的產品說明文件一樣，被扔棄在地板上。又或許我只是年事漸高，變得憤世嫉俗了。這些都無所謂。反正這件事再也不像十多年前一樣好玩，讓人想挑燈夜戰了。但這不表示學習可以停止。不久前我才更堅定這個想法。
我最近升級到 Microsoft® Outlook® 2007，我真的覺得很好用。不過我也是 MSN® Premium 的用戶；這是我的 ISP 提供的服務的一部分。使用上一版的 Outlook 時，我必須利用稱為連接程式 (Connector) 的特殊軟體來存取 MSN 電子郵件地址。但這個軟體連接程式無法在 Outlook 2007 上運作，於是我跟 MSN 連絡。MSN 要我去找我的 ISP，而 ISP 最後終於告訴我他們並不支援在 Outlook 2007 上使用 MSN Outlook 連接程式。就這樣來來回回透過電子郵件、聊天室和語音通話，簡直花了天長地久才得到這個答覆。
然後我突發奇想 -- 也許根本不需要再使用連接程式。我啟動 Outlook 2007，不使用連接程式軟體直接設定 MSN 的新連線。Outlook 毫無困難地連上網際網路，找到伺服器，並完成帳戶的設定。Outlook 對我的其他幾個 POP3 帳戶也是以相同的方式處理。因此我不但能夠存取電子郵件，還學習到這個產品有這項很棒的新功能。
這個故事告訴我們：如果支援部門中，有人願意花一點功夫試玩一下這個新產品，那麼他很可能就可以會告訴我不需要使用連接程式，如此一來，我們彼此都能省下很多時間。
也許更進一步的說，如果我一開始就先摸索這個產品，自己可能早就發現這個解決方法了。但是我卻期望別人來告訴我答案。由於沒有人花時間來研究對我們日常生活很重要的新產品，我們雙方都損失很多時間，如果我們其中一方能夠認真一點，靠自己來解決問題，就像我最後自行解決的方式一樣，就不必白費這些時間了。
日新月異的技術會推翻我們的假設。身為 IT 專業人員，我們必須避免預設立場。我們辛苦學到的專業知識總有一天會被新的技術取代，因為唯有舊的知識被新的知識取代後，技術才能變得更方便使用。我們不能永遠倚靠這些舊的知識持續提供競爭優勢。真正的競爭優勢不在於如何使用陳舊技術的知識，而是如何精通新觀念與技術。藉由不斷的學習，讓學習成為生活的習慣，我們才能夠持續駕馭嶄新技巧。隨著各式各樣新產品不斷湧現，學習必須成為我們的生存之道。
如果您想要跟我連絡，歡迎寄電子郵件到我的 Microsoft 帳戶或 MSN 帳戶 -- 因為我現在可以使用 Outlook 2007 同時接收這兩個帳戶的郵件了！

Mark D. Scott 是 Microsoft 諮詢服務的資深顧問。Mark 與客戶密切合作，協助設計和建置大規模的資料中心應用程式。您可以透過以下管道與 Mark 連絡：granddaddy2002@msn.com 或 mascott@microsoft.com。


 Windows 機密文件: 錯誤的威力
Windows 機密文件
錯誤的威力
Raymond Chen

在 Windows 95 中， 您可以到疑難排解頁面選取 [停用緩衝區認可同步處理 (Disable Synchronous Buffer Commits)]。但是您知道這個核取方塊的作用為何嗎？或是它存在的理由呢？
MS-DOS® Commit 函數的正常行為，是清除特定檔案的所有未寫入資料到磁碟上，並等待資料被確認為已寫入，然後才傳回。核取 [停用緩衝區認可同步處理 (Disable Synchronous Buffer Commits)] 選項後，便會立即傳回呼叫，而不用等待資料寫入。這樣當然會違反功能性規格，因為功能性規格要求必須等到資料寫入後才傳回呼叫。這個動作會提高知識庫文章 139669 中委婉稱為「檔案完整性問題」的風險，因為它會使得發出清除要求的程式誤以為資料已妥善放置在磁碟上，但其實不然。
資料庫程式可能會使用 Commit 函數，來建立磁碟上的檔案狀態與程式預期它在磁碟上的狀態相符的檢查點。如果電腦在更新期間斷電，資料庫程式可以使用最後一次認可點所記錄的資訊來重建資料庫完整性。但萬一 Commit 在認可完成之前立即傳回，就可能會遺失此完整性檢查點。結果會造成資料庫損毀。
如果後果這麼嚴重，為什麼還要提供這個選項呢？原因在於：Windows® 3.11 中有一個錯誤。
圖 1 啟用 Windows Server 2003 中的錯誤行為
圖 1 啟用 Windows Server 2003 中的錯誤行為
Windows 3.11 引進了「32 位元檔案存取」，這是低階檔案 I/O 介面的 32 位元實作。但是 Commit 函數的實作包含一個錯誤，亦即它會忽略清除檔案緩衝區的要求。如果您安裝了會清除其檔案緩衝區的程式，並且在 Windows 3.11 上執行這個程式，那麼清除動作將會無效。因此，萬一碰巧斷電，便會造成資料庫損毀。
Windows 95 檔案系統的同仁修正這個錯誤之後，新的錯誤報告便大量湧入，因為有使用者的應付帳款程式執行速度變得很緩慢。其他使用者的資料庫程式也遇到相同情況。到底發生了什麼事？
原來是這些程式會不斷發出清除呼叫。因為程式設計師注意到在 Windows 3.11 中執行清除呼叫的速度很快，因此他們在自己的程式中盡情地使用清除呼叫。每寫入一個位元組就執行清除。每寫入一個字串就執行清除。既然清除的速度很快，那麼應用程式就可以在每個作業後認可磁碟的資料，而不會明顯降低效能。但是就在 Windows 95 修正此錯誤之後，這些程式的執行變得非常緩慢，因為 Commit 呼叫突然之間必須確實完成工作。
當然，如果檔案系統小組什麼都不做，這些程式就會繼續緩慢執行，而使用者也會認定 Windows 95 出了問題。使用者會口耳相傳：「Windows 95 的執行速度慢得跟牛一樣」。但從另一個角度來看，如果檔案系統恢復成原本的 Windows 3.11 行為模式，就等於重新植入錯誤，而且可能產生討厭的「檔案完整性問題」。
因此，他們的解決方案是維持錯誤修正的狀態，然後新增一個核取方塊 (儘管深埋在疑難排解頁面中)，好讓由於錯誤修正而遇到程式執行問題的使用者，能夠恢復成之前的 Windows 3.11 行為模式。
歷史總是不斷重演。在 Windows Server® 2003 中，I/O 人員發現一個錯誤，就是標示為「強制單位存取 (Forced Unit Access，FUA)」的要求會遺失 FUA 標記，並當做一般 I/O 執行。這就好比是忽略清除要求情況的再版！他們修正了錯誤，但同時提供恢復成原有錯誤行為的選項。在 Windows Server 2003 版本中，這個核取方塊稱為 [啟用進階效能]，但是您現在知道它的意思其實是「還原舊有的錯誤行為」。

Raymond Chen 的網站 The Old New Thing，以及採用相同標題做為個書名的出版品 (Addison-Wesley，2007)，都討論 Windows 的歷史和 Win32 程式設計。他向來循規蹈矩。