 TechNet Magazine September 2007

TechNet Magazine September 2007

Windows Vista: 使用 BDD 2007 部署 Windows Vista

您的企業要從 Windows 2000 或 Windows XP 移轉至 Windows Vista，且專案必須由您來負責。別煩惱，這裡的逐步指南，將引導您使用 Business Desktop Deployment 2007 Solution Accelerator 來簡化 Windows Vista 的部署工作。

Michael Niehaus Windows Vista: Windows Vista 備份技術指南

許多人往往因為忽略了備份工作而後悔莫及。別再為自己找藉口了，現在全新的 Windows Vista 備份及還原中心提供各項功能，可讓您輕鬆保護資料，避免資料受損。進一步了解如何使用 Windows Vista 規劃完善的復原策略。

Christine Fok Windows Server: 11 個管理 Active Directory 的基本工具

在大型組織中，即使是最常見的 Active Directory 工作，例如新增及修改物件，也是既繁瑣又費時。這 11 個工具可以使 Active Directory 的管理輕鬆許多。

Laura E. Hunter Windows Server: 重新引發 Active Directory 標記物件

在每一個 Active Directory 嚴重損壞修復計劃中，都應該善用一些基本訣竅和工具。重新引發標記是這些技巧的其中之一，它是不需要使網域控制站離線而能修復已刪除物件的唯一方式。以下將引導您如何在 Active Directory 中尋找及修復標記。

Gil Kirkpatrick 通訊: 使用 Office Communications Server 2007 促進使用者的通訊能力

整合通訊的時代已經來臨。讓我們導覽 Microsoft Office Communications Server 2007，並了解整合訊息、語音、視訊和會議等功能，如何有助於提高產能以及強化組織內部的遠距共同作業功能。

Alan Maddison 編輯的話: 多元化的學習途徑

Joshua Trupin 讀者信件: 相關問題解答

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

Greg Steen SQL 問題與解答: CPU 瓶頸、還原和移動資料庫…等等

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

一般的 Windows 磁碟重組工具可以最佳化您硬碟機上的大多數檔案。但是某些項目，例如 Windows 分頁檔和登錄 Hive，卻令大多數的磁碟重組工具束手無策。由 Mark Russinovich 為 Sysinternals 建立的這項公用程式，可以成功地重組其他工具無法處理的檔案。

Lance Whitney The Cable Guy: 強式和弱式主機模型

多重主目錄主機可以透過同步連線到多個網路來提供增強的連接性。但是，在多重主目錄主機上執行的服務遭受攻擊的風險會比較高。為了協助您防止攻擊，本文涵蓋了多重主目錄主機的各種主機模型，以及在 Windows 中支援這些主機模型的情況。

Joseph Davies Windows PowerShell: 確保殼層的安全性

在設計 Windows PowerShell 時，Microsoft 將安全性定位為重要的考量。而且顯而易見。了解一下其中一些關鍵的安全性功能及設定，例如認證處理和執行原則，如何確保 Windows PowerShell 不會重蹈 VBScript 問題的覆轍。

Don Jones 嗨，Scripting Guy！: 如何建立關係/關聯性？

關聯式資料庫的設計正是為了要處理一對多的關聯性。這會使要查詢此類型資料庫的指令碼較難撰寫。但是不必擔憂，因為 Scripting Guy 會引領您完成任務。

The Microsoft Scripting Guys Exchange 問題與解答: 安裝、訊息日誌、儲存選項及其他主題

了解如何使用訊息日誌的功能來監控貴公司的電子郵件、查明 Office 2003 的使用者是否可以使用 Unified Messaging、檢查您 Exchange 2007 實作的儲存選項，以及取得如何使用舊版 Outlook 連接到 Exchange 2007 的答案…等等。

KC Lemson and Nino Billic 安全性監控: 使用者帳戶控制的長期影響

雖然已經有無數的文章討論此主題，但大家關於使用者帳戶控制仍然有很多疑問題和錯誤的觀念。本文將忠實探討什麼是 UAC、什麼不是 UAC，以及它對於您管理系統的方式有何影響。

Jesper M. Johansson 桌面檔案: 使用 Windows PE 進行 PC 修復

Windows Vista 提供一些寶貴的工具讓系統修復更輕鬆。不過對於多元的大型企業而言，現成的解決方案不一定合用。如果您的公司規模較大，而且需要建置自訂的自我修復解決方案，千萬別錯過本文的精彩討論內容，以瞭解如何使用 Windows PE 來建置自己的修復解決方案。

Wes Miller 現場筆記: 免費餐點以及培訓提示

優良的使用者教育制度能夠避免問題的發生。因此，請勿忽略非正式培訓課程的重要性，而且一定要在下課後遊蕩一下，看看使用者是否有不好意思在課程上提出的問題。

Michael Dragone Windows 機密文件: 已知 DLL 的拉鋸戰

已知 DLL 的功能之所以會包含在 Windows 中，是為了要提升效能。探索此功能的運作方式，以及深入了解此功能的演變過程。

Raymond Chen


 Windows Vista: 使用 BDD 2007 部署 Windows Vista
Windows Vista Michael Niehaus

使用 BDD 2007 部署 Windows Vista
摘要:
  • BDD 2007 Solution Accelerator
  • 準備影像
  • 驅動程式和應用程式套件

這項工作已經拖延了一陣子，現在還是得開始進行了。您服務的公司有數百、甚至於數千部電腦，全部需要從 Windows 2000 或 Windows XP 移轉到 Windows Vista。而且您的團隊必須完成這項任務。
要從哪裡開始呢？
若您已經有多年的 Windows® 作業系統安裝經驗，或許不難發現從 Windows NT® 3.5 到 Windows XP 的改變其實並不多。安裝和設定過程頗為一致，使用工具皆相同，而整體程序也沒有改變。但是在安裝 Windows Vista® 時，整個程序經過重新設計，並加入了許多新工具。若要好好了解這些變更及其影響，請參閱 2006 年 11 月號 TechNet Magazine 的＜您不可不知關於部署 Windows Vista 的十大事項＞文件，亦可從網路取得：technetmagazine.com/issues/2006/11/Deployment。

我要如何學習新的程序和工具？
您有兩個選擇：
  1. 學習每一項新工具、閱讀所有現有的文件、了解如何將這些內容應用於您目前的程序中、做必要的調整、然後驗收結果。
  2. 利用可以直接為您完成上述工作的捷徑。
您當然可以選擇第一個選項，但可能要閱讀的是一本書，而非一篇雜誌文章。我建議大家選擇第二個選項：您可以使用的方法，就是 Business Desktop Deployment (BDD) 2007 Solution Accelerator。您可以透過 Microsoft® Desktop Deployment Center 下載，網址為：microsoft.com/desktopdeployment。
BDD 2007 Solution Accelerator 是一組工具、指南和逐步程序，可簡化 Windows 作業系統部署過程，並且將 Windows Vista 所有新部署程序和工具全數整合。
若要開始使用 BDD 2007，請先識別您要安裝 BDD 2007 的電腦是 Windows XP 或 Windows Server® 2003。安裝之前，請先安裝 Microsoft .NET Framework 2.0 以及 Microsoft Management Console (MMC) 3.0。接下來，即可安裝 BDD 2007。安裝完成後，即可在 [開始] 功能表的 [BDD 2007] 資料夾中檢視版本資訊。接著使用 Deployment Workbench 捷徑啟動 MMC 嵌入式管理單元 (請參閱 [圖 1])。
圖 1 啟動 BDD 2007 Deployment Workbench
圖 1 啟動 BDD 2007 Deployment Workbench
接下來，最好查看一下 [Information Center] (資訊中心) 中的資訊，尤其是 [Getting Started] (開始使用) 檢查清單和文件。請確實下載最新的消息和元件清單，方法是用滑鼠右鍵按一下 [Components] (元件) 節點，並選擇 [Check for Updates] (檢查更新)。
這裡還需要一項必要條件：Windows 自動化安裝套件 (AIK)。BDD 2007 需要有 Windows AIK 中的工具，許多功能才能執行。您可以利用兩種不同的方式取得 Windows AIK：從 Microsoft 下載中心 (go.microsoft.com/fwlink/?LinkId=85377) 下載，或者使用 Deployment Workbench 的 [Components] (元件) 節點取得。不論用哪種方式，下載的檔案蠻大的，因此要有心理準備，下載的時間會比較長。
安裝 Windows AIK 完成之後，即可移至下一階段：取得您所需的所有檔案，以便執行 Windows Vista 部署。

我需要哪些檔案？
接下來，您需要取得 Windows Vista 安裝檔案、要安裝的應用程式、硬體所需的驅動程式，以及您可能要使用的 Windows Vista 更新或語言套件。這些全數都會複製到安裝 BDD 2007 時建立的發佈共用目錄結構中。
建立個人化的影像
本文所討論的步驟，說明如何直接從 Microsoft 產品 DVD 部署標準的 Windows Vista 影像。但是您或許想要部署個人化的影像，其中包含所有電腦都需要的其他應用程式 (例如 2007 Microsoft Office System)。這樣的爭議由來已久：是否應該維持最小 (「輕薄」) 的影像大小，並於部署階段再安裝其他程式，抑或者該建立較大 (「厚重」) 的影像，以預先安裝所有程式？這個問題的答案通常必須根據某些因素而定，例如可用來部署的時間、建立和維護影像所付出的系統管理負荷、網路頻寬...等等。在多數情況下，當然是愈輕薄愈好，不過這得由您自己決定。
不論您決定要在影像中包括哪些內容，請確認自訂影像的建立過程可完全自動化。有了自動化程序，要更新影像就十分容易，只要在處理過程中加入另一個步驟，接著重新執行整個程序，再擷取最後的新影像即可。
那麼要如何結合 BDD 2007 來達到這個目的呢？其實非常簡單：
  1. 建立一個組建來建立自訂影像。
  2. 為此組建修改工作順序，以包括所有自訂步驟。
  3. 從實驗部署點 (由 Windows PE ISO 開機) 執行「從無到有」部署，並選取該組建。
  4. 指定您要加入工作群組。
執行這些步驟時，部署精靈會顯示另一個窗格。
藉由選擇擷取參考電腦的影像，BDD 2007 將自動執行 Sysprep 以便作業系統準備開始進行擷取，接著重新啟動 Windows PE 並執行 ImageX.exe，以擷取新的 WIM 影像。如此一來，您就可以將影像匯入 Deployment Workbench，並於下次部署時使用。
使用 BDD 2007 擷取參考影像
使用 BDD 2007 擷取參考影像

首先，讓我們複製作業系統安裝檔案。插入 Windows Vista DVD (最好是大量授權媒體，因為這樣每次安裝時就不需要有個別的產品金鑰)，接著用滑鼠右鍵按一下 Deployment Workbench 中的 [Operating System] (作業系統) 節點，並選擇 [New] (新增)，以啟動 [新增作業系統精靈]。選取 [Full Set of Source Files] (完整的來源檔案) 並指定 DVD 光碟機路徑 (若您已將這些檔案複製到其他位置，請指定適當的路徑)。完成精靈，並接受其他的預設值。現在，您點選 [Operating Systems] (作業系統) 節點時，應該會在出現的清單中看到一或多個作業系統影像 (視您使用的媒體而定)。
接下來是應用程式。您目前尚無須新增任何應用程式，但如果增加了應用程式，則可於部署 Windows Vista 時從清單中選取這些程式。在理想狀態下，最好指定某命令列來自動安裝應用程式，這樣使用者就不需要介入，因為不應該要使用者等待應用程式開始安裝。為了解上述方法的實際操作，請在 Deployment Workbench 中的 [Applications] (應用程式) 節點上，選擇 [New] (新增) 命令，嘗試新增單一應用程式，接著完成 [New Application Wizard] (新增應用程式精靈) (請參閱 [圖 2])。
圖 2 將應用程式新增到 Workbench
圖 2 將應用程式新增到 Workbench
接下來是作業系統套件。共有三種您可能感興趣的套件類型：語言套件、安全性更新，以及 Windows Vista 元件。
語言套件可以讓 Windows Vista 使用多種不同的語言操作。有關支援的語言等詳細內容，請參閱 microsoft.com/globaldev/vista/Vista_Language_Support.mspx。語言套件封裝為 CAB 檔，所有軟體保證 (Software Assurance) 授權計劃的客戶均可從 licensing.microsoft.com 下載，若您執行 Windows Vista Ultimate，亦可由 Windows Update 取得 (請注意，只有 Windows Vista Enterprise 和 Windows Vista Ultimate 可支援在同一部電腦上安裝多重語言套件)。
Windows Vista 安全性更新通常每月推出，並可從下列網址下載各個 MSU 檔：microsoft.com/technet/security/bulletinsandadvisories。
您也可以加入新的 Windows Vista 元件，例如 Windows PowerShell™。這些元件可透過 Microsoft 下載中心 (microsoft.com/downloads) 下載，且亦封裝為 MSU 檔案。
幕後作業中，這些全都是元件，又稱為套件，因此位於 [作業系統套件] 節點。無論是透過線上 (若作業系統執行中) 或離線 (作業系統未執行) 作業，這些元件都可全數插入 Windows Vista。就 BDD 2007 而言，一律必須在離線狀態插入，時間則是在 Windows Vista 影像展開並置於磁碟上之後，並且在首次啟動之前。
此外還有另一項挑戰：MSU 檔案是為了線上安裝而設計，於 Windows Vista 執行的狀態下使用 WUSA.EXE 更新安裝程式。然而在本例中，最好在離線時安裝這些更新。為此，您需要包含實際元件的 CAB 檔案。這些 MSU 檔案其實本身就是 CAB 檔，其中包含了真正的元件 CAB 檔案。您可使用命令，自行從 MSU 檔案擷取這些 CAB 檔案，例如：
EXTRACT.EXE file.msu -F:*.CAB C:\
這樣就能讓您取得需要匯入的 CAB 檔。請注意，Microsoft 已發行 BDD 2007 的修補程式，可自動進行這項擷取工作。一旦完成安裝，即無須此手動步驟；亦即您只要將 BDD 2007 指向 MSU 檔案，它就能自行完成所有工作。如需有關此修補程式的詳細資訊，請參閱 support.microsoft.com/kb/937191。
若要將這些元件新增到 Deployment Workbench，請用滑鼠右鍵按一下 [OS Packages] (作業系統) 套件節點，並選擇 [New] (新增) 以啟動 [New Package Wizard] (新增套件精靈)。指定您欲新增之套件所在的資料夾路徑。
最後，可能需要用於執行 Windows Vista 的電腦硬體驅動程式。從廠商的網站或者 Microsoft Update 找出您需要的驅動程式，下載後即自其封裝中擷取。最後一個步驟或許較難處理，但最終結果應為原始驅動程式檔案：.inf、.sys、.dll 和驅動程式本身所需的相關檔案。
在擷取驅動程式檔案時，請用滑鼠右鍵按一下 [Drivers] (驅動程式) 節點，並選擇 [New Deployment] (新增部署)，以執行 [New Driver Wizard] (新增驅動程式精靈)。Workbench 會掃描目錄結構以尋找所有 .inf 檔案，因此別擔心如何清理擷取過的目錄結構。
待驅動程式匯入後，Deployment Workbench 會建立所有驅動程式明細的目錄，其中包括其支援的平台、製造商和版本，並列出該驅動程式支援的隨插即用 (PnP) ID 清單。

這些驅動程式有何用途？我是否要將這些插入稍早之前匯入的作業系統影像中？
BDD 2007 不會針對匯入的作業系統影像進行任何修改動作。相反的，驅動程式是在部署的過程中插入的。基本程序如下：
  1. 在部署的電腦上執行公用程式 (Microsoft.BDD.PnpEnum.exe)，識別出電腦上所有 PnP ID。
  2. 在驅動程式目錄中查詢每一個 PnP ID。每次找到符合的項目，就把所需的驅動程式檔案複製到電腦上。
  3. 待影像套用於磁碟之後，且於 Windows Vista 首次執行之前，指示 Windows Vista 安裝程式將驅動程式插入作業系統中。此順序有其必要，因為作業系統可能需要部分驅動程式 (例如大型存放裝置的驅動程式) 才能啟動。

我是否已經可以開始部署了？
在部署之前，還得完成幾個步驟。首先，您需要定義一個組建，以建立共用中之作業系統與適用設定的關聯性，以及安裝與設定作業系統所需執行的工作。
若要建立此組建，請用滑鼠右鍵按一下 [Build] (組建) 節點，並選擇 [New] (新增) 以啟動 [New Build Wizard] (新增組建精靈)。指定一個組建 ID (選擇任一簡單數值，不含空格或特殊字元) 以及組建名稱和說明，在執行作業系統部署時兩者都會出現 (請參閱 [圖 3])。接著請選取您要安裝的作業系統，並指定要使用的基本設定。
圖 3 指定基本組建資訊
圖 3 指定基本組建資訊

好了，現在可以開始部署了嗎？
還有一件事得先完成：部署點。簡言之，這個網路共用中包含了目前為止所有已收集的檔案、組建詳細內容，以及部署程序中使用的 Windows PE 影像。建立部署點的方式就和先前所看過的其他步驟差不多：用滑鼠右鍵按一下 [Deployment Points] (部署點) 節點，並選擇 [New] (新增)。選取 [Lab] (實驗) 或單一伺服器部署 (請參閱 [圖 4]) 並接受其他預設值。
圖 4 選擇部署點類型
圖 4 選擇部署點類型
完成精靈後，用滑鼠右鍵按一下清單窗格中的新部署點，並選擇 [Update] (更新) 以產生共用和 Windows PE 影像。
還記得您之前新增的驅動程式嗎？Windows PE 也需要這些驅動程式，至少需要網路和大型存放裝置的驅動程式，這樣更新程序才能自動將驅動程式加入 Windows PE 影像中。

我們是否已經可以開始部署了？
可以了！首先，讓我們試著在新電腦上部署。從 \distribution\boot 資料夾取得 LiteTouchPE_x86.iso 檔案，並使用您偏好的 CD 寫入軟體燒錄至 CD-R，或者從 Microsoft (go.microsoft.com/fwlink/?LinkID=77796) 下載並使用 cdburn.exe 工具。使用光碟機開機，以啟動 Windows PE，並顯示如 [圖 5] 的初始歡迎使用精靈。
圖 5 準備開始進行部署
圖 5 準備開始進行部署
選擇 [Run the Deployment Wizard] (執行部署精靈)，並按 [Next] (下一步) 開始執行。您可以在這裡選擇您已定義的組建、任何新增過的應用程式，以及所有已匯入的語言套件。您也可以選擇加入網域、指定電腦名稱，並組態其他各種設定。您甚至可以指定是否要自動擷取新的自訂影像 (使用 Sysprep、Windows PE 和 ImageX 來建立新的影像檔)。
部署可能需要花一些時間 (視電腦的速度和類型而定)，但不需要使用者互動。部署精靈完成時，隨即顯示摘要畫面，讓您了解處理過程中是否有警告或錯誤記錄。這樣可以讓您快速確認部署是否成功，黃色或紅色的摘要畫面表示還有需要注意的事項，而白色則表示一切正常。
現在來嘗試某部正在執行 Windows XP 的電腦。從命令提示字元，建立至您在 BDD 2007 伺服器上所建立 Distribution$ 共享的磁碟機對應，接著執行 LiteTouch.vbs 開始部署：
NET USE M: \\MyServer\Distribution$
cscript.exe M:\Scripts\LiteTouch.vbs
如此一來，即可啟動與先前相同的部署精靈，唯現在有些新選擇 (請參閱 [圖 6])。
圖 6 執行 Windows XP 之電腦的選擇
圖 6 執行 Windows XP 之電腦的選擇
若您選擇 [Refresh] (重新安裝) 這台電腦，現有作業系統就會遭到移除 (您可以選擇先使用 [User State Migration Tool] (使用者狀態移轉工具) 來擷取使用者資料和設定，此工具可使用 [Components] (元件) 節點下載，如同之前 Windows AIK 的做法)，並執行 Windows Vista 的全新安裝。您也可以選擇「升級」這部電腦，讓 Windows Vista 安裝程式自行處理現有作業系統的升級動作，保留電腦上目前的應用程式、資料及設定。您選擇的選項必須根據各種不同的因素而定，不過大多會選擇執行重新安裝，以便從全新、已知的狀態開始進行。

我懂這些就夠了嗎？
那麼 Windows XP 呢？
如果仍然部署 Windows XP 又會如何？別擔心，您仍可使用 BDD 2007 來幫助您完成該項程序。步驟皆可套用；只要使用 Windows XP 安裝檔案建立初始組建，擷取新的 Windows XP Windows Imaging (WIM) 影像 (部署 Windows XP 影像遠比執行自動安裝更快速)，然後使用該 WIM 檔進行部署工作即可。
請切記，和 Windows Vista 部署工作比較起來，部署 Windows XP 有幾項比較複雜的問題：
Windows XP 大型存放裝置驅動程式需要另行設定，例如 TEXTMODE 資料夾、unattend.txt 設定以及 sysprep.inf 設定。當然，這是因為大型存放裝置驅動程式無法插入現有的 Windows XP 影像中，因此每次需要加入其他大型存放裝置驅動程式時，都要擷取新影像。此外，Windows XP 影像需要硬體抽象層 (HAL)，因此您可能需要兩個到三不同的影像。最後，語言套件和安全性更新無法離線插入 Windows XP，因此需要待 Windows XP 開始作用後安裝。
若您使用 BDD 2007 部署 Windows XP，那麼一旦時機成熟，您就能開始使用 Windows Vista。

到目前為止所探討的，其實只是表面功夫而已。不過看過完整的程序，可以讓您了解到所有新工具互相配合的方式，無須一項一項摸索。現在您可以深入探究 BDD 2007 指令碼和記錄，以便查看已執行了哪些動作。您可以自行建立自訂影像，並加入 BDD 2007 進行部署，而非使用標準 Windows Vista 影像。您可以在 DVD 媒體或 USB 快閃磁碟機中載入建立的影像。亦可整合 SMS 2003 及其作業系統部署功能套件 (OS Deployment Feature Pack) 到程序中。

我可以在何處取得更多資訊？
請先閱讀我先前提及的所有文件，大概有上千頁，其中是依部署專案中的不同小組做區分。您亦可造訪之前提到的 microsoft.com/desktopdeployment 網站。加入 microsoft.public.deployment.desktop 新聞群組，其中有許多像您一樣的 IT 專家，會詢問有關 Windows 部署的各種問題。建議您也到協力廠商的網站上看看，例如 deployvista.com 和 myitforum.com，其中都有大量 BDD 2007 和 Windows Vista 部署的相關資訊。請參考新的 Windows Vista Resource Kit 一書 (microsoft.com/mspress/books/9536.aspx)，由 Microsoft Press 出版。也請造訪我的部落格：blogs.technet.com/mniehaus，以參考 BDD 2007 各個部分的討論。您還可以與當地的 Microsoft 代表詢問有關當地所舉辦的 BDD 2007 和 Windows Vista 訓練研討會。最後，請參閱「部署資源」資訊看板，以取得其他資訊。
若您有參與 Microsoft Office System 的軟體保證 (Software Assurance，SA) 授權計劃，請利用 Desktop Deployment Planning Services (microsoft.com/licensing/sa/benefits/deployment.mspx)，讓 Microsoft 或者 Microsoft 合作夥伴花幾天的時間幫助您設計一份計劃，甚至在您工作的場所進行概念驗證的實驗。
部署資源
  • Microsoft 桌面部署中心 microsoft.com/desktopdeployment
  • 您不可不知關於部署 Windows Vista 的十大事項 technetmagazine.com/issues/2006/11/Deployment
  • Microsoft .NET Framework 2.0 go.microsoft.com/fwlink/?LinkId=94601
  • Microsoft Management Console (MMC) 3.0 for Windows Server 2003 x86 go.microsoft.com/fwlink/?LinkId=94602
  • 安全性公告和諮詢 microsoft.com/technet/security/bulletinsandadvisories

Michael Niehaus 是 Microsoft Solution Accelerators 小組的系統設計師，他負責為 Business Desktop Deployment 開發最佳作法、工具及指令碼。您可透過電子郵件地址 michael.niehaus@microsoft.com 與他聯絡。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 Windows Vista: Windows Vista 備份技術指南
Windows Vista Christine Fok

Windows Vista 備份技術指南
摘要:
  • 檔案備份及還原
  • Windows Complete PC 備份及還原
  • 系統還原
  • 陰影複製

有太多人總是等資料已經遺失，一切無法挽回之後，才開始考慮資料備份問題。這種事情根本不應該發生，但不幸事實就是如此。Windows Vista 的目的在於更輕鬆的進行備份工作，並採用全方位的功能完整保護您的資料。
常見的系統還原功能經過重新設計，不但更加健全，還可支援更多種系統修復狀況。檔案備份功能在改良後，可以透過更簡便的方式完整保護資料，並且還加入兩項新功能：Windows® Complete PC 備份及還原和陰影複製。
所有上述功能都必須仰賴磁碟區陰影複製服務。這項服務可建立磁碟區的即時複本 (亦即「陰影複製」)，並追蹤陰影複製之間的變化。
以上四項功能都位於 [備份及還原中心] (請參閱 [圖 1])，雖然所有功能都可用來備份與還原資料，但其實每一項功能截然不同。不過這四項功能合併使用，即可保護資料在電腦使用期間不受到各種損害。
圖 1 Windows Vista 中的 [備份及還原中心]
圖 1 Windows Vista 中的 [備份及還原中心]

檔案備份
排定 Complete PC 備份
安排定期的 Complete PC 備份，可確實保有您整部電腦中最新的內容。Complete PC 備份無法透過控制台排定，但是您可以在工作排程器中建立新工作來解決此問題。若您選擇排定 Complete PC 備份工作，我建議定期監視以確認是否成功完成備份。為何需要這麼做？因為此方法並不會在磁碟空間或其他暫時性問題導致備份失敗時，透過快顯畫面進行通知。然而這樣的方法不可用來取代應定期執行的檔案備份功能。您可以利用下面的方法，使用工作排程器來排定 Complete PC 備份：
  1. 到 [工作排程器] (位於 [開始] 功能表的 [所有程式] 中，[附屬應用程式] 的 [系統工具] 資料夾中)。
  2. 按一下 [建立工作]。
  3. 到 [一般] 索引標籤。
  4. 鍵入描述性名稱，例如 Scheduled Complete PC Backup。
  5. 若您希望無論您是否登入的情況下皆執行工作，請按一下 [不論使用者登入與否均執行]。
  6. 按一下 [以最高權限執行]。
  7. 到 [觸發程式] 頁面。
  8. 按一下 [新增]，接著指定排定的備份將於何時以及間隔多久進行一次。
  9. 到 [執行] 頁面。
  10. 按一下 [新增]。
  11. 在 [程式或指令碼] 底下，鍵入 wbadmin。
  12. 在 [新增引數 (可省略)] 中，鍵入以下命令，以便視需要調整目標磁碟機代號。
    Start backup –allcritical –backupTarget:D: -quiet
    若您想加入系統、開機或 Windows 修復環境磁碟區以外的其他磁碟區，請使用下列替代陳述式，來取代 E 和 F 等適當的磁碟機代號 (以逗號隔開)：
    Start backup –allcritical –backupTarget:D: -include:E:,F: -quiet
    請注意命令必須包括 allcritical 旗標。若未包括此旗標，可能導致備份中遺失重要的系統磁碟區，因而造成還原時的錯誤。
  13. 設定任何其他工作的相關設定。
  14. 按一下 [確定]。

假設我買了一部新的筆記型電腦。在複製各種檔案 (包括相片、Microsoft® Word 文件...等等) 到我的系統內，安裝應用程式，並且下載最新的 Windows Update 之後，我決定進行檔案備份。因此我將筆記型電腦連上外接式硬碟，並且到 [備份及還原中心]。按下 [備份檔案] 按鈕時，出現精靈引導我完成設定。其中詢問我備份目標 (在這裡是指外接式硬碟)、備份的檔案類別 (例如相片)，以及何時進行備份工作。
檔案備份是根據類別式的方法來指定有哪些檔案需要備份。由於來源必須為 NTFS，因此目標硬碟採用 NTFS 或 FAT 格式皆可。判斷檔案是否與特定類別相關聯時，則依據以下三項要素：MIME 類型、應用程式關聯，以及副檔名。
若您要備份的檔案不屬於任何類別，請選擇 [其他檔案] 類別。此類別包括 Windows 無法識別其副檔名的檔案。不過這種類別不支援可執行檔以及系統檔案。這些類型的檔案因為鮮少是使用者資料，因此無法以此功能進行備份。若您真的要使用此機制來備份系統和可執行檔案，可以將這些檔案置於 .zip 檔中，並選取精靈的 [壓縮檔案] 類別。
由於這是我第一次使用新筆記型電腦的備份功能，因此要立刻執行完整備份，也就是完整備份所有已選取類別的檔案。之後只需要執行增量備份即可。在檔案備份中提到的增量一詞，指的是僅追蹤全新或更新過的檔案。例如，若您針對一個舊的 Word 文件進行修改，檔案備份工具會同時完整保留舊文件與更新後的文件 (單一完整備份以及之後建立循序增量備份的組合，即稱為備份組)。
您應該偶爾執行完整備份，而非一直執行增量備份。應該執行完整備份的因素，包括上次完整備份至今的時間長度、要備份的檔案數量、儲存備份的 CD 或 DVD 數量...等等。這是為了確保永遠有可使用的完整基準備份。
備份的資料會以 .zip 檔案格式儲存 (每個檔案最大容量為 200MB)。這使得資料能夠通用存取。例如，只要直接瀏覽備份媒體，即可將資料還原到非 Windows Vista 的電腦上。備份資料會儲存在個別的檔案中，並可合併多張光碟。若其中一片光碟失敗，其他媒體中的備份資料仍可存取。
在檔案備份中，磁碟區陰影複製服務會用來為其他應用程式已開啟或使用中的檔案，建立一致的複本。在備份過程中，備份應用程式會讀取這些一致的複本。例如，在備份經常由 Microsoft Outlook® 開啟的 .pst 檔案時，這種方法就十分好用。磁碟區陰影複製服務可確保備份的 .pst 檔案處於一致的狀態中，以便於還原時存取。
檔案備份不會自動刪除。不過，如果您的空間不足，可以手動刪除檔案備份。在此建議您：請務必刪除整個備份組，而非刪除個別增量備份。
另外，我必須告訴您應儘可能避免將檔案備份複製到其他位置。若您必須備份到其他地方，請切記唯有將單一原始備份媒體移至另一單一目標媒體的情況下，才能複製成功。例如，您可以將一片 CD 中的備份資料複製到一片 DVD 上，但是無法將多片 CD 的備份資料複製到單片 DVD 上。您在移動備份時，必須複製以電腦名稱命名的備份資料夾加上 mediaid.bin 檔案，這兩者皆位於備份媒體的根目錄中。請注意，若您要還原移動過的檔案，必須在備份控制台上選取 [進階還原] | [還原在不同電腦上備份的檔案]，才能找到這些檔案，因為電腦上的備份類別目錄並不知道此新備份的位置。

Complete PC 備份
待新筆記型電腦全數設定組態完成後，我打算進行完整備份，以保護包括作業系統、安裝的應用程式、組態設定以及更新過的所有內容。我使用 Complete PC 備份功能，以便日後若硬碟損壞或其他問題發生時，可用來復原電腦。如此我才不需要重新安裝所有應用程式，還得重新進行所有組態設定。第一次執行時，此功能會執行所選取磁碟區之所有區塊的完整備份，未存放資訊的區塊除外。接下來的備份工作則為區塊層次的差異 (稍後會針對此議題有更詳細的介紹)。
在執行備份之後，[備份及還原中心] 的控制台就會更新 (請參閱 [圖 2])。其中會提供如備份執行時間以及存放位置等資訊。
圖 2 [備份及還原中心] 提供有關先前備份的詳細內容。
圖 2 [備份及還原中心] 提供有關先前備份的詳細內容。
雖然 Complete PC 備份和檔案備份兩者皆執行備份工作，但前者的運作方式則與後者大異其趣。Complete PC 備份是以虛擬硬碟 (.vhd) 格式，建立整部電腦的區塊層次影像備份。首次執行完整備份時，引擎會掃描來源磁碟，並且將包含資料的區塊複製到 .vhd 檔案中，存放於目標磁碟上。雖然備份資料未經壓縮，但算精簡。
下次執行 Complete PC 備份時，僅會將全新和變更過的資料寫入 .vhd 檔，同區塊的舊資料則移動至陰影複製儲存區。磁碟區陰影複製服務會用來計算快照之間的差異，以及處理舊資料移出目標磁碟陰影複製區的過程 (請參閱 [圖 3])。此方法可以讓備份的速度更快 (僅備份變更的區塊)、更有效率 (資料以精簡的型態儲存)。請注意，備份應用程式會定義目標磁碟上陰影複製儲存空間的最大量。有關如何定期或自動使用 Complete PC 備份系統的逐步說明，請參閱「排定 Complete PC 備份」資訊看板。
圖 3 資料如何在 Complete PC 備份及還原中移動。
圖 3 資料如何在 Complete PC 備份及還原中移動。
還原資料時，區塊會還原至原始位置。若您希望從舊版的備份中進行還原，引擎會讀取陰影複製區，並還原適當的區塊。
請注意，Complete PC 備份只能備份 NTFS 格式的磁碟。若備份目標為硬碟機，亦須為 NTFS 格式。

