 TechNet Magazine May 2008

TechNet Magazine May 2008

Windows 系統管理: Windows Server 2008 中的 Active Directory 備份及還原

Windows Server 2008 及全新的 Windows Server Backup 公用程式在備份方面帶來了許多變更和廣受歡迎的增強功能。以下是在全新的伺服器 OS 中備份和還原 Active Directory 的深度指南。

Gil Kirkpatrick Windows 系統管理: 設計可行的 OU 結構

有太多的系統管理員都低估了擁有設計良好的組織單位結構的重要性。一同來了解擁有完善的 OU 策略的重要性，以及判斷最適合貴公司的 OU 結構。

Ken St. Cyr Windows 系統管理: 擴充 Active Directory 架構

許多仰賴 Active Directory 的應用程式都會對架構所做的變更自下定義。但不讓這些變更影響到其他應用程式是很重要的。本文將概述如何透過 classSchema 和 attributeSchema 物件來擴充 Active Directory。

Vikas Malhotra System Center: System Center Mobile Device Manager 簡介

全新的 System Center Mobile Device Manager 提供一套完整的工具，透過 MMC 嵌入式管理單元或藉由 Windows PowerShell 來管理 Windows Mobile 裝置。了解這項重要的工具如何讓您管理行動裝置、提高安全性，以及提供 Mobile VPN 功能。

Matt Fontaine System Center: System Center Essentials SP1 的新功能

Service Pack 1 在 System Center Essentials 2007 引入了顯著的增強功能。一同來探索一些可改善使用者體驗以及使系統管理更具效率的重要變更。

Pete Zerger 編輯的話: 誠摯歡迎新單元《SharePoint 內幕》

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

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

Greg Steen Exchange 佇列問題與解答: Exchange 2007 SP1 部署

在本期文章中，我們將為您提供 Exchange Server 2007 SP1 相關問題的解答。

Nino Bilic 公用程式焦點: SharePoint 容量規劃

本文將探索 SharePoint Capacity Planning Tool，並且說明如何設計拓樸來部署 SharePoint，以及如何在執行負載與流量模擬之後修改該拓樸。

Peter Skjøtt Larsen and Satish Mathew Sharepoint 內幕: 建置 SharePoint 基礎結構

SharePoint 雖然功能強大，但它的複雜性可能會讓部署作業充滿挑戰。我們全新的 SharePoint 專欄可助您一臂之力。在第一期文章中，我們將概略介紹 SharePoint 架構，並說明如何透過 WSS 3.0 來設立基本的 SharePoint 基礎結構。

Pav Cherny Windows PowerShell: 自動化目錄管理

第一版 Windows PowerShell 所提供的 Active Directory 管理功能沒什麼看頭。一同來探討如何使用增益集，更有效地運用 Windows PowerShell 中的 Active Directory 物件。

Don Jones 嗨，Scripting Guy！: 對規則運算式挑大眉

Scripting Guy 造訪羅浮宮，進行藝術賞析，並示範如何在指令碼中使用規則運算式來搜尋及取代。

The Microsoft Scripting Guys 安全性監控: 量子安全性的原則

本文將探討海森堡不確定原理 (Heisenberg Uncertainty Principle) 和量子物理的其他元素如何詮釋不斷演進的安全性策略。 (附註：在撰寫本文的過程當中，並未傷害任何貓咪)。

Jesper M. Johansson 桌面檔案: 棄系統管理員於不顧

為什麼大家都愛以系統管理員的身分執行呢？Wes Miller 決定探討以系統管理員身分工作的風險，並探究讓使用者 (包括您自己在內) 採用使用者身分的優點。

Wes Miller 現場筆記: 多隻滑鼠，一部電腦

如果教室裡的學生人數超過可用的電腦數目時，您該怎麼辦？Microsoft Research India 開發出一個叫做 MultiPoint 的解決方案，可在一部電腦上同時使用多隻滑鼠。

Kentaro Toyama Windows 機密文件: 16 位元圖示真的過氣了

Raymond Chen 想探討為什麼 Windows Vista 不支援 16 位元圖示，也很納悶到底有沒有人注意到這一點。

Raymond Chen


 Windows 系統管理: Windows Server 2008 中的 Active Directory 備份及還原
Windows 系統管理 Gil Kirkpatrick

Windows Server 2008 中的 Active Directory 備份及還原
簡介:
  • NTBACKUP 與 Windows Server Backup 比較
  • 備份工具和選項
  • 修復工具和選項
  • Active Directory 完善備份策略的關鍵

大家都知道 Active Directory 網域服務 (ADDS) 是 Windows 基礎結構中任務關鍵的元件。Active Directory 若是失常，網路基本上也沒什麼用處。因此，Active Directory 的備份和修復計畫
是保持安全性、持續業務和循規的基礎。
Windows Server® 2008 為 Active Directory® 帶來了許多新功能，當中有兩項功能對備份和修復計畫有著深遠的影響：那就是全新的 Windows Server Backup 公用程式，以及製作和使用 Active Directory 磁碟區陰影複製服務快照集的功能。在本文中，我將說明這些增強功能所帶來的變更，並向您解釋要如何利用這些變更使 Active Directory 備份活動更具效率。

NTBACKUP 與 Windows Server Backup 比較
群組原則設定
Windows Server Backup 提供了幾項群組原則設定，可讓您有限地控制備份在伺服器上的運作方式。藉著這些備份原則，您可以緩和一些人們執行未授權備份以獲得未授權資料存取權的相關風險。這些選項包括：
僅允許系統備份 如果有設定這個選項，Windows Server Backup 便只會備份重要的系統磁碟區。它並不能執行磁碟區備份。
不允許將本機連接的儲存裝置做為備份目標 這個設定不允許備份到本機連接的磁碟機。您只能備份到網路共用。
不允許將網路做為備份目標 這個設定不允許備份到任何網路共用。
不允許將光學媒體做為備份目標 當設定這個選項時，Windows Server Backup 不能備份到任何光學裝置，例如可燒錄 DVD 磁碟機。
不允許只執行一次備份 這個設定不允許 Windows Server Backup 執行未經排定的臨機操作備份，只允許執行透過 Windows Server Backup MMC 嵌入式管理單元排定的備份。

您自 Windows NT® 3.5 以來認識與愛用的 NTBACKUP 已經移除，取而代之的是 Windows Server Backup。而這項新工具不只是盛裝打扮的 NTBACKUP 而已，它可是一套嶄新的備份技術，讓您不得不重新思考備份系統的方式。
雖然 Windows® Server Backup 是 Windows Server 2008 唯一內建的備份解決方案，但它並非取代 NTBACKUP 功能。兩者最大的差別是，Windows Server Backup 是磁碟對磁碟的備份解決方案，它並不支援備份到磁帶。您可以在直接連接的磁碟區、網路共用，甚至是外部 USB 硬碟機和多磁碟機可燒錄 DVD 上建立備份影像，但就是無法備份到磁帶。不過可以確定的是，您還是可以將磁帶機掛在 Windows Server 2008 伺服器上，並將 Windows Server Backup 產生的備份影像複製到磁帶機 — 但是必須使用別人的軟體進行這個動作。
NTBACKUP 是以檔案為主的備份和還原工具，而 Windows Server Backup 則是以磁碟區和區塊為主。Windows Server Backup 會將它的備份來源當作一組磁碟區來處理，並把每個磁碟區視為磁碟區塊的集合。這遠比透過檔案系統備份檔案要有效率許多。依區塊來處理備份也允許 Windows Server Backup 利用磁碟區陰影複製服務快照集來執行區塊層級的增量備份，並允許在目標磁碟區上建立快照集以簡化多個備份的使用 (並減少多個備份使用的空間)。
即使您進行的是完整備份，Windows Server Backup 在目標磁碟上還是可以有效利用空間。比方說，您可以對同一個磁碟區執行多個完整備份。因為 Windows Server Backup 在存放備份影像的目標磁碟上是使用磁碟區陰影複製服務快照集，所以快照集只會儲存變更過的區塊。這麼一來就可以大幅減少多個完整備份所使用的空間。而且要修復增量備份，也不需要執行多項還原作業。即使快照集只存放每個備份的差異內容，磁碟區陰影複製服務還是會讓每個備份完整顯示。
不過要小心的是，如果您是備份到本機磁碟，只有目標才能享有磁碟區陰影複製服務快照集的好處 — Windows Server Backup 不能對存放在 DVD 或網路共用上的備份，執行磁碟區陰影複製服務作業。
另外一項附加的好處是，Windows Server Backup 會以 Microsoft® 虛擬硬碟 (VHD) 格式來儲存備份影像。您可以實際上拿備份影像，在執行 Microsoft Virtual Server 2005 的虛擬機器中，把它當做磁碟區一樣掛上。只要在虛擬機器掛上 VHD，然後瀏覽特定的檔案就行了，不必執行磁帶的測試還原，來查看該檔案是在哪一個磁帶上面 (注意：您不能拿備份影像來啟動虛擬機器。因為備份的硬碟設定並不會對應到虛擬機器的設定，所以不能將 Windows Server Backup 當作實體對虛擬的移轉工具)。
但是 Windows Server Backup 的磁碟區和區塊導向有個缺點。由於這個新工具會將備份來源視作一組磁碟區和區塊，因此它並不允許您單獨備份選定的檔案，您必須備份整個磁碟區。更麻煩的是，在預設的情況下，您不能將備份影像儲存到要備份的任何一個磁碟區上 (有些方法是專門用來應付這個問題的，請參閱 support.microsoft.com/kb/944530)。這對系統狀態備份有著深遠的隱含意義，我在本文稍後會討論到。

安裝 Windows Server Backup
Windows Server Backup 是 Windows Server 2008 中的一項「功能」，而且預設不會安裝。在使用 Windows Server Backup 執行備份之前，您必須使用伺服器管理員或 SERVERMANAGERCMD 命令列公用程式來安裝這項功能。
C:\> servermanagercmd -install Backup-Features
Windows Server Backup 包括兩個子功能，亦即 Windows Server Backup 和命令列工具。要注意的是，命令列工具指的是一組 Windows PowerShellTM 指令程式 — 而不是指 WBADMIN .EXE 命令列工具。因此，如果您選擇安裝兩個子功能，就必須安裝 Windows PowerShell 功能。
Windows Server Backup 安裝好之後，可以在伺服器管理員內的存放節點下，找到 Microsoft Management Console (MMC) 嵌入式管理單元。如果您將 Windows Server Backup 安裝在 Windows Server 2008 Server Core 安裝上，請使用 OCSETUP 命令 (請特別注意 OCSETUP 命令有大小寫區分)：
C:\> ocsetup WindowsServerBackup
go.microsoft.com/fwlink/?LinkId=113146 上有安裝程序的完整說明。
請注意，Windows Server Backup 並不能還原使用 NTBACKUP 建立的影像。對於這個罕見的案例，Microsoft 提供了適用於 Windows Server 2008 的 NTBACKUP 下載版本 (請參閱 go.microsoft.com/fwlink/?LinkId=113147)。

Windows Server Backup 元件
Windows Server Backup 應用程式在架構方面有了大幅的變動。這個全新的備份解決方案包含四個元件：
  • MMC 使用者介面 (WBADMIN.MCS)
  • 命令列介面
(WBADMIN.EXE)
  • 備份服務 (WBENGINE.EXE)
  • Windows PowerShell 指令程式組
將應用程式劃分成用戶端和服務有幾項優點，當中最重要的是提高可靠性。無論是您從 MMC 用戶端或命令列介面開始備份，大部分的苦差事都是由 WBENGINE 服務擔當，用戶端程式只負責報告備份的狀態。因此，終止用戶端並不會產生半生不熟的備份。雖然用戶端會停止，但服務還是會繼續到作業完成為止。當然啦，如果您真的想要的話，還是可以停止備份，不過得明確地進行。
這種分割的架構還有另外一項優點，那就是您可以使用用戶端來管理遠端機器上的備份。當您必須備份 Windows Server 2008 Core 機器時，這一點尤其管用。
Windows Server Backup 支援使用 Windows 修復環境或 WinRE (附在 Windows Server 2008 安裝媒體中) 進行 Windows 裸機還原。WinRE 可簡化從頭修復伺服器的過程，我在本文稍後會討論執行裸機還原。另外值得一提的是，Windows Server Backup 還支援幾個可用來管理備份的群組原則設定 — 這些在「群組原則設定」資訊看板都有提到。

磁碟區陰影複製服務
Windows Server Backup 透過三種不同的方式來使用磁碟區陰影複製服務。當您在 Windows Server 2008 上開始進行完整備份時，應用程式所做的第一件事，就是為所有的來源磁碟區製作一份陰影複本。此舉可以提供一致的檔案系統檢視，供備份軟體使用 (這跟 NTBACKUP 的作法類似)。Windows Server Backup 接著會從來源磁碟區將區塊 — 一個區塊接一個區塊進行 — 複製到備份目標，為過程中每個備份的磁碟區建置 VHD 影像。
除非另外指明，否則 Windows Server Backup 還會建立來源磁碟區的快照集，讓磁碟區陰影複製服務追蹤磁碟區上所有已變更的區塊。這麼一來，Windows Server Backup 便會建立區塊層級的增量備份，而這種備份只需要讀取來源磁碟區有所變更的區塊。也就是說，Windows Server Backup 可以只讀寫變更的區塊，無需因為檔案裡面有一點點變更就得讀取整個檔案。
此舉可以有效進行增量備份，只是來源磁碟區上需要有額外的磁碟 I/O 來進行寫入作業。如果您正在備份特別忙碌或攸關效能的磁碟區，則應該停用來源磁碟區上的磁碟區陰影複製服務快照集，方法是選取 [設定效能設定] 連結，然後停用該磁碟區上的增量備份 (如 [圖 1] 所示)。
Figure 1 Disable incremental backups on busy volumes
Figure 1 Disable incremental backups on busy volumes
當備份完成時，Windows Server Backup 會製作目標磁碟區的快照集 (假設您備份的是本機連接的硬碟)，在下次備份期間，覆寫目標 VHD 檔案。但因為磁碟區陰影複製服務正在維護目標磁碟區的陰影複本，所以每一個 VHD 檔案實際上會有多個版本與每一個完整備份相對應。基本上您是花費一次完整備份和變更區塊的成本，獲得多個完整備份。

備份到網路共用
備份到網路共用就跟備份到本機磁碟區一樣簡單。最大的差別在於，它不能建立遠端磁碟區的磁碟區陰影複製服務快照集。因此，每一個完整備份都會覆寫前一個備份，只留給您網路共用上每部伺服器最新的完整備份影像。也因為這項限制，您無法使用 Windows Server Backup 排程器來排定網路共用的備份。不過，您倒是可以使用 Windows 工作排程器來執行 WBADMIN 命令列程式，進行網路共用的完整備份。如果您選擇透過這種方式來排定網路共用的完整備份，請變更每一個備份的目標資料夾，以避免覆寫前一個備份。

備份到可燒錄 DVD
Windows Server Backup 也支援備份到光學媒體 (例如可寫入 DVD)，而且您還可以建立橫跨多個磁碟區的備份組。Windows Server Backup 一律會壓縮 DVD 的備份，也就是說您只能從 DVD 執行完整系統或完整磁碟區還原。Windows Server Backup 並不支援使用 DVD 的系統狀態或檔案層級備份和還原。您也無法排定 DVD 的備份。

系統狀態備份及還原
系統狀態還原只包含選定的檔案和一些應用程式資料庫 (而不是整個磁碟區)，這種備份既實用，往往也是必要的。但是 Windows Server 2008 早期的組建版本並不支援系統狀態備份及還原，備份工具只會備份重要的系統磁碟區 (也就是修復和重新啟動 OD 和重要應用程式所需的任何磁碟區)，這些重要的系統磁碟區等於是磁碟區導向的系統狀態備份。
了解到客戶的意見反映之後，Microsoft 在 Windows Server Backup 中加入了系統狀態備份和還原功能。應用程式會建立多個 VHD 檔案，每個裝載系統狀態資料的磁碟區各一個，但是它只會複製必要的檔案和資料庫到 VHD。另外一個問題是，當您執行系統狀態備份時，Windows Server Backup 並不會像在正常備份程序一樣建立目標磁碟區的快照集，而是由每一個系統狀態備份產生全新一組的 VHD 檔案，也就是說您不能像使用快照集式磁碟區備份一樣有效利用空間。
您只能使用 WBADMIN.EXE 命令列程式執行系統狀態備份 — MMC 嵌入式管理單元並不提供這個選項。若要執行系統狀態備份，請使用這個命令：
C:\> wbadmin start systemstatebackup
–backuptarget:e:
WBADMIN 接著會將重要的系統檔案和應用程式資料庫備份到目標磁碟區，置於為系統狀態備份保留的資料夾中。在含有預設目錄資訊樹狀目錄 (DIT) 的 32 位元 Windows Server 2008 網域控制站 (DC) 上進行系統狀態備份，需要 6GB 多的空間 — 這比在 Windows Server 2003 上還多 5GB，有部分是因為 Windows Server Backup 會擷取 NTBACKUP 不會擷取的核心 OS 檔案。
跟您預期的一樣，備份系統狀態所需的時間也比較長。不用說，這些初步的數字都是根據 OS 的預先發行版得來的。當然您需要在自己的環境內測試這項作業，但當您將網域控制站移往 Windows Server 2008 時，很有可能需要針對較大型的系統狀態備份 (以及較長的備份時間) 作規劃。

透過 MMC 備份伺服器
在執行 Windows Server Backup MMC (見 [圖 2]) 時，您可以選擇設定備份排程，也可以選擇立即執行臨機操作備份。在本例中，我選擇 [單次備份] 來執行立即備份。
Figure 2 Windows Server Backup MMC
Figure 2 Windows Server Backup MMC
如您在 [圖 3] 所見，我可以選擇備份伺服器上所有的磁碟區，也可以選擇只備份我所選的特定磁碟區。如果我選擇 [完整伺服器]，Windows Server Backup 便會備份所有掛上的磁碟區，但我無法選擇備份掛上的硬碟機 — 而是必須備份到可燒錄 DVD 或網路共用。
Figure 3 Using the backup configuration dialog to specify all or select volumes
Figure 3 Using the backup configuration dialog to specify all or select volumes
在本例中，我想要備份到本機硬碟機，所以我選擇 [自訂] 選項。這時候會出現一個對話方塊，讓我選擇要備份的磁碟區 (見 [圖 4])。根據預設，Windows Server Backup 會勾選 [啟用系統修復] 方塊，使 Windows Server Backup 選取開機磁碟區、OS 磁碟區和任何其他含重要系統檔案和應用程式資料庫的磁碟區。如果是在 DC 上，還包括裝載 SYSVOL、Active Directory DIT 和 Active Directory 記錄檔的磁碟區。這等於是系統狀態備份，但它不只會備份該些磁碟區上重要的檔案而已，還會備份所有重要的磁碟區。事實上，我甚至還能夠從系統修復備份組執行系統狀態修復。
Figure 4 Selecting specific volumes to back up
Figure 4 Selecting specific volumes to back up
在選擇目的地類型 (本機磁碟機或網路共用) 並指定目的地之後，Windows Server Backup 會提示我選擇 [VSS 複製備份] 或 [VSS 完整備份]。這裡的用詞可能會讓人混淆，因為兩個選項都會完整地備份選定的磁碟區。唯一的差別是 Windows Server Backup 在備份之後處理來源檔案的方式。如果您選擇複製選項，Windows Server Backup 會將備份檔案保留原封不動，如果選擇完整選項，Windows Server Backup 就會重設封存。

從命令列備份伺服器
如果您要編寫指令碼執行備份程序，或是要在 Server Core 安裝上備份伺服器，可以使用 WBADMIN.EXE 命令列程式。WBADMIN 會提供一組完整的選項，其功能基本上與 MMC 嵌入式管理單元差不多，包括管理備份排程在內。
如果我想啟動 WBENGINE 服務，它就會轉而執行備份程序。方法很簡單，只要輸入這個命令就行了：
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
如果要備份所有重要的系統磁碟區，可以輸入這個命令：
C:\> wbadmin start backup -allcritical
–backuptarget:e:
開始備份之後，WBADMIN 會繼續執行並顯示備份的進度。即使終止 WBADMIN，備份還是會在背景繼續進行。之後可以再使用這個命令，將 WBADMIN 重新連接到一個執行中的備份作業：
C:\> wbadmin get status
如果想終止執行中的備份作業，只要輸入下面這個命令就行了：
C:\> wbadmin stop job

透過 MMC 排定備份排程
與 Windows Server Backup 整合的備份排程器，實際上是為了進行一項工作而設計的：簡化本機磁碟磁碟區的日常完整系統備份的排程作業。您可以使用內建排程器，自動在多個目標磁碟之間輪流備份。如果您有容易卸除的硬碟機 (或是使用 USB 連接的硬碟機)，可以使用這項功能來設定輪流配置、移除備份磁碟、離站存放它，然後將最舊的備份磁碟裝回伺服器以進行下次排定的備份。
Windows Server Backup 排程器只能排定每天都會進行的備份，而無法排定一、三、五備份。所以如果您不想每天執行排定的備份，就必須直接用 Windows 工作排程器。
設定本機磁碟的排程備份時，Windows Server Backup 會負責該磁碟，將它格式化、設定特定的資料夾結構，並讓 Windows 檔案總管看不到目標磁碟。目標磁碟必須是基本磁碟 — Windows Server Backup 不能備份到設定為動態磁碟區的磁碟。
透過 MMC 嵌入式管理單元排定備份非常簡單。在這個範例中，我先選取 [備份排程] 連結，指定備份的類型以及要備份的磁碟區，接著 Windows Server Backup 便會顯示 [指定備份時間] 對話方塊 (見 [圖 5])。
Figure 5 Specifying when daily backups should occur
Figure 5 Specifying when daily backups should occur
在選定要進行備份的時間後，可以選擇要備份的磁碟區。在本例中，我選擇備份磁碟區 E:，如 [圖 6] 所示。Windows Server Backup 會努力為您選擇適當的目標磁碟區，但如果您想要備份的磁碟剛好沒有顯示出來的話，可以使用 [顯示所有可用磁碟] 按鈕，來查看所有連接的磁碟裝置。經過幾個「確認」對話方塊之後，Windows Server Backup 會將目標磁碟區格式化，並使用 Windows 工作排程器排定備份工作。
Figure 6 Specifying the destination disk for a scheduled backup
Figure 6 Specifying the destination disk for a scheduled backup
每完成一次排定備份，Windows Server Backup 都會製作目標磁碟區的快照集，而且每七天都會建立新的基礎影像。相關活動會記錄在 Microsoft/Backup/Operational 記錄檔中。您可以檢查該處看看備份是否順利完成，也可以將工作 (例如傳送電子郵件訊息) 與成功和失敗的事件建立關聯，這樣隨時都可以確知排定備份的狀態。

從命令列排定備份
如果您是在 Server Core 安裝上排定備份，或者只是想編寫指令碼執行這個程序，可以使用 WBADMIN 命令列管理備份排程。如果要新增排定的備份，請使用 WBADMIN ENABLE BACKUP 命令，指定目標、來源和排定時間，就像如下所示：
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
這個命令每天會將 C:和 D:磁碟機備份到 E:磁碟機三次，分別在上午六點、中午十二點和下午六點 (請注意，所有的時間都是使用 24 小時制指定)。若要備份所有重要的系統磁碟區 (也就是可以執行裸機還原或系統狀態還原的磁碟區)，請將 –include 參數換成 –allcritical。
您也可以使用 WBADMIN 來停用所有的排定備份，如下所示：
C:\> wbadmin disable backup
這個命令會刪除 Windows Server Backup 排程器所建立的所有排定備份工作，並釋放所有備份目標磁碟區以供正常使用。請注意，您隨時都可以使用 WBADMIN MMC 嵌入式管理單元，從遠端管理 Server Core 伺服器的備份和還原活動。

網域控制站的裸機修復
備份和修復其中一項最令人雀躍的改進，是在安裝程序當中加了 WinRE。當您從安裝媒體啟動 Windows Server 2008 時，可以選擇 [修復您的電腦] 選項，如 [圖 7] 所示。在此特別指出這個選項，是因為稍不留意就很容易錯過它。
Figure 7 The Repair your computer option is available on the installation screen
Figure 7 The Repair your computer option is available on the installation screen
在安裝畫面上選取修復選項之後，Windows 會讓我選擇一個復原選項，如 [圖 8] 所示。在本例中，我選擇 [Windows Complete PC 還原]，來叫用 Windows 修復環境。
Figure 8 Specifying system recovery options
Figure 8 Specifying system recovery options
選好要修復的作業系統之後 (通常只有一個選項)，WinRE 會讓您選擇要從中還原的備份。根據預設，WinRE 會選擇最近的完整系統備份，但是您可以指定儲存在本機磁碟上的其他備份，或是在網路上搜尋儲存在其他伺服器上的檔案共用的備份。
在我的例子當中，我選擇最近的完整系統備份。接下來出現的對話方塊 (如 [圖 9] 所示)，可讓我在還原所有磁碟之前，先將它們格式化和重新磁碟分割。如果您要修復的問題是因磁碟失敗而引起，或是您已在伺服器內替換了一或多個磁碟機的話，這就是一個適當的選項。
Figure 9 You can easily format and repartition disks before they're restored
Figure 9 You can easily format and repartition disks before they're restored
經過幾個確認對話方塊後，WinRE 就啟動還原程序，而伺服器則重新啟動。這是在伺服器上執行裸機修復較輕鬆的方法。

