 TechNet Magazine November 2006

TechNet Magazine November 2006

Windows Vista: 您不可不知關於部署 Windows Vista 的十大事項

從更靈活的映像處理乃至全新的開機載入器，Windows Vista 為桌面部署引進了若干重大改變。這篇文章將探討 Windows Vista 能讓您的日後部署比以往更快速而簡易的 10 種方式。

Michael Niehaus Windows Vista: 利用 Windows Vista 新的安全性功能保護您的個人電腦

Windows Vista 是遵照 Microsoft Security Development Lifecycle (安全性開發生命週期) 指導方針所開發，提供了舊版 Windows 中前所未有的安全性等級。這篇文章將探討 Windows Vista 所提供可協助偵測及防範安全性威脅的新式增強功能。

Justin Harrison Windows Vista: 利用「使用者帳戶控制」實現非系統管理夢想

儘管限制使用者權限是有助於保護系統的好辦法，卻也會給非系統管理帳戶帶來不便，引發諸如應用程式相容性等問題。Windows Vista 提供的新功能將可讓您更輕鬆地管理與支援標準使用者帳戶

Alex Heaton Windows Vista: 使用 Windows Vista 架設企業網路

自發行 Windows XP 開始，網路便徹底地改頭換面：使用者更富行動自由、無線網路隨處可得，同時安全性威脅也更為複雜。現在就來看看 Windows Vista 中能讓網路更單純、更安全且更容易管理的創新功能。

Jason Leznek Windows Vista: 準備迎接 Windows PE 2.0

更強大的 Windows PE 版本將隨著 Windows Vista 發行。本概觀將討論 Windows PE 2.0 中的新功能與特性，以及這些變更對您的影響

Wes Miller Windows Vista: 深入剖析新版 Microsoft 應用程式相容性工具組

隨著 Windows Vista 的到來，功能更強的 Windows PE 版本也將發行。本概觀將討論 Windows PE 2.0 中的新功能與特性，以及這些變更對您的影響

John Melton Windows Vista: Windows Vista 中事件管理的新工具

Windows Vista 代表企業管理上的一大進展，提供許多專為事件記錄和追蹤所設計的全新及改善的基礎結構與工具。因此讓收集資訊的方式更為簡單且強大，並且能夠迅速執行疑難排解。

Val Menn Windows Vista: Windows Vista 中更強大的群組原則

群組原則基礎結構已經過大幅度調整，提供了新的管理功能、新的原則設定，並且支援多項本機 GPO 等。本文將深入探討 Windows Vista 中對於群組原則的多項變更。

Jeremy Moskowitz 編輯的話: 準備好迎接 Windows Vista

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

Greg Steen 公用程式精選: Robocopy GUI

Joshua Hoffman SQL 問題與解答: 暫存資料表、64 位元處理、鏡像及其他資訊

Edited By Nancy Michell 嗨，Scripting Guy！: 改寫？沒問題！

The Microsoft Scripting Guys Windows 的未來: Windows Server "Longhorn" 中的目錄服務

Byron Hynes 資訊安全新知: 我剛收到資訊安全佈告欄，接下來該怎麼辦？

Christopher Budd Microsoft.com 幕後: ASP.NET 的管理與委派

Jeff Toews 實戰注意事項: 學習如何尋求協助

Edward Dake Windows 機密: 處理相容性缺失

Raymond Chen


 Windows Vista: 您不可不知關於部署 Windows Vista 的十大事項
Windows Vista Michael Niehaus

您不可不知關於部署 Windows Vista 的十大事項
摘要:
  • 全新的桌面部署方法
  • Windows 安裝程式的變更
  • 協助您開始使用的工具
下載本文程式碼: NeihausDeployment2006_11.exe (152KB)

您之前已完成部署 Windows XP，現在想要升級為 Windows Vista。無論您將部署至 10、100 或 100,000 台電腦，只要瞭解從 Windows XP 變更的程序，就能讓部署更順利地執行。
Windows® XP 與 Windows Vista™ 之間的部署差異有 10 項，當您要進行移轉時，將會發現這些知識十分受用。

1. Windows Vista 映像較大
使用 Windows XP 和 Windows 2000 時所建立的映像能夠輕鬆放入一張 CD (不到 700MB)。即使是加入許多應用程式、驅動程式和公用程式到映像中的組織，最後的作業系統映像多半介於 1GB 到 3GB 之間。
使用 Windows Vista 時，映像大小會從約 2GB 開始起算，而且是壓縮過的大小。一旦部署此映像，其大小常會在約 5GB 以上，而且沒辦法縮減。如果您加入額外的應用程式、驅動程式或其他檔案，此映像自然會更大。
那麼您將如何部署映像呢？您的網路是否擁有必要的容量呢 (10MB 網路或非切換式網路並不夠用)？如果要使用 CD，您能夠使用多少張呢？您將需要三或四張。現在 DVD (每張容量 4.7GB) 更容易製作，因此如果有 DVD 磁碟機，就可以用來進行部署 (如果沒有的話，下一次添購電腦時，請考慮加入 DVD 磁碟機)。
隨著 USB 隨身碟容量不斷增加 (如 4GB 以上的大容量) 且價格逐漸降低，使用 USB 隨身碟部署 Windows Vista 會相當容易，因為只要電腦的 BIOS 能夠支援，您就可以製作可開機的隨身碟。
最後一提的是 (雖然這點與映像大小無關)，請記住 I386 目錄已不再使用。所有元件無論是否已安裝，都會改為放置到 Windows 目錄中 (即使不是在標準的 SYSTEM32 目錄中)。當安裝新元件時，必要的檔案將從此位置抽出。

2. 安全性已增強
Windows Vista 的許多安全性增強功能將影響部署。例如，更容易在登入的使用者未具備管理員權限時，設定 Windows Vista 支援「低權限」使用者。當使用者未具備管理員權限時，某些應用程式便無法在 Windows XP 上執行，因為應用程式會假設使用者具備 C: 磁碟機和所有登錄組件的完整存取權。而使用 Windows Vista 時，嘗試寫入受限區域的應用程式會明確地將寫入的內容重新導向使用者設定檔中的其他位置。
在此要說明的第二項主要變更為，非管理員也能載入驅動程式。如此可讓使用者連接新的裝置，而不用再向支援工程師求助。
您將發現的第三項變更為，Internet Explorer® 可以使用提升的權限自動安裝 ActiveX® 控制項。新的服務可以代表使用者執行這些安裝 (當然，必須先由 IT 管理員透過群組原則允許這項操作)。
許多人目前可能在 Windows XP 上使用 Power User 權限，不過此權限與授與完整的 Administrator 權限相較之下，確實並未提供太多優勢 (在限制使用者權限方面)。因此，Windows Vista 中已移除 Power Users 群組，不過仍然可以在需要時，使用可套用至 Windows Vista 的另一個安全性範本重新建立。
有時候您會需要管理員權限，但是這並不表示您想要一直以管理權限執行。因此，Windows Vista 加入了「使用者存取控制」(User Access Control，UAC)，它會讓大部分使用者應用程式 (甚至是 Administrators) 以有限的權限執行。至於需要額外權限的應用程式，UAC 將提示您提供許可，要求以提升的權限執行的許可，或是要求可取代已登入使用者的其他使用者憑證。
Windows Vista 內建的防火牆也有增強的功能。現在，新的防火牆可以同時控制輸入和輸出流量，並且仍然可以透過群組原則完整設定。
最後要提到的是 BitLocker™ 完整磁碟區加密，這項功能會包括在 Windows Vista Enterprise 和 Ultimate 中，能夠加密整個作業系統磁碟區。如此磁碟區就只能從 Windows Vista 內部，而且在提供正確的金鑰時讀取 (該金鑰位於電腦內建的可信賴平台模組 (TPM) 1.2 晶片、USB 隨身碟，或直接輸入鍵盤中)。請注意，僅支援 TPM 1.2 或更新版本。

3. Windows Vista 已元件化
Windows Vista 中的其中一項大型結構變更，就是已完全成為元件化的作業系統。這項變更會在下列各方面影響部署。
若要設定應安裝哪些 Windows Vista 功能，則需設定要啟用的元件。[圖 1] 中顯示的新工具 (如 Windows 系統影像管理員) 即可協助進行此設定。
安全性更新、語言套件及 Service Pack 都是元件。而封裝管理員 (PKGMGR) 這類工具則可用來將這些元件套用至 Windows Vista。
圖 1 Windows 系統影像管理員
圖 1 Windows 系統影像管理員
此外，所有維修都可在離線或連線時執行。您甚至可以在 Windows Vista 未執行時套用變更至 Windows Vista 或 Windows Vista 映像。對於部屬來說，這是相當理想的方式：作業系統可以在初次開機並連線到網路之前先行修補。
驅動程式也會視為元件，因此可以輕鬆加入和移除 (甚至在離線時)。這表示您可以在部署過程中，將驅動程式加入現有映像 (甚至是剛好在電腦初次開機時)。而這項操作同樣適用大量存放裝置的驅動程式；您將不再需要單獨為了加入新的大量存放裝置的驅動程式而建立新映像。
Windows Vista 將公開更多設定，而其中大部分元件都會提供可設定的選項，因此與使用群組原則持續不斷管理的方式相較之下，能夠更容易設定安裝預設值。如需 Windows Vista 中新工具的概要，請參閱「需要與不再需要的工具」資訊看板。
需要與不再需要的工具
在此提供您將執行 Windows Vista 時使用的工具概要，以及在使用 Windows Vista 之後便不再需要的工具清單。

需要的工具：
  • SYSPREP：這是針對 Windows Vista 修改的更新版。
  • SETUP：Windows Vista 的新安裝工具，將取代 WINNT 和 WINNT32。
  • IMAGEX：建立 WIM 映像的新命令列工具。
  • Windows 系統影像管理員：建立和修改 unattend.xml 檔案的工具。
  • PEIMG：自訂 Windows PE 2.0 映像的工具。
  • Windows 部署服務：新版的 RIS，加入了部署 Windows Vista 和 Windows XP 映像，以及 Windows PE 2.0 開機映像的能力。
  • PNPUTIL：在 Windows Vista 驅動程式存放區中加入和移除驅動程式的新工具。
  • PKGMGR：同樣是新工具，這項 Windows Vista 工具可用來維修作業系統。
  • OCSETUP：此工具取代了 SYSOCMGR，可用來安裝 Windows 元件。
  • BCDEDIT：編輯開機設定資料的 Windows Vista 新工具。
  • 應用程式相容性工具組 5.0：此更新工具可讓您評估應用程式是否與 Windows Vista 相容。
  • 使用者狀態移轉工具 3.0：擷取和還原使用者狀態的更新工具，支援 Windows XP 和 Windows Vista 以及所有 Office 版本，包括 2007。
  • BitLocker：Windows Vista Enterprise 和 Ultimate 版中包含的完整磁碟區加密功能。

不再需要的工具：
  • 遠端安裝服務：RIS 已被 Windows 部署服務 (WDS) 取代，不過仍然在 Windows Server 2003 上提供傳統的支援；RIPREP 和 RISETUP 已無法在 Windows Vista 中使用。
  • 安裝管理員/記事本：改用 Windows 系統影像管理員編輯自動安裝程式設定檔。
  • WINNT.EXE 和 WINNT32.EXE：改用 SETUP。
  • SYSOCMGR：已被 OCSETUP、PKGMGR 取代。
  • MS-DOS 開機磁片：不再使用。請使用 Windows PE！

4. 文字模式安裝已不再使用
用來安裝 Windows XP 的基本程序從最早的 Windows NT® 時期開始就不曾變更。這個耗時的程序包含了初始的文字模式安裝步驟，其間會解壓縮並安裝作業系統檔案，接著建立所有登錄項目，然後套用所有安全性。而在 Windows Vista 中，此文字模式安裝階段已完全消失。取而代之的是由新的安裝程式執行安裝，並且將 Windows Vista 映像套用至電腦。
此映像套用之後，需要針對電腦進行自訂。這項自訂內容取代了之前在 Windows XP 和 Windows 2000 中稱為迷你安裝的程序，但兩者目的相同：作業系統會為它部署的特定電腦挑選必要的設定及特性。
映像準備程序也已變更。在 Windows XP 中，您會對電腦執行 Sysprep 以準備參考作業系統進行部署。而在 Windows Vista 中，您仍然會執行 Sysprep.exe (預設安裝於 C:\Windows\System32\Sysprep)，該程式會「一般化」電腦以進行複製。
Windows Vista (任何版本) 會以 DVD 提供，其為可立即安裝的一般化 (已執行 Sysprep) 映像，並且可立即部署至任何電腦。某些客戶會選擇原封不動地部署此映像 (可能會使用之前所述的維修功能插入修正程式或驅動程式)。

5. Boot.ini 已走入歷史
沒錯，Windows Vista 或新版的 Windows PE 2.0 將不再使用 Boot.ini 檔。取而代之的是新的開機載入器 bootmgr，它會從名為 BCD 的特殊檔案讀取開機設定資料。另外還會使用全新的工具 bcdedit.exe (或個別的 Windows Management Instrumentation 或 WMI 提供者) 維護 BCD 的內容。Windows PE 2.0 開機映像同樣可在 BCD 中設定，因此方便您開機進入 Windows Vista 或 Windows PE，而不需對電腦進行任何變更。這項靈活度在復原或維護時相當實用。

6. 以 XML 進行設定
在 Windows XP (及舊版的 Windows PE) 中，設定資訊是儲存在各種不同的文字檔中。這些文字檔現已取代為 XML 檔。
之前用來設定 Windows XP 安裝方式的 Unattend.txt 已取代為 unattend.xml。Unattend.xml 還會取代另外三個檔案：
  • Sysprep.inf，之前使用迷你安裝部署至電腦時，用來設定如何自訂 Windows XP 映像的工具。
  • Wimbom.ini，之前用來設定 Windows PE 的工具。
  • Cmdlines.txt，之前用來指定迷你安裝期間所執行命令的清單。
您可以從 TechNet Magazine 下載 unattend.xml 的範例，網址為：microsoft.com/technet/technetmag/code06.aspx。
不過，您仍然可以依喜好使用其他檔案。您不需要將所有設定項目都放入單一 unattend.xml 檔案中。新 XML 設定檔的高階結構描述已完整定義，其中並呈現每個階段的部署程序。實際的設定項目會在適當的作業系統元件上指定，而這些項目會從元件本身中動態出現。
使用 Windows XP 時，大部分的 IT 專業人員是使用「記事本」編輯各種不同的設定檔。您仍然可以這樣做，不過也可以使用之前提過的 Windows 系統影像管理員工具檢查 Windows Vista 映像以判斷可用的設定，並且進行各項設定。
另一項協助部署的工具為使用者狀態移轉工具 (USMT) 3.0，預計將與 Windows Vista 同時發行。這項工具同樣使用 XML 設定檔取代之前在舊版中使用的 .inf 檔。如需詳細資訊，請參閱 Migrating to Windows Vista Through the User State Migration Tool (英文)。

7. 不再有麻煩的 HAL
在 Windows XP 中，技術限制會防止建立可部署至所有電腦的單一映像。不同的硬體抽象層 (HAL) 即代表您必須維護多個映像 (如需相關的詳細資訊，請參閱知識庫文件＜執行 Windows XP 或 Windows Server 2003 安裝程式之後可以使用的 HAL 選項＞)。大部分組織的每個平台都需要兩個或三個映像 (x86 和 x64)，而儘管每增加一個映像就會增加成本與複雜度，有些組織仍然會選擇使用更多映像。
在 Windows Vista 中，這些技術限制都已消失，作業系統能夠偵測需要的 HAL 並且自動進行安裝。

8. Windows PE 規則
Windows PE 2.0 是即將隨著 Windows Vista 發行的最新版本，為部署程序的一大關鍵。甚至 Windows Vista 的標準 DVD 安裝也是使用 Windows PE 2.0，而大部分組織也將會使用它 (常會根據組織的特殊需要自訂) 做為部署程序的一部分。
與 MS-DOS® 部署相較之下，Windows PE 2.0 帶來相當多的優勢，包括不再需要花費許多時間嘗試尋找 16 位元真實模式驅動程式 (某些新的網路卡和大量存放裝置介面卡甚至已找不到這些驅動程式)。其他優勢還包括 32 位元和 64 位元網路堆疊和工具提供的更佳效能，以及大量記憶體支援。另外還支援如 Windows Scripting Host、VBScript 及超文字應用程式等工具。
Windows PE 已存在數年 (最新版 Windows PE 2005 與 Windows XP SP2 和 Windows Server 2003 SP1 同時發行)，但並非所有組織都能使用，因為它要求 Windows 桌面作業系統授權上具備軟體保證。不過 Windows PE 2.0 已不再沿用這項要求。所有組織都將能夠從 microsoft.com 下載 Windows PE 2.0，並且可自由用來部署授權的 Windows Vista 副本。
就像 Windows Vista 本身一般，Windows PE 2.0 會以元件化映像的方式提供，並且可以在連線和離線的情況下維修。而如同使用 Windows PE 2005 一般，即使 Windows PE 2.0 包括了一些新元件，您仍然可以加入數個選用的元件：MSXML 3.0、Windows 修復環境、語言套件、字型套件等。另外還提供像 peimg.exe 這類新工具，可用於維修 Windows PE 2.0。Peimg.exe 還可用來加入驅動程式 (包括大量存放裝置)，您將不再需要進行任何特殊處理。
如需 Windows PE 2.0 的詳細資訊，請參閱本期 TechNet Magazine 中 Wes Miller 所撰寫的文章 (英文)。

9. 映像的未來
使用 Windows XP 時，某些公司會使用 Systems Management Server (SMS) 2003 OS Deployment Feature Pack 的映像建立功能或協力廠商的映像建立工具。Microsoft 並未提供通用的映像建立工具。不過，在 Windows Vista 中這種情況已有所改變：已建立新工具以支援 Windows Imaging (WIM) 檔案格式。與許多其他映像格式不同的地方在於，WIM 映像是以檔案為主，因此可套用到現存的分割區而不會造成破壞。這在部署程序中是相當大的優勢，因為使用者狀態可以儲存在本機上，而非網路伺服器上，如此就能避免部署時經常成為最大網路流量的來源。
由於 WIM 檔是以檔案為主的映像，因此自然不是以磁區為主，也就不再有不同大小磁碟或分割區所造成的問題。WIM 映像僅包含單一磁碟區或分割區的內容，因此如果您要擷取多個分割區，則要為每個分割區建立個別的映像。不過，每個映像都可以儲存在相同的 WIM 檔中，因為 WIM 檔案格式支援每個檔案包含多個映像。
WIM 檔案格式還支援單一執行個體存放區，因此重複的檔案 (甚至是來自不同的映像) 會自動移除。在這項技術與運用的進階壓縮技術之間，WIM 映像通常比其他工具建立的映像小。然而，由於需要額外的處理，因此也會花費較長的時間建立。這項以效能交換容量的方式相當公平，因為您通常只會擷取一次映象，然後多次部署，也因此能夠實際減少網路流量。
IMAGEX 命令列工具會連接低階的 WIMGAPI API (已完整記錄並同樣於自訂工具中使用)，並且用來建立和操作 WIM 映像。此工具還提供裝載 WIM 映像做為檔案系統的機制。裝載之後，就能讀取映像並使用標準的 Windows 工具進行修改，因為其外觀就像一般抽取式媒體磁碟機。此設備提供了全新的維修良機。

10. 部署為非語言相關
Windows XP 以兩種方式支援不同的語言。您可以選擇部署當地語系化的 Windows XP 版本 (每種語言需要不同的映像)，或是部署已加入語言套件的英文多語言使用者介面 (MUI) 版本。這兩種方法各有優劣，但是在大部分情況下，需要支援多種語言的組織會採用 MUI 方式，處理執行核心為英文之作業系統的限制。僅使用一種語言的組織通常會選擇僅使用當地語系化的版本。
現在有了 Windows Vista，整個作業系統就會是非語言相關。此非語言相關核心加入了一個或多個語言套件，以建立部署的映像 (雖然只有部分 Windows Vista 版本支援多種語言)。
維修 Windows Vista 同樣也是非語言相關，因此在許多情況下，所有語言只需要一個安全性更新。而設定也是非語言相關，因此一個 unattend.xml 就能用於所有語言。

提供說明
上述各項變更表示您在 Windows XP 中慣用的映像建立和部署程序需要更新。在某些情況下，這些可能只是小範圍的更新，但其他情況下 (例如使用 cmdlines.txt 的 MS-DOS 程序) 就可能需要大幅變更。為了提供協助，Microsoft 建立了新工具、指導及逐步程序。這些都包含在 Solution Accelerator for Business Desktop Deployment (BDD) 2007 中。
BDD 2007 將部署程序細分成更容易管理的工作，讓不同的團隊管理各個元件。另外還會提供每個團隊指導、檢查清單及工具，以協助執行其工作 (請參閱 [圖 2])。
圖 2 BDD 2007 將部署程序細分成更容易管理的工作
圖 2 BDD 2007 將部署程序細分成更容易管理的工作
目前您可以註冊開放的 Beta 程式，然後從 connect.microsoft.com 下載 BDD 2007。下載中包含所有需要的 Windows Vista 部署工具，包括 Windows PE 2.0、ImageX、Windows 系統影像管理員及 USMT 3.0，連同說明如何在端對端程序中使用這些工具的文件。BDD 2007 的最終版本預計將會與 Windows Vista 在同一時間發行。如需瞭解 BDDWorkbench 的細節，請參閱 [圖 3]。
圖 3 BDDWorkbench 可協助您管理多種部署情況
圖 3 BDDWorkbench 可協助您管理多種部署情況
BDD 2007 的目標為單純化。即使您沒有現有的映像建立和部署程序，還是能使用 BDD 迅速建立一項程序。以下提供兩種部署方法：
  • 輕觸式：為完全重新撰寫的方法，需要使用者互動才能啟動部署。這種方法不需要任何特殊的基礎架構 (雖然它是運用 Windows 部署服務，即下一版的遠端安裝服務 (RIS))。
  • 零觸式：不需要使用者介入，分布於 SMS 2003 OS Deployment Feature Pack 上層。
BDD 2007 中的新功能包括驅動程式存放及插入、完整的電腦備份處理、所有 Windows Vista 部署工具的整合等。BDD 2007 將包括它所有自動化工具的完整原始程式碼，因此您可以根據特殊需要進行修改，或複製並貼入自己的方案。原始程式碼將持續提供不受限制。
如需 BDD 2007 的詳細資訊，請參閱 TechNet 桌面部署中心 (英文)。

Michael Niehaus Michael Niehaus 在 Microsoft 的核心基礎結構解決方案小組擔任系統設計工程師。他負責開發 Business Desktop Deployment 的最佳實作、工具及指令碼。您可以透過電子郵件與他聯繫：michael.niehaus@microsoft.com。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 Windows Vista: 利用 Windows Vista 新的安全性功能保護您的個人電腦
Windows Vista Justin Harrison

利用 Windows Vista 新的安全性功能保護您的個人電腦
摘要:
  • 使用 Windows 資訊安全中心
  • 設定和管理使用者帳戶控制設定
  • 使用 Windows Defender 掃描間諜軟體

在數年前，Microsoft 總裁 (也是當時的首席軟體架構設計師) 比爾蓋茲指示員工將「值得信賴的運算技術」作為公司的最高指導原則。隨著這項聲明，Microsoft 開發軟體的方式有了一系列的改變。
Windows Vista™ 是第一套完全在安全性開發生命週期 (SDL) 的指導方針下開發出的作業系統，其著重安全性的工程程序將安全性視為軟體設計的首重要務；所有廣泛部署的 Microsoft 產品都必須遵循這些指導方針 (如需有關 SDL 的詳細資訊，請見 The Security Development Lifecycle 一書，作者 Michael Howard 和 Steve Lipner，Microsoft Press®，2006)。
Windows Vista 還包括新的和升級的內建安全性技術，會主動偵測和防止安全性威脅。這些變更代表 Windows Vista 是目前為止最安全的 Windows® 版本。本文中將討論新的安全性 [控制台] 小程式、Windows 資訊安全中心及內建的防護，包括 Windows Defender、Windows 防火牆，以及使用者帳戶控制。

安全性控制台
當您開啟 Windows Vista 中的 [控制台] 時，將會發現 [控制台] 整理成十個功能區，其中大部分與安全性相關的小程式都分佈在 [安全性]、[程式集] 及 [網路及網際網路] 之間。您可以使用 [安全性] 小程式存取許多保護 Windows Vista 的新安全性技術，如 [圖 1] 所示。
Figure 1 Windows Vista 中的安全性技術 (Close Figure 1)

功能 | 說明
資訊安全中心 | 檢查更新、檢查安全性狀態、開啟自動更新、檢查防火牆狀態、喚醒時要求密碼。
Windows 防火牆 | 開啟或關閉 Windows 防火牆、允許程式通過 Windows 防火牆。
Windows Update | 開啟自動更新、檢查更新、檢視安裝的更新。
Windows Defender | 掃描間諜軟體及其他可能的惡意軟體。
網際網路選項 | 變更安全性設定、刪除 Cookie、清除歷程記錄。
家長監護 | 針對任何使用者設定家長監護、檢視活動報告。
BitLocker 磁碟機加密 | 開啟 BitLocker 磁碟機加密。
您也可以檢查 Windows Updates、開啟 BitLocker™ 磁碟機加密、刪除 Cookie、清除歷程記錄，以及設定喚醒電腦時提示輸入的密碼。
[安全性] 小程式還可讓您輕鬆存取資訊安全中心，是您用來管理和檢查電腦安全性設定及內建防護狀態的集中位置。

集中式安全性
直到 Windows XP Service Pack 2 (SP2) 中提供資訊安全中心之前，處理所有 Windows 安全性設定一直是十分棘手的工作。現在，您只需要資訊安全中心就能集中管理重要的 Windows 安全性設定，而且在 Windows Vista 中更為實用。
Windows 資訊安全中心會在背景執行，並主動監控四種類別的功能，如 [圖 2] 所示。防火牆、自動更新、惡意程式碼 (病毒和間諜軟體) 防護，以及其他安全性設定 (網際網路及使用者帳戶控制設定)。
圖 2 集中管理安全性設定
圖 2 集中管理安全性設定
有了 Windows 資訊安全中心，您就能夠看見做為電腦的防火牆，或防間諜軟體和防毒解決方案執行的程式。您也可以檢查防火牆、自動更新及使用者帳戶控制設定的狀態。Windows 資訊安全中心的獨特之處在於，除了內建的 Windows 技術之外，它還會監控協力廠商應用程式的狀態。此外還會檢查下列項目：
  • 是否已安裝防火牆，以及防火牆是否開啟。
  • 是否已安裝防毒程式，以及病毒碼是否為最新、即時掃描是否已啟用。
  • 是否已安裝防間諜軟體程式，以及定義檔是否為最新、即時掃描是否已啟用
Windows 資訊安全中心會使用兩種方法偵測協力廠商的防毒和防火牆應用程式。在手動模式中，Windows 資訊安全中心會搜尋登錄機碼以及可偵測出軟體狀態的檔案。同時會查詢傳回功能狀態之參與廠商提供的 Windows Management Instrumentation (WMI) 提供者。這表示，您可以使用非 Microsoft 解決方案處理防毒、防間諜軟體或防火牆問題，同時繼續使用 Windows 資訊安全中心監控及防護電腦。
Windows 資訊安全中心可藉由群組原則控制。根據預設，在網域環境中為停用狀態。若要開啟 Windows 資訊安全中心，請存取 [電腦設定\系統管理範本\Windows 元件\資訊安全中心] 節點。開啟資訊安全中心的原則名稱為 [開啟資訊安全中心 (僅網域 PC)]。
Windows 資訊安全中心還會監控 [使用者帳戶控制] 設定以及 [網際網路安全性] 設定的狀態。[使用者帳戶控制] 可讓您以標準使用者而非管理員的身分使用電腦，這樣做較為安全。身為標準使用者，您所做的任何變更都不會影響整個系統，而且您安裝的任何軟體能造成的傷害也相當有限。
在 Windows Vista 中，如果您以標準使用者身分執行不屬於網域的電腦，而軟體需要執行會影響整個系統的動作，則作業系統會提示您輸入管理員帳戶的密碼。如果您以管理員身分執行，Windows Vista 會提示您提供執行整個系統動作的許可，如此您就會在執行之前注意到 (及允許) 這個動作。
使用者帳戶控制是由群組原則在網域環境中進行管理。如果電腦不屬於網域的一部分，則會由本機安全性原則處理。原則設定可在 [本機安全性原則] 編輯器或 [群組原則] 編輯器中的 [電腦設定\系統設定\本機原則\安全性選項] 找到。您可在 [控制台] 的 [系統和維護] | [系統管理工具] 下找到 [本機安全性原則]。
如 [圖 3] 所示，Windows 資訊安全中心會監控許多網際網路安全性選項。
Figure 3 網際網路安全性設定 (Close Figure 3)