系統還原
系統還原預設為啟用。我選擇 [使用系統還原修復 Windows] 來存取 [系統還原] 精靈，此功能位於 [備份及還原中心] 左上角 (亦可於 [開始] 功能表的 [所有程式] 中，選擇 [附屬應用程式] 的 [系統工具] 進入此功能)。如果我選取 [選擇其他還原點] 並按 [下一步]，即可看見我在設定筆記型電腦、安裝應用程式，以及執行備份時，於各處已建立的還原點。
只有開機磁碟區上的還原點會預設為啟用，即使硬碟上有多個磁碟區時亦同。還原點會於應用程式和驅動程式安裝時自動建立，選取的磁碟區也會每天自動建立 (若當日尚未使用還原點)。還原點亦可手動建立，方法是選擇 [系統] 控制台小程式中的 [系統保護] 選項。執行檔案備份及 Complete PC 備份時所建立的陰影複製，亦可當作還原點使用。
在 Windows XP 中，系統還原會使用檔案系統篩選器來追蹤系統檔案變更。在 Windows Vista 中，系統還原是利用磁碟區陰影複製服務，在選取的磁碟機上追蹤區塊層次的變更。這使得系統還原功能更加健全，也允許其支援種類更多的修復狀況。
此外，現在新的系統還原在一般 Windows 安裝離線時仍可執行。這是利用 Windows 修復環境辦到的，在即使 Windows 無法啟動時仍可允許您修復系統。

陰影複製
陰影複製幾乎是隱形的，它預設會啟用，且使用者不需要輸入任何資料。若使用者需要還原某個檔案，這項功能就很好用。此功能主要是會公開由磁碟區陰影複製服務所建立的檔案即時複本。

陰影複製空間管理
在現用磁碟區以及 Complete PC 備份的備份磁碟上，皆保留了陰影複製的儲存空間。只要以更高的權限，在命令提示中執行以下命令，即可檢查陰影複製儲存空間的已使用、已配置和最大值：
VSSAdmin list ShadowStorage
已使用的值代表目前陰影複製佔用了多少空間；已配置的值則表示為陰影複製保留的空間大小 (因此不可用於其他目的)；最大值則為陰影複製不可超越的大小限制。
陰影複製採自動化的空間配置，也就是無法由使用者設定。新的空間是於先前配置的空間用完時，以固定增量再配置。這就是為什麼已使用空間的顯示值，永遠會低於您看見的已配置空間值。
針對現用磁碟區，可允許的最大陰影儲存空間是根據首先建立陰影複製的時間而定，通常是在系統還原首次啟動時，並且於設定過程建立還原點。此值設定為可用空間的百分之 30，或磁碟區總容量的百分之 15，其中以數值較小者為主。最大值是固定的，不會因為可用空間較多或較少而改變，也不會在磁碟區大小調整後變更。
不過，只要以更高的權限，在命令提示中使用 VSSAdmin 工具，即可手動調整此儲存區域的大小。例如，將 C:\ 的儲存區域大小增加到 15GB 的命令為：
VSSAdmin Resize ShadowStorage /For=C: /On=C: /MaxSize=15GB
此工具源自 Windows Server®，可於另一磁碟區上維護特定磁碟區的陰影複製。在 Windows Vista 中，磁碟區的陰影複製則置於同一磁碟區上。因此，來源和目的磁碟區必須是同一個。
另一方面，Complete PC 備份的備份目標磁碟則有固定的最大陰影複製限制，亦即磁碟空間的百分之 30。此數值是由 Complete PC 備份所控制，無法手動變更。此陰影複製儲存空間會用來儲存 Complete PC 備份的增量備份。
磁碟區上隨時可保留高達 64 份陰影複製，只要陰影複製儲存區域的空間足夠即可。一旦達到最大空間限制，就會刪除舊的陰影複本，以便挪出空間讓新的複本使用。因此，若到達現用磁碟區的陰影儲存限制，就會刪除系統還原的舊還原點，而舊的 Complete PC 備份則於備份磁碟到達限制大小時刪除。此外，儲存與編輯備份磁碟上的其他資料，有可能影響老舊備份檔的正常處理程序，導致舊備份檔更快遭到刪除。

使用陰影複製還原檔案
現在，試想我的筆記型電腦已使用一陣子，也曾用來製作某些簡報。我在完成簡報之後，就把簡報一起交給客戶。一個月後又開始新的專案，我也就把這些檔案給刪除了。不久，經理卻向我要一份舊簡報的複本，這時候陰影複製就能派上用場了。
要尋找已刪除檔案的複本共有兩種方式。第一種是如果我知道檔案的儲存位置，則只要輕鬆用滑鼠右鍵按一下包含已刪除檔案的資料夾，並選取 [還原舊版]。在這項功能中，我可以選擇包含要找之已刪除檔案版本的日期 (請參閱 [圖 4])，按一下 [開啟舊檔]，接著將目標檔案複製到現用磁碟區的其他位置。此複製作業和一般檔案複製的速度一樣快。
圖 4 還原已刪除的檔案
圖 4 還原已刪除的檔案
如果我已經忘記檔案的儲存位置，亦可在檔案樹狀圖中，開啟最接近的舊版上層資料夾，並從該處開始搜尋。例如，我已經忘記特定資料夾，但是還記得是在 [文件] 中的某個子資料夾裡。這時候我可以在 [Windows 檔案總管] 視窗右上角的搜尋方塊中鍵入檔案名稱 (全部或部分文字)，以便搜尋舊版的 [文件] 內容，如 [圖 5] 所示。請注意，陰影複製的搜尋功能無法在根資料夾中運作。且由於陰影複製未經索引排序，因此搜尋時有可能比在現用磁碟區上搜尋的時間更長。
圖 5 鍵入部分檔案名稱，以搜尋舊版的文件
圖 5 鍵入部分檔案名稱，以搜尋舊版的文件

從檔案備份還原檔案
陰影複製並非永遠可用，因為每隔一段時間為了管理可用空間，就必須剪除/刪除這些陰影複製。如果我需要的檔案已無法使用此方式取得，則可試著從已排定的檔案備份著手。我只要從 [備份及還原中心] 選取 [還原檔案]，並選擇包含該已刪除簡報的備份日期即可。按一下 [新增檔案] 之後，隨即出現開啟檔案對話方塊，讓我瀏覽備份。選擇我要找的檔案之後，可選擇要將該檔案還原至相同或其他位置。
值得注意的是，[還原檔案] 僅會顯示最新備份組內所包含的備份。要從舊的備份組檢視備份，請選取 [進階還原]，然後選取 [這部電腦上較舊備份的檔案] 選項。在極少的情況下，您有可能無法透過該選項找出某個舊備份組；這時候請選取 [進階還原]，然後選取 [還原在不同電腦上備份的檔案] 選項。這是因為電腦備份目錄太大時會遭到修剪。

從 Complete PC 備份還原檔案
為了解釋的更詳盡，我必須說明 Complete PC 備份可用來還原個別檔案。Complete PC 備份的目的雖然是以磁碟區層次進行還原，但亦可以 .vhd 格式儲存資料，也就是說，您可使用離線 VHD 掛接工具來存取和還原個別檔案 (在撰寫本文時，VHD 掛接工具僅隨附 Microsoft Virtual Server 2005 R2 SP1 提供，您可到以下位址下載：microsoft.com/technet/prodtechnol/eval/virtualserver)。若要掛接備份，請以提升的權限開啟命令提示字元，並且瀏覽至 Microsoft Virtual Server\Vhdmount。命令為：
vhdmount /m [path of the .vhd file] [drive letter to assign to the virtual hard drive]
第一次操作時，系統可能會因尚未簽署而無法找到要求的驅動程式。這樣會導致出現錯誤訊息，表示無法載入裝置驅動程式。若要解決此問題，請在使用上述命令插入 .vhd 檔案之後，到 [裝置管理員]，用滑鼠右鍵按一下顯示的新裝置，然後選取 [內容]。接下來到 [驅動程式] 索引標籤，選取 [更新驅動程式]，按一下 [瀏覽電腦上的驅動程式軟體]，再選取 [讓我從電腦上的裝置驅動程式清單中挑選]。正確的驅動程式檔案應位於 Microsoft Virtual Server\Vhdmount\vhdstor.inf。安裝後，隨即顯示出新的驅動程式，您可以瀏覽最新的 Complete PC 備份，並將您要的檔案複製到其他位置。

Complete PC 還原
現在試想像某個晴朗的午後，我決定在游泳池畔坐著使用筆記型電腦。我在濕答答的磁磚上滑了一跤，不小心把筆記型電腦掉進游泳池裡。現在電腦無法修復，我非得買台新的不可。因為我使用 Complete PC 備份工具，所以還能夠將系統還原至新的膝上型電腦，無需耗費時間手動重新安裝所有應用程式，以及依個人需要重新設定組態。執行 Complete PC 還原其實很簡單。啟動時，我使用 Windows Vista 安裝磁碟開機，進入 Windows 修復環境。這裡會出現提示，要求我把連接包含系統影像的裝置。我選擇適當的影像，接著就開始還原程序。
還原完成之後，我透過最新的檔案備份執行檔案還原工作。就是因為我經常製作檔案備份，所以檔案備份中的資料都是較新的。由於電腦已還原為選擇檔案備份之前的時間，因此目錄中並不包括此備份的記錄。因此，我選取 [進階還原] | [還原在不同電腦上備份的檔案] | [還原此備份中的所有檔案]。此外，我也開始新的完整備份，以保護剛還原的資料。
Windows 修復環境通常會由 OEM 安裝在硬碟機上，做為隱藏的分割。這可以用來將 Complete PC 備份影像還原到同一個硬體中。但如果您需要將某部電腦建立的影像還原至另一部電腦，則需要從外部媒體執行 Windows 修復環境，例如您的 Windows 安裝磁片。
其中有一些需要注意的事項。Complete PC 還原只有在還原到製作備份的相同硬體時方可使用 (當然，前提是沒有硬體損毀的問題)。
既然 Complete PC 備份中包括整部電腦的影像，在還原至不同的硬體時仍有些限制。首先，備份影像包括還原完成後用來開機的驅動程式。在極少數的情況下，在新電腦上開機時需要的驅動程式可能不存在。在將某種磁碟控制器類型 (IDE、SATA 或 SCSI) 製作的影像備份，還原至另一種磁碟控制器類型時，有可能發生這樣的情形。即使在這樣的情況下，仍有機會成功還原，因為影像備份中常見的 Windows 驅動程式通常都能相容。
第二，只有在新電腦至少具備相同數量的硬碟機，且每個硬碟至少和原本的容量一樣大，才能執行還原。若您打算使用 Complete PC 備份移轉至新硬體，請牢記這些限制條件。
由於備份及還原皆以整個磁碟區的區塊層次執行，因此 Complete PC 還原需要一個磁碟區來進行完整還原或略過。因此，您最好建立多重磁碟區進行備份 (例如將資料檔案與系統檔案個別放在不同的分割上)。如此一來，在還原時，您就可以選擇是否僅還原系統磁碟區 (視為關鍵) 或者所有磁碟區。

實際操作所有功能
相較於 Windows XP，Windows Vista 實現了大幅的改良，藉由推出新的備份技術和改善現有選項，來加強保護您的資料與系統。其中的四項主要備份功能為：檔案備份及還原、Windows Complete PC 備份及還原、系統還原，以及陰影複製。這些功能可帶來截然不同卻完全互補的功能特性，分別形成資料的全方位防護網。請務必了解這些功能共同運作的方式，以確保系統的設定方式可完全利用這四種方法，並且根據各種情況套用適當的保護和補救方式。
根據經驗法則，在資料損毀的情況下，一定要先嘗試陰影複製還原方法，因為這種方法可以保留最新的資料複本。針對系統不穩定和修復問題，請使用系統還原。Complete PC 還原一般應做為全系統修復的最後回復，且必須謹慎使用。無論如何，Complete PC 修復是一項不可或缺的救命妙法，但最重要的是要事先採取行動，否則一切免談：所以請立即備份！
我要特別感謝 Eduardo Laureano、Ivan Pashov、Jill Zoeller 以及所有備份及還原產品小組成員對於本文章所提供的協助。

Christine Fok 是 Microsoft 儲存技術解決方案部門的專案經理。她的主要工作包括 Windows 用戶端平台的備份及還原方法。


 Windows Server: 11 個管理 Active Directory 的基本工具
Windows Server Laura E. Hunter

11 個管理 Active Directory 的基本工具
摘要:
  • 在命令列建立物件
  • 在 Active Directory 內執行大量作業
  • Active Directory 的更新及維護

如果您曾經處理一份列出從下週起新進公司的 200 名新員工的 Excel 試算表，或使用者帳戶因為服務台人員輸入錯誤而設定不正確，
或者，您只是想要在除了每次開啟 [使用者及電腦] 之外有更簡單的 Active Directory® 管理方式，您可以利用一些免費的管理工具來幫助您。有些工具直接內建於 Windows® OS，有些隨附於 Resource Kit 或 Windows 支援工具中，有些則是免費的協力廠商工具。這些方便的工具是什麼？可從何處取得它們？現在就讓我們來了解一下。
我將先從 Windows Server® 2003 的內建命令列工具開始，這些工具可讓您建立、刪除、修改及搜尋 Active Directory 中的物件。

CSVDE
所謂的 CSVDE 即 Comma-Separated Values Data Exchange 工具，它可讓您使用 CSV 來源檔案，將新物件匯入 Active Directory 中；它也可以讓您將現有的物件匯出至 CSV 檔。CSVDE 不能用來修改現有的物件；當您在匯入模式下使用此工具時，您只能建立全新物件。
以 CSVDE 匯出現有物件的清單非常簡單。以下示範如何將 Active Directory 物件匯出至 ad.csv 檔：
csvde –f ad.csv
–f 參數指出輸出檔名稱跟隨在後。但您必須知道一件事實，根據您的環境而定，此基本語法可能會產生使用不便的大型輸出檔。為了限制工具只在特定組織單位 (OU) 內匯出物件，您可以修改陳述式如下：
csvde –f UsersOU.csv –d ou=Users,dc=contoso,dc=com
現在我們進一步假設您只要匯出使用者物件至 CSV 檔。在此情形下，您可以新增 –r 參數，它可讓您指定輕量型目錄存取協定 (LDAP) 篩選器來進行搜尋，以及指定 –l 參數，它可限制匯出的屬性數目 (請注意，以下全部在同一行)：
csvde –f UsersOnly.csv –d ou=Users,dc=contoso,dc=com –r
    "(&(objectcategory=person)(objectclass=user))" –l
    DN,objectClass,description
–i 參數可讓您將物件從來源 CSV 檔匯入 Active Directory 中。不過，使用 CSVDE 建立使用者物件有一項重要限制：您不能在其中設定使用者密碼。因此，我會避免使用 CSVDE 來建立使用者物件。

LDIFDE
Active Directory 提供大量使用者作業的第二個內建工具，叫做 LDIFDE，它的功能比 CSVDE 更強，且彈性更大。除了建立新物件之外，LDIFDE 也可以修改及刪除現有的物件，甚至延伸 Active Directory 架構。LDIFDE 彈性的交換條件是必要的輸入檔會使用比 CSV 檔更複雜的格式，這個輸入檔稱為 LDIF 檔，其副檔名為 .ldf (您也可以很輕鬆地設定使用者密碼，但這點稍後再探討)。
我們先從簡單的範例開始，將某個 OU 內的使用者匯出至 LDF 檔 (請注意，以下全部在同一行)：
ldifde -f users.ldf -s DC1.contoso.com -d "ou=UsersOU,dc=contoso,dc=com"
       –r "(&(objectcategory=person)(objectclass=user))"
就像大部分命令列工具一樣，您可以執行 LDIFDE /? 參數來找到 LDIFDE 參數的完整說明。[圖 1] 說明我在此處使用的參數 (請注意，CSVDE 和 LDIFDE 命令的參數其實是一樣的)。
Figure 1 LDIFDE 參數 (Close Figure 1)

參數 | 說明
-d | 指定 LDIFDE 應該在作業中連接的 LDAP 路徑。
-f | 在此案例中，指出用來輸出匯出結果的檔案名稱。
-r | 指定用於匯出的 LDAP 過濾器。
-s | 指定為了執行此作業而連接的網域控制站 (DC)；如果您省略它，LDIFDE 將連接到本機 DC (或已驗證您的 DC，如果您是從工作站執行此工具的話)。
LDIFDE 的真正功能在於建立及處理物件。不過，在這麼做之前，您必須先建立輸入檔。以下建立兩個新的使用者帳戶，叫做 afuller 和 rking；若要建立輸入檔，請在 [記事本] (或您愛用的純文字編輯器) 輸入文字並將它另存為 NewUsers.ldf：
dn: CN=afuller, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: afuller
objectClass: user
samAccountName: afuller

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: add
cn: rking
objectClass: user
samAccountName: rking
建立該檔案之後，請執行下列命令：
ldifde –i –f NewUsers.ldf –s DC1.contoso.com
這裡唯一的新參數是 -i，您大概猜得到，它表示這是匯入作業而不是匯出。
在修改或刪除現有的物件時，LDIFDE 命令的語法不變；不過，您可以修改 LDF 檔的內容。若要變更使用者帳戶的說明欄位，請建立一個叫做 ModifyUsers.ldf 的文字檔，如 [圖 2] 所示。
圖 2 ModifyUsers LDF 檔
圖 2 ModifyUsers LDF 檔
您可以執行與之前一樣的 LDIFDE 命令語法並在 -f 參數後面指定新的 LDF 檔名，來匯入變更。刪除物件的 LDF 格式更簡單；若要刪除您處理的使用者，請建立一個叫做 DeleteUsers.ldf 的檔案，並輸入下列命令：
dn: CN=afuller OU=UsersOU, DC=contoso, DC=com
changetype: delete

dn: CN=rking, OU=UsersOU, DC=contoso, DC=com
changetype: delete
請注意，LDIFDE 能夠設定使用者密碼，這點與 CSVDE 不同。不過，在您可以設定使用者帳戶的 unicodePWD 屬性之前，您必須先在網域控制站上設定安全通訊端層/傳輸層安全性 (SSL/TLS) 加密。
不僅如此，LDIFDE 還可以建立及修改 Active Directory 物件的類型，而不只是使用者帳戶。例如，下列 LDF 檔將在 contoso.com 樹系的架構中建立一個自訂架構延伸，叫做 EmployeeID-example：
dn: cn=EmployeeID-example,cn=Schema,
cn=Configuration,dc=contoso,dc=com
changetype: add
adminDisplayName: EmployeeID-Example
attributeID: 1.2.3.4.5.6.6.6.7
attributeSyntax: 2.5.5.6
cn: Employee-ID
instanceType: 4
isSingleValued: True
lDAPDisplayName: employeeID-example
因為 LDIFDE 檔使用業界標準 LDAP 檔案格式，所以，需要修改 Active Directory 架構的協力廠商應用程式通常會提供 LDF 檔，當您在生產環境中套用這些變更之前，可使用 LDF 檔來檢查及核准變更。
除了大量匯入及匯出作業的工具之外，Windows Server 2003 也包括內建工具組，讓您建立、刪除及修改各種 Active Directory 物件，以及對符合特定準則的物件執行查詢 (請注意，Windows 2000 Active Directory 不支援 dsadd、dsrm、dsget 及 dsquery 等工具)。

Dsadd
Dsadd 是用於特定目錄磁碟分割中建立 Active Directory 物件類別的執行個體。這些類別包括使用者、電腦、連絡人、群組、組織單位和配額。Dsadd 會使用由下列各項組成的一般語法：
dsadd <ObjectType> <ObjectDistinguishedName> attributes
請注意，您建立的每一個物件類型都會使用一組特定的參數，這些參數要對應該類型可用的屬性。此命令會建立填入了各種屬性的單一使用者物件 (請注意，以下全部在同一行)：
dsadd user cn=afuller,ou=IT,dc=contoso,dc=com
–samID afuller –fn Andrew –ln Fuller –pwd *
-memberOf cn=IT,ou=Groups,dc=contoso,dc=com "cn=Help Desk,ou=Groups,
dc=contoso,dc=com"
–desc "Marketing Director"
–memberOf 參數需要使用者要新增至的每一個群組的完整分辨名稱 (DN)；如果您想要將使用者新增至多個群組，可新增以空格隔開的多個 DN。
如果有任何元素包含空格，例如 Help Desk 群組的 DN，則需要以雙引號括住它。如果有元素包含反斜線，例如一個叫做 IT\EMEA 的 OU，則必須輸入反斜線兩次：IT\\EMEA (這些需求適用於所有 ds* 工具)。
當您使用 -pwd * 參數時，會提示您在命令列輸入使用者的密碼。您可以在命令本身指定密碼 (-pwd P@ssword1)，但這樣會以純文字將密碼顯示在螢幕上，或您內含該命令的文字檔或指令檔中。
同樣地，您可以使用下列兩個命令建立群組物件和 OU：
dsadd computer cn=WKS1,ou=Workstations,dc=contoso,dc=com
dsadd ou "ou=Training OU,dc=contoso,dc=com"

Dsmod
Dsmod 是用來修改現有的物件，其使用方式十分類似 dsadd，但視您要修改的物件類型而定，可能會使用不同的子功能表和語法。下列 dsmod 陳述式會變更使用者的密碼並修改其帳戶，因此在下次登入時會提示該使用者變更為新密碼：
dsmod user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
若要了解這些參數的相似程度，請參考您設定了相同屬性來建立此使用者時所用的 dsadd 語法：
dsadd user "cn=afuller,ou=IT,dc=contoso,dc=com" –pwd P@ssw0rd1
    –mustchpwd yes
顯而易見，如果您知道要在 dsadd 中建立物件的參數，可在 dsmod 中使用那些相同的參數來修改使用者。

Dsrm
與 dsadd 相反的是 dsrm；您可以想像得到，此工具可讓您從命令列刪除物件。基本 dsrm 語法非常直接了當：只要輸入 dsrm，後面跟著您要刪除的物件的分辨名稱，如下所示：
dsrm cn=WKS1,ou=Workstations,dc=contoso,dc=com
根據預設，dsrm 會提示「您確定要刪除這個物件嗎？」輸入 Y，然後按 Enter 鍵。您可以使用 –noprompt 參數而不顯示此提示，但顯然這麼做您就沒有機會在刪除之前確認是否已選取正確物件。如果您要刪除容器物件，亦即可能在其中包含其他物件的組織單位，則另有兩個參數會有幫助。下列命令會刪除 TrainingOU 組織單位及其中包含的所有物件：
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
這個命令會刪除包含在 TrainingOU 內的所有子物件，但會將組織單位物件本身留在原地：
dsrm ou=TrainingOU,dc=contoso,dc=com –subtree
    –exclude

Dsmove
若要在 Active Directory 中移動或重新命名物件，您可以使用 dsmove 工具，但請注意，您只能使用它在單一網域內移動物件。若要在網域或樹系之間移轉物件，請使用 Active Directory Migration Tool (ADMT)，您可從 Microsoft 網站免費下載它。Dsmove 會仰賴兩個參數，它們可分開使用或合併使用。此命令會給予 Steve Conn 帳戶新的姓氏：
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com"
    –newname "Steve Conn"
此命令會將 IT OU 中的 Steve 帳戶移到 OU 中：
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newparent
    ou=Training,dc=contoso,dc=com
您可以同時指定兩個參數，將 rename 和 move 合併成單一作業，如下所示：
dsmove "cn=Conn, Steve,ou=IT,dc=contoso,dc=com" –newname
    "Steve Conn" –newparent ou=Training,dc=contoso,dc=com

Dsget 和 Dsquery
ds* 命令列工具組也包括用來查詢 Active Directory 的兩個工具，它們是為了取得資訊而非建立或修改物件。
Dsget 使用物件的 DN 作為輸入，並提供您所指定之屬性的值。Dsget 使用與 dsadd 和 dsmod 相同的子功能表：user、computer、contact、group、ou 及 quota。
若要取得使用者的 SAM 帳戶名稱和安全性描述元 (SID)，請輸入下列命令 (請注意，以下全部在同一行)：
dsget user cn=afuller,ou=IT,dc=contoso,dc=com
    –samAccountName –sid
您將得到如 [圖 3] 所示的輸出。
圖 3 執行 dsget
圖 3 執行 dsget
Dsquery 會傳回符合您指定的準則的 Active Directory 物件清單。不論您使用哪一個子功能表，您都可以指定下列參數：
dsquery <ObjectType> <StartNode> -s <Search Scope> -o <OutputFormat>
對於 ObjectType，dsquery 可使用下列子功能表，它們各有自己的語法：computer、contact、subnet、group、ou、site、server (請注意，伺服器子功能表會擷取網域控制站的相關資訊，而非環境中的任何成員伺服器)、user、quota 及 partition。如果其中一個查詢類型無法滿足要求，您可以使用 * 子功能表，它可讓您輸入任意形式的 LDAP 查詢。
StartNode 在 Active Directory 樹狀目錄中指定要開始搜尋的位置。您可以使用特定 DN，例如 ou=IT,dc=contoso,dc=com，或下列其中一個捷徑指定元：domainroot 或 forestroot，前者從特定網域根目錄開始，後者從樹系根網域的根目錄開始，並利用通用類別目錄伺服器執行搜尋。
最後，[搜尋範圍] 選項會指定 dsquery 應如何搜尋 Active Directory 樹狀目錄。樹狀子目錄 (預設值) 會查詢指定的 StartNode 及其所有子物件，onelevel 只查詢 StartNode 當前的子系，base 僅查詢 StartNode 物件。
若要進一步了解搜尋範圍，請考慮一個包含使用者物件的 OU 和其本身包含其他物件的子 OU。使用樹狀子目錄範圍將查詢 OU、其包含的所有使用者物件及子 OU 及其內容。onelevel 範圍只會查詢 OU 包含的使用者，而不查詢子 OU 或其內容。base 查詢只會搜尋 OU 本身而不查詢其包含的任何物件。
最後，您可以使用 Output Format 來控制如何將 dsquery 的結果格式化。根據預設，dsquery 會傳回符合查詢的任何物件之分辨名稱，如下所示：
"cn=afuller,ou=Training,dc=contoso,dc=com"
"cn=rking,ou=ITTraining,ou=Training,dc=contoso,dc=com"
若要查詢 IT OU 內包含的所有使用者物件及任何子 OU，請使用下列命令：
dsquery user ou=IT,dc=contoso,dc=com
您可以新增其他參數來進一步限定此查詢，例如 -disabled，它只會傳回已停用的使用者帳戶；-inactive x,，它只會傳回在過去 x 週以來未登入的使用者；或 -stalepwd x，它只會傳回在 x 天以上未變更其密碼的使用者。
視目錄中的物件數而定，您在執行查詢時可能需要指定 -limit x 參數。根據預設，dsquery 會傳回最多 100 個符合查詢細節的物件；您可指定更大的數目，例如 -limit 500，或使用 -limit 0 指示 dsquery 傳回所有符合的物件。
您可以使用其他子功能表，也對其他物件類型執行有用的查詢。請看下列查詢，它會傳回 Active Directory 站台及服務所定義的每一個子網路，其位於 10.1.x.x 位址空間：
dsquery subnet –name 10.1.*
或使用下列命令以傳回位於 Corp 站台中的每一個子網路：
dsquery subnet –site Corp
使用另一個子功能表，您可以快速判斷樹系中有多少個網域控制站是設定為通用類別目錄伺服器：
dsquery server –forest –isgc
您也可以使用此語法幫助您判斷，網域中的哪一個網域控制站管理網域主控站 (PDC) Emulator Flexible Single Master Operations (FSMO) 角色：
dsquery server –hasfsmo pdc
就像其他包含子功能表的 ds* 命令一樣，您可以到命令提示字元中輸入 dsquery user /?、dsquery computer /?、dsquery subnet /? ...等等，來檢視特定 dsquery 子功能表內可用的所有參數。
另一個訣竅是使用 | 字元 (英數鍵盤上的 Shift + 反斜線) 將 dsquery 的輸出 pipe 到另一個工具，例如 dsmod。例如，假設貴公司已將 Training 部門重新命名為 Internal Development，現在您必須將舊部門名稱的每一個相關使用者的說明欄位更新為新名稱。在單一命令行上，您可以查詢有 Training 說明欄位的使用者物件，然後大量修改該說明欄位，如下所示：
dsquery user –description "Training" | dsmod
    -description "Internal Development"

協力廠商的好康工具
由於 Active Directory 是依據 LDAP 標準，因此，您可以使用可表示 LDAP 的任何工具來查詢及修改它。許多協力廠商發行付費工具協助您管理 Active Directory，但有時候您會發現社群已有的免費工具。例如由 Directory Services MVP Joe Richards 所建立的集合，可從 joeware.net/freetools 下載。其中有數個工具，分別提供許多不同的功能。有三個是我常用的，即 adfind、admod 及 oldcmp。

Adfind 和 Admod
Adfind 和 admod 類似 dsquery 和 dsmod；adfind 為 Active Directory 的命令列查詢工具，admod 可建立、刪除或修改一或多個 Active Directory 物件。
與具有多個子功能表和視物件類型而定的不同參數的 ds* 工具不同，不管您要執行的查詢或修改類型是什麼，adfind 和 admod 均具有一致的語法。adfind 的基本語法如下：
adfind –b <Search Base> -s <Search Scope> -f <Search Filter>
    attributesDesired
因此，對於網域內所有電腦物件的 DN 和說明的查詢如下：
adfind –b dc=contoso,dc=com –s subtree –f (objectclass=computer) dn
    description
對於所有使用者物件的查詢如下：
adfind –b dc=contoso,dc=com –s subtree –f "(&(objectcategory=person)
    (objectclass=user))" dn description
請注意，除了 LDAP 查詢的內容之外，其餘語法不變。
當您使用 adfind 時，會發現一些捷徑運算子，它們可為您節省一些打字的功夫。例如，-default 參數可取代先前範例中的 -b dc=contoso,dc=com，並搜尋整個網域；-gc 會搜尋廢棄項目收集 (GC) 並傳回 Active Directory 樹系中的所有使用者。您也可以使用 -rb 參數設定搜尋的相對基底；如果您想要在 phl.east.us.contoso.com 網域中搜尋 Training OU，您可以直接指定 –default –rb ou=Training 而不要指定 –b ou=Training, dc=phl,dc=east,dc=us,dc=contoso,dc=com，這樣可為自己節省不少功夫。.
Adfind 也可以執行一些在命令列不好管理的進階搜尋功能，包括 [圖 4] 所顯示的那些功能。
Figure 4 Adfind 參數 (Close Figure 4)

參數 | 說明
-showdel | 查詢 Deleted Objects 容器中的標記物件。
-bit | 查詢位元運算子，例如 userAccountControl 屬性。
-asq | 執行屬性範圍的查詢。此功能 (在 dsquery 中無法複製) 可擷取特定物件的屬性，然後對它執行查詢。
-dsq | 將 adfind 查詢的輸出 pipe 到 dsmod 或其他的 ds* 工具之一。
使用 –asq 參數的範例為「顯示屬於 HelpDesk 成員的群組成員資格」，如下所示：
adfind –default –rb cn=HelpDesk,ou=IT –asq member memberOf
Admod 顧名思義，是用來修改 Active Directory 內的物件。和 adfind 一樣，並沒有什麼特殊子功能表的特定語法需要記住，不論您使用的物件類型是什麼，admod 都使用相同語法。您也可以新增適當的參數 (例如 -add、-rm、-move、-undel)，使用 admod 來新增、移動、重新命名、刪除、甚至取消刪除物件。就像 dsquery 和 dsmod 一樣，您也可以使用 | 字元將 adfind 查詢的結果 pipe 到 admod。
請注意，使用 admod 執行取消刪除作業只會執行重新引發標記的作業，其中已移除大部分物件屬性。若要完全還原物件及其所有屬性，您還是需要執行物件的授權還原。