網域控制站的系統狀態復原
如果您需要從某種 Active Directory 相關的問題復原 — 例如，從備份復原已刪除的 OU — 應該將 Active Directory 網域服務 (ADDS) 資料庫還原到早先的狀態，而不是還原整個系統。即使您可以在 Windows Server 2008，把 ADDS 當作服務一樣加以停止，還是需要將伺服器開機到目錄服務還原模式 (DSRM)，才能在網域控制站執行系統狀態還原。
變更開機選項讓 Windows Server 2008 開機到 DSRM，並不像從前那麼容易。為了支援全新可延伸韌體介面 (EFI)，整個 Windows 開機環境已經重新設計過，舊的 boot.ini 檔案已經不存在，現在 Windows Server 2008 是改採開機設定資料 (BCD) 來控制開機程序。
管理 BCD 最簡單的方法，是使用 BCDEDIT 命令列程式。若要討論所有的 BCDEDIT 命令和選項，可能要另闢單元，所以在此只能說明一些實用的範例。
若要將 Windows Server 2008 DC 重新開機到 DSRM，請使用下列命令：
C:\> bcdedit /set safeboot dsrepair
這個命令會為預設開機載入器項目設定安全開機選項。在 Windows Server 2008 全新安裝中，只有一個開機載入器項目，那就是 WINLOAD.EXE。若要移除安全開機選項並以正常模式重新開機，請使用這個命令：
C:\> bcdedit /deletevalue safeboot
若要減輕您的負擔，可以在 DC 上設定兩個開機載入器項目 — 一個用於正常開機，另一個用於 DSRM 開機。這麼一來，您就可以使用 [系統] 設定下所提供的 [啟動及修復] 設定對話方塊來變更開機選項。若要加入新的開機載入器項目，請使用這個命令：
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
這個動作會透過複製預設開機載入器項目，來建立新的開機載入器項目。BCDEDIT 會顯示如下內容：
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
GUID 會識別新的項目。接著請使用這個命令，在 BCD 中設定新開機載入器項目的安全開機選項：
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
現在您就可以使用 [啟動及修復] 設定，從正常開機模式切換到 DSRM 開機模式了 (見 [圖 10])。
Figure 10 Disable incremental backups on busy volumes
Figure 10 Disable incremental backups on busy volumes
在使用 WBADMIN 啟動系統狀態還原作業之前，必須先識別要從中進行還原的備份。WBADMIN 可從完整系統備份、只包含重要系統磁碟區的備份，或是系統狀態備份來執行系統狀態還原。無論是透過哪種方式，都必須指定要使用的備份版本。要識別可用的備份版本，最簡單的方法是使用下面這個 WBADMIN 命令：
C:\> wbadmin get versions
WBADMIN 接著會在表單中顯示備份版本，此表單與 [圖 11] 所示的資訊相類似。請注意，每個備份都有備份時間、備份目標、版本識別項 (這是備份在通用標準時間開始的時間和日期)，以及一份備份可以支援的修復作業類型清單。
Figure 11 識別能夠用於復原的備份 (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
在本例中，我選擇最近的備份，並使用這個 WBADMIN 命令來啟動系統狀態還原：
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
這個命令會執行非授權的還原作業。如果您想要執行 SYSYOL 授權的還原，只要將還原的 SYSVOL 複本標示成授權就行了，方法是在 WBADMIN 命令中加入 authsysvol 參數。如需有關此程序的詳細資訊，請參閱 go.microsoft.com/fwlink/?LinkId=113152。

製作 Active Directory 快照集
Active Directory 在備份方面最令人驚喜的變更，與 Windows Server Backup 毫無關聯。在 Windows Server 2008 中，您可以充分利用 Active Directory 所提供的磁碟區陰影複製服務快照集。這些快照集是執行中的 Active Directory 服務非常輕量的時間點備份。更棒的是，建立它們根本用不到幾秒的時間！接著您可以掛上這些快照集，然後使用標準 LDAP 公用程式 (例如 LDP 工具) 來存取它們。
您可以使用 NTDSUTIL 命令，製作 ADDS 或 Active Directory 輕量型目錄服務 (ADLDS) 的快照集，如下所示：
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
這一系列的 NTDSUTIL 命令會建立內含 Active Directory DIT、記錄檔和 SYSVOL 的磁碟區的磁碟區陰影複製服務快照集。雖然仍舊會更新 Active Directory，但磁碟區陰影複製服務還是會使用寫入時複製策略，來確保您製作的快照集受到適當的維護。不過要注意的是，快照集並不是完整的 DIT 複本，它們只不過是 DIT 中自快照集製作以來經過修改的磁碟區塊集合。VSS 可以結合這些區塊與 DIT 目前複本來呈現 Active Directory DIT，就像在製作快照集當時一樣。[圖 12] 顯示如何刪除老舊或不用的快照集。
Figure 12 刪除不用的快照集 (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

掛上 Active Directory 快照集
如果要使用其中一個快照集，必須先指示磁碟區陰影複製服務，將快照集提供給檔案系統使用。方法是以 ntdsutil 命令列出可用的快照集，然後再掛上您感興趣的快照集 (見 [圖 13])。
Figure 13 使用 ntdsutil 掛上快照集 (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
"list all" 命令會列出磁碟區陰影複製服務目前所維護的所有可用的 Active Directory 快照集。而 "mount 1" 命令會掛上選定的 Active Directory DIT 快照集，並記錄磁碟區，讓它們能夠在檔案系統中使用。它們是位於 C:\$SNAP_200712032318_VOLUMEC$\ 和 C:\$SNAP_200712032318_VOLUMED$\。
如果您查看這些資料夾，就會看到那些磁碟區的完整內容，這些內容與在製作快照集當時所呈現的一樣。不過要注意的是，掛上的快照集是唯讀的 — 也就是說，您無法在掛上的快照集裡面修改任何檔案。

從 Active Directory 快照集復原資料
掛上內含 Active Directory 的磁碟區的快照集，就好像變魔術一樣。到底該如何取得這些快照集所含的 Active Directory 資料呢？秘密就在 DSAMAIN 命令。這是一個執行 ADLDS 的執行檔。基本上它是一部獨立的 LDAP 伺服器，幾乎它所有的程式碼都與 ADDS 一起共用。您可以使用 DSAMAIN，讓掛上的快照集看起來像是在製作快照集當時內含 Active Directory 資料的唯讀 LDAP 伺服器。
請看下面這個命令：
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
這個命令會掛上位於 c:\$snap_200712032318_volumed$\ntds\dit 資料夾內的 ntds.dit 檔案，並且在 TCP 連接埠 10000 (或是任何您所指定的開放連接埠) 將它提供給 LDAP 作業使用。DSAMAIN 會在您指定外加 1 的連接埠 (在本例中，即 10001) 上開啟 LDAPS 連接埠 (也就是在安全通訊端層用於 LDAP 的連接埠)、在您指定外加 2 的連接埠 (10002) 上開啟 GC 連接埠 (用於通用類別目錄連線的連接埠)，以及在您指定外加 3 的連接埠 (10003) 上開啟 GCS (在安全通訊端層上的通用類別目錄)。
您可以使用任何 LDAP 程式 (例如 LDP)，來存取掛在指定連接埠上的 DIT。但是在 Windows Server 2008 中，Active Directory 使用者和電腦 (ADUC)、站台及服務，以及網域和信任，還有 ADSIEDIT 都已經過修改，以便讓您使用 DSAMAIN，將它們連接到掛上的 DIT。如果您在任何 ADUC 的瀏覽窗格內，以滑鼠右鍵按一下頂層節點，然後選取 [變更網域控制站]，就會看到如 [圖 14] 所示的對話方塊。如果您連同連接埠 (在我的範例中是 localhost:10000)，直接輸入裝載掛有快照集之伺服器的名稱和 IP 位址，ADUC 就會連接到掛上的快照集，讓您像在製作快照集當時一樣，瀏覽目錄的內容。很不可思議對吧？
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
透過這種方式來存取目錄資料之後，許多資料復原的工作就比以往簡單許多。比方說，過去要從備份復原已刪除的物件，必須在現有的 DC 上執行備份的非授權還原，然後再執行已刪除物件的授權還原。而且若是您還原的備份沒有正確的資料，還得用不同的備份重新來過。但是現在，只要使用恢復刪除標記和快照集，就可以快速找出並復原刪除的資料，甚至不用讓網域控制站離線也辦得到。
不過，還是有一些限制。比方說，每一個作用中的快照集都會增加與寫入目錄作業相關聯的磁碟 I/O，因此在實際執行 DC 上的任何時間點，都不應該有超過一或兩個快照集處於作用狀態。另外，您讓快照集保持作用的時間越長，磁碟區陰影複製服務的差異存放區就會變得越大 — 這也可能會影響效能。更不用提的是，復原已刪除的物件只不過是修復問題的開端，另外可能還必須復原物件的連結屬性，例如群組成員資格。但是即使如此，快照集還是能夠幫助您識別已刪除物件所屬的所有群組。

完善的 Active Directory 備份和復原策略
Windows Server 2008 推出了嶄新的備份和復原系統。有些變更剛開始可能會讓您恨得咬牙切齒，不過一旦 IT 公司接受這些變更，並且將新的備份技術結合到日常作業之後，就會達成更有效的備份和修復實作。
雖然 Windows Server 2008 大大改變了您備份伺服器的方法，但是備份和復原 Active Directory 的基本策略並沒有改變太多。所以您在規劃策略時，務必要謹記這些最佳作法：
  • 定期執行完整系統備份，以備在硬體失敗後復原 DC。至於執行 DC 完整備份的頻率，則要根據資料更新的頻率、您對停機和/或資料流失的容忍度，以及從頭重建 DC 可能需要花費的功夫而定。
  • 經常定期執行系統狀態備份，以備份 Active Directory 中的變更。至於執行系統狀態備份的頻率，則要根據您對遺失 Active Directory 資料的容忍度而定。不過每天至少要進行一次。如果您有硬體的話，至少要在本機磁碟上保留一或兩個系統狀態備份，然後將較舊版的系統狀態版本複製到 DVD 或網路共用。
  • 每個網域至少要在兩個 DC 上進行系統狀態備份。萬一其中一個備份損毀或無法使用時，還能夠提供一些保障。
如果有定義應用程式磁碟分割複本的話，一定要使用它們來備份 DC。同時也請在 DC 上建立 Windows 修復環境磁碟分割，萬一重要系統磁碟機失敗，就可以快速開機到 WinRE。

Gil Kirkpatrick 是 NetPro 的技術長 (CTO)，並且自 1996 年以來便開始針對 Active Directory 開發軟體。他偕同 HP 的 Guido Grillenmeier 創辦了廣受歡迎的 Active Directory 嚴重損壞修復工作室。Gil 也是 Directory Experts Conference (請參訪 www.dec2007.com) 的創始人。
© 2007 Microsoft Corporation 和 CMP Media, LLC.保留所有權利；未經允許，嚴禁部分或全部複製.


 Windows 系統管理: 設計可行的 OU 結構
Windows 系統管理 Ken St. Cyr

設計可行的 OU 結構
簡介:
  • 良好 OU 設計的準則
  • 常見的 OU 設計模型
  • 記錄 OU 設計

別低估設計良好組織單位 (OU) 結構的重要性 — 和複雜性。我發現 IT 部門往往過於偏頗，
不是側重 OU 結構，就是欠缺周詳，兩者都可能使 Active Directory® 模型產生問題。
過度強調 OU 結構會削弱設計 Active Directory 其他區域的注意力，例如規劃網站拓樸或考量網域控制站大小。而過於忽視 OU 規劃，也會阻礙群組原則和委派工作的進行。
我經常見到一種心態，認為 OU 結構很有彈性，萬一發現不適合，日後再更改也無妨。OU 結構確實很有彈性，不過系統管理員常常發現日後變更 OU 結構比當初想像的要困難得多。當然啦，您可以加入新的 OU，但是舊 OU 並不容易清理。
規劃不良的 OU 結構到最後往往是一發不可收拾。如果在目錄中建立一個新物件，而系統管理員不知道要把物件放在 OU 結構的哪裡，他往往是建立新的 OU，或是把物件放在它不屬於的地方。這兩種情況都有危險，建立新 OU 很簡單，但是長期來說要追蹤的話並不容易。毫無節制地建立 OU 會導致 OU 結構混亂，而且東西很容易就在目錄中悄悄蔓延。另一方面，假如您將物件加入不適用的現有 OU 中，新物件可能會收到它不應該取得的原則，或是物件的權限可能會委派給非預定的使用者。
在設計 OU 結構時，應該將這個基本的方程式牢記在心：簡單 + 適應 = 長久之道。如果設計得過於簡單，適應力可能不夠，必須常常變更。如果設計適應度太高，那麼一切就會劃分得過於仔細，而變得太複雜。
關於群組原則、委派和物件管理有三大準則可引導您訂定設計決策。這些準則可總結成三個您應該自問的問題，幫助確保您所建立的 OU 結構，能夠經得起時間和組織變動的考驗。
  1. 您需要建立這個 OU，好套用專屬的群組原則物件 (GPO) 嗎？
  2. 特定的系統管理員群組在這個 OU 裡面需要具備物件的權限嗎？
  3. 這個新 OU 可讓它裡面的物件管理起來更方便嗎？
如果當中有任何一個問題的答案是肯定的，也許就應該建立 OU。如果三個問題的答案全都是否定的，就應該重新考慮一下配置，看看另外一種設計是否比較適合。在深入探討還有說明如何應用這些準則之前，我想先解釋一下這些準則的重要性。

準則 1：群組原則
OU 設計的第一個準則，是把要套用到 OU 的群組原則物件列入考量。GPO 容許您以強制的方式設定使用者和電腦的設定。您可以在 Active Directory 中定義多個 GPO，然後將它們套用到整個網域、不同的 OU，甚或是網域裡面的各個站台。GPO 分成兩種類別，一個用於使用者，一個用於電腦。
您可以在相同的 GPO 內，同時定義電腦原則和使用者原則。GPO 的 [使用者設定] 區段多半是定義使用者在登入時會有的體驗。[電腦設定] 區段也有這類型的設定，但是這個區段也包含了其他與電腦安全性相關的設定，例如，誰登入了本機電腦，或是資料如何加密。
下面是在定義 OU 來支援 GPO 時，必須牢記在心的一些基本原則。首先，別因為使用者和電腦原則可以在同一個 GPO 裡面定義，就認為把使用者和電腦物件放在同一個 OU 裡面是個好主意。將兩者置於同一個 GPO，會使得 GPO 的應用問題更難排解。尤其如果您有啟用回送原則的話，這種情況就更明顯。
其次，許多人都忽略可以在網站層級套用 GPO，因此為了套用 GPO，而設計 OU 結構來塑造網站結構的模型。這是常見的 OU 設計模型，稱為地理模型。稍後我會詳細討論這個模型。不認可地理模型在 OU 設計當中確實佔有一席之地是我的不對，但是您稍後就會看到，我不認為應該把套用 GPO 當作是實作這種模型的主要原因。
另外，當您就 GPO 的角度來考量 OU 結構時，目標應當是避免複雜化。您一定要確實將 OU 加入 GPO 繼承的流程中，如果 OU 包含的伺服器必須採用跟其他伺服器一樣的原則，不妨將這些電腦物件放在較廣泛的伺服器 OU 下，然後在伺服器 OU 下，針對不同的伺服器類型建立多個 OU (請參閱 [圖 1])。這麼做可以簡化原則的套用作業，因為低層 OU 中的每個電腦物件，會從伺服器 OU 以及其他任何該特定類型伺服器專屬的原則那邊取得原則。
Figure 1 Creating multiple OUs for different server types
Figure 1 Creating multiple OUs for different server types
另外一項基本原則是確定您沒有建立或連結多餘的 GPO。您可以對一個 GPO 建立一項原則，並將它套用到多個 OU。不過這種做法有時候實用，有時候有害。如果您必須變更 GPO 設定，但是連結 GPO 的系統過於複雜時，可能會不小心將變更誤套到不對的物件上。您建立的連結越多，就越難控制原則的領域。同樣地，您應該避免使用跟其他原則相同的設定來建立額外的原則。如果您經常這麼做，最好能夠考慮修改 OU 結構，套用新的 GPO 繼承模型。
最後，您應該盡可能為使用者物件和電腦物件建立 OU。根據預設，使用者和電腦物件是放置在容器中，但容器並不允許您把 GPO 直接與它們連結。GPO 可以從網域套用到 [使用者和電腦] 容器，但除非您封鎖他處的繼承，否則這些原則將會套用到網域當中的每個使用者和電腦上。在 Windows Server® 2003 中，您可以使用 rediruser.exe 和 redircomp.exe 工具，將使用者物件和電腦物件的預設位置，改成您為它們建立的 OU。

準則 2：委派
您一定要配合網域裡面委派權限的方式來建立 OU 結構。請記住，在 Active Directory 中委派權限時，權限的變更只對物件有效。所以如果您對使用者授與特定電腦物件的完整控制權，該使用者就能夠修改物件屬性，但是在電腦本身不會具有系統管理員權限。
以下是在設計 OU 結構時，關於委派的一些建議作法：
設計時留意權限繼承 比方說，假如您希望第 1 層的系統管理員能夠變更大多數帳戶的密碼，但其中有一個使用者群組很特殊，雖然系統管理員不應具有重設它們密碼的能力，卻仍需要具有變更帳戶顯示名稱的能力。
這時候您有兩種做法可以選擇：第一，您可以建立兩個不同的平行 OU，並將特殊的使用者與一般的使用者相區隔。不過，這也表示如果您想要變更所有使用者的委派選項，必須要在兩個不同的地方變更這些選項。這也與不必連結多個原則的作法相違背 (見 [圖 2])。
Figure 2 Maintaining two separate parallel OUs
Figure 2 Maintaining two separate parallel OUs
另一種做法是建立巢狀 OU，並在內含特殊使用者的 OU 上，設定明確拒絕權限。只要是委派專家都會告訴您，明確拒絕是能免則免 — 但是在這種情況下，魚與熊掌不能兼得，您必須擇其一 (見 [圖 3])。您可以在兩個不同的 OU 上複製和維護設定，或是在其中一個 OU 上設定明確拒絕。就長期來說，明確拒絕實際上是比較理想的決定。
Figure 3 Using an explicit deny permission
Figure 3 Using an explicit deny permission
注意 AdminSDHolder 這個做法相當可行，但是萬一特殊使用者全都屬於其中一個 Admin 群組 (Domain Admins、Schema Admins、Enterprise Admins 或 Administrators)，那就另當別論了，因為這些群組帳戶權限的處理方法是不一樣的。其用意是為了避免把系統管理帳戶的權限不慎交給其他人。
如果您為系統管理員建立不同的 OU，會發現委派給他們的權限都會無故消失。這都是 AdminSDHolder 在作怪，它是一個特殊的容器，會把存取控制清單定時套用到每個系統管理員帳戶。因此，除非對 AdminSDHolder 容器也進行相同的變更，否則您對系統管理員帳戶所做的任何委派變更都會被還原。所以您不應該為了委派，而將系統管理員帳戶與其他帳戶相區隔。比較慣用的方式是針對群組原則來區隔系統管理員帳戶 — 這在 Windows Server 2008 中尤其如此，因為您在裡面可能擁有多個密碼原則。

準則 3：物件管理
OU 應該會使物件的管理更具效率。將物件分組到同一個 OU 中，通常比較容易執行大量變更。Active Directory [使用者和群組] 嵌入式管理單元可讓您編輯選定的多個物件的特定屬性。所以如果您必須定期變更一組物件的屬性，把它們都放在同一個 OU 裡面會比較容易。
這種做法在您使用指令碼進行更新的時候也特別管用。如果您要列舉 OU 中所有的物件，然後一一加以處理的話，使用指令碼語言準沒錯。另一個選項是個別搜尋和修改各個物件。只要將物件放到同一個 OU 中進行管理，有時候每個星期可幫您省下好幾個小時的時間。
另一個幫助管理物件的方法，是根據物件的類型，將它們區分到不同的 OU 中。只要針對印表機物件或發佈的共用區，分別建立不同的 OU，那麼當您對 OU 中的其他物件執行管理作業時，就不用剔除這些物件。這套作法也與不將使用者和電腦帳戶組成到同一個 OU 的作法一致。

選擇模型
看完 OU 設計的準則之後，讓我們仔細探討一些常見的設計模型。請注意，礙於篇幅所限，我無法討論太多模型，但其實還有很多模型。您不需受到單種模型的限制，您可以挑出各個模型的一小部分，建造自己的混合模型，來處理特定的需要。
幾乎所有模型在小規模上運作都不成問題，但是隨著企業擴大，掌控環境的能力也會相對降低。因此，請務必先在適當的實驗室環境內徹底測試模型，另外，雖然 OU 結構剛開始時很容易變更，但時間一久就越來越難了。

平淺模型
平淺模型的名稱由來，是因為它幾乎保持平坦。在這種模型中，是由幾個高階 OU 包含大多數的物件 (見 [圖 4])。這個模型大多是運用在只有小型的 IT 工作室、部門分類不多，或是人員傾向於負責多項職能的較小型企業裡面。通常我建議深度不要超過 10 個子 OU，不過 Microsoft 建議的限制是 15 個子 OU，超過這個限制就會折損效能。
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
如果負責人事的人員也負責發薪，那就沒必要為人事和薪資部門建立兩個不同的 OU。在平淺模型中，所有的使用者物件都可以群組成一個大型的帳戶 OU，或是保留在預設的使用者容器內。您的使用者物件至少應該與電腦物件相區隔。
對於這個模型，我也建議您進一步將工作站與伺服器相區隔。這樣一來，您至少可以套用不同的群組原則，而不用定義 GPO 使用 Windows® Management Instrumentation (WMI) 查詢來篩選工作站或伺服器。
保持 OU 結構寬平而不是窄深的好處之一，是 Active Directory 搜尋作業執行起來會快很多。通常我建議深度不要超過 10 個子 OU。這種模型對物件的控制能力不太細微，但管理小型企業的物件，也不需要太細微的控制能力。因此，這種模型很難成功運用在大型企業中，但非常適合較小型公司。

地理模型
在地理模型中，不同的地理區域要建立不同的 OU。這種模型最適合 IT 部門分散，但又不想花錢操作多個網域的公司 (見 [圖 5])。
Figure 5 The Geographic Model separates OUs by geographical region
Figure 5 The Geographic Model separates OUs by geographical region
假設您在亞特蘭大、巴爾的摩和西雅圖都有辦公室。如果每個站台都負責管理自己的使用者和電腦，那麼就委派的角度來說可能很適合。但萬一西雅圖的使用者飛到巴爾的摩受訓，然後鎖定了他帳戶，那怎麼辦呢？巴爾的摩的 IT 人員若沒有收到這名使用者帳戶的權限委派，可能無法幫助這名使用者。巴爾的摩的上午八點是西雅圖的上午五點，表示這名使用者可能需要等幾個小時後，才能向西雅圖辦公室求助。
有些全球性公司都使用「跟著太陽跑」的模型，也就是服務台電話會路由到位在當時是標準上班時間的時區的地點。這表示公司就不用在每個地點設置 24 小時營運的服務台，但仍然能夠在必要時為夜晚工作的員工提供協助，例如解除帳戶的鎖定。
如果這就是您的模型，那麼對您的營運需求來說，根據地理位置建立不同的 OU，可能不是最佳的選擇。因為您必須為每個 OU 的使用者，委派不同的權限給每個地區的服務台。不過，如果您的地點有它們自己的 IT 部門，那麼地理模型也許就適合貴公司了。
因為網域運作方式的關係，地理模型也很難在單一網域裡面發揮功效。各網域間常常具有不同的安全性模型。只要看一下全企業應用程式 (例如 Microsoft® Exchange)，就不難發現這一點。
亞特蘭大的 Exchange Server 可能會定義不同的郵件原則，但企業內所有的 Exchange Server 也可能都套用相同的 GPO。果真如此，那麼根據地區把 Exchange Server 放在不同的 OU 中，可能會讓您多此一舉的把同樣的 GPO 連結到多個 OU。以委派的角度來看，您必須詢問 Exchange 系統管理員，是否真的需要對 Exchange Server 的電腦物件擁有專屬權限。在大多數情況下，電腦物件都是基於群組原則的目的，而不是委派的目的來而分割成地理 OU。

以類型為主的模型
以類型為主的模型，會依據用途將物件分類 (見 [圖 6])。您上次所建立的使用者物件，是針對一般使用者帳戶、系統管理帳戶，還是服務帳戶所建立？在以類型為主的模型中，對待這些物件的方式各有不同。
Figure 6 The Type-Based Model groups objects according to their functions
Figure 6 The Type-Based Model groups objects according to their functions
在大多數的情況下，您應該針對原則區分不同的使用者物件分類。您的原則很有可能會根據使用者帳戶類型而有所不同。比方說，允許使用者以服務帳戶登入電腦，一般來說是不當的商務作法。服務帳戶密碼通常是在許多人之間共用，因此如果某人使用服務帳戶登入的話，他們的身分識別會保持匿名。若是發生了什麼事，您可能無法追蹤到在事件發生當時登入的使用者身分。在這種情況下，您就得在服務帳戶上設定原則來防止互動式登入。這很適合 [圖 3] 中所示的階層式模型
其優點是您可以利用 GPO 繼承。例如，您可以採用「所有使用者」原則，也就是適合所有使用者物件用的原則。此外，您還可以根據「所有使用者」原則，為服務帳戶另外建置一個不同的原則。這套方法可確保您的服務帳戶與其他每個帳戶擁有相同的基本原則組，以及具備特定的登入限制。
這種方法也適用於使用權限繼承而非 GPO 繼承的委派。假設您希望第 2 層系統管理員能夠重設第 3 層系統管理員帳戶以外的所有帳戶密碼。在平坦的 OU 結構中，您必須委派權限給每個存有使用者帳戶的 OU。但是，在具備階層式結構、以類型為主的模型中，您可以在帳戶 OU 上賦予第 2 層群組「重設密碼」的權限，然後在第 3 層 OU 上，只要取消繼承權限，甚或是設定明確拒絕第 2 層的重設密碼就行了。
這個作法也非常適合電腦物件。您可以區隔伺服器和工作站，以便套用不同的原則。伺服器接下來可進一步細分成職能 (見 [圖 1])。在這種設計中，您可以在伺服器 OU 上，設定影響所有伺服器的高階原則，而仍舊在每個較低層的 OU 上設定個別的原則。
舉個例說，假設您有一個 Microsoft Operations Manager (MOM) 服務帳戶。在這種分層模型中，您可以建立一個 MOM GPO，然後將它套用到 MOM 伺服器 OU。接著在該 GPO 裡面，您可以授權讓 MOM 服務帳戶以服務的身分登入。此舉只適用於該 OU 裡面的 MOM 伺服器。MOM 伺服器還是會從較高層伺服器 OU 取得伺服器 GPO，但是它們也會獲得專門的 MOM GPO，也就是在 MOM OU 連結的 GPO。

記錄設計
設計出一套經得起許多 Active Directory 環境變更考驗的 OU 結構，是很有成就感的一項工作。但您需要有些管道來追蹤 OU 的動態特性。如果沒有的話，環境可能很快就會失控。當您需要進行變更，以及新增或刪除 OU 時，必須要有清楚的指導方針指示進行步驟，以確保您的模型持續遵循設計模型，並遵守三大準則。也因此，您必須要有記錄完整的設計。
Microsoft 在 Windows Server 資源套件當中有提供文件指南。如果您的結構架構穩固，而且預期變更也不多的話，這些指南就很有用處。但大部分公司的結構都是變更相當頻繁的動態結構。因此，下面提供了幾項重要的秘訣，確保您的 OU 結構記錄完善而且能夠支援動態的環境。
確定所有資訊皆有關聯 我個人堅信說明文件都有其用途。但是有太多操作文件包含太多無關緊要的資訊，根本很難找出重要的相關資訊。在記錄的過程中，千萬別為了記錄而記錄。您真的需要記錄每個 OU 或 OU 的存取控制清單上，每個存取控制項目 (ACE) 中的物件數量嗎？OU 記錄通常只需要下列資訊就綽綽有餘了：
  • OU 名稱
  • 簡短描述
  • 建立者 — 或者是取得詳細資訊或進行變更時所要連絡的人
  • 建立的時間
讓更新更簡單 如果您必須沉悶地更新一些複雜的 Microsoft Word 文件，很有可能會拖延輸入更新的時間。如果您知道馬上會有大量的更新可以一次輸入時，暫時拖延輸入小型更新倒是沒關係。但是大家常常忘了這些小小的變更，或是不斷拖延，到最後便不了了之。因此，更新文件應該簡單到讓您不嫌麻煩才是。在大多數的情況下，簡單幾欄的 Microsoft Excel® 試算表就行了。
在物件本身加上註解 OU 物件有個描述屬性可讓您輸入註解。請不要將註解寫在設計文件上，而是將它們置於描述屬性中，方便其他人一望而知 OU 的用途。如果您需要加上其他詳細資訊，可以加在 OU 文件中，描述屬性裡面只要輸入簡短描述即可。
將記錄過程自動化 您可以編寫指令碼，將 OU 結構的內容傾印到文字檔、Excel 試算表，甚至是 HTML 檔案中。這個指令碼可以排在每晚定時執行。如果您要在 OU 的描述欄位中加入註解，這就非常有用了。接下來只要將描述屬性傾印到檔案，就會自動形成一個記錄完整、而且永遠保持更新的 OU 結構。如果您在指令碼每次執行時都建立一個新檔案，而不是覆寫現有的文件，就可以保留一份含有 OU 結構長時間以來所產生之變更的歷史記錄。
只可惜，大多數系統管理員都是在真正需要的時候，才發現適度 OU 結構記錄的重要性。在凌晨三點時，如果沒有執行還原，根本找不出其他被意外刪除的 OU。
千萬別等到大禍臨頭才抱佛腳。建議您還是主動出擊，馬上著手編寫 OU 文件，並且指定人員負責更新。只要遵守規則讓記錄文件不難更新的話，要延續下去可說不費吹灰之力。

Ken St. Cyr 是 Microsoft 的顧問，在 IT 業界擁有十年的經驗。他自 Active Directory 問世以來就開始設計和實作以 Active Directory 為基礎的目錄解決方案。


 Windows 系統管理: 擴充 Active Directory 架構
Windows 系統管理 Vikas Malhotra

擴充 Active Directory 架構
簡介:
  • 了解預設的 Active Directory 架構
  • 新增 classSchema 或 attributeSchema 物件
  • 取得及使用物件識別碼
  • 使用 .ldif 檔案擴充架構
下載本文程式碼: Schema2008_05.exe (151KB)

自 Active Directory 隨著 Windows 2000 的發行而問世以來，Microsoft 一直不斷提供客戶基本架構定義來實作 Active Directory。
Active Directory® 的出現也對在 Windows® 上撰寫和實作許多應用程式的方式產生了巨大的轉變。在這之前，像是 Microsoft® Exchange 5.5 等應用程式的建置都會包含它們自身的目錄結構。而隨著 Active Directory 的普及化，許多應用程式 (無論出自 Microsoft 或其他公司) 都一捨過去從頭建立自己的架構的作法，轉而開始利用 Active Directory 所提供的基礎結構。
這些應用程式都從 Active Directory 所提供的基本架構開始著手，然後在必要時加以擴充。比方說，Microsoft Exchange 2000 便是利用 Active Directory 來實作訊息，藉以定義 Microsoft 訊息架構的未來。
如今，許多為了搭配 Active Directory 環境使用而撰寫的應用程式都仰賴 Active Directory 的基礎架構才能運作，而許多應用程式也在必要時定義著它們自己對架構的變更。不用說，這需要一個有能力擴充的架構，我在本文稍後會討論到。另外，由於有這麼多應用程式都倚賴 Active Directory 中的基本定義，因此核心架構持續保持穩定性就變得至關重要。由於許多應用程式都必須在相同的 Active Directory 內彼此並肩運作，因此對任何一個應用程式所做的變更必須不影響到其他應用程式。

何謂架構？
對許多人來說，Active Directory 架構是個謎，光想到要靠自己修改架構，可能讓人是膽戰又心驚。當然啦，擴充 Active Directory 架構述並不是每天的例行工作，但特定應用程式或商務需求卻可能有此必要。因此，了解何謂架構，以及它所含的內容非常的重要，因為 Active Directory 是許多公司內的重要資產，而因錯誤更新導致它運作不當可能會產生相當明顯的衝擊。
許多公司的策略是使用 Windows Server® 2008 中的 Active Directory 輕量型目錄服務 (ADLDS) (或 Windows Server 2003 中的 Active Directory 應用程式模式 (ADAM)) 作為一種擴充 Active Directory 架構的替代方案，來測試或直接實作自訂架構定義。
架構是為目錄服務提供格式的基礎結構。Active Directory 架構則定義著 Active Directory 網域服務 (ADDS) 中所用的物件類別和屬性。核心架構提供許多知名類別 (諸如 user、computer 和 organizationalUnit) 和屬性 (諸如 telephoneNumber 和 objectSID) 的定義。出現在核心架構定義內的物件稱為「類別 1」物件，而新增的物件則稱為「類別 2」物件。
您可以在路徑 cn=Schema, cn=Configuration,dc=X (其中 X 是 Active Directory 樹系的命名空間) 中定義的容器內找到 Active Directory 架構。要注意的是，Active Directory 樹系只包含一個架構，因此對樹系中的架構定義所做的變更會影響到該樹系內所有的網域。[圖 1] 顯示在不同版本的 Windows Server 中的 Active Directory 架構內新增的類別和屬性數目。
Figure 1 類別和屬性數量 (Close Figure 1)

版本 | 新增的屬性數量 | 新增的類別數量 | 架構延伸檔案
Windows Server 2003 | 208 | 49 | Sch14.ldf 至 sch30.ldf
Windows Server 2003 R2 | 81 | 29 | Sch31.ldf
Windows Server 2008 | 136 | 10 | Sch32.ldf 至 sch44.ldf
對於不同版本的 Windows Server 所進行的架構更新是利用一個稱做 Adprep 的公用程式來完成的。透過 Windows Server 2003 R2 的更新，架構版本會更新為 31，而透過 Windows Server 2008，它則會變更為 44。
您可以使用像是 ADSIEdit 等工具在 Active Directory 內檢查 cn=Schema,cn=Configuration,dc=X 的 objectVersion 屬性的值，來查驗這項變動。請注意，有些應用程式，例如 Exchange Server、System Management Server (SMS) 或其他倚賴 Active Directory 的應用程式，可能會根據應用程式的需要修改架構。

構造的基礎
Active Directory 是由兩種物件所構成：classSchema (簡稱類別) 和 attributeSchema (簡稱屬性)。通常當公司想要將資料儲存在現有架構裡面所沒有的特定屬性中時，便會考慮擴充 Active Directory 架構。您首先在架構容器裡面指定 attributeSchema 物件，然後為這個新物件定義必要的屬性，藉此在 Active Directory 架構內建立屬性。
您可以在 go.microsoft.com/fwlink/?LinkId=110445 上找到 attributeSchema 物件的屬性清單及其相關資訊。如您所見，attributeSchema 物件有許多屬性可以定義，當中有許多都是必要的。
除了標準的屬性之外，在架構裡面還有一些搭配成組 (提供前導連結和後置連結) 實作的特別屬性，稱為連結屬性。舉 Active Directory 中的群組成員資格為例，任何一個群組的成員屬性 (例如，一個名為 ContosoEmployees 群組，內含名為 John Doe 的成員) 都是前導連結，而該成員物件相對應的 memberOf 屬性就是後置連結 (因此，比如在查詢 John Doe 的 memberOf 屬性時，就會計算 ContosoEmployees 群組的辨別名稱，即 DN)。
前導連結的表現方式跟任何其他屬性沒什麼兩樣。它的值可以是單值或多值 (就跟成員屬性一樣，可以包含某群組成員的多個物件)，而且可與父物件一同儲存在目錄中。
另一方面說來，後置連結則是由系統維護以確保參考完整性。當您查詢後置連結屬性的值時，會從所有相符的前導連結值計算出結果。後置連結一律是多值。
ADDS 中的每個物件類別都是由架構容器內的 classSchema 物件定義而成。您可以在 go.microsoft.com/fwlink/?LinkId=110445 中找到成功定義 classSchema 物件的必備屬性清單。
您可以指定的類別共有三種：結構式、抽象和輔助。這些都是由 objectClassCategory 屬性的值來定義 (第四種類別稱為 88，包含了在 X.500 1993 標準之前定義的類別。這種類型的類別是在 objectClassCategory 屬性中以 0 的值指定，您不應該繼續定義這種類型的類別)。

取得及使用識別碼
目錄當中每個 classSchema 和 attributeSchema 物件的識別都是使用強制物件識別碼 (OID) 定義而成，這是比照 classSchema 物件的 governsID 和 attributeSchema 物件的 attributeID 所定義。這些是特定發行授權單位為了識別物件所提供的獨特數值。編號是由 LDAP 通訊協定 (RFC 2251) 的定義所控制。Active Directory 架構當中有些 OID 是由國際標準組織 (ISO) 發行的，而有些則是由 Microsoft 所發行。OID 對於目錄當中的物件必須是唯一的。
OID 是數字字串，例如 1.2.840.113556.1.y.z，像 [圖 2] 中所示。因此，比如使用者 classSchema 物件的 OID，就是 1.2.840.113556.1.5.9。
Figure 2 使用者物件的識別碼 (Close Figure 2)

數值 | 意義 | 描述
1 | ISO | 識別根授權單位。
2 | ANSI | ISO 指派的群組指定。
840 | USA | 組織所指派的國家/地區碼。
113556 | Microsoft | 國家/地區所指派的組織指定。
1 | Active Directory | 組織指派 (在本例中，由 Microsoft 指派)。
Y | 物件類型 | 定義不同物件類型 (類別) 的數字，例如 classSchema 或 attributeSchema。例如，5 定義物件類別。
Z | 物件 | 識別類別中特定物件的數字。例如，使用者類別會指派數字 9。
當公司企圖擴充架構時，它會取得自己的 OID 根數字來確保該 OID 是唯一的，這個根數字接著會建立分支以提供唯一 ID 給公司所建立的新物件類別和屬性。OID 根數字可直接向 ISO 國家註冊機構 (National Registration Authority，NRA) 取得，這在美國是美國國家標準局 (ANSI)。
您可以在 ansi.org 上找到取得根 OID 的程序和收費表。至於其他地區，請洽相關的 ISO 成員組織，ISO 在 iso.org/iso/about/iso_members.htm 上有提供一份清單。
過去，公司可以寄電子郵件到 schemreg@microsoft.com，向 Microsoft 索取 OID，但此舉現在會產生自動回覆郵件，提示申請者從 go.microsoft.com/fwlink/?LinkId=110453 下載和執行 VBScript。
針對由 Microsoft 發行的 OID，數字是在 Microsoft OID 數字空間範圍內指派：1.2.840.113556.1.8000.x，其中 x 是指派給公司的唯一數字。公司可進一步劃分這些 OID 來指定物件。因此，某公司可將 1.2.840.113556.1.8000.x.1.y 用於新的 classSchema 物件，並將 1.2.840.113556.1.8000.x.2.z 用於 attributeSchema 物件 (其中 x 代表公司的唯一數字，而 y 和 z 則分別是針對特定 classSchema 和 attributeSchema 物件指派的數字)。另外也建議在這些物件名稱中使用公司專用的首碼，以利區別。

定義連結屬性
前導連結的 attributeSyntax 值一定要是 2.5.5.1, 2.5.5.7 或 2.5.5.14，因為這些值會與內含辨別名稱的語法相對應，例如 Object (DS-DN) 語法。
後置連結的 attributeSyntax 值則必須是 2.5.5.1，這也是 Object (DS-DN) 語法。依照慣例，後置連結屬性會加入頂層抽象類別的 mayContain 值。這可讓後置連結從任何類別的物件中讀取，因為後置連結屬性實際上並不是與物件一起儲存，它們反而是根據前導連結值計算出來。
Windows Server 2003 推出了一項功能讓公司用來連結架構中的兩個物件：亦即自動產生 linkID。透過這項功能，系統會在屬性的 linkID 屬性設為 1.2.840.113556.1.2.50 時，為新的連結屬性自動產生 linkID。將 linkID 設定為前導連結的 attributeId 或 ldapDisplayName，便會建立相對應的後置連結。在建立前導連結之後，以及建立後置連結之前，必須要重新載入架構快取。否則的話，在建立後置連結時將找不到前導連結的 attributeId 或 ldapDisplayName。架構快取是在進行架構變更後幾分鐘內，或是在重新啟動網域控制站時，視需要重新載入。
假如您的 Active Directory 是位於 Windows 2000 層級，可能需要寄電子郵件到 schemreg@microsoft.com 向 Microsoft 申請 linkID。您會在自動回覆郵件中看到此行：「傳送到 schemreg@microsoft.com 的電子郵件，只有在與舊版環境的 linkID 註冊相關時，才會進行處理。」為此，請在電子郵件中提供下列資訊：公司名稱、連絡人名稱、電子郵件地址、電話號碼、註冊的首碼 (如果適用的話)、註冊的 OID (如果適用的話)。

準備擴充架構
假設您已經決定要擴充 Active Directory 架構。您的分析工作可能包括了在確定 ADLDS (或 Windows Server 2003 中的 ADAM) 不符合要求後，考慮不使用 ADLDS 所實作的替代目錄。接下來，您識別出要新增到架構的新 attributeSchema 物件，然後定義指定這些新物件所有必要的值 (例如 cn、ldapDisplayName 等等)。在定義物件的屬性值時，您也從 Microsoft 或其他來源取得了 OID。您將上述程序記錄成商務需求和技術規格。另外，您也實作了一個實驗室環境來模仿 Active Directory，並且準備好進行測試。
許多公司實際上都設有委員會來核准或否決這類的變更，以及訂定程序來實作它們。進行這類的檢查和權衡非常重要，因為 Active Directory 在許多公司裡面都被當作授權資訊來源，所以在進行變更後讓它繼續順利運作無疑是相當重要的一環。
一旦公司決定往下一步進行後，您就必須針對此專案定義測試和實作計畫。您可以使用 Microsoft Management Console (MMC) 內的 Active Directory 架構嵌入式管理單元加入新物件，或是利用程式設計或半程式設計的方式來擴充架構 (例如使用 LDIFDE 匯入 .ldif 格式檔案，使用 CSVDE 匯入 .csv 格式檔案，或透過 Active Directory 服務介面 (ADSL) 來編寫指令碼)。
無論您採用哪種方法，這項作業都必須在連接到或在 Active Directory 樹系中擁有架構主機的彈性單一主機操作 (FSMO) 角色的伺服器上進行。另外，您進行架構更新所用的帳戶也必須具備足夠的管理權限，才能執行更新，因此請把它設為架構管理員群組的成員。最後，您必須啟用樹系的架構更新 (預設為停用)。
除非變更內容非常簡單，否則應該透過自動化的方式進行，以促進測試和生產實作階段之間的標準化，並且減少因手動執行步驟可能造成的錯誤。假設您決定使用 LDIFDE 來實作變更，若要在擴充架構時套用更新，您必須加入新的屬性和類別，在類別中加入新的屬性，然後觸發快取重新載入。現在就來逐一討論幾個案例。

新增屬性
為了方便討論，假設有家名為 Contoso 的公司想要在它的 Active Directory 中新增屬性來識別每名員工的鞋子尺寸。Active Directory 樹系有兩個網域：contoso.com 和 employees.contoso.com。必備條件是，所有利用使用者類別定義建立的物件也應該包含這個新屬性。
有一點要牢記在心，因為兩個網域都位於相同的樹系中，所以架構變更對兩者都有影響。假設您從 Microsoft 收到了 1.2.840.113556.8000.9999 的 OID，並將它進一步細分成 1.2.840.113556.8000.9999.1 和 1.2.840.113556.8000.9999.2，分別用於 Contoso 的 classSchema 和 attributeSchema 物件。現在您要為這個新物件定義所有屬性值，如 [圖 3] 所示。
Figure 3 定義 contosoEmpShoe 屬性 (Close Figure 3)

屬性 | 值 | 備註
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | 指定 Unicode 字串。
oMSyntax | 64 | 指明 Unicode 字串。
objectClass | top, attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | 如組織所定義。
isSingleValued | TRUE | 只能存放一個鞋子尺寸值。
searchFlags | 1 | 您的分析指出您想要製作這個屬性的索引。備註：您將在實驗室環境中執行壓力測試分析。
isMemberOfPartialAttributeSet | TRUE | 您希望在通用類別目錄中提供這個屬性。
另外，雖然 contosoEmpShoe 屬性必須供所有建立成使用者類別物件的物件使用，但是還是不建議您修改該使用者類別的預設定義。您反而應該定義一個名為 contosoUser 的輔助類別，並將 mayContain 的值指定為 contosoEmpShoe，如 [圖 4] 所示。然後將針對 contosoUser 輔助類別定義的屬性新增到使用者類別中。
Figure 4 定義 contosoUser 類別 (Close Figure 4)

屬性 | 值
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1 (如組織所定義)
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, container
objectClassCategory | 3 (定義輔助類別)
執行了分析並定義好值之後，接下來要建立 .ldif 檔案，看起來就像 [圖 5] 中的程式碼。您可以將 [圖 5] 的內容複製到記事本中，然後把檔案另存成 contosoUser.ldif (或者您也可以在 technetmagazine.com 上找到程式碼下載的複本)。
Figure 5 .用於擴充架構的 ldif 檔案 (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
產生 .ldif 檔案之後，應該在實驗室環境中充分測試實作，驗證網域和樹系的端對端複寫作業，以及在樹系中啟用架構更新。此時，您應該使用具備「架構管理員」權限的帳戶登入。您可能想要停用架構主機 (在此執行變更) 上的輸出複寫，然後執行下列命令匯入 .ldif 檔案：
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
變更一經生效後，啟用架構主機上的輸出複寫，並確認所有網域控制站上都已進行複寫。
深深大吸一口氣，您已經大功告成！您在架構中定義了一個新屬性，它會與透過使用者類別 (也就是使用者帳戶) 建立的物件相關聯。
若要查驗變更，請開啟 [Active Directory 使用者和電腦]，連接到 employees.contoso.com 網域，瀏覽至 [使用者] 組織單位 (OU)，然後建立一個名為 ContosoTestUser 的新使用者帳戶。現在開啟 adsiedit.msc 主控台，然後連接到網域分割 dc=employees,dc=contoso,dc=com，展開 [使用者] OU，在 [ContosoTestUser] 上按一下滑鼠右鍵，再開啟 [內容] 頁面。瀏覽以尋找 contosoEmpShoe 屬性，您可以編輯此屬性以輸入值。您也可以使用 Ldp.exe 公用程式來驗證和修改屬性。
現在來看一下定義和連結兩個屬性的範例，讓我們假想一下 Contoso 非常重視員工鞋子尺寸，並且希望對記錄公司裡面鞋子尺寸的人員進行年度績效考察。這聽起來或許很可笑，但姑且讓我們進一步假設 Contoso 不僅希望追蹤負責測量員工鞋子尺寸的人，也希望追蹤他們記錄了哪些人的鞋子尺寸以及記錄的數目 — 全都只查詢一個屬性來完成 (您可能會覺得這些資料比較適合存放在資料庫資料表中，但此處的目的只是要解釋前導和後置連結的運作方式)。
不用多說，您要先進行稍早的範例中所述的分析步驟。無論如何，我們先直接跳到產生 .ldif 檔案 linkids1.ldif 和 linkids2.ldif，如 [圖 6] 所示。然後執行這個命令匯入 .ldif 檔案：
Figure 6 前導和後置連結 .ldif 檔案 (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
現在建立使用者物件時，它也會具有 ContosoShoeSizeTaker 和 ContosoShoeSizesTakenByMe 的屬性。比方說，建立 John 使用者物件時，ContosoShoeSizeTaker 屬性會填入記錄鞋子尺寸名叫 Frank 的員工 DN。現在當您進入 Frank 的使用者物件的屬性，並查詢 ContosoShoeSizesTakenByMe 屬性時，結果也會包含 John 的 DN，以及 Frank 可能記錄的其他員工 DN。為了完成我們的案例，管理階層可能會根據 Frank 使用者帳戶的 ContosoShoeSizesTakenByMe 屬性中包含的 DN 數量來嘉獎他。

系統檢查和平衡
像架構修改這麼重大的更新，不對架構需求進行檢查是不行的。Active Directory 是使用這些一致性檢查和安全性檢查，確認在對 Active Directory 進行新增或修改動作時，所產生的變更並沒有導致任何不一致或其他問題。
首先，每個類別的 governsID 值在架構內都必須是唯一的。定義 schemaClass 物件時，在 systemMayContain、mayContain、systemMustContain 和 mustContain 清單內定義的所有屬性都必須已經存在。同時，在 subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors 和 possSuperiors 清單中定義的所有類別也必須已經存在。
另外，systemAuxiliaryClass 和 anxiliaryClass 清單中所有類別的 objectClassCategory 也必須是 88 類別或輔助類別。同樣地，systemPossSuperiors 和 possSuperiors 清單中所有類別的 objectClassCategory 也必須指定為 88 類別或結構式類別。
定義不同的類別時，抽象類別只能從其他抽象類別繼承，輔助類別不能從結構式類別繼承，而結構式類別不能從輔助類別繼承。另外，rDNAttID 屬性中指定的屬性也必須採用 Unicode 字串的語法，而且必須是單值。
這些都是與 classSchema 物件相關的一些規則。那麼 attributeSchema 物件的規則呢？就跟類別的 governsID 值一樣，attributeID 的值也必須是唯一的。此外，mAPIID 的值 (如果有的話) 也必須是唯一的。還有如果有 rangeLower 和 rangeUpper 的話，rangeLower 必須小於 rangeUpper。attributeSyntax 和 oMSyntax 的值必須相符。如果屬性採用物件語法 (oMSyntax =127)，它必須具有正確的 oMObjectClass。linkID (如果有的話) 必須是唯一的。除此之外，後置連結也必須有相對應的前導連結。

要是出錯怎麼辦？
一旦使用新物件 (類別和屬性) 擴充架構之後，就無法將它們刪除。不過，您可以在架構物件上將 isDefunct 屬性設定為 TRUE 來停用類別或屬性。您無法停用屬於隨附在 Active Directory (「類別 1」物件) 的預設架構一部分的架構物件。您只能停用新增到預設架構的物件；也就是說，只有「類別 2」物件可以停用，而且只有當 Active Directory 確認任何現有的非解除功能類別的 subClassOf、auxiliaryClass 或 possSuperiors 清單中沒有用到該類別時才可以停用。
若嘗試使屬性解除功能，Active Directory 會檢查任何現有非解除功能類別的 mustContain 或 mayContain 中並沒有用到該屬性。您可以將 isDefunct 設定為 FALSE 來恢復停用的物件。如果您的 Active Directory 是位於 Windows Server 2003 層級，則可以重複使用停用物件的 ldapDisplayName、schemaIdGuid、OID 和 mapiID 值。

結論
新增或修改架構中的類別或屬性定義牽涉到新增或修改相對應的 classSchema 物件或 attributeSchema 物件。這個程序跟在 Active Directory 新增或修改任何物件類似，唯一的差別是它會另行檢查來確保該些變更未來不會在架構中引起不一致或產生問題。
雖然修改 Active Directory 架構相當直接明瞭，但了解架構的形成，以及它實作這些變更的運作方式也很重要。對生產 Active Directory 架構所作的變更都需要相當精心的規劃，而且必須審慎進行。定義新物件的商務需求和技術規格，然後進行廣泛的實驗室測試是不可少的。由於變更可能具有深遠的影響，建議您只在絕對必要時，才擴充 Active Directory 架構。

Vikas Malhotra 在紐約服務於 Microsoft 諮詢服務，他在這個行業投入 12 個年頭以來，曾與許多大型和中型規模的 IT 公司合作解決其基礎結構架構方面的需要，例如目錄、訊息、安全性和資料網路等。他持有電子和電訊工程的學士學位，以及電訊 (科技) 管理科學的博士學位。您可以透過電子郵件與他連絡：vikasmal@microsoft.com。


 System Center: System Center Mobile Device Manager 簡介
System Center Matt Fontaine

System Center Mobile Device Manager 簡介
簡介:
  • 典型的 Mobile Device Manager 系統
  • 將 Active Directory 擴充到 Windows Mobile
  • 註冊、佈建和清查 Windows Mobile 裝置

Microsoft System Center Mobile Device Manager 2008 的推出對於在公司網路上管理 Windows Mobile 裝置的 IT 專業人員來說真是一項好消息。透過在單一產品中提供裝置管理、安全性管理，以及行動虛擬私人網路 (VPN) 功能，
這項全新的產品不僅可減輕系統管理工作的負擔，還能促進行動裝置組合的投資報酬率 (ROI)。
Mobile Device Manager 可讓 IT 專業人員運用現有的 Active Directory® 和群組原則基礎結構來強制裝置設定。無線 (OTA) 裝置管理功能讓 IT 專業人員得以輕鬆地將更新和應用程式傳遞給裝置，同時 OTA 自我佈建功能也讓部署作業更簡單也更容易擴充。Mobile VPN 可讓使用者存取防火牆背後的資料和應用程式，並同時提供不間斷的連線讓系統管理員控制部署的裝置。在可延伸、可自訂及可擴充的單一產品裡面提供所有這些功能，讓 Mobile Device Manager 儼然成為當今 IT 專業人員必備的工具。

管理的需要
在未來的幾年，行動工作人力預期將持續快速成長。一直以來，行動裝置因為其行動力的關係，比其他網路配備更難以管理。它們連接到網路的方式繁多，而有些裝置並不如其他裝置安全 — 可能是存在於防火牆外部，使用與用戶端裝置不同的作業系統，還有體型小且容易亂擺或丟失。
現今的行動裝置所提供的擴充功能為企業和使用者提供了誘人的好處，但它也使得支援這些裝置更為複雜。這可能會暴露公司資料和網路而導致額外的安全性風險，尤其是當將裝置用來存取機密的企業營運 (LOB) 應用程式和客戶資料時更是如此。這類裝置在遺失、遭竊或不當使用時，可能會危及安全性。
隨著行動裝置與傳統網路用戶端之間的功能性差距漸小，我們越來越需要像管理膝上型電腦或桌上型電腦那樣來管理行動裝置。這也正是 Mobile Device Manager 背後的構想。隨著 Windows Mobile® 平台持續受到商務使用者的愛戴，Mobile Device Manager 將成為 Windows® 架構 IT 管理系統關鍵的一環。
Mobile Device Manager 的設計是為了提供 Windows Mobile 裝置的端對端管理和控制，就像管理和控制連線的電腦或膝上型電腦一樣輕鬆。它有三大功能：
裝置管理 集中化的功能用以佈建、監視和管理 Windows Mobile 裝置，每部伺服器可容納上萬名使用者。
安全性管理 更完善的機制用以保護機密資料及追蹤裝置。
Mobile VPN 透過不間斷的功能更容易存取防火牆背後的資料和應用程式。
Mobile Device Manager 與 System Center 的整體價值體系相配合，提供 IT 專業人員各種工具將公司資產當作一等公民一樣來管理，與桌上型和膝上型電腦平起平坐。它還為那些已經在使用其他 System Center 產品的人提供熟悉的使用者介面。
這也表示 Mobile Device Manager 在設計上與現有的 Windows 基礎結構搭配無間。舉幾個例子來說，它使用 Active Directory 和群組原則，可與現有的 Microsoft 分析和報告工具 (例如 SQL Server®) 搭配運作，而且您還可以使用 Microsoft® Management Console 嵌入式管理單元和 Windows PowerShellTM 指令程式來擴充它。

Mobile Device Manager 系統
Mobile Device Manager 可進行高度調整，而且可在單一執行個體上支援上萬台裝置，也支援多個設定選項。一般來說，Mobile Device Manager 的伺服器端有四大系統元件：閘道伺服器、裝置管理伺服器、註冊伺服器，以及 SQL Server 資料庫 (見 [圖 1])。
Figure 1 Typical Mobile Device Manager system
Figure 1 Typical Mobile Device Manager system
閘道伺服器通常是安裝在周邊網路，它的作用是作為裝置網路連線的終端機，驗證傳入裝置連線，為裝置提供穩定的 IP 位址，以及執行其他與裝置或網路連線相關的機能。
裝置管理伺服器則是裝置系統管理的中樞，包括群組原則管理、OTA 軟體散佈，以及裝置清除等。它可與現有的網域控制站搭配運作。裝置管理伺服器的職責是扮演 Windows Mobile 裝置的代理網路用戶端，讓這些裝置可與其他系統通訊。
註冊伺服器會建立 Active Directory 網域服務物件來表示網域控制站中的行動裝置，讓這些裝置可以像其他網域成員一樣加以管理。這部伺服器也會處理憑證要求和行動裝置的擷取作業。它在接受或發行註冊憑證之前，會使用 Active Directory 作為驗證裝置的基礎。SQL Server 資料庫提供一個儲存機制存放所有與裝置設定、工作、狀態設定等相關的資訊。
在基礎結構順利運作之後，Mobile Device Manager 會與行動裝置進行三種類型的互動：裝置註冊、建立 Mobile VPN 連線，以及裝置管理。裝置註冊是裝置加入 Active Directory 網域的過程。Mobile Device Manager 使用「共用密碼」— 會過期且只使用一次的密碼 — 讓裝置透過非安全連線進行註冊。一經註冊之後，裝置便可以透過路由裝置的網路流量與閘道伺服器進行 Mobile VPN 連線。系統管理員或系統可以使用 Mobile VPN 連線執行裝置管理，將軟體和設定推送到裝置。

將 Active Directory 擴充到 Windows Mobile
交互式或臨機操作式 IT 安全性方法所產生的風險可能比整合式的安全性方法還高。Mobile Device Manager 正是為了協助降低這類風險而設計的，它提供一種管道讓您運用現有的 Active Directory 網域服務基礎結構來管理行動裝置 (例如 Windows PC)。所得的結果是，更具效率的識別和存取管理、更一致的原則目標鎖定，以及一勞永逸的安全性設定。
就跟電腦或伺服器的情況一樣，您也可以將 Windows Mobile 裝置相關的群組原則物件指派到組織單位 (OU)、安全性群組和 Windows Management Instrumentation (WMI) 篩選器。系統管理員還可以阻止特定的裝置取得群組原則設定。
適用於 Windows Mobile 裝置的設定和原則共有 130 多種，讓您對各種功能具備更細微的控制能力。以下只是其中一個範例：
  • 密碼設定包括密碼需求、類型和最小長度、密碼到期日，以及在指定的失敗嘗試次數 (包括通知使用者剩餘的嘗試次數) 之後清除本機裝置。
  • 平台鎖定設定可讓系統管理員選擇啟用或停用裝置功能，包括相機、無線 LAN、紅外線、藍笌，以及卸除式存放裝置。郵局通訊協定 (POP)、網際網路訊息存取通訊協定 (IMAP)、短訊息服務 (SMS)，以及 Multimedia Messaging Service (MMS) 訊息全都可以關閉，而 Windows Update for Windows Mobile 也可以停用。
  • Mobile Device Manager 提供細微的應用程式控制，它可以預防裝置執行未經簽署的應用程式或是執行含非核准簽章的應用程式，或是根據系統管理員的判斷允許特定未經簽署的應用程式。
  • 為了協助保護資料，系統管理員可以強制加密在抽取式儲存卡上建立的檔案 (包括與裝置繫結的加密金鑰)。要保護裝置上的機密資料，也可以使用裝置加密。除了預設受到保護的檔案之外，系統管理員還可以指定其他要加密的檔案。
  • Mobile VPN 設定可判斷使用者對其裝置的 VPN 連線有何種控制權，此設定也可以用來設定資料加密層級。
  • ActiveSync® 設定會設定訊息格式、電子郵件壽命篩選器、大小限制、同步處理設定，以及其他設定。
  • S/MIME 設定可要求進行訊息簽署、訊息加密，或使用指定的演算法。
這些設定，還有其他設定都支援範圍廣泛的案例。它們可讓 IT 專業人員決定要在哪些裝置上執行哪種應用程式。您可以透過無線 (OTA) 啟用或停用硬體功能。例如，您可以停用相機以防有人意外或蓄意入侵機密資訊。您可以在裝置、抽取式儲存卡或兩者上強制資料加密，以降低遺失或遭竊的裝置或儲存卡將專利資料落入未經授權者之手的可能性。
其他安全性管理工具也是 Mobile Device Manager 的一部分。Windows Mobile 裝置現在有上千種應用程式可用，系統管理員確實有需要控制哪些應用程式可以安裝而哪些不行。Mobile Device Manager 可讓您單獨針對這個目的建立和強制應用程式允許及封鎖清單。它也提供強大的遠端清除功能。藉著與裝置進行不間斷的 VPN 連線，裝置不需要等待連接到網路再進行同步處理，就可以立即清除。當從遠端清除裝置時，它會從網域控制站移除，而且它的憑證也會撤銷。如果稍後將裝置復原，您可以在透過單次用的新密碼重新註冊之後設定裝置讓它重新加入網域。

掌控行動裝置
Mobile Device Manager 的設計目的是讓在網路上管理 Windows Mobile 裝置的工作盡可能輕鬆，它以單一解決方案提供完整的裝置管理功能，包括 OTA 佈建、OTA 軟體和更新散佈，以及完整且集中化的清查管理。
OTA 自我註冊的功能應該深得忙碌的 IT 專業人員和使用者之心。使用者可在 Windows Mobile 6.1 的裝置上輸入電子郵件地址，這個動作會根據指定的電子郵件地址嘗試尋找 Mobile Device Management Server。如果找不到伺服器，便會提示使用者手動輸入 Management Server 的位址。若找到伺服器並判定使用者可以註冊，便會要求使用者輸入由系統管理員預先產生的單次用密碼。
電子郵件地址和密碼是供驗證使用者，以及在 Management Server 中註冊他的裝置之用。這項作業完成之後，就會將系統管理員定義的設定和原則推送到裝置。採取自我註冊是為了提高 Windows Mobile 裝置部署的延展性，以及減少讓這些裝置順利運作所需的時間和金錢而設計的。
Mobile Device Manager 的 OTA 軟體散佈功能是以 Windows Software Update Services (WSUS) 3.0 為基礎，世界各地有許多 IT 專業人員都已經在採用軟體更新工具組。如 [圖 2] 所示，WSUS 3.0 提供了目標鎖定和應用程式封裝的功能，滿足複雜的 IT 需要。軟體可以根據系統管理員所設定的規則和原則自動傳遞到適當的裝置。就跟進行伺服器和用戶端更新一樣，您也可以使用 WSUS 3.0 將行動裝置更新和補充程式自動化。另外更不可少的是，您可以針對部署規劃和測試目的關閉自動更新。
Figure 2 Software distribution wizard
Figure 2 Software distribution wizard
管理大規模部署的行動配備最大的挑戰之一，就是記錄追蹤一切項目。Mobile Device Manager 將清查資訊集中化，並根據 SQL Server 2005 提供富彈性、可自訂的報告 — 且同樣是利用許多使用者已經採納和熟悉的軟體。系統管理員可以收集上百種清查資訊的項目，包括 (但不限於) 作業系統和版本、裝置模型、安裝的應用程式，以及安全性原則。清查作業也可擴充，容許系統管理員新增項目和登錄設定。
如需更高的彈性，而且您偏好圖形化使用者介面的話，還可以使用 Microsoft Management Console 嵌入式管理單元來控制 Mobile Device Manager (見 [圖 3])，或者如果您習慣使用命令列的話，也可以利用 Windows PowerShell 主控台。不論是採用哪種方式，都可以擴充和自訂系統 — 這對於希望軟體能夠配合公司的企業使用者來說是最重要的。
Figure 3 Mobile Device Manager Console
Figure 3 Mobile Device Manager Console

Mobile VPN
資訊工作者在行動裝置上彼此傳送電子郵件和訊息已行之多年。現今行動裝置技術當中最實用的發展之一，當屬存取位於防火牆背後的商務資料和應用程式的功能。隨著存取率的增加、新安全性風險的產生，必須更審慎管理新增的功能以防產生漏洞。Mobile Device Manager 提供尖端的 Mobile VPN 功能，讓使用者存取內部網路資料，範圍從 Microsoft DynamicsTM Customer Relationship Management (CRM) 到 SAP，乃至於 Siebel，無所不包。此模型是為了配合桌上型和膝上型電腦現行的遠端存取策略而建置的 (見 [圖 4])。
Figure 4 Mobile VPN settings
Figure 4 Mobile VPN settings
Mobile VPN 會使用雙封套安全性功能將裝置連接到閘道伺服器，當中的資料會透過 IPsec 加密的通道以 SSL 加密的形式進行傳輸。裝置一經授權，使用者就可以結合使用者認證，存取資源特定原則所指定的資源。
Mobile Device Manager 所採用的 Mobile VPN 技術可建立不間斷的連線，不僅可改善使用者的存取，更有助於確保 IT 專業人員使用現行的原則和設定來保持裝置的更新狀態 — 並在裝置遺失或遭竊時立即將之清除。即使工作階段遭到中斷，快速的重新連線可確保裝置工作階段不必重新授權便可持續進行。Mobile Device Manager 可讓 Wi-Fi 與行動網路之間能順利轉換，同時保持連線能力。
Mobile Device Manager Mobile VPN 所採用的安全性技術是以業界標準為基礎，包括 Open Mobile Alliance for Device Management (OMA DM)、網際網路金鑰交換 (IKE) 第 2 版，以及 OMA Software Component Management Object (SCOMO)。當在複雜環境中工作的 IT 專家遇到特定情況時，這有助於使系統更容易擴充和自訂。

完整的解決方案
Mobile Device Manager 提供了一套可透過單一介面存取的完整工具，用來管理 Windows Mobile 裝置。它利用 Active Directory 和群組原則來提供安全性工具，幫助保護資料、裝置和網路的安全。透過 OTA 註冊、佈建和更新，還有強大的清查工具，裝置管理的工作也更加輕鬆。Mobile VPN 是為了在不危及安全性的情況下，提供企業和使用者所要的功能而設計的。
上述所有這些功能都與簡化 IT 專業人員工作的構想是密不可分的，而所採取的作法就是將行動裝置當作第一等公民在網路上進行管理。Mobile Device Manager 讓 IT 專業人員有能力傳達高品質使用者體驗、減輕系統管理負擔，並提供更高的管理投資報酬率 — 這都值得大肆宣揚。
在此感謝 Brian Hoskins、Derek Snyder、Prithvi Raj、Lax Madapaty 和 Katharine Holdsworth 對本文的貢獻。

Matt Fontaine 在 BuzzBee Company 擔任自由技術文件作家兼顧問。他涉獵的行業廣泛，包括高效能運算、企業軟體、精算、商用房地產、工程、建設和消費包裝產品。Matt 是常青州立大學 (The Evergreen State College) 的光榮校友。


 System Center: System Center Essentials SP1 的新功能
System Center Pete Zerger

System Center Essentials SP1 的新功能
簡介:
  • 透過整合式安裝程式封裝達成更簡易的安裝
  • 強化覆寫以微調管理組件
  • 支援工作群組
  • 全新的健全狀況狀態重新計算工作

隨著 System Center Essentials 2007 在去年七月推出，Microsoft 實現了它對中型企業的承諾，消弭了昂貴、複雜企業工具與共享軟體解決方案之間的落差，
進而為 IT 營運提供了一套統合的管理解決方案。Essentials 2007 特別是為了因應中型企業面臨的挑戰而設計的，這些 IT 專業人員經常執行範圍廣泛的工作。
Essentials 既容易安裝又方便設定，讓 IT 專業人員不但能夠主動監視和管理用戶端及伺服器，更能追蹤軟硬體資產。它的設計目標是要簡化原本複雜的工作，像是應用程式和 IT 服務監視、用戶端和伺服器軟體部署，以及疑難排解桌上型電腦問題等。
Microsoft 自初版發行以來，便不斷向已經使用 Essentials 管理其 IT 基礎結構的客戶收集意見反映，並將這些資訊併入該產品的第一個 Service Pack 當中。SP1 不光只是提供錯誤修復而已，還引進了大量的增強功能，因而產品更具彈性，能滿足各種部署案例中的客戶需要。另外，效能的提升也明顯地強化了使用者體驗，使得系統管理更具效率。
在本文中，我將探討 Essentials 2007 SP1 中所提供的一些重要改進。我也會說明如何使用這些改進功能讓您的環境管理起來甚至更簡單。

更簡易的安裝
SP1 整合式安裝程式封裝累積了所有現行的 Essentials Hotfix，使得安裝工作輕而易舉，只需要按幾個滑鼠按鍵就一切搞定。您現在還可以設定 Essentials 來使用遠端 64 位元 SQL Server® 2005 執行個體，同時讓 Essentials Server 常駐在 32 位元的 Windows Server® 2003 執行個體。這可賦予系統管理員更高的彈性，在分散式 Essential 部署拓樸中，善用他們環境中現有的伺服器基礎結構。此外，Essentials 2007 SP1 Server、主控台和代理程式還支援 Windows Server 2008 平台。這個新 OS 進入量產發行後不久將可預期獲得 Windows Server 2008 的完整支援。

更佳的主控台效能
如果您用過 Essentials 2007 的 RTM 版本，您一定樂見 SP1 中回應度大幅提高的 Essentials 主控台介面。[警示]、[事件]、[效能]、[狀態] 和 [工作狀態] 檢視當中的效能都已提升。例如，在所有的 [警示] 檢視中，對資料擷取的變更可讓警示資料選擇的速度快上三倍之多。動作和報告現在都是在背景擷取，這可進一步提升 UI 效能。同樣地，以內容為主的工作和報告 (顯示在 [操作主控台] 右手邊的 [執行] 窗格中) 也會在背景載入，讓檢視可以更迅速回應您的選擇。
顯示在 [警示詳細資料] 窗格中的警示知識現在可以根據使用者的喜好設定顯示或隱藏，只要按一下 [顯示知識 (Show Knowledge)] 或 [隱藏知識 (Hide Knowledge)] 連結就行了 (見 [圖 1])。當檢視未來的警示時，便會記住這個喜好設定。系統管理員現在還可以使用標準鍵盤快速鍵 (例如 Ctrl+C 和 Ctrl+V) 來執行警示詳細資料的剪貼作業。
Figure 1 Alert Details pane with Show/Hide Knowledge links
Figure 1 Alert Details pane with Show/Hide Knowledge links

覆寫增強
覆寫是用來微調您的管理組件，在不需要的時候停用規則和監視器，以及修改各種閾值。覆寫有幾項相關的重大改良，不僅讓環境的規則和監視器微調更加簡單，還提高了 Essentials 環境中現行覆寫的可視性。這樣一來，您就不用建立自訂規則，也不必多花時間試著識別環境裡面現存的覆寫。
舉例來說，在您為任何管理組件建立好覆寫之後，現在就可以在 [覆寫摘要] 方塊中查看物件類型的覆寫摘要。Essentials 2007 SP1 會確保覆寫目標的描述完整無誤。比方說，假設您為 Server1 的 C:\ 磁碟機建立邏輯磁碟可用空間的覆寫，摘要便會顯示 'server1/c:'。讓我來舉例說明這項變更的重要性。
在 [圖 2] 中，請注意 Essentials 2007 RTM 版本裡面 Windows Server 2003 邏輯磁碟可用空間的覆寫摘要中，根本不可能辨識出覆寫的 C:\ 磁碟機執行個體目標是由哪部電腦所主控的。但在 Essentials SP1 的相同覆寫摘要中，您可以看到 [名稱] 欄位現在不僅會顯示目標磁碟機執行個體，還會顯示主控該磁碟機的電腦 (見 [圖 3])。
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Figure 3 The same Overrides Summary in Essentials 2007 SP1
警示嚴重性也會明顯左右系統管理員所收集的警示流量多寡。截至目前，如果設定密封管理組件的 Essentials 規則所產生的重要警示，對部分伺服器來說並不重要，系統管理員將無法調整這項設定，因為規則覆寫中並不會公開警示嚴重性和優先順序。唯一的解決方法相當費事，那就是建立覆寫來停用某些機器的規則，隨後再於可操控警示參數的非密封管理組件中重新建立規則 — 從系統管理的角度看來，這很明顯並不是理想的情況。
這個問題在 SP1 已經過巧妙的處理，所有密封的管理組件規則現在都會將警示嚴重性和優先順序公開成覆寫參數，如 [圖 4] 所示。系統管理員因此可迅速且輕易地透過建立覆寫，來降低或提高 Essentials 2007 中的規則所產生的警示嚴重性和優先順序。
Figure 4 Alert severity and priority rule overrides
Figure 4 Alert severity and priority rule overrides
您可能也已經注意到 [圖 4] 中的 [強制] 核取方塊，Essentials RTM 版本的主控台介面並沒有此方塊。在物件啟用多項覆寫的情況下，選取 [強制] 旗標的覆寫將具備較高的優先順序。當兩個物件群組設有相同的覆寫，且有些物件在這兩個群組中都有成員資格時，這點很實用。在想要優先處理的覆寫上設定 [強制] 選項，您將可確定究竟套用的是哪個覆寫設定。
為了更容易建立新的管理組件，Essentials 2007 SP1 還引進了從任何現有管理組件，複製檢視到未密封管理組件的功能。所有檢視類型 (例如 [事件]、[警示]、[效能]、[儀表板] 和 [圖表]) 都支援複製作業，而且可以在 [監視] 空間內完成。比如，若您為 Active Directory® 覆寫建立了管理組件，然後想要使用 Active Directory 覆寫管理組件中某個 Active Directory 管理組件檢視，只要選取所要的檢視，然後將它剪貼到 [監視] 空間的 [瀏覽] 窗格中所要的自訂管理組件資料夾就可以了。

全新的覆寫報告功能
另外值得一提的是 Microsoft® Generic Reporting Library 中的覆寫報告，這是位在 Essentials 主控台的 [報告] 窗格中。這份報告提供了一種方式，從儲存覆寫的管理組件觀點或根據套用覆寫的管理組件來描述覆寫 (見 [圖 5])。使用者可以設定報告參數將密封的 MP 覆寫從報告中排除。這個篩選選項很重要，因為 Microsoft 和其他廠商提供的密封管理組件包含了許多覆寫，但是當您報告自身環境的變更時不見得需要這些覆寫。
Figure 5 Overrides Report parameters
Figure 5 Overrides Report parameters
如果您遵循 Microsoft 的最佳作法，為每個密封的管理組件建立不同的自訂管理組件 (一個用於 Active Directory MP，一個用於 Exchange MP 等等)，您就能有效縮小報告範圍來查看套用到特定管理組件的覆寫。
選取適當的未密封管理組件後，您可以執行報告，這會顯示如 [圖 6] 所示的輸出。要注意的是，報告不但會清楚顯示覆寫所套用的規則或監視器 ([受影響的項目 (Affected element)] 欄)，還會顯示與該監視器相關的安裝和刪除日期及時間。這表示覆寫報告不僅可當成作用中覆寫的清單，還能作為覆寫設定變更記錄的報告。
Figure 6 Overrides Report detail
Figure 6 Overrides Report detail
最後，在每個受影響的規則或監視器的詳細資料檢視下方，您會看到一個標示為規則設定檢視的超連結。這個連結會啟動一個不同的 [規則] 檢視或 [監視器] 檢視，顯示以受影響物件類型為目標的檢視範圍。舉例來說，假如您按一下 [圖 6] 所示的覆寫的規則設定檢視連結 (這是以 Active Directory Domain Controller Server 2003 電腦角色為目標的規則覆寫)，請注意產生的規則檢視將只會顯示以該物件類型為目標的規則。

支援工作群組電腦
客戶意見反映的其中一項重點，就是關於在工作群組設定中管理伺服器與工作站的需求。許多環境的周邊網路或分公司都至少有一部沒有加入網域的伺服器。因為 Essentials 需要在 Essentials Server 和代理程式管理的電腦之間進行相互驗證，所以位於 Essentials Server 信任界限之外的工作群組電腦也超出 Essentials 代理程式部署的範圍。在許多環境內，這表示有可能讓基礎結構的重要元件處於不受監視的狀態，並且被排除在 Essentials 補充程式管理程序之外。那該如何安全地管理這些電腦呢？
SP1 引進了憑證式驗證，可用於無法使用 Active Directory 和 Kerberos 驗證的案例。若要這麼做，Essentials Server 和代理程式管理的電腦都必須安裝 X.509 數位憑證。此數位憑證可以從 Windows® 獨立或企業根憑證授權單位發行。如果目前您的環境中沒有 Windows 憑證授權單位，可以在環境內的網域控制站或成員伺服器上 (包括 Essentials Server) 透過 [新增/移除程式] 來安裝這項功能。如需有關 Windows Server 2003 中的憑證服務和公開金鑰基礎結構 (PKI) 的詳細資訊，請參閱 microsoft.com/windowsserver2003/technologies/pki。
若要在 Essentials 中設定憑證式驗證，首先要要求和發行憑證到 Essentials Server 以及要進行管理的電腦。您可以在作為憑證授權單位的伺服器上透過網站來輸入要求。
發行並安裝憑證之後，必須使用 MOMCertImport 命令列公用程式「註冊」憑證以便與 Eseentials 搭配使用。若要完成憑證設定，只要將憑證匯出到檔案 (.pfx 格式)，並在本機電腦上使用下列語法執行 MOMCertImport 就行了：
MOMCertImport.exe <cert path \ name>
一旦在 Essentials Server 和要進行管理的電腦上執行所有這些步驟之後，這些系統便能相互驗證，並且安全地透過加密的通道交換資料。若要完成代理程式部署程序，只要在目標電腦上手動安裝 Essentials 代理程式就成了。

網路和裝置監視
Essentials 2007 提供網路裝置監視功能，能夠探索許多啟用 SNMP 的網路裝置的通用屬性。雖然 SNMP 第 2c 版 (SNMPv2c) 目前最為普及，但並非所有網路裝置都是平等建立。因此，SP1 提供 SNMP 第 1 版 (SNMPv1) 的支援，來配合監視各種舊版的網路裝置，像是一些不具 SNMPv2c 功能的 UPS、路由器和列印伺服器等。如 [圖 7] 所示，系統管理員可以透過 [電腦和裝置管理精靈] 中額外的下拉式欄位，告訴 Essentials 要使用哪個 SNMP 版本。
Figure 7 Enhanced interface for network device discovery
Figure 7 Enhanced interface for network device discovery

增強的更新管理
SP1 在更新管理方面也提供了明顯的改進。Windows Server Update Services (WSUS) 3.0 自動核准規則容許您指定不同的產品和更新分類，例如自動核准 Microsoft Word 的定義更新。
Essentials 也新增了對多重自動核准規則的支援，使它的功能性與 WSUS 3.0 平台並駕齊驅 (見 [圖 8])。這讓系統管理員有能力針對多種更新類別建立自動核准，包括 Windows Vista® 重大更新和 2007 Office System 的 Service Pack。自動核准規則接著會套用到目前 WSUS 伺服器上的所有更新。因此，只要在 [自動核准] 對話方塊中按一下 [立即執行規則 (Run Rule(s) Now)] 工作，系統管理員就可以立即將變更套用到顯示在 Essentials 主控台中的現有更新。
Figure 8 Auto-Approvals in Update Management
Figure 8 Auto-Approvals in Update Management
藉由加強工作群組設定中電腦的代理程式部署支援，系統管理員便能夠從 Essentials 主控台控制整個環境的更新管理。

計算物件健全狀況狀態
過去在健全狀況總管中查看監視器的狀態時，系統管理員必須等候監視器狀態進行定期的重新整理，才能判斷復原或其他修正動作是否成功。健全狀況總管的 SP1 版本中有項新功能，那就是「重新計算健全狀況」工作，它會對監視器狀態執行所需的重新計算作業 (見 [圖 9])。由於不必在等待查看監視器狀態是否回歸健全狀態的同時，又花時間等候各項修正動作完成，因此能大幅加速疑難排解的過程。
Figure 9 Recalculate Health Task in Health Explorer
Figure 9 Recalculate Health Task in Health Explorer
同樣地，「重設健全狀況」工作 (自 RTM 以來提供) 也經過了一些重要的改良，以確保每個監視器會實際回應要求，將它的健全狀況重設為健康 (綠色)。這在對 Essentials Server 本身執行重設要求時更是如此，因為在 RTM 版本中它不一定會回應重設要求。

編寫診斷指令碼
診斷是 Essentials 2007 中一種特殊的新內嵌工作類型，允許在發生警示時自動或指定執行資料收集工作。自動診斷是設定在監視器每次進入錯誤狀態時執行的工作。診斷的結果會顯示在健全狀況總管的 [狀態變更事件] 索引標籤的 [詳細資料] 窗格中。指定診斷則會在相同的區域顯示成一個超連結，而且只要按一下該連結就可以執行。結果會顯示在本機電腦上的快顯視窗中。
如 [圖 10] 所示，SP1 允許在診斷工作中使用指令碼 (在 RTM 版則只能使用命令列回應) 來擴充診斷的功能。在遇到錯誤情況時，這樣可提供架構來執行更詳盡且多元的自動化資料收集回應。請注意，這些診斷工作都支援使用 VBScript 和 JScript®。
Figure 10 Alert Details pane with Show/Hide Knowledge links
Figure 10 Alert Details pane with Show/Hide Knowledge links

匯出到 Visio
SP1 中另外一項新功能是支援將圖表匯出成 Microsoft Visio® 2007 格式，當使用者選取圖表檢視時，工具列上會出現一個按鈕。這提供了非常便利的記錄功能，因為 Active Directory 和 Exchange Server 2003 管理組件提供了現成可用的詳盡拓樸圖表，為系統管理員省下了編寫說明文件的寶貴時間。另外，還可以儲存圖表配置喜好設定。Essentials 主控台會在下次選取圖表檢視時，記住這些喜好設定。

更完備的備份與復原指引
安裝 Essentials 2007 SP1 之後，安裝精靈現在會馬上自動提示使用者備份 Essentials Management Server 加密金鑰 (見 [圖 11])。Essentials Server 會在 Operations 資料庫的「使用認證執行 (Run As Credentials)」的安全存放區中使用此金鑰組。當 Essentials Server 必須從備份還原時，也得要使用這些金鑰。若無此金鑰組，將需要重新安裝 Essentials，並從頭設定。
Figure 11 Essentials encryption key backup
Figure 11 Essentials encryption key backup

提高管理組件品質
Essentials 的 SP1 除了有許多改進之外，Essentials 產品小組更是竭力透過更多樣化且嚴密的測試程序，並藉著與各種產品小組和應用程式主題專家更密切的互動，改進 Essentials 平台所用之管理組件的品質。成果將反映在未來發行的更多管理組件上，它們都會利用 Microsoft 監控平台中的新功能，包括自我調整閾值，使用分散式應用程式模型進行服務導向的監控，以及強大的報告引擎等。
Microsoft 將開始推出更多原生的管理組件，來運用 Essentials 中自 2008 年開始發行的新功能。您可從 System Center 管理組件類別目錄下載 Essentials 2007 的管理組件，網址是 go.microsoft.com/fwlink/?LinkId=112399。

立即試用
SP1 所提供的效能提升使得 System Center Essentials 2007 成為管理您的中型企業的 IT 基礎結構一項明智的投資選擇。如果您的環境內已經部署 Essentials 2007，不妨下載 SP1，親自體驗一下功能和效能方面的改進。如果您尚未部署 Essentials 2007，並且想要試用含 SP1 的 Essentials 2007，您可以下載整合 SP1 的安裝程式套件。您可以在 Essentials 2007 首頁找到這兩種套件，還有其他的產品資訊，網址是 microsoft.com/systemcenter/essentials。

Pete Zerger 是 AKOS Technology Services 的顧問夥伴，並且在 IT 產業已有九年的經驗。他擅長設計和部署企業營運管理、目錄服務，以及訊息解決方案。Pete 持有訊息中心的 MCSE 認證、SQL Server 2005 的 MCTS 認證，另外身兼 Microsoft Operations Manager 的 Microsoft MVP。他是 systemcenterforum.org 的創辦人，這是一個探討 Essentials 2007 和 System Center 組合軟體的人氣社群網站。


 編輯的話: 誠摯歡迎新單元《SharePoint 內幕》
編輯的話
誠摯歡迎新單元《SharePoint 內幕》

也許您還記得上月份我在《編輯的話》當中對 The Cable Guy 致上歡送之意後，就提到《TechNet Magazine》本期即將推出新的專欄。我想藉此表達心意，希望大家伸出雙臂迎接《SharePoint 內幕》，這份月刊涵蓋了 IT 專家在架構、部署、保護、維護和支援 SharePoint 基礎結構方面所需知道的一切資訊。正如我之前所做的承諾，本專欄將由 Pav Cherny 打頭陣，以一篇介紹 SharePoint 基礎結構重要元素的概觀文章揭開序幕。接下來則以 SharePoint 網站管理作為下月份的主題。我們仍將開放大家對專欄內容提出意見：如果您希望我們涵蓋哪些特定的 SharePoint 主題，請不吝告訴我們，來信請寄 tnmag@microsoft.com。
另外在本月份的議題當中，Gil Kirkpatrick 將針對 Windows Server 2008 的 Active Directory 備份與還原程序，發表一篇深入且內容豐富的概觀報導。在許多 (就算不是大部分) Windows 導向的網路中，Active Directory 是識別與存取資訊的權威來源 (我相信大家都同意這是非常重要的東西)。同時它也是所有 Exchange、SharePoint、Configuration Manager ... (族繁不及備載) 部署的重要基礎結構元素。但是，上個月我參加 Gil 在芝加哥 Directory Experts Conference 舉辦的其中一場會議時，他詢問與會人士，有多少人曾經針對 Active Directory 規劃出一套完善的嚴重損毀修復計劃，在場只有一人舉手。我可以肯定的說，大家都應該看看 Gil 所寫的文章。
也許 Active Directory 並非您的專長 (當然這個可能性微乎其微)，別擔心，這裡有許多資訊提供您作為參考。Matt Fontaine 將為我們介紹 System Center Mobile Device Manager (如果您負責管理貴公司的 Windows Mobile 裝置，那麼這絕對是您必須具備的新技術)，Pete Zerger 將逐步引導我們認識 System Center Essentials SP1 的新功能，而 Jesper Johansson 則把海森堡測不準原理 (Heisenberg Uncertainty Principle) 套用到 IT 安全性。Scripting Guy 永遠與我們同在，《Exchange 佇列問題與解答》也會再度回鍋，其他還有許多精采內容等著與您分享。
最後值得一提的是，我們正在針對新推出的《TechNet Magazine》酷網站 (網址仍是 technetmagazine.com) 籌備一個專案，並且邀請最愛的作者製作基本指南影片 — 這些影片將隨同線上文章一起提供，逐步引導您瞭解內容。我們非常歡迎您告訴我們，您最希望在這些影片看到哪些主題和技術的介紹。同樣的，來信請寄 tnmag@microsoft.com。謝謝啦！ —Joshua Hoffman


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

Windows 叢集
Windows® Compute Cluster Server 與傳統 Windows 叢集有何不同？
— 來自 blogs.technet.com/tnmag

這是很常見的問題！只要談到 Windows Compute Cluster Server (CCS)，很多人就會提出有關可用性叢集 (容錯移轉叢集) 的問題。運算叢集與「可用性叢集」不同，後者是在各系統間提供服務的容錯移轉。
運算叢集使用工作佇列或排程器來指派工作給叢集中的不同系統。排程器 (在叢集的主節點上執行) 接收工作排程要求，然後指派工作到叢集中的其他運算節點。簡單來說，CCS 可讓您分配電腦間的工作，而可用性叢集則是致力於提供不中斷的服務。
—John Kelbley，資深技術產品經理

Robocopy GUI
感謝貴專欄刊登有關 Robocopy GUI 的文章 (2006 年 11 月，technetmagazine.com/issues/2006/11/UtilitySpotlight)。Robocopy 因此變得很簡單易用，而且標籤群組讓我更容易了解許多命令列選項。
—Biff M.

非常謝謝您的寶貴意見！很高興您覺得這個工具好用。同樣地，若您希望《TechNet Magazine》介紹其他各種工具，請務必告訴我們！請將意見寄至：tntools@microsoft.com。

裝置驅動程式
請問要如何列出與特定裝置驅動程式相關聯的所有特定檔案？
—T.P.

若您想要一份清單列出支援特定驅動程式安裝的所有各種檔案，可惜目前並沒有完美的解決方案。最好的辦法就是查看相關驅動程式隨附的 INF 檔案 — 尤其是通常標示為 *.copyfiles 的部分，因為這個部分是關於該驅動程式的隨插即用識別碼 (PnPID)。這個部分會列出在驅動程式安裝過程中複製的檔案。
但是有些驅動程式會將呼叫「副安裝程式」當作驅動程式的一部分，進而實際解壓縮或安裝其他檔案，因此增加此辦法的困難度。不過剖析 CopyFiles 區段通常都可以讓您取得大部分的檔案 — 只是您必須仔細查看並了解 INF 的意思。
—Wes Miller，專欄作家，桌面檔案

Windows 驗證
我一直想找提供 Windows 驗證相關資訊的文章或白皮書。更具體的說，我想要進一步學習在 Windows 2000 Active Directory® 網域中使用網際網路驗證服務 (IAS) 的無線作業。可否請您介紹涵蓋這類資訊的文章？
—Brett M.

有關這個主題最佳的資料來源應該是 TechNet 上的 IAS TechCenter，請參閱 technet.microsoft.com/network/bb643123。其中包含與 IAS 驗證相關的一些文章及白皮書連結。
另一個適合張貼這些問題的線上論壇當屬 Windows 2000 Server 安全性新聞群組：microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security。

感激的讀者
我拜讀了您們在 2007 年 12 月份發表的一篇有趣文章《基本電腦鑑識指南》(網址是 technetmagazine.com/issues/2007/12/Forensics)。首先，我要恭喜您發表了這麼重要的資訊。其次，我想恭喜在 Microsoft 擔任專案經理的共同作者 Tom Cloward，因為他舉出了在安全性領域精采的經驗。我還想要恭喜在 Microsoft 擔任技術專案經理和安全性主題專家的共同作家 Frank Simorjay。您身處安全性領域，並同意分享您關於本主題的豐富知識來解決網際網路安全性攻擊所產生的問題。您們的貢獻值得讚賞。諸多感謝。
—Mr.S.

Mr. S.，感謝您的來信。我們也同意這個主題很重要，因此計畫在接下來幾期的《TechNet Magazine》中深入討論此主題，希望您滿意。再次感謝！


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

分析磁碟空間
FolderSizes
foldersizes.com
您要如何得知用戶端電腦上的所有空間是被什麼佔用了？為了了解電腦何時會逼近容量上限，您可能已經設定磁碟空間監視器，但是若要判斷如何清除磁碟來恢復可用空間的健康比例，這有時並不容易。有一個公用程式可以協助您識別是什麼佔用了空間，就是 Key Metric Software 推出的 FolderSizes。
第一次啟動這個應用程式時，它會快速地逐步解說應用程式的 UI，好讓您開始使用 (不過此應用程式本身就非常單純)。若要分析磁碟機或資料夾，只要在階層式 [資料夾瀏覽器 (Folder Browser)] 面板中按一下該磁碟機或資料夾即可。當 FolderSizes 掃描過目標後，程式會提供磁碟使用量的圖表，還有資料夾檢視以顯示每個上層資料夾的內容分別使用了多少空間。而且只要按一下滑鼠，就可以在圓形圖與橫條圖之間切換資料夾的視覺效果，以便了解空間使用在什麼地方。我個人覺得在處理各種同層級目錄時，橫條圖比較好用。
在橫條、圓形圖塊或資料夾上按兩下即可向下切入子資料夾。這種導覽方式可讓您快速方便地鎖定可能的問題點，例如使用者命名為業務簡報 MP3 的「隱藏」目錄。或者，如果您的使用者是個文件迷，喜歡在電腦上大肆囤積，您可以依照上次修改日期來排序，檢查哪些檔案已經很久沒有存取了。如此一來，就可以理所當然地說服使用者將檔案封存到 CD 或永久刪除，也不會造成任何麻煩。
另一個很棒的功能是 FolderSizes 可以讓您自訂圖表中所要顯示的層級數目。例如，您可以依照最大到最小的排序順序，同時檢視磁碟機上每個資料夾的圖表，藉此區隔問題點。找到問題點之後，您可以按一下滑鼠右鍵來存取 [自此開始命令提示字元 (command prompt from here)] 和 [探索此資料夾 (explore this folder)] 動作。這可讓您執行其他所需的公用程式或檢查。
FolderSizes 也包含內建的報告產生器，另外提供一組目標檔案系統內容的檢視。比方說，您可以尋找特定類型的最大檔案，或是系統中最舊的檔案；您可以尋找暫存或重複檔案；您可以尋找所有唯讀檔案；您也可以判斷出檔案伺服器中具有特定擁有者的所有檔案。這類的例子不勝枚舉。報告產生之後，就可以篩選檢視，列印報告，甚至是將報告匯出到 XML、HTML 或 CSV。
除此之外，FolderSizes 也提供一種絕佳的方法來簡化您的備份，可確保只抓取真正需要封存的檔案。您也可以使用應用程式的命令列介面來編寫指令碼並自動化用戶端或伺服器系統的檢查作業。因此，如果您正想找一種方法快速隔離霸佔伺服器或用戶端電腦磁碟空間的問題，不妨試試看 FolderSizes。
價格： 單一使用者授權 $50 美元起。
FolderSizes offers chart visualization of system folders
FolderSizes offers chart visualization of system folders

管理使用者帳戶
Inactive Users Tracker
netwrix.com/inactive_users_tracker_freeware.html
您的組織規模越大，就越難有效追蹤非使用中的使用者帳戶。就安全性來說，最好是能夠設立一套程序來確保您能輕鬆追蹤非使用中的使用者帳戶，並停用或移除這些帳戶，以避免可能的安全性漏洞。Inactive Users Tracker 是 NetWrix Corporation 推出的免費軟體公用程式，提供了簡單的方法來執行這些作業。
此工具會定期掃描您的 Active Directory® 網域以尋找非使用中的使用者，然後將非使用中帳戶的清單以電子郵件的方式寄到您選定的系統管理電子郵件地址。您可以指定要管理的網域，以及哪些帳戶具備掃描 Active Directory 中非使用中帳戶的權限。此外，您可以設定帳戶必須保持非使用中狀態多少天之後，才會「標記為」非使用中，並加入電子郵件通知。當然，您也可以排定程序要在何時開始。
除此之外，您只要設定 SMTP 伺服器將轉送通知電子郵件到系統管理位址，指定是否要公用程式使用名稱篩選器來篩選非使用中的使用者帳戶就行了 — 例如，您所有的顧問帳戶可能都以「c_」開頭。
本產品也提供商用版本 (報價會針對採購產品的客戶而量身訂製)。這個版本可讓您自訂傳送給使用者的電子郵件訊息，支援自動停用非使用中的使用者帳戶，且包含技術支援。
價格： 免費
Inactive Users Tracker notifies you about inactive users
Inactive Users Tracker notifies you about inactive users

增強電子郵件通訊
Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
一方面，在訴訟和規章日益興盛的今日，您的組織必須保護好電子郵件通訊。另一方面，始終如一的通訊與品牌認知能幫助您的組織與通訊對象打造出更密切的關係。Exclaimer Mail Utilities 2007 的設計是在 Exchange Server 2007 部署下運作，可協助您兼顧這兩個目標。
此應用程式提供三項基礎功能來統一及保護組織的電子郵件通訊：免責聲明、商標和簽章。此外，您也可以加入對抗垃圾郵件與病毒的模組。
在免責聲明部分，藉由在組織發出的每封郵件中加入自訂訊息 (顯示在郵件本文之後或之前) Exclaimer Mail Utilities 可協助您降低訴訟的風險，促進法規的遵循，例如美國健康保險流通與責任法案 (Health Insurance Portability and Accountability Act，HIPAA) 和 230 條例 (Circular 230)。在商標部分，您可以輕鬆地在每封要傳送的郵件中加入圖像與標籤，以確保與用戶端群之間的通訊都維持一貫的風格。至於在簽章部分，您可以確認每封郵件都會自動套用簽章，無論是從智慧型裝置、Microsoft® Outlook® Web Access 或標準 Outlook 用戶端發送都可以。簽章可從資料動態產生，而這些資料您可能早已存放在 Active Directory 樹狀目錄中。您可以設定工具來根據幾個要素自訂這些簽章，包括電子郵件要傳送給內部或外部人員，寄件者是誰，還有郵件主旨包含什麼內容。
Exclaimer Mail Utilities 2007 的售價是以使用者來計算，從每 25 位使用者 $245 美元起，視使用者人數增加而予以折扣。此外，反垃圾郵件模組、防毒模組和技術支援都是在基本成本上額外計價。第一年提供義務性質的技術支援，之後是每 25 位使用者 $55 美元。基於效能因素，執行 Mail Utilities 的電腦必須執行 64 位元 Windows Server® 2003 或 Windows Server 2008。如果您覺得這個產品不錯，但您的電腦仍執行 Exchange Server 2003，也可以選用另一個版本。
價格： 每 25 位使用者 $245 美元起。

書評
How to Cheat at Securing SQL Server 2005
syngress.com
身為 IT 專業人員，我們都了解安全性是基礎結構實作的首要考量。只要想想今日的網路環境如何四通八達，還有系統中保存了多少機密資訊就不難了解。而這對於 SQL Server® 執行個體更是如此，因為它們往往是機密資訊的集中化來源。此外，現在的法規強調保障個人隱私權，例如沙賓法案 (Sarbanes-Oxley) 和 HIPAA，萬一發生什麼事使得資料外洩，很可能會造成您在法律與財務方面相當大的困擾。
提到確保 SQL Server 2005 執行個體的安全性，您可以參考一下《How to Cheat at Securing SQL Server 2005》。標題可能容易讓人誤會 — 本書並非提供「投機取巧」的方法，而是提供逐步的參考資訊來鎖定您的 SQL Server 2005 部署。書中的策略是遵循「最低存取權」的基本原則，也就是只允許滿足業務需求的權限，其他則一律關閉。
在導言之後，本書就開始討論如何使用介面區組態工具來縮小 SQL Server 2005 執行個體的介面區。您會讀到一些實用的資訊，例如安裝 SQL Server 2005 時，預設服務的預設啟動 (手動、自動或停用) 選項。在下一章節中，您會學到各種 SQL Server 角色，還有這些角色可以如何大幅簡化系統管理工作。譬如說，書中教導您如何將角色繫結到 Windows® 群組。如此一來，當您新增使用者到群組時，使用者便會自動被授予權限來存取該角色可用的資源。
有關驗證與細微存取的章節談到了 Windows 和 SQL Server 登入以及兩者的優缺點。另外本章也說明了與驗證相關的 Microsoft 最佳作法。這本書接著將話題轉向授權，其中涵蓋了有哪些可用選項讓您微調使用能夠對執行個體執行的作業 (或者以資料庫的術語來說，就是原則的安全性實體權限)。您還會學到像是專用管理員連接 (DAC) 的功能，它提供僅限系統管理員的本機連線，可讓您在查詢或程序耗盡所有資源而使得伺服器停止回應時，連上執行個體。這個功能很有用，可補充 SQL Server 2005 之前版本的不足。
在 SQL Server 2005 中，結構描述與使用者被區隔成不同實體。有一章專門說明如何透過 T-SQL 與 SQL Server Management Studio 來定義、更新和刪除結構描述。在這一節中，您也會看到一些不錯的技巧，例如學習如何在 SQL Server 2005 中，除非是要建立新的結構描述，否則不使用 sp_adduser 預存程序來建立新使用者。而是改用 CREATE USER T-SQL 陳述式來建立使用者。
當然，密碼是確保安裝安全性的另一項重要因素，下一章詳盡地討論密碼原則，旨在協助您取得各個帳戶間一致的安全性層級。作者探討了各種不同的實作案例，引導您選擇最適合您的環境的最佳原則與原則類型。接下來則介紹資料定義語言 (DDL) 觸發程序，還有這些觸發程序如何預防非計畫中的結構變更，並提供伺服器登入變更的稽核線索。
在下一章中，您會找到 SQL Server 2005 加密資料與結構描述的很多方法，以便保護機密資訊的安全性。最後，本書提供 SQL Reporting Services、SQL Analysis Services 及 SQL Server Integration Services (SSIS) 的概觀，其中包含與安全性相關的最佳作法指引。書中的兩個附錄也非常有用，能深入剖析在 SQL Server 2005 方面如何保障並實作群組原則和 Active Directory。
我發現本書有兩個編排巧思特別有幫助。首先是各章都包含一節＜Solutions Fast Track＞，針對章節中涵蓋的重點提供逐條提示的功能、事實和最佳作法。第二個是＜Frequently Asked Questions＞一節，提供進行 SQL Server 2005 執行個體的系統管理時，相關問題的快速解答。若您正在尋找一種捷徑，從安全性的角度來加速 SQL Server 2005 系統管理工作，不妨考慮在您的參考書書架上添購這本《How to Cheat at Securing SQL Server 2005》。
價格： 電子書 $19.98 美元，印刷書 $49.95 美元

強而有力的畫面擷取功能
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
畫面擷取是逐步記錄使用者指示、呈現應用程式中出現的錯誤訊息，或是構成快速的精彩簡報一種有效的方式。當然，Windows 有自己內建的擷取功能 (PrtScr 用來擷取全螢幕，Alt-PrtScr 用來專門擷取使用中視窗)。但是，作業系統內建的功能有限。若您需要更精細地控制擷取內容與擷取時機，或想要擷取影片播放中的畫面，肯定得參考許多協力廠商為您提供的這類畫面擷取公用程式。Wisdom Software 所推出的 ScreenHunter Pro 就是這樣的一種工具。這個花費不多的公用程式具有一些實用功能，更能您根據特定需求來訂製畫面擷取程序。
UI 很單純，您只要挑選想要的畫面擷取部分，然後使用恰如其名的 [來源 (From)] 和 [目標 (To)] 索引標籤將擷取內容導向要存放的位置。在擷取內容部分，應用程式可讓您抓取可調整或固定的矩形區域、特定物件或視窗、使用中視窗、使用中視窗的特定部位、全螢幕、DirectX® 或螢幕保護程式來源、影片播放，或是更複雜的形狀 (手繪形狀、橢圓形或您所定義的多邊形)。您也可以同時擷取多個視窗物件或訊息方塊 (這特別適合用來只掠取使用中應用程式與其對話方塊或其他視窗介面)。接著您可以將畫面擷取傾印到剪貼簿、指定的檢視器或編輯器、印表機或是檔案。您甚至可以選擇將它傳送到電子郵件地址。
擷取的畫面可以依照各種影像品質儲存成 BMP、PNG、JPEG 或 TIFF 檔案。此外，您可以讓應用程式將擷取內容自動縮放成特定大小、加入框線，或是在擷取內容上加入浮水印，藉此減輕必須對影像執行的「後製」工作量。您甚至可以設定應用程式於指定間隔自動擷取畫面，這樣能實際記錄機器上的各種活動。
另一項不錯的功能，就是 ScreenHunter Pro 支援自動捲動功能，舉例來說，它可讓您擷取一長篇網頁，其中也包含超出螢幕可檢視範圍的可檢視區域。就像許多 IT 專業人員一樣，我也使用多個顯示器，因此我喜歡多個顯示器擷取支援，只要一個擷取動作就可讓您抓取多個畫面上的所有資訊。
這個公用程式甚至還包含內建的影像編輯器，可讓您在同一個應用程式環境中修改您的影像。如果您不需要某些更進階的功能 — 例如自動傳送電子郵件、排程擷取、浮水印及多個顯示器擷取 — 您可能對便宜一點的 ScreenHunter Plus 版本較感興趣。另外也有免費的精簡版本。
價格： ScreenHunter Pro 為 $29.95 美元
ScreenHunter Pro lets you specify when and what you capture
ScreenHunter Pro lets you specify when and what you capture

Greg Steen


 Exchange 佇列問題與解答: Exchange 2007 SP1 部署
Exchange 佇列問題與解答
Exchange 2007 SP1 部署
Nino Bilic

問：我想知道 Exchange Server 2007 SP1 是否只能用於 64 位元版本？如果也可用於 32 位元版本，那麼生產環境是否支援該版本？
答：就這一點而言，Exchange 2007 的原始 (RTM) 和 SP1 版本並沒有什麼不同。SP1 在 32 位元與 64 位元兩種版本中都可用。但是請務必記住，就 RTM 版本而言，生產環境中已安裝的伺服器角色只支援 64 位元版本。不過您可以使用 32 位元 SP1 版本來執行各種 /prepare 安裝參數，然後像使用 RTM 一樣來管理您的 64 位元伺服器。

問：我是不是得先完成 Exchange 2007 RTM 版本的完整安裝，接著套用 SP1 才能使用 SP1 伺服器？
答：這是 Exchange 2007 SP1 的特色，與舊版 Exchange 的 Service Pack 大不相同。取得 SP1 版本時，基本上就是取得 RTM 版本與匯入其中的 SP1，這表示您不需要使用 RTM DVD 來執行全新的 Exchange 2007 SP1 安裝。
因此，若要安裝新的 Exchange 2007 SP1 伺服器，您只需要 SP1 版本。舉例來說，即使您是要將第一部 Exchange 2007 加入 Exchange Server 2003 組織中，您還是可以立即開始使用 SP1。
問：我有一部在 Windows Server® 2003 上執行 Exchange 2007 RTM 的伺服器，現在要在機器上安裝 Exchange 2007 SP1。因為 Microsoft 說 Windows Server 2008 可支援 Exchange 2007 SP1，因此我打算稍後就地升級到 Windows Server 2008。您覺得這個計畫怎麼樣？
答：很遺憾的是這行不通。在已安裝 Exchange 2007 RTM 或 SP1 的情況下，並不支援從 Windows Server 2003 就地升級到 Windows Server 2008。這是基於多種技術方面的原因，您必須知道，如果執行這種就地升級，Exchange 安裝將會中斷。
如需詳細資訊，請參閱＜不可能的任務：從 Windows Server 2003 就地升級 Microsoft® Exchange Server 2007 到 Windows Server 2008＞，網址是 msexchangeteam.com/archive/2007/10/04/447188.aspx。

問：我有幾部實驗室伺服器從未輸入產品識別碼。因此，當我啟動 Exchange 管理主控台時，出現還剩下「0 天」的警告。有沒有辦法不輸入這些伺服器的產品識別碼，就升級到 Exchange 2007 SP1？
答：有的。Exchange 2007 SP1 安裝程式 (請參閱螢幕擷取畫面) 無法檢查已安裝伺服器的試用期長度。在此案例中，並不涉及升級封鎖。

問：我已經在信箱伺服器上安裝 Exchange 2007 SP1。現在我想要在這部伺服器上新增 Client Access server role。我應該使用 Exchange 2007 RTM 還是新的 Exchange 2007 SP1 版本？
答：您必須在套用 Exchange 2007 SP1 之後，使用 Exchange 2007 SP1 版本來安裝額外的伺服器角色。如前所述，Exchange 2007 SP1 是一個完整的產品，其中包含執行 Exchange 2007 所需的所有檔案，一旦成功安裝 SP1 之後，就不再需要 Exchange 2007 RTM 版本。
當然，如果您要升級到 Exchange 2007 SP1 的伺服器上有多個伺服器角色，那麼套用 SP1 便會自動升級所有已安裝的角色。您無法讓 SP1 只套用到相同實體伺服器上的某些角色。

問：我的 Exchange 組織有多部 Exchange 2007 伺服器，而且伺服器角色分散在其中數個伺服器上。我應該先升級哪些伺服器角色？
答：採取任何行動之前，您應該先下載並閱讀 Exchange 2007 SP1 版本資訊 (go.microsoft.com/fwlink/?LinkId=112364)，因為其中包含在現有安裝中套用 SP1 的重要資訊。
不過為了直接回應您的疑問，以下節錄自 SP1 版本資訊可以解答這個問題：

建議您在升級執行 Client Access、Unified Messaging、Hub Transport 或 Edge Transport server role 之後，再升級執行 Mailbox server role 的伺服器。如果您依照此順序升級伺服器，就可以避免可能發生的服務中斷 (根據這種順序升級角色，可確保「面對」信箱功能的伺服器能夠與信箱伺服器通訊且不被中斷，而不會在嘗試與更多功能的後端伺服器通訊時，遇到問題)。我們也建議您先升級位於網際網路面向站台中的 Client Access Server，然後再升級位於無法從網際網路存取的站台中的 Client Access Server。
如果您在 Exchange 組織中執行 Edge Transport server role，並建立 Edge 訂閱，那麼參與 EdgeSync 程序的所有 Transport Server 都必須執行相同的 Exchange 2007 版本。您必須升級訂閱 Edge Transport Server 的 Active Directory® 站台中的所有已訂閱 Edge Transport Server 和所有 Hub Transport Server；而且您必須在第一次升級到 Exchange 2007 SP1 (參與 Edge 訂閱程序的傳輸伺服器的 Exchange 2007 SP1) 的 15 天內這麼做。」

問：我將 ForefrontTM Security for Exchange Server 安裝在 Exchange 2007 RTM 伺服器上。我在升級到 Exchange 2007 SP1 之前，是否需要採取什麼特別動作？
答：RTM 版本的 Forefront Security for Exchange Server 與 Exchange 2007 SP1 不相容。升級之前您必須先移除 Forefront Security for Exchange Server，或是將它升級到更新版本。SP1 版本資訊會提供更多詳細資訊。
而且附帶一提，Exchange 2007 SP1 安裝程式有一項新的必要條件檢查，在上述情況下想要進行升級時，會提出警告。

問：我安裝了 Exchange 2007 RTM，之後又安裝 RTM 彙總套件更新 (Rollup Update，RU)。在套用 Exchange 2007 SP1 之前，必須先移除 RU 嗎？
答：您不需要在安裝 Exchange 2007 SP1 之前先手動移除任何彙總套件更新。Exchange 2007 SP1 安裝程式會負責去除在套用 SP1 機器之前必須先移除的更新。

Nino Bilic 是 Exchange Server 的技術支援專案經理。他靠著在「質量效應」(Mass Effect) 遊戲中探索銀河系和打擊壞蛋而致富。


 公用程式焦點: SharePoint 容量規劃
公用程式焦點
SharePoint 容量規劃
Peter Skjøtt Larsen and Satish Mathew

規劃大型的 Microsoft® Windows® SharePoint® Services (WSS) 和 Microsoft Office SharePoint Server (MOSS) 安裝作業，是一件相當複雜的工作。您必須參考許多因素，決定最能發揮成本效益的拓樸、硬體和頻寬需求。同時還要根據系統的使用方式，考量許多設定選項。系統管理員和規劃人員常常僅憑經驗法則幫助他們調整系統大小。
可喜的是，Microsoft 發行了第二代的 Microsoft System Center Capacity Planner (SCCP) 2007，這個一般用途的工具結合了一個適用各種應用程式的模型，與一個可以預估它們在進行特定部署作業時之行為的模擬器。這項產品引進了新的 SharePoint Capacity Planning Tool，它在這個引擎當中加入兩個 WSS 3.0 和 MOSS 2007 用的模型。
您可以從 Microsoft 下載中心 (網址為 microsoft.com/systemcenter/sccp/default.mspx) 免費下載 SharePoint Capacity Planning Tool 和 SCCP 2007。
SharePoint Capacity Planning Tool 是藉著編譯您對預期流量和運作狀況等問題的解答，來收集貴公司的需求。在產生初步設計時，精靈會提示您輸入有關您的結構與預計 SharePoint 需求等相關資訊，其中包括使用者的數量和類型 (匿名使用者相對於經過驗證的使用者)、網路參數、硬體設定、使用模式 (例如，發佈或共同作業)、儲存需求，以及索引和查詢需求。
Results of a simulation in the SharePoint Capacity Planning Tool
Results of a simulation in the SharePoint Capacity Planning Tool
這時候工具便會產生一個建議的基準拓樸，採用專門針對您的設定所取的名稱。接下來您再針對建議使用的拓樸執行負載和流量模擬，看看提議的安裝是否能在各種情況下運作。
初始拓樸可以利用模型編輯器加以修改，接著再執行假設案例，模擬流量成長、企業分公司擴張、新增硬體以及加大頻寛所造成的影響。根據螢幕擷取畫面顯示，這項模擬作業會產生預估的伺服器負載和使用者經驗報告，讓您根據成本、效能和可用硬體等參數，開始將設定最佳化。您可以將詳細報告或摘要報告匯出到 Excel® 試算表，並且將拓樸圖表匯出到 Visio® 檔。
SharePoint Capacity Planning Tool 可讓您測試各種環境，達到適當的開始設定，以減輕移轉部署的負擔。您也可以塑造現有拓樸的模型，並且執行各種假設案例，因此這個工具也很適合用來探索現有部署的潛在變更。

Peter Skjøtt Larsen 是 Microsoft Solution Accelerator 小組的資深產品經理。他進入 Microsoft 至今已四年的時間，負責 UNIX 移轉及通訊與共同作業。
Satish Mathew 是 Microsoft Solution Accelerator 小組的程式經理。他進入 Microsoft 至今將已將近五年的時間，最初是在 Windows PowerShell 小組工作，隨後轉調至目前的小組。


 Sharepoint 內幕: 建置 SharePoint 基礎結構
Sharepoint 內幕
建置 SharePoint 基礎結構
Pav Cherny
下載本文程式碼: SharePoint2008_05.exe (412KB)

正如電子郵件訊息一改商務通訊的面貌，以網路為主的共同作業也改變了你我合作及共享資訊的方式。而 SharePoint 技術正是這樣的一個好例子。透過 Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server
(MOSS) 2007，您可以建立小組網站、入口網站、網站內容管理解決方案、文件庫，以及搜尋中心，還有 2007 Microsoft® Office System 整合、XML 式表單，工作流程、行動支援等等更是不在話下。
然而，著手使用 SharePoint® 不是那麼容易。除了用詞容易令人混淆外，系統架構也可能很複雜，而且 SharePoint 需要您處理的元件不少，包括 IIS、Microsoft .NET Framework、SQL Server®，可能還有其他技術，例如商務智慧、InfoPath® Forms Services、Rights Management Services (RMS)、Exchange Server，以及 ForefrontTM Security。
建立 SharePoint 解決方案的方法繁多，無論是透過內建使用者介面或是透過程式設計，您可能很快會身陷整合和自訂兩難之中。另外，當 SharePoint 應用程式無法運作時，要疑難排解也可能很複雜。您通常需要有應用程式開發人員的腦袋，才能了解當中牽涉的元件，以及它們互動的方式。面臨所有這些挑戰，要從何著手來建置一個穩固、可調整且易管理的 SharePoint 基礎結構呢？
在本專欄中，我將以高階架構的觀點向您說明如何從基礎建置著手進行，然後深入探討 WSS 的部署，包括非常基本的商標自訂。使用 WSS 3.0 的「自助網站管理」功能，您將學會如何將建立和管理 SharePoint 網站的權限委派給個別使用者，並同時對 SharePoint 基礎結構保有集中化管理的控制能力。
先看一下 SharePoint 架構，就不難了解實作富有彈性和可調整之基礎結構所需的部署和設定步驟。所以讓我們約略談一下相依性，之後再切入部署 WSS 3.0 的主題。如需詳細的部署指示，請參閱附隨的參考資料。您可以在 TechNet Magazine 網站的程式碼下載區找到這份資料，網址是 technetmagazine.com。

SharePoint 架構
透過 SharePoint，以系統架構設計師本位思考技術確實有助益。無須了解枝微末節，只要熟悉 SharePoint 架構相關的整體相依性，解決方案就在不遠處，因為您可以預測出需要進行哪些設定，以及進行這些設定的原因。
SharePoint 是一項提供 Web 應用程式和網站的技術。它是以 IIS 為基礎的網站解決方案，透過 ASP.NET 與 IIS 整合，並仰賴 SQL Server 資料庫後端來存放設定資料和內容。簡而言之，SharePoint 的核心結合了三種不同的架構 (IIS、.NET 和 SQL Server)，如 [圖 1] 所示。
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
別讓上圖給嚇到了，元件數目龐大，架構剛開始看起來可能很讓人吃不消。但是所有這些元件都能融合到邏輯架構中，方便在進行有系統地分析時，深入洞察元件的相依性。
如前所述，SharePoint 仰賴 IIS 和 ASP.NET 來處理 HTTP 要求和回應。標準 IIS 元件，例如 HTTP 核心模式驅動程式 (http.sys) 和工作者處理序 (w3wp.exe)，會執行要求初始的佇列和路由作業，直到它們抵達 ASP.NET ISAPI 篩選器 (aspnet_isapi.dll)。安裝 .NET Framework 時，安裝常式會在 IIS Metabase (C:\Windows\System32\Inetsrv\metabase.xml) 中註冊 aspnet_isapi.dll，如下所示：
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
IIS 一載入 ASP.NET ISAPI 篩選器，就可以將對某網站的所有傳入要求傳送到 ASP.NET，這很重要，因為 SharePoint 最後必須透過 ASP.NET 接收這些要求。為了達成這個目的，SharePoint 會新增萬用字元應用程式對應，將所有傳入要求 (不管檔案名稱副檔名) 路由到 ASP.NET ISAPI 篩選器，藉此擴充選定網站的設定。
您可以在使用基本安裝選項安裝 WSS 3.0 之後，在 IIS 管理員裡面看到結果。WSS 安裝常式會停用伺服器上現有的預設 IIS 網站，並在有定義 ASP.NET 萬用字元應用程式對應的連接埠 80 上建立一個新的預設網站，如 [圖 2] 所示。
Figure 2 Wildcard application map for ASP.NET ISAPI filter
Figure 2 Wildcard application map for ASP.NET ISAPI filter
為了讓 ASP.NET 轉而將要求傳送給 SharePoint，SharePoint 也必須透過自訂 HttpApplication 物件來擴充 HTTP 要求管線，這個物件是透過 Microsoft.SharePoint 組件中一個叫做 SPHttpApplication 的類別實作而成的。SharePoint 會在 ASP.NET 應用程式檔案 (global.asax) 中定義這個自訂的應用程式物件，您可以到 SharePoint 擴充的網站，從根資料夾裡面的檔案系統中找到這個檔案。下面的程式碼列出了這種 global.asax 檔案的內容：
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET 會動態地剖析和編譯這個檔案，以產生 SharePoint 應用程式物件。
對於每個接收到的要求，ASP.NET 都會觸發一連串 Web 應用程式可以處理的事件，像是 BeginRequest、AuthenticateRequest、ProcessRequest 和 EndRequest。事件處理的細節已超出部署和管理 SharePoint 的討論範圍，不過您應該知道，除了 global.asax 中指定的 SPHttpApplication 之外，SharePoint 也會為網站實作 web.config 檔案中定義的自訂 HTTP 處理常式和模組。例如，SharePoint 會根據 SPRequestModule 類別使用 HTTP 模組，將它註冊成先於標準 ASP.NET 模組的第一個 HTTP 模組。SPRequestModule 會初始化 SharePoint 常式環境，例如透過 ASP.NET 來註冊 SPVirtualPathProvider 元件。SPRequestModule 是供 SharePoint 內部使用，但是 SharePoint 解決方案開發人員可以修改 web.config 檔案來註冊其他元件，像是自訂 HTTP 處理常式和模組。透過自訂和標準 HTTP 模組，SharePoint 便能在利用 ASP.NET 的同時，仍舊對 SharePoint 應用程式的所有要求保持高度的控制能力。
要注意的是，當使用 SharePoint 3.0 管理中心網站建立 Web 應用程式時，WSS 會新增 ASP.NET 萬用字元應用程式對應到選定的 IIS 網站中，並在網站的根資料夾中建立 global.asax 和 web.config 檔案。每個 Web 應用程式都會使用自己一套頂層 global.asax 和 web.config 檔案。
為了處理要求並傳回有意義的資訊給瀏覽器，WSS 3.0 和 MOSS 2007 有賴於標準 ASP.NET 頁面剖析器，它會編譯要求的 ASP.NET 網頁，或是在不編譯的模式下處理它們。但是 SharePoint 傳遞給 ASP.NET 的 ASP.NET 網頁不一定是位在它們應該存在的地方。比方說，您在 SharePoint 擴充的網站 (例如 SharePoint 3.0 管理中心網站) 的根資料夾中，將找不到 default.aspx 檔案，反而是在顯示該網站的首頁時開啟 default.aspx。將環境視覺化的正是 SPVirtualPathProvider 元件，它會從本機檔案系統或 SQL Server 內容資料庫載入頁面內容，然後把它當作虛擬檔案傳遞給 ASP.NET 頁面剖析器。對於管理中心網站，SharePoint 會從 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin 資料夾載入 default.aspx。
首頁，以及大多數其他 SharePoint 網站網頁，都是連結到 ASP.NET 主版網頁 (default.master)，這個主版頁面實作有功能表和巡覽控制的通用配置。Default.master 是位於 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global 資料夾中，而且包含了其他內容網頁已命名的預留位置，這些網頁也位在本機檔案系統或 SQL Server 內容資料庫中。重點是，當您在網頁瀏覽器開啟 SharePoint 網站時，您實際上是從一組內容頁面集合查看資訊，這些內容頁面不一定是位在本機 Web 伺服器上，而且是根據主版頁面內定義的配置排列的。
其中的通則是，未經修改的頁面 (或以 SharePoint 的用語：未自訂的頁面) 在每部 SharePoint 伺服器的本機檔案系統上是以頁面範本的形式存在，而自訂頁面則會寫入內容資料庫中，以便讓 Web 伺服陣列當中的所有 SharePoint 伺服器都能夠存取相同一組的頁面 (見 [圖 3])。根據假設，Web 伺服陣列中所有伺服器和網站之間的未自訂頁面應該都是一樣的。不過，假如您使用 Office SharePoint Designer 2007 在 SharePoint 網站內自訂內容頁面或主版頁面，SharePoint 會自動將自訂的頁面儲存在內容資料庫中。
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
除了自訂頁面和其他網站內容之外，SharePoint 也會將設定資料儲存在 SQL Server 資料庫中。SharePoint 將設定資料與內容相區隔是因為設定資料在本質上是通用的，而內容則是專用於個別 Web 應用程式和網站集合。因此，Web 伺服陣列只能有一個設定資料庫，但是它可以有多個內容資料庫。
Web 伺服陣列當中所有的 WSS 伺服器都是使用相同的設定資料庫來共用中繼資料、設定值，以及 Web 伺服陣列中每個經過 SharePoint 擴充的 IIS 網站的相關資訊。另一方面說來，個別的 Web 應用程式則可與一或多個內容資料庫相關聯 (但是每個內容資料庫都只能與一個 Web 應用程式相關聯)。
IIS 網站、Web 應用程式、網站集合、網站與內容資料庫之間的關係可能很容易令人混淆。照 SharePoint 的用語，Web 應用程式一詞指的是 SharePoint 擴充的 IIS 網站。Web 應用程式可包含多個網站集合，而且每個網站集合都可以再包含共用相同設定值的頂層網站和子層網站。
此外，建立多個網站集合也可讓您將網站集合的系統管理作業委派給不同的使用者和群組。單一網站集合並不能橫跨多個內容資料庫，但是一個 Web 應用程式可以使用多個網站集合的多個內容資料庫，提高在其他 SharePoint 網站產生大量資料庫活動的大型網站的延展性，並減輕其效能衝擊。不過，將每個 SharePoint 網站放在它自己的網站集合裡面並不是個好主意，因為這種部署方式會限制跨網站的功能。
WSS 3.0 並不支援在多個網站集合間搜尋內容。這類的搜尋作業需要有 MOSS 2007 或 Microsoft Search Server 2008 才能進行。例如，您可以為 建立一個 Web 應用程式和頂層網站，而網站集合管理員之後可以使用 SharePoint 使用者介面建立子層網站，例如 http://contoso/info 和 http://contoso/events。所有這些網站都存在於相同的內容資料庫，因為它們都屬於相同的網站集合。
身為伺服器陣列管理員，您還可以使用受管理的路徑 (例如 /sites)，然後在 SharePoint 3.0 管理中心定義額外的網站集合，例如 http://contoso/sites/IT 和 http://contoso/sites/HR。這三種網站集合 (http://contoso、http://contoso/sites/IT 和 http://contoso/sites/HR) 都可以有不同的網站集合管理員、設定值和內容資料庫，但是它們全都還是透過相同的 IIS 網站 (http://contoso) 存取，而且使用相同的 Web 應用程式的應用程式集區識別。
不用說，其他還有很多相關的細節，但是 IIS、ASP.NET 與 SQL Server 之間的這種關係對於了解熟悉 SharePoint 來說尤其重要。如果您有興趣深入了解 SharePoint 架構，我建議您閱讀 Ted Pattison 在《MSDN® Magazine》發表的＜探索 SharePoint Services 中重大的開發人員改進功能＞一文，網址是 msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview。

SharePoint 基礎結構要素
現在讓我們將之前概括討論的架構，轉化成富有彈性的 SharePoint 基礎結構。您肯定已經注意到，我們需要有 Windows Server®、IIS、.NET Framework 3.0 (用於 ASP.NET 和 Windows® Workflow Foundation)、WSS 3.0 或 MOSS 2007，以及 SQL Server。雖然您可以預期使用 Windows Server 2008 上的 IIS 7.0，但針對本文的目的，我們會使用 Windows Server 2003 上的 IIS 6.0，因為這是在撰寫本文時最常部署的版本。我們還是繼續使用 WSS 3.0，因為初次的 SharePoint 試驗，我們並不需要 MOSS 2007 專用的功能。
要採取精簡策略的話，您可以在單一電腦上安裝 WSS 3.0 與所有必要的元件 (如 WSS 3.0 的 single computer.pdf 上所述，這可在本專欄隨附的資料取得)，這用於實驗室伺服器或小型工作群組環境就綽綽有餘。不過，如果您打算把焦點放在 SharePoint 基礎結構中的靈活度上的話，就不應該從生產環境中的獨立部署開始著手。基於可用性還有未來的延展性，最好是從多層式基礎結構開始，然後在必要時加入更多伺服器。
如果您要的是直接明瞭且富彈性的系統設定的話，[圖 4] 正說明了我建議的 SharePoint 基礎結構。它包含了兩個 SharePoint 伺服器的 Web 伺服陣列，另外還有一部執行 SQL Server 的電腦。這項設定不僅免去了 Web 伺服器上處理資料庫的負擔，也提高了可用性、延展性，更加速了系統維護的效率。請注意，您還是需要 Active Directory®，因為這是 Web 伺服陣列部署中 WSS 3.0 的軟體需求。如須逐步部署的指示說明，請參閱隨附資料裡面的 Basic SharePoint Infrastructure.pdf 檔案。
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
您在這種安排下部署 SharePoint 所用的網域帳戶必須在 Web 伺服器上具備本機系統管理員的權限。您也必須在 SQL Server 2005 中將這個帳戶加入 dbcreator 和 securityadmin 這兩個 SQL Server 角色，還有 Master 資料庫的 db_owner 資料庫角色，如 Basic SharePoint Infrastructure.pdf 中所示。您接著可以在 WSS 3.0 安裝期間使用「SharePoint 產品及技術設定精靈」為 Web 伺服器伺服陣列建立必要的設定資料庫，並為 SharePoint 3.0 管理中心網站建立內容資料庫。不然的話，SQL Server 系統管理員必須為您佈建這些資料庫，並新增 WSS 系統帳戶到 db_owner 角色。
要特別謹記在心的是，您安裝 SharePoint 所用的使用者帳戶並不是 SharePoint 用來存取管理中心網站的設定資料庫或內容資料庫的帳戶。SharePoint 反而是使用設定為 SharePoint 3.0 管理中心網站之應用程式集區識別的系統帳戶。
「SharePoint 產品及技術設定精靈」會提示您輸入帳戶資訊。為此使用專用的網域使用者帳戶是個不錯的主意，例如 CONTOSO\WssConfigAdmin。我向來的作法都是對任何稍後另外建立的 Web 應用程式，使用個別專用的使用者帳戶。對每個 Web 應用程式使用不同的應用程式集區有利於確保隔離處理序，而對每個應用程式集區使用不同的使用者帳戶將有助於維護安全性隔離。不過要注意的是，這只是其中一種方法，而且您應該比照自己的環境和商務需求來評估管理性和可能的效能衝擊。
網域系統管理員應該為您建立的另外一個重要的系統帳戶，是搜尋服務帳戶。您可以使用管理中心帳戶，但是為了提高安全性，最好是使用不具系統管理權限而且不能修改任何內容的專用搜尋帳戶，例如 CONTOSO\WssSearch。因為搜尋服務只會針對製作索引的目的編目內容，並且會將搜尋資料維持在不同的資料庫裡面，所以不用具備寫入內容資料庫的權限。
在伺服器伺服陣列中建立 Web 應用程式時，您可以建立內容資料庫與搜尋伺服器的關聯，這可隱含地新增相對應的搜尋服務帳戶到 Web 應用程式的「完整讀取」原則中。搜尋伺服器是執行 Windows SharePoint Services 搜尋服務的 SharePoint 伺服器。如果您有遵照 Basic SharePoint Infrastructure.pdf 檔案裡面的逐步指示，應該已經將兩部 Web 伺服器都設定成搜尋伺服器，這樣一來，您就可以分散編目和製作多個內容資料庫索引的負載。不過，您也可以在 Web 伺服陣列中設定專用搜尋伺服器，將它從網路負載平衡和用戶端連線排除，如此用戶端連線就不會受到編目活動的影響。

自助網站管理
有了基本的 SharePoint 基礎結構，我們就可以將網站集合和網站的系統管理作業委派給個別的部門和使用者，而不用將系統管理的控制權分散到 Active Directory、Web 伺服器伺服陣列，或 SQL Server 資料庫上。身為伺服器陣列管理員，您可與 Active Directory 和 SQL Server 系統管理員合作為您的 Web 應用程式佈建應用程式集區帳戶和內容資料庫。在這些 Web 應用程式當中，您接著可以建立網站集合，並指定網站集合管理員建立子層網站的權限。這麼一來，各部門當中的網站集合管理員不用 IT 部門太多的協助，就可以管理他們的 SharePoint 資源，如 [圖 5] 所示。
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
您也可以讓使用者在受管理的路徑 (例如 /sites 路徑，或其他您在 SharePoint 3.0 管理中心建立且包含相對路徑的受管理路徑) 建立網站集合。如果您在 Web 應用程式中啟用「自助網站管理」功能，使用者便可以在 SharePoint 使用者介面當中建立他們自己的網站集合並管理網站群組和權限。跟子層網站不同的是，網站集合並不會繼承父網站的權限。
自助網站管理並不適用於所有 SharePoint 環境，而且預設會停用。您若是啟用它，內容資料庫裡面最後可能會出現一堆不常用的網站集合。然而，這項功能確實鮮明地展示了 SharePoint 系統管理的彈性，建議您在試驗部署中試試看 (此外，SharePoint 當中還有一些通知使用者和/或系統管理員非作用中網站的選項，以便在必要時將它們移除)。您必須明確地啟用 Web 應用程式的自助網站管理功能，如隨附的資料中 Enabling Self-Service Site Management.pdf 檔案所述。

SharePoint 自訂和商標
SharePoint 資源
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services Developer Center
  • Microsoft SharePoint 產品及技術小組部落格
  • 邏輯架構元件
  • 設計伺服器伺服陣列和拓樸

此時，很自然地您會想要在 SharePoint 使用者介面中加上公司的標誌、名稱和企業識別色。不過要注意的是，這會將 SharePoint 專案帶向 ASP.NET 開發人員層級。您至少要有個開發系統，例如裝有 Microsoft Office SharePoint Designer 2007 的獨立 WSS 3.0 伺服器 (請參閱隨附資料的 SharePoint Designer Installation.pdf)，這樣一來，您就可以建立和測試自訂，而不致影響到生產環境。另外，您也應該造訪 Windows SharePoint Services Developer Center 進一步了解 SharePoint 提供的各種自訂選項，網址是 msdn2.microsoft.com/sharepoint。
雖然 SharePoint 的開發已經超出本專欄的討論範圍，還是容我指出您應該多加考量的幾個層面。SharePoint 會將自訂頁面儲存在相對應網站集合的內容資料庫中。換句話說，您在 SharePoint 網站中套用到網站頁面、應用程式頁面、主版頁面、樣式表等等的任何自訂，只會在網站集合或網站層級套用。這對於想要使用 SharePoint Designer 2007 調整網站外觀的個別網站集合管理員來說是一大福音，但對於想要在 Web 伺服陣列的所有 Web 應用程式、網站集合和網站間強制企業識別的伺服陣列管理員而言，就沒什麼好處了。
您可以根據標準 SharePoint 佈景主題或網站定義的複本，來建立自訂網站佈景主題或自訂網站定義。您也可以建立自訂主版頁面，並將它們新增到主版頁面圖庫中。不過，如果啟用自助網站管理的話，這些選項就沒有一個能夠強制通用商標，因為具備建立網站集合或網站權限的使用者仍舊可以選擇使用不顯示企業識別的標準網站範本。
通用商標會要求您替換預設的 SharePoint 元件，以便改用您的自訂元件。開發人員在不修改原始檔案的情況下，需要大費周章來完成這項作業。其中一個方法是在 IIS 管理員中變更虛擬目錄的設定，把它們指向內含自訂檔案的新資料夾。另外一個方法是實作自訂 HTTP 模組或 ISAPI 篩選器，重寫 URL 以便將對特定預設頁面的要求重新導向到自訂版本。

結論
我把重點集中在使用 WSS 3.0 建立 SharePoint 基礎結構的基本知識，但並沒有探討其他功能，像是工作流程、問卷、訊息整合和防毒，也沒有討論 MOSS 2007 特定的功能，例如入口網站、網站目錄和商務資料目錄。文中也只談到在 SharePoint 內自訂網站系統管理和公司商標的皮毛。您可以透過在 Visual Studio® 中程式設計自訂應用程式的方式，進一步利用 WSS 3.0 發揮自訂。
如果您加入更多 Web 伺服器或資料庫伺服器，整個基礎結構將可穩健地應付未來的成長。試驗推出幾項自訂，讓使用者建立個別的網站，並大致熟悉 SharePoint。這麼一來，您就可以建立讓使用者採納的核心元件，還有相關的軟硬體，這些元件的彈性將可靈活地配合各種變動，並作為完整生產首展的基石。

Pav Cherny 是 IT 專家兼作者，專攻 Microsoft 共同作業與整合通訊技術。他的出版品包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。Pav 是 Biblioso Corporation 的總裁。


 Windows PowerShell: 自動化目錄管理
Windows PowerShell
自動化目錄管理
Don Jones

在推出第一版 Windows PowerShell 時，最背的其中一件事就是時間限制。Windows PowerShell 小組是在一定程度的壓力下推出產品 (它影響到另一個正準備發表的小產品，稱為 Exchange Server 2007)，而 Active
Directory 小組當時手邊還有很多工作 (另一個稱為 Windows Server® 2008 的小產品也在進行中)。因此 Windows PowerShell 推出了不怎麼樣的 Active Directory® 管理功能。
更明確的說，Windows PowerShell® 並非完全缺乏 Active Directory 功能。事實上，Windows PowerShell 小組在最後一刻進了最大努力，將 Active Directory 服務介面 (ADSI) 的完善支援加入產品中，VBScript 使用者現在都很熟悉這項適合編寫指令碼的技術。

ADSI 之道
ADSI 的運作方式與 Windows® Management Instrumentation (WMI) 類似。您發出使用特殊語法撰寫的查詢，此查詢會傳送到遠端電腦 (例如網域控制站)，接著開始執行。查詢的結果就是 Active Directory 物件或物件集合 (例如使用者或群組)，然後您取得該物件的參考供您之後使用。您可以修改物件屬性或執行方法來儲存變更、建立新物件、刪除物件等等。譬如說，若要建立使用者，您可查詢使用者所屬的組織單位 (OU) 或容器。您取回的物件有個 Create 方法，可用來建立使用者。
基本上，在 Windows PowerShell 中使用 ADSI 顯得簡單又直接。舉例來說，以下命令會擷取使用者並顯示其 Company 屬性：
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
您可以將使用者輸送到 Get-Member 來查看屬性與方法。可惜的是，Windows PowerShell 1.0 在實作這些目錄物件方面並不確實。如 [圖 1] 所示，命令介面並未列舉物件的目錄屬性，也未顯示物件方法 — 例如我剛才使用的 Get 方法。
Figure 1 Piping the user to Get-Member to see its properties
Figure 1 Piping the user to Get-Member to see its properties
這項支援功能在 Windows PowerShell 2.0 的 Community Technology Preview (CTP) 中獲得些許改善，不過成效不大。重要的是，底層的 Microsoft® .NET Framework 並沒有讓系統管理員很容易找到所需的功能 — 畢竟，Framework 原本是專為開發人員所設計的。另一個問題是 Windows PowerShell 小組已經盡力而為，更進一步的 Active Directory 支援必須來自最了解目錄的人，也就是 Active Directory 小組。我確信會有這麼一天 — 畢竟 Windows PowerShell 還是很年輕的產品。但是您當下該如何應付這些問題呢？
您可能還記得，我在這篇 2007 年 6 月份的專欄中討論過使用 Windows PowerShell 隨附的 ADSI 技術 (technetmagazine.com/issues/2007/06/PowerShell)。如需有關該「原生」技術的詳細資訊，建議您回頭閱讀那篇專欄。在本期專欄中，我要示範一些其他方法。

豐富的生態系統
Windows PowerShell 架構設計師 Jeffrey Snover 常提到 Windows PowerShell 周圍的豐富生態系統。這只意味著，產品小組成功讓任何人 (不僅是 Microsoft 內部的程式設計師) 都能延伸 Windows PowerShell 的功能。有一些公司已經開始這麼做，這些公司建立原生 Windows PowerShell 指令程式來讓您從命令列管理這些公司的產品 — VMWare、IBM、Citrix 及 Foundry 都是其中一些主要公司。
Quest Software 可說是這種豐富生態系統當中我最津津樂道的範例之一。這家公司提供一組專為 Active Directory 設計的非營利免費指令程式。您可以從 quest.com/powershell 下載這些指令程式。他們也提供 PowerGUI (powergui.org)，這是一個非營利的免費圖形化 UI，以 Windows PowerShell 為基礎針對還沒有準備好全面採用命令列的人而設計的。PowerGUI 讓您更容易學習如何使用 Active Directory 管理指令程式。相信我 — 您肯定會愛不釋手。這些指令程式提供輕鬆又有效的方式來管理 Active Directory，可說是前所未見 (如果您希望進一步了解 PowerGUI，PowerGUI 其實已經隨附 2008 年 1 月份的《工具箱》專欄中，網址是 technetmagazine.com/issues/2008/01/Toolbox)。

Windows PowerShell 之道
Windows PowerShell 運作的方式就是完全使用程式指令來進行。您不必使用傳統風格的指令碼或花俏的程式設計物件。以下是整個宇宙裡面我最喜歡的單行指令碼。這是單一行的命令列，可匯入 CSV 檔案並使用其中的資訊來建立幾十個或數百個新的 Active Directory 使用者：
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
這行命令的確很長，但也出乎意料的有用。它是以 Import-CSV 開頭，這個原生命令介面指令程式的工作只是讀取 CSV 檔案並傳回物件。CSV 檔案中的每一行都是單一物件，CSV 檔案中的欄會變成物件屬性。在我的 Provision1.csv 檔案中是使用類似「Logon Name」及「First Name」之類的欄名稱 — 這點很有趣，因為欄名稱不會直接對應到 Active Directory 使用者屬性。我發現這些檔案常會使用比較通俗的欄名稱，而非 Active Directory 特有的名稱。畢竟，您收到的檔案可能來自公司人事部的員工，他們應該不曉得 Last Name 實際上等於 Active Directory 中的 sn 屬性。
一旦匯入 CSV 檔案中的所有資料並傳回物件時，那些物件便會輸送到 ForEach-Object 指令程式，而指令程式會為每個物件執行一段程式碼 — 位於我的單行指令碼的大括號內。也就是說，這段指令碼會針對 CSV 檔案中的每一行各執行一次。在指令碼內，特殊 $_ variable 是目前物件 — 或 CSV 檔案目前行的參考。
您可以看到，我針對每個物件執行 New-QADUser 指令程式。這是 Quest 增益集中數十種指令程式中的其中一種。名稱 QADUser 不值一提。至於 Q，您應該已經猜到，代表 Quest。此命名慣例的設計是為了避免與 Microsoft Active Directory 小組未來生產的最終 New-ADUser 指令程式相互衝突。這麼一來，如果這兩個指令程式同時載入命令介面，您和命令介面都能輕鬆辨別這兩者。
單行指令碼的其餘部分包含 New-QADUser 指令程式的參數。它一開始指定 organizationalUnit，這是您要建立所有新使用者的位置。下一個是名稱屬性，我已將它設為 First Name 欄的內容、一個句點，然後是 Last Name 欄的內容。
最後一點很有趣的是：city 參數實際上會在 Active Directory 中變更 l 屬性 (或 Locality-Name)。指令程式也接受命名為 l 的參數，它也是執行相同的動作。在大部分的情況下，指向 Active Directory 屬性的參數可以使用屬性名稱或 Active Directory 使用者和電腦工具的文字標籤。

其他 Windows PowerShell 之道
Active Directory 是階層式的存放區，Windows PowerShell 的其中一項長處就是能夠將任何階層式存放區公開為磁碟機，讓您使用熟悉的命令集來管理各種存放區，例如 Dir、Del、Ren、Copy 等等。可惜的是，Windows PowerShell 1.0 並未隨附 Active Directory 的 PSDrive Provider，也就是說命令介面無法將 Active Directory 本身公開為磁碟機。
幸好，PowerShell Community Extensions 又再次展現出豐富生態系統的特色。這是免費的開放原始碼增益集，可從 codeplex.com/powershellcx 取得。安裝之後，PowerShell Community Extensions 可讓您直接將命令介面導向網域名稱，讓您開始以磁碟機的方式來管理目錄：
CD COMPANY:
CD SINGERS
DIR
這些命令會變更為 COMPANY 網域，變更為 Singers OU，然後顯示物件清單，如 [圖 2] 所示。我可以從該處使用 Del 命令來刪除使用者，使用 Md 命令來建立新的 OU，諸如此類。Community Extensions PSDrive Provider 中有幾處陷阱。基本上，這是由於您可能預期某些功能會實作，但因它們並未與 Active Directory 本身的運作方式相對應卻無法使用之故。而且您應該要特別小心：變更到網域根目錄並執行 del * -recurse 實際上會刪除網域中的每個物件，只要您的權限許可的話。在預設情況下，程式甚至不會詢問「您確定嗎？」。沒錯，命令列的功能強大，不過這種強大功能也會因為使用者缺乏技巧與細心而產生風險。
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory

馬上開始使用命令介面
我班上的學生老是詢問現在該如何應用 Windows PowerShell。畢竟，並非每個 Microsoft 產品都為了使用 Windows PowerShell 而經過重新設計，而且您可能直覺地以為 Windows PowerShell 仍有待改造以提供更棒的功能。
事實上，它強大的功能早已不在話下。即使 Microsoft 尚未針對命令列管理來調整 Active Directory，但其他工具已經嘗試這麼做，而且效果不錯。您可以使用 Windows PowerShell 來執行許多系統管理工作，包括自動化某些最耗時費力的工作，例如，建立一批批的新使用者。秘訣就在於盡量發掘社群為了讓 Windows PowerShell 更好用而進行的一些計畫 (您應該造訪一下 PowerShellCommunity.org，我負責管理這個由 Microsoft 共同贊助的網站)。只要將適當工具載入 Windows PowerShell，您就可以開始針對一些不想動手又極為耗時的工作編寫指令碼，成為更有能力且更有效率的系統管理員。

Don Jones 是《Windows PowerShell:TFM, 2nd Edition》的共同作者，《VBScript, WMI, and ADSI Unleashed》的作者，以及 PowerShellCommunity.org 的總監。


 嗨，Scripting Guy！: 對規則運算式挑大眉
嗨，Scripting Guy！
對規則運算式挑大眉
The Microsoft Scripting Guys
下載本文程式碼: HeyScriptingGuy2008_05.exe (150KB)

在 2007 年 11 月 ，Scripting Guy 必須在巴黎度過一天，途中再去參加於巴塞隆納舉辦的 Tech•Ed IT 論壇。在一日的行程中，我們趁機造訪了舉世聞名的藝術博物館 ─ 羅浮宮。
那麼 Scripting Guy 是怎麼看羅浮宮呢？很簡單：我們走到聖母院，然後左轉。
喔，您是指我們覺得羅浮宮好玩嗎？大部分還不錯。唯一的問題是，羅浮宮就像很多博物館一樣，只准看不准摸。大家都曉得蒙娜麗莎要是有眉毛的話，看起來美多了，但是不知道為什麼，如果有人想要動這些畫作，羅浮宮的管理人員就會很生氣。
備註： 其實兩位 Scripting Guy 都很喜歡蒙娜麗莎。而且那次的經驗又愉快又驚喜；經過這麼多媒體炒作，我們本來擔心它可能只是普通的一幅畫。但其實不然，它真的很酷 (不過加上幾根眉毛更棒)。然而有趣的是，我們兩個都對同樣高人氣的「米羅的維納斯」感到失望。我們都不覺得這個作品有這麼了不起，而且撰寫這篇專欄的 Scripting Guy 被「米羅的維納斯」的意象搞糊塗了。一尊沒有手臂的女人雕像？她要怎麼擦地板或洗碗盤！？
給女性讀者的話 (如果我們還有女性讀者沒被氣跑的話)：很顯然這裡印刷錯誤。我們的原意是：一尊沒有手臂的女人雕像？她還是能做比男人多兩倍的工作，而且做得很不賴。
如果原文引發任何誤解，Scripting Guy 深感抱歉。
無論如何，正當我們欣賞著羅浮宮的偉大珍藏時，兩位 Scripting Guy 突然想到同一件事：廁所在哪裡？而執筆本專欄的 Scripting Guy 在整理資料時想到另一件事：Scripting Guy 真是偽君子。畢竟，我們一方面很氣羅浮宮不讓我們修正蒙娜麗莎的畫像。而另一方面，我們其實也犯了同樣的罪。在 2008 年 1 月份的《TechNet Magazine》中，我們寫了一篇有關在指令碼中使用規則運算式的文章。那篇文章可說是標準的只准看不准摸的例子：我們示範如何使用規則運算式來識別文字檔中的問題，但是並未示範如何修正這些問題。真該死！
備註： 如果 Scripting Guy 在 2007 年 11 月到羅浮宮，那麼撰寫這篇專欄的 Scripting Guy 怎麼會靈機一動，想到一篇直到 2008 年 1 月才登上《TechNet Magazine》的文章呢？哇，這真是個謎啊，不是嗎？這一定跟里德蒙與巴黎的時差脫不了干係。
但還好 Scripting Guy 不像那些羅浮宮的管理人員，Scripting Guy 樂於承認自己的錯誤。我們不該只是示範如何使用規則運算式進行搜尋；我們也應該示範如何使用規則運算式來執行取代動作。事實上，我們應該要示範如 [圖 1] 所示的指令碼。
Figure 1 搜尋和取代 (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
老實說，這種規則運算式用法其實很普通：我們只是將所有 Mona Lisa 字串值的例項都取代為 La Gioconda (這是義大利文，意思是「我把眉毛放哪兒去了？」)。的確，我們可以使用 VBScript Replace 函式，讓這個取代作業更容易執行。但是別怕：我們將使用這個簡單的一小段指令碼來說明如何使用規則運算式執行搜尋和取代作業，而且當我們這麼做之後，我們還會示範如何使用這些運算式來執行一些更花俏的作業。
如您所見，這個指令碼其實沒什麼。我們一開始先建立 VBScript.RegExp 物件的執行個體；當然，就是這個物件能讓我們在 VBScript 指令碼內使用規則運算式。建立物件之後，我們接著指派值到物件的三個屬性：
Global 藉由將此屬性設為 True，我們告訴指令碼搜尋 (並取代) 在目標文字中找到的每個 Mona Lisa 的例項。如果 Global 屬性設為 False (預設值)，指令碼就只會搜尋和取代 Mona Lisa 的第一個例項。
IgnoreCase 將 IgnoreCase 設為 True 會告訴指令碼我們要執行區分大小寫的搜尋；換言之，我們會將 mona lisa 與 Mona Lisa 一視同仁。在預設情況下，VBScript 會進行區分大小寫的搜尋，這表示 — 多虧了大小寫字母 — mona lisa 與 Mona Lisa 會被視為完全不同的值。
Pattern Pattern 屬性會保存我們要尋找的值。在此例中，我們只要尋找一個簡單的字串值：Mona Lisa。
接著，我們將要搜尋的文字指派到名為 strSearchString 的變數：
strSearchString = "The Mona Lisa is in the Louvre."
然後我們呼叫規則運算式方法 Replace，傳送兩個參數給這個方法：我們要搜尋的目標文字 (strSearchString 變數) 與取代文字 (La Gioconda)。我們在此就是這麼做：
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
這樣就大功告成了。修改過的文字會儲存在變數 strNewString 中。如果現在回應 strNewString 值，應該會得到以下結果：
The La Gioconda is in the Louvre.
文法可能有待商確，但是大致的概念就是這樣。
如先前提過的，這麼做不錯，只是太大才小用了；藉由使用下列幾行程式碼，也可以完成一模一樣的作業 (事實上，如果我們願意，就算只使用一行程式碼也辦得到)：
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
換句話說，我們來看一看可以使用規則運算式來執行哪些 VBScript 的 Replace 函式做不到的有趣作業。
沒人想得到嗎？這裡舉個例子。我們 Scripting Guy 總是需要從某種類型的文件複製內文到另一種文件類型。有時進行的很順利，有時則不然。在不順利的情況下，我們常碰到奇怪的文字間距問題，這種問題是類似以下的文字產生的：
Myer Ken, Vice President, Sales and Services
哎呀；瞧瞧看這些多餘空格！在這個案例中，Replace 函數的用處有限。為什麼呢？其中的多餘空格數目沒有一定的規律：字詞之間可能有 7 個空格，可能有 2 個空格，或者可能有 6 個空格。因此很難使用 Replace 來修正問題。譬如說，若我們試著搜尋 2 個連續空格 (以單一空格取代這些 2 個空格)，結果如下：
Myer Ken, Vice President, Sales and  Services
這樣好一點，但也沒多棒。雖然可以這麼做，但是我們必須搜尋任意數目的空格 (譬如 39)；進行取代；從最開始的數字減 1；搜尋 38 個空格；進行取代；依此類推。或者，我們可以使用這個簡單多了的 (而且更萬無一失) 規則運算式指令碼：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
此指令碼的關鍵 (同時也是多數規則運算式指令碼的關鍵) 在於 Pattern：
objRegEx.Pattern = " {2,}"
我們在此想要尋找 2 (或更多) 個連續空格。我們怎麼知道此 Pattern 會尋找 2 (或更多) 個空格？這個嘛，我們在雙引號內加入單一空格並緊接著下面這個建構：{2,}. 在規則運算式語法中，這表示要尋找前置字元 (在本例中是空格) 至少連續出現 2 次的例項。萬一有 3 個、4 個或 937 個連續空格怎麼辦？沒關係；這些全都抓得到 (如果基於某種原因，我們想要抓取至少 2 個但不超過 8 個的空格，那麼我們可以使用語法 {2,8}，這裡的 8 是用來指定符合項目的上限)。
也就是說，每當我們找到 2 個以上的相連空格時，便會抓取所有這些連續空格，並取代為單一空格。我們原本充滿多餘空格的原始字串值會變成怎麼樣呢？就是這樣：
Myer Ken, Vice President, Sales and Services
看到了嗎？Scripting Guy 真的可以把事情做的更好。只要羅浮宮人員願意讓我們解決蒙娜麗莎的問題。
有一個案例很有趣 — 而且還滿常見的。假設貴公司有一個電話目錄，所有電話號碼都採用以下格式：
555-123-4567
但是您的老闆現在突然決定要使用下列格式來顯示所有電話號碼：
(555) 123-4567
您到底該如何重新格式化這些電話號碼？請恕我們冒昧，大膽建議您使用如下的指令碼：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
在此我們要搜尋 3 位數 (\d{3})，接著是一橫線，之後又是 3 位數和一橫線，最後再緊接 4 位數。換句話說，我們要搜尋以下格式，而每個 X 都代表 0 到 9 的一個數字：
XXX-XXX-XXXX
備註：我們怎麼知道 \d{3} 會告訴指令碼尋找三個數字三連轟？我們依稀記得在某處讀到這個用法。事實上，若非是《達文西密碼》出人意表的最後一章，想必是線上 MSDN® 提供的 VBScript 語言參照 (請參閱 go.microsoft.com/fwlink/?LinkID=111387)。
現在，我們可以使用規則運算式來搜尋任意的電話號碼，這還真不賴。不過此處還是有一個重大問題。畢竟，我們不可能也使用任意電話號碼來取代這些任意的電話號碼；而是必須使用完全一樣的電話號碼，只是格式有點不同。我們到底該怎麼做？
當然是使用下列取代文字囉：
"($1) $2-$3"
$1、$2 和 $3 是規則運算式「反向參考」的例子。反向參考就是找到的文字中可儲存並重複使用的部分。在這個特殊指令碼中，我們要尋找三個「子對應」：
  • 一組 3 位數
  • 另一組 3 位數
  • 一組 4 位數
這些子對應分別都會自動指派一個反向參考：第一個子對應式 $1；第二個是 $2；依此類推，一直到 $9。也就是說，在此指令碼中，電話號碼的三個部分都會自動指派反向參考，如 [圖 2] 所示。
Figure 2 電話號碼反向參考 (Close Figure 2)

電話號碼部分 | 反向參考
555 | $1
123 | $2
4567 | $3
在取代字串中，我們使用這些反向參考來確保會重複使用正確的電話號碼。我們的取代文字只是表示：將第一個反向參考 ($1) 放入括弧中。空一格，然後插入第二個反向參考 ($2)，接著是一橫線。最後，加上第三個反向參考 ($3)。
這樣會產生什麼結果呢？結果是得到如下所示的電話號碼：
(555) 123-4567
真是一點也不賴。
電話號碼指令碼還可以稍加變化。假設貴公司安裝了全新的電話系統，根據此轉變，所有的電話號碼現在都有相同的首碼；原本可能以 666、777 或 888 開頭的電話號碼現在全都以 333 開頭。我們可以重新格式化電話號碼，同時又變更電話號碼首碼嗎？當然沒問題：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
看出來我們怎麼辦到的嗎？我們直接移除取代文字中的舊首碼 (反向參考 $2)；將此替補為硬式編碼的標準首碼值 333。執行這段修改過的指令碼之後，電話號碼 555-123-4567 會變成什麼樣子？結果應該很像這樣：
(555) 333-4567
反向參考還有一個常見的用法。假設我們的字串值如下所示：
Myer, Ken
有什麼辦法可以調換這個值以顯示如下的名稱呢：
Ken Myer
要是沒有辦法，我們豈不是面上無光？下面就是執行這項作業的指令碼：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
在這個特定指令碼中，我們要尋找後面接著逗號的單字 — (\S+)，逗號後面緊接著空格，之後是另一個單字 (在本例中，我們使用 \S+ 來代表「單字」)。建構 \S+ 表示任何非空白字元的連續組合。換言之，字母、數字、符號皆可；事實上，除了空格、定位鍵或歸位換行以外，幾乎什麼都可以。如您所見，我們預期在這裡找到兩個子對應：一個代表姓氏 ($1)，另一個代表名字 ($2)。因此，我們可以使用以下語法將使用者名稱顯示為 FirstName LastName：
"$2 $1"
逗號到哪兒去了？顯然我們並不需要逗號，所以直接丟掉了。
備註：真好玩；不曉得為什麼，我們也開始跟 Scripting Editor 有同感了。嗯...
本日課程結束前，讓我們再探索一個例子吧 (好吧，更正一下，在本月課程結束前)。這並非萬無一失的作法；畢竟，我們可不希望介紹性質的本專欄變得太複雜 (規則運算式的確有潛力變得極度複雜)。不過，有一個指令碼 — 在大部分的情況下 — 可以移除 0000.34500044 這類數值之前的零：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
一如往常，這能成功的原因全仰賴 Pattern："\b0{1,}\."我們一開始先尋找字元界限 (\b)；這麼做可確保我們不會將 100.546 這類數值中的零刪除。接著尋找後面緊接小數點 (\.) 的 一或多個零 — 0{1,}。如果找到此模式，就以一個小數點「.」來取代這些零 (還有小數點)。如果一切照計畫進行，字串就會轉換成下面的樣子：
The final value was .34500044.
本期專欄已接近尾聲。結束之前，我們應該提一下，在油彩未乾之前，蒙娜麗莎這幅畫就已經倍受爭議。這位詸樣的女子是誰？她為什麼要這樣微笑？她為什麼沒有眉毛？多位藝術歷史學家認為蒙娜麗莎根本不是女性，而是達文西的自畫像 (如果是真的，他實在應該換位裁縫師了)。另一方面，Unarius 教育基金會甚至更進一步宣稱這幅畫其實是達文西在「更高世界」中的「雙生靈魂」，而且這個雙生靈魂引導了達文西的作畫。出於極端巧合，本月的《嗨，Scripting Guy！》也是這樣完成的。
這表示所有抱怨都應該傳送到本專欄作者在另一家微軟工作的雙生靈魂的電子郵件信箱：the-twin-soul-of-the-scripting-guy-who-writes-that-column@the-other-microsoft.com。謝謝您。

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

2008 年 5 月：指令碼獨
這個月我們要來玩玩有點不一樣的數獨。我們不在格子中填入 1 到 9 的數字，而是填入構成 Windows PowerShell™ 指令程式的字母和符號。在最後解答中，其中一橫列會拼出指令程式的名稱。
備註：如果您不清楚怎麼玩數獨，網際網路上有數千個網站提供玩法解釋，因此就不在此複述了，抱歉。

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：指令碼獨，2008 年 5 月

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


 安全性監控: 量子安全性的原則
安全性監控
量子安全性的原則
Jesper M. Johansson

以一般人意想不到卻又相當有用的東西作為話題交談，是件很開心的事。過去這一陣子以來，我一直用海森堡不確定原理來解釋安全性概念 (只要聽過我講獨角獸故事的人，都知道我喜歡從其他專業領域提出基礎理論來闡明我的觀點)。雖然看似奇怪，
不過在科學的其他領域當中，有些基礎概念還真的能夠拿來推論資訊安全性呢。
海森堡不確定原理源自量子物理學，是以 [圖 1] 所示的方程式為基礎。原理本身敘述粒子 (p) 的位置與粒子 (x) 的動量彼此關聯，如果提高測量位置的精度，就會降低測量動量的精度。而作為兩者精度界限的，則是一個小小的普朗克常數 (Planck's constant) 固定倍數。換一種淺顯易懂的方式來說，就是您無法以完全精度同時觀察一個粒子的多種特定事實。
Figure 1 Heisenberg Uncertainty Principle
Figure 1 Heisenberg Uncertainty Principle
這就直接關係到不確定帶 (uncertainty band) 的預估，也就是預估您對於一個粒子幾種事實狀態的不確定度有多高。無法預估不確定帶，就無法準確預估兩個變數對於它們所在的電腦網路安全性會產生什麼影響，這一點必須特別注意。
另外，您也必須做出取捨。也許在資訊安全性方面您並未受到普克朗常數的限制，但是在另一方面還是受到限制了。在這些取捨當中，要屬安全性與可用性 (或有用性) 的折衷最為明顯。如果您有片刻時間疏於注意可用性 (坦白說，我覺得安全人員除了阻斷服務攻擊之外，不應該為可用性負責)，最簡單的方法就是關閉它，只要關閉它，就不會再受到駭客入侵。不過這麼一來，有用性就會暴跌。
同樣的，您也可以實作昂貴的預防資料遺失產品，來抑制因為資料外洩而大幅損失的成本，這個作法比每年傳送一封電子郵件給所有員工，提醒他們即時傳訊應用程式不能作為商業用途，更能防止機密資料外洩。但問題是貴公司願意把錢花在預防資料遺失產品上嗎？您現在可以瞭解量子物理與安全性之間的關聯性，比您想像中更加密切了吧。

薛丁格的貓
「薛丁格的貓 (Schrödinger's Cat)」寓言詮釋的是另外一種相關但又不一樣的量子物理概念。故事起源於 20 世紀兩位傑出的物理學家艾文薛丁格 (Erwin Schrödinger) 與愛因斯坦 (後者您也許已經耳聞其名) 長期以來針對重疊 (superposition) 概念的爭論。薛丁格發現量子力學領域在兩種狀態的重疊當中，存在一些不合理的元素。
為了闡述他的理論，薛丁格提出一個假想實驗，假設有一隻貓被關在密封的盒子裡。除了貓之外，盒子裡還放了一個裝有毒氣的容器，毒氣的釋放是由一種 (想像的) 次原子放射性粒子所控制。放射性粒子一旦產生蛻變，就會釋放毒氣毒死貓咪。
這個遵循量子力學定律的次原子放射性粒子，是存在於重疊狀態當中。由於原子貓的狀態完全取決於次原子粒子的狀態，因此貓也存在於這個重疊狀態當中。只有實際觀察貓的狀態，才能夠確定貓生或貓死的狀態。
當然薛丁格的用意是為了告訴大家，量子力學中有某些定律在套用到原子系統時有多不合理。但是以一般人的術語來說，他舉的例子常被稱為「觀察者效應」。儘管這個觀察者效應並未套用到量子力學中的次原子系統，我們這些安全性專家對它倒是很感興趣。簡單的說，它的意思是您在觀察某個東西時，同時也改變了那個東西。
觀察者效應
讓我們舉一杯茶作為例子，進一步說明這個效應的原理。現在您在杯裡放進一只溫度計，測量茶的溫度。假設您放進溫度計的時候，茶是攝氏 80 度，而溫度計本身是 22 度 (室溫)。溫度計一放進茶中，便開始吸收茶的熱度，而茶也釋出本身的熱度為溫度計加溫。最後茶和溫度計的溫度就融合為一。但是，溫度計不會是 80 度，也不會是 22 度 — 而是介於兩者之間。也就是說，您測量茶溫的動作，改變了茶的溫度。
觀察者效應也與 infosec 密切相關。每當您執行某個動作來緩和安全性問題時，也可能會因為改變系統，而改變了安全性狀態。我實在想不出更好的詞彙，就姑且稱之為安全性狀態流動效應 (Security Posture Fluidity Effect，SPFE) 吧。
服務帳戶相依性就是其中一個比較單純的範例。我在《Protect Your Windows Network》(protectyourwindowsnetwork.com) 第 8 章中提到，您可以在系統上安裝入侵偵測服務 (IDS) 來偵測攻擊。但是 IDS 會登入中央系統，要求具備高度授權來存取被監視的系統。在大部分的情況下，這是指服務採用高度授權的服務帳戶。
萬一其中任何一個系統受到攻擊，攻擊者便會取得服務帳戶認證的存取權，除了停用 IDS 本身之外，還會存取其他所有的系統。這可說是最佳的 SPFE 範例。為了保護環境安全而安裝某個東西，卻也因此製造了新的潛在安全性問題。
其他關於 SPFE 的例子多不勝數。Steve Riley 針對 802.1x 在有線網路上的問題所提出的說明 (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx)，也是一個很好的例子。目前主機型防火牆儼然已經成為許多環境迫切需要的最愛，但是與 802.1x 併用卻也為某種攻擊製造了乘隙而入的機會，而這是以前不可能發生的情況。同樣的，安全性技術改變了環境的安全性狀態，使得之前被阻隔在外的攻擊有機可乘。
但這不表示那些方法毫無用處，能免則免，而是您必須全面考慮您的所作所為，對於安全性可能造成哪些隱憂。當您在進行風險管理時，必須採取專門針對風險的動作和預防措施。在執行緩和措施時，一旦實施對策之後，就不能隨意喊停。說得更明白點，安全性是一種程序。您必須採用深度防禦策略，但同時也要考慮這個防禦動作會對安全性狀態產生哪些改變，以及如何面對因它產生的威脅。

完善的強化策略
我從事強化導引 (hardening guidance) 已有 10 年以上的時間。回顧最初所做的導引，我發現我只是列出我和同事認為您應該開啟的設定而已。當時一般人所用的安全性策略仍很天真 — 基本上只要是專門提供安全性的東西就得開啟，並未想過有什麼需要關閉它的正當理由。
但是後來我漸漸明白，要有效進行強化工作，必須經過深思熟慮，把系統接踵而來要面對的威脅全部考量在內。《Windows 2000 安全性強化指南》(go.microsoft.com/fwlink/?LinkID=22380) 所列出的案例，就是根據後來揭露的這個觀念所衍生。經過自然演進之後，強化導引逐漸被分成三個威脅層級，相關資訊請參閱《Windows Server 2003 安全性指南》(go.microsoft.com/fwlink/?linkid=14846)。
那時候我一直納悶，為什麼所有的導引都開啟並就位了，還是擋不住系統受到攻擊的機率。原來是因為漏了某些修補程式，或是其中一個操作實例容我進入，或者是安裝了不安全的協力廠商軟體所致。
結果證明那兩篇指南文章所寫的強化步驟，無法幫助我們匯聚安全性狀態，充其量只是點出幾項重點而已。事實上，至今我所建立過最安全的系統 (msdn2.microsoft.com/library/aa302370)，只應用了那兩篇安全性指南所提到的四或五種調整做法，而且沒有一個能夠確實阻擋因它而起的攻擊。無奈的是，大家只求能有一個寫著「快來救我」的藍色按鈕，一按就能自動強化系統。但安全性可不是這麼容易打發的問題。

如何應付風險
要受到保護 (相對於有限的安全狀態)，就必須採取適當的風險對策。您必須瞭解您所面對的是哪些風險，然後決定要緩和哪一項風險，並且瞭解如何緩和風險，而這絕對不是扳動開關就做得到的。
這些安全性開關通常是針對特定案例所設計，不見得會針對您的案例建立最佳設定，而是建立一個良好的基準起點。這些開關之所以廣為使用，主要是因為大部分的市場都要求具備這些快速強化調整功能。現今軟體多半都已預設備有這些開關；沒有具備的話，可能會引發重大的副作用。
尤其在扳動大量開關之後，可能會產生不穩定或無法支援的系統，無法執行您希望它們執行的工作 — 而這些工作都是為了減輕您尚未列舉出來的威脅。SPFE 和量子物理告訴我們在採取保護動作之後，還要再度重新分析，但是有太多公司就是辦不到。其實它們是無法先行分析威脅，如果一開始就能確實分析威脅，您會發現真正有用的方法，並不是針對列出帳戶名稱和批發存取控制清單變更施加匿名限制，
而是：一. 決定系統是否應該提供特定的服務、提供給誰，然後強制實施該項原則；二. 確保只有絕對需要與您溝通的系統和使用者，才能夠與您溝通；三. 確保所有使用者和應用程式一律以最低權限執行。總之，真正有效的方法就是採取明智的安全步驟，並且執行困難的分析，讓每一個系統都能為它自己的安全性負起全責。
這也是為什麼目前的安全對策都採用像伺服器及網域隔離 (請參閱 microsoft.com/sdisolation)、Windows Server® 產品專用的「資訊安全設定精靈」(SCW)，以及在 Windows Server 2008 管理角色的「伺服器管理員」等工具。這些工具能夠逐步引導您瞭解您必須支援的案例，並且幫助您妥善的鎖定系統。當然這些工具並不會提供人人所需的萬靈丹，但至少它們能夠產生一個可以支援的設定，確實執行您購買該軟體所要執行的工作。

根據需要套用安全性
這句話的意思是，安全性不能指望其他實體或僅靠簡單的調整辦到。每一項資產都必須具備捍衛自己的能力，因為像「周邊網路」和「內部網路」等概念，在現在根本毫無意義。
大部分的公司網路充其量只具備部分敵對的能力。您必須瞭解這一點之後再採取適當的步驟，不要完全仰賴直覺式的強化導引。首先，您必須瞭解自己的需求，並且向其他瞭解您需求的人士取經。
最近網路廣播上有一位訪客建議小型企業使用者前往「聯邦國土安全部門」(Department of Homeland Security) 網站，下載 Internet Explorer® 的強化指南。笑話！難道要指望負責保護軍事和國家安全的政府機構告訴您如何保護小型企業的網頁瀏覽器嗎？如果說電腦安全性領域至今仍普遍存在某種錯誤邏輯的話，這就是最好的例子。這個邏輯覺得因為該指南是由三字母簡寫的政府機構所發出，所以具有高度安全性。
選擇通常採二元化表示：您可以選擇「高安全性」或「低安全性」。另一組更好的選擇方式是「高安全性」和「適度安全性」。聽好了，安全性可不是一成不變的僵化原則。
事實上，高安全性不見得適合每一個人 — 應該說，通常大部分的人都不適合！它並不是您應該努力的終極目標，而是針對禁不起系統受到任何攻擊的人所設計的設定。如果這個原則符合您的風險概況和威脅模型，那麼就採用高安全性。
如果不符合您的風險概況和威脅模型，最好還是改採更適當的選擇。目前您所能設定的調整功能，大部分已經妥善預設為中度風險概況。大部分的 Microsoft 產品皆普遍採用這個預設狀態，它在安全性和可用性、有用性以及效能之間，提供了相當合理的平衡。就強化而言，它都幫您打點妥當了。
您需要考慮的是其他的安全性步驟。您不妨從 TechNet 資訊安全中心 (http://www.microsoft.com/taiwan/technet/security/default.mspx) 開始著手，當然嘍，像《Windows Server 2008 Security Resource Kit》這類的書籍也不錯。

重點就是風險管理
現在您應該已經知道我的重點了：沒錯，就是風險管理。海森堡不確定原理所要傳達的關鍵訊息是您得做出取捨，這個部分並不難懂。
但是，「薛丁格的貓」所要傳達的訊息卻鮮少有人注意。您不僅要分析所有的問題層面，在取捨之間做出決定，同時還必須考慮您的解決方案會帶來哪些改變。健全的風險管理策略會考慮那些改變對系統所帶來的影響，以及那些改變是因為執行風險緩和策略，還是因為其他理由而產生。

年平均預期損失率
年平均預期損失率 (Annualized Loss Expectancy，ALE) 方程式 (如 [圖 2] 所示) 是量化風險常用的方法，也是許多安全性憑證課程所教授的方法。標準的 ALE 算法相當簡單，就是判斷事件發生的機率，以及算出每發生一次所耗費的成本，再將兩者相乘。這就是您每年預定為安全性事件支付的費用。如果風險成本高達某個程度，就得實作緩和措施。
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
但問題是標準 ALE 無法公正評估緩和措施的成本。除了緩和措施本身的成本之外，許多緩和措施所產生的副作用也會耗費成本。
讓我們看看其中一個最標準的安全性調整：帳戶鎖定。許多公司部署帳戶鎖定，很明顯是為了防止攻擊者猜中密碼。您可以用數學方式計算攻擊者猜中任何單一密碼的機率。如果創意夠高，也可以估算彌補攻擊者順利猜中密碼所產生之漏洞的平均成本。許多公司就根據這兩個數字，判定 ALE 不符要求，轉而實施帳戶鎖定。
但是這種緩和方式會產生一種您可能不會注意到的成本。當然實作緩和措施本身一定有其成本 (雖然金額相當微小)，但是為了精確起見，我們還另外加入緩和措施所產生的副作用成本。
首先是支援工程師為使用者解除鎖定的成本。即使帳戶鎖定時間不長 (假設 15 分鐘吧)，還是會耗費失去產能的成本，而這個因數就是每一個事件的成本。接著我們再將它乘以該事件在指定時段中所發生的可能性。以這個案例來說，就是把成本乘以預期的鎖定事件數目 — 您的記錄也許已經有辦法達到這個數目了。
除此之外，您還得把使用者惡化因數算在裡面。根據一些有趣的證據指出，使用者在帳戶鎖定的管制下，會使用較不複雜的密碼，因為這樣比較不容易打錯。因此，即使在實作緩和措施之後，我們希望避免的事件機率也不會完全降到零。
最後一點，緩和措施可能會在系統產生一些漏洞，而這些漏洞是實作緩和措施之前所沒有的。就拿帳戶鎖定來說，攻擊者可以利用這個特點停用網路中所有的帳戶，方法很簡單，只要重複猜錯密碼就行了。除了每一個事件的相關成本之外，還有該事件發生的機率。
如果把這些因數全部納入考慮，就能夠很清楚的看出您必須修改預期損失率方程式了。首先，您必須修改事件的機率。雖然前面所顯示的事件發生機率尚未降到零，但是現在可能性應該會比之前稍低，而且每一個事件的成本也可能不同於前。您需要在產品中加上緩和措施本身的成本，這個成本是實作成本加上所有副作用的年度成本總和。每一項年度成本，都是發生副作用的機率，乘以該副作用的每一個事件成本得出的結果。把方程式表示法再稍加簡化之後，就能得出更精確的風險分析方程式，如 [圖 3] 所示。
[圖 3] 當中改良過的方程式，可提供您更精確的方法來分析特定問題的風險。許多公司已經採用這個方法來分析它們的風險了。但還是有太多公司仍秉持簡單的風險觀點，沒有充分指出分析緩和措施影響力的需要。但是使用經過修改的 ALE 方程式之後，就可以提升這項需求的重要性。
Figure 3 Considering the additional costs of mitigation
Figure 3 Considering the additional costs of mitigation

到底歸根結底的重點是什麼？
如果您在讀完本文之後只有一個結論，那應該是質疑安全性策略所用的傳統智慧。我們在資訊安全性領域的做法，有太多是以千篇一律的老舊觀點為根據，但是許多假設已經過時。
現在的攻擊方式與過去早已不可同日而語，攻擊者都非常專業，攻擊目的不外乎為了金錢、國家主權，還有意識型態。您可不能把時間和金錢浪費在不能改善安全性的安全性調整，因為您負擔不了這個成本。換句話說，您必須採取更精密的方式來管理風險。
首先，您必須認清您所做的每一件事都會經過取捨，因此無法確切知道每一個細節。
其次，您必須瞭解您是在互相依存的系統當中作業。當您對系統做出安全性變更的同時，也會改變系統本身，因此必須將系統重新分析一次。
這個動作最好能在實際實作變更之前執行，因為這些變更常常會對系統造成莫大的影響，而且弊多於利。如果能夠使用更好的分析工具提醒您分析那些變更，可以大大降低健忘的機率。
最後一點，千萬不要忘記人為因素。您在資訊安全性方面所做的每一件事，都是為了讓企業和公司內部使用者盡可能安全地操作。
最近我在一項簡報當中指出，使用者購買電腦的目的可不是為了執行防毒程式。您的主要方針是安全性，但公司不是。公司忍受安全性，全是為了追求當下最佳的利益。千萬別忘記，是資訊安全性群組在服務企業，不是企業在服務資訊安全性群組。如果忽略這個原則，使用者一定會無所不用其極的完成工作，即使要規避他們不瞭解或不同意的安全性控制也在所不惜。

Jesper M. Johansson是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有管理資訊系統 (MIS) 的博士學位，研究安全性長達 20 多年，是 Microsoft 在企業安全性領域的最有價值專家 (MVP)。其最新著述為《Windows Server 2008 Security Resource Kit》。


 桌面檔案: 棄系統管理員於不顧
桌面檔案
棄系統管理員於不顧
Wes Miller

從三年多前開始，我把主要 Windows 系統上的使用者帳戶，從本機系統管理員帳戶改成本機使用者帳戶。我在 Microsoft 工作七年多以來，一直都是採用具有完整權限的系統管理員身分。系統管理員的確很方便，
但是也因為缺乏安全性，逼得我天天提心吊膽 (不只我，還有很多人也一樣)。這讓我深切體認到，每天以系統管理員身分工作，對系統的傷害比什麼都頻繁而且還要嚴重。
我也希望能有什麼方法可以改善這種情形，但是我的直覺和我所從事的行業在在告訴我，以本機系統管理員身分工作的公司實在太多了，包括 IT 專家本身都一樣。過去在 Winternals 工作時，轉用使用者身分是為了體認「生產消費者」(prosumer) 的辛苦，並且瞭解我們產品 (Winternals Protection Manager) 對於一般公司所能夠提供的幫助。當時 (現在還是) 大部分公司多半採用系統管理員身分，而我們決定讓系統管理員改採使用者身分，同時盡量縮短過渡期 — 至少盡量減少關鍵性問題產生。但是無論您引用什麼技術，要把公司從採用系統管理員身分，改成採用使用者身分，都不是件容易的事，不過為了有效縮減公司的攻擊面，除此以外，別無他法。我們就把它當作內部系統防火牆看待吧，因為這也是它真正的價值所在。

我們是怎麼辦到的？
我向您提出的挑戰：感同身受
如果您還沒開始考慮把系統管理員改為使用者，別再坐以待斃。我建議您身體力行，從自己做起。別用次要電腦 — 那跟作弊沒什麼兩樣。要用就用主要系統，也就是您每天在用的那一部。另外，如果您的作業系統是 Windows Vista®，我也建議您放棄使用使用者帳戶控制 (UAC)。當您開始在公司內部宣導改變時，多做少說，以身作則絕對是不二法門。慢慢您會發現，以非系統管理員的身分工作其實也沒那麼困難 — 而且提高安全性之後，真的會改變公司的攻擊面。

大部分使用者採用系統管理員身分的現象，可回溯到 Windows® 誕生之時。早期在 Windows NT® 3.1 版以前的 Windows，每一個互動使用者都具備同樣的權限 — 從功能性看來，完全沒有安全性可言。如果是在家裡使用倒無所謂，這只代表所有的軟體都以同樣方式安裝。因為它假設電腦的使用者就是擁有者，而且所有的軟體都只供這部電腦的使用者使用。
Windows NT 剛開始出現時，並未立刻攻佔企業市場 (更別提消費者市場了)。而且由於 32 位元 Windows 和 Windows NT 之間還具備 Win32® 相容性，因此大部分的應用程式廠商也沒有特別針對 Windows NT 的安全性基礎結構，重新建置應用程式。事實上，一直到 Windows 2000 推出之後，許多消費者導向的獨立軟體廠商 (ISV) 才開始注意 Windows NT。而 Windows XP 更強制終結了 Windows 9x 系列。
但是應用程式仍然繼續假設系統上的每一個使用者都有權寫入程式檔案 (使用者沒有)、登錄中的 HKEY_LOCAL_MACHINE (HKLM) (使用者沒有)，以及 HKEY_CLASSES_ROOT (使用者沒有)。在霸佔存取方面，尤以遊戲為最，請參閱 Matt Clapham 針對這個主題所寫的文章，網址為 technetmagazine.com/issues/2007/02/Gaming)。
這很麻煩，因為大部分跨系統的應用程式都把它們的檔案和登錄設定儲存在那些位置，您必須能夠讀寫到那些位置，才能安裝它們。於是有些應用程式便堅持等安裝之後再寫入那些機碼，真教人頭痛。比方說，我女兒有一個以 Flash 為基礎的遊戲。每次玩它時，它都會安裝一個自訂播放器 — 換句話說，只要我女兒以使用者身分 (而不是系統管理員身分) 玩它時，應用程式就會發生嚴重錯誤而無法啟動。這未免有點誇張吧，它還是消費者應用程式呢！現實情況是，許多非消費者應用程式在非系統管理員使用者的世界裡，仍然無法玩得盡興。事實上，如果您看過我的挑戰 (請參閱資訊看板「我向您提出的挑戰：感同身受」)，就會發現 Windows 本身對於使用者身分多沒耐心。
以 [圖 1] 來說，IPConfig /release 應該是以使用者身分在 Windows XP 上執行。如果把它和 [圖 2] 相比，其實同一個命令用在 Windows Vista 也沒有好到哪裡去，不過至少它會告訴您命令失敗的原因。請注意，網路工具整體來說已經進步到容許使用者重新整理他們的 IP 位址。同樣的，無論在哪一個版本下以使用者身分執行「電腦管理」(compmgmt.msc)，都可以執行限量的工作 — 只不過通常是以身陷窘境收場，如 [圖 3] 所示。Windows Vista 一開始並不會啟用「電腦管理」中的許多工具，而是顯示更明確的拒絕存取訊息。
Figure 1 Running as a user under Windows XP
Figure 1 Running as a user under Windows XP
Figure 2 Running as a user under Windows Vista
Figure 2 Running as a user under Windows Vista
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP

為什麼它如此舉足輕重
既然如此，那有什麼好在意的呢？那是因為身為 IT 專家的我們，應該開始強制應用程式適應最低權限的使用者，而不是反過來讓應用程式覺得互動使用者擁有該系統。
但是，容許系統管理員寫入登錄機碼的同一個原則，也會授予完整的存取權給使用者內容中所有的惡意程式碼，讓它們透過存取控制清單 (ACL)，存取它們尚未被明確拒絕的任何東西。在 UNIX 的世界裡，大家遵循的是不採用根使用者身分的規則 (在功能上等同 Windows 系統管理員帳戶)，這大半是因為挑戰安全性模型界線的軟體生態系統，小到幾乎不存在。
同樣的，在這種情況下最好還是遵循相同的原則，並且只在明確需要時，才採用系統管理員的身分 — 或者只在執行個別應用程式時，才採用系統管理員的身分，這反而更棒。只要架起我在前面提及的內部系統防火牆，惡意程式碼或間諜軟體就無法得逞 — 因為它無法寫入登錄，也無法寫入它為了確實侵害系統所需要的檔案系統位置 (例如，安裝服務或驅動程式，或者安裝給所有使用者使用)。此外，這麼做也可以讓反間諜程式放入它所認得的惡意程式碼，而不致讓整個系統承擔風險。
但是要注意的是，那些使用者並非刀槍不入。雖然這種等級的惡意程式碼尚未廣泛存在，也不能排除這種惡意程式碼順利入侵個別使用者內容，或者破壞這個資料的可能性。但是這類軟體所引發的攻擊向量很有限。因此，持續壓低 Linux 或 Macintosh 上惡意程式碼執行個體數目 (潛在受害者的數目越少，對於惡意程式碼作者的吸引力就越低) 所用的方法，可以幫助您確保使用者 (以及您自己) 的安全。

排除進階使用者？
當我們開發 Protection Manager 時，曾經聽到客戶說過：「我們所有的使用者都是以進階使用者 (而不是系統管理員) 的身分來執行 Windows XP，所以我們非常安全。」其實不然，進階使用者跟系統管理員只是五十步跟百步的差距而已。只要稍微在許多潛在漏洞下點工夫，就足以讓 Windows XP 上的進階使用者轉變成系統管理員。事實上，Windows Vista 和 Windows Server® 2008 已經沒有進階使用者群組了，只有在舊版 Windows 升級的系統上才看得到。總而言之，進階使用者群組能免則免，即使是使用 Windows XP 也一樣。

失真的權限
如果您讀過我在三月份專欄針對 Windows 精簡型用戶端發表的文章 (technetmagazine.com/issues/2008/03/DesktopFiles)，應該記得我反對為了節省空間而精簡 Windows XP。同樣的，您也可以考慮採用一種將系統管理員轉移為使用者的常用做法，不過執行時務必要小心謹慎。這個做法是調整登錄和檔案系統上的 ACL，讓使用者能夠寫入他們平常無法寫入的位置 — 因而啟用有問題的應用程式。
當然，最好的選擇是取得不需要這項變更的更新版應用程式，但是也並非每次都能這麼順利。如果您必須變更權限 (亦即放棄權限)，切記一定要非常小心。請記住，使用者和系統管理員之間的防火牆，多半是由登錄和檔案系統權限加以定義。一旦開啟它們，就會減弱您的保護，並且在無形之中拓寬惡意程式所設定的攻擊面 — 因此千萬要謹慎行事。

那麼 UAC 呢？
要討論將使用者從系統管理員身分轉移為使用者身分，一定要提到 Windows Vista 中的使用者帳戶控制 (UAC)。UAC 就像 Mac OS X 上的類似功能，容許您以系統管理員身分執行，卻又不必背負這麼多風險。
它到底如何運作呢？讓我們看看 [圖 4] 中，Process Explorer 所顯示的 cmd.exe 相關內容。右手邊的 cmd.exe 執行個體是以系統管理員身分，在沒有提高權限的情況下啟動。因此，即使右手邊的使用者與左手邊的使用者完全一樣 (左手邊的 cmd.exe 是在提高權限的情況下啟動)，應用程式本身並不包含必要的權限和權杖，讓它 (以及執行該執行個體的使用者) 執行任何需要具備系統管理員權限的工作。UAC 的功能，就是要縮減使用者互動內容中的攻擊面。唯一的問題是，它必須借助一種媒介告訴 Windows，這項工作需要具備系統管理員權限，以及使用者同意為了完成這項工作而提高權限。
Figure 4 Two instances of cmd.exe with different privileges
Figure 4 Two instances of cmd.exe with different privileges
在 Windows Vista 當中負責這項任務的是小盾牌，它會告訴您哪些工作需要提高權限 (見 [圖 5])。每當您執行這些工作時，都必須提高權限才行 — 而這點也被輿論視為 Windows Vista 的一大缺點。另外還有一個方法是增加認證的「麻煩」程度，但是此舉會引發潛在的安全性威脅，讓外力得以更輕易的入侵系統。
Figure 5 Shields in Windows Vista indicate the need for elevation
Figure 5 Shields in Windows Vista indicate the need for elevation
如果您有啟用 UAC，而且您的使用者是直接以使用者的身分執行，那麼當應用程式要求具備系統管理員權限時，畫面會提示他們輸入一組系統管理員認證。請注意這個情況，它與使用 runas 或 psexec 一樣，應用程式是在您啟動作為使用者的內容當中執行，這一點與在 UAC 採系統管理員身分執行是不同的。後者的工作是在您的內容當中執行，只不過它是在提高權限的情況下執行。

以使用者身分執行 Windows Vista？
在執行 Windows Vista 時，我個人偏好實際上以使用者的身分執行，而不是在 UAC 以系統管理員的身分執行，因為我相信對於一般企業來說，這仍是最佳的辦法。畢竟，您的使用者對於他們的系統擁有完整控制權，而且您可能早已減少惡意程式碼入侵的機會。
此外，如果您打算利用群組原則、防毒軟體、反惡意程式碼或其他軟體來管理您的使用者，而且您希望集中控制這些工作是否確實受到強制執行或完成，那麼一定要確保您的使用者不是系統管理員才行。如果使用者是系統管理員，他們就可以停止服務、新增或移除驅動程式等等。當然嘍，如果使用者夠狡猾的話，即使是採用使用者身分，還是可以利用 Windows PE 避開一些安全性障礙。雖然 BitLocker® 不會輕易讓他們稱心如意，但是同樣的道理，只要有足夠的時間、知識和奉獻的精神，具有實體存取權的使用者就能夠在他們的機器上為所欲為。
以使用者身分執行 Windows Vista，和以使用者身分執行 Windows XP 並沒有太大的差別。必要時，我還是會以系統管理員的身分，使用同樣的工具 — PSExec、RunAs (現在再加上 UAC) 來執行工作。過去在 Windows XP 時代，有為數不少的工作必須具備系統管理權限才能執行，現在已經不需要了。舉個例說，Windows Vista 使用者可以安裝本機印表機 (Windows XP 可以讓使用者安裝網路印表機，但是安裝本機印表機則必須具備系統管理權限)。在 Windows Vista，只要使用者實際坐在電腦前面操作，而且印表機驅動程式也妥善放在驅動程式存放區當中，使用者就可以安裝印表機，並且管理印表機上的列印工作 (其他詳細資訊，請參閱 go.microsoft.com/fwlink/?LinkId=111534)。請注意，Windows Server 2008 並未啟用這項功能。
以使用者身分在 Windows XP 執行的時鐘功能，常被人當作取笑的對象 (或許沒有這麼嚴重啦) — 您可以用使用者身分試著按兩下時鐘看看 (不管這是不是原先設計好的用法，一般人想看今天的日期時，通常都會這麼做吧) — 結果看到的不是日期，而是 [圖 6] 所示的錯誤訊息。真是不中用。當然您可以在 Windows XP 修改原則，讓使用者執行這個動作，但是 Windows Vista 已經自動幫您改好了。整體而言，若以使用者身分執行這一點來說 (無論您是使用 UAC，還是以正式使用者身分執行，然後以另一個使用者身分提高權限)，在 Windows Vista 是比在 Windows XP 上更加得心應手。
Figure 6 In Windows XP, non-admins couldn't change the time
Figure 6 In Windows XP, non-admins couldn't change the time

記住它的限制
您必須記住一點，並不是把使用者改為非系統管理員，就能夠解決一切問題。即使是專用使用者也得親自坐在自己電腦前面，努力的使用自己的系統，尤其如果原則或使用者權限不讓他們完成工作，或者讓他們不方便完成工作的時候更是如此。
如果您的使用者是採用系統管理員的身分，就可以輕易跳過任何已經設好的群組原則。當然，使用者只消花一點功夫，就可以進行在正常情況下無權進行的動作，例如開機到 Windows PE，並且修改權限 (雖然只要使用 BitLocker 或其他磁碟機/磁碟區加密，就可以防止他們這麼做，或者至少不讓他們太容易辦到)。
如果貴公司尚未開始改採使用者身分，那麼您一定要確實瞭解為什麼您和公司應該花費時間、金錢和心血，放棄系統管理員的身分。
舊版應用程式的確很難放手，不過如果您的應用程式就是無法以使用者身分執行的話，還是別為了它犧牲貴公司的安全性。您可以考慮將應用程式虛擬化 — 將它移到使用者確實是系統管理員的虛擬機器上。這麼一來，就能夠在必要時使用應用程式，但同時也可以把系統管理員改為使用者，來保護系統的其他部分。
請注意，我在本文當中完全沒有提到「鎖定」這個詞彙，也沒有提到由它衍生出來的任何詞彙。很多把系統管理員改為使用者視為工作一部分的人，常常會使用這個詞彙來說明。也許是我的心理學背景或是我目前所處的行銷世界作祟吧，我個人覺得為了不讓使用者有種權限被剝奪的感覺 (即使在語意學上看來的確是這樣沒錯)，還是應該盡量避免使用這個詞彙，
改把焦點擺在公司所能獲得的安全性利益上，並且妥善安置非主流案例 (例如，完全無法以使用者身分執行的特定使用者，或是非系統管理員權限不可的特定工作)。無論您是使用手動操作的東西，例如我的 Run.vbs 指令碼 (請參閱 technetmagazine.com/issues/2007/03/DesktopFiles)，或者是使用商務解決方案幫助您執行移轉 (無需讓使用者知道太多細節，只要把事情「搞定」就行了)，都必須儘快選擇走非系統管理員的路。談到採用非系統管理員的身分，經常為《TechNet Magazine》撰文的作者 Aaron Margosis，就是一位宣導此道不遺餘力的人。如果您還不熟悉他的部落格，不妨進去一探究竟 — 想尋找這方面的深入報導，來這裡絕對錯不了 (請參閱 blogs.msdn.com/aaron_margosis)。

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


 現場筆記: 多隻滑鼠，一部電腦
現場筆記
多隻滑鼠，一部電腦
Kentaro Toyama

今日的印度 是一個非常極端的 M 型國家。從一方面來看，它是一個 IT 強國，擁有受過良好教育的菁英份子負責開發因應全球電腦需求的技術。但是從另一方面來看，全國卻有 70% 的人口每天平均收入不到兩塊錢美金。這兩種極端現象同時出現在貧窮公立學校的臨時電腦教室裡面，教室裡頂多只有幾部電腦。這些電腦通常是由他人捐贈，因為學校本身沒有這個預算。
在這樣的環境中，學生人數幾乎永遠超過電腦數目。一部電腦前面擠了十個孩子根本是司空見慣的景象，而且電腦總是被最霸道的學生佔據。也對，個人電腦的「個人」，指的就是專供一個人使用。這種情況看在 Microsoft Research India 工作的我們眼裡，總想著是否能夠提供讓更多孩子使用電腦的機會。
沒想到解決方法竟然簡單到跌破眾人眼鏡：MultiPointTM 可以在一部電腦上插進多個 USB 滑鼠，讓每一個滑鼠對應到螢幕上不同顏色的游標 (research.microsoft.com/users/udaip/multipoint.htm)。這麼一來就有效建立了一個多人環境 (就像一個遊戲主控台)，以針對多滑鼠觀念所寫的教育軟體，讓許多孩子同時與一部電腦產生互動。
儘管大人一直擔心螢幕上會出現一片混亂，但是年輕學生馬上就跟上這種方式。在對國中二年級生所進行的嚴密研究當中，研究人員把五人 MultiPoint-PC 設定與一名學生一部電腦的設定互相比較之後，發現了幾種現象。第一，也許因為比較好玩的關係，當孩子們獲准每人使用一個滑鼠之後，他們與電腦和其他孩子打交道的時間便遠遠超過從前。第二，設計一些鼓勵合作的軟體應用程式，比設計純粹競爭用的軟體應用程式更為重要，以免讓某些孩子 (尤其是男孩子) 回歸缺乏教育價值的「速動」式競爭。最後一點，只要把分工合作設計為內建式功能，學生就能夠從 MultiPoint 應用程式當中，獲得與一人一部電腦方式一樣多的學習成果，至少在簡單的字彙記憶學習是如此。如需這項研究的其他相關資訊，請參考先前提供的 MultiPoint 連結。
大量購買的話，每隻滑鼠只有幾塊錢美元的成本，換句話說，只要提供 MultiPoint 教育應用程式給學校，就可以大幅降低每個孩子的電腦成本。舉個例說，一隻滑鼠 $5 美元，五個學生共用一部 $500 美元的電腦，平均每個孩子只花 $105 美元 (如果您有任何降低學生平均成本的寶貴意見，歡迎提供給負責規劃教育預算的人士)。
Microsoft 的 UP 無線潛能 (microsoft.com/unlimitedpotential) 和教育 (microsoft.com/education) 小組一致肯定 MultiPoint 對資源有限學校的價值。為了讓它快速獲得廣泛採納，他們推出一個軟體開發套件，讓教育內容開發人員得以將這個多滑鼠方案輕鬆套用到 C# 應用程式中。這個 SDK 可供大家免費下載及使用，只要是 Windows® 電腦都可以執行 MultiPoint 應用程式 (microsoft.com/downloads)。
作為「UP 無線潛能」旗下推出的其中一個方案，MultiPoint SDK 的目標是將電腦價值儘可能的延伸到更多學生身上。為了達到這個目標，我們需要您的幫忙。凡有意嘗試 MultiPoint 教育應用程式者，請不吝告訴我們，我們會在 MultiPoint 網站上公布最佳意見的連結。
接下來 Microsoft Research India 和終端機服務產品小組將考慮提供另一種共用電腦的方法：分割螢幕，讓兩個人、兩個鍵盤和兩隻滑鼠共用一部電腦和一個監視器。後者是從中間進行分割，讓不同的作業系統工作階段得以各自執行。

Kentaro Toyama 是 Microsoft Research India (research.microsoft.com/india) 的助理常務董事，暨新興市場小組 (research.microsoft.com/research/tem) 的首席技術研究員，負責為全球經濟弱勢社區開發技術。


 Windows 機密文件: 16 位元圖示真的過氣了
Windows 機密文件
16 位元圖示真的過氣了
Raymond Chen

我曾在 2008 年 2 月份的《Windows 機密文件》專欄中提到，Windows® 的確有淘汰部分功能。這些通常都是慢半拍又不起眼，每順利完成一件事，產品小組就要默默慶祝一次的功能。另外還有一項未出現在 Windows Vista® 的功能，就是 32 位元碼存取儲存在 16 位元模組 (通常是 16 位元 EXE 和 16 位元 DLL) 中之圖示的能力。
別激動，別忘了，16 位元碼還是可以存取儲存在 16 位元模組中的圖示；因為這些動作都是在 16 位元模擬層內進行。被淘汰的是從 32 位元碼存取那些圖示的能力，說得更明確一點，就是 32 位元圖示擷取函數 (例如 ExtractIcon 函數) 從 16 位元 DLL 載入那些圖示的能力。
從 16 位元模組擷取圖示的 32 位元碼，無法使用像 FindResource 這樣的核心函數來尋找檔案中的圖示，它必須實作自己的迷你載入器來剖析 16 位元模組標頭，尋找資源表，然後再剖析資源表，尋找所要的圖示資源。完成這些動作之後，才能將像素轉換成圖示。
您也知道，負責這個任務的程式碼已經年老力衰，在剖析可能損毀的位元時，很有可能因為犯錯或是受到惡意攻擊而發生錯誤。於是效能小組會要求變更開啟檔案的方法，以改善網路效能，因為不同的開啟和共用模式，會產生不同的網路快取效果。而可靠性小組也可能會要求重新寫入剖析碼，以避免使用記憶體對應檔案。最後維護這類程式碼的成本便開始超過它本身所提供的價值，您說，還有誰願意再寫 16 位元程式呢？
現在，只要 16 位元模擬層還在，16 位元程式仍然可以執行 (沒錯，64 位元 Windows Vista 沒有 16 位元模擬層，不過這不是 Windows XP 開倒車；因為 64 位元 Windows XP 也沒有 16 位元模擬層。雖然沒有因此改善什麼，倒也沒有任何惡化情況)。
Windows Vista 所失去的，只是從 32 位元程式執行 ExtractIcon，以及從 16 位元 DLL 取得圖示的能力而已。如果您的 [開始] 功能表有通往 16 位元程式的捷徑，該捷徑的圖示現在會變成一般程式圖示，因為 Windows Explorer 無法再從它的主要 EXE 擷取 16 位元程式的圖示了。這也不是什麼大不了的損失。不過如果您一直耿耿於懷的話，也可以編輯捷徑的內容，從 32 位元模組提出一個圖示給它。
如果一定要說少了這個功能會有什麼問題的話，那就是由特定圖示編輯工具產生的圖示了。因為某種原因，這個程式預設把圖示儲存為 16 位元 DLL 中的資源，也就是說，您再也無法從 32 位元碼存取那些圖示了。如果要暫時解決這個問題，很簡單，只要把那些圖示庫重新儲存為 32 位元 DLL 中的資源就行了。
我相信總有一天 (就算現在還沒有) 會有人撰寫一個小程式，從 16 位元 DLL 擷取所有的圖示，然後以那些圖示建立一個 32 位元資源專用的 DLL，讓那些還在使用 16 位元 DLL 舊圖示的人，能夠在 [開始] 功能表上的捷徑繼續沿用。不過話說回來，就算您真的寫出這個程式，恐怕也沒有人真正用得著。因為，向 Windows 使用者介面小組要求撰寫這類程式的人數根本就是：零。

Raymond Chen的網站「The Old New Thing」以及同名著作均探討 Windows 的歷史和 Win32 程式設計。他是一位嚴守規矩分際的人。