Windows 資訊安全中心會監控下列網際網路設定：
下載簽署的 ActiveX 控制項
下載未簽署的 ActiveX 控制項
初始化未針對指令碼標示為安全的指令碼和 ActiveX 控制項
安裝桌面項目
啟動應用程式和不安全的檔案
啟動 IFRAME 中的程式和檔案
軟體頻道權限
如果選項變更為不安全的狀態，[網際網路內容] 便會指出「您的安全性設定會讓電腦處於風險 (Your security settings put your computer at risk)」，而 Microsoft Internet Explorer® 將顯示資訊列，告訴您「您目前的安全性設定會讓電腦處於風險。請按一下此處變更您的安全性設定... (Your current security settings put your computer at risk.Click here to change your security settings...)」。Windows 資訊安全中心還會通知您「您未使用建議的安全性設定 (You're not using recommended security settings.)」。如果您開啟 [網際網路安全性設定]，不安全的設定將會以紅色強調 (請參閱 [圖 4])。
圖 4 強調的不安全設定
圖 4 強調的不安全設定
Windows 資訊安全中心可以將不安全的安全性設定還原為安全狀態。只要按一下 [立即還原我的網際網路安全性設定 (Restore my Internet security settings now)] 即可完成這項操作，如 [圖 5] 所示。
圖 5 移除危險的設定
圖 5 移除危險的設定

Windows Defender
Rootkit、木馬程式、間諜軟體及其他惡意軟體已成為令人頭痛的問題。它們會讓您的資訊處於風險中、降低電腦的效能，且可能造成系統當機。Microsoft 於 2004 年與 Giant Software 合作提供防間諜軟體技術以保護客戶。您會發現 Windows Vista 中內建了這項稱為 Windows Defender 的新技術 (同時也可供 Windows XP 的使用者下載)。
安裝 Windows Vista 之後，不必立即變更任何 Windows Defender 設定。由於 Windows Defender 會預先設定為以最低限度的中斷提供最大程度的安全性，因此您可以專注在使用電腦上，而不必忙著保護其安全。Windows Defender 啟動後隨即提供即時防護，且會在每天凌晨兩點自動檢查及下載更新的間諜軟體定義，並自動移除所有高威脅性的風險。您可以在 Windows Defender 中選取 [工具] | [一般設定] 來調整這些設定。
即時防護表示 Windows Defender 會持續小心監控電腦上可疑的行為。它會使用 [圖 6] 中列出的九種安全性代理程式監控系統的各個部分是否有間諜軟體特徵的應用程式行為。Windows Defender 安全性代理程式會共同監控幾乎所有常見的間諜軟體進入點。
Figure 6 Windows Defender 安全性代理程式 (Close Figure 6)

代理程式 | 監控
Internet Explorer 設定 | 瀏覽器安全性設定。
Internet Explorer 下載 | 搭配 Internet Explorer 使用的應用程式，例如 ActiveX 控制項和軟體安裝應用程式。
Internet Explorer 附加元件 (瀏覽器協助程式物件) | 啟動 Internet Explorer 時自動執行的應用程式。
自動啟動 | Windows 啟動時啟動的應用程式，包括透過登錄和 Windows 啟動資料夾啟動的應用程式。
系統設定 | Windows 中與安全性相關的設定。
服務和驅動程式 | 與 Windows 和應用程式互動的服務和驅動程式。
Windows 附加元件 | 與 Windows 整合的軟體公用程式。
應用程式執行檔 | 啟動時的應用程式及其執行檔。
應用程式登錄 (API 攔截) | 應用程式可自行插入並執行之作業系統中的檔案和工具。

威脅回應
Windows Defender 會在發現可能的惡意軟體或偵測到可疑的行為時警示您。當無害的 (低威脅) 變更發生時，Windows Defender 會在系統匣中顯示驚嘆號通知您。如果是更嚴重的威脅 (中或高)，Windows Defender 便會根據威脅等級顯示黃色或紅色對話方塊，如 [圖 7] 所示。這些威脅需要立即回應。
圖 7 紅色視窗表示高度威脅
圖 7 紅色視窗表示高度威脅
Windows Defender 執行的所有動作都會記錄在系統事件日誌中，且其來源為 "Windows Defender"。這類動作包括定義更新和間諜軟體掃描及移除。
Windows Defender 威脅警示相當聰明，因此您可以透過它們繼續執行工作。列出的威脅可能有許多個，而您可以在威脅警示對話方塊中選擇回應所有威脅 ([全部移除])。您也可以設定威脅警示根據未分類的威脅和已知允許執行的軟體分別回應。若要設定威脅警示，請開啟 Windows Defender，然後按一下 [工具 | 選項]。向下捲動到 [即時防護選項] (Real-time protection options)，然後選擇 Windows Defender 是否應通知您尚未按風險分類的軟體，以及允許執行的軟體對您的電腦所做的變更。
請注意，如果 Windows Defender 未正確分類您建立或使用的應用程式，您可以到 microsoft.com/athome/security/spyware/software/isv/cdform.aspx (英文) 提出廠商爭議。如果將應用程式誤認為間諜軟體，您可以在 microsoft.com/athome/security/spyware/software/isv/fpform.aspx (英文) 提出誤報。

隨選防護
雖然 Windows Defender 會小心監控可能的惡意軟體，但您也可以在需要時隨時啟動間諜軟體掃描。Windows Defender 提供三種類型的掃描：
  • 「快速掃描」會迅速檢查電腦上最有可能受到間諜軟體感染的位置。
  • 「完整掃描」會掃描硬碟上的所有檔案、執行中的應用程式、登錄以及其他位置。
  • 「自訂掃描」可讓您掃描特定檔案或資料夾，並且會在啟動時自動執行「快速掃描」。
若要起始掃描，請啟動 Windows Defender，然後按一下 [掃描 (Scan)] 按鈕旁的向下箭頭，接著選取您要啟動的掃描類型，如 [圖 8] 所示。
圖 8 選擇掃描類型
圖 8 選擇掃描類型
Windows Defender 在掃描期間偵測到威脅時，會顯示威脅的說明，以及您可採取以解決威脅的動作。根據預設會顯示可採取的最佳動作。如果找到多個威脅，您可以選取回應並按一下 [套用動作 (Apply Actions)] 一次套用所有動作，或是按一下 [全部移除 (Remove All)] 移除所有威脅。您可採取的動作包括：
  • 移除：從系統中將威脅完全移除。
  • 忽略：忽略威脅。下一次掃描時，Windows Defender 會再次偵測到該威脅。
  • 隔離：暫時停用威脅。您可以藉此測試移除威脅對於系統是否會有任何不良影響。而且可以固定從 Windows Defender 內還原動作。
  • 永遠允許：停止偵測威脅並將它加入允許項目清單中。您可以按一下 Windows Defender 中的 [工具] | [選項]，從允許項目清單中移除項目。

防止網路入侵
Windows Vista 中的 Windows 防火牆是雙向狀態的防火牆，包含了許多比 Windows XP 版更進階的功能。在 Windows Vista 中，Windows 防火牆會同時篩選連入和連出流量。您還可以設定下列規則：
  • Active Directory 帳戶和群組
  • IP 通訊協定編號
  • 特定類型的介面
  • 服務
  • 根據類型和程式碼的 ICMP 和 ICMPv6
  • 來源和目的地 IP 位址
  • 所有 TCP 或 UDP 通訊埠，或指定的通訊埠
在 Windows Vista 中，您還可以透過例外清單允許特定程式存取網路或拒絕流量。若要存取例外清單，請按一下 [開始] | [控制台] | [安全性]，然後按一下 [允許程式通過 Windows 防火牆 (Allow a program through Windows Firewall)]。
根據預設，Windows 防火牆會封鎖所有連入流量 (除非是明確要求的或符合規則)，並且允許所有連出流量 (除非符合規則)。
Windows Vista 包括稱為「具有進階安全性的 Windows 防火牆」的新 Microsoft Management Console (MMC) 嵌入式管理單元 (請參閱 [圖 9])，可讓管理員設定遠端電腦上的 Windows 防火牆設定。若要存取新的嵌入式管理單元，請按一下 [控制台] 中的 [系統和維護]，然後按一下 [系統管理工具]，再按一下 [具有進階安全性的 Windows 防火牆]。
圖 9 建立進階規則保護電腦不受網路威脅
圖 9 建立進階規則保護電腦不受網路威脅
若要加入規則，您也可以使用群組原則編輯器嵌入式管理單元存取 [電腦設定\Windows 設定\安全性設定\具有進階安全性的 Windows 防火牆]。您甚至可以使用 netsh advfirewall，從命令列設定新的 [進階安全性] 設定。
每次連線新的網路時，Windows Vista 都會建立該網路專屬的設定檔。當您再次連線到該網路時，Windows Vista 就會使用該設定檔中儲存的設定。連線新的網路時，作業系統會詢問的其中一項首要事項是此為公用或私人網路。這會決定 Windows 防火牆載入設定和規則的設定檔。如果您要編輯設定檔，請按一下 [具有進階安全性的 Windows 防火牆] 嵌入式管理單元中的 [Windows 防火牆內容]，然後按一下 [私人設定檔] 或 [公用設定檔] 索引標籤，如 [圖 10] 所示。
您可以在連線之後，依喜好從 [網路和共用中心] 變更與網路相關的設定檔。若要執行這項操作，請至 [控制台] | [網路和網際網路] | [網路和共用中心]。若要變更網路設定檔，請按一下已連線網路名稱旁的 [自訂]。
圖 10 根據網路類型自訂防護
圖 10 根據網路類型自訂防護

結論
Windows Vista 是自數年前「值得信賴的運算技術」聲明後的第一套完整的作業系統版本。Windows Vista 是遵照 Security Development Lifecycle (安全性開發生命週期) 指導方針所開發，且其中包含多項內建的防護，例如 Windows Defender、Windows 防火牆，以及使用者帳戶控制，並同時為獨立式系統與網域內部的系統提供無可比擬的防護。Windows 資訊安全中心、Windows 防火牆和使用者帳戶控制全都提供群組原則設定，可讓您在網域環境中有效部署，或在個人電腦上進行相當廣泛的設定。
SpyNet 社群
安全性威脅日新月異，有時候甚至每天更新也無法掌握電腦可能遭遇的所有安全性威脅。為了在間碟軟體定義的更新外提供更多的保護，Microsoft 亦在 SpyNet 社群中聚集使用者，這是一個分享間諜軟體資訊的線上群組。
Spynet 社群是自願性的全球 Windows Defender 使用者社群，會向 Microsoft 提報間諜軟體的新發現。參與這個社群的使用者在決定哪些可疑應用程式最後將分類為間諜軟體方面，扮演了相當重要的角色，同時還協助迅速發現新的威脅，讓所有 Windows Defender 使用者獲得更佳防護。
SpyNet 社群為「選擇加入」(Opt-in) 形式。.您必須明確決定參與。您可以選擇不成為成員，如此一來，當您可能已遭受間碟軟體感染時，任何相關資訊都不會傳送至 SpyNet。如果電腦上發現未分類的可能惡意軟體，您將不會收到通知。未分類的可能惡意軟體最後可能會在定期的間諜軟體定義更新中分類。
如果您選擇參與，共有兩種等級的成員資格：
進階成員資格： 參與者傳送關於未分類軟體及所採取動作的資訊至 Microsoft。進階參與者會收到可能不安全的最新未分類軟體的警示。某些個人資訊可能會傳送出去，但是 Microsoft 不會使用這些資訊與您連絡。
進階成員會收到移除統計資料，顯示其他進階成員遭遇相同威脅時的反應方式。這項資訊可幫助您決定目前未分類的可能惡意軟體是否具有危險。例如，如果新應用程式將散佈到網際網路，而 Windows Defender 偵測到該應用程式並視為可疑，則部分進階使用者會將它提報至 SpyNet 並將它移除。SpyNet 將告訴您有多少進階成員提報並移除該應用程式，如此您就能運用這項資訊好好決定接下來的動作。
基本成員資格： 關於可疑軟體的基本資訊會傳送至 Microsoft。個人資訊也可能會傳送出去，但是 Microsoft 不會使用這些資訊與您連絡。基本參與者不會收到未分類軟體的警示。
若要加入 Spynet 社群，請開啟 Windows Defender 並選取 [工具]，然後按一下 [Microsoft SpyNet]。

Justin Harrison Justin Harrison (justin@harrison.org) 是 Windows 安全性、數位媒體技術與數位文件方面的專家。他曾任職於 GE Energy 以及 Microsoft 的數位文件團隊與娛樂遊戲團隊。


 Windows Vista: 利用「使用者帳戶控制」實現非系統管理夢想
Windows Vista Alex Heaton

利用「使用者帳戶控制」實現非系統管理夢想
摘要:
  • 為何應避免以系統管理員身分執行
  • 嘗試以標準使用者身分執行來解決問題
  • 「使用者帳戶控制」的運作方式

對大多數的 IT 組織而言，讓較少的使用者以系統管理員權限執行是個值得實現的目標。雖然 IT 系統管理員普遍認為將使用者限制成標準使用者帳戶是可行之策，但還是約有 80% 的人以系統管理員帳戶部署桌上型電腦，導致這些
電腦更容易感染惡意程式且更難管理。然而要避開系統管理員帳戶卻不是那麼簡單。如果您稍加嘗試，就會發現有許多潛在的障礙。
首先是應用程式相容性的問題。由於多數應用程式都是使用系統管理員帳戶進行撰寫與測試，標準帳戶甚至可能無法執行這些程式 (這是最常見的情況，因為應用程式會試圖寫入受限制區域，如 Program Files 目錄或 HKLM 登錄機碼)。
其次，舊版的 Windows® 均過度限制使用者，禁止其設置大部分的設定。標準使用者必須求助於支援人員，否則無法變更時區和電源設定、連接安全的無線網路，或安裝 ActiveX® 控制項，而尋求支援需負擔相關成本。
所幸 Windows Vista™ 解決了這些問題。即便使用者沒有系統管理員帳戶，您也可利用 Windows Vista 的「使用者帳戶控制」(UAC) 及其他管理技術輕鬆支援和管理這些桌上型電腦、提高標準使用者的工作產能，且實現這一切完全不需要放寬安全性，不必依循慣常方法修改存取控制清單 (ACL) 為使用者提供更高彈性的可自訂化存取。接著我們就來仔細瞧瞧 Windows Vista 如何減緩存取控制方面的一些問題。

以模擬方式改善相容性
由於具有「檔案及登錄模擬」功能，在 Windows XP 上無法以標準使用者身分執行的應用程式，大多完全不必修改就能在 Windows Vista 上執行。在 Windows XP 中，多數應用程式一旦試圖寫入檔案系統的受保護區域及禁止標準使用者存取的登錄時便會中斷執行。Windows Vista 則會將寫入動作 (及後續的檔案或登錄讀取動作) 重新導向到使用者設定檔內的某個特殊位置，藉以改善相容性。例如，若應用程式試圖寫入 C:\program files\contoso\settings.ini 但使用者無權寫入該目錄，寫入動作將重新導向到 C:\Users\使用者名稱\AppData\Local\VirtualStore\Program Files\contoso\settings.ini。如果應用程式試圖寫入 HKLM\Software\Contoso\，該動作便會自動重新導向到 HKCU\Software\Classes\VirtualStore\MACHINE\Software\Contoso。[圖 1] 概述了重新導向流程。此外，「Windows Vista 軟體標誌認證計劃」(Certified for Windows Vista Software Logo Program) 將要求應用程式不需模擬就能以標準使用者身分執行；若未符合這項要求，便不頒發該標誌給應用程式。
圖 1 檔案及登錄模擬流程
圖 1 檔案及登錄模擬流程

標準使用者可以執行更多作業
Windows Vista 賦予了標準使用者帳戶更多權限，因而使用者無須求助於支援人員，也不必仰賴系統管理員帳戶提供完整權限組，即可執行一般工作。新權限包括：可檢視系統時間和行事曆、變更時區、修改無線網路安全性設定、變更電源管理設定，以及從 Windows Update 下載和安裝重大更新。
此外，磁碟重組在 Windows Vista 中屬於自動排程的程序。需要系統管理員權限才能執行的動作將標註盾牌圖示，讓使用者得知自己能否變更哪些設定值。

ActiveX 控制項安裝
對 ActiveX 控制項進行集中管理可能尤為棘手，因為控制項不僅更新頻繁，且必須先重新封裝方可透過軟體發佈程式如 Systems Management Server (SMS) 或透過群組原則來散發。Windows Vista 隨附選用元件稱為 ActiveX Installer 服務，讓 IT 系統管理員能使用群組原則來指定允許標準使用者從哪些網站安裝 ActiveX 控制項。如需使用 ActiveX Installer 服務，請執行下列步驟：
  1. 在用戶端電腦上啟用 ActiveX Installer 服務。您可以透過 [Windows 功能] 控制台小程式，或在設定桌面映像時啟用此服務。
  2. 在 [Active Directory 群組原則] 中，從 [電腦設定] | [系統管理範本] | [Windows 元件] 下選取 [ActiveX Installer 服務]，再選取 [啟用]。如今一旦原則已複寫給使用者，使用者就能從您指定的網站安裝控制項。
由於 ActiveX 控制項及其他的可執行程式碼可能會執行惡意動作，請務必謹慎使用此功能；只對您信任的廠商以及嚴格控管下的內部網路網站上才能使用。
ActiveX Control Installer 服務亦已與 Windows Vista 事件基礎結構整合，因此如果有使用者需要安裝的 ActiveX 控制項，您就會自動接獲通知。每當標準使用者試圖安裝尚未核准的控制項，服務便會在應用程式記錄檔中建立事件。在 Windows Vista 中，可將工作設定為只要觸發事件即自動傳送電子郵件或執行另一程式。藉此，您就能得知何時已發佈使用者所需的控制項，並可將該網站加入群組原則而不致嚴重停滯使用者的工作進展。有了 Windows Vista，您也能向整個企業內的多部電腦訂閱事件，以產生使用者試圖安裝之所有控制項的清單。

硬體裝置驅動程式安裝
系統管理員權限依然被普遍使用的另一個原因，是考慮到使用者常在出差旅遊時無法安裝所需的裝置驅動程式，尤其是膝上型電腦使用者。Windows Vista 提供新的 Driver Store 基礎結構，藉由靈活控制標準使用者所能安裝的驅動程式而紓解了這道難題。首先，您可以在 Driver Store 中預先填妥信任的驅動程式，讓使用者能在必要時安裝核可的驅動程式。其次，您可以利用群組原則賦予標準使用者權限，允許其安裝各類裝置 (如印表機)，甚至指定裝置硬體識別碼 (如核可的快閃磁碟機)。
由於 Windows Vista Driver Store 係位在每一部用戶端電腦硬碟上系統內附驅動程式和協力廠商驅動程式的受信任快取區，使用者不需具備系統管理員權限就能進行安裝。如果要將驅動程式接移到 Driver Store，請將驅動程式載入離線映像，或透過網路將驅動程式動態更新到連線用戶端。對於離線映像，使用封裝管理員可將驅動程式分毫不差地接移到 Driver Store。
對於連線映像，請使用命令列公用程式如 pnputil.exe 或 DevCon，再搭配使用軟體發佈應用程式來新增、更新或刪除 Driver Store 中的驅動程式。為了進一步提升驅動程式接移程序的效率並賦予彈性，Windows Vista 允許 IT 部門和協力廠商簽署驅動程式封裝完整性。
根據預設，只有具備系統管理員權限的使用者可新增驅動程式到 Driver Store。但對於某些使用者，特別是行動使用者而言，於外出期間很可能急需安裝印表機之類的裝置。藉由新的群組原則設定，Windows Vista 能讓您賦予標準使用者彈性，於必要時安裝其驅動程式尚未接移到 Driver Store 但已核可的裝置。若要委派裝置驅動程式接移權限，請開啟 [群組原則] 介面，再瀏覽到 [電腦設定] | [系統管理範本] | [系統] | [驅動程式安裝] | [允許非系統管理員安裝這些裝置的驅動程式 (Allow non-administrators to install drivers for these devices)]。您必須知道裝置類別的 GUID，以便允許標準使用者接移和安裝該類裝置。您可以上網到 MSDN ® 查閱裝置類別，或者如果裝置已安裝到您的電腦，請開啟 [裝置管理員 | 內容] 視窗。按一下 [詳細資料] 索引標籤，然後選取標示為 [裝置類別 GUID] 的下拉式清單。您也必須確定，用於簽署驅動程式的憑證已經位於用戶端電腦的「受信任的發行者」存放區 (可透過群組原則進行管理)。
Windows Vista 的這些先進功能如今為標準使用者提供了安裝裝置所需的彈性，因此您可以將更多使用者移到受管理的桌面環境。

桌面鎖定層級
即使 Windows Vista 作業系統有了上述改進，並非全部組織都能以標準使用者權限部署所有的 Windows Vista 桌面。某些組織可能仍有應用程式需要系統管理員權限，或其內部使用者 (如開發人員) 必須安裝自己的軟體。沒問題！Windows Vista 允許多種層級的桌面控制，可透過使用者帳戶選擇和群組原則進行設定，各種層級都比 Windows XP 中具有完全控制權的系統管理員帳戶提供更高管理性和安全性。大多數與 UAC 設定相關的系統設定均可在「安全性原則編輯器」(secpol.msc) 中找到，如 [圖 2] 所示。
圖 2 安全性原則編輯器
圖 2 安全性原則編輯器
第一種控制層級稱為「管理核准模式」。這種模式藉由預設以標準使用者身分啟動程式，並於程式試圖以系統管理員權限執行時警示使用者，進而降低某些類型惡意程式的攻擊威脅。在此模式下，如果使用者執行的程式需要系統管理員權限，您可以透過事件日誌進行稽核。但請記住，儘管應用程式是以標準使用者權限執行，這種模式不比真正的標準使用者帳戶來得安全。使用者仍具有系統管理員權限，因而得以變更原則設定、安裝未核准的軟體，且無法杜絕 Rootkit 之類高殺傷力的惡意程式暗地安裝。
下一種層級以第一種層級為基礎，但利用群組原則對使用「受信任的發行者」存放區內的憑證進行簽署的程式限制提高權限。這有助於遏止未經簽署的惡意程式取得系統管理員權限，並可防止使用者隨意安裝軟體。不過，在以系統管理員帳戶身分執行的情況下，精通門道卻心懷不軌的使用者或複雜的惡意程式可能會透過停用原則 (至少暫時停用) 來執行未經授權的動作。因此，唯有當您情非得已無法使用真正的標準使用者帳戶時，才使用上述兩種層級做為解決問題的過渡時期措施。
下一種安全性層級是將使用者從系統管理員帳戶剔除並指派為標準使用者。UAC 有一項功能稱為 Over the Shoulder Credentials Dialog，預設會在標準使用者啟動需要系統管理員認證的程式時出現。標準使用者將被封鎖而無法執行動作，但若他們知道系統管理員的使用者名稱和密碼，只要輸入就能繼續執行動作。可能用到這項功能的典型情況像是在外出差旅遊的膝上型電腦使用者。例如，如果使用者在途中急需安裝特定軟體，則可電洽支援人員索取本機系統管理員帳戶的密碼，再輸入該密碼就能執行程式了 (請參閱 [圖 3])。若您已將系統管理員密碼告訴使用者，建議您備妥各項處理流程和工具，以便在使用者重新連接網路時重設系統管理員密碼，並且記錄所有用過系統管理員認證來執行的程式。另外尚請注意，如果 PC 感染了惡意程式，系統管理員可能會遭誘騙，而在非自願的情況下將系統管理員權限授與惡意程式。
圖 3 要求輸入系統管理員密碼
圖 3 要求輸入系統管理員密碼
您也可以選擇利用群組原則停用認證對話方塊，將 [使用者帳戶控制:標準使用者之提高權限提示的行為 (User Account Control: Behavior of the elevation prompt for standard users] 設定為 [自動拒絕提高權限要求 (Automatically deny elevation requests)] (請參閱 [圖 4])。我們建議大多數部署標準使用者桌面的企業以這種方式設定 UAC。多數組織均可藉由這麼做，避免使用者電洽支援人員索取 IT 部門不願透露的密碼。
圖 4 利用群組原則封鎖應用程式
圖 4 利用群組原則封鎖應用程式
如需最堅固的桌面鎖定層級，您可以使用 UAC 和標準使用者帳戶再結合 Windows 軟體限制原則 (SRP)。藉助於 SRP，企業就能更進一步阻止執行任何未被具體允許的軟體。SRP 的設計用意是針對未符合基於 Authenticode® 憑證、雜湊、路徑或網際網路區域等特定條件的軟體進行封鎖使其無法執行。SRP 係透過群組原則進行管理，而您只需經由簡單的操作即可建立非常強的原則，以防未經核准的程式安裝和執行。典型的原則可能會禁止所有的可執行檔，但下列路徑中的可執行檔除外：%WINDIR% 和 %PROGRAMFILES%，並將原則套用到系統管理員以外的所有使用者。
設定妥這項原則後，IT 人員仍可將其所需的任何軟體程式安裝於 Program Files 目錄，而不必將每個 .exe 逐一加入白名單 (已核准項目的清單) 中。且由於標準使用者無權存取這些目錄，而無法將程式移到其他可執行的位置。
您或許已發現本文至今尚未提到 Power Users 群組。這是因為 Windows Vista 不再使用 Power Users 群組。某些組織之所以使用 Power Users 群組是為了限制系統管理員權限。儘管賦予部分人員 Power User 權限可防止其未經核准設定系統組態，這些使用者 (或以 Power User 認證身分執行的惡意程式) 或許仍能取得其他權限，甚至取得完整的系統管理員認證。因此，Windows Vista 只設置系統管理員和標準使用者做為兩種主要帳戶類型。

桌面管理基礎結構
有了「檔案及登錄模擬」功能、新的 Driver Store 基礎結構，再加上前面討論的其他功能，要以標準使用者帳戶身分部署 Windows Vista 桌面就變得更容易了。然而即使運用這些技術，如果沒有管理基礎結構 (工具、處理程序和人員) 足可支援未能親自執行作業的使用者，您仍無法完全支援標準使用者環境。您需要考量的一些事項包括：
軟體安裝 如果使用者無法自行安裝軟體，您必須提供其他辦法。有個辦法不需要藉助任何其他管理軟體，那就是使用群組原則。您可以透過群組原則，將程式加入 [新增/移除程式] 清單中。使用者若以這種方法安裝程式，系統便會啟動該使用者所需的較高權限協助完成安裝。要擁有更完善的方案，您也可以使用 SMS 或類似產品。某些方案甚至允許您建立自助服務入口網站，讓標準使用者可挑選想要安裝的軟體。
軟體更新 您必須提供可在 PC 上安裝更新的辦法，而不是傳送電子郵件提醒使用者「請安裝此更新！」如果要管理與部署大部分的 Microsoft 更新，您可以透過 Windows 伺服器免費下載 Windows Server Update Services 來使用。如需部署範圍更廣的更新，同樣可考慮使用桌面管理產品，像是 SMS。
支援流程和人員配置 當使用者電洽支援人員尋求解決導致效能問題的事件或告知希望安裝新軟體時，單靠電話溝通大概都無濟於事，因為使用者並沒有足夠的權限。您的 IT 部門必須多加利用遠端協助和遠端系統管理工具來診斷問題及變更設定。雖然支援人員可以使用遠端桌面從遠端變更系統管理設定，但因登入的標準使用者無法核准需要系統管理員權限的動作提示，所以 Windows 遠端協助的用法也有所不同。
規劃明確而有效率的流程來處理原則例外狀況是非常重要的。例如，假定行銷部門有人需要安裝新的試用版圖形設計工具，以評估是否值得該部門採購。該由誰核准安裝這個軟體呢？部門經理、直屬主管還是 CIO？究竟如何安裝軟體，而又得等多久才能開始安裝？我們建議的作法是建立簡單的核准工作流程，並與支援部門的問題追蹤系統整合。基本工作流程如下：
  1. 使用者提出希望安裝程式的要求，附上安裝程式的連結 (安裝程式位於使用者的本機硬碟或光碟機內)，並證明該軟體不是非法取得且用途正當。
  2. 傳送要求鑒請經理核准。
  3. 轉寄要求給 IT 部門的應用程式組長，鑒請檢查以確認毫無任何已知相容性問題、執行病毒掃描，並確定公司尚未購買該程式的網站使用授權，也未曾向其他廠商購買類似程式。
  4. 轉寄要求給技術支援人員，鑒請從遠端起始安裝，並於安裝完成後通知使用者試用軟體。
為了建立工作流程介面，您可以編寫動態網頁，或購得市售商業支援或問題追蹤套裝軟體。對於受管理與未受管理的環境，您也必須採用不同的人員配置。順利的話，您只需要少數技術人員，就能對不穩定或受感染的 PC 進行實際診斷或重新製作映像。不過，起初您可能必須配置較多人力進行軟體封裝與部署。
從長遠來看，由於電腦能夠長期維持穩定，您所付出的支援成本應會較低，但支援人員一開始可能得應付使用者經常來電尋求協助設定組態的局面。等到您依照使用者所需的設定配置了桌面映像和群組原則後，支援人員接到求助電話的次數便會逐漸減少。

企業文化
最後一個障礙不是技術層面，而是心理層面。某些使用者可能會對沒有系統管理員權限這種構想存有排斥心理。但我相信大多數的使用者不會覺得有任何差別。且如果您強制以標準使用者帳戶身分部署 Windows Vista，即可整合桌面搜尋、全新的 Aero™ (半透明) 使用者介面及針對行動使用者所做的改進，其生產力提升的好處絕對遠超過不具備系統管理員身分所帶來的任何不便。然而，若因處理流程規劃不當導致人員必須等候數週才獲准安裝軟體，那麼肯定有些員工會不太高興。
基本上，確保 PC 資產安全、杜絕使用者使用未經授權的軟體及強制遵守政府法規和內部政策是 IT 部門的責任。多數的公司將會發現，達成此目標唯一的辦法是制訂一套新原則，對擁有系統管理員權限的使用者人數加以限制。所幸，用了 Windows Vista 您就知道這有多麼容易。
其他資源
關於如何縮減系統管理員權限的說明，請參閱：
  • Aaron Margosis 的「非系統管理」部落格 - 以最低權限在桌面上執行 (英文)
  • 「使用者帳戶控制小組」部落格 (英文)
  • User Account Control Overview (英文)
  • 瞭解與設定「使用者帳戶控制」(英文)
  • 虛擬實驗室：使用者帳戶控制 (英文)

Alex Heaton 是 Windows Vista 資訊安全小組的資深產品經理。他曾擔任 Microsoft 資訊安全網站 (包括 microsoft.com/protect) 的首席網站經理，同時也是「使用者帳戶控制小組」部落格 blogs.msdn.com/uac (英文) 的撰文者之一。


 Windows Vista: 使用 Windows Vista 架設企業網路
Windows Vista Jason Leznek

使用 Windows Vista 架設企業網路
摘要:
  • 下一代 TCP/IP 堆疊
  • 使用者為主的網路工具
  • 改善網路安全性
  • 簡化網路管理工作

您還記得上一次嘗試一整天卻無法連線到公司網路的情況嗎？想像一下：無法存取電子郵件、無法瀏覽網際網路、無法使用
印表機或檔案共用。無法存取銷售資料庫中的重要資料。您根本無法工作。
網路連線能力對於大部分的人來說，是執行工作的關鍵能力。同樣地，使用者期望行動更自由，能夠隨時隨地讓公司所屬的筆記型電腦連線到任何公用或家用網路。但是，您是否對錯綜複雜的安全性生畏？
Windows Vista™ 網路功能團隊的工程師瞭解連線能力的重要性，而且從推出 Windows® 95 開始，便不斷努力提供最佳的網路功能創新。隨著 Windows Vista 的問世，網路功能變得更容易使用、更安全、更易於管理，並且能針對各種網路做最大程度的調整。
發行 Windows XP 至今業已五年。其間發生了許多變更，包括使用者隨時隨地需要更普遍的無線網路功能、政府或業界制定的規範如 Sarbanes-Oxley 和 HIPAA，以及降低成本與更有效運用現行投資的需要。使用者期望網路資源「垂手可得」，對於可能發生的輕微連線問題也變得無法容忍。結果使用者較以往更富行動自由，他們不只是連線到公司網路，也可能會連線到四周的任何網路。

開始使用堆疊
Windows Vista 擁有更新的 TCP/IP 堆疊實作，其中包括大幅改善的功能，可解決數項最常見的網路問題，提供更高的效能與輸送量、原生 Wi-Fi 架構，以及檢查網路封包的 API。
若要充分運用網路，則需要對 TCP/IP 組態設定進行複雜的調整。Windows Vista 會偵測網路狀況並自動最佳化效能，免除了手動進行調整的需要。在高損失率的網路上 (例如無線網路)，Windows Vista 更能從單一或多個封包損失復原。它能動態增加或減少 TCP 接收視窗，以充分運用連結。使用者透過高速/高延遲的 WAN 傳輸檔案，或從網際網路下載檔案時，會發現傳輸速度已快上許多。
Windows Vista 也已將原生無線網路架構 (原生 WiFi) 納入為核心網路堆疊的一部分。其優勢包括彈性地在多種品牌和機型的硬體上部署、不受硬體影響的相似使用者經驗，以及更可靠的協力廠商無線 NIC 驅動程式。Windows Vista 中的無線網路可集中管理，支援最新的安全性通訊協定，並且提供使用者更完整的網路經驗。
Windows 篩選平台 (WFP) 是下一代 TCP/IP 堆疊中的全新架構，其提供的 API 能讓協力廠商軟體開發人員參與 TCP/IP 通訊協定堆疊中，數個通訊層上進行的篩選決策，而不需自行撰寫核心模式應用程式。此平台還支援下一代防火牆功能，例如，驗證的通訊和以應用程式的 Windows Sockets API (應用程式為主的原則) 使用情況為主的動態防火牆設定。

提升使用者的能力
網路和共用中心 (Network and Sharing Center) 是專門讓使用者檢查網路狀態的位置，包括使用者是否已連線、連線目標為何，以及使用者位於區域網路或是網際網路上 (請參閱 [圖 1])。使用者還可以檢視電腦上各種網路服務的狀態。電腦是否可在區域網路上顯示？是否有任何共用的資料夾或印表機？使用者還可以建立或連接到現有的網路，無論是臨機操作網路或基礎結構無線網路、VPN 或家用寬頻連線。
圖 1 網路和共用中心
圖 1 網路和共用中心
Windows Vista 還可以診斷和解決許多連線問題，而不需要使用者致電服務台。「網路診斷架構」能讓 Windows Vista 從應用程式的動作判斷出連線問題的根本原因。例如，如果使用者無法連線網際網路站台，「網路診斷」將嘗試追蹤問題，從是否有作用中的無線網路和有效的 IP 位址，乃至於存取 DNS 伺服器、尋找 Proxy 伺服器，以及從網頁伺服器取得回應。
如果找到問題，使用者會收到清楚說明問題以及如何解決的訊息 (請參閱 [圖 2])。有時候這就像點選回應一般的簡單。不過，有時候使用者必須進行組態變更，而對話方塊會將使用者引導至正確的位置。使用者或許會因為未具備足夠的知識或管理權限而無法採取適當的動作；事件檢視器中會記錄更詳細的資訊，可協助服務台迅速解決問題，而不必花上數小時進行疑難排解。
圖 2 疑難排解連線問題
圖 2 疑難排解連線問題
Windows Vista 擁有應用程式可呼叫以取得連線狀態的網路覺察 API，能讓應用程式察覺連線中的變更，並且識別電腦目前連接的網路類型 (網域、公用或私人)。當 Windows Vista 能夠透過網路存取網域控制站時，會自動切換至網域設定檔。此類別中不能放置其他網路。除非使用者或應用程式將網路識別為私人，否則其他所有網路都會分類為公用。代表網際網路的直接連線或在公共區域 (例如機場或咖啡店) 中的網路應保留為公用。只有位於私人閘道裝置背後的網路應識別為私人網路，例如，家用或小型企業網路。
有了「網路覺察」，具有進階安全性的 Windows 防火牆 (將於稍後討論) 這類應用程式就能根據目前連線的網路類型擁有不同的設定，並且在網路類型變更時自動切換設定。例如，管理員可能已將防火牆設定為在電腦連線網域網路時，針對桌面管理軟體開啟特定通訊埠，但這些通訊埠應在使用者於公用作用點作業時自動關閉。
群組原則在 Windows Vista 中同樣具備網路覺察能力：它會自動獲知電腦位於網域網路上，並且開始處理任何新的群組原則設定，而不會等到下一個重新整理週期。這表示即使 Windows Vista 才剛結束休眠，它也會在連線至網域網路時自動檢查新的群組原則設定。如此可讓管理員爭取時效，更迅速地部署安全性設定。

保護網路安全
威脅有多種類型：使用者存取不明的無線網路、連線至企業網路的不安全公用電腦，以及嘗試存取本身未具備存取權之資源的未受管理資源。光是這些就足以讓網路管理員終日忙碌又輾轉反側。Windows Vista 可藉由提供完整且易於設定的增強型網路安全性功能，在這些情況中予以協助。
Windows Vista 中的原生 Wi-Fi 架構能夠廣泛支援最新的安全性通訊協定，包括 Wi-Fi 保護的存取 2 (WPA2) 企業版和個人版、PEAP-TLS 以及 PEAP-MS-CHAP v2 (具備傳輸層安全性與 Microsoft Challenge Handshake 驗證通訊協定的受保護可延伸驗證通訊協定)。這項廣泛的支援能確保 Windows Vista 與幾乎所有無線基礎結構之間的互通功能。Windows Vista 會檢查無線網路卡的功能，而大部分通訊協定是在連線或建立無線網路時根據預設所選擇。若使用 EAP-HOST 架構，Windows Vista 就能支援硬體廠商或組織自訂的驗證機制。
Windows Vista 包括多項有關無線用戶端行為的改善功能，可減少常見的無線攻擊。用戶端將只會自動連線至使用者明確要求或識別為慣用網路的網路，並且不會自動連線臨機操作網路。如果使用者即將起始不安全的網路連線，用戶端還會顯示警告。此外，用戶端將減少主動探查的慣用網路，並且只有在使用者指示時探查，讓攻擊者更難識別用戶端嘗試連線的網路為何及使用相同名稱建立惡意網路。
Windows Vista 原生無線用戶端支援單一登入 (SSO) 功能，該功能會在適當時機執行網路安全性設定的 Layer 2 網路驗證，同時整合使用者的 Windows 登入經驗。一旦設定了單一登入設定檔，網路登入將優先於 Windows 登入。此功能會啟用例如群組原則更新、登入指令碼和無線啟動程序載入等情況，而這些情況需要網路能力才能讓使用者登入。
具有進階安全性的 Windows 防火牆為 Windows 平台帶來了新層次的網路安全性，同時支援輸入和輸出篩選以及 Windows Service Hardening。如果防火牆偵測到 Windows 服務發生 Windows Service Hardening 網路規則所定義的行為異常，則防火牆會封鎖該服務。具有進階安全性的 Windows 防火牆亦支援驗證的繞道，能讓通過 IPsec 驗證的特定電腦繞過防火牆規則進行遠端管理工作。
Windows 防火牆的其中一項重大變更就是與 IPsec 整合。在過去，管理員必須倚賴兩種不同的工具：防火牆和 IPsec 部署及管理工具，建立一組分層的網路安全性規則。而有了 Windows Vista，管理員就能建立可結合防火牆通訊埠與 IPsec 規則的簡單網路安全性規則，以保護網路避免未經授權的存取。此項整合提供了強制執行已授權之點對點網路通訊的簡單方式，藉此提供受信任網路資源的可調整分層存取，並且/或保護資料的機密性和完整性。
管理員可以利用邏輯的方式，將企業網路隔離在可由任何電腦 (包括訪客) 存取的區域中，或是只能由已通過網域驗證的電腦存取的區域中 (網域隔離)。管理員可進一步隔離只能由特定的一組使用者或電腦存取的特定伺服器，例如 HR 應用程式伺服器僅限 HR 群組的電腦存取 (伺服器隔離)，如 [圖 3] 所示。
圖 3 伺服器和網域隔離
圖 3 伺服器和網域隔離
病毒或蠕蟲可透過行動筆記型電腦進入私人網路，並且迅速感染其他電腦。連線至以 Windows Server "Longhorn" (為下一版的 Windows Server) 為主的網路基礎結構時，Windows Vista 將支援網路存取保護 (NAP)，以降低不安全的電腦透過 VPN 連線或直接連線至私人網路時的風險。如果執行 Windows Vista 的電腦沒有最新的安全性更新、病毒簽章，或不符合企業安全性需求，NAP 就會封鎖這部電腦完整存取網路的能力。這部電腦將只能連線受限的網路，並且可下載和安裝更新、病毒簽章，或符合目前健康狀態需求所需的組態設定。

簡化網路管理工作
Windows Vista 中的網路功能設計為支援高層次的管理能力，以協助降低部署無線網路和網路安全性原則的成本，並且為應用程式和使用者提供高品質的服務。Windows Vista 會進一步透過 Network Shell (NETSH) 使用群組原則或命令列指令碼管理網路功能，因此您不需學習或部署新的管理工具，並且可以充分利用 Active Directory® 中的現行投資和已建立的組織單位 (OU) 結構。
在稱為「具有進階安全性的 Windows 防火牆」(請參閱 [圖 4]) 的單一精靈驅動 Microsoft Management Console (MMC) 嵌入式管理單元內，或透過 NETSH 的命令列指令碼部署和管理網路安全性規則 (結合防火牆和 IPsec 原則) 更為容易。新的嵌入式管理單元提供簡單的方式，讓您部署輸入或輸出篩選與連線安全性規則，以限制特定使用者、電腦或應用程式的存取，同時提供更深入的系統管理控制。IPSec 可藉由使用者、電腦或狀況憑證要求驗證 (與網路存取保護整合)，以根據情況提供安全性原則。嵌入式管理單元可簡化建立伺服器或網域隔離規則的作業，由於它是以群組原則為基礎，因此您可以根據商務結構設定目標規則。
圖 4 具有進階安全性的 Windows 防火牆
圖 4 具有進階安全性的 Windows 防火牆
使用群組原則還可以定義行動用戶端連線無線網路，以及在無線網路上操作的方式。例如，公司可定義要求所有無線連線使用特定通訊協定，或是所有連線必須限於特定無線網路的原則。由於必須透過群組原則才能進行這些設定，因此可防止使用者變更這些設定。
NETSH 可啟用自動化和指令碼，協助無線網路連線的疑難排解。管理員可使用命令列介面驗證、變更或移除用戶端的無線網路組態設定檔。這些組態設定檔還可以匯出到其他電腦或從其他電腦匯入，以加速完成多部電腦的設定。
由於高頻寬的應用程式會消耗所有可用容量，而應用程式並非撰寫成給予 IT 管理員中央頻寬控制權，因此可能會降低網路品質。加入更多頻寬可能仍無法解決這些問題，反而只會導致這些應用程式消耗新增加的頻寬。利用原則為主的服務品質 (QoS)，管理員就能設定優先順序和/或調節輸出網路流量，而不需要修改應用程式。原則可以將輸出流量標上「區別服務代碼點」(Differentiated Services Code Point，DSCP) 值，讓路由器設定優先順序，或讓 Windows Vista 調節送出的輸出流量 (無論路由器設定為何)。結合這兩種技術就能提供更大的彈性。[圖 5] 顯示建立 QoS 原則。
圖 5 建立 QoS 原則
圖 5 建立 QoS 原則

為企業量身訂做且提供更多益處
企業級的組織支援網路時，經常會擔心延展能力的問題。例如，可用的 IP 位址變得不夠用，尤其是因商務需要而使每位使用者必須使用多個網路裝置，例如，額外的筆記型電腦和 Smartphone 等行動裝置。同樣地，當您想要提供額外的網路服務 (例如 IPsec) 時，可能也會考慮對 CPU 負載造成的影響。而 Windows Vista 支援 IPv6 和硬體卸載功能，可以解決網路延展性方面的顧慮。
為了解決公用 IPv4 位址受限的問題，許多政府機關、ISP 及其他組織都將轉換為 IPv6 這個引領網際網路的下一版網路通訊協定。Windows Vista 透過雙層 IP 堆疊架構同時支援 IPv4 和 IPv6。IPv6 是預設啟用的功能，藉由連通 IPv6 流量到私人 IPv4 網路或網際網路的 IPv6 轉換技術，雙層堆疊支援可以讓您逐步移轉成使用 IPv6。Windows Vista 原本即支援 PPPv6 和第二層通道通訊協定 (L2TP/IPv6) 虛擬私人網路 (VPN)，能讓遠端存取使用者充分利用 IPv6 網路的益處。
Windows Vista 支援將網路流量處理卸載至專用的網路介面卡。新的卸載功能包括 IPv6 和 TCP Chimney 卸載。這些架構上的創新可最佳化效能與網路輸出量，達到現今高速網路能實現的效能與營運收益。運用相容的網路介面卡硬體可消除與網路封包處理相關的瓶頸，例如 CPU 負荷與可用的記憶體頻寬，而不需變更現有的應用程式或網路管理工具。
網路堆疊還可支援接收端擴充，能夠動態平衡輸入網路連線，如此即可在多個處理器或核心之間分擔負載，並降低處理網路流量時可能發生的瓶頸。

總結
Windows Vista 象徵著自從 Windows 95 問世以來，Windows 網路功能的重大更新。使用者將發現，在四處移動時能更輕鬆地利用有線和無線網路。有了新的自動調整網路堆疊，檔案傳輸將更快速。而企業將能夠降低安全性風險，包括改善的保護能力，以對抗來自行動和無線使用者的威脅。系統管理員將發現 Windows Vista 更容易管理，並且能夠針對網路流量建立詳細的安全性原則，以及針對關鍵任務應用程式建立 QoS。這些新功能可讓您更充分利用網路基礎結構，同時大幅減少管理工作並提升使用者產能。
其他資源
  • New Networking Features in Windows Server "Longhorn" and Windows Vista (英文)
  • Next Generation TCP/IP Stack in Windows Vista and Windows Server "Longhorn" (英文)

Jason Leznek 是 Windows Vista 網路功能的資深產品經理，在 Microsoft 服務將近十年，加入 Windows Vista 團隊之前原為 Windows Server Update Services 和群組原則的產品經理。而更早之前則從事 Microsoft 企業客戶調查工作長達七年。


 Windows Vista: 準備迎接 Windows PE 2.0
Windows Vista Wes Miller

準備迎接 Windows PE 2.0

摘要:
  • Microsoft Windows Imaging 技術
  • 驅動程式更新和維修
  • 自訂自動安裝程式

在前兩期的 TechNet Magazine 中曾討論過 Windows 預先安裝環境 (Windows PE) 的歷史，內容涵蓋了各種設計決策，以及目前能夠使用 Windows® PE 的方式。而本文的重點將放在 Windows PE 2.0，這個版本將隨 Windows Vista™ 同步發行。不過，本文將不會深入討論如何使用個別功能。以下內容將著重在 Windows PE 2.0 中新功能和能力的概觀。在此僅提供一些實用的資訊，有關 Windows PE 2.0 的使用方式則將在未來的文章中詳細討論。
開始著手開發 Windows Vista 之初，Windows 安裝程式團隊 (我當時為成員之一) 的主要工作在於建立全新的安裝程式架構、建立協助部署的全新映像工具，以及設計取代遠端安裝服務 (RIS) 的方案。然而重點卻轉移到中間的 Windows PE 和 Windows XP Service Pack 2 (SP2)，且又再接著轉移到 Windows Server® 2003 SP1。這表示 Windows Vista 中 Windows PE 的開發工作就此延後了一些時間。不過，這中間的 Windows PE 更新仍讓我們有機會提供一些原本打算納入 Windows PE 2.0 版中的功能，因此我們的工作並非完全延宕。
在定義要納入的新功能時，Windows PE 團隊將工作重點高度集中在 Windows PE 使用者的持續性與一般使用情況 (請參閱「Windows PE 2.0 新手」資訊看板)。現在就來看看有哪些主要新功能。

使用映像
您必須先瞭解一些關於 Microsoft® Windows Imaging (WIM) 技術與 Windows 部署服務的基本概念。WIM 是全新的設計，用於將 Windows 做為映像進行部署 (舊稱為 Sysprep 映像)。不過 WIM 不是以磁區為基礎 (如同大部分映像工具一般)，而是以檔案為基礎。這表示不再需要複製硬碟的每一個磁區，WIM 會挑選每個檔案及其相關的中繼資料 (存取控制清單、短檔名和長檔名等)，並且將資料保存在單一檔案中。
WIM 映像的其中一項主要優勢在於，單一 WIM 檔案可保存超過一個磁碟區 (每個檔案稱為一個磁碟區映像) 的副本。而且無論擷取的數量多寡，每一個檔案只會儲存一次。這稱為「單一執行個體」。功能上來說，這項技術與遠端安裝服務使用的技術相似，不過運用的科技則大異其趣。建立 WIM 映像的工具稱為 ImageX (請注意，此工具曾一度稱為 XImage，但是現在已更名)。
當我們開發 Windows Vista 及其新的映像式安裝程式引擎 (該引擎將使用 Windows PE 部署作業系統) 時，發現可以運用一些小技巧來節省媒體上的空間。當時我們不確定 Windows Vista 會以 CD 或 DVD 提供，因此傾向盡量縮減安裝程式本身佔用的磁碟空間。由於 CD 上組成 Windows PE 的所有檔案版本與一旁的 WIM 檔案中的檔案完全一致，因此就有了將 Windows PE 納入 WIM 檔案本身並且從中開機的想法。多虧了 Windows 核心作業系統團隊的某位架構設計師完成的卓越工作，讓我們的想法能夠在 "Longhorn" (現為 Windows Vista) 的 Developer Preview 於 2003 年專業開發人員大會發表前付諸實踐，製作出一系列原型並且整合到產品中。如今，Windows PE 存在媒體的一個 WIM 檔案 (boot.wim) 中，而安裝媒體則出現在另一個 WIM 檔案 (install.wim) 中。雖然原本在 Windows PE 和 Windows 之間想像的單一執行個體已不再是安裝媒體的一部分，Windows PE 仍然因壓縮於光碟片上並縮減佔用空間而獲益。由於 Windows PE 1.6 中整合了 RAMDisk 開機功能，換置媒體的能力 (在開機完成後移除初始的開機 CD/DVD) 也因早期 WIM 開機工作已完成而加入。
將 Windows PE 映像納入 WIM 與使用 ImageX 挑選檔案 (這部分的細節將在未來的文章中討論)，以及提供 /boot 旗標給 ImageX 藉此將映像表示為可開機一樣簡單。請將這個映像想像為開機磁區。當 Windows 開機管理程式載入 WIM 檔時，/boot 旗標包含的標記就會指出 WIM 檔中的哪一個映像 (無論包含一個或多個) 可開機。請注意，只有 Windows PE 可從 WIM 檔開機。您無法從 WIM 啟動所有 Windows Vista。同時，WIM 是唯讀的，如同在 CD 或 DVD 上一般。因此，您無法從 Windows PE 的 WIM 映像開機，也無法修改任何檔案。若要對 Windows PE 進行任何變更，則必須修改 WIM 本身。

處理驅動程式
對於 Windows PE，我們總是將焦點放在大量存放裝置和網路裝置的支援上。然而，Windows PE 偶爾仍會缺乏新系統上某些裝置的支援。Windows PE 1.5 中已包含一些新增裝置驅動程式的改善支援，而 Windows PE 2.0 則進一步讓此功能更加完善。現已支援所有類型的裝置，並且開機之後隨即運作，不再需要 factory.exe 或 drvinst.exe。若要在 Windows PE 2.0 中加入新的裝置驅動程式，只要執行新的 peimg.exe 工具就會自動加入驅動程式。語法相當簡單，如下所示：
peimg.exe /inf drivername.inf builddirectory\Windows
只要將 drivername 取代為 .inf (可接受萬用字元如 net*.inf) 的名稱，並且將 builddirectory 取代為建立 Windows PE 映像所在的目錄名稱即可。

塗銷空間
在 Windows PE 下執行的應用程式經常面臨的一項問題為，許多 Windows 應用程式 (甚至許多 Windows 元件本身) 是準備在可寫入的存放區上執行。但是從唯讀媒體 (例如 CD-R) 執行時，許多應用程式會出現不良反應。例如，當我初次嘗試在 Windows PE 下執行 Microsoft Internet Explorer® 時 (最後僅嘗試 MSHTA，或稱 Microsoft HTML 應用程式 (Windows 元件))，主要的 DLL 無法註冊，因為這些 DLL 需要可寫入的存放區，才能在註冊程序期間完成某些必要的工作。
在 Windows PE 2.0 中已不會發生這個問題，因為現在有多達 32MB 的塗銷空間可讓檔案系統寫入。因此，之前因 Windows PE 本身為唯讀而無法運作的元件現在將可以運作，因為這些元件現在可以寫入需要的磁碟中。不過這與用於塗銷空間的 RAMDrive 不同 (如 Windows PE 使用者所慣用)，其不同之處在於，塗銷空間與開機磁碟區位於相同的磁碟區上，而不是另一個暫時的磁碟。

選用元件
如同舊版 Windows PE，新版同樣提供選用的元件，可用來加入更多功能 (當然，這些元件會增加大小，而這也是為什麼它們僅為選用的原因)。不過仍然支援 Windows Script Host (WSH)、Windows Management Instrumentation (WMI) 及 MSHTA。現在您可以加入 MSXML、Windows Vista 修復環境、額外的 Windows 字型，以及正式 Microsoft Data Access Components (MDAC) 的支援，其取代之前支援 SQL 的舊版 ADO (包括部分而非全部的 MDAC 支援)。不過，最重要的變更在於能夠輕鬆加入這些元件。您不再需要透過困難的 WSH 指令碼實作這些元件，只要使用 peimg.exe (之前提過用來加入驅動程式的同一項工具) 就能輕鬆加入或移除這些元件。

語言套件
Windows Vista 的其中一項原始的宗旨為採用多語言使用者介面 (MUI) 的概念 (這個概念是在 Windows 2000 中初次採用，並於 Windows XP 中進一步改善)，並且在整個作業系統中實作此概念。在 Windows 2000 和 Windows XP 中，您可以指定英文以外的語言，但是 MUI 本身則倚賴英文版的作業系統才能開始執行。這表示，只要英文版存在，您就可以擁有其他任何語言。
不過，在 Windows Vista 中這種情況已有所改變。雖然在此將不會詳述所有細節，但仍必須說明這是 Windows PE 的重大變革。以往並未在舊版的 Windows PE 下正式支援 MUI。您必須從 Windows 中的當地語系化語言建立語言支援。現在，加入或變更語言支援與其他任何選用元件的操作方式相同，亦即使用 peimg.exe 即可新增或移除語言套件，以因應特殊的 Windows PE 需求。

更佳的維修
舊版的 Windows PE 還缺乏維修支援。若要加入 Service Pack，則必須重建整個 Windows PE。若要加入 Hotfix，則須臨時手動進行 (如果您敢嘗試的話)。事實上，由於 Windows PE 相當小，僅包括有限的 Windows 功能，而且無法長時間執行，因此之前我們並未正視維修問題。不過那是在惡名昭彰的 Blaster 弱點發生之前的情況。由於遠端程序呼叫已加入 Windows PE 中，弱點即可在適合的環境下進行攻擊，而造成 Windows PE 連續重開機。
這也是讓我們決定在 Windows PE 1.5 中加入 Windows 防火牆的原因。而自此之後，我們的團隊就開始確保未來的 Windows PE 版本能夠進行維修，就像完整版的 Windows 一樣。Windows Vista 的其中一個重點區域為改善的維修能力。而 Windows PE 繼承了這項能力。就像其他選用的元件和語言一樣，Windows PE 會使用 peimg.exe 執行更新。更新將透過 Windows 下載中心提供。

自動檔案支援
您可能很熟悉舊版 Windows PE 中用來驅動小型應用程式 factory.exe 的 winbom.ini。不過在新版中，這個檔案已被取代。現在您將使用新的 XML 基礎結構自訂 Windows PE (此 XML 機制與 Windows Vista 中用於自動安裝程式的機制相同)，以及名為 wpeinit.exe 的新應用程式。
Wpeinit.exe 會使用 Windows Vista 中的標準 unattend.xml 格式指定 Windows PE 自訂內容及動作。[圖 1] 顯示的範例 unattend.xml 檔案可用來自訂 Windows PE。unattend.xml 檔的格式會記錄為 Windows OEM Preinstallation Kit (OPK) 與 Windows Automated Installation Kit (WAIK) 的一部分；這部分將於稍後討論。
Figure 1 unattend.xml 檔的架構 (Close Figure 1)
XML 檔 註解
<ComputerName>MyWinPEMachine</ComputerName>
 將 Windows PE 的電腦名稱設定為 MyWindowsPEMachine。
<Restart>Shutdown</Restart>
 重新啟動時關閉系統 (並非重新開機，如舊版 Windows PE 的做法)。
<RunSynchronous>

<RunSynchronousCommand> <Order>1</Order> <Path>notepad.exe</Path> </RunSynchronousCommand>
 執行 notepad.exe。
<RunSynchronousCommand> <Order>2</Order> <Path>cmd.exe</Path> </RunSynchronousCommand>
 當 notepad.exe 完成時，cmd.exe 便會執行。
</RunSynchronous>

<EnableFirewall>true</EnableFirewall>
 開機時啟用 Windows 防火牆。
<PageFile> <Size>1000</Size> <Path>C:\pagefile.sys</Path> </PageFile>
 在 C: 磁碟機上建立 1GB 的分頁檔。
<LogPath>C:\mylog.txt</LogPath>
 將 wpeinit.exe 的輸出內容以及此指令碼記錄到 C:\mylog.txt 中。

Windows 部署服務
之前提到，我們其中一個主要目標在於，無論安裝程式是從 CD、DVD 或網路啟動，都將一併移轉為統一的基礎結構，藉此改善網路為主的安裝程式。只可惜在執行 RIS 為主的 Windows 安裝時，安裝程式執行的過程中仍有許多額外的工作需要完成。我們希望盡可能摒除複雜而重複的工作，而為了達成此目標，我們建立了 Windows 部署服務。
Windows 部署服務與 RIS 一樣，是 PXE 為主的安裝。但與 RIS 不同的是，該服務是透過網路啟動 Windows PE，並使用相同的映像式安裝程式基礎結構 (如同一般的 CD 或 DVD 安裝程式)，同時提供 RIS 始自 Windows 2000 即隨附的相同類型集中式企業安裝基礎結構。有關 WIM 和 Windows 部署服務尚有許多要討論的內容，而本文中並沒有足夠的空間進行討論。不過別擔心，我將在未來的文章中進行更深入的討論，敬請密切期待！

使用 WAIK
至此，您可能想知道如何開始使用 Windows PE 2.0，而您首先需要取得 WAIK。舊版的 Windows PE 會在 Windows OPK 或軟體保證媒體中隨附。由於 Windows PE 2.0 是以提供所有授權的 Windows 客戶使用為目的，因此 Microsoft 已為非 OEM 客戶建立了 WAIK。
WAIK 提供所有需要的 Windows PE 建置工具讓您建立自己的 Windows PE 2.0。目前您可以在 Windows Business Desktop Deployment (BDD) 2007 Beta 版中取得 WAIK。除了 WAIK 之外，BDD 還提供如何使用 WAIK 及其工具的指導。當然，實際熟悉 Windows PE 2.0 以及 Windows Vista 中包括的所有其他新安裝程式與部署技術的最佳方法，就是盡快開始試用。
Windows PE 2.0 新手
Windows PE 2.0 包括 Windows PE 1.6 中的所有功能，並加入了許多新功能和元件，包括：
  • 從 Microsoft Windows Imaging (WIM) 映像內開機
  • 驅動程式插入與即時的隨插即用支援
  • 可寫入的塗銷空間 (即使是從 CD 開機)
  • 輕鬆加入選用元件 - Microsoft 核心可延伸標記語言服務、Windows 修復環境、Microsoft Data Access Components
  • 語言套件
  • 自動檔案支援
  • 建立與更新 Windows PE 的工具已獲得改善

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


 Windows Vista: 深入剖析新版 Microsoft 應用程式相容性工具組
Windows Vista John Melton

深入剖析新版 Microsoft 應用程式相容性工具組
摘要:
  • 影響應用程式相容性的變更
  • 評估對於應用程式的影響
  • 管理安全防護與部署

Windows Vista 即將發行，如今正是您開始準備評估、部署與支援此一新作業系統的最佳時機，包括新工具、新功能和新的培訓計劃。當然，您的主要任務是決定如何讓這個重要的 Windows 版本能在現有的環境下發揮作用。
我個人認為首要之務莫過於從整體的應用程式組合開始著手，判斷哪些應用程式能與 Windows Vista™ 一起正常運作。
Windows Vista 有些重大變更可能會影響應用程式相容性。在 Windows Vista 開發階段，確保應用程式相容性是一項重要的考慮因素。透過將數千個應用程式與每個版次進行交互測試，並即時向工程團隊提供有關版次變更對於應用程式之影響的意見反應，降低了開發週期發生相容性問題的機率。
此過程致使大部分的相容性問題縮減至僅涉及少數幾個方面。本文將討論這些方面並提供若干秘訣，以協助您克服在部署過程中可能遇到的障礙。

影響相容性的變更
某些應用程式或許基於合理因素而設計成只在特定的作業系統版本上執行，而這可能造成安裝或程式執行失敗以致根本無從測試應用程式。
幸好，使用 Windows Vista 的程式相容性助理 (PCA) 即可輕鬆解決這類問題。PCA 會在安裝期間自動偵測潛在的相容性問題，然後建議將設定修改為 Windows® XP 相容模式，讓您得以順利安裝再繼續進行測試。
如果應用程式的其他功能均可正常執行，則只需修改應用程式版本檢查，或對桌面應用程式套用修正程式，應用程式的執行就會如在舊版作業系統上執行一樣。
如今的資訊公路與 2001 年 Windows XP 發行時相比已大異其趣。糟糕的是，系統安全性考量當前面臨的陷阱卻與日俱增。Windows Vista 實作了許多新的安全性功能，而這些功能對於應用程式相容性問題的解決會佔有一席之地。
Windows Vista 內建 Microsoft® Windows 資源保護 (WRP) 功能，使應用程式即便試圖寫入受保護的系統檔案和登錄位置也能順暢執行無礙。WRP 會自動建立暫存工作區，並將應用程式工作階段的寫入動作重新導向。這項技術使原本無法在 Windows XP 中執行的應用程式得以在 Windows Vista 中執行，因而相容性遠勝過舊版作業系統。不過，此暫存工作區僅供目前的應用程式工作階段使用，所以在切換工作階段後無法保存任何資料。
Windows Vista 藉由「使用者帳戶控制」(UAC) 實作 Windows XP 中眾所周知的系統管理員和標準使用者。許多公司在使用 Windows 2000 及 Windows XP 實作標準使用者方案時都曾感到相當棘手。而在 Windows Vista 中，Microsoft 提供了更健全的標準使用者體驗，於標準使用者或應用程式執行系統管理員層級的工作時加上適當的提高權限提示。對於應用程式，您必須使用 Microsoft 應用程式相容性工具組和 UAC 評估工具 (稍後詳述)，判斷有哪些應用程式若以標準使用者身分執行將可能受到限制，並確保應用程式不會在非必要的情況下試圖執行系統管理員層級的命令。
由於 Internet Explorer® 是多數使用者聯繫網際網路的重要窗口，Microsoft 在 Windows Vista 中採取了一些措施，以降低經由引進 Internet Explorer 受保護模式而遭受攻擊的可能性。Windows Vista 中的 Internet Explorer 基本上會以標準使用者身分執行，從而限制其寫入電腦某些區域的能力，避免將惡意程式或病毒引入系統。您也可以使用 Microsoft 應用程式相容性工具組所附的 Internet Explorer 相容性評估工具 (Internet Explorer Compatibility Evaluator)，偵測有哪些內部網路、外部網路或網際網路應用程式可能受限於受保護模式。
創造新作業系統最大的好處就是能夠創新：提供新特性和新功能，以及利用新的硬體技術。然而，此等創新也會致使應用程式相容性面臨一些挑戰。
安全性在 Windows Vista 中扮演著重要角色，而特別值得一提的是防火牆和防毒應用程式採用了更健全的新 API 結構。不過，這些附加功能意味著多數企業亦需將其協力廠商防火牆和防毒軟體升級到新版本。WinLogon/GINA (Graphical Identification and Authentication，圖形識別與驗證) 架構在 Windows Vista 中也已遭汰換，因此您必須檢查原先執行或通過驗證認證的應用程式。
您或許亦應考慮添購更強的最新 64 位元處理器和作業系統。雖然 32 位元應用程式在這類系統上應可正常運作，您仍需確定已有 64 位元驅動程式。請注意 64 位元 Windows Vista 平台並不支援 16 位元應用程式。

評估應用程式的影響
應用程式相容性工具組的設計旨在協助您清查與分析現有的應用程式組合，排定優先順序使其合理化。[圖 1] 列出此工具組的各項元件。[圖 2] 說明此工具組所附個別的相容性評估工具 (Compatibility Evaluator)。
Figure 2 工具組的相容性評估工具 (Toolkit Compatibility Evaluator) (Close Figure 2)

評估工具 | 說明
Inventory (詳細目錄) | 清查多個系統區域，收集每一部電腦上應用程式及其關聯元件的相關資訊。
Internet Explorer | 監控 Internet Explorer 7.0 以探查具有潛在相容性問題的 Web 應用程式。會記錄 Web 位置供進一步處理。
User Account Control (使用者帳戶控制) | 監控使用者與應用程式的互動，並於請求提高安全性權限時，記錄應用程式資訊供進一步處理。
GINA | 監控舊版架構應用程式使用認證的情況，並記錄這些應用程式以便進行必要的修改。
Deprecated Components (過時元件) | 清查 Windows Vista 已不再支援的舊技術 (如 FrontPage Server Extensions) 使用情況。如果偵測到任何應用程式使用這類技術，便會予以記錄供進一步處理。
Session 0 (工作階段 0) | 偵測 Session 0 的具體請求，並據以記錄應用程式。Session 0 在 Windows Vista 中受到完全保護，所以應用程式如今已無法在此工作階段中執行。
Figure 1 應用程式相容性工具組元件 (Close Figure 1)

元件 | 說明
Compatibility Evaluator (相容性評估工具) | 可在電腦上執行的各種評估工具，用於偵測與記錄潛在的應用程式相容性問題。
Log Processing (記錄檔處理) | 取得記錄於個別電腦上的累積相容性資訊，並於預先定義的間隔將此資訊傳送至中央記錄檔。
Inventory Database (詳細目錄資料庫) | 供 Application Compatibility Manager 報表功能使用，並可啟用許多新欄位以協助管理每個應用程式的部署流程和狀態。
Application Compatibility Manager | 此中央管理工具提供各項功能，可用於監控及變更部署流程的相關資訊。
Microsoft Compatibility Exchange | 分享相容性資訊的社群資源。可從 Microsoft Compatibility Exchange 取得的其他相容性資訊包括：其他客戶的分析結果、Microsoft 憑證資訊，以及廠商的應用程式相關資訊。
基本上，透過四個步驟大致可瞭解並判別 Windows Vista 對您的應用程式有何影響。
首先，您必須清查企業內部所有的應用程式，及其就應用程式相容性而言的已知狀態。針對這項工作，您可藉助於 Systems Management Server (SMS) 之類的軟體管理系統，或純粹憑藉可信的傳統試算表來完成，但兩種方法都無從得知相容性狀態。應用程式相容性工具組所附的相容性評估工具則可提供這項重要資訊。
要收集整體的應用程式詳細目錄，第一步是建立能夠部署到桌上型電腦的相容性封裝 (Compatibility Package，請參閱 [圖 3])。您可以附上相容性評估工具，協助判別哪些應用程式可能存在相容性問題。此封裝可透過軟體管理系統進行部署；其檔案極小，在用戶端電腦上執行時佔用很少資源。而一旦執行後，您將收到關於電腦和應用程式的相容性資訊。
圖 3a 建立相容性封裝 (Compatibility Package)
圖 3a 建立相容性封裝 (Compatibility Package)
圖 3b
當您取得相容性評估工具傳回的第一份報表後，應會希望獲得最新的相容性資訊。下一步正是與 Microsoft Compatibility Exchange 進行同步。請按一下 [Send and Receive Data] 圖示，然後提供您的登入資訊，就能與 Microsoft Compatibility Exchange 連線。該處即為相容性資訊的來源，可協助您分析應用程式組合，排定優先順序以將其合理化。應用程式報表 (Application Report) 將包含由其他社群成員、軟體廠商及 Microsoft 所提供與您的組合中各應用程式有關的資訊，顯示了這些應用程式大致的相容性狀態。此外，您還能快速查閱已知問題和可能的方案，進而減少需要自行從事整體測試的次數。對於早已公認的問題，您就不必再親自測試而後反覆探索該問題，也沒有必要四處尋求解決方案。
如今您已有了應用程式組合，接下來的目標是減少需要投注心力解決問題的應用程式數目。最有效率的辦法是將應用程式加以組織與分類。
首先請利用 Application Compatibility Manager 內建的篩選功能。詳細目錄清單可能含有許多您不需要在意的應用程式 (請參閱 [圖 4])。例如，若您即將更換硬體，就可忽略 OEM 提供的硬體驅動程式或特殊應用程式。
圖 4 利用 Application Compatibility Manager 進行篩選
圖 4 利用 Application Compatibility Manager 進行篩選
下一步是開始制定您要如何組織這些應用程式，以剔除無關緊要的部分。請稍加思考應用程式係屬於全面性，還是僅侷限於特定的地理區或部門。哪些應用程式可就近向廠商尋求支援？內部有哪些商務營運系統應用程式須交由員工照料？可能要為所有開發人員建立一個類別，再為每位開發人員建立一個子類別，以便指派負責程式。決定好您的組織策略後，即可開始著手將應用程式分類。
您可以利用應用程式相容性工具組，藉由選取 [組織 (Organize)] 功能並建立個人項目來建立類別和子類別 (請參閱 [圖 5])。這些項目將會列在報表選項中，讓您可針對每個子類別項目建立非常具體的報表。
圖 5 指派類別
圖 5 指派類別
分析階段的最後一步是為每個應用程式或每部電腦指派類別。經常使用行動裝置的員工將從中受益，因為 Windows Vista 提供許多新功能可改善使用行動裝置之員工的體驗，因此您會希望為這些應用程式建立類別或子類別。應用程式可指派為隸屬多個類別，因此若您建立開發小組類別並以小組成員的名稱做為子類別，就能追蹤各個應用程式是由哪些成員負責。

管理修改與部署
將應用程式初步分類後，您即可更進一步精簡清單。一部電腦上可能列有數百個應用程式，但絕非所有的應用程式都值得關注。請記住，目標是要大幅縮編應用程式的清單，才能將心力集中在必要的安全防護工作上。在合理化過程中，優先順序清單中首先要剔除實用性即將過時，或是正處於更新或改造階段的應用程式。您還會發現若整個組織現存應用程式的多種版本，則可將其整併為單一版本以方便提供支援。某些應用程式可能已由其廠商或 Microsoft Compatibility Exchange 認定為相容，因而完全無須予以理會。部分應用程式也許並不屬於計劃升級的地理區或部門所管轄。
應用程式相容性工具組的「自訂報表」(Custom Reports) 功能可協助合理化應用程式。您可以選取特定類別，讓合理化後的應用程式清單縮編為只剩下某特定小組、地理區或位置。這樣應有助於您將焦點集中在需要投入更多相容性工作的領域。
將應用程式組合精簡為一組易於管理的應用程式後，如今您即可處理一系列明確的應用程式相容性問題，以實現順暢而適時地部署新作業系統。利用「排定優先順序」(Prioritize) 功能，您可為每個應用程式指派特定的優先順序和類別。
應用程式相容性工具組還提供一些附加功能，可協助您完成管理應用程式狀態及部署資訊的過程。藉由交互選擇 [測試 (Testing)]、[安全防護 (Mitigating)] 和 [準備部署 (Ready to Deploy)] 可以追蹤特定應用程式的狀態。而在 [報表 (Reports)] 區段中，您將看到所有應用程式的整體部署狀態。
您亦可在此區段中自行新增應用程式的相關資訊。您可以對應用程式進行認證，及建立或編輯該應用程式的具體新問題 (請參閱 [圖 6])。請與 Microsoft Compatibility Exchange 分享這項資訊，以協助其他系統管理員分析其個人環境。
圖 6 記錄應用程式的相容性狀態
圖 6 記錄應用程式的相容性狀態

總結
如今您已瞭解到在開始部署 Windows Vista 之前，應該投注心力事先處理哪些事項。如需 Microsoft 應用程式相容性工具組的詳細資訊，請造訪 microsoft.com/technet/prodtechnol/windows/appcompatibility (英文)。

John Melton 涉足資訊科技 (IT) 領域已長達 20 餘年，且過去 10 年一直都在 Microsoft 任職。John 原為系統工程師，目前則是 Windows Vista 及「Microsoft 應用程式相容性」的小組產品經理。


 Windows Vista: Windows Vista 中事件管理的新工具
Windows Vista Val Menn

Windows Vista 中事件管理的新工具
摘要:
  • 新的事件基礎結構
  • 事件類型
  • 結構化事件內容
  • 使用 XPath 運算式

許多人會說，事件記錄和追蹤相當枯燥。而越來越多人抱怨，追蹤和事件只不過是次要活動 (例如，偵錯和自動監控功能) 的附帶結果，且不夠重視事件記錄和追蹤功能的重要性。
Microsoft® Windows Vista™ 著重在扭轉這些看法，並且讓企業管理向前邁進了一大步。Microsoft 徹底檢修了部分主要元件及其使用者介面。事件日誌服務已針對企業徹底重新撰寫，而追蹤速度也較以往更快、更安全。
想像一下，如果能擁有一組更上乘的工具，協助您發現並解決關鍵任務系統中的問題。或者，如果能擁有可讓支援技術人員輕鬆收集說明事件，並且從使用者的系統進行追蹤的功能？再者，如果能讓開發人員利用使用者傳送的追蹤內容，即時診斷並修復部署系統中的錯誤？想像一下，如果收集資訊的方式更為簡單且強大，並且能夠迅速執行疑難排解，聽起來是不是有趣多了？

何謂事件？
電腦應用程式就像是執行各種功能的「黑盒子」。在這個盒子中進行著許多活動，不過由於您看不見盒子內部，因此很難瞭解內部工作的情形。然而，應用程式會向外與其他程式或使用者溝通。這些溝通「事件」就能讓您稍微窺探應用程式的內部。
如果是軟體，事件通常定義為軟體系統中與外界進行通訊的活動 (所謂外界是指使用者或其他程式)。這類活動通常是指狀態或組態的變更。其溝通的內容可能是軟體系統的目前狀態或組態，以及變更的原因。
廣義來說，事件這個詞也可以用來表示這些活動公開 (Expose) 的方式。這類公開事件的範例如下所述：
  • 用於處理程序之間通訊 (IPC) 的 Win32® 物件
  • 用於暫時 (非持續) 通知的 WMI 事件
  • 儲存到追蹤檔中的 Windows 事件追蹤 (ETW) 追蹤事件
  • 儲存於事件日誌即時記錄中且可能保存於事件日誌檔中的事件日誌事件
  • 使用自訂基礎結構儲存到檔案中的事件
此處列出的後三個範例為本文中將討論的類型。

事件的使用方式
追蹤或記錄的事件是程式或作業系統中活動的記錄。這些追蹤和事件日誌不只是開發人員所需。對於 IT 和支援人員來說，更是不可或缺的工具，並且能讓您一窺執行中應用程式的狀態與內部作業情形。
您可以使用這類日誌監控整體系統健康狀態。使用事件日誌可搜尋指出問題的任何事件。例如，您可能會在 CertificateServicesClient 來源的 Application 日誌中發現錯誤事件 6，以及下列訊息："Automatic certificate enrollment for local system failed (0x80070576).There is a time and/or date difference between the client and server." (本機系統的自動憑證註冊失敗 (0x80070576)。用戶端和伺服器之間的時間和/或日期不同。)同樣地，您可以偵測元件從不良狀態轉換回正常操作的情形。例如，更正時間和日期的差異之後，同一個 CertificateServiceClient 來源可能會在 Application 日誌中發佈資訊事件 19，指出："Certificate enrollment for <user name> successfully received an AutoenrolledWindowsSystemComponentVerification certificate from certification authority <authority name>." (<使用者名稱> 的憑證註冊成功收到來自憑證授權單位 <授權單位名稱> 的 AutoenrolledWindowsSystemComponentVerification 憑證。)這類資訊對於尋找和解決衝突及其他組態問題來說，相當具有價值。
這項資訊對於診斷問題也十分實用。您可以找出造成問題的程式和系統動作，並且找到協助您判斷根本原因的詳細資料。同樣地，您還可以運用這項資訊評估及解決效能問題。
事件日誌提供的寶貴資訊可讓您用來確保更安全的環境。這些資訊可用來偵測嘗試入侵的行為、稽核系統歷程記錄、確保不可否認性，以及找出設定錯誤的資源。

Windows Vista 中的事件
舊版 Windows® 在事件記錄和追蹤方面有許多缺點。包括受限的事件日誌延展性 (所有日誌的總容量限制為可用記憶體的數量)、事件發佈效能 (例如，限制可在作用中網域控制站上發佈的事件數量)，以及受限的追蹤事件安全性。
Windows Vista 利用稱為 Windows Eventing 6.0 的全新事件記錄和追蹤基礎結構解決了許多這類問題。它不但延伸了始自 Windows 2000 即持續使用的 ETW，更取代了事件日誌服務和事件檢視器。新的 Windows Eventing 是專為處理保留在日誌檔中以供未來檢查使用的事件所設計 (而不是用於暫時事件，如 IPC 和通知機制)。
藉由提供安全性與延展性解決方案，自訂事件記錄和追蹤實作就不是那麼重要了。不過須注意的是，增強功能是在保留與現有事件日誌和 ETW API 之完整相容性的情況下提供，這表示所有現有的應用程式將持續運作不變。

檢視事件的新方法
現行的事件檢視器已是 IT 社群中，最普遍的 Windows 程式之一。新的事件檢視器已徹底重新撰寫，而由於它存在 Microsoft Management Console (MMC) 3.0 中，所以外觀上也有所改變，不過仍然相當熟悉，因此轉換時應相當容易。
樹狀窗格與事件清單都會繼續使用。您仍然可以在 [Windows 記錄檔] 節點下存取熟悉的應用程式記錄檔、系統記錄檔和安全性記錄檔。然而，根目錄中已加入一些新的節點，而新的 ForwardedEvents 記錄檔 (將於稍後討論) 也已加入 [Windows 記錄檔] 節點中。
最明顯的新功能就是位於事件清單下方的預覽窗格。其中包含焦點所在事件的內容。這表示，您不需要按兩下事件，就能看見事件內容，也不必為了同時看見清單和 [事件內容] 對話方塊，而與視窗大玩捉迷藏。不過您仍然可以按兩下事件，在對話方塊中顯示其內容。新的對話方塊並非強制回應，因此您可以同時顯示多個事件內容對話方塊。
新的檢視模式讓您只需按幾下滑鼠，就能顯示所有想看的事件。您可以針對一個或多個日誌檔收集事件，也可以讓事件著重在特定的 ID、等級 (嚴重性) 或時間範圍。
您將在 [自訂檢視] 節點下找到 [系統管理事件] (如 [圖 1] 所示)。其中會提供一份清單，列出系統管理員想查看的各個不同記錄檔中的所有錯誤和警告。
圖 1 系統管理事件
圖 1 系統管理事件
那麼，到底如何判斷哪些是管理員想查看的日誌和事件呢？我們識別出了五種不同的事件類型，以及與各類型相關的使用者。[圖 2] 中提供了詳細資料。對於各使用者群組想查看的所有事件日誌和追蹤事件來說，這是相當普遍卻有效的分類方式。
Figure 2 事件類型及使用者 (Close Figure 2)

事件類型 | 說明 | 使用者
管理 (Admin) | 管理類型對於大部分的系統管理員來說即足夠。這些事件的等級相當高，通常會提供足夠識別問題及判斷解決方式的資訊。管理事件至少能夠識別問題發生的時間，或指出應用程式、元件或系統整體處於不健康狀態或已從不健康狀態復原。大部分的管理事件為錯誤或警告，並且通常有因應動作。 | 管理員、支援人員及監控與分析程式
作業 (Operational) | 作業事件與管理事件一樣可診斷問題。但作業事件不僅包含錯誤和警告。這類事件還會通知使用者應用程式或 OS 元件是否正常運作。由於作業事件的容量維持相當低，因此啟用時不會影響系統效能。作業事件與管理事件是由支援人員、監控公用程式，以及一些經驗較豐富的管理員使用。 | 進階管理員、支援人員及監控與分析程式
稽核 (Audit) | 稽核事件提供有關使用者存取任何資源或採取動作的歷程記錄。這類事件本身不代表程式失敗或成功，而是指出動作失敗或成功。稽核事件可以完全停用，或搭配不同等級的細節選擇性啟用。同時也支援 OS 等級的安全性稽核 (這類事件可在事件日誌的安全性記錄檔中找到)。 | 進階管理員、安全性稽核人員，以及鑑識專家
分析 (Analytic) | 分析事件與作業事件差異並不大，會在應用程式和元件正常運作時記錄。但是分析事件的容量和細節則遠大於作業事件，所以可能會對系統效能造成負面影響。因此，分析事件一般為停用狀態。若要使用分析事件，請在診斷工作階段之前啟用，然後在檢查追蹤之前停用。 | 支援人員監控與分析程式
偵錯 (Debug) | 偵錯事件同樣是高容量的事件，因此通常為停用狀態。這類事件主要為開發人員所使用，IT 專業人員很少會檢視這類事件。 | 開發人員
Windows Eventing 中的每一個日誌都有指定的類型。而日誌中的所有事件都會共用該日誌的類型。[圖 1] 中的檢視是使用此類型資訊定義，其中會擷取 Admin 類型日誌中的所有錯誤和警告事件。

Windows Eventing 的架構
Windows Eventing 的基礎結構是由可讓程式發佈事件物件，並將事件物件傳送至日誌檔的軟體元件所組成。ETW 會提供用來將所有事件類型從事件發佈者傳輸至目的地的傳輸方式。ETW 也已在 Windows Vista 中徹底檢修，而且現在會提供更佳的效能與增強的安全性。透過 ETW 發佈事件並非同步，因此不會影響發佈程式的效能。當系統收到新事件時，就會收集有關目前使用者內容和發佈程序的資訊並附加到事件中。
事件發佈之後，會以不同的方式處理不同的類型。由於分析和偵錯事件通常容量較大，因此必須儲存到僅需最少處理的檔案中，以避免影響系統效能。因此這些事件會立即儲存到追蹤檔。
管理和作業事件的頻率並不高，因此能夠進行額外的處理而不會影響系統效能。這些事件會傳送到事件日誌服務，該服務會將這些事件儲存到即時事件日誌中，並且可以選擇性地將它們傳送給即時訂閱者。訂閱者可使用查詢語言 (將於稍後討論) 挑選想要收到的事件。
IT 社群對於兩種訂閱者特別有興趣。一種是大幅增強的 Windows Vista 工作排程器，另一種是可用來傳送事件給遠端事件收集站的事件轉寄站。

結構化事件概要
關於事件日誌的常見抱怨為，日誌中包含太多不必要的內容。也就是說，這些內容是隨不怎麼重要，甚至不重要的事件所累積，而且常會隱藏或混淆重要的事件。由於有些事件確實提供了少許資訊，因此對於某位使用者來說不必要的內容，對於其他人來說可能相當寶貴。
Windows Vista 提供了篩選掉不必要事件的方式，可讓您瞄準確實重要的事件。這個方式需要使用事件日誌服務支援的跨日誌查詢語言。為了執行此方式，所有事件都必須遵循正確定義的結構。
舊版事件日誌提供了某種事件結構，但該結構並未完整定義，而且只能使用 Win32 API 檢視。而在 Windows Vista 中，事件擁有完整定義的結構。事實上，事件對外是使用具備已發佈結構描述的 XML 呈現。如此就能建立查詢，以收集您需要的事件，同時篩選掉無關的事件。由於使用 XML 的關係，XPath 就成了事件查詢語言的基礎。當然，使用結構化事件開啟了自動化的新視野，如同在新的工作排程器整合中所見。
現在，事件預覽窗格包含了 [詳細資料] 索引標籤。[事件內容] 對話方塊中也提供同樣的索引標籤。選取 [事件內容] 對話方塊上的 [詳細資料] 索引標籤就會顯示事件的 XML 表示方式。[圖 3] 中顯示的範例為工作排程器中的作業事件。其中包括兩個部分。系統部分是由此事件的每個事件執行個體中常見的一般事件資訊，以及發佈執行個體時收集的一些系統參數所組成。EventData 為可延伸的區段，其中包含應用程式的結構化資訊。
圖 3 事件的 XML 表示方式
圖 3 事件的 XML 表示方式
每個事件日誌檔都會視為這類結構化事件元素的順序。這代表一種邏輯、可閱讀的事件日誌和事件保存檔檢視方式。事件會在內部儲存為二進位格式，此格式的設計在於提供精簡度、可靠性與搜尋效能之間的平衡。

事件屬性
XML 資料的 System 區段提供事件發生的時間、處理序識別碼、執行緒識別碼、電腦名稱，以及使用者的安全性識別碼 (SID)。在舊版 Windows 中，事件只有兩種屬性：EventID 和 Category。而 XML 還會提供其他詳細資訊，包括 EventID、Level、Task、Opcode 及 Keywords 屬性。現在就來看看這些屬性的細節。
EventID 和 Version：事件會由其 EventID (兩位數字) 和 Version (一位數字) 的組合單獨識別。來自相同事件提供者且共用 EventID 和 Version 的所有事件，會共用相同的結構。
Level：這個值代表事件的嚴重性或詳細程度。預先定義的值 1 (嚴重)、2 (錯誤)、3 (警告)、4 (資訊) 及 5 (詳細) 為常用值，但是提供者可以定義自己的值，且最大值為 255。數字越大，表示事件越詳細。
Task：Task 屬性通常會識別事件提供者的一般功能區 (例如，列印、網路功能或 UI)。此屬性也可以代表程式的子元件。安全性稽核事件即廣泛使用此屬性。每個事件發行者都可為這個兩位數字定義自己的一組值。不過請注意，Task 屬性的意義通常會在語義上與舊版 Windows 中的 Category 屬性相符，而且為 Category 屬性的超集合。基於這個理由，事件檢視器會在稱為 [工作類別] 的欄位中顯示此值。
Opcode：此為一位數的值，通常用來代表軟體執行的特定動作或動作的一部分。此值常在追蹤活動為主的程序中使用 (例如 Web 服務，而活動則是 Web 服務收到的特定要求)。這個屬性有少數預先定義的值，最常見的值包括 1 (開始) 和 2 (停止)。
Keywords：這是一個包含 56 個旗標的遮罩，可由程式設定，以方便將類似的事件設為群組。而每個事件可以設定一個以上的旗標，表示該事件屬於多個群組。

瞭解發行者和事件
如果事先不知道能夠在事件日誌和追蹤檔中找到的所有資訊類型，就很難主動出擊。因此，我們對於新事件基礎結構的主要目標之一，就是針對每個事件發行者提供文件，包括事件及其目的地的組合資訊。
為了達到此目標，每個發行者都必須列舉將隨著事件結構發行的所有事件。這項資訊會經過編譯、編碼，然後隨發行者的 Binary (程式或 DLL) 儲存。
您現在可以找出所有在事件記錄系統中註冊的發行者，以及每個發行者的組態。其中包括檢視某個發行者可能記錄之所有事件的完整清單、這些事件的結構，以及相關的訊息 (甚至是在事件發生之前)。[圖 4] 顯示如何使用命令列公用程式 wevtutil 顯示提供者組態。圖中顯示的命令會顯示系統對於名為 Microsoft-Windows-Video For Windows 的事件發行者已知的所有相關資訊。
圖 4 使用 wevtutil 顯示提供者組態
圖 4 使用 wevtutil 顯示提供者組態

查詢語言的運作方式
之前已提過，新的基礎結構中事件的結構化本質能夠讓我們納入查詢語言的支援，而該語言是以標準的 XPath 運算式為基礎。一般來說，只要提供起始位置 (XML 元素)，XPath 運算式就能參考元素內的任何位置 (如需 XPath 語言的完整說明，請參閱 w3.org/TR/xpath 網站上的官方參考資料)。XPath 運算式更常參考起始元素內包含的其他元素或屬性。由於事件日誌基本上是 Event 元素的順序，因此您可以假設每個日誌的外觀看起來就像這樣：
<root>
<Event>... </Event>
...
<Event>... </Event>
</root>
根元素並沒有名稱，它只不過是當作所有 XPath 運算式的關聯內容使用。真正會定義的是前面的 X，這表示 XPath 運算式可參考 Event 元素、其子元素及屬性。而如果 XPath 運算式選取的元素存在，便會評估為 true。現在一起來看看，以 [圖 3] 中所顯示事件為主的相當簡單的 XPath 運算式：
*/System[Provider/@Name='Microsoft-Windows-TaskScheduler' and Level <= 2]
此運算式會選取 Microsoft-Windows-TaskScheduler 事件提供者中，等級 2 或更小 (也就是所有錯誤和嚴重事件) 的全部 Event 元素 (「全部」是以星號表示)。
雖然使用簡單的 XPath 運算式就能夠選取單一日誌中的事件，但簡單而強大的 XML 查詢語言還能讓您選取和抑制任何日誌或外部事件保存中的事件。事實上，查詢語言已在 Windows Vista 事件記錄中普遍使用。例如，自訂檢視就是以查詢為主。您可以使用查詢語言指定要在事件檢視器的事件清單窗格中，顯示哪些來自不同特定日誌的事件。您可以使用語言訂閱事件、保存選取的事件，以及觸發新的工作排程器中的動作。
實際的查詢 XML 或 XPath 運算式必須提供給事件日誌命令列公用程式。不過並非每個人都懂得定義這類查詢，因此事件檢視器提供了簡單的使用者介面來建立常用的查詢。例如，[圖 5] 中顯示的 [建立自訂檢視] 對話方塊就可以用來為所有工作排程器事件建立檢視。但請注意，每個查詢建立對話方塊都有一個 [XML] 索引標籤，這個索引標籤會顯示查詢文字，並且讓您直接編輯查詢。
圖 5 建立常用查詢的使用者介面
圖 5 建立常用查詢的使用者介面

常見的查詢用法
使用查詢的方式有許多種。其中自然有些使用方式會比其他方式更常用。例如，查詢常用來檢視事件檢視器中，甚或事件日誌命令列公用程式中的選取事件。
您可以使用 Windows 工作排程器將工作附加至查詢。當符合查詢的事件發行時，工作排程器就會啟動指定的工作。但須注意的是，此功能會使用訂閱並且回應任何最近出現的事件。您只能訂閱管理和作業事件；偵錯和分析事件則會直接寫入追蹤檔，因此系統無法在這些事件發生時進行檢查。
查詢可以用來保存選取事件。您可以從任何類型的即時日誌、下層事件保存 (EVT 檔)、外部追蹤檔，或 Windows Vista 事件保存檔中選取事件。保存檔可在事件檢視器中開啟，備份至次要保存區，或傳送給支援人員協助診斷問題。所有事件說明和其他事件相關字串，都可以使用保存作業期間選取的語言附加至保存檔。如果完成此作業，事件就會包含任何電腦選擇使用之語言的完整說明。
最後，查詢可以用來將事件轉寄至專門收集事件的系統。此功能會使用新的事件收集站服務，可讓管理員建立遠端電腦的事件訂閱。這些訂閱會保留在收集站電腦上，並且可以使用可設定的排程進行重試。事件收集站會使用業界標準的 WS-Management 通訊協定在遠端電腦上建立訂閱，並且使用 WS-Eventing 通訊協定傳輸事件 (這兩種通訊協定都很安全並且與防火牆互動良好)。事件收集站收到的事件會儲存到本機的事件日誌中。

結論
Windows Eventing 的變更相當大幅且廣泛，本文所討論的內容僅為開端。單就事件轉寄功能便足以撰寫一整篇文章。
事件系統在效能、延展性、可靠性及安全性上擁有許多改善。但請別忘記，我們的主要目標在於改善 Windows 的管理能力。事件檢視器檢視使用的查詢語言可讓您更輕鬆地發現問題。與工作排程器的緊密整合則開啟了簡易監控、自動化問題解決方案，以及開發迅速通知問題的方式。而事件轉寄則使得伺服器與桌上型電腦能夠保存事件並且在不需代理程式的條件下進行監控。
這些功能都能在不需犧牲舊版相容性的情況下實作，也就是說，現有的解決方案將持續運作。最後要強調的是，事件記錄的改善功能可協助組織更有效地管理系統。

Val Menn 服務於 Microsoft 的管理基礎結構小組，並擔任事件日誌的程式經理。之前則是許多啟動程式的軟體工程師與系統管理員。


 Windows Vista: Windows Vista 中更強大的群組原則
Windows Vista Jeremy Moskowitz

Windows Vista 中更強大的群組原則
摘要:
  • 群組原則基礎結構
  • 改善的網路覺察
  • 新增的群組原則功能

Windows Vista 大幅度更新了群組原則基礎結構。而當世界各地的組織部署 Windows Vista 時，許多管理員可能不會注意到其工作方式已有所變更，因為群組原則功能中的許多變更
是以隱匿的方式完成。不過，管理員將會發現 Windows Vista™ 群組原則已經比舊版更為強大。
在 Windows Vista 之前，群組原則處理是在稱為 winlogon 的處理序中發生。Winlogon 必須負起大部分的責任，包括讓使用者登入其桌面，以及提供服務給不同的群組原則例行工作。而現在，群組原則本身就是一項 Windows® 服務。此外，其方式更為強硬，這表示此服務不但無法停止，管理員也無法取得群組原則權限的擁有權並藉此關閉這項服務。這些變更加強了群組原則引擎的整體可靠性。
而這只是個開端。現在讓我們更深入瞭解新群組原則中的幾項主要變更。

改善的網路覺察
在 Windows Vista 之前，群組原則引擎會嘗試判斷連結的快慢。接著會利用這項資訊建立將套用的原則設定。若是透過慢速連結，群組原則就不會傳送整個原則設定至您的系統，因為這樣可能需要相當長的下載時間。新的群組原則中仍保留這項協助功能。而改變的是計算目前網路頻寬的方式。
此速度是藉由傳送「網際網路控制訊息通訊協定」(ICMP) Ping 封包至網域控制站所決定。此方法在實際運用上已有許多問題。首先是許多管理員會關閉其路由器上的 ICMP。其次是，如果連線是透過經常延遲的連結 (像是衛星)，那麼計算出的結果就不可靠。而在這些情況下也就無法保證群組原則引擎判斷出的連結速度是否為真。
此外，群組原則引擎無從得知電腦是否已從休眠或待機狀態復原。即使您在未連線六個月之後忽然再次撥入，群組原則引擎也不會得知。使用者可以使用執行 Windows XP 或 Windows 2000 的電腦撥入、查看電子郵件然後斷線，而這一連串動作並不會讓群組原則更新。大部分管理員會希望必要時能夠在從休眠或待機復原的系統上，或於長時間離線之後再次撥入的電腦上執行群組原則更新。
更新的 Windows Vista 群組原則變得更為聰明，能夠得知即時的網路連線狀態。主要的變更即在於，現在群組原則引擎在 Windows Vista 中是使用「網路定位知悉服務 2.0」(NLA) 處理常式。NLA 服務會在網域控制站可使用時提醒群組原則引擎。在取得與網域控制站的聯繫後，就可以依需要執行群組原則更新。

多項本機 GPO
在 Windows Vista 之前僅支援一項本機群組原則物件 (GPO)。如果您在命令提示字元中鍵入 GPEDIT.MSC，並且變更部分設定，就會影響每一位使用該電腦的使用者和管理員。通常當您要移除一般使用者 [開始] 功能表中的 [執行] 命令，但仍要讓管理員使用此命令時，就會是個問題。
新的多項本機 GPO 功能即利用 GPO 層解決了這個問題。此功能多半會在未加入 Active Directory 網域的系統上使用。不過，此功能對於企業使用者來說也會相當實用。
新的多項本機 GPO 功能是以分層為主，因此可能會稍微複雜 (請參閱 [圖 1])。預設的本機 GPO 仍然存在，而且會套用至本機電腦系統的內容，並影響系統上的所有使用者。此 GPO 同時定義電腦設定及使用者設定。
圖 1 使用者的全部本機群組原則
圖 1 使用者的全部本機群組原則
第二層會影響本機系統 Administrators 群組或本機系統上非 Administrators 群組的成員。根據定義，使用者帳戶無法同時屬於這兩個群組。這一層會判斷使用者屬於本機系統管理員或是一般使用者，然後套用適當的 GPO (Administrators 或非 Administrators)。第三層會影響特殊命名的本機系統使用者帳戶。
以上就是三個可能的本機 GPO，三者都會影響任何登入電腦的特定使用者。例如，您可以使用這三個分層提供特定電腦上每一位使用者的設定、僅影響電腦上非 Administrators 的其他設定，以及僅影響該電腦上特定單一使用者的設定。
當然，如果系統已加入 Active Directory® 網域，則 Active Directory 群組原則物件會優先於本機原則。另外須注意的是，網域管理員可以選擇關閉 Windows Vista 的所有本機 GPO 處理。

錯誤訊息和疑難排解
Windows Vista 擁有全新的「事件日誌」系統。群組原則引擎會運用這套新的 Windows Eventing 6.0 系統 (一般稱為「事件日誌」) 並將事件分割成兩個特殊的日誌。一般熟知的「系統記錄」(現在稱為「管理日誌」) 負責記錄群組原則問題。如果群組原則引擎發生錯誤，該錯誤會在系統記錄中列為來自群組原則服務 (而非 Userenv 處理序)。
新的「應用程式與服務」日誌 (亦即「作業日誌」) 為群組原則專屬，其中保存作業事件。此日誌會實際取代繁瑣的 userenv.log 疑難排解檔案，因為群組原則引擎的每個步驟都會在此列出以方便讀取。

ADM 和 ADMX
早在開始使用 Windows NT® 4.0 時，ADM 檔就已提供群組原則中擁有的基本定義範本。雖然 ADM 檔並未控制群組原則中的一切，但是除了 [電腦設定] | [系統管理範本] 以外，這些檔案還須負責 [使用者設定] | [系統管理範本] 下的所有項目。
功能上來說，這些 ADM 檔案有些瑕疵。在 Windows Vista 之前的 Windows 版本中，每次建立新的 GPO，就得將一大堆 ADM 檔案複製到每個 GPO 資料夾中 (位於 SYSVOL 中)，而每個 GPO 大約為 5MB。而這一大堆 GPO 造成 SYSVOL 上出現許多重複的系統範本檔，因而造成每個 5MB 容量中出現許多重複的項目。
此外，ADM 檔並不是非語言相關。ADM 檔是以一種語言建立，而使用該檔案的每個人都必須自行應付該語言。
為解決這些問題，Windows Vista 中的群組原則針對原則定義檔引進了新的 XML 格式稱為 ADMX。ADMX 檔本身即為非語言相關。不過，這些檔案必須搭配語言專用的 ADML 檔使用。您只要加入多個 ADML 檔搭配 ADMX 檔，就能輕鬆加入多種語言。
ADMX 格式支援中央存放區。如此即可避免複製重複的資訊，更能輕鬆更新 ADMX 檔。假設某個 Service Pack 更新了 ADMX 檔，那麼您只要將更新的檔案放入中央存放區就行了。網域中使用 Windows Vista 工作站的所有群組原則管理員都將能夠存取更新的 ADMX 檔。以往，您必須確認每位管理員的電腦都有正確的更新 ADM 檔，而這項工作相當具挑戰性。
網域管理員必須在 SYSVOL 上手動建立中央存放區，而且必須針對每個 Active Directory 網域執行一次此操作。建立中央存放區之後，使用 Windows Vista 電腦建立和管理 GPO 的所有管理員都會自動使用中央存放區。請注意，此為 Windows Vista 專屬的功能，而且檢查中央存放區是否存在的是已加入 Active Directory 網域的 Windows Vista 電腦。您不需等待下一版的 Windows Server® (代號為 "Longhorn")，也不必將使用者電腦轉換成 Windows Vista。無論網域是以 Windows Server Longhorn、Windows Server 2003 甚或 Windows 2000 為基礎，情況都相同。若要使用中央存放區，您只需要建立中央存放區，然後使用 Windows Vista 電腦建立或管理 GPO 即可。
如前述，ADMX 和 ADML 檔是以 XML 為基礎。XML 的主要益處在於使用業界標準的語言。不過值得一提的是，目前並沒有 ADMX 圖形化編輯器 (Microsoft 未打算發行任何圖形化編輯器)。此外，也沒有將 ADM 轉換成 ADMX 的工具可用於任何您可能擁有的自訂 ADM 範本。
Windows Vista 將隨附約 130 個 ADMX 檔，取代舊版 Windows 隨附的 6 到 8 個 ADM 檔。這些檔案位於 \Windows\PolicyDefinitions 目錄中，如 [圖 2] 所示。請注意，ADML 檔會存放在特定語言的子目錄中，例如 en-US 目錄用於英文 (美國)。
圖 2 \Windows\PolicyDefinitions 目錄中的 ADMX 檔

群組原則管理主控台
「群組原則管理主控台」(Group Policy Management Console，GPMC) 為 Windows XP 和 Windows Server 2003 的下載項目。可編寫指令碼的 Microsoft Management Console (GPMC) 提供了管理群組原則的單一管理工具。
GPMC 現已內建於 Windows Vista。這表示您可以隨時存取最佳的工具，以建立或編輯 GPO。只要在 Windows Vista 的 [開始 | 搜尋] 命令提示字元中鍵入 GPMC.MSC，就可以開始執行工作。

新的控制項目
Windows Vista 中擁有約 800 項新的原則設定。這些設定分布於多個不同的類別中，其中多項是您已熟知且倚賴的設定。此外，Windows Vista 還引進了一些相當棒的新類別，有些是前所未見的，有些則是沒有任何群組原則控制。
群組原則中增強的功能包括有線和無線網路原則、Windows 防火牆和 IPsec、列印管理、桌面殼層、遠端協助，以及 Tablet PC。請注意，更新的有線和無線原則可能需要整個樹系的架構更新 (如需相關的詳細資訊，請參閱 microsoft.com/technet/itsolutions/network/wifi/vista_ad_ext.mspx)。
Windows Vista 群組原則中的新功能包括卸除式存放裝置管理、電源管理、使用者帳戶控制、Windows 錯誤報告、Network Access Protection 以及 Windows Defender。
若要控制單獨影響 Windows Vista 電腦的功能，則建立或編輯 GPO 時必須使用 Windows Vista 電腦 (或 Windows Server "Longhorn" 電腦)。這是因為舊版的作業系統無法識別這些 Windows Vista 專屬的新設定。
深入探討這些新功能的任何一項都會需要整篇文章，因此本文將不會深入每項功能的細節。不過，特別值得注意的是卸除式存放裝置管理功能和電源管理功能 (如 [圖 3] 所示)。我預料這些功能將廣泛成為系統管理員的利器。簡單來說，這些功能可讓您進一步控制能夠連接至 Windows Vista 的裝置，以及筆記型電腦、桌上型電腦和監視器將用來為公司節省開支的電源設定。
圖 3 透過群組原則強制執行電源管理
圖 3 透過群組原則強制執行電源管理
只要利用 Windows Vista 中額外的電源管理設定，管理員就能選擇關閉或讓未使用的視訊顯示監視器進入低電源的「睡眠」模式。Environmental Protection Agency 的 Energy Star 網站上公佈的研究顯示，控制監視器的電源用量可讓每部監視器每年節省 $10 到 $30 美元。若您公司內有數百或數千部監視器，那麼省下的開支將會相當可觀。
至於卸除式存放裝置管理，請考慮下列情況：管理員想要讓學生使用 USB 快閃磁碟機存取校園資訊工作站上的論文報告、作業或其他文件。不過，基於可能發生的誤用以及潛在的安全性風險，學生「不」應擁有校園資訊工作站上 USB 磁碟機的寫入權限，除非是學校核准的 USB 磁碟機。這類裝置管理的細節可以使用 Windows Vista 群組原則設定來完成。

總結
如您所見，這些 Windows Vista 管理的改善內容都是在您未察覺的情況下發生。管理員將發現，Windows Vista 群組原則提供了強大而靈活的設定管理，其中包括大幅增加的可規劃設定，以及提升系統安全性的新資源 (還能降低成本)。
群組原則的進一步創新
本文中所述的大致上是將隨 Windows Vista 提供的功能。然而，群組原則團隊已開始構思未來的創新內容。更多的群組原則功能很可能會在 Windows Server "Longhorn" 期間提供。雖然這些功能不會在一開始隨 Windows Vista 提供，但仍可能透過 Service Pack 或其他附加元件機制提供給 Windows Vista。因此，即使這些即將提供的新功能隨時可能改變，未來仍會有三項預定的主要改善功能。而且可以確定的是，這些功能都不需要 Windows Server "Longhorn" 就能執行。
註解 其中一項經常要求的功能為加入描述每項 GPO 功能，或任何特定群組原則設定功能的註解。目前加入註解的唯一方法是，利用試算表追蹤記錄 GPO 和設定，然後在試算表中加入註解。輸入註解的功能將會是相當受歡迎的新增功能。
範本 管理員有時候會想要提供其他管理員開始建立自己的 GPO 的入門指示。群組原則範本將提供這項能力。管理員可先從使用範本開始進行，之後便能建立自己的自訂 GPO。Microsoft 可能會在初始的範本集中加入常用的案例，提供如何控制不同類型電腦的特定指導方針 (如需相關的詳細資訊，請查看常用案例文件和檔案 (英文))。
搜尋和篩選器 在看似數以百萬計的眾多原則設定中，有時候很難找到您需要的特定原則設定。幸好即將提供的搜尋功能將會讓您更容易搜尋原則設定的標題、說明文字和註解的內容。GPO 內啟用或停用的原則設定也將一目了然，因此更容易迅速變更發生錯誤的 GPO。
您可以瀏覽 Windows Server 意見入口網站，並提交額外的群組原則功能要求，網址為 windowsserverfeedback.com (英文)。

Jeremy Moskowitz 為群組原則中的 MCSE 和 MVP，他經營的 GPanswers.com 是有關群組原則的社群論壇。此外，他還舉辦為期兩天的群組原則密集訓練課程。他的最新著作為 Group Policy, Profiles and IntelliMirror, Third Edition (Sybex, 2005)。您可以透過下列網站連絡 Jeremy：www.GPanswers.com (英文)。感謝 Microsoft 群組原則團隊的 Mark Lawrence 協助提供相關參考資訊。


 編輯的話: 準備好迎接 Windows Vista
編輯的話
準備好迎接 Windows Vista

WINDOWS VISTA 目前 處於發行候選版本階段，要不了多久，最終版本就將付諸製造。我們發行這一期特別的 TechNet Magazine，期望能為正準備試用和部署這個最新作業系統的各位提供指引。
您一定已經聽說，您需要全新的電腦才能執行 Windows Vista。這很可能不是真的。Windows Vista 將提供數種不同的組態：Business、Enterprise、Home Basic、Home Premium 和 Ultimate。猜猜看哪一個可以為您提供極致的體驗！
所有版本都在安全性和可靠性方面進行了改善，但還會進行進一步的修改，以提供最適合目標使用者的功能。您可以在下列網頁找到有關這些版本的資訊：Get Ready:The Editions (英文)。
若要判斷您電腦將如何執行，最好的方式就是使用 Windows Vista Upgrade Advisor (英文)。此工具會掃描您的電腦，並報告其 CPU、記憶體、圖形和附屬應用程式的評比。Windows Vista 只會安裝至您的電腦可以負荷的程度，所以如果您的電腦使用舊型的圖形介面卡，您就不會自動得到封面上閃亮的全新 Aero 介面。不過，您仍可以獲得改良的安全性、可靠性和其他等等優勢。
新增的安全性功能使得在電腦上意外引進惡意軟體的機會大為下降，也讓非必要的管理權限更容易解除。您可能會聽到一些較為「獨立」的使用者開始批評耳語，但您的回應很簡單 -「沒什麼比安全更重要」。同樣地，您的人員可能要歷經一些陡峭的學習曲線，所以請下載發行候選版本，並以沙箱執行一段時間。您最好準備好面對接下來的問題。
談到準備，沒有什麼比這份雜誌更適合的了，其他的 TechNet 方案則可做為補充資料。您會找到許多針對 IT 專業人員提供的其他資源，其中包含了測試和部署 Windows Vista 的豐富資訊：為 IT 專業人員所提供的 Windows Vista 資源 (英文)。您甚至可以直接從 Windows Vista 小組取得資訊：Windows Vista Team Blog (英文)。接下來的 18 個月將為桌上型電腦帶來重大變革，預作準備絕對值得。
—JOSHUA TRUPIN

感謝以下的 Microsoft 技術專家：Derk Benisch、Steve Campbell、Mike Chan、George Holman、Khushru Irani、Kamal Janardhan、Michael Keigley、Mark Lawrence、David Lowe、Mike Lewis、Nathan Muggli、Michael Murgolo、Roger Wolter 和 Andy Zeigler。


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

監控網路
Alchemy Eye
alchemy-lab.com (英文)
天底下絕無永不發生故障、絕對可靠的基礎結構和應用程式堆疊，所以保障您的利益最好的辦法之一就是比別人更早發現問題，而這正意味著您的手邊應有一套強大的全功能網路監控公用程式。若有任何服務不幸意外中斷，您當然希望能夠迅速做出反應並著手修復問題，而不是等到上司手裡抓著一把表達憤怒的電子郵件 (沒錯，他們還把電子郵件印了出來) 破門而入闖進辦公室後才知道出了問題。
Alchemy Labs 提供了可擴充的服務監控應用程式，此應用程式名為 Alchemy Eye，可協助您比其他使用者提早一步發現問題。新增服務監視器的操作很簡單，而且只要按幾下滑鼠就可以複製先前建立的監視器。此應用程式將每個服務視為一部伺服器，但若要監控同一部電腦上的多個 IP 和服務，則必須建立多個應用程式「伺服器」。
Alchemy Eye，功能強大的網路監控公用程式
Alchemy Eye 針對每個受監控的服務提供了許多種通知機制。您可以選擇每當服務中斷和恢復正常時都發出警示。您也可以透過電子郵件、傳呼器/簡訊、ICQ 或 MSN® Messenger 傳送通知。此外，您還能在受監控的服務中斷時執行可執行檔，以便記錄事件日誌項目、播放音效、透過 ODBC 連線執行 SQL 查詢、執行 VBScript 或 JavaScript，或執行以上所有作業。如果您覺得這些選項還不夠用，亦可另購其他的通知外掛程式。最後，如果該程式本身的功能或加上可洽網站另購的外掛程式都不能滿足您的需要，您也可以支付額外費用向其公司申請建置自訂外掛程式。
我個人特別偏愛的一項功能，是能夠為每個服務新增維護視窗。透過這些視窗可以暫停監控伺服器資源，因此可避免在排定停機維修期間發出錯誤警報。您也可以在觸發某個事件時嘗試重新啟動 Windows® 服務，雖然這可能需要仰賴遠端 RPC 呼叫，而且必須交由有權重新啟動應用程式的帳戶來執行 (您的基礎結構或許不允許這麼做)。
如果您需要監控大量服務，可將服務群組分成數個資料夾組合管理，如此更便於管理清單。此應用程式也提供了一組 HTML 報告，可讓您產生正常執行狀況報告交付上司審閱。報告的內容區分為服務可用性、事件日誌統計資料、錯誤類型和故障次數等。
售價：每一份授權 $299 美元。

對應網站結構
PowerMapper Professional 4.0
www.powermapper.com/pro.htm (英文)
建立網站地圖和連結檢查似乎是每一位網際網路工程師的一項日常工作。Electrum Multimedia Ltd. 的 PowerMapper Professional 4.0 為您提供了尋檢網站 (檢查錯誤連結) 的簡易辦法，並可產生美觀的網站結構圖表報告。
當您建立好網站地圖後，可以視個人需要選擇地圖樣式來自訂地圖。此應用程式內建七種地圖樣式，如網頁雲狀標示、樹狀檢視或目錄格式等。最後產生的地圖亦可供點選，讓您能夠逐頁瀏覽網站地圖。大型網站更可利用多頁列印功能，印出大幅頁面圖供簡報展示或進行資訊結構會議時使用。
PowerMapper 提供尋檢網站的簡易辦法
PowerMapper Professional 4.0 另一項出色的功能是，可以匯出為協力廠商的格式，如 Microsoft® Excel® 和 Google 網站地圖格式。
售價：$349 美元。

書評
Microsoft Windows Scripting Self-Paced Learning Guide (英文)
程序自動化是造就 IT 作業環境成功的一項關鍵因素。若欠缺這項因素，IT 專業人員將陷於日復一日不斷執行重複性的工作而永不得解脫。根據我的經驗，真正積極主動的 IT 工作團隊可以激勵員工士氣。
因此，Microsoft Windows Script Host 搭配 VBScript 將賦予您既功能強大又可自訂的自動化工具，而由 Ed Wilson 所著 Microsoft Windows Scripting Self-Paced Learning Guide 一書 (Microsoft Press®，2004 年出版) 則為您展示如何擺脫重複性的無聊工作。
本書是從「操作」的角度出發，所以即使您不是開發人員也不用擔心看不懂。例如，第二章〈Getting in the Loop〉說明了如何以程式設計的方式宣告變數、連接檔案系統及登錄，還有如何使用 for 和 while 迴圈。
等到您掌握了語法後，本書開始接著闡述系統管理，並說明如何精通使用 FileSystemObject 進行檔案和目錄操作，極適合應用於自動化封存系統和網頁記錄。
然後，本書介紹了 Windows 管理介面 (WMI) 的強大功能，並展示如何透過 Windows Script Host 和 VBScript 收集與操作資料。您可以利用 VBScript 搭配 Windows 工作排程器，根據經由查詢 WMI 測試所得的磁碟閾值來執行動作。
本書第三部分探討 Active Directory 服務介面 (ADSI)，展示如何連接 Active Directory 以執行相關工作，例如匯入使用者清單及變更其密碼，或根據使用者的組織單位成員資格進行磁碟機對應。本書也說明了如何使用登錄，以及建立、修改或刪除登錄機碼。
本書最後部分介紹如何使用 VBScript 管理 IIS 6.0，自動化諸如建立網站或虛擬目錄等重複性的工作，以及如何連接與使用 Exchange Server 2003 來檢查佇列狀態。
總而言之，在所有的 IT 作業專業人員的書架上，本書都應佔有一席之地。
售價：$44.99 美元。

使用功能強大的文字編輯器
TextPad
www.textpad.com (英文)
這是一款不錯的編輯器，不僅能精確顯示檔案內容，還提供快速而強大的編輯工具，且支援任何類型的字元集，絕對是 IT 專業人員的必備工具。Helios Software Solutions 的 TextPad 提供了您所需要的一切功能。有別於我所試用過的其他編輯器，TextPad 能夠開啟並修改超大檔案，而不致拖累電腦或應用程式處理序的執行。此應用程式僅受限於其執行所在電腦的虛擬記憶體數量。
您可以同時開啟多個檔案，然後透過使用者介面上可供選擇的索引標籤或清單檢視，輕鬆地在檔案之間切換。TextPad 還有另一種很棒的檢視稱為 Clip Library，只要在其中按兩下就能輕鬆快速插入控制字元、MS-DOS® 字元或 ANSI 特殊字元。Clip Library 也會保存剪貼簿的歷程記錄，讓您方便從先前剪下的內容拖放文字加入，除此之外還能選擇 HTML 標記和 HTML 字元而將 HTML 放入文字檔。此應用程式實際上並未限制可執行復原和重複功能的次數，因此您可追蹤回復自從開啟文件以來所有操作過的步驟。
TextPad 最棒的其中一項功能是 Document Class，可根據文件類型的副檔名來擴充採用色彩編碼的語法檔案。因此您將能夠輕鬆地對 HTML 和 VBScript 等特殊檔案格式加註色彩編碼。您想像得到的任何檔案類型幾乎都可建立語法檔案，而且如果您不打算自己從頭到尾建立 (其實這是很簡單的程序)，只要稍加搜尋網際網路通常就能找到所要的範本。
TextPad 另一個有用的功能，是可以將您常用的工具加入編輯器的功能表做為增益集。例如，在 TextPad 網站上有個小秘訣，示範了如何利用工具整合功能直接從應用程式內編輯和執行 VBScript，從而加速完成系統管理工作。
使用 TextPad 開啟並修改超大檔案，而不致拖累電腦的執行
使用 TextPad 開啟並修改超大檔案，而不致拖累電腦的執行
TextPad 使用者介面目前已翻譯為七種語言，且附帶十種不同語言的拼字檢查字典。所有的基本功能也都涵蓋在內，包括顯示行號、欄位置和設定文字換行等等。
您也可以點選滑鼠進行搜尋、排序和縮排，而無須在檔案中添加任何多餘內容。TextPad 提供的尋找/取代功能極為出色，此一既強大又簡單的功能可快速修改整篇文件中重複的內容。您可以尋找文字或十六進位值，比對整個單字或其中若干字元，甚至更棒的是使用規則運算式快速尋找所需對象並予以取代。搜尋範圍亦可自訂為選取文字、使用中文件或目前開啟的所有文件。
TextPad 還提供巨集功能，如果您需要反覆執行相同的鍵盤動作，即可錄製巨集讓這些步驟自動完成。
如果上述功能仍不夠用，TextPad 已與 Windows 檔案總管整合，只要在任何檔案上按右鍵，就能從快顯功能表迅速編輯存取。
售價：每份單一使用者授權 $29 美元。

工具箱徵文
如果您希望在本專欄中介紹偏愛的工具或公用程式，請與作者連絡，寄電子郵件到 tntools@microsoft.com。

本專欄所表達的觀點僅為作者個人意見，未必反映 Microsoft 的觀點。所有售價均於出刊時經過確認，隨時可能有所變動。

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


 公用程式精選: Robocopy GUI
公用程式精選
Robocopy GUI
Joshua Hoffman
下載本文程式碼: UtilitySpotlight2006_11.exe (1052KB)

不容忽視的基礎 無論您是 IT 專業人員或只是家用電腦的使用者，試著想像不必再複製檔案的情形。無論您要建立桌上型電腦部署的主要映像、發行新網頁至網頁伺服器，或只是要備份或重新整理自己的文件和照片，複製檔案絕對會是您每天與個人電腦互動的核心作業之一。
不過問題就是在這裡。Microsoft® Windows® 內建的傳統「複製與貼上」功能有其限制。對於簡單的工作來說 (在目錄之間移動文件等)，這項功能綽綽有餘，但是它缺乏 IT 專業人員在職場中所需的進階功能。例如，複製與貼上作業並不包括任何進階的復原能力，無法在發生短暫的網路中斷之後進行復原。此作業同時也是孤注一擲的方法，尤其是在複製完整的目錄時。您無法透過使用者介面選擇單獨複製新檔案或已更新的檔案。您只能複製個別檔案、整個目錄，或是全部不複製。
Robocopy 登場。這項功能強大的工具隨附於 Microsoft Windows Server® 2003 Resource Kit Tools (英文)，提供了上述所有進階功能以及其他功能。Robocopy 能讓您執行更全面的檔案複寫工作，並且確實簡化您的作業。我想，這套工具的最大好處在於建立兩個檔案結構之間完整鏡像的複寫能力 (包括您選擇的所有子目錄和檔案)，而不會複製任何不需要的檔案。只有來源位置中的新檔案或已更新的檔案才會複製。Robocopy 還能讓您保留所有相關的檔案資訊，包括日期和時間戳記、安全性存取控制清單 (ACL) 等。
當然，每個人都有自己的工作方式。有些人喜歡使用命令列，而對於這些人來說，Robocopy 工具本身即相當理想。不過，其他人可能比較喜歡使用指標點選的方式，而對於這些人來說，Robocopy GUI 即為理想工具。這項受歡迎的 Robocopy 附加元件是由 Derk Benisch 這位 Microsoft MSN Search 小組的系統工程師所提供。Derk 的公用程式可讓使用者利用簡單且外觀十分熟悉的圖形介面，自訂 Robocopy 指令碼 (請參閱 [圖 1])。
圖 1
無論您是否要建立磁碟機對應，或是要儲存結果記錄的位置為何，Robocopy GUI 都可讓您指定來源和目標路徑，以及任何要套用的自訂選項或篩選條件。這些都是能夠透過傳統的 Robocopy 命令列執行的功能，但是對許多功能而言，如果能以圖形化介面整合其選項的話，更能簡化操作過程。
Robocopy GUI 還能以十分有趣的方式延伸現有 Robocopy 工具的功能。例如，此工具為多執行緒工具，能讓您建立 Robocopy 指令碼、執行指令碼，並且在第一個指令碼執行的同時開始建立另一個指令碼。此外還能讓您儲存指令碼 (即使您並未實際執行這些指令碼)，以便建立常用指令碼的程式庫或是與同事共用您的指令碼。最重要的是，Robocopy GUI 可讓您儲存預設值，如此您就不必每次都從頭開始進行。
Robocopy GUI 包括本身所屬的說明檔，以及一份內嵌的完整 Robocopy 參考手冊。此參考手冊包括所有 Robocopy 命令和語法的完整索引，能協助您判斷要使用的設定。
有了這些實用的功能，Robocopy GUI 就能為任何 IT 專業人員的工具箱錦上添花。您將可在我們網站上的下載區段 (英文) 找到 Robocopy GUI。

Joshua Hoffman 是 TechNet Magazine 的技術與徵稿編輯。


 SQL 問題與解答: 暫存資料表、64 位元處理、鏡像及其他資訊
SQL 問題與解答
暫存資料表、64 位元處理、鏡像及其他資訊
編輯：Nancy Michell

暫存資料表
問：我聽說為了避免爭用問題，最好不要老是使用暫存資料庫 tempdb。這是真的嗎？我會使用這個資料庫是因為我需要存取分散在多個資料表內的資料，甚至隨時加以修改。使用檢視表無法輕易辦到這一點。
答：的確如此，過度使用 tempdb 可能導致爭用問題。但是，正如知識庫文章 support.microsoft.com/kb/328551 所述，爭用通常是在罕見的情況下才會發生的問題，例如同時有數百個 SPID (伺服器處理序識別碼) 爭相建立和刪除大量暫存資料表的情況。
實際上，使用暫存資料表 (順便一提，不見得位於 tempdb 中) 是可接受的一種解決方案。關鍵在於與第一時間建立資料表的負擔相比，您從暫存資料表提取資料所獲得的效能提升是否較佔上風。
您必須先考量暫存資料表的大小、使用壽命、使用頻率，特別是作用中執行個體的數目，再決定是否摒棄這種方案。伺服器規模同樣重要，因為 tempdb 爭用可能與硬體有關。
如果您需要大量的小型臨時資料表，可以試著使用資料表變數，在某些方面會比暫存資料表更具優勢 (請參閱下一個問題的解答，以獲取資料表變數和暫存資料表之間差異的詳細介紹，並另請參閱「常見問題集 - SQL Server 2000 - 資料表變數」取得詳細資訊)。
以您的情況為例，如果所有對資料庫的查詢都必須經歷暫存資料表建立程序，則對原始資料模型進行查詢而非單僅試著使用資料表或許也是明智之舉。

問：何謂資料表變數，對效能有何幫助？我真的能用它們來代替暫存資料表嗎？
暫存資料表和資料表變數提供相同的基本功能；事實上，兩者均具體化為 tempdb 資料庫中的暫存資料表。不過，如果只插入少許資料列，資料表變數可提供較優越的效能。這是因為資料表變數不會保存任何統計資料或索引，所以負擔較輕。如果資料表內容不超過資料庫引擎將存留在資料快取中的 8KB 資料庫分頁大小，則使用資料表變數較好。
根據《SQL Server™ 線上叢書》：
  • 資料表變數就像是本機變數。其範圍定義明確，即以對其進行宣告的函數、預存程序或批次指令為範圍。在此範圍內，資料表變數可視同一般資料表使用。
  • 每當定義資料表變數的函數、預存程序或批次指令結束時，即自動清除資料表變數。
  • 與使用暫存資料表相比，在預存程序中使用資料表變數可減少重新編譯預存程序的次數。
  • 使用資料表變數時，需要鎖定與記錄的資源較少。
  • 在某些情況下可改善效能，儘管不會保存統計資料。

鏡像

問：我打算使用 SQL Server 2005 鏡像處理來支援高可用性。系統將在高可用性模式下執行，以支援自動容錯移轉。但我還想執行一些位於鏡像上的其他應用程式，以便充分利用資源。鏡像伺服器將支援兩個資料庫：Production DB 做為主要資料庫的鏡像，及 Staging DB 做為獨立資料庫。另外還要支援兩種用戶端類型：其一設定為鏡像容錯移轉後存取 Production DB，其一則直接連接 Staging DB。
此外，某些 SQL Server Integration Services (SSIS) 封裝將在鏡像伺服器上執行。這些封裝會存取以上兩個資料庫，將本機上的 Staging DB 傳來的資料轉送到在主要伺服器上執行的 Production DB。在容錯移轉期間，SSIS 封裝會將本機 Staging DB 傳來的資料轉送到本機 Production DB (進行容錯移轉)。這種組態是否還有哪些問題需要注意？
答：從一般看法來講，不建議使用這種組態，因為容錯移轉後的新主體可能不堪負荷。
就鏡像的觀點而言，整個組態的功能性似乎沒有問題，但若您要繼續實施此方案，便應徹底進行測試。測試應該在尖峰負荷時段，於容錯移轉後期使用標準組態進行。尖峰負荷應為估算的未來尖峰負荷而非目前的負荷值；您必須考慮到日後的商務需求，否則一旦負荷超過過去的容量，方案將無法運作。
測試後很有可能發現網路、磁碟甚至 CPU 的瓶頸，這些瓶頸具體表現時會是應用程式回應時間遲緩、輸送量不如預期、逾時錯誤，或鏡像伺服器不斷重排佇列 (視實際的重排率而定，可能導致容錯移轉超時太久出乎意料之外)。
此外，在容錯移轉期間執行封裝將造成與故障的主體中斷連線。一旦容錯移轉完成且新主體上的資料庫已可使用，封裝應能再與新主體重新連線才對。當然，其前提為：封裝內建連線重試機制並能正常處理連線錯誤，比方能夠從「已中斷」的連線狀態復原。

SQL Server 與 64 位元作業系統

問：如果我執行 64 位元版本的 Windows Server® 作業系統，就必須使用 SQL Server 2000 Enterprise Edition (64 位元) 而不能使用 32 位元 SQL Server 2000，是嗎？
答：從 SQL Server 2000 的觀點來看，唯一支援的原生 64 位元架構是 Intel 的 ia64。因此，SQL Server 2000 所謂的 64 位元支援是指 ia64。原生 64 位元 ia64 唯一支援的 SQL Server 2000 版本是 Enterprise Edition 版。既沒有像原生 64 位元應用程式一樣在 ia64 上執行的 SQL Server 2000 Standard Edition，也沒有在 ia64 Windows® on Windows (WOW，可執行 32 位元應用程式的作業系統子系統) 下執行的 SQL Server 2000 Standard Edition。
AMD x64 電腦要使用 SQL Server 2000 的話有兩種選擇。您可以執行 32 位元作業系統，在此情況下可執行任何 SQL Server 2000 版本及任何 Service Pack (SP)。或者，您也可以在 WOW 下執行 64 位元作業系統和 SQL Server 2000 (任一版本) SP4。執行於第二種環境的 SQL Server 2000 並非原生 64 位元應用程式，而是以 32 位元模式執行於 WOW 下，因此甚至不知道外界是 64 位元環境。
更確切地說，ia64 WOW 和 x64 WOW 是兩種截然不同的子系統。在 ia64 架構下，WOW 必須模擬受限制的虛擬位址空間，並進行實際的電腦指令模擬。ia64 電腦指令與 x86 完全不一樣，所以是截然不同的電腦。SQL Server 所有的元件 (SQL Server 2000 或 SQL Server 2005) 都不支援在 ia64 WOW 下執行。
而在 x64 WOW 下，情況則完全不同。x86 和 x64 電腦的架構非常相近。兩者擁有相同的指令集 (或幾乎相同)，所以只需要模擬 32 位元虛擬位址空間，而硬體更可在這方面提供協助。因此，SQL Server 多數元件都支援 x64 WOW，比方 SQL Server 2000 SP4 及 SQL Server 2005 任一版本。

升級到 SQL Server 2005

問：我想從 SQL Server 2000 升級到 SQL Server 2005。除了 SQL 程式碼的更新外，應用程式還有哪些方面需要更動？例如，若我要使用 Microsoft® .NET Framework 用戶端連接 SQL Server 2005，桌面用戶端是否有必要升級到 Windows XP SP2？
我目前使用 Windows XP SP1 和 Visual Basic® 6.0，以及一些採用 .NET 技術的應用程式。這種情況下是否需要 SQL Server Native Client、.NET Framework 2.0 和 Windows XP SP2？換言之，用戶端升級的整體最低需求為何？此外若我決定採用 SQL Server 2005 鏡像處理，用戶端需求是否有所不同？
如果想要充分發揮鏡像的功能，您必須使用 SQL Native Client (用於 OleDb 或 ODBC) 或是 ADO.NET 2.0 SqlClient。而且連接字串必須變更為同時參照主體和鏡像。
然而，只要有 SQL Native Client 或 .NET Framework 2.0，用戶端就能識別鏡像。當主體停機時，舊版用戶端雖能連接卻不會自動嘗試鏡像。
您不需要碰觸用戶端，即可在用戶端和伺服器之間附加 BIG-IP 切換，以便於容錯移轉期間手動搬移用戶端。或者，您可以修改應用程式的程式碼，而在發生主體伺服器連線故障時嘗試連接鏡像伺服器。
系統需求如下：Windows Installer 3.0、Microsoft Windows XP SP1 或更新版本、Microsoft Windows 2000 SP4 或更新版本，或是 Microsoft Windows Server 2003。有關各項需求的詳細資訊，請參閱 Using ADO with SQL Native Client (英文)、Updating an Application to SQL Native Client from MDAC (英文) 及 System Requirements for SQL Native Client (英文)。

SQL Server 2000 記憶體不足
問：當我用來實際營運的 SQL Server 2000 Enterprise Edition SP4 在 Windows Server 2003 SP1 上執行時，發生了異常的「記憶體不足」例外狀況。事件日誌中記錄著如 [圖 1] 的錯誤。
Figure 1 「記憶體不足」錯誤 (Close Figure 1)
2006-06-23 14:41:40.72 spid77    WARNING:  Failed to reserve contiguous memory of Size= 24641536.
2006-06-23 14:41:40.85 spid77    Buffer Distribution:  Stolen=4800 Free=1744 Procedures=39391
                                Inram=0 Dirty=90621 Kept=0
                                I/O=0, Latched=99, Other=3063345
2006-06-23 14:41:40.85 spid77    Buffer Counts:  Commited=3200000 Target=3200000 Hashed=3154065
                                InternalReservation=587 ExternalReservation=0 Min Free=1024 Visible= 173320
2006-06-23 14:41:40.85 spid77    Procedure Cache:  TotalProcs=9555 TotalPages=39391 InUsePages=1031
2006-06-23 14:41:40.85 spid77    Dynamic Memory Manager:  Stolen=44191 OS Reserved=7648
                                OS Committed=7619
                                OS In Use=7603
                                Query Plan=39088 Optimizer=0
                                General=4183
                                Utilities=140 Connection=7651
2006-06-23 14:41:40.85 spid77    Global Memory Objects:  Resource=1617 Locks=313
                                SQLCache=1836 Replication=204
                                LockBytes=2 ServerGlobal=42
                                Xact=63
2006-06-23 14:41:40.85 spid77    Query Memory Manager:  Grants=0 Waiting=0 Maximum=94533 Available=94533
2006-06-23 14:41:40.88 spid77    Error: 17803, Severity: 20, State: 12
2006-06-23 14:41:40.88 spid77    Insufficient memory available..
我的伺服器裝有很多 RAM (32GB)。奇怪的是，這個問題似乎不定時發生；導致此錯誤的預存程序大概每執行 20 次就會發生一兩次異常。
伺服器的效能計數器指出可用的記憶體還有很多。延遲寫入器對磁碟進行分頁的速度不夠快嗎？處理序為何會在執行預存程序時要求那麼多的記憶體？是 Select 陳述式的數目有問題，還是因為使用了暫存資料表？
這個問題與電腦的實體記憶體數量絲毫無關。依您的 boot.ini 設定情形，應用程式大概會配置到 2 至 3GB 的虛擬位址空間。虛擬位址空間是 32 位元系統的寶貴資源。根據預設，緩衝集區將消耗約 384MB 的虛擬位址空間。這 384MB 係配置供執行緒堆疊使用，及供給下列元件配置使用：太大以致緩衝集區無法處理，或不知如何透過緩衝集區進行配置的元件 (協力廠商延伸預存程序、連結的伺服器、COM 元件)。
警告訊息表示約有 23MB 配置失敗。這種數量上的配置成功與否取決於 384MB 區塊內其他配置的數量與位置。
您或可考慮移除一部分載入系統的協力廠商延伸預存程序，以判斷是否透過 sp_oacreate 或連結的伺服器使用了任何 COM 元件。
如果 SQL 預存程序 (sproc) 中使用了 FOR XML 子句，則一旦您加以執行，預存程序很有可能要求如此大量的記憶體 (此處並未刊載說明)。然而，如需詳細資訊，您可以從 Process\sqlservr\Virtual Bytes 查看還有多少虛擬位址空間可用。您也可以使用 VMStat 工具 (附在 Jeffrey Richter 所著 Programming Applications for Microsoft Windows 一書附贈的光碟中) 來判斷最大的虛擬位址區塊大小。延遲寫入器並不涉及此等配置作業；供配置使用的記憶體區域不是位於緩衝集區 (bpool)，對吧？

衷心感謝以下 Microsoft IT 專業人員不吝於分享技術專業知識：Ramon Arjona、Stephen Borg、Sandu Chirica、Robert Djabarov、Guillaume Fourrat、Osamu Hirayama、Alejandro Mihanovich、Maxwell Myrick、Uttam Parui、Shashi Ramaka、Gavin Sharpe、Vijay Sirohi、Jimmie Thompson、Madhusudhanan Vadlamaani、Jian Wang 與 Dave Wickert。


 嗨，Scripting Guy！: 改寫？沒問題！
嗨，Scripting Guy！
改寫？沒問題！
Microsoft Scripting Guys
本專欄是根據 Windows Vista 的搶鮮版 (Prerelease Version) 而寫成。本文所含的某些資訊有可能變更。
下載本文程式碼: ScriptingGuys2006_11.exe (151KB)

您大概 早已聽聞，在職場上突飛猛進的最佳方式，就是建立網路 (又稱人脈) – 您知道，就是與業界中的其他人士建立關係，如此才能向他們請益、與他們分享資訊，說不定某天還可以被他們網羅聘用。Scripting Guys 從來就沒有真正掌握這個職場人脈的精髓 (這點大概很明顯了)，但我們倒是知道一點有關電腦網路的知識。這是因為您可以透過指令碼來進行很多的「網路」作業。
Windows® Management Instrumentation (WMI) 提供幾種課程，您可以用來控制和監視您的網路環境。其中兩種課程，Win32_NetworkAdapter 和 Win32_NetworkAdapaterConfiguration，讓您使用電腦上的網路 (要不然咧？) 介面卡。
我們常聽到的一個問題是：「有什麼方法可以透過指令碼來啟用和停用網路介面卡？」嗯，我們不賣關子。現在就可以告訴您，沒有這種方法。至少在您執行 Windows Vista™ 之前是沒有。我們已在 Windows Vista 中的 Win32_NetworkAdapter 類別中新增了兩種方法：Enable 和 Disable。我們馬上就要來看看這些方法，但首先，在您太過沮喪之前，我們要告訴您如何藉由前 Windows Vista 作業系統來執行幾項作業。就當做前菜吧，您將找出電腦上實際可以使用的是什麼網路介面卡 (請參閱 [圖 1])。這內容還不賴，對吧？
Figure 1 尋找網路介面卡 (Close Figure 1)
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_NetworkAdapter")

For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo "Description: " & objItem.Description
    Wscript.Echo
Next
在 [圖 1] 中，我們一開始要連接至本機電腦上的 WMI 服務。當然，透過 GUI 來找出本機電腦上的網路介面卡並不難，但您要不要使用 GUI 來取得遠端電腦上的網路介面卡資訊看看？這就是這段指令碼和一般 WMI 指令碼的美妙之處：您可以對遠端電腦執行這段指令碼，只要將 strComputer 的值變更為遠端電腦的名稱即可。
在連接至 WMI 服務之後，接下來要查詢 Win32_NetworkAdapter 類別。這個查詢會傳回電腦上所有網路介面卡的集合。之後，我們只需要設定 For Each 迴圈，逐一執行介面卡的集合，然後回報每個介面卡的名稱和描述即可。您的輸出看起來像這樣：
Name: Broadcom NetXtreme 57xx Gigabit Controller
Description: Broadcom NetXtreme 57xx Gigabit Controller

Name: RAS Async Adapter
Description: RAS Async Adapter

Name: WAN Miniport (L2TP)
Description: WAN Miniport (L2TP)

Name: WAN Miniport (PPTP)
Description: WAN Miniport (PPTP)
單單藉由回報 Win32_NetworkAdapter 的不同屬性 (例如 DeviceID、Manufacturer 和 TimeOfLastReset 等)，就能擷取網路介面卡的許多相關資訊。如需詳細資訊，請參閱 Script Center 中的下列傑作 Automating TCP/IP Networking on Clients (英文)。

改寫以順應變化
如果是使用 Win32_NetworkAdapter 類別，則只能擷取網路介面卡的相關資訊。如果想要真的變更介面卡的任何設定，則需要使用 Win32_NetworkAdapterConfiguration 類別。這個類別不但能提供介面卡的其他相關資訊 (多虧有了 Win32_NetworkAdpater 所沒有的屬性)，還提供數個方法，可讓您依需求來設定網路介面卡。
例如，也許您無法啟用和停用介面卡，但是卻可以在每個具有 TCP/IP 功能的介面卡上，啟用和停用動態主機設定通訊協定 (DHCP)。[圖 2] 所顯示的指令碼會尋找所有具有 TCP/IP 功能的介面卡，然後檢查是否每個介面卡都啟用了 DHCP，並在未啟用時加以啟用。
Figure 2 啟用 DHCP (Close Figure 2)
strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_NetworkAdapterConfiguration Where IPEnabled = 'True'")

For Each objItem in colItems
    If objItem.DHCPEnabled = False Then
        Wscript.Echo objItem.Caption
        intReturn = objItem.EnableDHCP
        Select Case intReturn
            Case 0
                Wscript.Echo "DHCP enabled"
            Case 1
                Wscript.Echo "You must reboot before DHCP will be enabled"
            Case Else
                Wscript.Echo "Error occurred"
        End Select
        Wscript.Echo
    End If
Next
如同 [圖 1] 中的指令碼，[圖 2] 中的指令碼會連接至本機電腦上的 WMI 服務，然後再查詢 Win32_NetworkAdapterConfiguration 類別。請注意，由於我們只要尋找具有 TCP/IP 功能的介面卡，所以會在查詢中包含 Where 子句：
Where IPEnabled = 'True'
這個子句指定只要尋找 Win32_NetworkAdapterConfiguration 類別的執行個體 (其中 IPEnabled 屬性為 True，代表與該執行個體相關之介面卡具有 TCP/IP 功能)。
接下來要使用 For Each 迴圈，在查詢所傳回的介面卡集合中重覆。首先要在迴圈內部檢查每個介面卡的 DHCPEnabled 屬性。如果該屬性設定為 False，代表未啟用 DHCP，若是如此就要加以啟用。啟用方法是呼叫介面卡物件上的 EnableDHCP 方法。就是這麼簡單！
為了讓您能夠更清楚地觀察指令碼進行的作業，我們會回報 Caption 屬性，以瞭解使用的是哪些介面卡。我們也會包含 Select Case 陳述式，並為使用者建立每項可能結果的描述元。EnableDHCP 方法會在結束後傳回整數值。0 的值表示該方法已成功執行，而且 DHCP 已啟用。1 的值則表示該方法已成功執行，但需要重新啟動電腦，變更才會生效。任何其他的值均表示發生某項錯誤，DHCP 未能啟用。Select Case 陳述式會用來檢查這些整數值，並傳回適當的訊息。
您也可以停用 DHCP；這項作業可藉由設定靜態的 IP 位址並在介面卡上設定子網路遮罩來完成 (請參閱 [圖 3])。
Figure 3 設定 IP 位址 (Close Figure 3)
arrIPAddress = Array("192.168.0.12")
arrSubnetMask = Array("255.255.255.0")

strComputer = "."
Set objWMIService = GetObject _
    ("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_NetworkAdapterConfiguration Where IPEnabled = 'True'")

For Each objItem in colItems
    If objItem.DHCPEnabled = True Then
        Wscript.Echo objItem.Caption
        intReturn = objItem.EnableStatic(arrIPAddress, arrSubnetMask)
        Select Case intReturn
            Case 0
                Wscript.Echo "Static address assigned"
            Case 1
                Wscript.Echo "You must reboot before the static address will take effect"
            Case Else
                Wscript.Echo "Error occurred"
        End Select
        Wscript.Echo
    End If
Next
[圖 3] 中的指令碼幾乎與 [圖 2] 中的指令碼相同，只有幾處重要的差異。指令碼一開始先宣告兩個陣列 (arrIPAddress 和 arrSubnetMask)，並為每個陣列指派一個值。然後在 For Each 迴圈中檢查 DHCPEnabled 是否為 True (而不是 False)，True 的值表示已啟用 DHCP (也就表示我們要將其停用)。接著要呼叫介面卡物件上的 EnableStatic 方法。您將注意到，與 EnableDHCP 方法不同，EnableStatic 可以使用參數。這些參數是我們稍早所宣告的陣列，其中包含新的靜態 IP 位址和子網路遮罩。

Windows Vista 新增項目
如我們先前所做的承諾 (Scripting Guys 絕對不會食言... 至少很少啦)，現在我們要告訴您可以在 Windows Vista 中進行什麼作業。如前所述，在 Windows Vista 中，WMI 類別 Win32_NetworkAdapter 具有兩個新的方法：Enable 和 Disable，您可使用這兩個方法來啟用和停用網路介面卡。還有一個新屬性：NetEnabled；如果介面卡已啟用，此屬性會傳回 True，若沒有啟用則會傳回 False。[圖 4] 顯示的指令碼會尋找電腦上所有停用的網路介面卡，然後將其啟用。
Figure 4 啟用網路介面卡 (Close Figure 4)
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_NetworkAdapter Where NetEnabled = 'False'")

For Each objItem in colItems
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo "Description: " & objItem.Description
    objItem.Enable
    Wscript.Echo
Next
這幾乎與 [圖 1] 中所示的指令碼相同。(假設您還沒發現的話，我們可是指令碼回收運動的忠實提倡者)。現在要連接至本機電腦上的 WMI 服務，並查詢所有的 Win32_NetworkAdapter 執行個體。由於我們只要尋找停用的介面卡，所以會加入 Where 子句：
Where NetEnabled = 'False'
這個子句使用新增的 NetEnabled 屬性，指定查詢只會傳回 NetEnabled 設定為 False 的介面卡 (也就是網路介面卡停用)。接著再設定 For Each 迴圈，使其逐一查看查詢所傳回的網路介面卡物件集合。在回報介面卡的「名稱」和「描述」後，就呼叫 Enable 方法來啟用介面卡。
很簡單，對吧？但願我們也可以掌握另一種網路關係 (人脈) 的精髓。

Microsoft Scripting Guys Scripting Guys 的老闆是 Microsoft。在打棒球/教棒球/看棒球 (以及其他各種活動) 以外的時間，這些人負責 TechNet Script Center 的運作。請到 www.scriptingguys.com (英文) 一探究竟。


 Windows 的未來: Windows Server &quot;Longhorn&quot; 中的目錄服務
Windows 的未來
Windows Server "Longhorn" 中的目錄服務
Byron Hynes
本專欄是根據 Windows Server 的搶鮮版 (Prerelease Version，代號 "Longhorn") 而寫成。本文包含的所有資訊均有可能變更。

新版的 Windows Server (代號 "Longhorn") 將為您帶來數項 Active Directory 改良。有些變更非常顯著，向更佳的管理性和效率開啟了令人興奮的全新大道。Active Directory 中最顯著的一項變更就是功能和功用的命名。與識別管理相關的所有項目，現在都群聚於 Active Directory® 標誌下方。我們過去所熟悉的 Microsoft® Windows Server® 2003 中的 Active Directory，現在已成為 Active Directory 網域服務 (ADDS)，而且還有一些其他的服務，包括 Active Directory Federation Services (ADFS)、Active Directory 輕量型目錄服務 (ADLDS，前身為 Active Directory/Application Mode，或稱 ADAM)、Active Directory 憑證服務 (ADCS) 以及 Active Directory Rights Management Services (ADRMS)。
上述每種服務都代表一種伺服器角色，這是 Windows Server "Longhorn" 中的新概念。您可以選擇讓電腦專屬於一種或多種伺服器角色，並且使用伺服器管理員來管理伺服器角色，如 [圖 1] 所示。您可以使用這個工具來新增角色、尋找說明，並執行其他必要的管理工作。
圖 1 伺服器管理員
圖 1 伺服器管理員
如您所見，這個新方法會將日常的功用及功能組織為邏輯群組，並可以從伺服器管理員存取。

功能等級
Windows Server "Longhorn" 為樹系和網域引進了新的功能等級。Windows Server "Longhorn" 樹系功能等級 (將於發行時重新命名) 並未新增任何自身的功能，而是確保樹系中的所有網域都達到 Windows Server "Longhorn" 網域功能等級。該等級提供兩項新的增強功能：第一個功能是針對 SYSVOL 共用而使用最新的分散式檔案系統 (DFS) 複寫引擎，該引擎不但較為強大、可針對細部調整，還十分有效率。第二個功能是針對 Kerberos 驗證通訊協定而新增的 256 位元先進加密服務 (AES) 加密支援。使用最新的功能等級可以提供最佳效能，但您也可以在遷移至 Windows Server "Longhorn" 時，繼續以較低的功能等級操作。
數種支援不同功能的結構描述延伸也被引進，其中每一種都完全可與目前所使用的現有結構描述相容。執行 Windows Server "Longhorn" 的網域控制站可以和那些執行 Windows Server 2003 的控制站同時存在並互相操作，完全沒有問題。

伺服器核心的支援
Active Directory 網域服務是可在 Windows Server "Longhorn" 的「伺服器核心」安裝中運作的伺服器角色之一。伺服器核心是一個最小安裝選項，只會保留核心的伺服器功能，此主題的詳細討論並不屬於本文範圍。伺服器核心不會安裝 Windows 殼層，也不會使用圖形使用者介面，因此可以減少相當多的系統負荷。

唯讀網域控制站
對於某些環境而言，Windows Server "Longhorn" 中最顯著的 ADDS 功能就是唯讀網域控制站 (RODC)，這項功能可以用來輕鬆部署網域控制站，以主控網域資料庫的唯讀複本。這非常適合無法確保網域控制站實體安全性的位置，或是必須在網域控制站上執行其他應用程式並由伺服器管理員 (理想上並非 Domain Admins 群組的成員) 進行維護的位置。這兩種案例在分公司部署中都很常見。
只需在安裝精靈中啟用一個核取方塊，即可安裝唯讀網域控制站，如 [圖 2] 所示。
圖 2 安裝唯讀網域控制站
圖 2 安裝唯讀網域控制站
在 Windows Server "Longhorn" 發行以前，如果使用者必須使用不同位置的網域控制站進行驗證，則必須透過廣域網路 (WAN) 連結來傳輸流量。WAN 連結通常比較慢，成本也比區域網路 (LAN) 連線為高，有時也較易發生服務中斷的情況。一個可行的解決方案是在遠端站台或分公司部署 DC。不過，這樣會引進其他問題，包括複寫流量，以及需要透過分公司中的 DC 來維護實體安全性等 – 小型的遠端分公司站台經常缺乏這種設備。在其他情況下，分公司與集線器站台的網路連接頻寬通常都很低，使登入所需的時間增長。
除了帳戶密碼 (除非特別設定) 外，RODC 會保存可寫入網域控制站保存的所有 Active Directory 網域服務物件和屬性。不過，源自本機的變更並不能套用至儲存在 RODC 上的複本，反而會套用到可寫入網域控制站，然後再複寫回 RODC。這樣可防止在分公司位置所做的變更透過複寫而污染或損毀樹系，並藉此排除一個主要攻擊途徑。
要求對網域目錄資訊進行讀取存取的本機應用程式可以直接從 RODC 取得存取權，而要求寫入存取權的輕量型目錄存取協定 (LDAP) 應用程式則會接到 LDAP 的轉介回應。這個轉介回應會將其連接到可寫入網域控制站 (一般是位於集線器站台)。
由於無法直接對 RODC 寫入變更，所以無法自 RODC 產生變更。同樣地，身為複寫協力電腦的可寫入網域控制站也不必從 RODC 提取變更。如此可降低集線器中 bridgehead 伺服器的工作量以及監控複寫所需的時間與精力。RODC 單向複寫可套用至 ADDS 和分散式檔案系統 (DFS) 複寫。RODC 可針對 ADDS 和 DFS 複寫變更執行一般的輸入複寫。
在網域資料庫中，每個安全性主體都具有大約 10 個密碼或秘密，也稱為認證。RODC 並不會儲存使用者或電腦的認證，但本身的電腦帳戶和每個 RODC 的特殊 "krbtgt" 帳戶 (用於 Kerberos 驗證的帳戶) 不在此限。RODC 會以其站台 (通常為分公司) 的金鑰發行中心 (KDC) 形式顯示。當 RODC 簽署或加密票證授與票證 (TGT) 要求時，會使用與可寫入網域控制站上的 KDC 不同的 krbtgt 帳戶及密碼。
帳戶第一次嘗試向 RODC 進行驗證時，RODC 會將要求傳送至集線器站台的可寫入網域控制站。如果驗證成功，則 RODC 也會要求正確認證的複本。可寫入網域控制站會辨識出要求是來自 RODC，並且查詢有效的 RODC 密碼複寫原則。
密碼複寫原則會判斷認證是否可以複寫並儲存在 RODC 上。如果可以，則可寫入網域控制站會將認證傳送至 RODC，然後 RODC 會加以快取，如 [唯讀網域控制站的作業方式] 資訊看板所示。
在認證快取於 RODC 之後，下一次使用者嘗試登入時，就可以直接由 RODC 提供要求服務，直到認證變更為止。當 TGT 是使用 RODC 本身的 krbtgt 帳戶簽署時，RODC 會辨識出該帳戶具有快取的認證複本。如果已經有另一個 DC 簽署了 TGT，則 RODC 會將要求轉寄給可寫入網域控制站。
藉由限制只有經過 RODC 驗證的使用者才能使用認證快取功能，就比較不會因為 RODC 被侵入而暴露認證。
依預設，RODC 上不會快取任何使用者密碼，但這並不一定是最有效率的情況。一般而言，相較於網域中全部的使用者，只有幾個網域使用者需要將認證快取於指定的 RODC。您可以使用密碼複寫原則來指定可針對哪些群組的使用者進行快取。例如，藉由限制只有經常位於分公司的使用者才能使用 RODC 快取功能，或者避免快取重要的認證 (例如管理員)，將可降低暴露認證的可能性。
因此，在發生 RODC 遭竊或以其他方式遭到侵入的事件時，只有已經快取的認證需要重設，而且如前所述，您會確實知道這包括哪些帳戶 (如 [圖 3] 所示)。
圖 3 快取的帳戶資訊
圖 3 快取的帳戶資訊

管理員角色分隔
在許多分公司中，網域控制站都會有其他的伺服器角色或工作需要執行，例如充當檔案或列印伺服器等。在其他的狀況下，還會根據需要，在網域控制站上安裝公司所從事行業的應用程式。這就會造成問題：為了管理這些應用程式和伺服器，分公司的員工需要具有管理認證。而任何可以管理 Windows Server 2003 網域控制站的人員，都可以管理整個網域。
在 Windows Server "Longhorn" 中，可以只授與管理員管理特定 RODC 的權限，而不讓他具有管理其他網域控制站的存取權，也不必在非必要的情況下，將他設定為 Domain Admins 安全性群組的成員。

使用者介面和工具改良功能
為了支援 RODC 的功能並輕鬆地監控密碼複寫作業，現在 Active Directory 使用者和電腦中的網域控制站屬性頁面上新增了 [密碼複寫原則] 索引標籤，如 [圖 4] 所示。
圖 4 密碼複寫原則索引標籤
圖 4 密碼複寫原則索引標籤
在此索引標籤上按一下 [進階] 按鈕，就可以看到已傳送至 RODC 的密碼、儲存於該處的密碼，以及已根據該 RODC 進行驗證的帳戶，如 [圖 5]。由於此清單包含已經過驗證的帳戶 (即使它們不屬於可以複寫其密碼的群組)，所以您可以使用該項資訊來決定要包含在密碼複寫原則中的群組。
圖 5 進階密碼複寫原則
圖 5 進階密碼複寫原則
廣受推崇的 dcpromo 公用程式已進行了幾項變更，此程式之前稱為 Active Directory 網域服務安裝精靈。此精靈可以啟動為完整的圖形應用程式，方法是在安裝作業系統之後立即執行的「初始設定工作」(Initial Configuration Task，ICT) 頁面中，選擇 [新增角色] 命令。在伺服器管理員中選擇 [新增角色]，然後再選擇 ADDS，或從命令列或 [執行] 方塊呼叫 dcpromo。
只要您以圖形模式使用此精靈，就會注意到項目和選項的排列比較整齊，相關的項目會群聚在一起，選項也會比較多。您可以從 UI 存取進階模式，而不必使用 /adv 參數來執行工作，例如建立新的網域樹系、從媒體進行安裝 (以減少透過 WAN 進行的初始複寫作業)，或選取來源網域控制站以進行初始複寫等。
某些改進功能是為了讓您的工作更順利，並減少令人挫折的錯誤。例如，如果要使用精靈在現有的網域或樹系中建立新的網域控制站，可以瀏覽現有的網域，而不需輸入 NetBIOS 名稱。
已新增頁面來指定其他選項，並讓您將 DC 設定為全域類別目錄伺服器、DNS 伺服器和 RODC。您也可以在精靈中設定網站選取項目、設定功能等級、建立 RODC 的密碼複寫原則，並設定 DNS 委派。
dcpromo 是命令列工具，可以用完全自動的方式執行。與 Windows Server 2003 中同樣的工具不同的是，自動安裝並不需要回應任何使用者介面提示，例如需要重新啟動電腦等。這使得 ADD 更易於在 Windows Server "Longhorn" 的伺服器核心安裝上使用。

ADDS 稽核
Microsoft 在 Windows Server "Longhorn" 中，新增了許多目錄服務的稽核功能。您可以在 Windows Server 2003 中開啟或關閉目錄存取的稽核功能，但即使啟用了完整的成功稽核，稽核軌跡仍不會包含已變更的資訊。現在就可以了。
在 Windows Server "Longhorn" 中，ADDS 的稽核原則具有下列四個子類別：
  • 目錄服務存取
  • 目錄服務變更
  • 目錄服務複寫
  • 詳細的目錄服務複寫
對於大多數的 IP 專業人員來說，只需記住這些變更的兩個要點：首先，目錄服務存取稽核所提供的資訊，基本上與在 Windows Server 2003 中相同，但事件識別碼已從 566 變更為 4662。如果要使用工具來剖析安全性事件日誌，請注意這項變更。再來，新的 Directory Services Changes 類別會同時記錄變更屬性之前和目前的值。
若要在 ADDS 中實作稽核，請使用全域稽核原則、系統存取控制清單 (SACL) 和 ADDS 架構。這些元件組合在一起，就可以建立出既富彈性、又功能完備的稽核架構。
全域稽核原則可控制是否在 ADDS 上執行任何稽核。如果已啟用稽核，則全域原則可控制要針對四個存取子類別 (如前所述) 中的哪個類別進行稽核。全域稽核原則通常會套用在預設網域控制站群組原則物件中，所以會套用至網域控制站上的整個目錄。
雖然群組原則工具可以開啟或關閉全域稽核原則，但您必須使用 Auditpol.exe 命令列工具來檢視或設定子類別。這些類別不會顯示在圖形使用者介面中。
SACL 是物件安全性描述元的一部分。藉由指定 SACL 中的項目，可以告訴系統兩件事：您所在意的動作和使用者 (或安全性主體)。換句話說，事件日誌中應該記錄您指定哪些使用者來嘗試執行哪些動作。所以如果想要記錄 Domain Admins 對 User 物件所做的變更 (而不是使用者自己所做的變更)，可以使用 SACL 來加以控制。SACL 適用於物件 (可以針對新物件定義 SACL，也可以從容器物件繼承)。
您也可以將 ADDS 架構設定為只針對特定的屬性稽核變更。由於 SACL 依預設會套用至物件，所以如果存取或變更任何屬性，都會列入記錄。這可能會產生許多記錄活動，而且可能並不是所有的屬性都與您相關。所以，就屬性等級而言，您可以設定旗標以避免對該屬性的變更列入記錄。
SearchFlags 是在定義屬性的類別中所定義的屬性，所以是屬性 (Attribute) 的屬性 (Attribute)。它同時也是位元遮罩，其中每個單一位元組的位元值都代表不同的開啟/關閉設定。您可能會覺得把它想成屬性 (Attribute) 的屬性 (Property) 比較不會混淆。在 Windows Server 2003 中使用其中七個值來控制不同的設定，包括屬性的索引和 GC 複寫。在 Windows Server "Longhorn" 中，第八個位元 (值為 128) 是用來控制是否要記錄變更。如果設定此位元，則 ADDS 不會在對該屬性進行修改時記錄變更事件。這適用於所有包含該屬性的物件。在 Beta 2 中，無法使用圖形使用者介面來設定第八個位元。
依預設，在 Windows Server "Longhorn" 中，全域稽核原則會開啟，而目錄服務變更會設定為記錄成功的變更。

可重新啟動的 ADDS
在 Windows Server "Longhorn" 中，ADDS 是可重新啟動的服務。這只是代表 ADDS 服務可以停止後再啟動，而不需重新啟動網域控制站。這樣可以讓管理員更輕鬆地執行在服務執行時所不能進行的功能 (例如離線進行的資料庫磁碟重組)，而不必進入目錄服務還原模式。
執行 Windows Server "Longhorn" 的網域控制站有三種可能的狀態：ADDS 啟動、ADDS 停止和目錄服務還原模式。現在讓我們一一檢視這些狀態。
ADDS 啟動 網域控制站正常運作。
ADDS 停止 伺服器同時具有目錄服務還原模式的網域控制站以及網域連結成員伺服器的特性。
與目錄服務還原模式相同，ADD 資料庫 (Ntds.dit) 也是離線的。如果無法連絡另一個網域控制站進行登入，則可以使用目錄服務還原模式密碼從本機登入。
與成員伺服器相同，此伺服器會連結到網域。使用者可以藉由互動方式登入，或使用另一台提供網域登入功能的網域控制站，透過網路而登入。不過，網域控制站不應長期間維持此狀態，因為它將無法服務登入要求，或與其他的網域控制站進行複寫。
目錄服務還原模式 此模式 (或稱狀態) 與 Windows Server 2003 中相同。
[圖 6] 中的流程圖說明執行 Windows Server "Longhorn" 的網域控制站如何能在這三種可能狀態之間轉移。
圖 6 Windows Server 'Longhorn' 上的網域控制站可以在三種狀態之間轉移
圖 6 Windows Server 'Longhorn' 上的網域控制站可以在三種狀態之間轉移

需要更多資訊？
想要在一篇短短的文章內說明 Windows Server "Longhorn" 中新增 ADDS 功能的深度，是不可能的任務。但正如以上所見，一些之前您必須試著尋找替代方案或只能忍受的問題，都可藉由新增的 Active Directory 功能解決。隨著本產品最終版本的發行日期越來越近，而您也想要更深入瞭解，請不必擔心，我們會公開提供其他的文件。就目前而言，如果要在測試版階段尋找更新，最佳位置是在 Windows Server "Longhorn" 網站 (英文)。

Byron Hynes 服務於 Microsoft 的 Windows Server 使用者協助事業群。他曾擔任過顧問和訓練師，並具有多樣化的經驗，包括區域網際網路骨幹的運作、主從式和啟用 Web 之應用程式的疑難排解，以及資料庫結構描述、網路基礎結構和安全性模型的設計等。您可以透過下列方式與他聯絡：bhynes@microsoft.com。


 資訊安全新知: 我剛收到資訊安全佈告欄，接下來該怎麼辦？
資訊安全新知
我剛收到資訊安全佈告欄，接下來該怎麼辦？
Christopher Budd

Microsoft 應客戶要求，於 2003 年 10 月確立資訊安全佈告欄的每月發行程序。客戶的主要要求之一是希望能預知資訊安全佈告欄的發行排程。到目前為止，我們都能善用該定期性和可預知性來調整及改進我們的程序。
Microsoft 資訊安全佈告欄網站 (英文) 是您可以在其中尋找最新的資訊安全佈告欄和搜尋過期佈告欄之處，如 [圖 1] 所示。[圖 2] 則顯示範例佈告欄，此例為 2006 年 8 月份的佈告欄。
圖 1 Microsoft 資訊安全佈告欄網站
圖 1 Microsoft 資訊安全佈告欄網站
對大多數的客戶而言，Microsoft 的每月資訊安全佈告欄對於 Microsoft 安全性更新的部署，扮演著提升程序完整性的推手角色。由於資訊安全佈告欄會在可預期的日期發行，因此客戶也可以利用此機會來自行建立處理這些佈告欄的定期程序。這些客戶已在其本身的安全性更新評估及部署程序中建立了時間表和步驟，根據 Microsoft 的每月資訊安全佈告欄發行來整合可預期的時間表。客戶使用該項程序以系統性的方式來分析、測試和部署更新，不但有助於提升其整體安全性狀況，也可減少當機時間和作業中斷的情況。
圖 2 2006 年 8 月資訊安全佈告欄
圖 2 2006 年 8 月資訊安全佈告欄
不過，有些客戶會在沒有既定程序的情況下進行安全性更新評估和部署。雖然可以透過未系統化的方式部署更新而不發生任何問題，但基本上這與我們認定的安全性更新管理最佳作法是衝突的。
我們已針對佈告欄發行的方式和時間提供了有用的相關資訊，但尚未針對佈告欄可以使用的對象以及如何在您自身的程序中整合這些佈告欄提供足夠的指引。有些客戶可能並不清楚對其有益的程序，或者建立這些程序的最佳方式。
因此，在本專欄中將列出在評估和部署安全性更新時，我們所推薦的步驟和程序。任何規模的組織都可以遵循這些步驟。如果是規模較大的組織，可能需要根據內部結構，在不同的群組之間切割這些步驟。如果是規模較小的組織，則可以由單一群組或甚至單一人員來執行所有步驟。不論職責的分配如何，在評估和部署的程序中都必須明確地說明所有這些步驟。[圖 3] 提供程序的概觀。
圖 3 資訊安全佈告欄的評估和部署程序
圖 3 資訊安全佈告欄的評估和部署程序

1. 接收進階通知
每月資訊安全佈告欄程序的第一個步驟，應該是確保您收到最新安全性更新的進階通知。Microsoft 會在標準的每月發行日 (每月的第二個星期二) 的前三個工作天，於太平洋時間 (GST -8) 上午 10 點左右在網站上公佈資訊；因此，進階通知資訊會在前一個星期四公佈。
進階通知的目的是在實際發行之前，提供有助於部署規劃的資訊。其中所含資訊的詳細程度，是在發行安全性更新之前，根據保護客戶的需求，藉由不揭露任何可能構成攻擊之資訊加以平衡所得。進階通知會整合即將發行之更新的相關資訊，並依產品名稱提供，但不揭露任何特定版本的資訊 (例如，Microsoft® Windows® 或 Microsoft Office)。其中每個項目都會詳細列出將針對該產品所發行的佈告欄數、這些佈告欄的最高嚴重性、是否有任何更新需要進行重新啟動，以及適用於這些佈告欄的偵測工具等。
為了確保不發生任何意外並盡可能降低混淆情況，進階通知也會針對將於同日發行，但與資訊安全佈告欄不相關的其他更新提供相關資訊。尤其，它還會詳列會透過 Microsoft Update (MU) 和 Windows Update (WU) 發行多少高優先順序的非安全性更新，以及 Microsoft Windows 惡意軟體移除工具是否有任何更新。
最後，我們會針對可能導致部署延誤的問題提供相關資訊，如同我們在 MS06-019 中，針對 "Send as" 權限變更所提供的資訊。
新的進階通知會於每月發佈 (英文)，此時會透過「安全性通報服務：完整版」(Security Notification Service Comprehensive Edition，SNSCE) 傳送通知。您可以在此註冊 SNSCE (英文)。

2. 評估潛在影響
一旦接到進階通知，第一個步驟應該是評估即將發行的佈告欄與您環境的相關性。即使進階通知只會針對受影響的產品提供有限的資料，仍具有足夠的資訊，可以用來評估即將發行的佈告欄是否與您的環境相關。
例如，假設進階通知指出有兩個具有最高嚴重性等級而且需要重新啟動的 Microsoft Exchange 佈告欄。如果沒有執行該程式，您就會立刻知道這些佈告欄並不適用於您的環境。相反地，如果有執行 Exchange Server 2003，則您會知道在星期二最多可能會收到兩個具有嚴重等級且需要重新啟動的佈告欄。.
在進行規劃用途時，請將進階通知視為一項工具，可協助您就佈告欄數目、嚴重性以及與重新啟動相關的部署影響，來判斷組織所受到的最大可能影響。一旦評估了更新的相關性和最大可能影響，就可以建立排程，其中應該包含下列動作項目：
  • 進行風險評估、測試和部署的人員
  • 測試計畫和測試實驗時間
  • 部署計畫和排定的重新啟動作業 (視需求)
此時所有的排程都應該是暫時性的，因為進階通知中的資訊有可能隨時變更。此外，由於進階通知的資訊有限，所以您可能會在擁有完整詳細資料時變更計畫。
最後，如果有任何其他資訊 (例如功能變更)，則應該使用進階通知和實際的資訊安全佈告欄發佈之間的時間來研究問題，並評估該問題對環境的可能影響。您可能需要根據研究而修改您暫時性的排程。

3. 接收 Microsoft 資訊安全佈告欄
Microsoft 會在每個月第二個星期二發佈其資訊安全佈告欄。太平洋時間上午 10 點是預定的發佈時間，但由於這項發佈與一個龐大而複雜的程序相連，所以可能會因多種原因而延遲。在此項發佈中，資訊安全佈告欄、安全性更新、偵測和部署工具 (例如，Microsoft Baseline Security Analyzer (MBSA) 和 Windows Server® Update Services (WSUS)) 的更新，以及新增的偵測工具 (例如新版的 Enterprise Scan Tool (EST)) 全都會發佈到 Microsoft 網站。
Microsoft 資訊安全佈告欄網頁會啟用對 RSS 摘要的支援。當資訊安全佈告欄包含更新時，我們的 RSS 摘要也會更新，而這會接著更新 RSS 彙總程式和檢視器。此外，也會使用安全性通報服務 (Security Notification Service，SNS) 和 SNSCE 傳送通知。通報會同時透過電子郵件和 MSN® Alert 傳送。
若要獲知新資訊安全佈告欄的可用性資訊，應該在所有可用的通知機制中註冊。您可以訂閱 RSS 摘要 (英文) 以及 SNS 和 SNSCE (英文) 兩項服務。

4. 評估資訊安全佈告欄的相關性
您要清楚指派檢視新資訊安全佈告欄的職責並評估這些佈告欄與您環境的相關性，這是很重要的。在進行此項評估作業時，可以從資訊安全佈告欄中擷取完整的特定資訊，並依需要來修改及調整您的暫時排程。回到前面的範例，如果您通知 Exchange 管理團隊可能會有重要的安瞿性更新，但接著又發現 Exchange Server 並不受影響，就可以針對這些資源的排程進行調整。
一旦評估過資訊安全佈告欄與組織的相關性之後，就可以在程序中使用那些相關的佈告欄繼續作業。

5. 執行風險評估並為佈告欄評訂等級
現在您需要執行相關的風險評估。在有劃分職責的組織中，這個步驟常會由安全性群組來執行。雖然每個 Microsoft 資訊安全佈告欄都包含最高嚴重性等級，但該等級只反映出所有受影響產品中全部弱點的最高嚴重性。套用於貴組織的 Microsoft 嚴重性等級，可能與列出的最高安全性等級不同，這是根據您環境中版本的問題嚴重性而定。請在資訊安全佈告欄的＜提要＞下方，查看完整的「嚴重性等級和弱點識別碼」表格，並針對您的特定版本取得特定的弱點資訊，這點很重要。
在那之後，您應該檢視其他的技術資訊，例如「緩和因素」和 FAQ 中每個弱點的技術詳細資料，並根據您的環境和原則來調整風險評估。您的原則也可能要求評估中要說明非技術的環境因素，例如威脅環境或者特定應用程式對貴組織的關鍵性為何。
在本程序結束後，您應該會有每個佈告欄的風險等級以及與其相關的更新。現在繼續我們的範例，Exchange 管理群組可能會根據資訊安全佈告欄中詳細說明的變更，將安全性更新評比為「中等風險」。您應該根據原則，依需要來更新和變更排程。例如，您的原則可能會要求中等風險更新需要比低風險更新多一到兩天的測試。
在某些情況下，您的原則可能還會要求，需要針對特定風險等級的佈告欄考量實作的因應措施。例如，貴組織的原則可能會指出，應該針對評比為重要的所有安全性更新儘快地檢視和部署因應措施。在這種情況下，您要對因應措施執行額外的風險評估，以判斷要實作什麼以及何時要進行實作。
在本程序結束後，您應該會有要在環境中部署的更新清單，其中每項更新都具有相關的風險等級。此外，您還應該有要進行實作的因應措施清單，這項清單會用來更新您的測試和部署排程。對排程所做的變更應該反映原則所指定的時間軸。例如，您的原則可能會指出，對於所有重要的安全性更新，都必須在 24 小時內部署因應措施，並在 7 日 (非工作日) 內部署更新。

6. 判斷安全性更新和/或因應措施對組織的可能影響
瞭解安全性更新或因應措施對環境的影響，是評估程序中的一個重要步驟。在有劃分職責的組織中，這個步驟常是由管理直接受到安全性更新或因應措施影響之系統的群組來執行。
瞭解可能的影響，有助於瞭解和判斷安全性更新或因應措施本身所造成的風險。您可以在資訊安全佈告欄的＜與本安全性更新相關的常見問題集 (FAQ)＞一節中找到相關資訊。關於安全性更新如何解決弱點的方法，則位於＜弱點詳細資料＞下的弱點常見問題集內。
本步驟的目標是判斷更新和因應措施的風險等級。現在繼續前述的範例，Exchange 管理群組可能會根據資訊安全佈告欄中詳細說明的變更，將安全性更新評比為「中等風險」。您應該根據原則，依需要來修訂排程。例如，您的原則可能會要求「中等風險」更新需要比「低風險」更新多一天的測試。
您可能也需要根據風險等級對排程的影響，重新檢討部署因應措施的相關決策。例如，您可能會發現需要多兩天的測試時間，而這會使系統未受保護的時間超出原則所允許的期限。在這種情況下，可能要重新檢討因應措施的部署，以求符合原則。
最後，在進一步開始發展更新的測試計畫時，您要使用此步驟所產生的資訊。

7. 定義測試計畫
測試若要有效，則必須系統化，而且必須使用有意義的計畫建立。您的測試應該針對最可能在環境中造成問題的區域進行。由於每個環境都不同，所以我們不能提供有效測試計畫的標準範本。
在有劃分職責的組織中，測試計畫常會由一個以上的群組來設計。負責管理直接受到安全性更新或因應措施影響之技術或系統的群組，可以提供其特定專業。測試群組可以提供建立測試案例的專業、測試工具的選項，以及對實際時間軸的瞭解。
在此階段，您應該注意測試計畫對於安全性更新或因應措施的風險等級會有什麼影響，並依此對測試和部署排程進行變更。例如，如果您判斷開發出的測試計畫，並不能完全照您的規劃測試更新，則可以增加其風險等級、選擇延後部署，並在此期間實作解決方法。

8. 開發部署計畫
部署是實際實作安全性更新或解決方法所提供之防護的程序。因為部署是本程序實際的終極目標，所以瞭解可用的部署方法，並將其當作考量因素而列入評估，與安全性風險評估一樣重要。在有劃分職責的組織中，判斷安全性更新的可能部署方法，常是由負責管理軟體更新基礎結構的群組 (例如維護 Systems Management Server (SMS) 的群組) 來執行。監督組態管理技術 (例如 Active Directory) 的群組可能需要判斷因應措施的可能部署方法。
在此步驟中，您的目標是瞭解可能的部署方法，並從其建立用來部署安全性更新或因應措施的計畫。在此步驟中，您必須瞭解部署的可能方法將如何影響您的排程以及進行任何必要的變更。例如，如果某安全性變更不受 WSUS 的支援，而這是主要的部署方法，則您可能會決定部署更新所需的時間會比原先計畫的多兩天，而且決定實作在此部署期間提供必要防護的因應措施。
您可以在資訊安全佈告欄的＜與本安全性更新相關的常見問題集 (FAQ)＞一節中，找到部署方法的相關資訊。實作因應措施的相關方式會列於每個解決方法中；每個弱點都有相關的個別因應措施。
這包含規劃階段。在此階段，您擁有的排程，應該要反映出有關安全性風險、安全性更新風險等級以及因應措施、測試和部署之評估及規劃的所有項目。如您在這些階段中所見，這些階段彼此之間的關聯複雜，而且不一定呈線性關係。在某些組織中這些階段會同時發生，在其他組織中則是循序發生。您應該根據組織的原則、需求和資源，決定這些步驟的實作。這些步驟最重要的並不是特定的結構和順序，而是要確保這些不同的階段可以彼此通知和回應。任何實作的關鍵都在於保持彈性和變通。

9. 測試更新和因應措施
在測試階段中，要透過稍早在測試環境中定義的測試計畫來施行安全性更新和因應措施。測試環境的目標是在生產環境中複寫重要項目。在測試安全性更新或因應措施時，要努力找出在部署到生產環境之前所可能發行的任何問題。
在測試中辨識出問題時，應該判斷問題的嚴重性，以及解決問題的步驟。您可能會發現，有些小問題的影響等級尚可接受，而其他的問題則需要在部署更新之前加以解決。如果選擇接受問題，則請加以記錄，以供支援人員參考。
若要解決問題，可以向 Microsoft 產品支援服務 (PSS) 提報，此單位提供安全性更新相關問題的免費支援。您可以在下列網站找到 PSS 的連絡方式：support.microsoft.com/security。由於解決問題可能會增加測試的時間，並因此延誤部署，所以在選擇解決問題的方式之前，應該考慮對排程的可能影響。
當測試完成且所有問題都已解決或記錄時，接著可以證明要在生產環境中部署之安全性更新或因應措施。

10. 部署更新和因應措施
在安全性更新或因應措施都經過測試的証明後，就可以繼續部署程序。在部署期間要將安全性更新或組態變更實際套用至系統時，請使用計畫來指引您。參與計畫開發的群組通常也負責實際的部署。
如果在部署時遭遇問題，例如，安全性更新無法透過更新管理基礎結構而正確安裝，則您需要仔細檢查該問題。如果問題造成延誤，則可能需要重新檢查選項和/或考量因應措施以保護您的系統。
在理想狀況下，測試程序會在部署之前識別出所有在生產中可能發生的問題。不過，如果在部署到生產環境之後真的遇到問題，則應該遵照在測試中遭遇問題時會遵循的相同步驟處理。請評估問題並決定要接受還是解決該問題。
如果安全性更新成功地套用，則保護機制已經就位，而這些程序的終極目標也已達成；不過，如果沒有成功套用，則您的系統仍可能受到攻擊。
由於某些系統可能尚未成功更新，所以佈署程序的最後步驟十分重要 - 也就是對系統進行稽核，以確認部署成功。在某些組織中，稽核會由個別的稽核群組執行，此群組常與安全性小組相關連。WSUS、MBSA 和 SMS 之類的 Microsoft 工具可以用來稽核安全性更新是否成功套用。此外，在資訊安全佈告欄的＜安全性更新資訊＞章節中，也會提供如何確認安全性更新是否成功套用的相關資訊。

結論
藉由 Microsoft 每月發行的資訊安全佈告欄，您可以針對安全性更新的管理實作更為定期的規劃和程序。建立定期的程序和過程，有助於提供更佳的系統防護，同時也可以將干擾和可能的停機時間減至最少。
雖然每個組織都應該建立本身獨特的程序來管理安全性更新，貴組織的程序應該包含本專欄中所建議的步驟。您不需要擁有個別的安全性和更新小組，但應該要執行安全性風險評估並開發部署計畫。
此篇文章的重要概念在於規劃的重要性。有了良好的規劃，涉及實際活動的步驟 (例如測試和部署階段) 在進行時就會順利許多，而這也使安全性更新的程序順利成功。

Christopher Budd 是 Microsoft 安全性回應中心 (Microsoft Security Response Center，MSRC) 的資訊安全方案經理，擅長與 IT 和安全性專業人員以及其他的軟體使用者進行技術方面的溝通。


 Microsoft.com 幕後: ASP.NET 的管理與委派
Microsoft.com 幕後
ASP.NET 的管理與委派
Jeff Toews

microsoft.com 的 Web 基礎結構幾乎完全是以 .NET Framework 2.0 執行。microsoft.com 營運小組重要的 Web 管理挑戰之一，就是正確設定 ASP.NET，而我們也已在嘗試將我們的設定調整至盡善盡美的過程中，獲得許多經驗。設定
正確的組態時，需要對於 web.config 和 machine.config 檔案中的各種組態區段具有充分的操作知識，並且瞭解這些設定所代表的意義。若想很快地掌控設定及其含義，參考範例是一個好方法。在本專欄中，我將說明在設定執行 microsoft.com 網站的伺服器時所得到的一些組態密訣，這樣一來，您可以從我們的經驗中學習，過程會輕鬆不少。

1. 正確地設定編譯參數
在生產環境中部署 ASP.NET 應用程式時，一定要確定不會有人在任何應用程式的 web.config 檔案中，不小心 (或故意) 地將編譯偵錯屬性的設定保留為 True，如以下所示：
<compilation debug="true" />
在需要管理許多 Web 應用程式的忙碌環境中，您會想要使用 ASP.NET 組態控制機制來防止這種狀況發生。(稍後我會針對此點提供更多詳細資料)。
另外，請務必不要在個別的 .aspx 中將頁面特定的偵錯屬性設定為 True (如下所示)，這點也很重要：
<%@ Page debug="true" %>
但是，在發行量很高的忙碌環境中，期待所有的 .aspx 頁面在發行之前都一定要移除這項設定，往往是不切實際的。您需要整體的方法來防止這種情況發生。
使用這項設定來編譯 Web 應用程式，會導致二進位檔處於偵錯狀態，而非零售狀態。另外，您的程式碼也不會最佳化，因而效能低落。此外，您的 ASP.NET 要求也不會逾時，因為偵錯設定會防止逾時。在生產環境中使用偵錯版本，就像是敞開大門邀請駭客上門一樣！
幸運的是，Microsoft® .NET Framework 2.0 具有新的 machine.config 部署設定，會告訴 ASP.NET 停用下列項目：偵錯功能、追蹤輸出和 ASP.NET 錯誤訊息的顯示 (本機和遠端)，不論 web.config 檔案中的指示或特定的頁面屬性為何。程式碼看起來像這樣：
<configuration>
    <system.web>
          <deployment retail="true"/>
    </system.web>
</configuration>
請注意，後面兩個優點 (停用追蹤輸出和停用遠端顯示詳細的 ASP.NET 錯誤訊息) 是您真的應該採用的安全性最佳作法。如果不這麼做，就好像將應用程式的內部工作暴露於全世界之前，任人宰割一樣。
趁我在談這個主題時，再告訴您另一個重要的事實：在 <location allowOverride="false"> 內部的根 web.config 檔案中鎖定 <system.web><compilation> 偵錯屬性，或使用 lockItems 屬性，可避免應用程式組態階層中位於較低階層的 web.config 檔案開啟偵錯設定，但這並不能避免個別的 .aspx 頁面在其頁面屬性中啟用偵錯模式。部署零售參數是唯一可以完全停用所有階層之 ASP.NET 偵錯功能的方式。
將部署零售參數設定為 True，可能是任何具有正式生產伺服器的公司，在確保應用程式永遠能在可能情況下以最佳效能執行，並且沒有任何安全性資訊漏洞時，所應遵循的最佳作法。如我先前談到的，這是 ASP.NET 2.0 中的全新參數，也是 ASP.NET 團隊從使用者的意見直接反映出來的結果。
相反地，如果是開發人員需要對其 Web 應用程式進行偵錯的對內預先生產環境，則不要使用部署零售設定。只需在預先生產的根 web.config 檔案中設定 <compilation debug="false">，並讓這個值由個別應用程式的 web.config 檔案或 .aspx page 屬性覆寫即可。

2. 在 ASP.NET 2.0 中使用中信任等級
如果，如同 microsoft.com 上的許多網站一樣，您在將網站或應用程式移轉為 ASP.NET 2.0 之後，仍持續使用「完全」或「高」信任等級，請再次考量現在的「中」信任等級所能達到的效果。例如，受限的 WebPermission 會將應用程式的通訊僅限於您在 <trust> 元素中所定義的位址或位址範圍。如此就可以控制及維護認可的外部網站清單以及可以從遠端呼叫的位址範圍。這對安全性來說可是一大建樹。
FileIOPermission 也受到限制。這代表應用程式的程式碼只能存取其虛擬目錄階層中的檔案。依預設，在「中」信任等級下，只會針對每個應用程式的虛擬目錄階層授與「讀取」、「寫入」、「附加」和「路徑探索」等權限。這麼一來就不會再進行隨機的檔案 I/O 存取 – 在裝載許多應用程式的共用 Web 環境中，這是相當重要的。
另一個優點是會移除未受管理的程式碼權限。這表示您可以避免使用舊版的元件，到目前為止，這是我們所找到的停用 Aspcompat 頁面屬性最簡易的方式。(將 Aspcompat 設定為 True 可能導致頁面效能降低)。
ASP.NET 2.0 的「中」信任等級可以為管理員提供針對前述的每個預設限制建立自訂例外狀況的能力，就這點而言，該項設定就相當有彈性。在 ASP.NET 1.1 中就缺乏這種彈性。在 ASP.NET 2.0 中以「中」信任等級執行比在 ASP.NET 1.1 中簡單的另一個原因是，您可以存取 Microsoft SQL Server™ 資料庫。
因此，如果要在同一台伺服器上裝載多個應用程式，可以使用程式碼存取安全性以及「中」信任等級來提供應用程式隔離。藉由在根 web.config 檔案中設定並鎖定信任等級 (使用 <location allowOverride="false"> 標記)，您可以針對伺服器上的所有 Web 應用程式建立安全性原則。藉由設定 allowOverride="false" (如 [圖 1] 所示)，個別的開發人員將無法在其應用程式的 web.config 檔案中覆寫「中」信任原則設定。
Figure 1 信任設定 (Close Figure 1)
<configuration>
    <location allowOverride="false">
        <system.web>
            <securityPolicy>
                <trustLevel name="Full" policyFile="internal" />
                <trustLevel name="High" policyFile="web_hightrust.config" />
                <trustLevel name="Medium" policyFile="web_mediumtrust.config" />
                <trustLevel name="Low"  policyFile="web_lowtrust.config" />
                <trustLevel name="Minimal" policyFile="web_minimaltrust.config" />
            </securityPolicy>
            <trust level="Medium" originUrl="" />
        </system.web>
    </location>
</configuration>
您可於下列文章中找到有關在 ASP.NET 2.0 中使用「中」信任等級的詳細資訊：＜How To:Use Medium Trust in ASP.NET 2.0＞(英文)。

3. 限制指定檔案類型的下載
在伺服器上有些檔案類型是您絕對不想要落入壞人手中的。幸運的是，ASP.NET 依預設會設定為截取和停止用於 ASP.NET 應用程式中的數種不同檔案類型的要求。這些檔案包括 .config 檔案和儲存應用程式原始碼的 .cs 檔案。ASP.NET 可將兩種檔案類型與 System.Web.HttpForbiddenHandler 建立關聯，以確保檔案的隱私。這個處理常式在啟動後，會對要求檔案的使用者傳回錯誤。事實上，您可以使用這個方法來限制任何檔案類型。
例如，在 microsoft.com 網站上就不允許 .asmx 檔案類型，方法是將下列項目加入至根 web.config 檔案的 <system.web><httpHandlers> 區段。
<add path="*.asmx" verb="*" type=
    "System.Web.HttpForbiddenHandler" />
如您所見，您可以在 <httpHandlers> 元素中使用 <add> 子標記來指定要封鎖的其他檔案類型。請將動詞屬性設定為等於 "*"。當您這麼做時，就等於是針對該檔案類型封鎖所有的 HTTP 要求類型。將路徑屬性定義為萬用字元，以符合要封鎖的檔案類型。例如，您可以指定 "*.mdb"。最後，將類型屬性設定為 "System.Web.HttpForbiddenHandler"。

4. 在新增組件參照時請小心
每個執行 .NET Framework 的 Web 伺服器都有適用於整個電腦的程式碼快取，稱為 Global Assembly Cache (GAC)。GAC 會儲存特別指定為由電腦上多個應用程式共用的組件。如果有多個不同的應用程式需要參照這些組件 (即使 Web 伺服器上大多數的網站並不會存取這些組件)，則將它們加入 GAC 是合理的。這並不會導致效能/資源明顯降低，還可提供維護集中式版本控制的優點，而不是讓共用的組件四散於伺服器中個別應用程式的 /bin 資料夾內。
不過，何時應該將組件參照加入至 root web.config 的條件，則需要比決定何時將組件置於 GAC 中的條件嚴格許多。讓個別的應用程式針對並非完全全域的元件，在其應用程式的 web.config 檔案中加入組件參照，比在根 web.config 檔案中宣告這些組件參照，在效能上會高出許多。這樣可以為 Web 伺服器上所有不使用這些組件的應用程式大幅節省頁面載入的時間，因為編譯器不需要花時間載入不必要的組件。ASP.NET 編譯器不會只因為組件位於 GAC 中，就為應用程式載入該組件；只有在其 appdomain 或較高的應用程式領域中有組件的參照存在時，此編譯器才會載入該組件。結果是，應用程式開發人員可以在 microsoft.com 中，在其應用程式的 web.config 檔案中覆寫所有 Microsoft.com 環境的 <configuration><system.web><compilation><assemblies> 元素。
特別是，在 microsoft.com 生產和執行環境的根 web.config 檔案中，<system.web><compilation> 節點的所有屬性 (包括 debug、explicit、defaultLanguage) 及所有元素 (buildProviders、expressionBuilders 等等；<assemblies> 元素除外) 都會鎖定：
<compilation debug="false"
    explicit="true" defaultLanguage="vb"
    numRecompilesBeforeAppRestart="500"
    lockAttributes="*" lockAllElementsExcept=
        "assemblies" >
在對內的預先生產環境中，根 web.config 檔案的 <system.web><compilation> 區段會鎖定，但我們允許應用程式發行者特別覆寫 <assemblies> 元素和 debug="false" (以啟用疑難排解/偵錯)：
<compilation debug="false" explicit="true"
    defaultLanguage="vb"
    numRecompilesBeforeAppRestart="500"
    lockAllAttributesExcept="debug"
    lockAllElementsExcept="assemblies" >
請注意，此處使用的鎖定屬性是 ASP.NET 2.0 的新增功能。同樣地，如需這些屬性的詳細資訊及其使用範例，請參閱 General Attributes Inherited by Section Elements (英文)。

5. 移除手動設定的 MaxConnection 值
幾乎所有的 microsoft.com 網站都具有 ASP.NET 應用程式，可以呼叫遠端的 Web 服務叢集。可從單一的 Web 伺服器同時進行的遠端 Web 服務呼叫最大數目，是由 machine.config 檔案中 <connectionManagement> 元素的 maxConnection 屬性決定。在 ASP.NET 1.1 中，maxConnection 值預設是設定為 2。這個舊的預設 maxConnection 值對於 microsoft.com 這種擁有數百個不同應用程式會進行遠端 Web 服務呼叫的類似網站而言，實在過低。其結果是，在等候遠端 Web 服務呼叫完成時，ASP.NET 要求會排入佇列。(您可透過 perfmon counter ASP.NET\Requests Queued 來檢視佇列的 ASP.NET 要求數目)。為了讓更多的遠端 Web 服務呼叫可以同時執行 (並藉此改善網站上應用程式的效能)，我們將使用四個處理器的 Web 伺服器的 maxConnection 值增加到 40 (一般建議的 maxConnection 值為 CPU 數目的 12 倍，但是請依照您的特定狀況來調整此值)。
不過，在 ASP.NET 2.0 中已經不再需要手動設定 maxConnection 了，因為此值現在會自動調整及設定。這是 machine.config 中 processModel 標記的新組態區段所造成的結果 (如需 processModel 元素的詳細資訊，請參閱 processModel Element (ASP.NET Settings Schema) (英文))。
<system.web>
    <processModel autoConfig="true" />
</system.web>
在 machine.config 中啟用 autoConfig 時 (此為預設設定)，ASP.NET 會將 maxConnection 參數的值設定為 12n (其中 n 為 CPU 的數目)。啟用 autoConfig 也會導致下列狀況：maxWorkerThreads 參數和 maxIoThreads 參數會設定為 100，minFreeThreads 參數設定為 88n，minLocalRequestFreeThreads 參數設定為 76n，而 minWorkerThreads 則設定為 50。
在 ASP.NET 2.0 中使用 autoConfig 以自動調整並設定 maxConnection 和清單中其他屬性值之前，請務必移除這些參數的手動設定值，因為這些值可能會取代 autoConfig 值而被使用。從 ASP.NET 1.1 (需要明確地設定 maxConnection) 遷移至 ASP.NET 2.0 (具有預設值) 時，需要記住這點。
同樣地，maxConnection 的 autoConfig 值和先前所列出的其他屬性，在某種程度上都是隨意自定的，而且可能無法用於每個執行個體，但我發現這些限制幾乎對所有的 microsoft.com 應用程式都非常適用。
如果決定需要手動調整 maxConnection 值，在增加其值時請小心，因為這可能會導致 CPU 使用量增加。使用量增加的原因是由於 ASP.NET 現在可以處理較多的連入要求，而不必讓它們依序等候呼叫 Web 服務。當然，您應該記住，maxConnection 屬性並不會影響本機的 Web 服務呼叫，而只會對遠端呼叫造成影響。

6. 注意未處理的例外狀況
將 ASP.NET 1.1 網站或應用程式轉換為 ASP.NET 2.0 版本時，注意在未處理例外狀況的預設原則中發生了什麼重大變更將極為有用。在 .NET Framework 1.1 和 1.0 中，在 Managed 執行緒上未處理的例外狀況會遭到忽略，而且因為應用程式會持續執行，所以這些例外狀況常會保持隱匿。除非附加捕捉例外狀況的偵錯程式，否則您不會知道發生了任何問題。不過在 ASP.NET 2.0 下，在擲出未處理的例外狀況時，ASP.NET 應用程式會意外結束。如果舊的預設例外狀況處理原則先前遮掩了許多未處理的例外狀況，這就可能對網站或應用程式的可用性造成嚴重的衝擊。
解決這個問題的最佳方式，就是進行徹底的測試，並排除未處理的例外狀況 (其實應用程式中真的不該出現例外狀況)。不過，如果要遷移非常大型的應用程式 (很難判斷出現例外狀況的位置)，或者如果需要遷移許多舊版應用程式 (很難進行徹底的個別測試)，則您有幾個選擇。將 microsoft.com 網站轉換為 ASP.NET 2.0 版本時，我們將未處理的例外狀況原則變更回 ASPNET 1.1 和 ASP.NET 1.0 中的預設行為。
若要啟用這個舊版的預設例外狀況處理行為，請將下列程式碼加入至 aspnet.config 檔案：
<configuration>
    <runtime>
        <legacyUnhandledExceptionPolicy
            enabled="true" />
    </runtime>
</configuration>
此程式碼位於下列兩個資料夾中：
%WINDIR%\Microsoft.NET\Framework\v2.0.50727 (位於 x86 或 SYSWOW64 系統) 和 %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 (位於 x64 系統)。
這項變更基本上會將 .NET Framework 還原為 1.1 和 1.0 的舊版行為。請將這種方法視為短期的修正方式，因為最終真正會造成困擾的，還是應用程式的遮罩問題。不過，在避免由於意外終止之工作者處理序所造成的可用性問題時，這還是非常方便的方法。如需此項行為變更的詳細資訊，請參閱未處理的例外狀況會導致 ASP.NET 應用程式在 .NET Framework 2.0 中意外結束。

7. 確定 Proxy 伺服器組態正確
Web 伺服器管理員可以藉由設定 machine.config 檔案中的 <configuration><system.net><defaultProxy> 元素，將 Proxy 伺服器指定為用於網際網路的 HTTP 要求。
在 microsoft.com 的生產環境中，我們將 <defaultProxy> 值設定為使用系統的預設 proxy (因為沒有安裝防火牆用戶端)，並且使用 <location allowOverride="false"> 標記來防止 <defaultProxy> 元素遭到應用程式開發人員的覆寫 (可能會因一時不察而使用內部 Proxy 伺服器發行 web.config 檔案)：
<configuration>
    <location allowOverride="false">
       <system.net>
          <defaultProxy>
              <proxy usesystemdefault="true" />
          </defaultProxy>
       </system.net>
    </location>
</configuration>
在 microsoft.com 內部的預先生產和執行環境中，我們將 usesystemdefault 屬性設定為 False，將 bypassonlocal 設定為 True，並且加入 proxy bypasslist (請參閱 [圖 2])。bypasslist 會列出一般的表示式，描述不使用指定 Proxy 的位址。同樣地，此區段是包含在 <location allowOverride="false"> 標記內，可防止開發人員在其 web.config 檔案中自行指定 proxy 伺服器。(這些通常是內部的 proxy 伺服器，而且在頁面發行至生產環境後，就無法再對其進行呼叫)。任何在預先生產或執行階段中指定 proxy 伺服器的嘗試，都會導致執行階段的 ASP.NET 錯誤，因此開發人員在發行至生產環境之前，必須先移除這項組態。
Figure 2 設定 Bypasslist (Close Figure 2)
<configuration>
    <location allowOverride="false">
        <system.net>
             <defaultProxy>
                <proxy
usesystemdefault="false"
proxyaddress = "http://proxy.server.foo.com:80"
bypassonlocal = "true" />

                <bypasslist>
<add address="10\.*"/>
<add address="dns\.foo\.com" />
<add address="name1\.name2\.foo\.com" />
                </bypasslist>
            </defaultProxy>
        </system.net>
    </location>
</configuration>

8. 不要向任何人展示自訂錯誤
如前所述，絕對不要在生產環境中，讓 Web 伺服器從遠端傳回詳細的 ASP.NET 錯誤訊息。
在 microsoft.com 生產和執行環境的根 web.config 檔案中，<configuration><system.web><customErrors> 模式屬性會設定為 RemoteOnly，如此才會向遠端用戶端顯示錯誤訊息，並向 localhost 顯示 ASP.NET 錯誤訊息 (允許 Web 伺服器管理員進行疑難排解)。請注意，<customErrors> 元素是包含在 <location> 標記內，且具有 allowOverride="false" 的值 (請參閱 [圖 3])。這是為了避免個別的應用程式擁有者不小心 (或故意) 設定 mode="Off" 並將詳細的 ASP.NET 錯誤訊息擴散到網際網路上。
Figure 3 避免錯誤訊息顯示 (Close Figure 3)
&lt;configuration&gt;
    &lt;location allowOverride=&quot;false&quot;&gt;
        &lt;system.web&gt;
            &lt;customErrors mode=&quot;RemoteOnly&quot; defaultRedirect=
                   &quot;/errorpages/generic_customerror.aspx&quot;&gt;
                &lt;error statusCode=&quot;404&quot; redirect=&quot;/errorpages/filenotfound_customerror.aspx&quot; /&gt;
            &lt;/customErrors&gt;
        &lt;/system.web&gt;
    &lt;/location&gt;
&lt;configuration&gt;
同時請記住，如前所述，在 machine.config 檔案中使用 <deployment retail="true"/> 參數會關閉同時對遠端用戶端和本機顯示詳細 ASP.NET 錯誤訊息的功能。如果要執行 ASP.NET 2.0，則這個部署零售參數仍應該是您關閉這些錯誤訊息的主要方法 (若要取得關於 ASP.NET 例外狀況的詳細資訊，請使用應用程式事件記錄)。
在 microsoft.com 對內的預先生產環境的根 web.config 檔案中，<customErrors> 模式屬性是設定為關閉，如此 ASP.NET 錯誤訊息才會永遠同時對本機和遠端用戶端顯示。以下程式碼可用來啟用偵錯和疑難排解，另外，這裡並不會設定任何自訂的錯誤頁面：
<configuration>
    <location allowOverride="false">
        <system.web>
            <customErrors mode="Off" />
        </system.web>
    </location>
<configuration>

9. 知道何時啟用追蹤
在執行 ASP.NET 頁面期間，會產生 ASP.NET 追蹤，並擷取關於 Web 要求、頁面控制項樹狀結構，以及執行頁面生命週期和控制項各種階段的有趣詳細資料。同樣地，您也可以顯示由網頁開發人員寫入追蹤的自訂訊息。該追蹤可以附加至在應用程式的追蹤檢視器中，當作受追蹤要求之清單的一部分而進行追蹤或檢視之頁面的回應輸出。此功能主要是針對內部預先生產環境中的開發階段偵錯案例而提供，不該用於生產部署。
在 microsoft.com 生產和執行環境的根 web.config 檔案中，<configuration><system.web><trace> 啟用的屬性會設定為 "false"，如此就可以停用在網頁中輸出追蹤資訊的能力。請注意，<trace> 元素會包含在 <location> 標記內，而且具有 allowOverride="false" 的設定。這是為了避免個別的應用程式擁有者不小心 (或故意) 設定 enabled="true" 並將詳細的 ASP.NET 追蹤資訊輸出到網際網路上。
<configuration>
    <location allowOverride="false">
        <system.web>
              <trace enabled="false" localOnly="true"
              pageOutput="false" requestLimit="10" traceMode="SortByTime" />
        </system.web>
    </location>
<configuration>

<system.web><trace>
如前所述，在 machine.config 檔案中使用 <deployment retail="true"/> 參數也會關閉在網頁中輸出 ASP.NET 追蹤輸出的功能。如果是執行 .NET Framework 2.0，則這個參數應該仍是您關閉追蹤輸出的主要方法。
為了確保無法在對外的生產環境中意外啟用追蹤，我們從 microsoft.com 的根 web.config 檔案移除了實際的 trace.axd 處理常式，或加上註解加以排除，如下所述：
<!--
<add path="trace.axd" verb="*" type=
    "System.Web.Handlers.TraceHandler"
    validate="True" />
-->

10. 停用工作階段狀態 Web 伺服陣列
因為所有 microsoft.com 上的網站目前都是使用不具任何相似性的網域負載平衡 (NLB) 而叢集在一起 (需要不具相似性，才能將要求平均分散到叢集中的所有伺服器)，所以不保證同一伺服器會處理指定應用程式的所有要求。結果，ASP.NET 工作階段狀態模組要停用，以避免應用程式開發人員使用 Session 屬性。對於需要維持狀態的應用程式開發人員，我們所提供的指導方針是使用 View State (這樣可以在頁面程式碼內維持結構中的狀態，並且不使用任何伺服器資源)。
若要在 Web 伺服器上停用工作階段狀態，只要從 <httpModules> 節點移除下列的子節點即可：
<add name="Session" type=
    "System.Web.SessionState.
    SessionStateModule"/>
在此我假設您已經看過、甚至使用過 ASP.NET 組態檔 (machine.config、root web.config 以及個別應用程式的 web.config 檔案)，但是如果您尚未這麼做，下列的 ASP.NET 快速啟動教學課程將很有幫助：asp.net/QuickStart/aspnet/doc/management/fileformat.aspx (英文)。
本文章提及 ASP.NET 2.0 組態系統現在也包含了一些非常有用的功能，可以讓管理員使用 lockItems 和 lockCollections 屬性來鎖定組態的個別元素和屬性。這些屬性和其用法都記載於下列文章 General Attributes Inherited by Section Elements (英文)。

Jeff Toews 是系統工程主管，已經擔任 Microsoft.com 營運小組的成員六年，目前位於美國華盛頓州的 Redmond。若有任何技術問題或意見，可以透過下列方式與他聯絡：mscomblg@microsoft.com。


 實戰注意事項: 學習如何尋求協助
實戰注意事項
學習如何尋求協助
Edward Dake

有太多的桌上型電腦 管理員都認為他們永遠不需協助。我們每個人都該獨立作業，並且盡可能瞭解各項流程。電腦可以完成我們要它們執行的作業，而且只會按照我們的指示進行，而軟體則會依照設計的方式運作。我們怎麼會需要尋求協助，或與同儕合作呢？
誰在乎您的組織中有多少管理員在胼手胝足地工作呢？每個人都有其指定的工作，我們也知道這代表什麼意思，所以我們絕對不會藉由設定或基礎結構的變更來阻礙他人。公司裡有您無法存取的伺服器嗎？很明顯地，該伺服器並不是因為例行維護而關機，而是已經永遠離線。把它刪除吧！不要向別人查詢到底發生什麼狀況，也不要寄送電子郵件或參考 Information Technology Infrastructure Library (ITIL) 或 Microsoft® Operations Framework (MOF) 建議的任何變更管理文件。需要試用新產品或程序嗎？反正我們都有真正的電腦可用，誰需要虛擬電腦呢？
上述的所有範例聽起來很可怕嗎？雖然這些情況看來可能很誇張，但我在做支援工程師的時候卻全遇過，而且其中很多情況只要稍加規劃或在小組之間稍加溝通就可以避免。
事實上，若要達到真正的效率，管理員需要仰賴整個 IT 團隊，包括團隊內外的所有人員。在今天的異質性企業環境中，管理員不可能知道管理上所有該知道的事情。我們都需要建立良好的關係，以在必要時有專家可以諮詢。我的即時通清單充滿了我尊重和信賴的其他群組的人。
我發現當我們需要解決以前沒有遇過的問題或處理涉及多種技術的複雜問題時，建立合作的同儕網路 (這可不是在說什麼有線或無線的技術) 是極為有用的。假設您要疑難排解 Active Directory® 複製問題，舉例來說。這個問題是複製問題，還是 DNS 問題？forestprep 這個詞彙現在適用於 Exchange Server 和 Active Directory。現在嘗試的是哪一個 forestprep？我需要與同儕在 Exchange 或 Active Directory 中協同作業嗎？
我使用 Microsoft Office Communicator 和 Windows Live™ Messenger (最新發佈) 中的連絡人 (依群組排序)，而我已說不清有多少次我是因為工程師同僚的協助而解決了複雜的問題。請認識瞭解您的同儕，並在遇到超出您特定支援領域的問題時尋求其協助。大多數的人都非常願意幫忙，而這代表您能更即時地解決眼前的問題，甚至在問題變得更嚴重之前加以阻止。
在我的合作工具箱中還可找到其他工具，包括 Microsoft 技術社群、支援網路廣播和產品解決方案中心等。所有這些工具都在 Microsoft 說明及支援頁面的「自我支援選項」下，以功能選項的形式提供。我發現新聞群組 (位於「技術社群」區段) 非常方便，可從遭遇過相同問題或具有與我相同環境的人蒐集資訊和建議。
將自己加入特定技術新聞快訊的發佈清單同樣很有幫助。此類佈告欄包含秘訣和訣竅、最佳作法、有關最新發佈的新聞，以及能協助我解決問題和瞭解最新功能的其他資訊。
在虛擬環境中測試是一種安全的方式，可用來嘗試結構描述更新、群組原則、環境變更和許多其他的產品和流程。您可以使用 Microsoft Virtual Server 2005 R2 (英文，可在註冊後免費下載) 來建置實驗室，以便在生產環境中進行更新的首展之前先加以測試。如此一來，您便可以在非生產環境中找到並解決可能的問題，而避免在整個企業中進行首展時遭遇未預期的問題。我發現 Windows Server System™ Reference Architecture (WSSRA) 中的下列資源對於規劃和設計虛擬測試環境非常有用。尤其請參閱標題為 WSSRA Virtual Environments for Development and Test (英文) 的文件。「規劃、測試和試驗部署專案」的相關章節尤其有用。
我同時強烈推薦 TechNet 虛擬實驗室 (英文)，其中含有產品的展示和測試活動。這些實驗室會定期更新，您不需自行花費時間精力來建置環境，即可獲得第一手的產品或技術體驗。
我還發現許多產品新版本中的「說明和支援」功能非常有用。隨著時間推進，該功能已進行許多改良，現在已是用來搜尋目前技術和更新內容之說明的無價工具。另外，也不要忘記線上文件或甚至電子書等，都可用來提供快速搜尋和協助。做一個表現優異的管理員，並不代表您需要知道所有事情。也許最重要的是知道哪裡可以尋求協助。學習如何與同儕以及其他群組中的人合作，以解決跨領域或先前未遇過的問題，可以使您成為更成功的管理員。這個產業的優勢在於我們是一個社群，而我們應該努力與彼此建立關係。我經常仰賴其他人的協助來完善地解決問題。結果通常非常令人滿意，而我的管理技巧也因為與他人合作而更上層樓。

Edward Dake 自 1997 年後在 Microsoft Corporation 擔任技術客戶經理和支援工程師職務。他目前的職務是客戶服務和支援事業部目錄服務小組的技術主管。


 Windows 機密: 處理相容性缺失
Windows 機密
處理相容性缺失
Raymond Chen

之前有一個 為 Windows® 3.1 撰寫的程式，它會藉由尋找 [控制台] 視窗、存取 [檔案] 功能表，並且搜尋稱為「印表機」的項目來開啟 [印表機控制台]。在 Windows 95 中，[控制台] 的 [檔案] 下並沒有 [印表機] 選項。因此，在 Windows 95 上執行時，此程式會張貼不需要的命令訊息至 [控制台]。為解決這個問題，Windows 95 建立了虛構的 [控制台] 視窗讓程式尋找。當程式張貼訊息至虛構的視窗時，[印表機] 資料夾就會開啟。
有些人認為，Windows 3.1 應該已偵測到該程式對 [控制台] 做出不當假設並顯示警告。那麼程式的作者就會看見警告，並且在發行產品之前修正問題。但偵測程式碼區塊的意圖需要人工智慧領域的大膽分析。基本上，Windows 3.1 必須偵測到程式正在對 [印表機] 進行 Strcmp、分析此特殊 Strcmp，然後判定是否有害。但這種方法僅適用於前述的「印表機」案例。您希望系統執行多少相容性檢查？又會發生多少次誤報呢？
另一項爭議為，Windows 95 應回應此不當假設並顯示警告對話方塊，指出「程式 XYZ 正在執行不當操作」。但為了讓 [控制台] 得知張貼垃圾訊息的是哪個程式，則必須深入偵測視窗管理員。這樣做會在兩個元件 ([控制台] 和視窗管理員) 之間建立危險的連結。同樣地，這種方法只適用一個案例。您希望視窗管理員與系統中的其他所有元件短暫連接嗎？
提供一般訊息而不指名特定應用程式會較為容易。但是這也不是理想的解決方法。虛構的錯誤訊息與沒有任何錯誤訊息一樣沒有好處。除此之外，使用者很可能會略過此對話方塊，因為它根本沒有提供特定的建議動作。使用者可能會覺得這個對話方塊令人厭煩。這點相當重要。任何錯誤訊息都應該提供因應動作。如果使用者知道如何回應警告，則對話方塊就會變得相當實用。
另一個問題是，對話方塊會因為對話方塊迴圈的關係建立重複進入點。這是一項技術問題。非預期的重複進入動作是 UI 程式設計中主要的錯誤來源。此外，[控制台] 本身可能會處於強制回應狀態，而顯示對話方塊會造成強制回應結構瓦解。
對話方塊還會造成新的當地語系化負擔。如果要為所有相容性缺失都寫出一個對話方塊，那麼整個系統內將充斥數以百計的對話方塊。每個對話方塊都會需要翻譯成 33 種語言，因為 Windows 提供這 33 種語言的完整翻譯。
最後，請考慮競爭者的產品產生其中一個對話方塊時的反應。他們可能會說「Microsoft 將自己作業系統發生問題的責任推給其他人」，或是「Microsoft 故意讓我們的程式顯得錯誤百出」。這可不是誇張的說法。之前已經有一些公司向國會抱怨 Microsoft 惡意針對其產品，使這些產品無法正常運作。不過進一步調查發現，是這些公司的程式有問題。坦白說，最好是幫他們修復錯誤，勝過冗長的國會調查。
因此，目前的 Windows 版本只會在程式完全無法與 Windows 相容以致於無法執行，或只能在相當有限的情況下執行時，才會顯示警告對話方塊。而即使在這種情況下，Microsoft 仍會嘗試配合廠商，共同確保不讓客戶陷於困境、孤立無援。畢竟人們購買程式的目的是想在作業系統上執行這些程式。如果程式無法執行，沒有人會在乎是誰的錯，因為他們只想把工作完成。

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