Oldcmp
還有另一個 joeware 工具，我認為是自動化工具組不可或缺的一部分：oldcmp，它會掃描 Active Directory 資料庫中在指定的週數內尚未使用的電腦帳戶，並且可執行下列動作：
  • 建立帳戶的報告，而不對它們採取任何動作
  • 停用未使用的電腦帳戶
  • 將電腦帳戶移到您指定的不同 OU
  • 立刻刪除電腦帳戶
請注意，由於 oldcmp 可能對目錄造成嚴重破壞，因此，它有一些內建的安全功能。它不會刪除任何尚未停用的帳戶 (除非有手動指定「我很肯定」的命令列參數)。除非有特別指定「我很肯定」的參數，否則它不會一次修改超過 10 個物件，而且它絕對不會對網域控制站的電腦帳戶做任何動作。
不管該工具目前令人誤會的名稱，Joe 已更新 oldcmp，使它對已有某一段特定時間未使用的使用者帳戶執行類似功能。
對於小型 Active Directory 環境或您一次只處理一兩個新增或變更的環境，像 Active Directory 使用者及電腦之類的 GUI 工具，已足夠應付每日例行管理工作。但如果您每天要新增及修改大量物件，或您希望管理工作有更有效率的解決方案，則移到命令行可以大幅加快建立、修改及刪除 Active Directory 物件的程序。誠如您所見的，免費提供的一些彈性大功能強的工具，已直接內建於 Windows 中，並且可從 Active Directory 社群的成員下載。任何這些工具都能夠大幅提高 Active Directory 系統管理者的生產力，甚至成為日常生活中不可或缺的工具。

Laura E. Hunter 是四度在 Windows Server Networking 領域榮獲 Microsoft MVP 獎的人。她是 Active Directory Cookbook 第二版 (O'Reilly，2006) 的作者。Laura 是在資訊科技業已有 10 年經驗的老手，她目前在一家全球工程設計公司擔任 Active Directory 設計師。她擁有多張業界認證，也經常在使用者群組會議和產業會議中演講。


 Windows Server: 重新引發 Active Directory 標記物件
Windows Server Gil Kirkpatrick

重新引發 Active Directory 標記物件
摘要:
  • 已刪除的物件如何儲存在 Active Directory 中
  • 使用 LDP 和 ADRESTORE 來尋找及還原標記
  • 物件屬性和 systemFlags

雖然您可能不喜歡談論這個主題，但現實生活中總是會意外遺失資料，身為 IT 專業人員的您，更需要為一切修復狀況做好準備。在 TechNet Magazine 的 2007 年 4 月號中，我討論過
為修復 Active Directory® 使用者和群組做好規劃的重要性。在 technetmagazine.com/issues/2007/04/ADRecovery 的那篇文章中，我涵蓋了物件連結、複寫、刪除和授權還原等機制。只可惜，授權還原功能需要您在 Directory Service Restore Mode (DSRM) 中啟動網域控制站。這麼做會使 DC 在還原操作期間無法使用。
還有另一個方法您應該知道的。重新引發標記 (Tombstone Reanimation，「借屍還魂」的同義字，但這可與殭屍一點關係也沒有) 提供不使 DC 離線即可修復已刪除物件的唯一方式，它是唯一修復已刪除物件之身分識別資訊的方式，例如其 objectGUID 和 objectSid 屬性。它恰到好處地解決了因重建已刪除的使用者或群組而必須修正所有老舊存取控制清單 (ACL) 參照的問題，這些參照包含已刪除物件的 objectSid。只是您要記住，重新引發標記有其本身的限制 (此點容後再敍)，因此，您仍然應該保存授權還原的功能。
重新引發標記是在 Windows Server® 2003 Active Directory 推出的，用以簡化某些資料修復狀況。此功能利用一項事實，即 Active Directory 在實際移除已刪除物件之前會先將它們保留在資料庫一段期間。在本文中，我將詳細說明 Active Directory 如何刪除物件及重新引發物件，而且會告訴您如何使用標準 Microsoft 工具來修復已刪除的物件。

什麼是標記？
當 Active Directory 從目錄中刪除物件時，它不會真的從資料庫移除該物件。相反地，Active Directory 會將該物件的 isDeleted 屬性設定為 TRUE、從該物件中移除大部分屬性、重新命名該物件，然後將物件移到物件的命名內容 (NC) 中的一個特殊容器，叫做 CN=Deleted Objects，以此方式將物件標示為已刪除。現在該物件叫做標記，一般目錄操作看不見它。它不會顯示在任何 Microsoft® Management Console (MMC) 嵌入式管理單元中，且大部分輕量型目錄存取協定 (LDAP) 公用程式並不知道標記的存在。無論從那方面來看，標記等於是不見了。然而，資料還在那裡，它只是隱藏起來而已。那麼，Active Directory 為何要將標記 (亦即，已刪除的物件) 保留在資料庫中？
雖然其他程序看不到標記，但 Active Directory 複寫程序看得到。為確保對裝載所刪除物件的所有 DC 執行刪除，Active Directory 會將標記複寫到其他 DC。於是，標記會用於在整個 Active Directory 環境中複寫刪除。

標記的存留時間
Active Directory 通常會從目錄中刪除物件，以回應 LDAP 刪除通訊協定操作或 Security Accounts Manager (SAM) 刪除操作。此操作稱為原始刪除，與 Active Directory 複寫程序執行的刪除操作不同。請注意，此次討論不考慮動態物件，它們有不同的刪除機制，當其存留時間 (TTL) 到期時，會直接由 Active Directory 刪除。
當 Active Directory 接收到刪除操作時，它會先瀏覽檢查清單，確保該物件能夠加以刪除。我們竟然需要這個程序，很驚訝吧，不過，這是因為它可確保下列條件全部為真：
  • 物件的 isDeleted 屬性尚未設定為 TRUE (您無法刪除已刪除的物件！)
  • "private object" 回應專屬安全描述元控制旗標未設定在物件的安全描述元中 (這似乎是一個未記載的「功能」。專用物件旗標為安全描述元結構的 Sbz1 位元組的位元 1)。
  • "disallow delete" 位元 (0x80000000) 未設定在物件的 systemFlags 屬性中。
  • 物件 isCriticalSystemObject 屬性未設定為 TRUE。
  • 物件的安全描述元授與適當的存取權，讓使用者能夠刪除該物件 (更具體地說，使用者可以刪除物件本身，也可以從父系物件中刪除子物件)。
  • 此物件不是現有命名內容的交互參照物件 (objectClass = crossRef)。
  • 此物件沒有任何下層物件 (如果 LDAP 刪除操作包括 LDAP "tree delete" 控制物件 ID，除非 isCriticalSystemObject 屬性設定為 TRUE，否則 Active Directory 也會自動刪除下層物件。這樣可防止重要系統物件在樹狀目錄刪除操作中不小心遭到刪除。當然，您可以個別地刪除這些物件)。
  • 此物件不是重要內部物件 (例如，它不是 DC 的 nTDSDSA 物件或 NC 表頭的 ancestor 的 placeholder 物件)。
除了這些條件為真之外，Active Directory 還必須在適當狀態下才能處理刪除操作。比方說，如果 Active Directory 正在重新命名網域的程序中，則它不會刪除網域信任帳戶或 crossRef 物件。
如果確定事實上可刪除該物件，Active Directory 就會將該物件轉變成標記。Active Directory 會先從物件中移除不必要的屬性，但留下 [圖 1] 所指定的那些屬性以及在架構中定義為要保留在標記中的那些屬性 (如需其詳細資訊，請參閱＜修復物件屬性＞一節)。然後它會將物件的相對分辨名稱 (RDN) 變更為 CN=<old RDN>\0ADEL:<objectGUID>，其中 \0A 指出 ASCII 換行字元， <objectGUID> 則是以字串表示的 objectGUID。然後 lastKnownParent 屬性設定為物件上層容器的分辨名稱 (DN)，isDeleted 屬性則設定為 TRUE。然後 Active Directory 會從物件移除所有正向和反向連結屬性。最後，如果物件的 systemFlag 屬性沒有設定 "disallow move on delete" 位元，Active Directory 會將該物件移到 NC 的 CN=Deleted Objects 容器中 (如需本主題的詳細資訊，請參閱「systemFlags 屬性及物件行為」資訊看板)。
Figure 1 儲存在標記中的屬性 (Close Figure 1)

寫在程式中要儲存的屬性
attributeID
attributeSyntax
dnReferenceUpdate
dNSHostName
flatName
governsID
groupType
instanceType
lDAPDisplayName
legacyExchangeDN
mS-DS-CreatorSID
mSMQOwnerID
nCName
objectClass
objectGUID
objectSid
oMSyntax
proxiedObejctName
replPropertyMetaData
sAMAccountName
securityIdentifier
sIDHistory
subClassOf
systemFlags
trustPartner
trustDirection
trustType
trustAttributes
userAccountControl
uSNChanged
uSNCreated
whenCreated
因 searchFlags 設定而儲存的屬性
msDS-AdditionalSamAccountName
msDS-Auxiliary-Classes
msDS-Entry-Time-To-Die
msDS-IntId
msSFU30NisDomain
nTSecurityDescriptor
uid
請注意，CN=Deleted Objects 資料夾是平面的，沒有物件階層。您可能會認為，如果您刪除兩個具有相同 CN 的不同物件，會造成名稱衝突。但事實並非如此。由於 objectGUID 已併入每一個標記的 RDN 中，因此，每一個標記的 RDN 在 CN=Deleted Objects 容器內都是唯一的。
顯然，物件不會永遠留在 CN=Deleted Objects 容器中。對於一開始使用 Windows® 2000 和 Windows Server 2003 建置的樹系，預設的標記存留時間為 60 天，對於一開始使用 Windows Server 2003 SP1 建置的樹系，則為 180 天。您可以設定 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=<root domain> 物件的 tombstoneLifetime 屬性，來變更標記的存留時間。
每隔 12 小時，每一個網域控制站就會啟動廢棄項目收集程序 (這可藉由為 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 物件的 garbageCollPeriod 屬性設定一個新值來加以變更)。廢棄項目收集會掃描 DC 上的所有標記，並實際刪除比標記存留時間更久的任何標記。

使用 LDP 尋找標記
LDP 是使用 Active Directory 的公用程式，類似 Windows 檔案總管。LDP 原本是由 Active Directory 開發小組設計來測試其 LDAP 程式碼，當時 Active Directory 還在開發階段。現在 LDP 是 Windows Server 2003 伺服器支援工具的一部分，它已發展成使用 Active Directory 的健全工具。
即使一般目錄操作看不到標記，您仍然可以使用 LDAP 搜尋操作及稱為控制項的特殊 LDAP 延伸，在 Active Directory 中找到標記物件。控制項是定義在 LDAP 標準中的一種機制，用來延伸 LDAP 通訊協定，以提供超出 LDAP 標準所定義的其他功能，但仍然與其他 LDAP 規格軟體保持相容。Active Directory 支援 22 個控制項，包括 Return Deleted Objects 控制項。當此控制項用來延伸 LDAP 搜尋操作時，它會擷取隱藏的已刪除物件。
為了示範其運作方式，我使用企業系統管理員認證登入 foo.local 網域，然後使用 Active Directory 使用者及電腦 (ADUC) MMC 嵌入式管理單元建立一個使用者物件 (CN=John Smith,CN=Users,DC=foo,DC=local)，如 [圖 2] 所示。然後，再次使用 ADUC 刪除該使用者物件。
圖 2 使用 ADUC 建立使用者
圖 2 使用 ADUC 建立使用者
現在，我可以執行 LDP 程式，用它來顯示已刪除使用者的標記。第一步是將 LDP 連接到特定的 DC，並使用適當的認證進行驗證。為了連接到 DC，我直接從 [連線] 功能表中選取 [連接] 選項。由於我是在 DC 上執行 LDP，因此我只按下 [確定] 就可以連接到本機 DC。如果您是從遠端執行 LDP，則必須指定您要連接的 DC 名稱。在順利連線之後，LDP 會顯示 rootDSE 的屬性，這包含說明 DC 狀態及其本身設定的屬性 (請參閱 [圖 3])。
圖 3 LDP 連接到 DC
圖 3 LDP 連接到 DC
現在，為了使用網域或企業系統管理員認證在 DC 進行驗證，我從 [連線] 功能表中選取 [連結]。由於我是以樹系的企業系統管理員登入 (網域系統管理員和企業系統管理員預設為具有權限列出 CN=Deleted Objects 容器的物件及重新引發物件)，因此，我直接將 [連結] 對話方塊中的 [使用者名稱] 和 [密碼] 保留空白，並按下 [確定]。否則，我可以在 [連結] 對話方塊中輸入適當的認證。
接下來，我想要列出 CN=Deleted Objects,DC=foo,DC=local 容器的內容。通常您不會看到 CN=Deleted Objects 容器，因為該容器本身是標示為已刪除。您可以搜尋 CN=Deleted Objects 容器的唯一方式是使用 Return Deleted Objects LDAP 控制項。
若要搭配 LDP 使用此控制項，請到 [瀏覽] 功能表並選取 [搜尋]。即出現 [圖 4] 所顯示的搜尋對話方塊。[基本 Dn] 欄位可讓您指定要在目錄樹中開始搜尋的位置。我輸入網域的 Deleted Objects 容器的 DN–在此範例中，DN 是 CN=Deleted Objects,DC=foo,DC=local。
圖 4 LDP 搜尋對話方塊
圖 4 LDP 搜尋對話方塊
在 [篩選器] 欄位中，我指定 LDP 將使用的搜尋條件。預設值為 (objectClass=*)，它指示搜尋工具傳回含有 objectClass 屬性值的所有物件。因為即使 Active Directory 中的已刪除物件也具有 objectClass 的值，所以預設篩選器將傳回搜尋範圍內的每一個物件。在此範例中，我將篩選器變更為 (objectClass=user)，限制為只搜尋使用者物件。這樣可以在 CN=Deleted Objects 容器的數千個標記當中，更容易找到已刪除的 John Smith。
您會發現，CN=Deleted Objects 容器中的物件將超過 Active Directory 在單一搜尋操作中可傳回的數量。若要解決此問題，通常您會使用分頁 LDAP 搜尋，它以一次一個群組的方式傳回結果。不過，LDP 不容許您同時指定分頁和延伸搜尋。因此，您必須重新定義 LDAP 篩選器來尋找您要的那個物件。
[範圍] 圓鈕可讓您指定要搜尋的目錄樹範圍。基本搜尋只會傳回 [基本 Dn] 欄位指定的物件。單層搜尋將傳回直接從屬於 Base Dn 物件的物件。樹狀子目錄搜尋將傳回從屬於 Base Dn 物件的所有物件。因為 CN=Deleted Objects 資料夾是平面的，所以我使用單層搜尋來擷取所有標記。
到目前為止，我只概述了傳統的 LDAP 搜尋方式。如果我現在執行它，LDP 會顯示錯誤，指出 CN=Deleted Objects,DC=foo,DC=com 不存在，因為它標示為已刪除。我還是必須在搜尋操作中包括 Return Deleted Objects LDAP 控制項。要這麼做時，我會按一下 [搜尋] 對話方塊上的 [選項] 按鈕，並選取 [Extended for the Search Call Type]，如 [圖 5] 所示。此選項可讓我指定搜尋操作的控制項。這裡，我也將屬性清單變更為 *。這會使 LDP 顯示它擷取的每一個物件的所有一般屬性，而非 LDP 的預設屬性集。
圖 5 LDP 搜尋 選項對話方塊
圖 5 LDP 搜尋 選項對話方塊
現在我按下 [控制項] 按鈕來顯示 [控制項] 對話方塊。LDP 的 [控制項] 對話方塊有點難用，因此當您這麼做時，務必小心遵循這些步驟來新增 Return Deleted Objects 控制項。
開啟 [載入預先定義] 下拉清單，選取 [Return deleted objects]，並按下 [移入] 按鈕。這樣會將 Return Deleted Objects 控制項的物件 ID (OID) (1.2.840.113556.1.4.417) 新增至 Active Controls 清單中，如 [圖 6] 所示。然後 LDP 會將此控制項新增至所有後續延伸的搜尋操作中。按下 [確定] 以儲存控制項設定，並再一次按下 [確定] 以關閉 [搜尋選項] 對話方塊。
圖 6 新增 Return Deleted Objects 控制項
圖 6 新增 Return Deleted Objects 控制項
[控制項] 對話方塊有一些罕見行為。具體來說，即使 OID 出現在 Active Controls 清單中，不一定表示該控制項實際上有作用。有時候您必須移出控制項再將它移回，才可確保該控制項會使用於下一個 LDAP 操作。
現在我準備要執行搜尋。我按下 [LDP 搜尋] 對話方塊上的 [確定] 按鈕，LDP 即從該網域的 CN=Deleted Objects 容器中擷取所有使用者物件。[圖 7] 顯示我的結果。
圖 7 來自 CN=Deleted Objects 容器的結果
圖 7 來自 CN=Deleted Objects 容器的結果

檢查 LDP 結果
我的搜尋傳回兩個標記物件。首先，您會看到第一個標記的 DN：CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local.已刪除物件的 objectGUID 是以字串表示 (41800281-6bc4-42c3-a99b-b283022b3af8)。在 DN 下方是屬性清單，它顯示 objectClass、cn、distinguishedName...等等的值。您會看到 isDeleted 屬性的值是 TRUE，表示該物件事實上已經刪除。您也會看到 objectSid 已保留在標記中，這對於修復使用者及群組的標記很重要，此點容後再敘。lastKnownParent 屬性代表包含已刪除物件的物件在變成標記之前的 DN，在修復標記時，此屬性也很重要。
在我的範例中，LDP 顯示兩個標記物件，兩者都是名為 CN=John Smith 的使用者物件，它們原本來自 CN=Users,dc=foo,dc=local 容器。兩個具有相同 RDN 的不同物件如何來自相同容器？其解釋很簡單。在執行 LDP 來搜尋標記之前，我在 CN=Users,DC=foo,DC=local 容器中建立了 CN=John Smith 使用者物件，並刪除它。然後我又建立了具有相同屬性的另一個使用者物件，同樣也刪除了它。因為我已經刪除第一個 CN=John Smith 使用者物件，所以建立第二個非常合理 (即使它具有相同名稱)。但這些是不同的、獨一無二的物件，由其 objectGUID 加以區別。由於 Active Directory 將 objectGUID 併入標記的 DN 中，它們看起來像是 CN=Deleted Objects 容器中的個別物件。

如何重新引發標記
Active Directory 提供將標記還原為正常物件的機制。這實際上就是用於已刪除物件的取消刪除功能。此功能是一種特殊形式的 LDAP 修改操作，它必須包括兩項特定屬性修改：它必須移除 isDeleted 屬性 (而不只是將它設為 FALSE)，而且它必須變更物件的 distinguishedName，將該物件移到另一個容器。新的 distinguishedName 通常 (但未必) 使用 lastKnownParent 屬性作為容器，並保留相同的 RDN，但去掉 \0ADEL:<objectGUID> 元件，這是 Active Directory 在建立標記時所新增的元件。
在重新引發標記之前，Active Directory 會檢查並確保某些必要條件全部為真。使用者必須具有重新引發標記的延伸存取權，此權限是定義在包含標記之 NC 的 NC 表頭上。使用者無法重新引發他自己的物件。標記的 isDeleted 屬性必須設為 TRUE。而定義在安全性描述元的物件擁有者安全性識別元 (SID)，必須是來自該樹系的其中一個網域或信任網域中。
如果有問題的物件是在 Configuration 或 Schema NC 中，則 FLAG_CONFIG_ALLOW_RENAME 和 FLAG_ CONFIG_ALLOW_MOVE 位元必須設定在標記的 systemFlags 屬性中。如果物件是在 Configuration 或 Schema NC 中，而且有設定 FLAG_CONFIG_ALLOW_LIMITED_MOVE 旗標，則該物件只能移到具有相同的上二層容器中，換句話說，在移動之後，該物件必須留在其上三層容器中。如果物件是在網域 NC 或應用程式磁碟分割中，則 FLAG_DOMAIN_DISALLOW_RENAME 和 FLAG_DOMAIN_DISALLOW_MOVE 位元不得設在標記的 systemFlags 屬性中。
使用者必須具有如安全描述元所定義的權限，才能修改 RDN (通常是 CN，但不一定) 以及將物件新增至新的上層容器中。新的上層容器必須是標記之 objectClass 的可能上層，如架構所定義。雖然通常不容許在 System 容器中移進或移出 (除非 Unlock 系統樹狀子目錄登錄值不是零)，但容許在 System 容器中重新引發標記。
絕不容許重新引發架構物件的使用。不過，這其實不會造成問題，因為您無法正當地從 Schema NC 中刪除物件。
如果所有檢查都很順利，而且必要的需求都符合的話，Active Directory 就會對於標記執行下列步驟來重新引發物件：
  • 移除 isDeleted 屬性。
  • 如果在修改操作中沒有規定，objectCategory 會設定為標記中所指出最具體的 objectClass。
  • RDN 已變更，且物件寫入新的上層容器。
在重新引發之後，物件具有它原本擁有的相同 objectGUID 和 objectSid 屬性。這表示物件的外部參照 (例如在 ACL 中) 不必重設，如果您重建已刪除的物件則必須加以重設。重新引發的物件，其外觀和作用就和它被刪除之前一樣。不過，有一項重要的差異：已還原的物件會缺少標記中未儲存的任何屬性。

使用 LDP 重新引發標記
systemFlags 屬性及物件行為
systemFlags 屬性是對類別端定義的選用屬性，它使 systemFlags 成為每一個 Active Directory 類別的選用屬性。它是 32 位元整數位元遮罩，控制物件的移動及刪除行為。以下是重要旗標的摘要。

FLAG_DISALLOW_DELETE (0x80000000)

如果設定此旗標，系統就不容許物件遭到刪除或移到另一個網域。

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

除非此旗標設定在 systemFlags 屬性中，否則 Configuration 和 Schema NC 中的物件無法重新命名。

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

除非此旗標設定在 systemFlags 屬性中，否則 Configuration 和 Schema NC 中的物件無法移動。

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

除非此旗標設定在 systemFlags 屬性中，否則 Configuration 和 Schema NC 中的物件無法移動。此旗標對移動操作的目標容器加諸進一步限制‑目標容器與目前容器必須具有相同的上二層容器。

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

網域 NC 或應用程式 NC 中的物件預設為可以重新命名。不過，如果此旗標是設定在物件的 systemFlags 屬性中，則系統不容許物件重新命名。

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

網域 NC 或應用程式 NC 中的物件預設為可以移到另一個容器中。不過，如果此旗標是設定在物件的 systemFlags 屬性中，則系統不容許移動物件。

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

如果設定此旗標，系統不會將物件移到其命名內容的 CN=Deleted Objects 容器。它會設定 isDeleted 屬性，重新命名物件，及移除架構中未指定要儲存的屬性。這表示並非所有已刪除物件都會出現在命名內容的 CN=Deleted Objects 容器中；有些物件會留在原始上層容器中。

現在我已告訴您重新引發標記是如何運作的具體細節，我想要示範如何使用 LDP 來還原我刪除的 CN=John Smith 使用者。首先，我連接到 DC 並進行驗證。現在我何以使用 LDP 執行修改操作。在修改操作參數中，我可以移除 isDeleted 屬性，同時指定新的 DN。
因為我要操作標記，所以必須指定 Return Deleted Objects LDAP 控制項。若要在 LDP 中設定修改操作的這個控制項，請從選項功能表中選取 [控制項]，並從 [載入預先定義] 下拉清單中選取 [Return deleted objects]，按 [移入] 按鈕，並按下 [確定] 以儲存控制項設定。
現在我從 [瀏覽] 功能表中選取 [修改]，以開啟 [修改] 對話方塊，並輸入我想要還原之標記物件的 DN。要達到此目的，最簡單的方式是從我先前執行的搜尋操作的結果中複製及貼上 DN。
接下來，我必須輸入要執行的屬性操作清單。重新引發標記需要兩個屬性操作，刪除 isDeleted 屬性，並以重新引發之標記的所需 DN 來取代 distinguishedName 屬性。因此，我在 [屬性] 欄位中輸入 isDeleted，並選取 [刪除] 圓鈕。當我按下 Enter 按鈕時，屬性操作就會新增至 [項目清單]，如 [圖 8] 所示。
圖 8 指定要執行的屬性操作
圖 8 指定要執行的屬性操作
然後我在 [屬性] 欄位中輸入 distinguishedName，選取 [取代] 圓鈕，並在 [值] 欄位中輸入該物件的新 DN。在此情況下，我使用使用者的原始 distuiguishedName，即 CN=John Smith,CN=Users,DC=foo,DC=local。當我按下 Enter 按鈕時，修改操作就會新增至 [項目清單] 中。
因為我必須在修改操作中包括 Return Deleted objects LDAP 控制項，所以必須使用延伸的 LDAP 修改。為了這麼做，我勾選了 [延伸] 核取方塊。在一切都設定之後，如 [圖 9] 所示，我按下 [執行] 按鈕使這些變更生效。LDP 會在大型文字視窗中顯示結果。
圖 9 變更 distinguishedName
圖 9 變更 distinguishedName
當我回到 Active Directory 使用者及電腦 MMC 嵌入式管理單元並查閱 CN=Users 容器時，我發現曾經刪除的使用者物件又回到它所屬的地方。但該物件與其原始狀態有一些重大差異，此點容後再敘。

使用 ADRESTORE 重新引發標記
當您了解如何使用 LDP 之後，重新引發標記就沒有那麼困難了。但它也沒有那麼方便使用。還好，Sysinternals (此公司現在已經成為 Microsoft 的一部分) 的一些好心人士開發了一個命令列工具來簡化重新引發程序。此工具稱為 ADRESTORE，您可以從 Microsoft 網站取得它：microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx。它的安裝很簡單。只要將執行檔複製到您機器上的適當目錄即可，例如 C:\WINDOWS\SYSTEM32 目錄。
ADRESTORE 可在兩種模式下執行。如果您執行它時不使用參數，它會列出預設網域的 CN=Deleted Objects 容器中的所有標記。您可以將搜尋字串新增至命令列，以選取要顯示的物件，例如：
C:\> adrestore John
這樣會顯示 CN=Deleted Objects 容器中在其 CN 或 OU 屬性中包含 "John" 的所有標記物件，它會使用 LDAP 搜尋篩選器 cn=*John* 和 ou=*John*。這並非搜尋標記物件最有彈性的方式，但它適用於大部分情況。[圖 10] 顯示我的搜尋在 ADRESTORE 中傳回的輸出。
圖 10 儲存在標記中的屬性
圖 10 儲存在標記中的屬性
如果您想要重新引發標記，而不只是找到它，則您需要指定 –r 參數以及一個選用字串，如下所示：
C:\> adrestore –r John
此命令會提示您重新引發每一個相符的標記物件。ADRESTORE 一律會將物件重新引發到標記的 lastKnownParent 屬性所指定的容器中，不可以指定不同容器。
ADRESTORE 提供方便的命令列介面來使用 Active Directory 重新引發功能。雖然不是那麼有彈性，但比起使用 DLP 卻簡單許多。同樣地，ADRESTORE 也無法避免重新引發標記的兩個重要問題：要修復第一次刪除物件時從物件中移除的屬性，及修復從 Configuration NC 刪除的物件。

修復物件屬性
從資料修復方面來看，重新引發標記比執行授權還原有更大的好處： 重新引發標記不需要使 DC 離線。且重新引發標記比直接建立已刪除物件的新版本更好。如果您重建某物件，它一定會取得新的 objectGUID 和 objectSid (如果它是安全性主體，如使用者) 屬性。因此，物件的任何外部參照 (例如 ACL) 必須加以更新，來反映新物件的身分識別。這可是令人相當頭痛。
刪除物件時會移除某些屬性，這些屬性並不會隨著重新引發標記而跟著修復。但 Active Directory 會儲存標記中的一些主要屬性，其中最重要的是身分識別相關屬性，例如 objectGUID 和 objectSid。根據預設，它也許儲存許多其他屬性 (請參閱 [圖 1])。大部分寫在程式中要儲存的屬性不太有趣，尤其是在討論修復已刪除的使用者物件時。但您可以在 Active Directory 架構中設定相對應的 attributeSchema 物件的 searchFlags 屬性的位元 3 (0x00000008)，來指定標記中要儲存的其他屬性。在 Windows Server 2003 R2 中，有些屬性已在架構中設定此位元 (這些也顯示在 [圖 1] 中)。
安裝特定應用程式可能變更現有屬性的 searchFlags 的位元 3，甚至新增已設定位元 3 的屬性。例如，Exchange Server 有設定幾個其他屬性，且會儲存在標記中。
即使您在架構物件的 searchFlags 屬性中指定這麼做，Active Directory 也不會在標記中儲存正向連結或反向連結的屬性。尤其，Active Directory 不會儲存像群組的成員屬性或使用者的 memberOf 屬性之類的屬性。因此，重新引發標記並未提供解決方案來修復 Active Directory 中的群組成員資格，請參閱我所寫的＜嚴重損壞修復：Active Directory 使用者及群組＞一文：technetmagazine.com/issues/2007/04/ADRecovery。因此，在重新引發標記時，您還是必須提供替代機制來修復此資訊。
如果您想要以重新引發標記作為資料修復策略的一部分，您需要確定重要屬性已儲存在標記中，或您需要提供另一種方式來儲存及修復重要屬性，例如使用 LDIFDE 或另一個備份和還原方法。其他選項包括第三方 Active Directory 資料修復產品，其中會提供自動化機制，來備份及還原標記未儲存及修復的屬性。

從 Configuration 命名內容中重新引發物件
重新引發標記還有另一項很重要的限制，那就是，一般而言，您無法重新引發從 Configuration NC 刪除的物件。那些物件受到移動及重新命名方面的特殊規則限制，如物件的 systemFlags 屬性所定義。除非 systemFlags 屬性另有指定，否則 Configuration NC 中的物件將無法移動或重新命名，這表示其標記將無法重新引發。Active Directory 在建立特定類別的物件時會強制使用 systemFlags 屬性的某些值，如 [圖 11] 所定義。請注意，Active Directory 對這些值套用位元邏輯 OR 運算，並結合在加法運算中指定的任何 systemFlags 值。如此一來，即使應用程式對 systemFlags 屬性指定不同值，仍會適當地設定必要位元。
Figure 11 預設 systemFlags 設定 (Close Figure 11)

類別 | 預設值
server | FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site | FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer | FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA | FLAG_DISALLOW_MOVE_ON_DELETE
siteLink | FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge | FLAG_CONFIG_ALLOW_RENAME
nTDSConnection | FLAG_CONFIG_ALLOW_RENAME
在正常情況下，Configuration NC 中您唯一可以重新引發的物件是伺服器物件。有趣的是，當 Active Directory 刪除伺服器物件時，標記不會移到 Configuration NC 的 CN=Deleted Objects 容器中；標記會直接留在物件所在之處。這可讓知識一致性檢查程式 (KCC)，即負責計算 Active Directory 複寫拓撲的程序，從已刪除的伺服器物件可能禁止適當複寫的特定狀況中自動修復。因此，如果您發現自己正試圖重新引發伺服器物件，請記住，您不會在 CN=Deleted Objects 容器中找到它。

在修復計劃中重新引發
重新引發標記應該是您資料修復工具組的重要組件。此機制是唯一不需要使 DC 離線就可以修復已刪除物件的方法，同樣重要的是，它也是可以修復已刪除物件之身分識別資訊的唯一方法。這恰好解決了重建已刪除的使用者或群組又必須修正所有老舊 ACL 參照的問題。
但重新引發標記是一個不完整的解決方案。您必須提供自己的機制來修復 Active Directory 未保留在標記物件中的屬性，而且您要從 Configuration NC 修復已刪除物件的能力也有限。請記住，如果您真的決定要重新引發已刪除使用者或群組的使用，您仍然必須修復群組成員資格及您可能需要的任何其他連結屬性。

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


 通訊: 使用 Office Communications Server 2007 促進使用者的通訊能力
通訊 Alan Maddison

使用 Office Communications Server 2007 促進使用者的通訊能力
摘要:
  • Office Communications Server 架構
  • 會議功能
  • Enterprise Voice
  • 增強顯示狀態

整合通訊的時代已經來臨。即將推出的 Office Communications Server 2007 根據 Live Communications Server 2005 的使用經驗，提供完整的徹底檢修結果。除了結構和管理上的改良之外，Office
Communications Server 2007 還包括新的用戶端：Office Communicator。此用戶端同樣以全新提升的功能為訴求，例如 Enterprise Voice、內部 Web 會議、增強顯示狀態和即時訊息，以及同盟。集結這些功能，即成為 Microsoft® Unified Communication 策略的平台，並且可提高產能、加強遠距共同作業功能。
此更新亦包括簡化的 Microsoft Management Console (MMC) 嵌入式管理單元介面。[圖 1] 顯示其中一種效能計數器的管理增強功能。
圖 1 新的 MMC 嵌入式管理單元效能計數器
圖 1 新的 MMC 嵌入式管理單元效能計數器
新的 Office Communications Server 2007 共有兩個版本：Standard 和 Enterprise。Office Communications Server 2007 Standard 版本適用於不到 10,000 名使用者的部署工作。部署 Standard 版本時，將以單一前端伺服器裝載所有服務。
針對較大型部署，則適用 Enterprise 版本，並可選擇合併或擴充的設定。在合併拓撲中，所有硬體皆以前端伺服器的單一集區方式排列。若要發揮最大擴充性，您可以使用擴充設定，以便在前端伺服器的企業集區 (Enterprise Pool) 外部，使用執行 Internet Information Services (IIS)、Web 會議和音訊/視訊 (A/V) 會議伺服器的專屬 Web 伺服器。[圖 2] 顯示擴充設定拓撲。
圖 2 擴充設定拓撲
圖 2 擴充設定拓撲

架構
Office Communications Server 2007 架構是以多部核心伺服器為基礎。前端伺服器、邊緣伺服器以及應用程式伺服器。前端伺服器提供使用者驗證、通訊錄維護、顯示狀態管理、會議管理和應用程式裝載，另外還有伺服器、用戶端、媒體管理 (包括檔案分享)、即時訊息 (IM) 路由以及會議流量之間的訊號處理。
Office Communications Server 2007 的核心會議功能是由一系列整合式伺服器提供，又稱為 Multipoint Control Unit (MCU)。[圖 3] 為這些伺服器及其角色的摘要說明。
Figure 3 會議伺服器及其功能 (Close Figure 3)

會議伺服器 (MCU) | 支援的功能
即時通訊 (IM) | 藉由在參與者之間路由 IM 流量來提供群組 IM 功能。整合至前端伺服器，且不得安裝於另一部伺服器。
電話語音 | 支援撥入與撥出的撥號音。整合至前端伺服器，且不得安裝於另一部伺服器。
Web | 負責共同作業功能，例如白板功能、應用程式共享，以及問與答。此伺服器亦提供 Office 文件分用和 PowerPoint 簡報的支援。可安裝於前端伺服器，或於擴充集區設定的另一部伺服器上。
音訊/視訊 (A/V) | 用來進行多方 IP 音訊/視訊混合與轉接。可安裝於前端伺服器，或於擴充集區設定的另一部伺服器上。
前端伺服器的另一項重要功能，是做為通訊錄伺服器的主機。若您十分熟悉 Live Communications Server 2005 SP1，應該不難識別出這項服務。在 Office Communications Server 2007 中，它扮演重要的角色，現在已不屬於選擇性元件。通訊錄伺服器是由兩個元件所組成：通訊錄服務以及通訊錄檔案存放區。本伺服器負責提供內部和外部來源的連絡資訊。Active Directory® 和 Exchange Server 的全域通訊清單和通訊群組清單，是典型的內部來源。外部來源則包括來自同盟夥伴或公用 IM 連絡人的使用者。
Office Communications Server 2007 強化了 Live Communications Server 2005 所推出的外部使用者連線能力，並允許外部使用者參與內部會議。這項額外的功能需要兩個全新的邊緣伺服器：Web 會議邊緣伺服器 (Web Conferencing Edge Server) 以及音訊/視訊邊緣伺服器 (A/V Edge Server)。另一項改變是，過去的存取 Proxy 伺服器，如今已成為 Access Edge Server。Office Communications Server 的邊緣伺服器 (Edge Server) 在設計上是要置於您的周邊網路 (過濾的子網路)，並提供關鍵的外部使用者連接管道。[圖 4] 提供邊緣伺服器角色的摘要及其用途說明。
Figure 4 邊緣伺服器 (Edge Server) 的角色 (Close Figure 4)

伺服器 | 支援的功能
Access Edge Server | 同盟、遠端使用者連線；公用 IM 連線 (PIC)。
Web Conferencing Edge Server | 外部 Web 會議。
A/V Edge Server | 音訊/視訊 (A/V) 會議和外部使用者的點對點音訊/視訊 (A/V) 呼叫。
反向 Proxy 伺服器 | 群組擴充、通訊錄檔案下載、Web 會議存取會議內容。並不限定為 Office Communications Server 角色，但可提供重要功能。ISA Server 2006 亦可提供反向 Proxy 功能。
除了之前說明的整合式伺服器以外，Office Communications Server 還利用各種應用程式伺服器來執行必要功能，例如驗證、儲存會議中繼資料，並提供通訊群組清單功能。應用程式伺服器通常配合 Office Communications Server 使用，其中包括 IIS、憑證伺服器、Active Directory 環境下的通用類別目錄伺服器、SQL Server® 2005、Exchange Server 2007 以及檔案伺服器。
IIS 會用來存取會議內容、更新通訊錄、擴充 IM 的 Active Directory 通訊群組、擴充 Outlook® 外部使用者通訊群組清單，以及促進 Office Communications Server 元件之間的基礎通訊。
憑證伺服器在 Office Communications Server 中扮演十分重要的角色，用於保護用戶端/伺服器通訊以及伺服器/伺服器通訊的安全。若您使用內部企業憑證伺服器，所有內部用戶端和伺服器都必須信任發行的憑證授權單位 (CA)。每個 CA 憑證鏈結本身必須安裝至各電腦上受信任的根目錄存放區。若您使用 Office Communications Server Federation Service，則您的合作組織也必須使用。
Active Directory 環境中的通用類別目錄伺服器則用於支援會議參與者的驗證。針對內部和同盟使用者，您的通用類別目錄伺服器會使用 Kerberos 進行驗證。屬於公司員工的遠端使用者將透過 NTLM 使用其 Active Directory 認證，而匿名使用者則會使用 Digest Authentication 驗證。
SQL Server 2005 將用來維護會議的狀態資料、使用者註冊以及顯示狀態資訊。在發生失敗的時候，您可以使用 SQL Server 中儲存的資料快速還原會議，這樣不但是快速可靠的復原方式，又不會損失內容資料。
Exchange Server 2007 及其 Unified Messaging (整合通訊) 功能，可以透過語音訊息和自動語音應答功能，為 Office Communication Server 2007 提供重要的附加價值。
檔案伺服器會用來儲存用戶端需要存取的資料。例如，用戶端在下載檔案伺服器上儲存的通訊錄時，所要求的實體檔案。同樣的，其他的會議內容亦會儲存在檔案伺服器中。
基礎的 Office Communications Server 2007 通訊協定架構，是以混合的標準網際網路通訊協定及 Microsoft 通訊協定為基礎。例如，Session Initiation Protocol (SIP) 大幅使用於 IM、會議及顯示狀態訂閱。由 Office Communications Server 的各種元件所使用的通訊協定，則可提供最大的功能與彈性。[圖 5] 為核心通訊協定的摘要及其用途說明。
Figure 5 通訊協定及其用途 (Close Figure 5)

通訊協定 | 支援的功能
超文字傳送通訊協定 (Hypertext Transfer Protocol，HTTP) | 用戶端存取、下載會議內容，以及通訊錄資料。亦用於會議伺服器和 Focus (Office Communications Server 元件) 之間的通訊。
工作階段初始通訊協定 (Session Initiation Protocol，SIP) | 由各 Office Communications Server 元件建立和管理的工作階段，包括 Enterprise Voice、IM、會議伺服器以及增強顯示狀態。
集中會議控制通訊協定 (Centralize Conference Control Protocol，CCCP) | 一種自訂通訊協定，用來建立和控制會議和會議用戶端。
持續性共用物件模型 (Persistent Shared Object Model，PSOM) | 一種自訂通訊協定，用於 Web 會議內容的傳輸，其中包括安全性金鑰和使用者角色與權利。
即時傳輸通訊協定 (Real-Time Transport Protocol，RTP) | 傳送即時資料。在 Office Communications Server 2007 中，提供 Enterprise Voice 和音訊/視訊 (A/V) 會議的傳輸機制。
安全即時傳輸通訊協定 (Secure Real-Time Transport Protocol，SRTP) | 安全性服務，例如加密、訊息驗證以及 RTP 資料整合。在 Office Communications Server 2007 中，用來保護音訊和視訊內容在媒體裝置上傳輸的安全性，例如麥克風和喇叭。
即時傳輸控制通訊協定 (Real-Time Transport Control Protocol，RTCP) | 與 SRTP 共同使用，以傳遞有關音訊/視訊 (A/V) 會議工作階段在媒體裝置之間的訊號品質相關資訊。

Enterprise Voice
Enterprise Voice 是 Microsoft 實作的 Voice over Internet Protocol (VoIP) 電話語音，這是該產品最重要的附加功能。根據使用 Session Initiation Protocol (SIP) 進行訊號處理和 Real Time Protocol (RTP) 的語音流量實作，您可以使用 Enterprise Voice 透過兩部 PC 或者與其他電話撥打和接聽電話。此外，Enterprise Voice 提供的功能包括呼叫控制、路由以及電話號碼正規化。它能夠支援公用交換電話網路 (Public Switched Telephone Network，PSTN)，並可與私人交換機 (Private Branch Exchange，PBX) 相互運作，以便支援 SIP、以電腦為基礎的電信應用程式 (Computer-Supported Telecommunications Applications，CSTA)，或者直接與 Office Communications Server 2007 API 連結。
Office Communications Server 2007 無須大幅修改現行語音基礎架構，即可完成部署，並為您提供許多優勢。Enterprise Voice 可支援三項部署設定：SIP–PBX、SIP–IP–PBX 以及 IP-PSTN。
在 SIP–PBX 設定中，所有遠端呼叫皆由 PBX 控制，您仍可保留現有的電話。這項整合是透過遠端呼叫控制 (Remote Call Control，RCC) 閘道和 CSTA 實現。
SIP–IP–PBX 設定是利用 IP-PSTN 閘道，以省略 CSTA，並允許 Office Communicator 用戶端撥號和控制 IP-PBX 電話。若您並無現有的話筒，可以將 Office Communicator 設定為「軟體電話」。
結合 IP-PSTN 元件部署 Office Communications Server 2007，即可讓您將呼叫控制路由到前端伺服器。Office Communicator 可以與 VoIP 或 Microsoft 認證的協力廠商 SIP 結束點連結 (在許多組織內部，此結束點通常是話筒)，以便透過網際網路撥打和接聽電話。
媒體閘道是協力廠商閘道，可提供 VoIP 與 PSTN 之間的訊號處理和媒體轉換。Office Communications Server 2007 支援三種媒體閘道類型，可大致分類為基本、進階和基本交互式。為了支援進階以外的閘道，Office Communications Server 2007 以中繼伺服器 (Mediation Server) 的角色，提供關鍵通訊協定和媒體轉譯功能。另外亦可使用 Office Communications Server 提供的元件，進行遠端辦公室整合。
就 Office Communications Server 2007 的其他元件而言，Enterprise Voice 必須仰賴邊緣伺服器才能提供外部使用者連接管道。值得一提的是，公司週邊以外的使用者，都必須使用 Access Edge Server (因其 SIP 訊號處理的角色)，而 A/V Edge Server 則允許外部使用者存取語音或視訊服務，以連接到週邊網路服務，例如防火牆和網路位址轉譯 (Network Address Translation，NAT) 實作。
雖然 Enterprise Voice 終究還是會支援更多的用戶端，但目前建議使用的 Enterprise Voice 用戶端仍是最新版的 Office Communicator。此外，Microsoft 及其夥伴已宣佈新的 VoIP 電話硬體與 Office Communications Server 整合的計劃。
Enterprise Voice 亦與 Exchange Server 2007 的 Unified Messaging (整合通訊) 角色整合，以提供語音郵件、電子郵件、行事曆、通訊錄和傳真回條的單一介面，而且可以使用 Outlook Voice Access 透過電話或者從電腦進行存取。另外，Unified Messaging (整合通訊) 還提供自動語音應答服務，可供您用來實作自動式電話功能表系統。

增強顯示狀態
您在 Live Communications Server 2005 中或許已孰悉顯示狀態的概念，不過 Office Communications Server 2007 又進一步擴充與強化此功能。整體來說，顯示狀態與使用者的狀態和可用性相關聯。在 Office Communications Server 中，支援的基礎架構已建立更細膩的顯示狀態相關設定，以實現更豐富的使用經驗。
使用者現在可以從六種不同的狀態模式中做選擇：狀態可設定為線上、忙碌、請勿打擾、馬上回來、離開或顯示為離線。使用者亦可以其他資訊來自訂此項狀態。例如，若使用者狀態設定為「請勿打擾」，使用者可提供為何不想受打擾的附加資訊。
增強顯示狀態亦允許使用者藉由使用以下五個選擇性顯示狀態層級，篩選要顯示給其他使用者看的資訊：這些顯示狀態層級為個人、小組、工作地方、公用及封鎖。這些層級可提供階層式的顯示狀態管理。舉例來說，個人顯示狀態層級會允許連絡人最大彈性，例如即使使用者狀態設定為忙碌時，仍可透過 IM 進行連絡。顯示狀態層級亦會控制顯示給連絡人看的資訊量。
此外，在使用 Office Communicator 時，使用者可以設定其位置狀態，此狀態可以是自訂位置，亦或是住家或辦公室的預設選項。分類為個人或小組的連絡人皆可看到位置資訊。
雖然顯示狀態的增強是一項受歡迎的新功能，也將由時間證明這實際上可以簡化通訊流程，但是 Office Communications Server 以及顯示狀態引擎的基本架構，對於組織而言才具有最大的影響力。例如，Office Communications Server 2007 包含成員網頁組件 (Member Web Part) (一種 Office SharePoint Server 2007 網頁組件)，這可允許使用者檢視與 SharePoint 網站或入口網站相關聯之其他使用者的顯示狀態。此網頁組件可輕鬆加入您的 SharePoint 網站，以便促進您關鍵共同作業基礎架構之間的顯示狀態資訊。
顯示狀態資訊將透過文件工作環境與智慧標籤動作按鈕，整合至整套 Microsoft® Office 2007 應用程式套件。例如，智慧標籤動作按鈕可顯示出使用者的狀態、連絡人和行事曆等資訊。使用者可以使用智慧標籤動作來分擔工作、安排會議或者開始 IM 對話。

內部會議
Office Communications Server 2007 的另一項重大增強功能為內部會議。可以讓內部或外部使用者 (匿名或同盟) 進行即時會議的功能，對於許多組織而言，是一項極有用的工具。這些會議可以預先排定或臨機進行，其中亦包括 IM 會議、音訊/視訊會議和 Web 會議，以及其他共同作業工具 (例如檔案分享、白板功能、投影片註解、參與者輪詢，以及參與者問與答)。Office Communications Server 亦支援從某種會議類型轉變為另一種類型。例如，使用者可以選擇將共同作業功能加入現有 IM 工作階段，並建立臨機會議。
雖然建議在會議時採用 Office Communicator 做為用戶端，但 Office Communications Server 2007 亦可支援 Office Live Meeting 2007 和 Office Live Meeting Add-In for Outlook 2007。Office Communicator 2007 可支援 IM、A/V 工作階段參與、應用程式分享、白板功能以及檔案傳輸。Office Live Meeting 2007 支援參與會議、排定工作階段、記錄工作階段、參與者輪詢以及問與答。
Office Live Meeting 2007 Add-In for Outlook 2007 中則包括使用 Outlook 2007 支援會議工作，還有可指派個別參與者做為出席者或簡報者，以及可分別傳送邀請函給不同的角色。除了掌握召集者、簡報者或出席者角色的使用者之外，亦可根據其位置和認證，分類為內部或外部使用者群組。內部使用者擁有 Active Directory 登入，且位於企業區域網路 (LAN) 上。外部使用者又細分為三種子類別：遠端、同盟和匿名。
遠端使用者代表任何在組織內具有 Active Directory 帳戶的人。其中應包括遠端工作者或承包商。所有遠端使用者在會議中可以是召集者、出席者和簡報者。
同盟使用者的認證是由 Office Communications Server 中建立同盟所定義。同盟使用者可參與會議成為出席者和簡報者，但無法召集會議。
匿名使用者群組受到的限制最多；他們只能當出席者參與受邀的會議。
若要為任何會議提供額外的安全性層級，可以指定不同類型的參與控制設定。Office Communications Server 2007 提供以下項目：開放式驗證、封閉式驗證以及匿名。
開放式驗證會議會允許任何有 Active Directory 登入的遠端或內部使用者參與。任何同盟使用者亦可參與。封閉式驗證會議則僅允許會議召集者邀請的使用者參與。同盟使用者將無法參與會議。
匿名會議則會開放給所有收到邀請的人參加。若要加入會議，使用者必須出示會議金鑰，並通過摘要式驗證，以驗證其認證。除非匿名使用者加入後被升級為簡報者，否則匿名使用者只能是出席者。部份可使用的設定如 [圖 6] 所示。
圖 6 會議設定
圖 6 會議設定

撥入
藉由簡化通訊、整合各種通訊媒體，並且交由使用者控制，Office Communications Server 2007 具有革新企業運作型態的潛力。關聯式通訊的概念 (亦即顯示狀態資訊和溝通管道兩者皆內嵌於應用程式中) 將是這項革新的基礎。若您還沒有 Office Communications Server 2007，請把握優勢、盡快部署。
如需有關 Office Communications Server 2007 的詳細資訊，並嘗試 Beta 版，請造訪 TechNet Office System TechCenter，網址為：technet.microsoft.com/en-us/office/bb267356.aspx。此外，亦請務必參考 Unified Communications Group Team 的部落格：blogs.technet.com/uc。

Alan Maddison 是 MTI Technology Corporation 的資深顧問。他主要專精於 Active Directory、Exchange Server 和虛擬化。


 編輯的話: 多元化的學習途徑
編輯的話
多元化的學習途徑
Joshua Trupin

自從我們 開始出版雜誌之後，9 月號的文章一直都是以「開學」為主題。當然，我們也知道世界各地的時間表不一定一樣。例如，美國的開學時間是 8 月底。然而，有些人是活到老、學到老，絕不放假。
就大多數的人而言，9 月應該夠接近了。TechNet Magazine 也要開學了，因為我們是頒發 IT 專家學位的高等教育機構。好啦，這是我們幻想出來的。但是我們雜誌所提供的學習內容絕對不是幻想出來的。本月的教學大綱非常密集。
稟持著優良高等教育機構的精神，我們提供了各式各樣的教學課程，內容涵蓋 SQL 指令碼的入門課程 (於《嗨，Scripting Guy！》專欄中) 到各種 Active Directory 管理工具的介紹，豐富無比。
中階的課程則包括 Windows Vista 的學位。首先，您將學習如何使用 Business Desktop Deployment (BDD 2007) 部署 Windows。在您的企業中完成 Windows Vista 的部署之後，還有如何實作系統定期備份的指南可供參考，其中探索當下可運用的主要技術。
完成以上教學課程之後，距離 IT 專家的學位就不遠了，此時，您就要開始挑戰進階的課程，亦即 Active Directory 的研究。如果您曾經想知道什麼是「標記重新引發」，這個月的文章就可以為您解答。
TechNet Magazine 當然只是學習管道的途徑之一。Microsoft TechNet 網站還有更多元化的遠端學習課程可供選擇。TechNet 網站上有數百個專門研討關鍵技術且適用於 IT 專家的網路廣播課程，包括 Microsoft IT 如何在公司內部運用各項技術的展示。網路廣播的內容有依照觀眾類型 (IT 專家、高階主管...等等) 和技術領域進行區分，而且都有難易度的分數，就像大學課程的編號一樣。
舉例而言，本月的 TechNet Magazine 中有數篇 Active Directory 的深入研討文章。但是，也許您目前還不需要那麼深入的資訊，則可以先從TechNet 網路廣播的等級 200 展示開始接觸，該展示的標題為《Active Directory 基礎》(msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032295120)。
今日的教育管道非常多元化。無論是透過雜誌或網際網路，我們都會提供豐富的資訊供您參考。閱讀我們的文章之後，建議您造訪 TechNet Magazine 的部落格 (blogs.technet.com/tnmag)，做一點課後的複習和討論。
—Joshua Trupin

感謝下列 Microsoft 技術專家： Paul Bowden、Justin Hall、Anand Lakshminarayanan、Eduardo Laureano、Mike Lewis、Tim Mintner、Michael Murgolo、Mark Russinovich 及 Jim Truher。


 讀者信件: 相關問題解答
讀者信件
相關問題解答

PsTools
在 2007 年 3 月的《桌面檔案》專欄中，Wes Miller 有提到 PsTools 公用程式 (＜A PsTools 入門＞，請參閱 technetmagazine.com/issues/2007/03/DesktopFiles)。我似乎無法執行這些超猛的公用程式。我特別想用的是 PsLoggedOn。可否請您具體說明如何將這些好康公用程式放置到我系統路徑的資料夾中？若有實際範例會很有幫助。
—Tim

最理想的入門方法將完整的 PsTools 套件 (download.sysinternals.com/Files/PsTools.zip) 下載到一個工作的目錄中 (例如 c:\toolbox)。將 ZIP 檔案解壓縮至該目錄之後，就可以開始使用其中的工具。如果您要將該目錄加入您的預設搜尋路徑 (PATH) 中，使工具可以從任何位置執行，請在命令提示中執行下列命令 (其中要以您的工作目錄取代 c:\toolbox)：
SET PATH=%PATH%;c:\toolbox

對於 Robocopy 的讚揚
直到我閱讀了 2006 年 11 月的文章對於 Robocopy GUI (technetmagazine.com/issues/2006/11/UtilitySpotlight) 的介紹，我們的服務中心一直無法找到保存從網路資料夾移動至 SharePoint® 存放區之檔案的時間戳記。Robocopy 真的是超棒的工具！
—Cristino

檢查登錄子機碼
在過去的數週，我一直在尋找如何測試 EnableLUA 登錄子機碼到底是開啟 (On) 或是關閉 (Off)。關閉時，使用者帳戶控制會停用。我們希望是停用的，才能讓我們在測試實驗室裡自動安裝程式，而無須以系統管理帳戶登入進行確認。我們想要把這項測試放入所有安裝指令碼的開頭，然後在執行安裝指令碼之前，先執行可將 EnableLUA 值從 1 (開啟) 變更為 0 (關閉) 的指令碼。但是，我一直無法使測試成功地完成作業。希望您可以提供協助，感激不盡。
—Derek

以下是讀取登錄機碼、檢查值以及在需要時變更值的基本指令碼。此範例會讀取 HKLM\Software\Microsoft\Test\TestKey 機碼，檢查值是否為 1，如果是，就會將值變更成 0；如果值不是 1，則指令碼會結束：
On Error Resume Next
Set WSHShell =  Wscript.CreateObject _
    ("Wscript.Shell")
RegLoc = _
    "HKLM\Software\Microsoft\Test\TestKey"
KeyValue = WSHShell.RegRead(RegLoc)
If (KeyValue = "1") then
  WSHShell.RegWrite RegLoc,"0"
end If
Wscript.Quit
再次提醒您，修改登錄時請務必小心，特別是在這樣的情況下。

ReadyBoost
可否請您更清楚地為我說明 ReadyBoost？具我的了解，ReadyBoost 會像電腦的 RAM 和硬碟機之間的緩衝區，但是資料會同步寫入。由於系統需要寫入兩份資料，這不會降低效能嗎？還有我該如何測試有使用 ReadyBoost 以及沒有使用 ReadyBoost 的系統效能？
—Alex

ReadyBoost 的概念是要讓 Flash 記憶體 (如 USB 隨身碟...等等) 成為暫時的快取儲存體，以擴充傳統 (通常更昂貴) 的 RAM 記憶體。ReadyBoost 不一定會同步寫入資料到 Flash 記憶體和硬碟機，而是會做為 RAM 和磁碟機之間的中繼快取儲存體。Mark Russinovich 在 2007 年 3 月的文章《深入探索 Windows Vista 核心：第 2 篇》中有比較詳細的說明，其中有提到：
「在 ReadyBoost 服務初始化快取之後，Ecache.sys 裝置驅動程式會攔截對本機硬碟磁碟區 (例如 C:\) 的所有讀取和寫入，並將寫入的任何資料複製到服務所建立的快取檔案中...
...ReadyBoost 看到可利用快取滿足的隨機讀取時，會從快取提供服務，但是因為硬碟的循序讀取存取優於 Flash 記憶體，所以即使快取中有資料，它也會讓屬於循序存取模式的讀取直接送往磁碟。」
您可以透過線上閱讀 Mark 的整篇文章，網址為 technetmagazine.com/issues/2007/03/VistaKernel。

Windows PE 的下載檔
在 2007 年 5 月的《讀者信件》專欄中，您提供的資訊好像有些不一致。針對第一個問題＜製作影像＞，您說：「您可以使用 WAIK 中的工具，來建立與自訂 Windows® PE 2.0 影像...」這似乎隱含 Windows PE 包括在工具中，且可以下載。
但是在最後一個問題＜取得 Windows PE＞，您卻回答：「Windows PE (僅) 能透過軟體保證 (Software Assurance，SA) 授權計劃..."我想您的第一個答案是對的，而第二個答案已不適用。
—Xihui

Windows PE 2.0 可以從 Windows 自動化安裝套件 (Windows Automated Installation Kit，WAIK) 中下載。它的授權規則與 Windows PE 1.6 不同 (這是上一個版本，是在去年的＜Windows PE 入門＞中所提及。您可以閱讀該文章，網址為 technetmagazine.com/issues/2006/09/WindowsPE)。Windows PE 1.6 僅能透過軟體保證 (Software Assurance，SA) 授權計劃取得。

Windows PowerShell 的安全性
周遭有許多人在討論 Windows PowerShell™。我看過許多探討其類似 UNIX 的語法、格式化命令輸出的簡便性...等等，但是我還沒有看到在資料中心部署 Windows PowerShell 的安全性考量和相關資訊。
請問要在實際執行伺服器上部署或執行如 Windows PowerShell 功能這麼強大的殼層 (Shell) 時，應該要注意哪些安全性問題？
—Carlos

Windows PowerShell 的安全性是一項重要的議題，這我們完全同意。事實上，我們的 Windows PowerShell 專欄筆者，Don Jones 將在本月的 TechNet Magazine 中深入探索此主題。除了本月的文章，建議您也參考兩本最近出版的重要書籍：Windows PowerShell in Action (由 Bruce Payette 著作，Manning Publications，2007) 以及 Windows PowerShell:TFM (由 Don Jones 和 Jeffrey Hicks 共同著作，SAPIEN Press，2007)。這兩本書對於 Windows PowerShell 都有深入的探討，而且對於其安全性更是以完整的主題章節投入。

SQL 最佳作法
對於您在 Best Practices Analyzer (BPA) 和符合結構描述的物件 (請參閱 technetmagazine.com/issues/2007/05/SQLQA) 方面所提供的解答和建議，我必須強烈地提出反對意見。SQL Server™ 2005 依然必須解析結構描述 (相對於 SQL Server 2000 中的擁有者，而且作者錯誤地將其稱之為「結構描述」)。SQL Server 2005 的解析順序在線上叢書 (BOL) 裡有清楚的記載。
因此，合格的物件依然是最佳作法，以避免發生語意模糊的錯誤，使最佳化工具在解析物件名稱時的 CPU 循環週期能夠減少。專欄中的建議與 Microsoft 白皮書《在 SQL Server 2005 中進行批次編譯、重新編譯及計畫快取問題》的建議似乎有互相矛盾的問題。
—Mike

針對此答案，我們直接找到《SQL Q&A》的專欄筆者 David Browne，他也是位於美國德州達拉斯之 Microsoft Technology Center 的技術架構設計人員 (Technology Architect)。以下是他的答覆：
最佳作法是見仁見智的議題。特別是涉及效能時，每一個人對於哪些因素會導致效能的變化，以及應該如何進行最佳化，都會有自己的意見。
舉例而言，以某一個方式撰寫查詢以減輕最佳化工具在編譯期間的 CPU 循環週期，是我不會考量的做法，而且我也不認為這能夠在實際執行的作業上有所助益。
但是，藉由促進查詢計劃的重複使用來減少編譯次數，卻是常見的效能最佳化做法。

WinPE
我們使用的是 Systems Management Server (SMS) Operating System Deployment Feature Pack (OSDFP) 以進行 OS 的安裝。隨著 Windows Vista® 的發行，我們想要透過 OSDFP 進行安裝，因此已升級到最新的版本。請問最新的 OSDFP 所提供的 Windows PE 是哪一個版本？
我們以往會建立一個影像 installation .iso 檔案，並將其複製到 Remote Installation Services (RIS) 中。然後我們會使用網路開機選項來啟動新的電腦。由於我們已將 RIS 升級到 Windows Deployment Services (WDS)，而這僅支援 Windows Imaging (WIM) 檔案做為開機影像。請問我們要如何從 OSD 的安裝選項中建立 WIM 影像?
—Vasishta

在最新的 OSDFP 版本中，所附的 Windows PE 並未更新，其版本依然是 1.5 (又稱為 Windows PE 2004)。雖然 Windows PE 並未更新，最新版的 OSDFP 已可以完全支援 Windows Vista 的部署。
建立可部署桌上型電腦影像的最佳流程，在 BDD (Business Desktop Deployment) 解決方案加速器 (Solution Accelerator) 中有所描述。您可以在線上找到所需的元件和說明文件，網址為 microsoft.com/technet/desktopdeployment/bdd/2007。另外，建議您也參考本月 TechNet Magazine 中，由 Michael Niehaus 著作的文章：《使用 BDD 2007 部署 Windows Vista》。

Windows 2003 Server 海報
我剛剛接收到 2007 年 7 月的 TechNet Magazine，其中的兩張 Windows Server® 2008 海報真的讓我很高興！我的同事在上一期收到了一份 Windows 2003 Server 海報。請問您知道我要怎麼樣才能取得 Windows 2003 Server 版本的海報嗎？無論是印刷品或是 PDF 都可以。
—Jason

聽到您很欣賞 Windows Server 2008 的海報，我們感到欣慰！Windows Server 2003 海報的 PDF 版本可以透過線上取得，網址為 go.microsoft.com/fwlink/?LinkID=80428。Windows Server 2003 的海報只有一個版本。


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

移動 SQL Server 資料庫
xSQL Bundle Professional Edition
www.xsqlsoftware.com
無論您的工作內容是營運支援、應用程式開發、品管測試或設定管理，只要您是 IT 專業人員 (既然您正在閱讀 TechNet Magazine，因此我想您應該是)，移動 SQL Server™ 資料庫就可能是家常便飯。移動資料與資料結構描述時，您必須提防發生不一致的情形。為了協助您防範這類不一致的情形，您需要一個好的工具組，來執行結構描述與資料的比對以及同步處理。
我最近使用的一個工具是 xSQL Software 推出的 xSQL Bundle。這個套件是由四個不同的應用程式組成：xSQL Object、xSQL Data Compare 及其相關的命令行公用程式。
xSQL Object 可讓您比對和同步處理資料庫結構描述。它會針對您想在各個資料庫之間比對的物件類型和執行個體，提供各種比對選項。這個應用程式還可讓您建立結構描述快照集，對於維護版本歷程記錄特別方便。這項功能也能讓您輕鬆地復原之前的結構描述狀態。您甚至可以使用 xSQL Object 產生結構描述指令碼，以便
傳輸或封裝您的資料庫結構描述。
xSQL Data Compare 可以比對和同步處理兩個 SQL Server 資料庫中所包含的資料。您可以選擇比對兩個資料庫之間的完整內容，或選取一組資料表進行比對。假使資料表不完全相符，您可以定義自訂的資料表對應，以確保這些資料表中的資料一樣。進行大量資料同步處理時，應用程式會切換成大量插入模式，以節省同步處理作業的時間。
xSQL Data Compare 與 xSQL Object 都可讓您儲存工作區，因此您無須經常重新建立比對環境。這兩個應用程式的同步處理都是交易式的，因此您可以確認所有作業都已成功執行，或已完全復原。此套件中的所有應用程式同時支援 SQL Server 2000 與 SQL Server 2005 資料庫執行個體，因此您也可以比對和同步處理各個版本之間的相關資料及物件。
xSQL Bundle 中較強大的其中一項功能，應該是命令行公用程式，事實上，此功能可讓您透過您的建置、程序、監視或自動化工作排程器，來執行比對與同步處理工作 (我深信重複性的工作應該要自動化，好讓人工作起來更輕鬆、更有效率)。命令行公用程式可接受經由主要應用程式 UI 的組態精靈所建立的 XML 組態檔，而每個公用程式都有一些文字檔記錄選項，好讓您追蹤自動執行過程中的動靜。

價格： xSQL Bundle Professional Edition 的單一使用者授權為 $499 美元起。
xSQL Data Compare 可以同步處理兩個 SQL Server 資料庫中的資料。
xSQL Data Compare 可以同步處理兩個 SQL Server 資料庫中的資料。

建立更安全的通訊
WinSSHD
www.bitvise.com
若您正在尋找促進組織安全性的方法，不妨考慮使用 Secure Shell Handling 2 (SSH2) 和 Secure FTP (SFTP)。簡單來說，SSH2 通道可讓您安全地連線到遠端機器上的服務，而且還可協助您減少在防火牆上開啟、可用於接聽並指向應用程式的連接埠，藉此降低潛在駭客入侵的風險。SFTP 是標準 FTP 伺服器的另一項選擇，它會使用 SSH2 來保障您的資料與命令的安全性。
如果您對這些通訊協定有興趣，那麼就一定要參考一下 Bitvise 的 WinSSHD。WinSSHD 是專為 Windows 設計的 SSH2 伺服器。
安裝很簡單。此應用程式會提供直覺式的控制台來管理 WinSSHD 服務。從基本的啟動/停止功能到 Windows® 事件記錄檔的自訂檢視 (篩選 WinSSHD 事件的地方)，都可以在控制台中找到。您也可以在這裡啟動設定面板，以便進行核心設定。您可以設定介面與連結埠繫結、調整記錄設定、指定要啟用的 SSH 工作階段加密方法、設定工作階段逾時、選擇驗證方法、指定 Proxy 組態，以及控制可以存取執行個體的使用者。您還可以匯入及匯出組態。
存取控制設定能讓您透過 IP 規則 (包含子網路控制的遮罩支援) 與 DNS 名稱規則 (在 IP 規則之後處理) 來限制存取。
WinSSHD 支援虛擬化作業，這點對 SFTP 實作來說很棒。這表示您可以指派數千個虛擬使用者到同一個 Windows 帳戶，藉此簡化帳戶與安全性細節。此應用程式也支援使用 Windows 群組進行驗證和存取控制，讓您無須根據個別使用者來定義原則。
Kerberos 5 和 NTLM 驗證的支援，也讓 WinSSHD 可以整合成單一登入環境。若要完成這項作業，您需要支援 GSSAPI 的 SSH 用戶端，像是同樣由 Bitvise 推出的 Tunnelier 就是不錯的搭配選擇。如您所料，Tunnelier 可完全與 WinSSHD 伺服器相容。它也可以透過遠端模式來設定您的 WinSSHD 伺服器。
如果您的 SFTP 或 SSH2 伺服器環境是任務關鍵的環境，那麼您可以建立 WinSSHD 叢集以達到高度的可用性。這項作業很簡單，但若您需要一些協助，則該公司的網站提供的資訊與設定指南，即可教導您如何設定叢集、轉送連結埠、建立遠端桌面通道...等等。

價格： $99.95 美元。
WinSSHD 可讓您指定 SSH 工作階段加密方法
WinSSHD 可讓您指定 SSH 工作階段加密方法

監視 USB 活動
USB Monitor Professional
www.hhdsoftware.com
這個產品適合所有類型的使用者使用。或許您是 DIY 軟體迷，喜歡建立和修改 USB 裝置的驅動程式。或者您是實際建立 USB 裝置的硬體工程師。又或許您只是發現自己盯著某些 USB 裝置的活動警示燈，好奇到底是什麼原因引發這麼多活動。如果上述任何一點說中您的心聲，那麼 HHD Software 的 USB Monitor Professional 就很有用。這個公用程式可讓您記錄、顯示和分析在 USB 裝置與透過 USB 主控制器的 Windows 系統之間傳輸的資料。
UI 的使用方式有一點迂迴，但是當您習慣之後，就可以收集在所監視的 USB 裝置上來回傳遞的大量相關資訊。根據預設，應用程式會記錄傳遞到 USB 裝置的大部分命令與命令集。對某些裝置 (特別是大型存放裝置) 而言，這種設定可能會太冗餘。幸好，您可以自訂要讓應用程式記錄大量存放裝置的哪些資料。
記錄工作階段之後，接著您便可以依照多種方式分析資料。針對大量存放裝置，您可以使用「大量存放裝置檢視」。除此之外的選項還有統計和裝置輸出的線型圖、未經處理的封包和控制要求檢視、資料封包解碼器檢視、HID 特定檢視，以及靜止影像檢視 (Still Image View) (這會解碼適合裝置的 USB 靜止影像通訊協定 (USB Still Image Protocol))。
有鑑於應用程式記錄的資料量，您不會希望讓 USB 記錄工作階段執行太久。不過，您還是可以限制用於作用中記錄階段的最大磁碟空間大小，並壓縮記錄的資料，來減少所需空間。

價格： 一般授權為 $175.99 美元起。
USB Monitor Professional 會記錄傳遞到 USB 裝置的命令。
USB Monitor Professional 會記錄傳遞到 USB 裝置的命令。

管理虛擬媒體
Virtual CloneDrive
www.elby.ch/fun/software
處理實際媒體可能是很累人的事。自從我切換成 Windows Vista 並喪失與 Microsoft Virtual CD-ROM Control Panel 的直接相容性之後，就一直在尋覓可以裝載 CD 和 DVD 影像的代替品 (附帶一提，如果您有興趣的話，可以在以下網址找到 Windows XP 的 Microsoft®Virtual CD-ROM Control Panel)。
當然，您也可以在 Windows Vista 中執行 Virtual CD-ROM Control Panel。問題在於，您總是必須以系統管理員的身份執行，而且您只能在系統管理員內容下檢視裝載的光碟機，也就是說，必須透過「以系統管理員身份執行」命令提示，而非在使用者的 Windows 檔案總管內容下。因此，不僅是工具無法按照我所需的方式運作，而且還要我以不安全的環境執行應用程式。
我發現有一個工具可以在您的 Windows Vista 使用者內容中運作，
那就是 Elaborate Bytes 的 Virtual CloneDrive
。這個應用程式會將自己安裝成 GUI 管理應用程式和存放裝置控制器，您可以從
[裝置管理員] 中看到它。安裝之後，應用程式會有三個基本設定。首先，
您可以指定要使用的虛擬光碟機數目，最多可以有 8 個平行光碟機。其次 -- 這也是我最喜歡的選項 -- 就是可以選擇設定 Virtual Sheep 設定，以生氣的羊咩咩圖示來取代標準的 CD/DVD 光碟機圖示，如此一來，您就知道哪些光碟機是 ISO 光碟機，而哪些是系統上的實體光碟機。最後，您可以選擇在啟動時自動裝載您上一次指派給該虛擬光碟機的最後一個影像。
除了 ISO 檔案以外，Virtual CloneDrive 也可以裝載和讀取 .ccd、.dvd、.img、.udf, 及 .bin 檔案。此外，它還會整合到 [Windows 檔案總管] 中，讓您得以快速裝載和卸載影像。而 Virtual CloneDrive 最大的好處之一就是它是免費的。如果您已遷移至 Windows Vista®，而且一直在尋找新的解決方案來管理 ISO 檔案，務必要試試看這個工具。

價格：免費。
Virtual CloneDrive 使用之生氣的羊咩咩
Virtual CloneDrive 使用之生氣的羊咩咩

書評
SharePoint Products and Technologies Administrator's Pocket Consultant
microsoft.com/MSPress/books/10623.aspx
雖然今日的辦公室不見得完全不使用紙張，但是要處理的電子文件的確越來越多。管理這些文件以及這些文件的共用方式變成日益重要的問題，而許多公司都考慮採用 Microsoft SharePoint®Services 與 SharePoint Server 作為解決方案。Ben Curry 所著的 Microsoft SharePoint Products and Technologies Administrator's Pocket Consultant 能提供協助。無論您只是想考慮看看 SharePoint、已經深入到規劃階段，或已經部署好 SharePoint 基礎結構，這本提供系統管理內容與日常工作參考的著作都是您的良伴。
對於看過 Administrator's Pocket Consultant 系列的讀者而言，這本指南也會令人感到熟悉。其精彩的內容與結構水準使這本書出類拔萃。這本書涵蓋了 Windows SharePoint Services 3.0、SharePoint Server 2007 Standard 以及 SharePoint Server 2007 Enterprise Edition。其中分成四個章節。
第一節〈SharePoint 產品和技術基礎〉提供 SharePoint Server 產品的元件、版本、需求及安裝概觀。本節會說明 Windows SharePoint Services 3.0 與 SharePoint Server 的 Standard 及 Enterprise 版本的差異。接下來的內容會分別指引這三種產品的安裝步驟。這一節還詳述了在安裝過程中所建立的 SQL Server 資料庫和 IIS 網站。
下一節是〈SharePoint 核心系統管理〉，其中討論中央系統管理 UI (Central Administration UI)，並提供參考資料來教導您如何建立新的站台集合與站台，如何匯入、使用和編輯 Web 組件，以及如何針對安裝設定群組和電子郵件設定。在此您也可以了解如何管理不同的工作流程功能及監視那些工作流程。
本書的第三部分〈使用 SharePoint Server 2007〉深入探討 SharePoint Server Standard 與 Enterprise 版本專有的特色與功能。其中包括如何設定企業內容管理、如何建立和設定 SharePoint Portal、如何設定搜尋與編制索引，以及如何設定 Excel®Calculation Services 等主題。討論 Excel Calculation Services 的部分，也有提供如何在多伺服器環境中設定服務以便提高效能與可用性的指引。
第四節則細述 SharePoint Server 實作的操作面向、示範如何將 SharePoint Server 2007 擴充成伺服器陣列，以及該實作還有其他哪些可行的設定。最後，書中提到備份與還原作業的基礎、如何分析效能，以及如何使用 SharePoint Server 的記錄功能來協助維護和改善您的站台。
雖然這本書將自己分類為系統管理員的日常參考指南，不過我認為在規劃階段以及對於 SharePoint 有興趣的讀者，都可以將本書視為認識 SharePoint 的捷徑。這本書的架構一開始是以深入淺出的方法來描述不同的 SharePoint 技術和作用，然後進一步導入複雜的主題，像是如何設定 Excel Calculation Services 和擴充成伺服器陣列，這樣可確保為剛開始學習 SharePoint 技術的讀者提供實用的參考，並隨著讀者的知識漸長，也能繼續提供有用的資訊。

價格： $29.99 美元。

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


 SQL 問題與解答: CPU 瓶頸、還原和移動資料庫...等等
SQL 問題與解答
CPU 瓶頸、還原和移動資料庫...等等
由 Nancy Michell 編輯

問：我的 SQL Server™ CPU 使用量突然暴增，但是我沒有做任何變更，未增加新使用者、沒有硬體發生故障、未建立新資料表。因此到底發生了什麼事？

提示：在建立索引期間的存取
有的時候，當您想要對大型資料表建立索引時 (此舉可能要花費大量的時間)，但是卻希望讓資料在此程序的期間仍可使用。您該如何同時達到這兩個目標呢？
叢集索引在建立、刪除或是重建時，SQL Server 都會在資料表上附加結構描述修改 (SCH-M) 鎖定，此舉可以防止所有使用者在此作業期間，存取基礎的資料。這就是當您對資料表建立叢集索引時的情況。相反的，當您對某資料行建立非叢集索引時，SQL Server 會在資料表上附加共用 (S) 鎖定，此舉雖然也會防止對基礎資料表進行資料更新，但是至少讓您能夠執行 SELECT 陳述式，因此您仍可讀取資料。
在建立叢集索引期間，如果資料表的讀取性是重要的，那麼您可以建立資料表的索引，並使其成為線上作業。以下就是這個命令：
CREATE UNIQUE CLUSTERED INDEX CLUST_IDX_SQLTIPS
ON SQLTips (tip) with (ONLINE=ON) Go;
對資料表使用線上索引作業時，SQL Server 仍會在基礎資料表上，針對叢集索引放置 SCH-M 鎖定，或是針對非叢集索引放置共用 (S) 鎖定，但是只會進行一段非常短的時間，亦即在索引作業開始和結束的階段。所以在索引建立期間，此選項可以繼續讓使用者查詢和更新基礎資料表。但是請注意，線上索引建立/作業僅適用於 SQL Server 2005 Enterprise Edition。

答：會突然發生出乎預期的 CPU 瓶頸，伺服器上又毫無變更或額外的負荷時，有幾項可能的核心原因，但是其中一些常見的原因包括：未最佳化的查詢規劃、差勁的 SQL Server 設定、不適當的應用程式/資料庫設計，以及硬體資源不足。
在像這樣的情況下，第一件要做的事情就是辨識您的伺服器是否受 CPU 限制，如果是的話，請找出本機 SQL Server 系統上，成為 CPU 最大消耗者的陳述式。您可以使用效能監視器並查看 PROCESSOR:% PROCESSOR TIME 計數器，來判斷伺服器是否受 CPU 限制。如果您發現每個 CPU 所使用的時間值等於或大於百分之 75，就表示發生了 CPU 瓶頸。
您還應該查詢系統上稱為 SYS.DM_OS_SCHEDULERS 的動態管理檢視 (DMV)，以查看可執行工作的數目，來監視 SQL Server 的排程器。非零的值表示工作必須等候其時間片段才能執行；此計數器的值如果太大，也是發生 CPU 瓶頸的徵兆。
您可以使用以下查詢來列出所有排程器，並且查看可執行工作的數目：
SELECT
 Scheduler_ID,
 Current_Tasks_Count,
 Runnable_Tasks_Count
FROM
 SYS.DM_OS_SCHEDULERS
WHERE
 Scheduler_ID < 255
若要取得前 50 項耗用 CPU 資源的 SQL 陳述式，請使用 [圖 1] 中的查詢。
Figure 1 前 50 大 CPU 資源耗用者 (Close Figure 1)
SELECT TOP 50 (a.total_worker_time/a.execution_count) AS [Avg_CPU_Time],
 Convert(Varchar,Last_Execution_Time) AS 'Last_execution_Time',
 Total_Physical_Reads,
 SUBSTRING(b.text,a.statement_start_offset/2,
 (case when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
 else
 a.statement_end_offset end - a.statement_start_offset)/2) AS Query_Text,
 dbname=Upper(db_name(b.dbid)),
 b.objectid AS 'Object_ID'
 FROM sys.dm_exec_query_stats a
 CROSS APPLY
 sys.dm_exec_sql_text(a.sql_handle) AS b
 ORDER BY
 [Avg_CPU_Time] DESC

問：我必須從磁帶復原 SQL Server 2005 的資料庫。在復原之後，使用者對資料庫所擁有的大部分權限都遺失了。可否告訴我在還原的期間，我做錯了什麼？資料都完好，但是權限都亂成一團。

答：最可能的情況是您未及時將主資料庫還原到同一時間點，並且使用者資料庫中的登入識別碼與目前的主資料庫不符。您必須將其同步。「移動資料庫時可從何處獲得協助」資訊看板列出了最有用的資源，以供您解決在還原或移動資料庫時所遭遇到的問題。

問：我開發了一個應用程式，其中的預存程序使用 SQL Server 2005 SP1 中的 OpenXML，將 XML 資料切換成關聯式資料表。XML 文件最大可為 5KB (平均為 2.5KB)。預存程序可供多次平行呼叫 (至多 50 次)。
我遇到非常嚴重的鎖定爭奪問題，我想它們可能是由 OpenXML 造成的。您認為如何？

答：對於在單一執行緒上切斷或轉換資料，雖然 OpenXML 可能比節點方法快速，但是節點方法通常會有更好的擴充性，特別是在平行使用的情況下。然而，如果您一定要使用 OpenXML，就應該遵循以下指引，來改善整體 OpenXML 的效能。
不要用相同的資料列模式呼叫 OpenXML 五次 (正如您在解決方案中所做的一樣)，您應該將具相同資料列模式的所有資料，都擷取到暫存資料表中，然後再從暫存資料表中執行您的選取作業。請嘗試用 sp_xml_removedocument 盡早釋放記憶體。此外，最好還是避免使用萬用字元 (例如 * 和 //)；而且盡可能提供明確的路徑，因為如此可提升查詢的效率。

問：DBCC SHRINKFILE 在我的伺服器上執行得實在很緩慢。請問在多處裡器的電腦上，是否能獲得較佳的效能？我該怎麼做才能改善這種情況？

答：DBCC SHRINKFILE 是單一執行緒的作業，這表示它無法利用多個 CPU。它會把頁面從檔案的後端移動到檔案的前端，一次移動一個頁面。而且壓縮 (正如其名) 並不會執行重組；事實上在許多情況下，壓縮還會造成邏輯的分散。
改善壓縮效能的一些方式，包括在叢集索引中移動頁面。如果您擁有堆積，並且這些堆積具有許多非叢集的索引，速度就可能相當緩慢 (相較於叢集索引的情況)。
另請注意，移動大型物件區塊 (LOB) 資料的頁面會很緩慢，因為必須讀取整個資料列的資料，才能找到 LOB 資料的根節點。
如果索引/資料表的大部分內容位於檔案的結尾，您就可以重建索引，使其移動到檔案的前端。重建索引會利用多個 CPU，並且在 bulk_logged 模式下可能使用比較少的記錄空間。然後您在執行壓縮時，它就會執行得更快。
如需壓縮作業的詳細資訊，請參考位於 blogs.msdn.com/sqlserverstorageengine/archive/2007/03/29/how-does-your-schema-affect-your-shrink-run-time.aspx 和 blogs.msdn.com/sql-serverstorageengine/archive/2007/04/15/how-to-avoid-using-shrink-in-sql-server-2005.aspx 的內容。
移動資料庫時可從何處獲得協助
  • 如何在執行 SQL Server 的電腦之間移動資料庫
  • 如何使用 SQL Server 中的卸離和附加功能將 SQL Server 資料庫移到新位置
  • INF:使用 WITH MOVE 選項搭配 RESTORE 陳述式
  • 如何解決在 SQL Server 之間移動資料庫的權限的問題
  • INF:如何在 SQL Server 的執行個體之間傳送登入和密碼
  • INF:認識並對 SQL Server 2000 中的複製資料庫精靈進行疑難排解
  • 還原傾印之後發生使用者登入及 (或) 權限錯誤
  • 您無法將系統資料庫備份還原至不同的 SQL Server 組建
  • 如何從資料庫備份或交易記錄檔備份在 SQL Server 擷取特定資料表或資料列

提示：變更通訊埠
任何熟悉 SQL Server 的人都知道，SQL Server 接聽的預設通訊埠編號是 1433。雖然 SQL Server 的命名執行個體係設定為使用動態通訊埠 (這表示在 SQL Server 執行個體啟動的時候，都可以選取任何可以使用的通訊埠)，但是預設的 SQL Server 執行個體卻一律接聽通訊埠 1433。因此，如果您的伺服器也是接聽預設的通訊埠，而您未嚴密地保護它的安全，則伺服器有可能暴露在安全性風險中。但是您可以變更預設的通訊埠來對抗攻擊。以下是變更的方式。
開啟 [SQL Server 組態管理員]，並且展開 [SQL Server 2005 網路組態]，然後選取 [通訊協定]。接下來，按兩下 [TCP/IP]。TCP/IP 屬性的清單及其功能顯示於下列圖表中，請按照規定加以設定。
請注意，SQL Server 資料庫引擎可以在同一 IP 位址上接聽多個通訊埠，因此請以半形逗號，如 1433,1500,1501 的格式分隔，來分別列出您要使用的通訊埠。如果您想要設定單一 IP 位址接聽多個通訊埠，還必須在 [TCP/IP 內容] 對話方塊的 [通訊協定] 索引標籤上，將 [全部接聽] 參數設定為 [否]。
接下來用滑鼠右鍵按一下每個位址，再按一下 [內容] 指定您想要設定的 IP 位址。如果 [TCP 動態通訊埠] 對話方塊包含 0，這表示資料庫引擎正在接聽動態通訊埠，請刪除 0。在 [IP 內容] 區域內的 [TCP 通訊埠] 方塊中，輸入您希望此 IP 位址接聽的通訊埠編號，然後按一下 [確定]。在 [主控台] 窗格中，按一下 [SQL Server 2005 服務]，並且在 [詳細資訊] 窗格中，用滑鼠右鍵按一下 [SQL Server (<執行個體名稱>)]，然後按一下 [重新啟動]，以停止並重新啟動 SQL Server。
在將 SQL Server 設定為接聽特定通訊埠之後，共有三種方式可供用戶端連接到此通訊埠。您可以在伺服器上執行 SQL Server 瀏覽器服務，用名稱來連接到資料庫引擎執行個體；您可以在用戶端建立一個別名，指定其通訊埠編號；或是您可以用程式設計的方式，將用戶端設計為利用自訂連接字串來連接。

屬性 | 描述
使用中 | 表示 SQL Server 正在接聽指定的通訊埠。不適用於 IPAll。
已啟用 | 啟用或停用這個連線。不適用於 IPAll。
IP 位址 | 檢視或變更此連線所使用的 IP 位址。列出電腦所使用的 IP 位址，以及 IP 回送位址 127.0.0.1。不適用於 IPAll。
TCP 動態通訊埠 | 如果動態通訊埠尚未啟用，即為空白。若要使用動態通訊埠，請設定為 0。
TCP 通訊埠 | 檢視或變更 SQL Server 接聽的通訊埠。根據預設，預設執行個體會接聽通訊埠 1433。此欄位僅限 2047 個字元。

感謝以下 Microsoft IT 專家回答本月的問題： Chad Boyd、Cindy Gross、John Hadden、Saleem Hakani、Stephen Jiang、Mahesh Nayak、Paul Randal 及 Wayne Yu。


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

一般的 Windows® 磁碟重組工具可以最佳化您硬碟機上的大多數檔案，但是某些項目卻令大多數的磁碟重組工具束手無策。已開啟並鎖定為專用的檔案，例如 Windows 分頁檔和登錄 Hive，通常無法由 Windows 內建的磁碟重組工具或其他廠商的公用程式處理。檔案正在使用中時，標準的 Windows API 無法支援這些檔案的磁碟重組功能。還好，由 Mark Russinovich 為 Sysinternals 建立的 PageDefrag 公用程式，可以成功地重組其他工具無法處理的項目。
PageDefrag 可以成功地重組 Windows 分頁檔、登錄 Hive、事件記錄檔及休眠檔案 (當筆記型電腦進入休眠模式時，儲存記憶體資料的磁碟區域)。該程式會在電腦開機過程中，於系統開始使用這些檔案時先將它們最佳化。
若要執行 PageDefrag，只需要按兩下 pagedfrg.exe 檔案。程式會顯示每一個它可以進行磁碟重組之檔案的名稱 (請參閱 [圖 1])。分頁檔的名稱為 pagefile.sys。登錄 Hive 會以各 Hive 的個別檔案 (DEFAULT、SAM、SECURITY、SOFTWARE 及 SYSTEM) 顯示。事件記錄檔會以個別檔案顯示；例如，AppEvent.evt 是應用程式記錄檔，SecEvent.evt 是安全性記錄檔，而 SysEvent.evt 是系統記錄檔。最後，休眠檔案則是 Hiberfil.sys。
圖 1 PageDefrag 會顯示每一個可以處理之檔案的名稱
圖 1 PageDefrag 會顯示每一個可以處理之檔案的名稱
在各檔案名稱的旁邊，會有一個 [Clusters] (叢集) 欄，其中會顯示磁碟上有多少個叢集已配置給該檔案，還會有一個 [Fragments] (片段) 欄，以指出磁碟上有多少個檔案的片段，亦即非連續性的檔案片段。根據此資料，您就可以判斷檔案是否需要進行磁碟重組。
您有兩個選項：您可以在下一次開機時進行檔案的重組，或在每一次開機時進行。除非檔案的使用率非常高，或者位於極少重新開機的伺服器或電腦上，否則僅在下一次開機時進行重組應該就可以了。您也可以啟用倒數功能，以便您在下一次電腦開機時可以取消磁碟重組作業。
您下一次重新開機時，系統會執行 chkdsk 命令，然後 PageDefrag 就會開始作業。已經組織成連續叢集的檔案會略過。有片段的檔案則會一一重組，以最佳化。程式會顯示正在進行磁碟重組的項目名稱，還會告訴您重組是否成功，以及在重組前和重組後所配置給檔案的叢集數目。
如果電腦上的可用磁碟空間不夠多，或是可用的空間也已經嚴重地劃分為多個片段，則 PageDefrag 有可能會無法進行重組檔案以最佳化。在這樣的情況下，您就需要先在 Windows 中執行磁碟重組工具來釋放可用空間，然後再嘗試執行 PageDefrag。
PageDefrag 的執行速度通常很快，因為它所處理的檔案數目不多。然而，如果檔案已劃分為很多個片段，則至少在第一次執行時，會需要花費較久的時間。PageDefrag 完成作業之後，Windows 就會正常地載入。您可再次開啟該程式，以確認每一個檔案都已經重組為單一片段。
您可以在命令列上以非互動式的方法執行 PageDefrag，或是在指令碼中使用 -e Defrag boot、-o Defrag once、-n Never Defrag 等選項，以及使用 -t Set countdown 選項來指定 pagedfrg.exe 檔案執行前的倒數時間。
若要進一步了解並下載此公用程式，請造訪 microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx。

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


 The Cable Guy: 強式和弱式主機模型
The Cable Guy
強式和弱式主機模型
Joseph Davies

將網路主機設定為包含數個網路介面的多重主目錄主機，已經越來越普遍。多重主目錄主機能提供增強的連接性，因為它可同時連線到多個網路，例如內部網路或網際網路。但是正由於它們可以同時連線到內部網路與
網際網路，在多重主目錄上執行的服務會比較容易遭受攻擊。為了協助防止攻擊，以及介紹多重主目錄主機處理 IP 流量的方式，我將說明多重主目錄主機的弱式和強式主機模型，然後解釋在 Windows® 中如何支援這些模型。
RFC 1122 是描述多重主目錄主機的兩個模型的規格，其中的多重主目錄主機並非當做路由器使用，而且只會傳送和接收單點傳播 IP 流量。這些模型稱為強式主機和弱式主機，會指定傳送或接收的單點傳播流量是否必須與此流量流經的網路介面建立關聯。這些模型會決定主機如何傳送和接收封包，而且會影響主機上執行之服務的安全性風險。
雖然 RFC 1122 是針對 IPv4 定義這些模型，但 IPv6 也同樣適用。舉例而言，IPv6 的多重主目錄主機可以是同時使用 IPv4 與 IPv6 的電腦，其中包含連線到內部網路和 IPv6 通道介面的網路介面卡。

弱式主機模型
在弱式主機模型中，IP 主機 (無論是 IPv4 或 IPv6) 可以在未指派所傳送之封包的來源 IP 位址的介面上傳送封包。這就是所謂的弱式主機傳送行為。IP 主機也可以在未指派所接收之封包的目的地 IP 位址的介面上接收封包。這就是所謂的弱式主機接收行為。
當您使用包含多重介面的多重主目錄 IP 主機時，在這些介面上啟用弱式主機接收行為有時會使得主機容易遭受多重主目錄攻擊。譬如說，[圖 1] 顯示主機 A 同時連線到網際網路與內部網路。主機 A 的公用 IPv4 位址 131.107.89.211 已指派給網際網路介面，而私人 IPv4 位址 192.168.17.48 則指派給內部網路介面。
圖 1 多重主目錄電腦的範例
圖 1 多重主目錄電腦的範例
同時在網際網路與內部網路介面上啟用弱式主機傳送行為時，主機 A 可以傳送來自網際網路介面上 131.107.89.211 的封包、來自網際網路介面上 192.168.17.48 的封包、來自內部網路介面上 131.107.89.211 的封包，以及內部網路介面上 192.168.17.48 的封包。
啟用弱式主機接收行為時，主機 A 可以接收下列封包類型 (假設主機防火牆規則允許連入流量)：在網際網路介面上傳送到 131.107.89.211 的封包、在網際網路介面上傳送到 192.168.17.48 的封包、在內部網路介面上傳送到 131.107.89.211 的封包、在內部網路介面上傳送到 192.168.17.48 的封包。
當您啟用弱式主機接收行為時，網際網路上的惡意使用者可以傳送封包到主機 A 的網際網路介面，藉此攻擊在主機 A 上面執行但僅提供給內部網路之主機使用的服務。如果網際網路基礎結構支援將目的地為 192.168.17.48 的封包轉送到主機 A 的網際網路介面，就可能發生此類型的攻擊。您可以透過在主機 A 的網際網路介面上設定適當的防火牆規則，來防止此類型的攻擊。不過，即使這麼做，在主機 A 上執行且適用於內部網路用戶端的服務仍然具有風險。

強式主機模型
在強式主機模型中，傳送和接收行為不太一樣。進行強式主機傳送時，主機只能在已被指派所傳送封包之來源 IP 位址的介面上傳送封包。進行強式主機接收時，主機只能在已被指派所接收封包之目的地 IP 位址的介面上接收封包。
在網際網路和內部網路介面上啟用強式主機傳送行為時，[圖 1] 中的主機 A 只能在網際網路介面上傳送來自 131.107.89.211 的封包，以及在內部網路介面上傳送來自 192.168.17.48 的封包。
啟用強式主機接收行為時，主機 A 只能在網際網路介面上接收傳送到 131.107.89.211 的封包，以及在內部網路介面上接收傳送到 192.168.17.48 的封包。
在 [圖 1] 中，您無須設定防火牆規則，主機 A 的強式主機模型便會刪除在網際網路介面上傳送到位址 192.168.17.48 的所有連入封包，有效地隔離主機 A 的內部網路介面與網際網路。
當您選擇強式主機模型時，請記得這會影響某些專為弱式主機行為而設計的連線類型。例如，某些負載平衡實作可能會使用弱式主機接收行為，以便在任何介面上接收封包，然後從內部將這些封包路由到適當的介面。使用弱式主機傳送的主機，在傳送來自任何來源位址的流量至連線較快的介面時，也可能會受到影響。

強式主機傳送和接收
我們現在來看一下，當您允許每個介面啟用或停用強式主機傳送和接收時，傳送和接收程序將如何在 IPv4 或 IPv6 的一般主機上運作。
針對要傳送的封包，IP 首先會檢查是否已經指定來源位址。若未指定，IP 便會在路由表中，針對封包進行目的地位址的無限制查詢。無限制查詢會考慮路由表中的所有路由。根據目的地所選定的路由，IP 會決定下個躍點介面 (用來在連結階層放置封包的介面) 和下個躍點位址。根據下個躍點介面，IP 會視需要使用 RFC 3484 中定義的位址選擇程序，來決定最佳的來源位址。此時，IP 已經做好傳送封包的準備：來源和目的地位址、下個躍點介面，以及下個躍點位址。
來源位址一旦指定，就會知道來源介面。來源介面會被指派來源位址。接著 IP 會判斷來源介面上是否有啟用強式主機傳送。
如果已停用，IP 便會在路由表中，執行封包目的地位址的無限制查詢。IP 會根據目的地的最佳路由，來決定下個躍點介面和躍點位址。IP 具有來源與目的地位址、下個躍點介面，以及下個躍點位址。請注意，若在來源介面上停用強式主機傳送行為，則下個躍點介面可能會與來源介面不同。
如果來源介面上有啟用強式主機傳送，則 IP 會在路由表中進行封包目的地位址的有限制查詢。在有限制查詢中，只會考慮包含來源介面之下個躍點介面的路由。根據為目的地選取的路由，IP 會決定下個躍點位址。IP 具有來源與目的地位址、下個躍點介面，以及下個躍點位址。請注意，若在來源介面上啟用強式主機傳送行為，則下個躍點介面永遠會與來源介面相同。[圖 2] 顯示一般 IP 傳送主機的處理程序。
圖 2 一般 IP 傳送主機的處理程序
圖 2 一般 IP 傳送主機的處理程序
一旦指定來源位址之後，有限制路由查詢就可以在路由表的數個最接近目的地的路由中，選取公制較高的路由。例如，[圖 1] 中的主機 A 有兩個預設路由；其中一個指向網際網路且公制為 10，另一個則指向內部網路且公制為 20。強式主機行為在兩個 LAN 介面上均已啟用。
如果主機 A 上的傳送應用程式並未指定來源位址，那麼路由查詢的結果將會是公制較低的預設路由；主機 A 一定會透過來源位址 131.107.89.211 從網際網路介面傳送流量。但是，如果主機 A 上的傳送應用程式指定來源位址為 131.107.89.211，那麼查詢結果就是網際網路介面的預設路由；主機 A 會從網際網路介面傳送流量。如果主機 A 上的傳送應用程式指定來源位址為 192.168.17.48，那麼查詢會選取內部網路介面的預設路由；主機 A 會從內部網路介面傳送流量。使用有限制路由查詢時，IP 會使用公制較高的預設路由，透過來源位址 192.168.17.48 來傳送流量。
針對接收的流量，IP 首先會確定此流量的目的地是否為該主機。若否，則 IP 會以無訊息的方式放棄此封包，因為主機並非當作路由器使用。IP 接著會判斷連入介面 (接收封包的介面) 上是否有啟用強式主機接收。若已停用，IP 便會處理此封包。若已啟用，IP 會確定封包中的目的地位址，是否指派到連入介面。如果是的話，IP 便會處理此封包。否則，IP 會以無訊息的方式放棄此封包。[圖 3] 顯示一般接收主機的處理程序。
圖 3 接收主機處理程序
圖 3 接收主機處理程序

Windows 中的弱式和強式主機行為
Windows XP 及 Windows Server® 2003 會使用弱式主機模型來進行所有 IPv4 介面的傳送與接收，並使用強式主機模型來進行所有 IPv6 介面的傳送與接收。您無法設定此行為。根據預設，Windows Vista 和 Windows Server 2008 中的下一代 TCP/IP (Next Generation TCP/IP) 堆疊，將可支援在 IPv4 與 IPv6 的所有介面上同時啟用強式主機傳送與接收，但 Teredo 主機特定轉送的 Teredo 通道介面除外。[圖 4] 列出可用來為 IPv4 和 IPv6 的各個介面設定傳送與接收行為的命令。請注意，InterfaceNameOrIndex 是 [網路連線] 資料夾的介面名稱，或是它的介面索引。您可以從下列命令所顯示的資料中，取得介面的介面索引：
Figure 4 設定強式和弱式傳送與接收行為的命令 (Close Figure 4)

• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv4 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostsend=enabled|disabled
• netsh interface ipv6 set interface [InterfaceNameOrIndex] weakhostreceive=enabled|disabled
netsh interface ipv6 show interface
弱式和強式主機行為與 RFC 3484
為了提供標準化方法來選擇要進行連線的來源及目的地 IPv6 和 IPv4 位址，RFC 3484 定義了兩個演算法。第一個是來源位址選擇演算法，可用來選擇搭配目的地位址的最佳來源位址。另一個是目的地位址選擇演算法，可根據喜好設定順序來排序可能的目的地位址清單。
針對特定目的地位址選擇來源位址候選清單時，強式和弱式主機行為會產生作用，而這也會影響到最終排序的目的地位址清單。就強式主機傳送行為而言，來源位址候選清單是由指派給目的地之傳送介面的單點傳播位址所組成。就弱式主機傳送行為而言，候選清單可能包含已指派給啟用弱式主機傳送之任何介面的位址。如需有關來源與目的地位址選擇的詳細資訊，請造訪 microsoft.com/technet/community/columns/cableguy/cg0206.mspx。

根據預設，弱式主機傳送與弱式主機接收都會在 IPv4 和 IPv6 的所有介面上停用，但 Teredo 主機特定轉送的 Teredo 通道介面除外。
如需有關 RFC 3484 的詳細資訊，請參閱「弱式和強式主機行為與 RFC 3484」資訊看板。

停用遠端存取 VPN 連線的預設路由
遠端存取虛擬私人網路 (VPN) 用戶端，是多重主目錄主機的另一個範例。即使它可能有連線到網際網路的單一 LAN 介面，但是當遠端存取 VPN 用戶端完成 VPN 連線時，它就算是多重主目錄。其中包含兩個介面：LAN 介面，以及用於 VPN 連線並以點對點通訊協定 (Point-to-Point Protocol，PPP) 為基礎的介面。其中也有兩個 IPv4 位址：網際網路服務提供者 (ISP) 為 LAN 介面指派的 IPv4 位址，以及 VPN 伺服器為 PPP 型介面指派的 IPv4 位址。
為了確保 VPN 用戶端會經由 VPN 連線傳送預設路由流量到內部網路，Windows XP 和 Windows Server 2003 修改了 IPv4 路由表，其中提高了現有預設路由的公制，並新增了使用 PPP 介面且公制較低的預設路由。這項預設行為讓內部網路上的位置可供連接，而且讓網際網路上的幾乎所有位置在 VPN 連線期間都不可連接。藉由不新增 VPN 連線的預設路由，並且新增內部網路目的地的特定路由，便可為 VPN 用戶端設定分割通道，使其同時具有網際網路與內部網路的存取能力。不過，風險是分割通道 VPN 用戶端可以在網際網路與內部網路之間路由封包。如需詳細資訊，請參閱 microsoft.com/technet/community/columns/cableguy/cg1003.mspx。
Windows XP 和 Windows Server 2003 中的預設 VPN 用戶端行為，是專為弱式主機傳送行為所設計。路由查詢永遠會使用 VPN 連線的預設路由，因為它的公制最低。但是當您使用強式主機傳送行為時，傳送流量所使用的預設路由將取決於封包中的來源 IP 位址。針對由 ISP 指派且來自 IPv4 位址之流量的路由查詢將使用預設路由，而此預設路由會使用 LAN 介面，讓所有網際網路位置都可供連接。針對由 VPN 伺服器指派且來自 IPv4 位址之流量的路由查詢將使用預設路由，而此預設路由會使用 PPP 介面，讓所有內部網路位置都可供連接。因此，當您使用強式主機傳送行為時，VPN 用戶端會因為具有分割通道設定，而可以同步存取網際網路與內部網路，即使是沒有系統管理員層級權限來直接修改 IPv4 路由表的應用程式也是如此。
為了防止強式主機傳送行為在預設情況下建立分割通道設定，Windows Vista® 和 Windows Server 2008 中的 VPN 用戶端會在 VPN 連線完成時，自動停用 LAN 介面的預設路由。這個行為可確保在路由表中，只有單一作用中預設路由會使用 PPP 介面。此外，這項行為也可確保沒有系統管理員層級權限的應用程式，將無法執行分割通道。
由於來自 VPN 用戶端電腦的流量必須源自由 VPN 伺服器指派的 IPv4 位址，因此這項行為更能有效隔離內部網路與網際網路。當 VPN 連線終止時，停用的預設路由便會啟用。
您可以使用以下命令來控制這項行為：
netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

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


 Windows PowerShell: 確保殼層的安全性
Windows PowerShell
確保殼層的安全性
Don Jones

當 Windows PowerShell 小組齊聚一堂來建立新的殼層時，會議室中不斷提到「指令碼」一詞，使整個總部 (Redmond) 大概都聽得見充滿挫折的呻吟聲。畢竟，Microsoft 之前對於系統管理指令碼所做的努力 (我是指 VBScript) 不能說是完全沒有問題。而
過度寬鬆的執行模型，再加上多數使用者喜歡以完整的系統管理員權限登入的習慣，因此開啟了災難之門。
「不用說，」那場 Windows PowerShell™ 的首次會議的與會者一定祈禱「不要再經歷一次相同的折磨。」他們的確沒有。Microsoft 已經提升它的安全性評價，最主要是因為 Microsoft 開始提前設想安全性，而非在稍後的產品開發週期中才考量。這種哲學在 Windows PowerShell 中表現的淋漓盡致。

我的指令碼為什麼不執行？
在全新的電腦上安裝 Windows PowerShell 並按兩下 .ps1 檔案：出現記事本，而非 Windows PowerShell。這是因為 .ps1 副檔名 (用於 Windows PowerShell 指令碼的副檔名) 與殼層本身沒有關聯性。換句話說，您無法以按兩下指令碼的方式來執行它。執行指令碼唯一的方法是開啟 Windows PowerShell，輸入指令碼名稱，然後按 Enter。
實際上，僅僅輸入指令碼名稱也不足夠。您可以在 [圖 1] 中看到，檔案 Demo1.ps1 存在於目前的資料夾中，但只是輸入 demo1 並按下 Enter 會產生錯誤：「'demo1' 詞彙無法辨識是否為 Cmdlet、函數、可執行程式或指令檔。」為什麼會這樣？畢竟，這個檔案的確存在。
圖 1 為了防止命令劫持 (Command Hijacking)，Windows PowerShell 需要指令碼路徑
圖 1 為了防止命令劫持 (Command Hijacking)，Windows PowerShell 需要指令碼路徑
這是 Windows PowerShell 安全性模型的另一個層面。惡意使用者常在其他殼層中使用的攻擊手法，就是建立與內建命令相同檔名的指令碼。舉例來說，如果您要使用者執行您的指令碼，您可能將其命名為 Dir.ps1，然後放入資料夾中。如果您說服使用者輸入 Dir 並按下 Enter，您的指令碼可能會執行並非使用者期待的 Dir 命令。這種技巧稱為命令劫持 (Command Hijacking)。在 Windows PowerShell 中，您必須總是提供這類指令碼的路徑，以便有效防護 Windows PowerShell 不受命令劫持 (Command Hijacking) 的攻擊。
執行 demo1 沒有作用，因為並未提供路徑，但是 ./demo1 就會執行。這是因為我已經指定了路徑，即目前的資料夾。這個命令行不太可能與內建命令搞混，因為如果您指的是內建命令，就不會輸入這樣的路徑。因此，要求路徑能讓 Windows PowerShell 防止命令劫持 (Command Hijacking)，也能避免按下 Enter 之定義的混亂。

指令碼執行原則
安裝了嶄新的 Windows PowerShell，也使用正確的語法之後，現在您嘗試執行指令碼。但出乎意料之外，您又遇到另一個錯誤訊息，告知您不允許 Windows PowerShell 執行指令碼。您可能會驚嘆：為什麼？歡迎來到殼層的執行原則的世界。
您可以在殼層中執行 Get-ExecutionPolicy，即可檢視目前的執行原則。在預設情況下，執行原則會設定為 Restricted，簡單來說，就是無論如何都不會執行指令碼。根據預設，Windows PowerShell 只能以互動方式使用，而非用以執行指令碼。您可以使用 Set-ExecutionPolicy 指令程式 (Cmdlet)，從以下四種可用的執行原則設定中選擇其中一種：
  • Restricted，這是預設設定，將不允許執行任何指令碼。
  • AllSigned 只會執行受信任的指令碼 (稍後再詳加說明)。
  • RemoteSigned 會執行本機指令碼而不會要求它們是受信任的指令碼；不過，從網際網路下載的指令碼則必須是受信任的指令碼，才可執行。
  • Unrestricted 允許執行所有指令碼，即便是未受信任的指令碼。
坦白說，所有實際執行的電腦至少都應設為 AllSigned。我發現 RemoteSigned 適合用於開發和測試環境，但一般使用者就不必了。至於 Unrestricted，我認為根本沒有必要，而且我認為未來的 Windows PowerShell 版本應該刪除這個過度寬鬆的設定。

信不信任的問題
您的電腦已經預先設定為信任特定根憑證授權單位 (CA)，即核發數位憑證的伺服器。[圖 2] 顯示 [網際網路選項] 控制台應用程式，其中列出受信任的根 CA。在 Windows Vista® 中，這份清單很短，而且只包含一些主要的商業根 CA。相反地，Windows® XP 中的預設清單就很龐大，而且包含許多我從未聽過的根 CA。如果根 CA 列在此清單中，基本上就表示您信任操作此根 CA 的公司會先確實檢查某人的身分，然後才核發數位憑證。
當您取得第三級 (Class III) 數位憑證時 (通稱為程式碼簽署憑證)，CA (可能是商業 CA 或組織內部的私人 CA) 必須驗證您的身分。數位憑證就像是電子護照或識別卡。舉例來說，在核發表示我是 Don Jones 的 ID 之前，CA 必須採取一些步驟來確認我真的是 Don Jones。當您使用您的憑證來數位簽署 Windows PowerShell 指令碼時 (您可以使用 Set-AuthenticodeSignature 指令程式來執行這項作業)，您是將自己的名字簽署到指令碼中。當然，如果您能夠取得包含別人名字的假憑證，您就可以把那個人的名字簽署到指令碼中，正因如此，[圖 2] 的清單必須只顯示值得信任的 CA。
圖 2 Windows Vista 中預設為受信任的根 CA
圖 2 Windows Vista 中預設為受信任的根 CA
當 Windows PowerShell 查看指令碼是否受信任時 (在 AllSigned 和 RemoteSigned 執行原則設定底下這麼做)，它會提出三個問題：
  • 這個指令碼是否經過簽署？若否，則表示指令碼不受信任。
  • 簽章是否完好？換句話說，指令碼在簽署之後是否遭到變更？如果簽章不完整，則表示指令碼不受信任。
  • 簽章是否使用由受信任的根 CA 所核發的數位憑證來建立？若否，則表示指令碼不受信任。
本月指令程式：Set-AuthenticodeSignature
Set-AuthenticodeSignature 是簽署 Windows PowerShell 指令碼的關鍵，可讓您使用殼層最安全的執行原則 AllSigned。若要使用這個指令程式，首先要使用另一個指令程式 (Get-ChildItem) 來擷取已安裝的程式碼簽署憑證：
$cert = Get-ChildItem –Path cert:\CurrentUser\my –codeSigningCert
您必須將該檔案路徑替換成指向已安裝憑證的檔案路徑，任何已安裝的憑證都可以透過 cert:drive 的方式來存取。一旦載入憑證之後，執行下列即可簽署指令碼：
Set-AuthenticodeSignature MyScript.ps1
–cert $cert
當然還要提供 .ps1 指令檔的完整路徑。Shell 會新增簽章區塊到檔案中。

這如何提升安全性？沒錯，駭客的確可能會撰寫惡意的指令碼，簽署此指令碼，然後說服您的環境中的使用者執行這個指令碼。由於此指令碼已經過簽署，因此將會執行。但是因為這個指令碼已經過簽署，因此您可以使用此簽章來尋找作者的身分，並採取適當的行動 (例如，訴諸執法機構)。不過，如果建立惡意指令碼的人還簽署自己的真實名字，那也真夠笨的了！
當然，要是惡意使用者能夠取得其他身分的憑證，例如從身分檢查作業不完善的 CA 取得憑證，您就無法使用簽章來找出真正的罪犯。這也是為什麼您信任的根 CA 應該具備讓您滿意的身分驗證程序。
使用 AllSigned 執行原則設定時，您甚至需要在執行自己產生的指令碼之前，先逐一數位簽署這些指令碼。Set-AuthenticodeSignature 指令程式很容易使用，但這些作業還是有點繁瑣。這時協力廠商軟體就派上用場了。建議您選擇指令碼編輯器或視覺式開發環境，來使用您指定的憑證自動簽署指令碼。如此一來，簽章的使用情況就一目了然，而且也不費力。如需支援的編輯器與開發環境的建議，請造訪線上指令碼論壇 (例如我的網站：ScriptingAnswers.com)，並張貼訊息來詢問其他 Windows PowerShell 支持者使用的編輯器與開發環境。
當您取得憑證之後，您也可以執行下面的單行指令來簽署特定位置的所有指令碼：
Get-Childitem *.ps1 | %{Set-AuthenticodeSignature $_.fullname $cert}

集中保障安全性
顯然 Windows PowerShell 執行原則可以依照逐部電腦的方式進行設定。但是對於企業環境來說，這不是理想的解決方案。在這種情況下，您可以使用群組原則 (您可以從以下網址下載 Windows PowerShell 系統管理範本：go.microsoft.com/fwlink/?LinkId=93675)。只要將檔案拖放到可影響整個網域的群組原則物件 (GPO) 中，然後設為 Restricted 即可。這麼一來，無論 Windows PowerShell 安裝在哪裡，您都不必擔心會執行指令碼。接著，您可以在要執行指令碼的電腦上 (像是您自己的工作站) 套用更寬鬆的設定 (例如 AllSigned)。

替代憑證
不同於 Windows 之前的系統管理指令碼語言，Windows PowerShell 甚至已經做好準備，能夠在安全的情況下應付替代憑證。舉例來說，Get-WMIObject 指令程式包含 –credential 參數，可讓您為遠端 WMI 連線指定替代憑證。此參數可接受使用者名稱但不接受密碼，藉此防範將密碼用硬式編碼的方式寫在純文字指令碼中。而是在您提供使用者名稱時，Windows PowerShell 會使用對話方塊提示您輸入密碼。若您打算再次使用替代憑證，您可以使用 Get-Credential 指令程式來儲存驗證資訊：
$cred = Get-Credential DOMAIN\USER
您會立刻看到輸入密碼的提示，而最終憑證將會儲存在變數 $cred 中。接著可以視需要將 $cred 變數傳遞到 –credential 參數。您甚至可以使用 ConvertTo-SecureString 和 ConvertFrom-SecureString 指令程式，將憑證轉換成加密的字串，或將先前加密的字串轉換回憑證。
但是此舉的問題在於，您的加密金鑰會儲存在純文字指令碼中，完全失去安全防護功能。因此替代的作法是新增 Get-Credential 的呼叫到 Windows PowerShell 設定檔中。那麼當 Windows PowerShell 執行時，您會立刻看到輸入使用者名稱和密碼的提示，而使用者名稱和密碼接著會儲存在名為 $cred 的變數中。如此一來，Shell 中將會永遠有一個代表網域系統管理員帳戶的 $cred 變數。您也無須在任何地方儲存該憑證；因為每次開啟殼層時都會重新建立憑證，也就無須費心儲存了。

預設的安全環境
在預設情況下安裝和設定的 Windows PowerShell，會提供支援指令碼的系統管理殼層所能提供的最高安全等級設定。除非您變更這些設定，否則 Windows PowerShell 將會盡可能維護安全性。也就是說，只有您的決策和動作會降低 Windows PowerShell 的安全性。因此，在變更任何預設值之前 (重新設定副檔名關聯、變更執行原則...等等)，請先確認您已完全了解這些動作的後果，並且願意負起這些變更的責任。

Don Jones 是 SAPIEN Technologies 的指令碼語言大師，也是 ScriptingTraining.com 的講師。您可以透過 Don 的網站與他連絡：ScriptingAnswers.com。


 嗨，Scripting Guy！: 如何建立關係/關聯性？
嗨，Scripting Guy！
如何建立關係/關聯性？
Microsoft Scripting Guy
下載本文程式碼: HeyScriptingGuy2007_09.exe (150KB)

人際關係 很重要。但是 Scripting Guy 又是怎麼知道這一點的呢？至少我們都有看電視，電視上都有說：人際關係很重要。
而且我們指的不只是連續劇或是電視上播的本週強檔影片。例如，某理財貸款公司的廣告就熱烈歡迎大家上門借錢。這是因為他們願意借錢給原來沒本事借錢的人嗎？不是。那難道是因為他們的年利率高達 900% 嗎？當然不是這樣的。真正的原因是，這家公司會與您建立密切的個人關係。就像他們的廣告說的：「人際關係真的大有關係」。
請注意：是啦，我們已經感動得落淚，而且這也沒什麼好丟臉的。畢竟，想到有人竟然能夠和他的高利貸公司建立起深厚不變的親密關係，真的很感人嘛。
我們知道讀者們正在想什麼：「如果高利貸公司和借款人之間的關係 (Relationship) 有那麼重要，撰寫與關聯式資料庫互動的指令碼的人不就更要注重關聯性 (Relationship) 囉。」沒錯，事實上，撰寫與資料庫互動的指令碼的人，一定要注重關聯性。可惜的是，許多指令碼撰寫者有時會忽略關聯性的重要性。但是沒有關係，在本月的專欄中，我們會糾正大家的觀念。
我們知道許多系統管理員都會使用資料庫，而常見用途之一就是追蹤硬體數量。問題是，大多數的資料庫都沒有採用最佳化的架構。舉例而言，如果您要建立一個資料庫來記錄所有電腦上的硬碟機。如果您對於資料庫設計不熟，就可能會建立一個只有單一資料表的資料庫，如 [圖 1] 所示。
圖 1 單一資料表資料庫
圖 1 單一資料表資料庫
如您所見，這個設計十分簡單：其中有一個電腦名稱的欄位和數個是/否的欄位，以記載電腦是否具有 C:磁碟機和 D:磁碟機。就這樣而已。很簡單明瞭。
那麼這個資料庫到底有什麼問題呢？老實說，問題太多了。如果您可以確保所有電腦上的硬碟機都不會超過兩顆，這個設計才能勝任 (應該可以)。但是，萬一有台電腦裝了三顆硬碟機，那該如何？在這樣的情況下，您就需要新增一個可以記錄 E 磁碟機的欄位。那麼，萬一有台電腦裝了 11 顆硬碟機，那該怎麼辦呢？而且，如果您必須追蹤每一顆硬碟機的屬性，那又怎麼辦？例如，如果您想要追蹤每一顆硬碟機的總大小。那麼，您就需要加入一個 Drive_C_Size 欄位、一個 Drive_D_Size 欄位，以及一個 Drive_E_Size 欄位...好啦，您知道問題出在哪了吧 (而且搞不好您還需要追蹤可用磁碟空間、磁碟機連接類型、是否有啟用磁碟配額...等等)。
您需要牢記的基本原則如下：只要項目需要追蹤一個以上的項目 (例如，電腦可以配置一個以上的硬碟機)，就不應該採用「一般檔案」(單一資料表) 的設計。是的，就硬碟機的案例而言，或許您會認為單一資料表的設計還勉強可用，畢竟會安裝到電腦上的硬碟機數目有限。但是，如果您想要查詢資料庫以傳回硬碟機大小大於 100 GB 的清單，要如何在這樣的設計中達成目標？答案是，您需要先在 Drive_C_Size 欄位中搜尋大於 100 GB 的硬碟機，然後在 Drive_D_Size 欄位中執行相同的搜尋，然後在 Drive_E_Size 欄位中執行相同的搜尋，然後...由此可見，這絕對不是很有效率或可行的方法。那麼，應該採取什麼樣的替代方案呢？如果無法使用一般資料庫檔案，那應該使用哪一種資料庫？
答案很簡單：當然是關聯式資料庫囉。關聯式資料庫原本就設計為可以處理一對多的關聯性 (例如，一部電腦可以有多顆硬碟機)。我們知道您想要問的問題，答案是：您不需要另購任何設備即可使用關聯式資料庫，因為只要有某一種資料庫 (例如 Microsoft® Access™、SQL Server™、Oracle...等等)，就應該有關聯式資料庫的功能。您不需要另購任何設備，只需要知道兩件事：1) 如何在資料庫中的兩個資料表之間建立關聯性；以及 2) 如何撰寫能夠運用該關聯性的指令碼。
請注意：電視上有說，我們不應該運用人際關係來獲取好處，但是，此關係非彼關係。
由於本專欄並不是「嗨，資料庫設計家！」專欄，所以我們不會花費太多時間討論資料庫的設計。我們將使用一個簡單的關聯式資料庫設計，幫助您了解撰寫關聯式查詢的方法。在此資料庫中，我們有兩個資料表。第一個的名稱為「Computers」，其中有兩個欄位：ComputerName 和 SerialNumber。ComputerName 欄位是存放電腦名稱的地方，而 SerialNumber 欄位則是要存放...哦，您已經猜到了嗎？沒錯，就是序號。
那我們到底要把硬碟機資訊存放在哪裡？這些資訊會存放在第二個資料表中，命名為 DiskDrives。此資料表包含三個性質簡單明確的欄位：SerialNumber、DriveLetter，以及 DriveSize。
此處的關鍵欄位是 SerialNumber。如果您覺得此欄位名稱很耳熟，沒錯，這就是在 Computers 資料表中的相同欄位名稱。這可不是意外或巧合；這是我們刻意設計的。這是為了要在這兩個資料表之間建立關聯性，所以需要有一個會出現在各個資料表中的欄位；這樣我們才知道哪一顆硬碟機屬於哪一部電腦。
那麼，為什麼我們要使用序號，而不使用電腦名稱？原因很簡單：電腦名稱可以 (而且也經常會) 變更。序號通常不會變更。
讓我們別再紙上談兵了。請看看 [圖 2] 的指令碼，它會搜尋這兩個資料表，並擷取屬於各電腦的硬碟機清單。[圖 3] 顯示此指令碼傳回的資料。
Figure 3 搜尋結果 (Close Figure 3)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-01
E:

atl-ws-02
C:

atl-ws-02
D:
Figure 2 搜尋資料表 (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
 "Provider = Microsoft.Jet.OLEDB.4.0; " & _
 "Data Source = c:\scripts\test.mdb"

objRecordSet.Open "SELECT Computers.*, DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber " & _
 "ORDER BY Computers.ComputerName, DiskDrives.Drive", objConnection, adOpenStatic, _
  adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
 Wscript.Echo objRecordset.Fields.Item("ComputerName")
 Wscript.Echo objRecordset.Fields.Item("Drive")
 Wscript.Echo
 objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
我們不會在本月的專欄中討論連接與使用資料庫的基本概念；如果您是資料庫指令碼的新手，建議您先觀賞 Scripting Guy 的網路廣播「系統管理員的資料庫指令碼需知」 (go.microsoft.com/fwlink/?LinkId=22089)。我們只能透漏一點點消息 -- 我們所連接的是 Access 資料庫 (C:\Scripts\Test.mdb)，而且使用的是名為 Computers 和 DiskDrives 的關聯式資料表。從指令碼中也應該看得出來。
對了，另一件需要提及的是，如果您要使用 Access 2007，就必須執行一項小變更：Provider 必須從 Microsoft.Jet.OLEDB.4.0 變更為 Microsoft.ACE.OLEDB.12.0，如下所示：
objConnection.Open _
 "Provider = Microsoft.ACE.OLEDB.12.0; " & _
 "Data Source = c:\scripts\test.accdb"
就這樣。我們的重點放在如何從兩個資料表擷取資料的 SQL 查詢：
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
您覺得複雜嗎？或許有一點。讓我們一一分解其中的指令碼，使您更容易理解。
查詢的第一個部分很簡單。我們要選取兩個資料表中的所有欄位：Computers 和 DiskDrives。此舉的 SQL 查詢指令碼如下：
SELECT Computers.*, DiskDrives.*
這個部分還好；星號 (*) 代表萬用字元，亦即「所有項目」。
如果您之前有撰寫過 SQL 查詢 (或是 Windows® Management Instrumentation (WMI) 的查詢，其中使用的是 SQL 查詢語言的子集)，就應該清楚採用的慣例：指定要選取的項目之後，您需要指定要從哪裡選取項目。下一段查詢指令碼就會長這樣：
FROM Computers INNER JOIN DiskDrives ON Computers.SerialNumber = DiskDrives.SerialNumber
請不要慌張。雖然這比一般的 FROM 陳述式還要複雜一點，但這不是沒有理由的。畢竟，在一般的 SQL 查詢中，我們只會從單一資料表選取資料；而我們這次是要同時從兩個資料表選取資料。
讓我們仔細看看語法以及運作方式。如您所見，我們要指令碼從 Computers 資料表和從 DiskDrives 資料表中選取資料。請注意：我們使用的詞彙並非 "and"；而是使用 INNER JOIN。此詞彙會定義關聯性類型，而這又會描述我們要如何將兩個資料表的資訊聯結成單一資料錄集 (沒錯，其實聯結 (Join) 方式有很多種；我們稍後會討論)。
如上所述，我們需要指定資料表之間的關聯性類型；我們也需要指定資料表的關聯性。這就是下列程式碼的作用：
ON Computers.SerialNumber = DiskDrives.SerialNumber
我們現在要定義聯結資料表的方式。只要 Computers 資料表的 SerialNumber 欄位和 DiskDrives 資料表內的 SerialNumber 欄位符合，記錄就會合併。如果我們使用不同的欄位 (例如 ComputerName) 做為聯結欄位，又會如何？若是如此，程式碼就會變成如下：
ON Computers.ComputerName = DiskDrives.ComputerName
在這裡先告訴您，這兩個欄位的名稱的確不需要一樣，只需要包含相同的資料。使用相同的名稱只是要讓關聯性欄位較容易辨識。另有一項重點要請您注意：由於我們有兩個相同名稱的欄位，所以在參考其中一個欄位時，一定要使用 TableName.FieldName 的語法。所以程式碼會變成：Wscript.Echo obj- Recordset.Fields.Item("Computers.SerialNumber")。
我們所需的大概只有這樣；其他的查詢程式碼僅會將資料排序，以電腦名稱為主，再以磁碟機代號為輔：
ORDER BY ComputerName, Drive
其實沒有那麼難，對吧？現在讓我們休息片刻，討論一下聯結 (Join)。為什麼我們要在查詢中使用內部聯結 (Inner Join)？很簡單。內部聯結只會傳回各資料表中，值相符的記錄。換句話說，假設有一個項目的序號是 121989。如果該序號同時出現在 Computers 和 DiskDrives 資料表中，就會傳回相對的記錄 (當然，相符的序號不能是任何欄位中的資料，必須是 SerialNumber 欄位中的資料)。這樣清楚了吧？很好。
那麼，現在假設我們有一部電腦，序號為 121989；但是其中沒有該序號的硬碟機。在這樣的情況下，序號為 121989 的電腦就不會傳回任何資料。這是因為內部聯結僅會在各個聯結之資料表中都具有相符值時，才會傳回該記錄。
換句話說，內部聯結查詢會傳回所有具有硬碟機的電腦；但是不會傳回沒有硬碟機的電腦，或沒有安裝在電腦中的硬碟機。這樣很好，因為這通常就是我們要的結果。但是如果您想要產生一份清單，其中包含沒有硬碟機的電腦或是沒有安裝在電腦中的硬碟機，那該怎麼做？
這就是外部聯結 (Outer Join) 的用途 (喔，原來這就是外部聯結的用途！)。目前讓我們僅考慮兩種外部聯結的類型：也就是左和右。在我們的資料庫中有兩個資料表：Computers (這會被視為「左」資料表，因為它是主要資料表)，以及 DiskDrives (這會被視為「右」資料表，因為...它不是主要資料表)。假設我們希望傳回的資料錄集會包含所有的電腦，即使是沒有安裝硬碟機的電腦，在這樣的情況下，我們就可以使用 LEFT OUTER JOIN 查詢語法，如下所示：
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "LEFT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
您可能已經看出來，左外部聯結 (Left Outer Join) 會傳回左資料表中的所有記錄，即使右資料表中沒有相符的記錄。如此一來，傳回的資料中就會包含所有的電腦，但是來自右資料表 (硬碟機) 的記錄則只會包含與電腦相關聯的記錄。
相對的，如果我們希望傳回的資料錄集會包含所有的硬碟機，包括沒有安裝在電腦中的硬碟機：由於 DiskDrives 資料表是關聯性的右資料表，因此我們需要使用 RIGHT OUTER JOIN 查詢語法，如下所示：
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "RIGHT OUTER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "ORDER BY ComputerName, Drive", _
 objConnection, adOpenStatic, adLockOptimistic
讓我們比照一下此案例和真實生活的情況：如果 DiskDrives 是這個關聯性的右 (譯註：Right，與「對」同字) 資料表，那麼 Computers 就應該是「老公」資料表，而不是「左」資料表囉。這是因為多位 Scripting Guy 都曾經從痛苦的經驗中學習到：「老公」在任何關係/關聯性裡，都不會是「對 (譯註：Right，與「右」同字)」的一方。
使用右外部聯結 (Right Outer Join) 之後，傳回的會是右資料表的所有記錄 (所有的硬碟機)，但是其中僅會包含與硬碟機相關聯的電腦記錄 (左資料表中的紀錄)。
這目前可能還會有點難懂，但是只要您稍微玩一下，很快就可以抓到其中的竅門。如果您需要一個可以盡情測試的資料庫，我們有張貼一個範例資料庫可供使用，下載位置為 microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx。
在使用外部聯結時有一點很重要，就是您至少要在指令碼的第一行加入 On Error Resume Next 的指令行。為什麼呢？因為當我們執行左外部聯結查詢時，有可能會傳回沒有安裝任何硬碟機的電腦。這看起來好像沒事 (畢竟這就是我們要的資料)，直到我們碰上下列這一行程式碼，其中應該要以磁碟機代號回應：
Wscript.Echo objRecordset.Fields.Item("Drive")
由於此電腦沒有 Drive 欄位，就會導致指令碼發生錯誤而終止：
C:\Scripts\database.vbs(22, 9) Microsoft VBScript runtime error: Type mismatch
只要我們實作了 On Error Resume Next，指令碼就可以忽略沒有安裝硬碟機的電腦，順暢地繼續執行。另一個替代方案是先使用下列程式碼來檢查 Drive 欄位，然後再採取適當的動作：
If IsNull(objRecordset.Fields.Item("Drive"))_Then
    Wscript.Echo "No disk drives installed."
Else
    Wscript.Echo _
      objRecordset.Fields.Item("Drive")
End If
有了上列程式碼，我們就可以先檢查傳回的值是否為 Null，還是有傳回實際的磁碟機代號。如果是 Null，我們就以「沒有安裝硬碟機」回應。如果傳回的並非 Null 值，則我們就以 Drive 欄位的值回應。結果的輸出如 [圖 4] 所示。
Figure 4 顯示適當的結果 (Close Figure 4)
atl-ws-01
C:

atl-ws-01
D:

atl-ws-02
C:

atl-ws-02
D:

alt-ws-03
No disk drives installed.
接下來讓我們看看其她的查詢範例，並省略詳細說明。例如，以下的內部聯結查詢會傳回電腦與所安裝硬碟機的清單，只要硬碟機的大小大於 50 GB (我們假設硬碟機的大小是以 GB 為單位)：
objRecordSet.Open "SELECT Computers.*, " & _
 "DiskDrives.* FROM Computers " & _
 "INNER JOIN DiskDrives ON " & _
 "Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "WHERE DriveSize > 50 " & _
 "ORDER BY Computers.ComputerName, " & _
 "DiskDrives.Drive", objConnection, _
 adOpenStatic, adLockOptimistic
如您所見，我們僅在原始的查詢中加了一個 WHERE 子句：
WHERE DriveSize > 50
如果我們只要所有電腦的 E: 磁碟機資訊呢？沒有問題，只要加入適當的 Where 子句即可：
WHERE Drive = 'E:'
接下來是一個較複雜的查詢，這會傳回沒有安裝硬碟機的電腦集合：
objRecordSet.Open _
 "SELECT Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "FROM Computers LEFT JOIN DiskDrives " & _
 "ON Computers.SerialNumber = " & _
 "DiskDrives.SerialNumber " & _
 "GROUP BY Computers.ComputerName, " & _
 "DiskDrives.Drive " & _
 "HAVING (DiskDrives.Drive) Is Null " & _
 "ORDER BY Computers.ComputerName", _
 objConnection, adOpenStatic, adLockOptimistic
如上所述，這一個查詢比較複雜一些，但是由於空間的限制，我們將略過其運作方式的說明。最重要的是，這確實可以正常運作。
或許應該說是第二重要的吧；因為我們已經提過好幾次，最重要的是關係/關聯性。但這並不代表關係/關聯性不會出錯喔。正如伍迪．艾倫 (Woody Allen) 在「安妮霍爾」(Annie Hall) 一片中所說：「關係...就像鯊魚一樣；它必須一直向前進，否則就會滅亡。而且我認為，在我們手上的是一條已死的鯊魚。」可惜伍迪沒有機會認識內部聯結和外部聯結，因為只要掌握這些查詢技巧，關係/關聯性的建立一定可以成功！

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


 Exchange 問題與解答: 安裝、訊息日誌、儲存選項及其他主題
Exchange 問題與解答
安裝、訊息日誌、儲存選項及其他主題
KC Lemson and Nino Bilic

問：我正在執行 Exchange Server 2007 安裝程式，不知是否可以略過必要條件檢查。我不想更正必要條件檢查所指出的所有問題；我只想執行安裝程式並完成它！

答：簡短的答案為否，您不可以。如果必要條件檢查發現的問題使安裝無法繼續進行，您就必須修正必要條件檢查所指出的任何問題，否則長期而言，Exchange 可能會發生很多問題。
有些系統管理員曾嘗試編輯 ExBPA.PreReqs.xml 檔案 (這就是包含 Exchange 2007 安裝必要條件清單的檔案)，並且移除會造成封鎖安裝的檢查。然而此舉並沒有效果，因為 XML 檔案已使用數位簽章，並且對其內容所做的任何修改都會使簽章無效。
這些動作都是為了避免您建立的安裝無法正常運作。我們已在不同的環境下測試過 Exchange 2007，並且了解有一些組態和設定比其他的設定運作得更好，而有一些則可能會導致重大的問題。必要條件存在的目的，是要確定根據我們的經驗和測試，使您的安裝有最大的成功機會。
如果您發現是 Exchange 2007 必要條件檢查功能出了問題，並且在您的環境裡會封鎖安裝，就要請您向 Exchange 支援小組提出問題報告。

問：在哪裡可以找到安裝記錄檔？我在 C:磁碟機的根目錄中找不到。

答：所有安裝記錄檔現在都是儲存在 %SYSTEMDRIVE%\ExchangeSetupLogs 目錄中，在大多數安裝的情況下，此目錄就是 c:\ExchangeSetupLogs。您在那裡會找到多個檔案，其中有兩個是您想要的：
ExchangeSetup.log 這個記錄檔包含有關執行安裝時所使用之工作或參數的資訊。在設定伺服器角色時，為了設定伺服器所執行工作的相關資訊，也會記錄到此記錄檔中。此處也將是您可以查到有關您伺服器安裝之大部分資訊的地方。Service Pack 的安裝也會附加到同一個檔案。
ExchangeSetup.msilog 此檔案包含有關安裝時，進行解壓縮階段的資訊。當 Microsoft® 安裝程式將檔案從暫存位置複製到其目的地時，會記錄到此檔案中。因此，如果您的問題與複製檔案或在安裝期間存取檔案有關，那麼這個記錄檔就可能會有幫助。

問：我知道必要條件檢查是由 Exchange Server Best Practices Analyzer (BPA) 進行的，那麼我可以在哪裡找到必要條件檢查的報告？
答：如果您想要找出 BPA 在必要條件檢查時期所建立的報告，請查看以下資料夾：
%SYSTEMDRIVE%\Exchangesetuplogs\PreReqs
檔案名稱會採用標準的格式：
ExBPA.<dateandtime>.data.xml
如果您想要知道某特定必要條件檢查是在尋找什麼，請找到包含您所看見錯誤訊息的 XML 檔案，在該訊息的上方，您就會看到所測試的規則定義。
問：我該如何閱讀安裝記錄？我有哪些選項？
答：通常有兩種方式可以閱讀安裝記錄。您可以在 Exchange 管理介面中執行 Get-SetupLog，或者您可以直接在 [記事本] 或您偏好的文字編輯器中開啟安裝記錄檔。
如果您使用了 Get-SetupLog，以下就是如何挑出任何警告或錯誤的範例：
Get-SetupLog c:\exchangesetuplogs\exchangesetup.log –error
如果您想要使其更方便查看，就應該取得 Out-HTML.ps1 和 Out-IE.ps1 指令碼，這些指令碼提供於 Exchange 2007 PowerShell Scriptacular 示範套件中 (如需詳細資訊，請參考我們的部落格，網址為 msexchangeteam.com/archive/2006/12/27/431998.aspx)。
您取得這些指令碼之後，請將其放入 Exchange 指令碼的資料夾 (根據預設是 c:\program files\microsoft\exchange server\scripts)，然後執行下列指令：
Get-SetupLog –tree:$false –error:$false | Where { $_.status –eq "Error" } | select datetime, depth, description, status | Out-HTML | Out-IE
此舉會開啟易於導覽的瀏覽器視窗，其中會以 HTML 檢視模式顯示在安裝期間可能發生的錯誤 (請參閱 [圖 1])。
圖 1 Out-HTML 和 Out-IE 使安裝記錄的檢視更易於閱讀
圖 1 Out-HTML 和 Out-IE 使安裝記錄的檢視更易於閱讀
反之，如果您選擇使用 [記事本] 來檢視 exchangesetup.log，以下有一些提示：
  • 若要尋找安裝過程的開始處，請搜尋：[0] Starting Microsoft Exchange 2007 Setup。
  • 若要尋找安裝過程的結尾處，請搜尋：[0] End of Setup。
  • 主要的安裝工作會以下列符號分隔：[0] **************。
  • 若要尋找執行安裝的帳戶，請搜尋：[0] Logged on user。
  • 如果您想要查看在安裝期間使用哪一個網域控制器，請搜尋：[0] Setup will use the domain controller。
一般來說，在使用 [記事本] 檢閱安裝記錄時，您應該從檔案的結尾開始，再回溯到前面，來查看發生了什麼問題。錯誤經常會記載在記錄檔的最後面。

問：我可以使用 Exchange 2007 Unified Messaging 搭配我的 PBX 嗎？

答：可能可以。請參考 microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx，以取得支援的 VoIP 閘道和 PBX 的清單。對支援產品的任何變更都會加入此網頁。
問：我有一個同時執行 Small Business Server 2003 和 Exchange 的用戶端，且公司的原則要求所有郵件都要加以監控。為了執行監控，我想要傳送一份所有送入和送出郵件的複本，到系統管理者的帳戶。我該如何完成這項工作？
答：您需要的是訊息日誌的功能，它可以讓您在另一個日誌信箱中，保存一份送至或來自某特定信箱資料庫之所有訊息的複本。其中提供多種選項，可供您設定日誌複本的詳細度 (例如，您是否要擷取 BCC 收件者？)，您還可以下載另一項工具：go.microsoft.com/fwlink/?LinkId=93725，以獲得進階的功能。Exchange 2003 中的日誌功能是針對每個資料庫層級分別啟用的，因此該資料庫中的每位使用者都會記載到日誌中。建立了信箱以存放日誌的訊息之後，請在 Exchange 系統管理員的信箱儲存區屬性中，核取相對的核取方塊，表示要針對該儲存區之所有信箱所送出或接收的訊息進行封存。依據您的業務原則而定，您可能也要啟用信箱管理員自動從日誌信箱中清除舊日誌複本的功能。
Exchange 2003 具有另一項與日誌十分類似的功能，稱為封存接收器。與日誌不同的地方在於，這會將訊息的複本儲存到 Exchange 的另一個信箱中，而封存則會將訊息存放至伺服器硬碟上的指定資料夾中。如何在這兩種方法之間進行選擇？日誌通常用於符合相關法規，但是如果您想要擷取來自或送出到網際網路的所有訊息，封存接收器就很好用。
Exchange 2007 明顯簡化了這些情況，而且您可以輕易地針對每一位使用者或每一個通訊群組清單 (DL) 記載日誌。如果您不希望使用者知道其郵件已記載到日誌中，就可以在全域通訊清單中將該 DL (請注意，這與 DL 的隱藏成員資格並不一樣) 隱藏起來，或是對使用者設置自訂的屬性，然後建立查詢式通訊群組 (亦稱為動態通訊群組清單，或 DDL)，來選取具自訂屬性的所有使用者。如果您想要將整個企業的所有郵件日誌都記載到同一個位置，請在建立日誌規則時，將收件者欄位維持空白。另請注意，在 Exchange 2007 中，如果您想要使用非資料庫的日誌功能，則您需要有該些使用者的 Enterprise 用戶端存取授權 (CAL)。您可以在 microsoft.com/exchange/howtobuy/licensingFAQ.mspx 取得更多的資訊。如果您不想要 CAL 或其他的任何功能，則可以繼續使用 Exchange 2003 中以資料庫記載日誌的功能。最後，請參閱 2006 年 12 月號的 TechNet Magazine，由 David Strome 所著，標題為《Exchange 2007 更強大的日誌功能》的文章，網址為 technetmagazine.com/issues/2006/12/journaling。

問：我的所有使用者都是執行 Microsoft Office 2003，而且我們一直要到 2008 年硬體更新時，才要移轉到 2007 Office System。從我目前閱讀過的資訊看來，恐怕我們會因為這個原因而未能擁有一些功能。請問他們目前能夠使用 Unified Messaging 嗎？

答：當然。在 Office 2003 中，已啟用 Unified Messaging 的使用者在其信箱中可以接收語音信箱訊息和傳真，並且可以透過任何電話來存取其信箱。如果您未升級到 Outlook 2007，無法使用的 Unified Messaging 功能包括透過 Outlook 的 [選項] 索引標籤設定語音信箱的功能，以及特殊的自訂表單 (它會顯示在 Outlook 中的語音信箱訊息上，讓您能夠播放訊息，而不必啟動另一個媒體播放機)。除此之外，讓您撰寫語音記事，並儲存在語音信箱訊息中的功能也將無法使用。但是即使沒有 Outlook 2007，已啟用 Unified Messaging 的使用者仍然可以使用 OWA 2007，來存取 Unified Messaging 的設定 (在 OWA 選項的頁面上)，以及在 OWA 中使用語音信箱的自訂表單。

問：我的公司已經有存放區域網路 (Storage Area Network，SAN)，而且我希望與 Exchange 2007 連結。但是我已聽過很多有關直接連接儲存裝置 (Direct Attached Storage，DAS) 的資訊，讓我懷疑是否應該選用該選項。您認為如何？

答：這個問題沒有對或錯的答案；而是需要取決於貴公司的原則和使用情況 (尤其是如果您已經有 SAN)。如果您正在考慮要購買新的 SAN、增加另一個，或者正在考慮要進行升級，則我們強烈建議您考慮使用 DAS。以下是可供您參考的一些資訊：直到 2007 年六月，Microsoft IT 已部署了 17 套 Exchange 2007 信箱伺服器，總計 40,000 個信箱 (其中配額範圍從 500MB 到 10GB 不等)，全部都使用叢集連續複寫 (Cluster Continuous Replication，CCR) 以及 DAS。在九月之前，我們計劃會有 35 套 Exchange 2007 信箱伺服器，總計 152,500 個信箱，全部都是在 DAS 上。因此如果您正在懷疑 DAS 是否適合企業級的應用，答案是絕對適用。DAS 已經讓 Microsoft IT 得以有效增加使用者的配額，但同時減少整體儲存成本。有關此拓撲與部署過程，以及可節省之成本的相關資訊，請造訪 microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx。
雖然一開始的時候，將所有伺服器連結到同一個 SAN，看起來似乎可節省大量的儲存體，但是這樣會有風險。例如，經常發生的一個問題，是與連結到 SAN 之軟體的不同使用情況有關。例如，如果您在 SAN 上有 HR 應用程式，它會在每天傍晚 5:00 PM 執行批次程序，此時，I/O 的劇增可能會嚴重影響 Exchange 的使用者。對共用的 SAN 部署來說，缺乏確定性的 I/O 是一項常見的問題。
DAS 所提供的另一項優點，是它比較容易管理，因為它並不需要專門的儲存體管理人員或特殊的設備。它可以逐步增加，並且容易購買，爾後還能陸續擴充。此外，它通常比較便宜，因此如果您希望手邊有備品可用，也並不會造成太高的成本負荷。

問：我已安裝了第一套 Exchange 2007 伺服器。現在當我嘗試使用 Outlook 2003 連接時，會得到一項錯誤訊息，表示管理員已封鎖我的 Outlook 版本 (「Microsoft Exchange 管理員已經封鎖您所使用的 Outlook 版本。請連絡管理員以取得協助。」)但我就是系統管理員，並且我絕對沒有封鎖它。請問這是為什麼？

答：這種行為並未出乎預料。在安裝 Exchange 2007 的時候，安裝精靈會詢問在您的企業裡，是否有執行任何 Outlook 2003 (含) 以前的版本，或是 Entourage 用戶端 (請參閱 [圖 2])。如果您對這個問題回答「否」，就可能會發生這個情況。
圖 2 Exchange 2007 安裝程式詢問關於舊版用戶端的問題
圖 2 Exchange 2007 安裝程式詢問關於舊版用戶端的問題
若要在事後 (在安裝完成之後) 解決這個問題，您只要使用 Exchange 管理主控台或 Exchange 管理命令介面，建立一個公用資料夾儲存區，然後重新啟動資訊儲存庫 (Information Store) 服務即可。在這種情況下，重新啟動資訊儲存庫服務是一定要的，並且舊版的用戶端 (Outlook 2003 及更早的版本) 一直要到重新啟動此服務之後，才能夠連接到伺服器。
除此之外，如果您執行的是自動安裝的 Exchange 2007，就可以使用 /EnableLegacyOutlook 選項，來指定您希望如何回答有關舊版用戶端的問題。

問：為什麼 Exchange 2007 在乎我是否使用舊版的 Outlook 來連接到伺服器？為什麼建立公用資料夾儲存區，並且重新啟動資訊儲存庫服務即可解決這個問題？

答：這些問題的答案在於公用資料夾儲存區的存在。如果您回想一下，在先前的 Exchange 版本中，公用資料夾儲存區是用來儲存使用者的空閒/忙碌資料，以及其他資訊。當舊版 Outlook 的使用者使用 MAPI 或 RPC over HTTP 連接到其 Exchange 伺服器，並且發佈一些資訊到其行事曆上時，有關其空閒/忙碌狀態的資訊也會發佈到伺服器，放入稱為 Schedule+ 資料夾的特殊公用資料夾中。這是唯一可供舊版 Outlook 用戶端發佈使用者空閒/忙碌資料至伺服器的方式，而且也是舊版 Outlook 可讀取其他使用者空閒/忙碌資訊的唯一方式。
Exchange 2007 知道這件事。這就是為什麼如果沒有公用資料夾儲存區，Exchange 2007 就會封鎖較早版本的用戶端。如果 Exchange 2007 允許舊版用戶端的連線，用戶端就會碰到經常發生的錯誤，因為 Outlook 將無法連接到公用資料夾儲存區，來發佈空閒/忙碌資料，並且用戶端的功能也會受到限制，因為使用者想要執行的空閒/忙碌查閱功能 (例如在嘗試安排與某人開會的時程時) 根本不能運作。這也是為什麼建立公用資料夾儲存區能夠解決問題，因為 Exchange 2007 伺服器就會知道舊版用戶端能夠使用空閒/忙碌的發佈功能，因而允許執行信箱的登入。
從全部這些說明中，您應該可以歸納出一件事情：Outlook 2007 用戶端不需要公用資料夾儲存區，來發佈其空閒/忙碌資訊。這是事實，但是有一個但書。
讓我們不要涉入太深，只要表明：如果有公用資料夾儲存區存在於 Exchange 2007 伺服器上，即使是 Outlook 2007 用戶端，也會將使用者的空閒/忙碌資料發佈至其中。做這件事情的理由是：如此一來，其他的用戶端 (其中一部分大概是舊版的 Outlook 用戶端) 才都可以查閱 Outlook 2007 使用者的空閒/忙碌資訊；如果此項資訊不在公用資料夾儲存區中，舊版用戶端就看不到 Outlook 2007 使用者的資訊，因為沒有任何用戶端曾經將資訊填入公用資料夾儲存區中。然而，如果公用資料夾儲存區不存在，Outlook 2007 用戶端就不會嘗試發佈空閒/忙碌資料。如果沒有公用儲存區，並且所有用戶端都至少是 Outlook 2007，就會使用另一種空閒/忙碌資訊查閱機制，其中行事曆資料會直接從使用者的信箱中讀出，而不必在其他任何地方建立此項資訊的複本。如果您希望閱讀更多相關的資訊，請查閱伺服器說明檔中有關可用性服務的資訊，或是查閱位於 go.microsoft.com/fwlink/?LinkId=69434 的 Exchange 線上文件。

問：我剛閱讀過知識庫文件 288894，其中討論了關於使用登錄機碼來封鎖 MAPI 用戶端 (請參閱 support.microsoft.com/kb/288894)。我檢查了我伺服器的登錄，但是此機碼尚未設定。請問儲存區是如何執行舊版用戶端的版本封鎖呢？

答：這是一個非常好的問題！事實上 Exchange 2007 資訊儲存庫並不使用該知識庫文件中所提到的「停用 MAPI 用戶端」登錄值，來封鎖舊版的用戶端。這樣做是因為公用資料夾儲存區有可能根本不存在，所以如果沒有任何公用資料夾儲存區，修改該登錄機碼就不可能取消封鎖這些用戶端。
封鎖比 Outlook 2007 更早版本的用戶端之行為，已透過硬式編寫的方式寫入 Exchange 2007 的資訊儲存庫中。在服務啟動時，儲存區會檢查是否有公用資料夾儲存區，然後決定是否只允許 Outlook 2007 進行連接，或者舊版的用戶端也能夠連接至其信箱。此項檢查只會在服務啟動時發生。這就是為什麼您在建立了公用資料夾儲存區之後，必須重新啟動資訊儲存庫服務，變更才會發生作用的原因。

KC Lemson 是 Exchange Server 使用者經驗的專案經理。她目前正在一所極具聲望但未向教育部登記的大學攻讀博士學位。
Nino Bilic 是 Exchange Server 支援計劃的經理。他正考慮成為 Forza Motorsports 2 中的專業賽車手。


 安全性監控: 使用者帳戶控制的長期影響
安全性監控
使用者帳戶控制的長期影響
Dr. Jesper M. Johansson

以系統管理員身分執行有明顯的問題存在：任何攻擊使用者的惡意程式或其執行的應用程式，只要遭受感染，就能夠擁有超過 90% 的電腦控制權。Windows Vista 中的使用者帳戶控制 (UAC) 功能，是 Microsoft 對於普遍安全性挑戰的解決方案，該挑戰是指
目前在 Windows 平台上，有 90% 的使用者是以系統管理權限來執行。雖然可以標準使用者身分在 Windows® XP 上執行，而且我也這麼做過，但卻非常麻煩。比方說，如果您使用 Windows XP 且經常旅行，會發現若以標準使用者身分，您將無法在系統上修改時區。
UAC 應該是可以改善這一切的功能。實際上，這是第一個錯誤的觀念。UAC 不只是一項功能而已；它是功能的集合，而大部分功能並不明顯。我並沒有要深入分析 UAC 的所有實作細節。對此，我強烈建議您閱讀 Mark Russinovich 在 TechNet Magazine 的 2007 年 6 月號所寫的一篇文章，您可以透過線上存取：technetmagazine.com/issues/2007/06/UAC。
而在本文中，我希望公正地定義什麼是 UAC、什麼不是 UAC，以及它對於您管理執行 Windows Vista® 系統的方式有何影響。

UAC 的外觀
UAC 最明顯的特色是它的提高權限對話方塊，如 [圖 1] 所示。事實上，如果您向 Windows Vista 使用者詢問什麼是 UAC，大部分人的回答會是：那個令人討厭的提高權限對話方塊。
圖 1 在管理員核准模式中的系統管理員 UAC 核准對話方塊
圖 1 在管理員核准模式中的系統管理員 UAC 核准對話方塊
雖然 UAC 有很高的曝光率以及探討，我認為大部分關於 UAC 的探討與 UAC 的真正原貌沒有太大關係。事實上，似乎還有一些混淆不清。有一些自稱權威的人士在部落格文章、新聞群組項目和各種文章中，發表了如「Vista 最惱人的功能」等類標題的內容，他們武斷地認為有很多人都會關閉這項功能，並說明它為何會造成困擾。
既然瞭解 UAC 背後原理的人這麼少，不如我在本專欄一開頭就先探討什麼是 UAC？

什麼是 UAC
UAC 是要嘗試讓更多人以標準使用者身分執行電腦。其實它算是 2.0 版了。1.0 版是在 Windows NT® 3.1 提供的，其中可讓使用者以非系統管理員身分執行。這與 16 位元 Windows 3.1 及其後續版本 Windows 3.11、Windows 95、Windows 98 和 Windows Me 之間有很大的改變，它們當中沒有任何一個版本具有低權限使用者的概念。非系統管理員到底能不能執行有用的工作取決於許多因素，但是到 Windows XP 和 Windows Server® 2003 為止，最低使用者權限通常代表著麻煩及毫無用處。Windows Vista 實現了第一套完整的技術組合，旨在使互動式使用者權限能夠正確地使用與執行工作。
雖然可以說 UAC 的目標，是要隔離以系統管理員身分執行的應用程式以及並非以系統管理員身分執行的應用程式，以提供某種程度的保護，但那絕對不是 UAC 的主要用途。其主要用途是要開始讓更多使用者以標準使用者身分執行，以強迫開發人員撰寫更多以標準使用者身分執行的程式，因而減少使用者需要提高權限的情況。開發人員撰寫越多符合 UAC 的應用程式，使用者得到的提示數目就越少，使用者經驗也越佳。在此過程中，最理想的狀況是大部分使用者都不以系統管理員身分執行，並希望他們對於所看到的一些提高權限提示開始抱持懷疑的態度。提示越少，使用者越能夠在接受它們之前審慎考慮。
至少理論上是如此。在引伸意義上，雖然惡意程式可能可以減少，但這要看使用者是否持續啟用 UAC，而這又取決於開發人員是否撰寫相容的軟體，以及使用者是否不再輕視這些提示 (僅快速點選帶過)，而認真考慮提高權限的要求是否可信且必要。
為了增加在大部分時間都以非系統管理員身分執行的使用者數目的目標，UAC 的設計納入了下列子目標：
  1. 減少需要提高至管理帳戶的案例數。
  2. 使提高權限大為簡化，最好是自動化，比使用 runas.exe 或登出某帳戶後再登入另一帳戶這類舊把戲更簡單。換句話說，要消除差距，直到獨立軟體供應商 (ISV) 修正其應用程式為止。
  3. 為以系統管理員身分執行的應用程式提供某種隔離措施，來保護以非系統管理員身分執行的應用程式。
  4. 儘可能讓公開的應用程式可以用更低的權限去執行。
在上述目標當中，有兩個是要讓以非系統管理員身分執行的使用者經驗盡量美好。有兩個則是要保護公開的應用程式。
有趣的是，其中只有兩個與一般對於 UAC 的認知有關，而且只有一個實際涉及提高權限的工作。然而，當應用程式要求更多權限時，最為人詬病的是提高權限，因為它是構成 UAC 的技術集合當中，唯一使用者看得到的部分。第一個大目標與提高權限一點關係也沒有。其構想只是希望在大部分時間讓更多人以非系統管理員身分執行。事實上，您可以說，其用意是要減少提高權限事件的次數。
與提高權限工作本身有關的目標是 2 和 3。目標 2 是要使提高權限的工作比在 Windows XP 中更簡單，目標 3 是要為以提高的權限執行的應用程式提供某種程度的保護。其餘目標則與完全不同的議題有關。不過，這些目標都需要變更作業系統。若您有興趣知道仔細內容，先前提及的 Mark Russinovich 文章中有詳述這些變更。
一如前述，有許多人建議停用 UAC。可能有許多人根本不會給此功能機會就將其停用，也有更多人會在向大型商家購得其電腦時，發現已安裝的 Windows Vista 版本已經停用 UAC。我認為零售商在預設部署映像中，為作業系統停用重要的安全功能，實在很不應該。
遺憾的是，很多關閉 UAC 的建議都是憑藉初次經驗而已。在安裝電腦時，當您安裝軟體及做任何必要變更時，會看到很多提示。電腦進入穩定狀態下之後，就不會像在設定電腦時需要處理眾多提示。前幾星期與後幾星期將大不相同。如果您在一個處於穩定狀態的電腦上試用 UAC，我想您會發現它一點也不麻煩。

什麼不是 UAC
UAC 並非刻意設計成 Windows 有史以來最麻煩的功能。相反地，這一套技術的設計是要讓使用者不再像過去幾年來，經常使其系統曝露在惡意程式碼的威脅之下。
以目前的 UAC 形式而言，它並無法阻止真正厲害的攻擊者，或有人協助的攻擊者。如果壞人想不到可擊敗 UAC 的方法，他們的最後手段當然就會引誘使用者為他們代勞。假設可以選擇勁舞豬和安全性，從經驗判斷，每次獲勝的一定是勁舞豬。使用者已知道如何不理會對話方塊，因此在我們能夠成功重新教育他們之前，使用者都會這麼做。造成此現象的原因有許多，包括軟體有太多警告對話方塊、其中的訊息毫無意義，以及使用者所購買的裝置所附的手冊都會包含這樣的附註：請按一下 [是]，關閉安全性警告對話方塊。
UAC 無法提供絕對的安全性。事實上，它再度使舊式本機權限提高攻擊變得有趣。這種攻擊以往很不受重視，因為在 Windows 上，幾乎每個人都是系統管理員，因此提高權限至其他系統管理員毫無意義。換句話說，UAC 的確改變了這類攻擊的本質，並將遊戲規則轉變成比較像已在 UNIX 上流行超過 20 年的規則。
UAC 無法阻止壞人竊取您的個人資料。不管使用者的執行權限為何，使用者的個人資料都可以讓該使用者存取。因此，包括惡意程式在內的應用程式，都可以存取此資料。UAC 不會，也無法改變這一點。使用者還是需要警愓、存疑及擇善固執，這是我們有機會就應該對使用者灌輸的觀念。
UAC 不是設計來保護以提高權限執行的應用程式，使其不會遭受在相同登入工作階段中以正常權限執行的應用程式的所有攻擊。雖然 UAC 的確提供了一些薄弱的程序隔離功能，但是讓各個應用程式在個別的沙箱中執行作業，絕對不是 UAC 當初的設計目標。

謠言
關於 UAC 的謠言及其用途的誤解，Microsoft 本身難辭其咎。例如，在《Windows Vista 安全性指南》中，＜防範惡意程式＞一章將 UAC 列為防範惡意程的主要技術 (文章位於：microsoft.com/technet/windowsvista/security/guide.mspx)。它建議在大部分情況下執行時要開啟 UAC，並列出使用 UAC 對抗惡意程式時要考量的一些要點。不過，其中卻明顯漏掉這一點：UAC 並不會 (也不是用來) 阻止惡意程式。
目前全球對 Windows 安全性最了解的一些專家 (例如 Joanna Rutkowska)，才真正了解 UAC 的用途。正如她在 2007 年 2 月 4 日在一篇部落格文章中所陳述的，UAC「是 Vista 推出的一個新安全機制，其主要目標在於強迫使用者使用受限的帳戶工作，而不以系統管理員身分工作」(theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html)。她說的大部分都沒錯，不過我覺得應該使用「鼓勵」而非「強迫」一詞。
不過，這表示對 Windows 常見攻擊的本質會有重大改變。正如我在本專欄前面提到的，提高本機權限的安全性風險，是使用者可以從本機標準使用者提高至本機系統管理員，這在 Windows 平台上一向不受到重視。
在 Windows Vista 中，其構想是希望使用者以標準使用者身分執行，因此，提高本機權限的問題突然又變得非常值得探討。只可惜，我們仍然受到 UAC 的一些限制。記住，沒有有效的隔離；沒有任何安全界限能夠在同一部桌上型電腦上隔離程序。雖然作業系統確實有包含一些保護措施來阻擋一些明顯而非必要的通訊管道，但要完全阻擋它們是不可能的，而且也不恰當。因此，Microsoft 不把不存在的安全界限視為安全性漏洞。Mark Russinovich 在 blogs.technet.com/markrussinovich/archive/2007/02/12/638372.aspx 的一篇部落格文章中，對此有討論類似的議題。
Mark 的看法完全正確。在同一部桌上型電腦上，低權限程序和提高權限的程序之間並沒有安全界限，Microsoft 非常了解這個事實。由於同一部桌上型電腦上的程序之間本來就沒有隔離，因此，當發現同一部桌上型電腦上的程序之間沒有隔離時，並不能稱之為安全性弱點。顯然，這削弱了 UAC 對抗惡意程式之首席機制的價值，但原先的設計並非如此 (雖然您可能在許多文章中讀到這一點，其中也包括來自 Microsoft 的一些文章)。
此一事實是否削弱 UAC 在其主要目標上的價值，亦即希望更多人在更多時候以標準使用者身分執行？不會。惡意的低權限應用程式與提高權限的應用程式之間，不管有沒有無法滲透的安全界限，都不會改變更多使用者能夠有效使用 UAC 並以標準使用者身分執行其 Windows Vista 電腦的優點。事實上，與業界所相信的一些說法剛好相反，我是以 Windows Vista 的標準使用者身分撰寫本文 (以及我所寫的關於 Windows Vista 安全性的整本書)，而且在整個過程中，我都沒有看到任何 UAC 提示！
雖然 UAC 並不能減輕所有的安全性問題，也未擁有許多人 (包括我自己在內) 非常想要的功能 (亦即可對抗惡意程式的首席保護機制)，但這不表示它不是一項安全性技術。能夠透過個別使用者帳戶識別使用者的能力，不能獨力阻止惡意程式感染您的系統，但沒有人會因而將此事實引伸為使用者帳戶不是一項安全技術。UAC 不能解決我們希望它解決的所有問題，不表示它解決的問題不重要。
UAC 會交由一些技術 (如大幅改進的 Windows Firewall、Windows Defender 和其他反惡意程式) 來防範惡意程式碼，以及在惡意程式碼 (不論是由於狡猾的程式設計或是以飛行豬的技巧) 不幸入侵時無法執行。這些安全性技術沒有一項能夠 100% 完成其任務，然而它們全都是重要的安全性技術，各佔有一席之地。但誠如我之前多次提到的，即使所有攻擊途徑都關閉了，最後它也會把腦筋動到使用者身上。如果使用鍵盤的人選擇讓惡意程式碼執行，全世界沒有一項緩兵之計能幫得了忙。

最佳作法
您應該如何使用 UAC？是否應該在管理員核准模式下，以系統管理員身分執行？我曾多次提到，UAC 不能防止從較低權限的應用程式，將程式碼插入到同一部桌上型電腦上更高權限的應用程式中。這表示，不論是在管理員核准模式下，或是以標準使用者身分執行然後在工作階段中提高權限 (潛在提高權限) 都無法提供有效的隔離。不過，不論哪一種方式，都比在 Windows XP 之下以系統管理員身分執行或在 Windows Vista 中關閉 UAC 更好。畢竟，惡意程式仍有可能在互動式桌面上利用提高權限的應用程式使壞。
您所決定的執行方式，將取決於風險管理方法。當您以標準使用者身分執行然後使用潛在提高權限來提升應用程式之後，提高權限的應用程式與一般應用程式會有不同的使用者環境。這可減少污染攻擊的風險，避免惡意的未提高權限應用程式污染有提高權限的應用程式的使用者環境，但它不一定能夠移除未提高權限應用程式控制已提高權限應用程式的能力。數個星期以前執行的惡意應用程式雖無法輕易污染您今天執行的已提高權限應用程式，但現在執行的惡意應用程式卻可控制已提高權限的應用程式。因此，您必須從使用的簡便性和風險的平衡點來決定執行方式，無論是使用管理員核准模式或是潛在提高權限的方式。
這樣可造就 UAC 的一套最佳作法，如 [圖 2] 的總結。就我的看法，目前的最佳選項是最複雜的。不過，對於真正擇善固執或希望避開風險的使用者而言，最佳選項是以標準使用者身分執行，且絕不要提高權限。在 Windows XP 之下以系統管理員身分執行的話，可以說一旦您執行了惡意程式碼，一切就完了。在 Windows Vista 之下，如果您執行惡意程式碼，然後在該工作階段內提高權限，也可能會完蛋。您可以自由挑選最適合您，且可讓您較為安心的執行方法。
Figure 2 帳戶提高權限的最佳作法 (Close Figure 2)

保護層次 | 提高權限方法
最差 | 關閉 UAC。
差 | 自動提高至系統管理員。
佳 | 在管理員核准模式下執行。
較佳 | 以標準使用者身分執行，並提高權限至另一個管理帳戶。
最佳 | 以標準使用者身分執行，並將使用者切換至另一個管理帳戶而不是使用 UAC 來提高權限。
此外，真正擇善固執的人不會信任廠商所說「應用程式必須以系統管理員身分執行」之類的話！做此不實陳述的其中一個最明顯範例就是 Visual Studio® 2005 Service Pack 1。當您啟動 Visual Studio 時，它會告訴您應該以系統管理員身分執行。然而，這樣的陳述只適合需要執行特定工作的開發人員。如需詳細資訊，請參閱 msdn2.microsoft.com/en-us/vstudio/aa972193.aspx。

授權使用者
使用者應該獲得授權，以做出更多更好的決策。有一名安全性專業人士，他認為安全性決策不應該讓使用者知道。其暗示的理由是，使用者不僅對安全性不感興趣，而且也不夠聰明，不會知道該如何做適當處理。他們唯有仰賴 Insert-YourFavoriteAntiTechnologyHere 才能受到適當保護。
我不認為技術能夠保護人們免於遭受以人為目標的攻擊。今天大部分的攻擊事件 (包括幾乎所有網路釣魚攻擊在內)，主要都是鎖定人及其執行電腦的方式為目標，而非電腦內的技術。這些攻擊當中最有效的是混合對人的攻擊與對技術的攻擊，但它們仍然需要與使用者互動才能執行。我們不能期望技術能夠防範不以技術為目標的攻擊。不久前我寫過一些關於此主題的文章：technetmagazine.com/issues/2006/07/SecurityWatch。
UAC 已強迫使用者做出安全性決策，但是技術廠商已承諾要防止使用者做出決策的解決方案。使用者都不太想理會安全性的問題，這是事實。不過，沒有軟體能夠洞悉其他軟體的意圖，這也是事實。沒有一個防範入侵系統可得知網站在詢問您的信用卡號碼，是為了要傳送一份 Windows Vista Security 給您，還是要把資料交給犯罪組織。唯有使用者可以做這樣的判斷，而且也要有適當的資訊。身為軟體工程師，我們需要讓使用者習慣於做安全性決策、教導他們如何做，並提供他們做出安全決策所需的資訊。
如果我們堅持目前的做法，試圖防止使用者做出安全性決策，就會發現我們根本無法保護他們。使用者最後會對遭到駭客入侵，且隱私權、銀行帳戶、身分、地位和自尊遭到冒犯感到厭煩。當發生此情形時，他們將會停止使用我們需要他們購買才能使產業維持下去的產品。在高科技產業中，有人認為如果我們不願意面對電腦有安全性問題的事實，而將一切資料都電子化，則使用者將盲目地使用我們提供給他們的一切。目前就是如此。當使用者最後了解到我們並未對他們開誠佈公時，會對我們的產品完全失去信心和信任，而背離它們，造成我們隱瞞事實而試圖保護的產業全盤瓦解。
UAC 是授權使用者負責其系統安全性的一大步。它絕非完整的安全性解決方案，但卻是第一次嘗試幫助使用者以最低權限執行，這絕對是正確的方向。

Dr. Jesper M. Johansson 是負責軟體安全性問題的首席安全性工程師，也是 TechNet Magazine 的特約編輯之一。Jesper 擁有 MIS 博士學位，在電腦安全性領域有 20 年以上的經驗。


 桌面檔案: 使用 Windows PE 進行 PC 修復
桌面檔案
使用 Windows PE 進行 PC 修復
Wes Miller

我之前在專欄中曾說過，起初我們只將 Windows PE 視為部署環境的工具。如同所有優良產品一樣，Windows PE 的功能已演進，不再侷限於此。客戶 (最初是 OEM) 想要建置一個用於製造及使用者自行修復的解決方案，因此多家公司生產了
Windows® PE 的解決方案，來滿足這兩個需求。
今日大部分修復工具的基礎，都是透過運用部署程序來將系統復原成先前的良好狀態。Windows Vista® 比 Windows XP 更能簡化復原程序，並內建影像支援 (請參閱本期 TechNet Magazine 中，Christine Fok 所撰寫關於 Windows Vista 備份技術的文章)。
在本月專欄中，我將說明如何在 Windows PE 上建置自己的修復解決方案。Windows PE 2.0 是 Windows 自動化安裝套件 (AIK) 的免費元件，適用於所有 Windows 授權使用者。此授權不僅適用於部署，也適用於使用 Windows PE 進行修復和疑難排解。
當然，您還必須考量自己的自訂與調整需求，但我會在本文中探討無論是部署 Windows XP 或 Windows Vista 都需要注意的通則。如果您熟悉影像處理，您大概已經曉得大部分的通則。
所有 Windows PE 修復解決方案都包括以下主要元件：
  • Windows PE
  • 影像公用程式
  • 相關的指令碼 (或正式的應用程式)
您可以選擇是否要包含 SQL 支援與 Active Directory® 服務介面 (ADSI) 支援。透過 SQL 連線，您可以用間接方式建置解決方案，讓系統包含各種「用料表」來定義安裝所需的項目。同樣地，連線到 Active Directory 對於處理每部電腦的帳戶物件 (MAO) 屬性也很方便。
要注意的是，Microsoft 不支援在 Windows PE 中包含 ADSI，但是好幾篇線上文件都有說明怎麼做，而且只要步驟正確，效果很不錯。如果您不想要這麼做，可以僅加入 SQL 支援，並在其中建置 Windows PE 修復工具的工作流程。如需 ADSI 屬性，您可以讓包含排程工作的伺服器系統查詢相同的 SQL Server™，然後透過 ADSI 查詢 Active Directory -- 本質上是以通過 (Pass-Through) 的方式運作。
這個解決方案不甚完美，而且需要一些指令碼或其他自動化作業來補強，但是這項設定可讓您從 Windows PE 進行與 Active Directory 的互動。
請注意，您也可以使用 LDIFDE 公用程式，從 Windows PE 內部讀取 Active Directory 資訊 (如需詳細資訊，請參閱此主題的知識庫文章，網址是：support.microsoft.com/kb/237677)。例如，您可以使用下列命令：
ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"
輸入此命令將會從指定的電腦物件擷取屬性到 x:\output.ldf，並在此剖析輸出。

SKU、位元及語言
您必須考慮您要部署的 Windows 的版本、架構及語言。在特定區域的小型組織中，您可能只會部署一個作業系統 (Windows XP 或 Windows Vista)，或是使用已經預先安裝在新電腦上的作業系統。即使有的話，您也可能還不會部署很多 x64 Windows 系統。而且您很可能只需要支援一種語言。但是當您的組織越大越全球化，可能就會涉及更多架構、版本和設定。
我在之前的專欄中曾經提到，在相同的 Windows Imaging Format (WIM) 檔案中可以儲存 x64 和 x86 磁碟區影像，但是這無法節省空間。若您要建置修復解決方案，而且必須兼顧這兩種架構，那麼您應該分別在不同的 WIM 中儲存各個解決方案。同樣地，若您要同時部署和支援 Windows XP 與 Windows Vista，在同一個影像中儲存這兩者也無法節省空間。只有當您在這兩種部署中包含相同應用程式 (例如，2007 Microsoft® Office System) 的許多執行個體時，才會出現節省空間的情況。此時，該應用程式檔案無須儲存多次，但是即使如此，也不太可能省下太多空間。
Windows PE 開機方法
Windows PE 1.6
從遠端安裝服務 (RIS)
進行 PXE 開機 (無 RAMDisk)
硬碟機
USB 快閃磁碟機
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB 快閃磁碟機
RAMDisk 硬碟機

Windows PE 2.0
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB 快閃磁碟機
RAMDisk 硬碟機

從 RIS 進行 PXE 開機 在您需要 PXE 的情況下是最理想的選擇，但是比起 PXE RAMDisk，這種方法需要比較長的開機時間，而且耗用比較多的網路資源，因此不太划算。
硬碟機 使用最少記憶體但會鎖定磁碟機。如果您是使用雙磁碟分割進行對拷修復方案，這個方法就很適合。
USB 快閃磁碟機 讓開機程序更方便；但是如果開機系統尚未經過 OEM 驗證為 UFD 可開機，而且沒有 Windows Vista Capable 標誌 (標誌會確認系統支援 UFD 開機)，UFD (在 RAMDisk 與非 RAMDisk 方案中) 便會雜亂無章。UFD 開機需要高效能 (讀取與寫入速度都很快) 的快閃磁碟機，以及 USB 控制器和 BIOS 的高速 USB 支援。
RAMDisk 開機 (在所有類型中) 需要更多記憶體，不過可以發揮最佳效能，並將 Windows PE 放入 RAMDisk 記憶體中以擺脫它的干擾。一般來說，Windows PE 1.6 的 RAMDisk 開機應該只用於至少具備 256MB RAM 的系統上。一般而言，Windows PE 2.0 (一定是 RAMDisk WIM 開機) 只應該在至少具備 384MB RAM 的系統上執行。

不過請注意，當您在相同的 WIM 中儲存特定 Windows 版本的多個 SKU 時，將可顯著節省空間。例如，假設您結合 Windows XP Professional 與 Windows XP Tablet PC Edition 或是結合 Windows Vista Business Edition 與 Windows Vista Ultimate Edition；這些結合案例可有效利用空間，因為相同版本與相同 Service Pack 層級的兩個 SKU 可共用許多同樣的程式碼與檔案。
最後該語言上場了。組織越大，需要考量的語言越多。在 Windows XP 中，您可以選擇使用當地語系化版本或多語系使用者介面 (MUI)。在完全當地語系化的 Windows XP 版本中，幾乎所有的字串都已翻譯成目標語言。另一方面，使用 MUI 時，基準語言是英文 (English)，而 MUI 語言套件 (和之後的語言介面套件) 則會盡可能轉換語言字串 (MUI 在 Windows 2000 中使用的效果不錯，而在 Windows XP 與 Windows Server 2003 中的表現更好)。
若您的組織使用 MUI，當您在相同的 WIM 中結合各種語言版本時，會產生不錯的結果。這是因為他們的核心都是使用英文二進位碼檔案。但是在 Windows Vista 之前，當地語系化的版本並非如此。由於二進位碼檔案本身已當地語系化，而各種語言中的同一個二進位碼檔案並不相符，也就是說您必須針對每種語言儲存近乎整個作業系統 (和所有當地語系化應用程式)。
在 Windows Vista 中，您可以忽視當地語系化版本 (當地語系化檔案已成為單一二進位碼檔案的一部份，只是在其中包含不同的資源檔)。Windows Vista 會針對每種語言 (包括英文) 使用 .mui 資源檔。基本上，Windows Vista 是不受語言限制的，而幾乎所有語言資訊都存放在 MUI 檔案中。因此，將多種 Windows Vista 語言版本儲存在相同的 WIM 中，將可大幅節省空間。即使將兩種、四種或更多語言儲存成單一的 WIM，影像檔的大小也不會大幅增加，而且您可以之後再根據需求的變化來切換或新增語言。
簡言之，在建置解決方案時，您應該考慮到 Windows 版本，以及其他應用程式版本是否有共用相同的二進位碼檔案，以便將檔案儲存在單一執行個體存放區。這樣可協助您判斷整個組織需要多少 WIM 檔案。

使用者狀況
一般而言，組織越大，情況就會越複雜。原因不只是單純的組織規模而已，同時也是基於所產生的各種變數；亦即，使用者和業務單位更多，需求就會更龐雜。
我還記得一家跨國組織，它有數萬名使用者，而且從單一的地理與組織位置進行部署程序管理。這個組織的負責人總是會提出一些深具挑戰性的問題。譬如說，他會擔心在非洲某些地方的遠端使用者常遇到網路連線品質不良的情況，而且他們的位置往往距離電話線有數百哩遠。他需要知道這些使用者如何復原自己的系統，而不會停工好幾天或長途跋涉來取得支援。
當您開發產品時 (在此您應該將修復解決方案視為一個產品)，您必須考量到使用者的需求。考量特定的商務需求，但同時也要考量與不同使用者類別相關的各種複雜情況。您應該整合所有的使用案例，並利用簡短說明來描述您支援的各種使用者類型。這樣可幫助您辨認出修復解決方案不小心遺漏的使用者，並確保您照顧到各種使用者類型的需求。

正確的 Windows PE 版本
另一項重要決策，是決定哪一種 Windows PE 版本符合您的需求。這個專欄的前幾篇文章可能有所助益，不過在此我會更清楚加以解說。如果您符合以下任何一種情況，就應該使用 Windows PE 1.6：
  • 您只需要修復 Windows XP (或 Windows Server 2003)
  • 您修復的系統都與進階組態與電源介面 (Advanced Configuration and Power Interface，ACPI) 不相容
  • 您修復的系統的 RAM 不到 512MB
  • 您修復的系統需要進行預先開機執行環境 (Pre-Boot eXecution，PXE)，且記憶體是在 256MB RAM 以下。
如果您符合以下任何一種情況，就應該使用 Windows PE 2.0：
  • 您只需要修復 Windows Vista (或 Windows Server 2008)
  • 您需要同時修復 Windows Vista 及 Windows XP
  • 您有使用 BitLocker™
請注意，ImageX (請參閱〈建立、更新及儲存〉一節) 和大部分的協力廠商影像解決方案，都能順利搭配任一版本的 Windows PE 使用。

啟動 Windows PE
接下來您需要考慮到 Windows PE 的開機方式。使用者狀況在此扮演關鍵角色。讓您的使用者攜帶 CD 或 DVD 進行修復是否切合實際？他們能夠在旅行時放入膝上型電腦中嗎？還有您如何保持修復媒體的最新狀態呢？卸除式媒體上的修復影像可能很快就過時了。
毫無疑問，我最常見到的情況是使用次要硬碟磁碟分割。另一個選項則是 PXE 開機。您也可以考慮使用外部 USB 磁碟機，甚至是 USB 快閃磁碟機 (UFD)；但要注意的是，使用的硬體必須明確支援從 UFD 裝置開機。
「Windows PE 開機方法」資訊看板概述各個 Windows PE 版本所支援的開機方法，並提供關於每個方法的一些重點考量。
您對啟動 Windows PE 的目標，應該是在符合特定條件的情況下啟動修復程序：
  • 以最低程度的使用者互動
  • 以最少的動作 (卸除式媒體或卸除式裝置)
  • 要考慮到電腦可能沒有網路連線
  • 要考慮到電腦可能無法在本機開機 (Windows 無法開機)
出自整個磁碟機發生故障的疑慮，系統管理員常會將 Windows PE (一般或 RAMDisk) 放在硬碟上視為不可行的選項。但事實上，基於今日磁碟機的可靠性，這其實是可行的，而且萬一實體磁碟機真的整個故障了，使用者也無法靠自己的力量修復系統。
因此我傾向於建立次要磁碟分割，並在此儲存修復影像。我並不太贊同隱藏該磁碟分割，這樣只會讓使用者感到困惑。在上面使用存取控制清單 (ACL) 也不實際，除非您的使用者都不是本機系統管理員。
藉由縮減用於 Windows 的磁碟分割 (請參閱「建立修復磁碟分割」資訊看板)，您可以建立足夠的空間來儲存 Windows PE 和您的修復影像。若要將 Windows PE 放在次要磁碟分割上，您只要在修復磁碟分割上建立適當的開機磁區，並將 Windows PE 放在該磁碟分割上即可 (Windows AIK 與舊版 Windows PE 隨附的文件都有解說這個程序，在此我就不細述了)。請記得一個重點：用來開機的磁碟分割取決於標示為使用中的磁碟分割。Diskpart 有可用來設定使用中旗標，以及同等重要的非使用中旗標。若要從 Windows 內部 (或是從 Windows PE 副本內部) 啟動修復磁碟分割，請使用 diskpart 來切換使用中磁碟分割 (請參閱 [圖 1])。下面是用來切換單一磁碟中有雙磁碟分割系統的 diskpart 指令碼範例 (其中使用 diskpart /s nameofscript.txt)：
SEL DIS 0
SEL PAR 1
INACTIVE
SEL PAR 2
ACTIVE
EXIT
圖 1 Diskpart 變更使用中磁碟分割
圖 1 Diskpart 變更使用中磁碟分割
許多市售的修復工具都使用這個程序來對拷磁碟分割 -- Windows PE 本身就有內建可針對特定磁碟分割類型 (例如隱藏的 OEM 磁碟分割) 執行這個動作的功能。有時候這些工具也會取消隱藏已隱藏的 OEM 磁碟分割類型。

建立、更新及儲存
建立修復磁碟分割
只要您瞭解相關步驟，那麼建立修復磁碟分割並兼顧 Windows 完整性的作業並不困難。此處提供快速的必備步驟提要。請注意，這個處理程序需要 Windows PE 2.0。即使您可能不是使用 Windows PE 2.0 進行部署或修復，但是這項工作必須使用 2.0 版。在部署 Windows Vista 和建立用於 BitLocker 開機檔案的開機磁碟分割時，也可以應用這個程序，因為 BitLocker 需要至少兩個磁碟分割 (一個用於開機檔案，另一個用於 Windows 系統的其餘部分)。
  1. 重組磁碟 (有助於加速耗時的壓縮程序)
  2. 開機到 Windows PE 2.0
  3. 執行 diskpart (您也可以為步驟 4 到 9 建立指令碼，然後傳遞下列引數給 diskpart：/s name_of_your_script
  4. SEL VOL 1 (或是您要壓縮的磁碟區)
  5. SHRINK DESIRED=N MIN=N (指定單位為 MB，DESIRED 是目標，而 MIN 則是所需的絕對最小值)
  6. 壓縮完成時，執行 SEL DIS 0
  7. CRE PAR PRI (若要指定磁碟餘數以外的大小，您可以指定 SIZE=N)
  8. ASSIGN LETTER=N:(這個代號僅適用於 Windows PE 底下)
  9. 結束 diskpart
  10. FORMAT N:/Q /Y /FS:NTFS (NTFS 格式化新的磁碟分割)
  11. 執行 bootsect N:/nt60 用於 2.0，/nt52 用於 1.x)
  12. 複製所需的 Windows PE 檔案到修復磁碟分割
  13. 系統關機

ImageX 是免費提供的解決方案，不過您可能已經有慣用的影像工具。您可以使用最熟悉的工具。若考慮使用 ImageX，有幾點我覺得不錯的可以討論一下 (除了價格誘因以外)。ImageX 在壓縮方面特別有力。此外，可以附加影像和輕鬆加以編輯的這項特性也很棒。
另外，ImageX 可讓您以非破壞性的方式建立一或多個磁碟區的影像，這點也不錯，如此一來，您只要略過使用者資料即可保留這些資料。換句話說，在修復 Windows 時，您不需要消除整個磁碟區。
當然，您必須決定儲存影像的位置。假設您的解決方案使用修復磁碟分割，您可以在此儲存 WIM 或其他影像檔案。您甚至可以考慮使用 Windows 部署服務 (WDS)，建立標準的 OS 影像，並儲存在網路上。這樣可提供整體基礎結構都適用的通用修復解決方案。當然，如果您有外派的使用者 (例如前文提到，在世界另一端的工作者)，您必須確保當他們無法連上網路時也能使用自己的解決方案。
我說過您可以使用 DVD 等媒體，但是基於數個原因，我個人並不喜歡在一般用途中採取這個作法。舉例來說，影像大小很容易超過 DVD 的容量，而且 DVD 光碟不容易更新。我並不是說光學媒體毫無用處；只不過您必須衡量哪一種方案適合哪些使用者類型。如果您還猜不到的話，我的個人偏好是將影像儲存在修復磁碟分割、USB 硬碟或快閃磁碟機上，或是在允許的情況下，使用 WDS 儲存在網路上。
選用 WDS 的好處之一，是影像可以集中管理且容易更新。讀者應該都知道，現在每月都會推出 Windows Update，而且這些更新內容通常都很重要。您的解決方案應該盡可能將修復影像保持在最新的狀態。藉由 WDS，您將可以隨時在每個伺服器上更新影像，而且會很完整。

使用者資料與設定的考量重點
建構修復解決方案時，您必須謹記幾點。計畫任何修復解決方案的重點之一，是要確保使用者資料的安全性。您當然不希望外派使用者執行修復之後，發現所有重要資料都在修復過程中遺失了。最理想的情況是將使用者資料儲存在 C:磁碟分割以外的位置，否則您就必須非常小心處理系統修復作業。
我之前曾說過，ImageX 可讓您以非破壞性的方式還原磁碟。譬如說，它會將現有的 Documents and Settings (或 Users) 目錄樹狀結構移到另一個目錄，好讓使用者或指令碼在修復完成後能夠手動修復檔案。在大部分的情況下，將所有檔案儲存在自己的設定檔底下的使用者，或使用漫遊設定檔的使用者，應該都可以修復系統而不會遺失使用者資料。但是請記得，除非您非常仔細地打造修復解決方案，或有完美的備份解決方案，否則可能還是會遺失一部份的使用者資料。
別忘了，即使您盡心規劃，還是有些使用者會將資訊儲存在本身設定檔以外的位置。您應該確定您的解決方案考慮到可能會不小心弄丟使用者資料的情況，並且事先警告使用者。
若您使用加密檔案系統 (EFS)，請確認已執行主要修復計畫，您一定不希望無法復原的加密造成資料遺失。跟 BitLocker 一樣，請確保您可以復原用它加密的磁碟區。這表示您需要使用 Windows PE 2.0 (1.x 無法與 BitLocker 互動)。如需 BitLocker 修復的詳細資訊，請參閱 blogs.msdn.com/si_team。
最後，有些使用者會因為某些自訂內容或應用程式消失而感到困擾，請做好心理準備。自訂的內容 (針對應用程式或 Windows 本身) 會隨機儲存在其他位置，而非使用者設定檔中。在還原整個作業系統磁碟分割時，有些使用者會來電詢問：「x 到哪裡去了？」或是「Word 怎麼不再顯示 y 了？」請先灌輸使用者正確的觀念，讓他們瞭解系統環境不會與復原之前一模一樣。
使用 Windows PE 建立自己的修復解決方案需要花一些時間，而且在規劃及建構解決方案時，也必須考量到使用者狀況。修復解決方案不需要過度複雜化 -- 只要能支援您的使用者恢復作業，並在有限的技術支援和最短的時間內完成即可。

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


 現場筆記: 免費餐點以及培訓提示
現場筆記
免費餐點以及培訓提示
Michael Dragone

我是一位系統工程師， 目前任職於一家大約有 150 人的產權保險公司。我們的電腦需求其實相當簡單，因為我們的主要實務 (LOB) 應用程式是以網頁為基礎。因此，我們主要用於互動的程式，當然就是 Internet Explorer® 以及 Microsoft® Office。
由於應用程式部署需求看來相當簡單，您可能會認為我們的使用者在日常作業上應該不會有使用這些應用程式的問題。這基本上是對的。會發生的問題，通常都是 TechNet Magazine 讀者可以在數秒鐘內解決的問題。
透過實際經驗，我發現優良的使用者教育制度能夠避免問題的發生。在此我要跟您分享我們通常會為使用者做的兩件事，希望您看了之後也會採取類似的步驟，來造福您的使用者。
我們會安排的第一件事，就是培訓課程。我們會定期開課，以介紹新安裝的系統、即將部署的新應用程式，以及新訂立的原則。當然，如果我們要做重大的系統變更，我們也會事先舉辦特殊的課程，來說明變更內容以及給使用者機會提問。我們會在實施變更之前，先做這樣的溝通，讓使用者做好準備。
例如，我們即將全面更換電話系統。雖然我們的使用者依然可以透過 Outlook® 存取語音信箱，用來存取語音信箱的軟體卻會改變。我們已規劃相關的培訓課程，讓電話系統供應商向使用者展示新的介面，以及讓使用者可以在系統部署之前先提出任何疑問。
我們也會在課程中檢討使用者的一些困擾。如果您曾經有參考問題報告系統的內容，就會知道使用者所面臨的問題。例如，我們有一位使用者對於為何兩個不同的系統會需要使用不同的密碼感到不解。我們費盡口舌的說明一直無法說服她，但是課程中的一張 PowerPoint® 投影片卻能夠讓她大嘆「喔！原來如此」。
我的經驗告訴我，無論是什麼主題，成功的課程或會議所需的都是免費餐點和輕鬆的口吻。讓您的使用者能夠敞開心胸地提問很重要，即使是比較「愚蠢」的疑問。
我要提示的第二件事，就是要經常在辦公室遊走。我每天會花 10 到 15 分鐘與使用者哈拉。如果我看到有人正在使用奇特的方法執行某一項作業，我就會停下腳步，與使用者討論她正在做什麼，以及為什麼要這麼做。通常我都可以為她找出更簡便的替代方法。例如，我們有一位使用者會持續、意外地重新整理他的 Outlook 工具列，但是不知道如何修正問題。他一直默默地忍受，直到有一天，我發現了這個問題。我立刻向他說明如何變更他的工具列，以便在不小心造成重新整理時能夠恢復到他喜好的設定。
其她的使用者也可能會其他各種原因而不願意向服務中心或技術支援部門提問。有些人可能會感到尷尬，因為覺得他們想要問的問題可能比較愚蠢，不應該勞駕 IT。另外，有的使用者則會一直可憐兮兮地忍受老舊的鍵盤或滑鼠，因為他們不知道 IT 通常都會有備用的周邊裝置。只要每天花費數分鐘的時間去實地觀察您的使用者，就可以事先解決許多問題，也能夠為下一個培訓課程找到新點子 (但是還是別忘了要提供免費餐點)。
很重要的是，工作上的每一個細節都要以使用者為主。如此一來，所有或至少絕大部分的系統設定、原則和程序等的變更，就不會造成使用者的困擾。每一位使用者都有獨特的需求和個性，所以對於變化的反應會有所不同。
通常，由於我們比較樂於接觸新技術，所以有時候會忽略了我們所服務對象的特質以及他們對於新科技的接受度。只要用耐心並事先安排相關的使用者培訓課程，您就可以幫助使用者變得跟您一樣的喜愛電腦。當然，過程中還是要一步一步來。

Michael Dragone 是位於美國紐約一家產權保險公司的系統工程師。他具有 MCDST 和 MCSE:Messaging 的認證。工作之餘，他喜歡到海邊的沙灘上散步、與他的狗玩耍，以及確保伺服器的修補程式都已裝妥。


 Windows 機密文件: 已知 DLL 的拉鋸戰
Windows 機密文件
已知 DLL 的拉鋸戰
Raymond Chen

Windows 的這一項功能曾經被非正式地稱為「已知 DLL 」(Known DLL)，指的是核心模組載入器會以特殊方式處理的動態連結程式庫 (Dynamic Link Library，DLL) 清單。當載入器看到程式有載入時期動態連結至已知 DLL 時，就會立即使用已知的複本，並略過通常在載入模組時的搜尋演算法。有些人可能會認為這屬於安全性功能 (若為如此，也僅是相當弱的安全性功能)，但事實上，安全性並非此功能的原意。已知 DLL 完全是為了要提升效能。
已知 DLL 功能的運作方式，已經過多次的演變。在某些 Windows® 版本中，核心會以已知 DLL 做為起點，並查詢已知 DLL 連結的所有 DLL，然後再查詢該些 DLL 所連結的 DLL...以此類推。此程序會針對所有的依存性項目執行一系列的轉移性解析，然後將它們都視為已知。在其他的 Windows 版本中，不會執行此轉移性解析過程；而是僅會將明確列為已知的 DLL 視為已知。在某些 Windows 版本中，已知 DLL 會在系統啟動時由核心預先載入；在其他的版本中，並不會預先載入，所以核心僅會利用清單以省略在路徑中搜尋 DLL 的麻煩。
各個版本不僅對於已知 DLL 的解釋方式會有差異，連 KnownDLL 登錄機碼的內容也有可能變更。Windows 效能小組有時候會變更已知 DLL 清單以及該清單如何轉換成一組 DLL 的規則，一切都根據他們對於應用程式將如何使用 Windows 而異。跟一般的工程設計一樣，都需要取捨和平衡。在系統啟動時預先載入已知 DLL 可以讓使用該些 DLL 的應用程式的啟動速度更快，但是需要付出代價。系統的啟動時間會更久，而且需要佔用更多記憶體，因為該些 DLL 會保留在記憶體中，無論是否有用到它們。整個過程就是個拉鋸戰，以犧牲其他元件的代價來提升某些元件的效能。如何找到最佳平衡點是一項艱難的任務，而且如您所見，此平衡點也持續地在微調，以因應使用模式的演變。
已知 DLL 有一項較不明顯的後果，是已知 DLL 的優先順序會比本機重新導向的 DLL 更高 (我們曾經在 2007 年 1 月的專欄中研討過重新導向的 DLL)。如果您仔細想一想，就能理解此行為是預期的，而非突變的行為。畢竟已知 DLL 的目的，就是要略過搜尋路徑以加快 DLL 的載入速度。如果核心每次都要檢查本機重新導向的 DLL，那只會使執行速度變慢。您可能會想說，在搜尋路徑中加入一個目錄沒什麼大步了，但是如果該目錄位於地球另一端的網路伺服器上，那麼單一個目錄也可能拖累整體效能。
您知道嗎，我們曾經看到需要仰賴特定 DLL 為已知的程式。曾經有一個程式，其應用程式目錄中有一個稱為 Version.dll 的檔案。在正常的規則下，此私用的 Version.dll 檔案應該要覆寫系統目錄中的檔案，但是在 Windows XP 中，Version.dll 已列為已知 DLL。這代表應用程式目錄中的檔案會被忽略，而會優先使用系統目錄中的檔案。
但是在 Windows Vista® 中，Version.dll 以不再列為已知 DLL，這可能是因為效能小組發現應用程式的使用率不高，所以不值得先載入。如此一來，該程式便無法在 Windows Vista 上正常運作，因為該應用程式實際上需要仰賴核心略過該程式在自己的應用程式目錄中所安裝的 DLL。也就是說，該程式主動地在搜尋路徑中安裝了一個 DLL 檔案，但是又需要仰賴 Windows 忽略該檔案！若要 Windows 忽略某個檔案，最有效率的做法當然是一開始就不要安裝該檔案囉。最矛盾的是，負責撰寫該程式的公司竟然提出問題報告，說他們找到一個安全性漏洞。

Raymond Chen 的網站「The Old New Thing」以及採用相同標題做為書名的出版品 (Addison-Wesley，2007)，都討論 Windows 的歷史和 Win32 程式設計。他連自己的衣服尺碼都已經不清楚了。