 TechNet Magazine November 2007

TechNet Magazine November 2007

Windows 系統管理: Windows Vista 中關於離線檔案的變更

使用者要如何在連線不穩定甚至沒有連線能力的情況下，使用存放在網路上檔案並同時避免版本控制的問題呢？這種問題可說是隨處可見。持續可用是帶來絕佳體驗的關鍵，一同來了解 Windows Vista 如何以改進功能提供更佳的方法來使用離線檔案。

Jeremy Moskowitz 桌上型電腦的部署: 使用 BDD 2007 進行簡單、可調整的部署

沒有 SMS 2003 嗎？別擔心，建立簡單的桌上型電腦部署還有其他辦法。這裡提供了詳盡的指南，只需要稍微手動輸入或是完全不用手動輸入，便可以 BDD 2007 和 SQL Server 建立可調整的部署。

Adam Shepherd 通訊: Microsoft 內部的 Exchange Edge Transport Server：第二篇

Exchange Edge Transport Server 能協助您建立更可靠及更安全的傳訊環境。我們已經在＜第一篇＞中示範如何設定這些伺服器，在本文中我們將透過範例來詳細說明這些關鍵功能如何改善您的傳訊環境。

Kay Unkroth 網路功能: 使用 ISA Server 2006 來設定 VPN 遠端存取

虛擬私人網路可改進連線能力並提升產能，而且實作和管理起來一點也不難。了解您如何能夠利用 ISA Server 2006 來解決兩種常見的 VPN 案例。

Alan Maddison SQL Server: 最佳化 SQL Server 查詢效能

最佳化資料庫效能時，微調個別的查詢就跟微調伺服器硬體和軟體組態一樣重要。只要有一個查詢失控，整個資料庫都可能跟著遭殃。這裡提供了產生、分析和修改執行計畫，以將 SQL Server 查詢效能最佳化的指南。

Maciej Pilecki 編輯的話: 讓您有更多電可用

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

Greg Steen Exchange 佇列問題與解答: 保障電子郵件通訊協定安全、不明垃圾郵件及其他

在本期月刊中，Exchange 小組將探討 SMTP 的傳輸層安全性，如何防止詐騙的 NDR 阻塞您的佇列，以及如何因應各種不同的安裝挑戰。

Nino Bilic and Scott Landry 公用程式焦點: Windows PowerShell 的 SMS Cmdlet

本文所要探討的是，新手剛開始如何使用 Windows PowerShell Cmdlet，從命令列管理 SMS 2003 用戶端。

Don Brown The Cable Guy: 無線單一登入

單一登入為一般使用者和系統管理員提供不少好處。現在就讓我們看看單一登入如何簡化網路無線驗證的實作。

Joseph Davies 研究筆記: 使用高效能運算對抗 HIV

這篇文章將探討 Microsoft Research 的 eScience 小組如何與醫療研究人員協力合作，使用高效能運算來尋求 HIV 的治療方法。

Kristin Firth and Mia Matusow Windows PowerShell: 撰寫規則運算式

透過撰寫得當的規則運算式，可以讓 Windows PowerShell 指令碼判斷資料的格式是否有效。粗略了解一下您如何能夠在 Windows PowerShell 中使用規則運算式。

Don Jones 嗨，Scripting Guy！: 遠從墳墓裡執行桌面管理

Scripting Guys 將示範說明如何使用 Windows 遠端管理來擷取遠端電腦上的類別屬性和執行個體。對了，本月還有很酷的猜謎。

The Microsoft Scripting Guys 安全性監控: 安全地隨處存取

您可以利用終端機服務元件，探索隨處存取解決方案在網路和安全性設計方面的考量因素，並且學習幾種以 Windows Server 2008 建立解決方案的實用方法和最佳作法。

John Morello 桌面檔案: 磁碟重組的真相

磁碟重組的陷阱曾讓許多人產生迷思，許多管理員就因為對的了解不夠而沒有執行重要的維護工作。在這裡，我想請各位釐清哪些問題是真的，哪些問題不可能發生，從中再找出防治問題的方法。

Wes Miller 現場筆記: 鱈魚教官

當社群成員開始騷動時，也許您只需要一條大魚。一同來瞭解社交工程如何拯救 Live QnA。

Betsy Aoki Windows 機密文件: 檔案系統矛盾說

不知您有沒有想過，為什麼需要在那些關鍵開機檔內建一個迷你檔案系統驅動程式呢？

Raymond Chen


 Windows 系統管理: Windows Vista 中關於離線檔案的變更
Windows 系統管理 Jeremy Moskowitz

Windows Vista 中關於離線檔案的變更
摘要:
  • 連線與離線持續性
  • 檔案可用性
  • 離線資料夾的演化

桌面管理最棘手的難題之一是讓離線使用者能像連線一般地工作。這類需求比您想像中得更迫切，比起五年前，使用者現在具有更高的行動力。雖然有很多工作的確需要離線處理，
但是這三種最常見的情況確實需要離線處理：將膝上型電腦與公司網路中斷連線準備上路、在緩慢或斷斷續續的連線環境中進行連線，以及分公司與總公司之間失去連線。
遇到這些情況，要如何在檔案正本放在主要伺服器的同時，使離線電腦保存檔案的副本？更重要的是，要是總公司的人修改伺服器上的檔案，而出差員工又對它進行修改，要如何處理這樣的衝突呢？幸好，內建於 Windows® 2000、Windows XP 和 Windows Vista® 的離線檔案引擎可以處理這些問題。

答案在於快取
離線檔案引擎是個名副其實的大型快取機器。沒錯，私底下 (還有在 Microsoft 內部) 它又叫做用戶端快取 (CSC)。離線檔案引擎可設定並極有彈性，使用者可以決定想快取的內容，並設定使系統快取所需內容。您可以像連線一般地離線存取同一檔案，並不會影響命名空間。也就是說，無論是在線上或離線工作，都是使用相同的 UNC 路徑或磁碟機代號來存取檔案。
您可以將檔案設定成手動或自動快取。如果已經知道外出時會經常用到哪些檔案或資料夾，只要先將它們指定為隨您出差就行了，設定方法如下：Windows XP 使用者可按一下滑鼠右鍵，叫出儲存在本機或網路共用上的檔案，接著選取使檔案可離線使用的選項 (見 [圖 1])。在 Windows Vista 中，此選項稱為 [永遠可以離線瀏覽]。以手動方式使檔案可以離線使用有時候稱為固定 (Pin) 檔案。
[圖 1] 使檔案可離線使用
[圖 1] 使檔案可離線使用
[圖 1a] 離線檔案資料夾
[圖 1a] 離線檔案資料夾
使用中的共用可以透過 UNC 路徑或與磁碟機代號對應來連線。沒錯，檔案不一定要儲存在執行 Windows Server® 機器上。它可以存在於可提供 SMB (伺服器訊息區) 通訊協定的任何項目，例如 Samba 伺服器或 NAS 裝置 (有些極少數的例外)，它們也都遵守 SMB 通訊協定。
第一次選擇固定檔案時，Windows XP 會帶您逐步完成一連串的精靈畫面，詢問您何時進行同步處理。如果您在每個畫面上都按 [下一步] 並接受預設值，同步處理便會在您每次登入或登出時執進行，還有閒置時在背景進行。精靈完成後，圖示將會變更，表示檔案現在已經可以離線使用。
一旦與網路中斷連線，除了已選擇為可離線使用的檔案，共用上其他所有檔案都無法使用。這有時候會出問題：圖示會顯示哪些檔案永遠可以離線瀏覽，但要等到中斷連線之後，才能看出來並不是所有其他檔案都可以使用。這我會在本文稍後詳細討論。
手動使檔案可離線使用有它的好處，但是有時候採取較為自動的方式可能比較妥當。接下來我會透過自動快取來探討這個案例。

自動快取優於手動快取的情況
自動快取是在伺服器按共用逐一設定而成。假設有個共用叫做 Sales，您想讓業務人員帶著檔案出差，就可以指示 CSC 引擎如此處理。[圖 2] 顯示按下 Windows Server 2003 的 [快取] 索引標籤後出現的 [離線設定] 對話方塊。[圖 3] 中說明了設定的內容。
Figure 3 自動快取設定 (Close Figure 3)

設定 | 描述
只有使用者指定的檔案和程式可以在離線時使用。 | 允許使用者手動指定可離線使用的檔案。這是預設值。
使用者從共用開啟的所有檔案和程式將可於離線時使用。 | 允許自動快取 Windows 檔案總管接觸過的所有檔案和程式。[效能最佳化] 設定適用在快取程式而不是用到文件上，但是它對效能通常沒有影響，因此在大多數的情況下可以忽略，而不會產生問題。Windows Vista 便完全忽略此選項。
來自共用的檔案或程式無法離線時使用。 | 當用在 Windows 2000、Windows XP 或 Windows Vista 用戶端上時，封鎖使用者存取供離線使用的項目。
[圖 2] Windows Server 2003 的 [離線設定] 對話方塊
[圖 2] Windows Server 2003 的 [離線設定] 對話方塊
要了解自動快取的運作方式，先假設有個 Sales 共用，裡頭有 10 個檔案 (Sales01.txt ~ Sales10.txt)，[所有檔案和程式] 的設定也已經啟用，使用者從共用開啟這些檔案時可自動離線使用。可是結果並非立即可見。對於使用者來說，他們看不出有更多檔案突然可以離線使用的跡象。而且，只有用 Windows 開啟 (因而快取) 的檔案之後才能提供離線使用。簡單來說，您必須在實際從網路中斷連線前，親自在線上開啟想要離線使用的檔案才行，否則就無法離線使用這些檔案。
再者，自動快取的檔案也不一定會一直保存在快取中。Windows XP 和 Windows Vista 處理這個暫時空間的方式不太一樣，不過重點是檔案可能因空間的限制而被排除掉。有用到的檔案才會保留下來。有段時間未開啟的檔案會被排除以將空間留給開啟的新檔案。因此，雖然您近來接觸過的檔案很可能還留在快取中，但是別以為自動快取會保證這些檔案可用。要確定檔案確實可用，就得固定檔案。身為系統管理員，您也可以使用群組原則透過管理方式指派的離線檔案設定來固定檔案。
讓我們來看看一個實際的操作範例。假設叫做 EastSalesUser1 的 Windows XP 使用者開啟了叫做 Sales05.txt 的檔案，另一名叫做 EastSalesUser2 的 Windows Vista 使用者開啟了 \\server\sales 共用上的 Sales05.txt。
由於 Sales 共用上已設定自動快取，所以當 EastSalesUser1 (Windows XP 上) 和 EastSalesUser2 (Windows Vista 上) 離線時，還是可以使用那些檔案。Windows 已在離線檔案快取中儲存了這些檔案的副本。但其他使用者沒用到的檔案怎麼辦呢？
Windows XP 和 Windows Vista 對於被留置在辦公室的檔案有不同的處理方式，如 [圖 4] 和 [圖 5] 所示。Windows XP 對於沒有快取到的檔案隻字不提，離線後，這些檔案可能就莫名其妙的蒸發了。相對的，Windows Vista 則會顯示圖示覆疊，並替未經快取的檔案標上暗灰色的 X。對於顯示可離線使用的檔案，這可是一大進展。唯一的問題就在這些現象只有在中斷連線後才看得到，在連線工作階段是不會出現的。所以說能使檔案的狀態更明確得卻是求之不得的進步。
[圖 4] Windows XP 只有在離線後才顯示可用的檔案
[圖 4] Windows XP 只有在離線後才顯示可用的檔案
[圖 5] Windows Vista 在離線時顯示無法使用的檔案
[圖 5] Windows Vista 在離線時顯示無法使用的檔案

可用還是不可用
有些系統管理員對於利用離線檔案猶豫不決，正是因為擔心混淆，到底哪些檔案肯定可以離線使用，哪些不行，還有判別方式都需要處理。在 [圖 5] 中，sales01.txt 上的綠色圓形圖示指出檔案保證可用 (再次強調，檔案固定後就保證可離線使用)。
不過，先前有解釋過，Windows XP 和 Windows Vista 兩者透過自動快取供離線使用的 Sales05.txt 並非一定真的離線可用。切記，唯有您接觸過的檔案才可離線使用。因此，如果系統能指明檔案暫時或可能離線可用的話，該有多好。由於沒有圖示加以區別，因此可能很難判斷出哪些檔案可離線使用。Windows Vista UI 在這方面比較好一點，但也要眼睛銳利才看得到。Windows Vista 中有個叫做「離線可用性」的檔案總管屬性倒是有提供可用性的資訊。當項目處於選取的狀態時，預覽窗格中會顯示這個屬性。如果項目是固定的，則其值會是 [可隨時使用]。如果未固定但已快取，則其值會是 [可用]。
Windows XP 和 Windows Vista 中檔案暫時可離線使用的概念雷同，但是實作的方式稍有差異。[圖 6] 說明 Windows XP 和 Windows Vista 處理離線檔案的方式。
[圖 6] Windows XP 和 Windows Vista 離線檔案區域
[圖 6] Windows XP 和 Windows Vista 離線檔案區域
簡單的說，Windows XP 和 Windows Vista 都有個地方可保存離線檔案，但是兩個作業系統存放總是和暫時可離線使用的檔案在作法上不盡相同。
對於 Windows XP，永遠可離線瀏覽的檔案 (由圖示變更指定，如 [圖 1] 所示) 是固定放置在存放它們的地方。要是手動固定 10GB 的檔案，使它們永遠可離線瀏覽，則整個 10GB 將永遠可用。使用者可固定的檔案數目並沒有任何限制 (不受磁碟分割最上限的限制)。然而，Windows XP 最多只能自動快取 2GB 的檔案。原則是此處只會存放經常開啟的檔案，而必要時則會剔除那些不常用到的檔案。根據預設，硬碟上 10% 的可用空間是配置給暫時可用的快取，如 [圖 7] 所示。只有 Windows XP 上的系統管理員才能使用此設定。
[圖 7] 在 Windows XP 中設定離線檔案的磁碟空間
[圖 7] 在 Windows XP 中設定離線檔案的磁碟空間
Windows Vista 也可以永久或暫時地存放檔案。不過，差別在哪呢？暫時檔案快取是包含在整體快取內。根據預設，整個快取 (包括暫時檔案和永遠可離線瀏覽的檔案) 的上限是硬碟上 25% 的可用空間。會有此變更的理由是因為在 Windows XP 中，使用者可能不停手動快取檔案 (可能是十幾個 GB)，結果用盡硬碟空間。有了這個新配置，系統管理員可撥出特定的空間給整個快取來防範這種情況。看一下 [圖 8]，注意磁碟機上 25% 的可用空間很奇怪地顯示成整個磁碟機的 15.2%。也注意一下第二個滑桿 (設定暫時空間) 永遠不能設得比第一個滑桿 (設定所有離線檔案的最大空間) 高。您可以按一下 [變更限制] 選項來存取這些 [離線檔案磁碟使用量限制] 滑桿，但是要記住您必須具備系統管理員認證才能這麼做。
[圖 8] Windows Vista 中離線檔案的可用空間
[圖 8] Windows Vista 中離線檔案的可用空間

避免過度快取
資料夾重新導向是另一個 Windows 功能，可讓您確定一般位於機器本機上的某個重要資料夾實際上存放在伺服器。如此一來就不用擔心本機機器故障，反正重要檔案的副本是在網路共用上。
假設您有個重新導向的 [我的文件] 資料夾 (在 Windows XP 中) 或 [文件] 資料夾 (在 Windows Vista 中)。這時 (實際上不管是重新導向哪一個資料夾)，作業系統會假設您希望這些檔案總是可離線使用，而且重新導向資料夾內的每個檔案都會有一個如 [圖 1] 所示的符號。它有一個缺點：假如您處於連線良好且隨時不斷線的網路，之後漫遊到新機器，就會快取新機器上重新導向資料夾的全部內容，即使您只打算用一個工作階段就不用了也是一樣。這不僅浪費空間，而且若處理不當，也有危安全性。
另外一個不知不覺自動快取檔案的情況是出現在使用 Windows 檔案總管瀏覽共用上的檔案。假設您只是要使用檔案總管查看網路共用上 1GB 的圖形檔，而自動快取已啟用，那麼這些檔案很有可能就會自動下載並放置到您的快取中。這是因為使用檔案總管接觸檔案，等於是把它放到暫時離線快取。通常共用中的每個檔案都會被接觸到，以取得例如檔案大小或影像預覽的中繼資料。若是在快速且連線狀態良好的連結上發生這種情況，沒什麼大不了。Windows 可以迅速地在背景快取檔案以供日後使用。要是透過緩慢連結自動快取連線到該網路共用，可能就會動彈不得，這種狀況在 Windows XP 檔案總管和 Windows Vista 檔案總管基本上是一樣的。幸好 Windows Vista 離線快取引擎可以經過訓練，使它更容易辨別緩慢的連結。

使用群組原則的離線檔案
Windows Vista 離線檔案的重大變更
離線檔案小組組員非常想告訴您我們最得意的變更，但礙於篇幅有限，無法在此一一探索。總而言之，下面是離線檔案的重大變更：
  1. 不間斷地離線對連線交易，表示開啟控點不會再封鎖交易。
  2. 縮小規模依檔案離線，讓一個共用離線不再使整個伺服器也跟著離線。
  3. 透過 Windows 檔案總管中的 [線上工作]\[離線工作] 按鈕強制離線模式。
  4. 依使用者來加密快取內容。
  5. 全新的同步處理引擎，偵測和分析變更的速度更加快速。
  6. 與 Windows 搜尋相整合，以便製作重新導向資料夾的索引。
  7. 本機對遠端同步處理可運用差異點陣圖傳輸 (Differential Bitmap Transfer) 功能。
  8. 透過同步中心延緩解決衝突。
  9. 通知區域球形文字說明已移除，不再干擾使用者。
  10. 提供全新完整的 COM API 和 WMI 支援以利管理，記載於 MSDN® 上，網址是 msdn2.microsoft.com/bb530662。
  11. 透過 WMI 提供者的指令碼支援 (不久將記載於 MSDN 上)。
  12. 全新的殼層項目屬性：離線狀態和離線可用性。
  13. 建立映像以便在離線時代表無法使用的命名空間元素。檔案總管會將這些項目顯示成含灰色 X 覆疊顯示的灰暗項目，以便從連線狀態轉換成離線狀態時，避免殼層資料夾檢視產生劇烈的變動。
  14. 全新的控制台小程式。
如果您決定想要進一步了解，可以在我的著書和 Microsoft 說明文件中找到許多與此相關的資訊。

我稍早有說過，每當使用者 (或檔案總管) 接觸某檔案時，會將整個檔案帶入快取中。如果檔案是 80MB 的 Visio® 或 Word 文件，也無可奈何。Windows XP 和 Windows Vista 都知道何謂緩慢連結。事實上，根據預設，Windows XP 認為緩慢連結是 64Kbps。如果連線速度大於此值，且用戶端是 Wdinwos XP，即使使用者不願意，還是會透過登入時的緩慢管線把檔案帶下來。所以最好是設定 Windows 更妥善應付緩慢連結。等會您就會看到，您可以透過群組原則來達到這個目的，方法是建立群組原則物件 (GPO) 與包含目標帳戶 (Windows XP 或 Windows Vista) 的組織單位 (OU) 相連結。
當使用者透過緩慢連結進行連線時，Windows XP 會先嘗試使用本機快取的檔案，之後才嘗試使用網路副本。這很合理，但是 Windows XP 還是可能做一些您意料不到的事：如果使用者從網路開啟大型檔案或檔案總管接觸到它們，它便會將檔案下載到快取中 (如果快取中沒有這個檔案的話)，這就麻煩了。而且在我的測試中，要是將同步處理排定在登出時進行 (預設值)，該些檔案的其餘部分便會透過緩慢連結下載放到快取中 (麻煩加倍)。
Windows Vista 的反應就不一樣，它預設並不會將任何情況視為緩慢。事實上，如果您是用小容器進行連線，每秒只取得 1 個位元，Windows Vista 還是會將該連線看成快速連線，然後使用網路上的檔案副本。但是您可以訓練 Windows Vista 來了解當連線緩慢時您希望指定哪些共用來進行轉換。這樣一來當發生這類情況時，事情就比較好辦一點。Windows Vista 的行為 (經過群組原則設定後) 會變成即使使用一般的檔案和檔案總管作業，透過緩慢連結就是無法使用定義成緩慢連結共用的內容。
離線檔案服務所執行的背景同步處理也不會在緩慢的連線上進行。不過，應該要注意的是，透過同步中心還是可以進行手動同步處理。
設定 Windows Vista 來修改它處理緩慢連結的方式，可透過群組原則設定 [設定緩慢連結模式] 來完成 (請勿將此與名稱類似的 Windows XP 設定 [設定緩慢聯結速度] 相混淆)。[設定緩慢連結模式] 接受下列值：當連線緩慢時，您希望自動轉換成離線的伺服器和共用名稱，以及連線速度必須多緩慢，伺服器\共用的組合才會離線。伺服器\共用組合可以是 \\server\share 的任何組合，甚或是只用一個星號 (*) 來代表所有伺服器上的所有共用。第二組的值是宣告輸送量 (以 kbps 計) 和延遲 (以毫秒計)，必須超過此值才能宣告為緩慢。不過在這裡跟您報個料：下載檔案時，不會檢查比較常用的配對 (輸送量)。因此，如果您在重新導向的 [文件] 資料夾中有 10GB 的檔案，而且您膝上型電腦有緩慢的連結又還沒包含當中任一檔案的話 — 就有的您等的了。不過，要是您將它與延遲檢查一起搭配，而且延遲下降得比指定值還低的話，那麼共用就會轉換成離線，饒過使用者而不用忍受等候這些檔案的漫長煎熬。
知識庫文件 934202 中的 Windows Vista Hotfix (預定包含在 Windows Vista Service Pack 1 中的變更) 應該能夠提升特定緩慢 VPN 狀況的效能 (此文可從 support.microsoft.com/kb/934202 取得)。事實上，這個 Hotfix 應該可以在下載是發生在緩慢連結時，強制檢查輸送量值。

同步處理衝突
您可能會猜想要是有人在離線時 (比如在飛機上) 變更檔案，而另一個人在線上 (總公司的線路) 變更同個檔案的話會發生什麼事。這種情況是在用戶端的層級處理。當您從離線狀態轉換成連線狀態時，會馬上發生 Windows Vista 離線檔案背景同步處理。您接著會收到提問要怎麼做 (在工作列通知區域中出現圖示後透過同步中心的項目進行)。使用者介面已經過重新設計來顯示其中一個檔案似乎比較新，也顯示比較詳細的衝突資訊。當將檔案存回伺服器時，使用者可以選擇重新命名目前只存在他機器上的檔案來保留衝突的檔案，如 [圖 9] 所示。
[圖 9] Windows Vista 檔案變更衝突通知
[圖 9] Windows Vista 檔案變更衝突通知

其他相關資源
離線檔案是提供您及您的使用者的實用功能。事實上，如果您用過資料夾重新導向，表示您已經有用到離線檔案，因此應該了解如何進一步靈活運用。我在本文提到了 Windows Vista 中一些離線檔案的變更，但這不過是一小部分。如需詳細資訊，請參閱「Windows Vista 離線檔案的重大變更」資訊看板。
您可以在線上找到更多有關離線檔案的詳細資訊，對於 Windows XP 請參閱 go.microsoft.com/fwlink/?LinkId=98141，Windows Vista 請參閱go.microsoft.com/fwlink/?LinkId=98138。
我的著作中 (請參閱本文結尾的傳記) 也有一大節專門討論離線檔案 — 包括各種群組原則設定的優缺點。最後，如需更詳盡的資訊，以及與其他人談談您的離線檔案經驗，請在 GPanswers.com 的社群論壇中花點時間，當中有個專門探討這個主題的區段。

Jeremy Moskowitz 是群組原則方面的 MCSE 和 MVP，他經營的 GPanswers.com 是有關群組原則的社群論壇。此外，他還舉辦一系列的群組原則密集訓練課程。他的最新著作為《Group Policy: Management, Troubleshooting, and Security》(Sybex，2007 年)。請造訪 www.GPanswers.com 與 Jeremy 聯絡並進一步了解相關資訊。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 桌上型電腦的部署: 使用 BDD 2007 進行簡單、可調整的部署
桌上型電腦的部署 Adam Shepherd

使用 BDD 2007 進行簡單、可調整的部署
摘要:
  • BDD 2007 的核心功能
  • 與 SQL Server 整合
  • 建置可調整的部署方案

大多數參與部署 Windows 的人都有聽過 Microsoft Solution Accelerator for Business Desktop Deployment，亦稱為 BDD，它是一套最佳作法指引和
工具，用來幫助您將 Windows® 部署至用戶端桌上型電腦。Windows Vista® 以 BDD 2007 的形式更新了 Solution Accelerator。這個版本包含了全新的 Microsoft® Management Console (MMC) 和工作編序器 (Task Sequencer)，工作編序器是源自 System Center Configuration Manager 2007，亦即 Systems Management Server (SMS) 2003 的後繼版本。
BDD 2007 還有一項較不為人知的功能可作為完整的部署方案。在舊版的 BDD 中，它可以幫助您透過容易管理且可重複的方式建立和維護桌上型電腦映像。BDD 2007 現在提供額外的功能，可將 BDD 與 Windows 部署服務 (WDS)、SQL Server TM，以及 Windows Server® 2003 分散式檔案系統複寫 (DFS-R) 相結合，建置出可調整的部署方案。
可是等一下，進行 Windows 用戶端部署不是建議使用 SMS 2003 搭配作業系統部署 (OSD) Feature Pack 嗎？
沒錯，如果您已經有 SMS 2003 基礎結構，應該朝著使用 BDD 2007、SMS 2003 和 OSD Feature Pack 方向來進行部署。這是目前達成自動部署最周全的方法，而且它確實能夠拉低在組織內設定、安裝和管理 Windows 的成本。
然而，許多客戶並沒有 SMS 2003 或是同等的軟體部署方案。對於這些客戶，在本文中我會探討另一種選項。

BDD 2007 核心概念
BDD 2007 提供兩種主要的部署方法。第一種方法是精簡式安裝 (Lite Touch Installation)，只使用 BDD 2007 來部署用戶端。這會在建置階段當場呈現一組精靈來擷取部署相關的資訊，例如應該為用戶端指定什麼電腦名稱 (見 [圖 1])，應該使用什麼鍵盤配置和時區等等。這種方法之所以稱為「精簡」是因為在建置階段開始之前收集這類資訊所需的手動輸入時間通常很短。
[圖 1] BDD 2007 精簡式安裝精靈
[圖 1] BDD 2007 精簡式安裝精靈
第二種方法是自動安裝 (Zero Touch Installation)，這是透過與 BDD 2007 整合，以 SMS 2003 的功能搭配 OSD Feature Pack 為基礎建置而成。這種組態可提供完全自動化、可調整、容易管理且免動手的部署方案。
BDD 2007 在建置階段 (用戶端 OS 部署的前幾個步驟之一) 會從各種不同的來源收集資訊。這些來源包括 WMI 呼叫和 BDD 2007 組態檔 — Bootstrap.ini 和 CustomSettings.ini。資訊是收集和儲存成變數，以用於整個部署程序。在精簡式安裝的案例中，Bootstrap.ini 和 CustomSettings.ini 檔案可讓您預先定義所有資訊，如果不定義，就必須手動輸入將這些資訊收集至部署精靈。
能夠預先指定所有資訊，使得精簡式安裝精靈不用在建置階段擷取這些資訊，可讓您將整個精簡式安裝程序自動化，並在那些 SMS 2003 不支援的環境內也能採自動安裝方案。您可以選擇預先定義的資訊範例包括 ComputerName=RDG0001VST，用於指定 RDG0001VDT 的電腦名稱，或是 TimeZoneName=GMT Standard Time 用以確保電腦時區是設定為格林威治標準時間。使用 BDD 進行部署期間所有可用的屬性都詳細記載在一份組態參考資料中，網址是 technet.microsoft.com/library/bb490302.aspx。
如需有關設定和使用 BDD 2007 的詳細資訊，請參閱 2007 年 9 月號《TechNet Magazine》的＜使用 BDD 2007 部署 Windows Vista＞一文 (technetmagazine.com/issues/2007/09/BDD)。

BDD 與 SQL Server
為什麼 BDD 2007 要搭配資料庫？答案取決於您在部署期間如何動態地提供詳細資料，如果不提供這些詳細資料，就得透過精簡式安裝精靈手動輸入。我之前有提到，這可以使用 CustomSettings.ini 檔案來達成。問題在於，實際的部署中，這些詳細資料會隨著要部署的機器而改變。另外，如果您嘗試為 500 台不同的機器定義特定的選項和設定，CustomSettings.ini 檔案很快也會變得難以管理。透過連接一個後端資料庫到 BDD 主控台，您等於多了一個更方便管理的方案，不僅動態而且還可以擴充。
讓我們稍微談一下 SQL Server 如何與 BDD 2007 整合。首先，您必須確定部署伺服器上有安裝 SQL Server (最好是 SQL Server 2005 或之後的版本)。謝天謝地，在 BDD 2007 中建立資料庫的步驟很簡單：只要在 BDD 2007 Deployment Workbench 中的 [Database (資料庫)] 節點按一下右鍵，再按 [New (新增)]，然後遵循指示就行了 (見 [圖 2])。BDD 小組提供了完善的精靈，讓您能夠快速又輕鬆地動手操作。
[圖 2] BDD 2007 的部署資料庫組態
[圖 2] BDD 2007 的部署資料庫組態
資料庫一建成，就可以開始探索它的功能。資料庫內的項目主要分成四大類：電腦、角色、位置，以及廠牌和機型。每個類別都可讓您定義項目，而且針對每個定義的項目，您可填入 BDD 2007 變數，指派應用程式，以及提供其他索引鍵設定 (見 [圖 3])。
[圖 3] 指派部署屬性
[圖 3] 指派部署屬性
將這四種類別當做兩個不同的群組來看待蠻有幫助的。電腦、位置，以及廠牌和機型類別提供您不同的方法在建置階段識別電腦。每部已識別的電腦接著可與資料庫中的特定角色建立關聯，以針對特定目的加以佈建，例如用於銷售、行銷或財務目的等，而每個角色會確保相關的企業營運應用程式皆已安裝。
使用 [電腦] 區段依照 MAC 位址、資產標籤、通用唯一識別元 (UUID)，或序號來識別機器。因為這個區段中有可能會建立大量的項目，組織內的每部電腦各有一個項目，所以請在每個項目中只加入非常特定的屬性，例如 ComputerName。
使用 [位置] 區段針對組織周圍的特定地理位置來建立項目。每個項目可由該位置的預設閘道來識別。如果您在 Active Directory® 中有以位置為主的組織單位 (OU)，而且您希望將某位置建置的電腦加入與該位置相對應的 OU 中的網域，這就特別好用。
使用 [廠牌和機型] 區段為您的部署必須支援之各種硬體類型建立項目。BDD 2007 會將這些項目與透過 WMI 呼叫探索得到的資訊相比對。在開發環境中 [廠牌和機型] 區段一種常見的用途是，建立項目分別檢查「Microsoft Corporation」和「Virtual Machine」的 [廠牌和機型] 屬性來查看某機器是 Virtual PC 2007 或是 Virtual Server 2005 虛擬機器。您若是在建置階段找到這些屬性的符合項，便可以告訴 BDD 它需要在部署階段安裝 Virtual Machine Additions 應用程式，方法很簡單，只要將應用程式加入 [廠牌和機型] 項目就行了。
提供方法識別機器之後，便可使用 [角色] 區段為每個您想要佈建的部署角色建立項目。這類的範例包括透過將與 BDD 中定義的 Windows XP 或 Windows Vista 組建相對應的 BuildID 屬性加入每個項目，來設定 Windows XP 角色和 Windows Vista 角色的項目。另外一種方法是指定部門角色，例如會計、業務或財務。我通常是在這個區段填入大多數的 BDD 屬性 (時區、地區設定、組織資訊等)。這樣一來可盡可能減輕資料庫的管理工作，因為項目並沒有繫結到任何特定的機器、硬體或位置。
我們需要告知 BDD 2007 它應該在部署階段搜尋資料庫，尋找與它目前正在建置的電腦相符的任一項目。若要設定 BDD 讓它在部署期間使用資料庫，可在部署點上按一下滑鼠右鍵，然後按一下 [Configure DB (設定 DB))。這個動作會帶您完成一連串的精靈，它會以項目來填入 CustomSettings.ini 檔案，使精簡式安裝程序查詢資料庫以取得資訊。

讓您的部署可彈性調整
您現在已有一部部署伺服器可以自動化精簡式安裝，並動態地佈建每台機器，讓它們在特定的商務角色內運作。但要如何調整這套方案呢？
方案的架構是以中樞與支點 (hub-and-spoke) 拓樸為基礎，如 [圖 4] 所示。您設定的第一部部署伺服器將是中樞兼父系部署伺服器。而每個子系部署伺服器則將作為支點。
[圖 4] 中樞與支點部署架構
[圖 4] 中樞與支點部署架構
若要啟用此架構，您必須使用 DFS-R 將發佈共用複寫到每部部署伺服器。然後使用 SQL Server 快照集複寫將 BDD 部署資料庫的副本佈建到每部子系部署伺服器。這套方案的好處在於子系部署伺服器的需求很低 — 每台機器上只需要安裝 SQL Server Express、WDS 和 DFS-R 便可部署。
因為 BDD 2007 發佈共用中可能會存放大量資料，我規定使用 Windows Server 2003 R2 中的 DFS-R，而不使用舊版 Windows Server 中的檔案複寫服務。DFS-R 採用遠端差異壓縮 (Remote Differential Compression，RDC) ，只複寫在複寫群組成員之間的檔案差異 (delta) 變更。這在自訂映像檔中只做了微幅變更 (例如新增驅動程式) 時，會明顯影響複寫流量的多寡。使用 DFS-R，複寫流量只會等於所做變更的大小，而不是重新散佈整個映像檔。
Microsoft 網站上有豐富的 DFS 相關資訊，開始不妨先參考 microsoft.com/windowsserver2003/technologies/storage/dfs，我會在談到 BDD 部署的內容中解說基本安裝和設定步驟來提供整個程序的概觀。
請注意，如果您的伺服器執行的是以 Windows Server 2003 R2 以前的安裝版本為基礎的 Active Directory，可能需要更新 Active Direcotry 結構描述才能使用 DFS-R，因為複寫服務需要新的物件類別。如需有關在 Windows Server 2003 R2 中擴充 Active Directory 結構描述的完整細節，請參閱 go.microsoft.com/fwlink/?LinkId=99936。
第一步是將 DFS 元件安裝到 Windwos Server 2003 R2 部署伺服器上。要這麼做的方法有很多，其中一個最簡單的方法是使用標準 [新增/移除 Windows 元件] 精靈。這一步完成後，您需要使用 DFS 管理主控台設定複寫群組，如 [圖 5] 所示。
[圖 5] DFS 管理主控台
[圖 5] DFS 管理主控台
若要將 BDD 2007 部署方案向外延展，需要複寫兩個特定的資料夾。第一個是 BDD 2007 發佈共用，當中保存了所有的 BDD 原始檔和組態檔。您必須將這些檔案提供給每部部署伺服器使用。
第二個要複寫的資料夾是 WDS 用來保存 LiteTouch_x86.wim 檔案的 [Boot] 資料夾。這是 BDD 開機環境，由 WDS 提供給您的桌上型電腦用戶端機器以開始部署程序。您必須複寫這個檔案，以便當父系部署伺服器上的開機環境產生變更時，將變更複寫到部署基礎結構的其餘部分。
複寫的路徑是 X:\Distribution (當中 X 是在 BDD 2007 安裝階段指定的磁碟機代號) 和 Y:\RemoteInstall\boot (當中 Y 是保存 WDS RemoteInstall 共用之磁碟區的磁碟機代號)。
DFS-R 是多重主機複寫，因此不可能建立單向複寫拓樸。有鑑於此，為了集中管理發佈共用，請將每部子系部署伺服器上的發佈共用設定為唯讀。這將只允許 DFS-R 複寫寫入資料夾中 (因為它使用的是備份和還原權限)。從這些子系伺服器建置而成的子系機器完全不需要寫入此資料夾，因此只需要授與每個帳戶讀取權限。
最後一個使用 DFS-R 完成複寫資料的組態步驟是設定 WDS 中的開機設定資料 (BCD) 存放區的重新整理原則。這可確保對開機環境所做的任何變更會反映到每部子系部署伺服器上。所有 WDS 伺服器上都必須設定這個組態變更，而且我建議將此建置到佈建部署伺服器的組建和組態程序中。
在每部部署伺服器上，請執行下列命令：
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
重新整理的時段將視您在部署伺服器上重新整理資料有多頻繁而定。如果您將 DFS-R 設定成每個小時進行複寫，那麼理當將 BCD 存放區重新整理原則設定成每 60 分鐘進行重新整理。

SQL Server 複寫
到目前為止，您已將 BDD 2007 向外延展，從主要部署伺服器複寫 BDD 發佈共用和 WDS 開機映像到每部子系部署伺服器。您現在需要完成整個程序，然後複寫 BDD 2007 Deployment Workbench 資料庫，讓每部部署伺服器可從本機使用它。
產品說明文件形容 SQL Server 採用的複寫方法幾乎就跟發行雜誌一樣。就雜誌而言，會有出版商 (publisher) 製作雜誌，有配銷商 (distributor) 為出版商散發雜誌，還有訂閱者 (subscriber) 訂購和收取雜誌。SQL Server 的內建複寫功能也使用相同的英文術語。
不過要注意的是，要成為 SQL Server 資料庫的發行者，伺服器不能執行 SQL Server Express Edition，它必須使用完整版的 SQL Server。對於主要部署伺服器，我使用 SQL Server 2005 (不過 SQL Server 2000 也有支援)。而對於每部子系部署伺服器，您可以使用 SQL Server 2005 或 SQL Server 2005 Express。
開始設定 SQL Server 複寫之前，有幾個您應該先完成的步驟，以確保 SQL Server 的設定正確以便支援複寫。當佈建部署伺服器時，請確定安裝 SQL Server 2005 或 SQL Server 2005 Express Edition 期間已包含複寫元件。SQL Server Express 在預設的情況下並不會安裝複寫元件。
接下來，需要在 SQL Server 中啟用遠端連線，才能允許精簡式安裝從遠端開機環境連線到 SQL Server。若要設定 SQL Server 進行遠端連線，請啟動 SQL Server 介面區組態工具，選取 [服務和連接的介面區組態]，然後設定伺服器來接受 TCP/IP 和具名管道的本機和遠端連線。
接下來，在主要部署伺服器上，建立一個共用資料夾來保存複寫快照集資料，供每部子系部署伺服器上的複寫代理程式讀取。我之後會將這稱為共用資料夾。我通常是把這個資料夾與其餘部署內容放在同一個磁碟區上。
如果子系部署伺服器上安裝的是 SQL Server Express Edition，將需要最後的設定步驟。SQL Server Browser 服務在預設的情況下是停用的。若要允許複寫，必須將此服務設定為自動或啟動。請使用 SQL Server 組態管理員工具來設定此服務。您還必須在要接受這些複寫內容的子系伺服器上先建立資料庫。請將資料庫名稱跟主要部署伺服器上的 BDD 2007 資料庫名稱保持一致，這樣一來就不需要進行額外的組態。

設定複寫
您現在可以開始設定 SQL Server 複寫。請從主要部署伺服器開始著手，它應該是執行完整版的 SQL Server 2005，啟動 SQL Server Management Studio。第一步是建立和設定散發。方法是，巡覽至管理主控台的 [複寫] 資料夾，如 [圖 6] 所示。在 [複寫] 資料夾上按一下滑鼠右鍵，然後選取 [設定散發] 來啟動散發精靈。
[圖 6] SQL Server Management Studio：複寫
[圖 6] SQL Server Management Studio：複寫
在精靈中，確定主要部署伺服器應該是作為自己的散發者。將開機快照集資料夾設定成之前建立的 SQL Server 複寫共用的 UNC 路徑。最後，將主要部署伺服器設定成發行者。
當精靈順利將伺服器設定成發行者和散發者後，您必須告訴 SQL Server 要發行哪個資料庫。方法是，以滑鼠右鍵按一下 [複寫] 資料夾，然後按一下 [發行者內容]。在內容對話方塊中，選取 [發行集資料庫]，然後選擇您的 BDD 2007 資料庫進行交易式複寫，如 [圖 7] 所示。您實際上並不是使用交易式複寫，但無論您的用意是快照集或是交易式複寫，都是選取這個選項。
[圖 7] 發行資料庫
[圖 7] 發行資料庫
您現在必須建立一個發行集，供子系部署伺服器訂閱。在 [複寫] 資料夾中，以滑鼠右鍵按一下 [本機發行集]，然後選取 [設定散發] 來啟動散發精靈。選取 BDD 資料庫作為要發行的資料庫。選取快照集複寫作為發行類型，並指定要複寫所有的資料表、預存程序和檢視。您應該選擇立即建立初始快照集。排程快照集代理程式時，除非您打算經常對資料庫進行變更，否則預設一天執行一次應該就綽綽有餘。
最後一步是讓子系部署伺服器訂閱此發行集。這會告訴 SQL Server 在指定的間隔將資料庫的副本發送到每部子系部署伺服器。在 [複寫] 資料夾的 [本機發行集] 子資料夾下，找出剛剛建立的發行集，以滑鼠右鍵按一下，然後選取 [新增訂閱] 來啟動訂閱精靈。在此精靈中，選取您在上個步驟建立的 BDD 發行集作為選定的發行集。選擇在散發時執行所有代理程式，讓複寫拓樸成為發送訂閱。然後將每部子系部署伺服器新增成訂閱者，並提名您在每部伺服器上建立的資料庫來接收複寫資料的副本 (請記住，這個資料庫的名稱應該跟主要部署資料庫相同)。最後，設定要用於進行連線的帳戶，並定義要用於複寫的排程。這應該與您為快照集代理程式選擇的排程相對映。這個快速導覽說明了讓 SQL Server 複寫順利運作所應該進行的步驟。您應該馬上就可以看到資料開始進行複寫！

設定 BDD 2007
到目前為止，您設定了 BDD 2007 讓它使用資料庫，並將資料庫和 BDD 2007 發佈共用複寫到子系部署伺服器。若要完成部署方案，您必須設定 BDD 2007，如此一來，當用戶端下載 BDD 開機環境時，它便可自動連線到屬於其本機部署伺服器的任一伺服器。
當您開機進入精簡式 Windows PE 環境時，若用戶端是從 WDS 伺服器開機的話，Windows PE 中便會設定一個登錄值，來存放用戶端剛剛從中下載開機環境的伺服器名稱。初始 BDD 2007 部署指令碼會取得這個值，然後把它存放到一個稱為 %WDSServer% 的環境變數中。
要注意的是，如果您是使用初版的 BDD 2007，可能會發現這個值在 Windows PE 登錄中並沒有適當填入。您可從 support.microsoft.com/kb/937191 取得更新來修正此行為。
若要設定 BDD 2007，只要編輯 BootStrap.ini 和 CustomSettings.ini 組態檔，以 %WDSServer% 取代部署伺服器的任何參考即可。這通常牽涉到連同取代 SQL Server 執行個體名稱的值和 DeploymentRoot (亦即保存發佈共用的伺服器) 的值。在 [圖 8] 和 [圖 9] 中顯示了範例 Bootstrp.ini 和 CustomSettings.ini 檔案的摘要內容。
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 Bootstrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
請注意這套方案規定將 WDS 與 BDD 2007 複寫資料庫和 BDD 2007 複寫發佈共用放在同一部伺服器上。理由應該很明顯：它可讓您使用 %WDSServer% 變數來提供簡單的保全方法，告知用戶端機器其本機部署伺服器的所在位置，並防止它跨 WAN 回頭進行交談。

其他考量事項
BDD 2007 的好處在於您可以擴充它，所以擴充此方案時有許多層面可考量。舉例來說，您可以使用內建功能來監視 SQL Server 和 DFS-R，設計各種方法使用資產管理資料庫的資訊來填入環境內的各部電腦，甚或是使用 SQL Server 預存程序來擷取這類資訊。遺憾的是，本文的篇幅不夠，不過希望您已從中窺探出一些在自己的組織中統馭 BDD 功能的方法。

Adam Shepherd 是在英國服務於微軟顧問服務 (Microsoft Consulting Services) 的顧問。Adam 的技術專長著重於部署、維護和管理 Windows 用戶端。您可以透過電子郵件地址 adamshep@microsoft.com 與 Adam 連絡。


 通訊: Microsoft 內部的 Exchange Edge Transport Server：第二篇
通訊 Kay Unkroth

Microsoft 內部的 Exchange Edge Transport Server：第二篇
摘要:
  • 使用 Edge Transport 記錄與追蹤
  • 使用指令碼進行反垃圾郵件設定
  • 測試典型垃圾郵件案例
下載本文程式碼: Edge2007_11.exe (161KB)

網際網路上的垃圾郵件和其他惡意資料氾濫，要怎麼確保為組織中的使用者提供安全可靠的傳訊服務？正如上個月我在本專欄系列的第一篇所述，其中一個方法是將
Exchange Server 2007 Edge Transport Server 和 Forefront Security for Exchange Server 部署在介於網際網路與生產環境之間的周邊網路。
本篇是這個雙部曲專欄的下篇，在此我會說明如何使用 Exchange Server 2007 的標準代理程式的記錄和追蹤功能來分析 Edge Transport 代理程式使用狀況。我也將使用自訂方法，從傳輸管線傾印所有事件物件到 XML 檔案。接著，我會講解如何將反垃圾郵件設定應用在 Edge Transport 測試實驗室，這也是 Microsoft 在自身企業生產環境中所採用的設定方式。最後在文末我會提出一些真實且有趣的測試案例，示範 Edge Transport 代理程式如何回應各種垃圾郵件狀況。
如需 Edge Transport 測試實驗室安裝作業與一般 Edge Transport 架構的詳細資訊，請參閱 2007 年 10 月號《TechNet Magazine》中本系列專欄的第一篇文章，網址是 technetmagazine.com/issues/2007/10/Edge。
我使用了大量的指令碼及批次檔將最重要的組態工作自動化，這些指令碼可以從本文隨附的程式碼下載中取得 (請至：technetmagazine.com/code07.aspx)。另外，如需有關 Edge Transport 代理程式的 Microsoft IT 組態的詳細背景資訊，我推薦專為 Microsoft IT 百寶箱所撰寫的＜Microsoft® Exchange Server 2007 Edge Transport 和傳訊保護＞技術白皮書。這份 IT 百寶箱白皮書可從以下網址下載：microsoft.com/technet/itshowcase/content/edgetransport.mspx。

記錄和追蹤
Exchange Server 2007 包含幾項記錄和追蹤功能，其中包括通訊協定記錄、代理程式記錄和管線追蹤，這些功能可輔助傳輸代理程式問題的診斷及疑難排解。雖然在本文中我並未實際針對傳輸代理程式進行疑難排解，但是這些記錄和追蹤資訊對於檢驗 Edge Transport 代理程式的運作情況很十分實用。
要追蹤 SMTP 傳送與接收活動的相關資訊，您應啟用傳送與接收連接器的通訊協定記錄功能。利用在本專欄系列的第一篇中設定的測試環境 (見 [圖 1])，我在 New-SendConnector 與 New-ReceiveConnector Cmdlet 中進行下列設定來啟用通訊協定記錄：
[圖 1] 測試環境
[圖 1] 測試環境
–ProtocolLoggingLevel: Verbose
您會發現，在預設情況下，產生的 SMTP 記錄檔會放入 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog 底下的子資料夾。
要分析 SMTP 交談，通訊協定記錄是很好用的功能，但是反垃圾郵件代理程式不一定會妨礙 SMTP 工作階段。譬如說，內容篩選器可能只會對輸入郵件加上包含垃圾郵件信賴等級 (SCL) 值的戳記。只要 SCL 分級低於特定閾值 (預設為 7)，內容篩選器便不會讓 Edge Transport 作業拒絕該郵件。如此一來，SMTP 交談便可以順利進行。
要分析反垃圾郵件代理程式 (連線篩選、內容篩選、Edge 規則、收件者篩選、寄件者篩選和寄件者識別碼) 是如何在通過傳輸管線的郵件上運作，必須查看代理程式記錄而非通訊協定記錄。根據 EdgeTransport.exe.config 檔案中的 AgentLogEnabled 參數，代理程式記錄通常是啟用狀態。在預設情況下，代理程式記錄位於 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog 資料夾中。您可以使用記事本來開啟這些記錄，不過 Get-AgentLog 在 Exchange 管理命令介面中顯示的代理程式記錄資訊更直接易懂。
管線追蹤是另一項實用的功能，可用來針對特定寄件者，擷取當郵件通過傳輸管線時的訊息快照集。這個概念相對來說比較單純；Edge Transport 作業會在叫用登錄 OnEndOfHeaders、OnEndofData、OnSubmittedMessage 及 OnRoutedMessage 事件的 SMTP 接收及路由代理程式的前後建立各封郵件的快照集。藉由比較這些郵件快照集，就可以看出各個代理程式如何修改每個郵件。當然，在測試環境中啟用這項重要的功能是不容分說的。
以下的 Set-TransportServer Cmdlet 用法會啟動測試使用者的管線追蹤。正如您的預期，PipelineTracingEnable 參數設為 $true 可啟用管線追蹤。測試使用者的電子郵件地址設定在 PipelineTracingSenderAddress 參數中：
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
啟用管線追蹤後，您就會在 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots 資料夾中看見指定寄件者 (在本範例中為 Contoso.User@contoso.com) 每封個郵件的郵件快照集檔案 。這是預設資料夾。每個郵件的快照集檔案都分別放在一個子目錄中，而且子目錄是按指派給該郵件的 GUID 來命名。請注意，您可以在名為 Original.eml 的檔案中找到原始郵件，並在開頭為 SmtpReceive 或 Routing (視遇到的事件或安裝的代理程式而定) 的 .eml 檔案中找到郵件副本。要分析 SMTP 接收事件 OnEndofData 及 OnEndOfHeaders 登錄的反垃圾郵件代理程式的處理情形，請檢視 SmtpReceive*.eml 檔案。要分析防毒軟體以及路由事件 OnSubmittedMessage 及 OnRoutedMessage 登錄的其他代理程式的處理情形，則應分析 Routing*.eml 檔案。

自訂管線傾印
Exchange Server 2007 的標準代理程式記錄和追蹤功能可以滿足所有疑難排解需求，不過這些標準功能並未涵蓋所有傳輸事件。舉例來說，管線追蹤無法擷取有關 OnConnectEvent、OnEhloCommand、OnMailCommand、OnRcptCommand、OnDataCommand 等類似的傳輸事件相關資訊，因為傳送主機尚未傳輸任何可以寫入 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing 資料夾的郵件。 若要擷取有關這些事件的詳細資訊，您必須實作自訂代理程式，以便將事件資料傾印到檔案系統中的檔案內。
正如我前一篇文章所述，建立自訂代理程式並不複雜，所以我忍不住建置了 SMTP 接收代理程式和路由代理程式，把傳輸管線的所有事件物件一股腦傾印到 XML 檔案中。在本文提供的下載中，您可以找到對應的 Microsoft Visual Studio® 2005 專案，名為 PipelineXMLDump。其中有兩個重要檔案，一個是實作代理程式工廠和代理程式的 DumpAgents.cs，另一個是實作協助程式類別，透過 System.Re- flection 方法將事件來源欄位和事件引數物件寫入 XML 檔案的 XMLDump.cs。如果您編譯原始程式碼並將產生的 PipelineXMLDump.dll 檔案複製到 Edge Transport 測試伺服器上名為 C:\PipelineXMLDump 的資料夾中，就可以使用 RegisterPipelineXMLDump.ps1 與 EnableDumpAgents.ps1 兩個指令碼來登錄和啟用自訂代理程式。這兩個指令碼包含在下載內容的 PipelineXMLDump 專案資料夾中。當然，我的自訂代理程式僅供說明，尚未經過充分測試，因此絕對不可安裝在生產環境中。您必須自行承擔使用這些代理程式的風險。
DumpAgents.cs 向您示範如何實作傳輸管線支援的所有 SMTP 接收和路由事件處理常式。如果您想要實作自己的自訂代理程式，這是一個不錯的起點。我的傾印代理程式會將 XML 檔案寫入 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump 底下的子資料夾中，這個子資料夾會呼應 SMTP 工作階段識別項 (SMTP 接收代理程式) 或郵件識別項 (路由代理程式)。[圖 2] 顯示傳送到 OnConnectEvent 處理常式中的 SMTP 接收代理程式的事件引數資訊範例。此範例顯示接受連入連線要求的本機 IP 端點 (IP 位址與連接埠)。
[圖 2] OnConnect 事件期間傾印的引數資訊
[圖 2] OnConnect 事件期間傾印的引數資訊

準備測試執行
有關記錄、追蹤和傾印的理論已經談得夠多了。讓我們準備進行幾個測試，來看看反垃圾郵件代理程式的運作情形。下面是簡短的流程描述，在您的測試環境中，這個流程會盡可能對映 Microsoft IT 組態。如前所述，＜Microsoft Exchange Server 2007 Edge Transport 和傳訊保護＞技術白皮書中提供相關的背景資訊。
一開始先執行附帶下載中的 EDGE01_disable_agents.ps1 指令碼來停用位址修正輸入、附件篩選和位址修正輸出等代理程式。位址修正沒有必要，因為收件者使用的內部與外部電子郵件地址都一樣。我不使用附件篩選代理程式是有原因的，因為 Forefront Security 提供了替代的附件篩選功能。
測試環境並未連線到網際網路，因此很難測試連線篩選代理程式。為了解決這個問題，您可以透過執行 INTERNET01_create_IP_block_list.bat 檔案在網際網路主機上建立 IP 封鎖清單。請確認您已經安裝 Windows® 支援工具，因為其中包含有 DNS 命令列工具 (dnscmd.exe)。否則，您就必須花時間使用 DNS 主控台來手動建立 DNS 記錄。
現在您可以執行 EDGE01_add_block_list_provider.ps1 指令碼來設定連線篩選代理程式。此指令碼會加入 ip-bl.consolidatedmessenger.com 的 IP 封鎖清單提供者。這是 Consolidated Messenger 的 IP 封鎖清單，而先前描述的 INTERNET01_create_IP_block_list.bat 檔案執行作業已經在測試環境中建立此 IP 封鎖清單。Microsoft IT 也使用本機 IP 封鎖清單和 IP 允許清單，不過這些功能不需要手動設定。要注意的是，Microsoft IT 並未使用 IP 允許清單提供者。
接下來，執行 EDGE01_recipient_filter.ps1 指令碼來設定收件者篩選代理程式，封鎖收件者不存在的郵件，以及封鎖傳送到僅供內部或輸出使用的信箱與全域通訊群組清單的郵件。
寄件者篩選代理程式也需要更新組態。Microsoft IT 使用寄件者篩選這個防範措施，對抗來自特定寄件者地址的郵件癱瘓攻擊，並封鎖判定與業務無關的特定清單伺服器與相似來源。Microsoft IT 更利用寄件者篩選機制來封鎖寄件者資訊無效或遺失的郵件。讓我們在 Edge Transport Server 上執行 EDGE01_sender_filter.ps1 指令碼，將這個組態套用到測試環境中。
如果想要對照 Microsoft IT 組態，您還需要在 DNS 中設定寄件者原則架構 (SPF) 記錄。若要產生 SPF 記錄，證明您的 Edge Transport Server 已授權您的網域 (adventure-works.com) 所寄出的郵件，您可以使用下列網址提供的 Microsoft 寄件者識別碼架構 SPF 記錄精靈 (Microsoft Sender ID Framework SPF Record Wizard)：microsoft.com/mscorp/safety/content/technologies/senderid/wizard。試用看看並指定現有的網際網路網域名稱。在測試環境中，您可以執行網際網路主機上的 INTERNET01_create_SPF_record.bat 檔案。
就這麼簡單！不用再設定其他參數，因為大多數代理程式的預設設定都適用。要快速瀏覽 Edge 規則、寄件者識別碼、通訊協定分析和內容篩選代理程式最重要的預設設定，請在 Edge Transport Server 上執行 EDGE01_check_defaults.ps1 指令碼。

運用 Edge Transport 代理程式
現在，讓我們將 Edge Transport 代理程式應用在幾個實際的傳訊案例中。為了傳送測試郵件到 Edge Transport Server，我使用 Windows Server 2003 和 Outlook® Express 內含的 SMTP 與 POP3 服務當做訊息用戶端並保留大部分的預設設定，不過請記得啟用記錄功能。
但是這裡得先警告讀者：如果您的測試環境與生產系統或網際網路有任何連線，千萬不要遵循本節內容執行任何步驟或指令碼。您必須自行承擔測試的風險。
我要測試的第一個代理程式是連線篩選代理程式。它理當第一個接受測試，因為連線篩選代理程式是 Edge Transport Server 上最辛勞的代理程式。在 Microsoft，連線篩選代理程式封鎖 88% 提交的網際網路郵件。以一般工作日來說，130 萬次提交嘗試中只有 15 萬是來自合法寄件者。
那麼，就讓我們以 Fabrikam.User@Fabrikam.com 的名義傳送電子郵件到 Administrator@adventure-works.com。如果一切順利，系統管理員應該不會收到此郵件。相反地，Fabrikam.User 應該會收到傳遞狀態通知 (DSN)，說明傳遞至收件者的作業已經失敗。Fabri- kam.User 檢查電子郵件地址正確無誤，重新傳送相同的郵件，而 Fabrikam.User 又再次收到 DSN。然後 Fabrikam.User 連絡支援工程師並報告此問題。Fabrikam.User 不是第一個遇到此問題的人。事實上，沒有任何 Fabrikam 員工可以再與 Adventure Works 通訊。情況不對勁，這個問題很緊急。您想要趕快解決這個問題，於是查看了 %systemroot%\system32\Logfiles\SMTPSVC1 資料夾中有關 INTERNET01 的 SMTP 記錄，正如 [圖 3] 中顯示的紅色文字，問題就在那兒！
Figure 3 SMTP 記錄讓問題現形 (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
從 550 錯誤回應得知，Consolidated Messenger 將您的網際網路主機的 IP 位址列在 IP 封鎖清單中。這也是情有可原。您連絡 Consolidated Messenger，希望從清單中移除。結果卻發現，登上 Consolidated Messenger 封鎖清單比從清單移除簡單多了。完整的移除作業需要花上數天甚至數週的時間。
您需要更快取得協助，因此經由電子郵件地址 cmipbl@adventure-works.com 連絡 Adventure Works。您以 Fabrikam.Admin@Fabrikam.com 的身分傳送電子郵件，說明目前的情況並要求解除封鎖您的主機的網際網路 IP 位址 (在本例中為 192.168.1.100)。在確認您的身分之後，Adventure Works 使用下列命令同意以臨時例外狀況的方式處理並藉此解除封鎖位址，此臨時例外狀況會在 30 後自動到期：
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
三十天的時間應該足夠您與 Consolidated Messenger 周旋，Adventure Works 也不需要花時間手動維護例外狀況了。藉由提供自動到期的例外狀況，Adventure Works 能夠盡量減輕系統管理員在維護 IP 允許清單方面的工作量。

安全寄件者
接下來，我們要測試內容篩選的安全寄件者認知，這個有趣的新功能可以提高垃圾郵件篩選的精準度。EdgeSync 從內部環境以雜湊及加密的形式將安全寄件者資訊傳播至 Edge Transport Server。內容篩選代理程式在篩選過程中使用此資訊來做出明智的抉擇。您只需要將安全寄件者資訊 (也就是安全寄件者清單、安全收件者清單、封鎖的寄件者清單及外部連絡人) 放入 Active Directory® 中就行了，方法是使用 Update-SafeList Cmdlet，接著使用 Start-EdgeSynchronization Cmdlet 來複寫資訊到 Edge Transport Server。Microsoft IT 會在非尖峰時段定期執行 Update-SafeList Cmdlet 排程。不過在我們的測試環境中，只要手動執行相對應的指令碼 (HUB-MBX-01_update_safelist.ps1) 就足夠了。
首先，在 Edge Transport Server 上執行 EDGE01_clean_up.ps1 指令碼來移除先前建立的 IP 允許清單項目，藉此整理測試環境。這是必要步驟，因為內容篩選代理程式不會處理來自此清單中的來源的郵件。下一步是執行網際網路主機上的 INTERNET01_clean_up.bat 檔案，從 Consolidated Messenger 封鎖清單移除 100.1.168.192.ip-bl.consolidatedmessenger.com 的 IP 封鎖清單項目。如同前面所述，要是不這麼做，模擬的網際網路主機就無法傳送郵件。
最後，傳送一封內容篩選代理程式幾乎可以確定是垃圾郵件的郵件。這裡有點棘手，因為內容篩選代理程式使用預設的 SCL 拒絕閾值來傳遞大部分的郵件給使用者，以降低誤判的機率。不過經過幾次測試，我發現某個郵件版本會讓 SCL 分級提升為拒絕等級。若要以 Contoso.User@Contoso.com 的身分傳送郵件，請在網際網路主機上執行 INTERNET01_contoso_msg.vbs 指令碼。
我的指令碼使用匿名 SMTP 連線來提交郵件到 INTERNET01 上的 SMTP 服務。若要讓它產生效果，您需要將 SMTP 服務設為轉接匿名使用者的郵件。在 IIS 管理員中，開啟預設 SMTP 虛擬伺服器的屬性。在 [存取] 索引標籤上，按一下 [轉送] 按鈕，接著選取 [下列清單以外的所有項目]。稍後我會說明這項設定的含意。
當您執行指令碼以傳送郵件時，Contoso.User 應該會收到說明傳遞失敗的 DSN：診斷代碼：smtp;550 5.7.1 由於內容限制，因此郵件遭拒。在網際網路主機的 SMTP 記錄中也可以看到這個回應內容，如果您在 Edge Transport Server 上執行命令 Get-AgentLog | Select-Object -Last 1 來顯示代理程式記錄的最後一個項目，應該就會看到郵件遭拒的原因是它的 SCL 分級為 7，如 [圖 4] 所示。
[圖 4] 由於內容限制，因此郵件被封鎖
[圖 4] 由於內容限制，因此郵件被封鎖
不過，Contoso.User 並非濫發垃圾郵件者。在此案例中，郵件無法成功發送很可惜，不過 Contoso.User 通常可以與 Adventure Works 的收件者通訊。因此 Contoso.User 以另一封電子郵件通知系統管理員，告知其原始郵件被錯誤地封鎖。系統管理員知道 Contoso.User，而且為了確保垃圾郵件篩選未來不會再封鎖其郵件，因此系統管理員將 Contoso.User 新增到安全寄件者清單中。若要在 Office Outlook 2007 中執行這項作業，請在收到的 Contoso.User 郵件上按滑鼠右鍵，指向 [垃圾郵件]，然後按一下 [新增寄件者至安全的寄件者清單]。
Update-SafeList Cmdlet 會依照例行的間隔執行，以重新整理 Active Directory 中的安全清單資訊，而在下一次 Edge 同步處理之後，Contoso.User 便可以與系統管理員通訊，而不會發生誤判的情形。若要模擬這個程序，請執行 HUB-MBX-01_update_safelist.ps1 指令碼。
現在執行 INTERNET01_contoso_msg.vbs 指令碼來再次傳送 Contoso.User 郵件。然後使用命令 Get-AgentLog | Select-Object -Last 1 來查看 Edge Transport Server 上的代理程式記錄，在 ReasonData 底下您會看到現在已經略過了內容篩選，因此不會再誤判 Contoso.User 了！

垃圾郵件攻擊
我們現在來大鬧一場當做測試執行的結尾。相信您一定已經注意到，在上一個測試中，我將網際網路主機設定為開放式轉送，這樣會對濫發垃圾郵件者敞開大門。現在來看一下，要是 Spam.Sender@cohovineyards.com 發現此組態漏洞，趁機濫用主機傳送幾千封垃圾郵件到 Adventure Works，這時會發生什麼事。INTERNET01_spam_msg.vbs 指令碼只提交一個垃圾郵件，但是您可以編輯指令碼並變更 max_loop 值來產生更多垃圾郵件。
為了模擬垃圾郵件攻擊，我提交了 1,000 封郵件到我那台有安全漏洞的主機，以便轉送到 Edge Transport Server。SMTP 服務將每次輸出連線的郵件數量限制為 20，因此在 Edge Transport 上的通訊協定分析代理程式受夠並拒絕接收之前，SMTP 服務花了一些時間轉送出充足的垃圾郵件。
通訊協定分析代理程式會根據 SMTP 通訊協定分析和來自 Microsoft Update 的 IP 信譽更新來自動維護 IP 封鎖清單項目，藉此協助內容篩選代理程式。此時，SMTP 通訊協定分析攔截到垃圾郵件訊息。通訊協定分析代理程式追蹤每封郵件的 SCL 分級以計算出 SCL 平均值，並利用這個平均值來決定寄件者信譽等級 (SRL)。模擬垃圾郵件活動的過程中，隨著越來越多非法郵件抵達，網際網路主機的 SRL 會一直增加，直到超過 SRL 封鎖閾值為止。結果，主機在 24 小時後被加入 IP 封鎖清單，再也不會收到來自這個主機的垃圾郵件了！這是自動執行的作業，不需要任何系統管理員介入。
[圖 5] 顯示產生的 IP 封鎖清單項目以及郵件處理的相對變更。封鎖主機之前，Edge Transport Server 會先在 OnEndOfData 事件中拒絕每封垃圾郵件，因為這是根據 SCL 閾值而針對每封郵寄採取行動的內容篩選代理程式 (請參考 [圖 4])。郵件已提交但失敗。封鎖我的主機之後，連線篩選代理程式便會在 OnMailCommand 事件期間拒絕此連線。郵件就無法再送出。在郵件提交前中斷與濫發垃圾郵件者的連線可節省網路頻寬和處理資源。
[圖 5] 停止攻擊的網際網路主機
[圖 5] 停止攻擊的網際網路主機

其他測試
當然，還有許多其他代理程式功能與案例可以測試。譬如說，以 Blocked.User@Contoso.com 或 Blocked.User@Fabrikam.com 傳送郵件來測試寄件者篩選。您可以傳送郵件到 Blocked.User@adventure-works.com 來測試收件者篩選。您也可以使用 Telnet 來模擬不同垃圾郵件防堵間隔的目錄蒐集攻擊。Microsoft IT 在網際網路面向接收連接器上使用預設間隔為五秒進行 SMTP 5yz 回應，Microsoft IT 利用這段時間就足以遏止濫發垃圾郵件者的目錄蒐集攻擊。不過您可以使用 Set-ReceiveConnector Cmdlet 來套用各種不同的值，如 EDGE01_tarpitting.ps1 指令碼所示。
您也可以更進一步檢查管線追蹤針對來自 Contoso.User@Contoso.com 的郵件所建立的快照集檔案。查看防毒戳記，X-MS-Exchange-Organization-AVStamp-Mailbox:MSFTFF;1;0;0 0 0，Forefront Security 使用此防毒戳記將郵件標記為已掃描。Hub Transport Server 上的 Forefront Security 發現了此戳記包含最近版本資訊，就無須再次掃描這個郵件。如果您試圖在測試郵件中插入假的防毒戳記來愚弄 Forefront Security，就會看到標頭防火牆開始採取行動，它會在 OnDataCommand 事件之後立即移除這些戳記，而且早在叫用 FSE 路由代理程式的 OnSubmittedMessage 事件觸發之前便會進行。
檢視快照集檔案中的郵件標題時，您或許應該為 Contoso.com 建立一筆 SPF 測試記錄，將錯誤 IP 位址誤認為合法寄件者。其中一種方法是在網際網路主機上執行 INTERNET01_wrong_SPF_record.bat 檔案。接著您應該以 Contoso.User@Contoso.com 身分傳送測試郵件，並檢查 X-MS-Exchange-Organization-SenderIdResult 和 Received-SPF 標頭：
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

結論
在我的本篇和上一篇文章中，您已經知道 Exchange Server 2007 Edge Transport Server 提供一套完整的傳輸代理程式，這套工具能夠實作可靠且精準度高的反垃圾郵件功能，其中包括連線篩選、通訊協定分析及內容篩選。此傳輸架構不但可加以擴充，而且還支援實作其他代理程式以加入附加功能。FSE 路由代理程式便是一個附加代理程式的好例子，它可將 Forefront Security for Exchange Server 整合到傳輸架構中。
與連線垃圾郵件防堵、標頭防火牆、TLS 與驗證等附加功能結合之後，Edge Transport Server 提供必要的手段在多個層級達到滴水不漏的高度通訊保護。藉由在周邊網路中部署 Edge Transport Server 和 Forefront Security，與您的內部 Exchange Server 組織完全分隔，您可以將大量的非法及惡意內容阻擋在您的郵件環境以外，並且傳遞誤判率極低的合法郵件給您的使用者。

Kay Unkroth 是一位企業家，曾擔任過支援工程師、系統開發人員、諮詢人員、訓練人員和作家等職，鑽研 Microsoft 伺服器技術長達 15 年以上。同時他也是專營管理文件與本土化服務之 Biblioso Corporation 的合夥創辦人暨董事長。


 網路功能: 使用 ISA Server 2006 來設定 VPN 遠端存取
網路功能 Alan Maddison

使用 ISA Server 2006 來設定 VPN 遠端存取
摘要:
  • VPN 通訊協定
  • 設定網站間 VPN 連線
  • 設定遠端存取 VPN 連線
  • ISA Server 2006 中的新功能

虛擬私人網路 (VPN) 提供高階的適應性、延展性，以及對網路連線的掌控能力。除了增強安全性之外，它們比
傳統的專用點對點連線更能省下大把的鈔票，而且它們極富彈性。
VPN 種類繁多，有些是用來連接行動使用者至公司網路，有些是用來連接位處異地的兩個網路。這些不同的 VPN 所使用的通訊協定，以及它們所提供的功能各異。有些提供安全性功能，例如驗證和加密，而有些可能連內建的安全性功能也沒有。不用說，有些設定和管理起來也比其他來得容易。
在本文中，我將探討您如何能夠使用 Internet Security and Acceleration (ISA) Server 2006 來實作 VPN。我的重點特別放在如何運用 ISA VPN 的功能來解決兩大常見的案例：一種是提供 VPN 遠端存取連線給使用者，另一種是提供網站間 VPN 連線。兩種實作都包含安全性功能，以確保資料私密性，同時為內部網路資源提供保護。
在第一個案例「遠端存取 VPN 連線」，遠端用戶端透過網際網路起始 VPN 連線連接到您的 ISA Server。ISA Server 接著將遠端用戶端連接到您的內部網路，讓使用者不間斷地存取內部網路資源，包括資料和應用程式。第二個案例「網站間 VPN 連線)比較複雜一點，因為它有用到路由器，此路由器有可能是 ISA 本身。但是此種連線可讓您將不同辦公室或分公司地點不間斷地彼此連接，或連接到中央辦公室。
使用 ISA Server 2006 來實作 VPN 還有其他幾項優點。其中一個最明顯的好處要歸功於 ISA Server 的整合功能，也就是說 VPN 功能與防火牆功能能夠攜手合作。此外，ISA Server 還提供 VPN 隔離功能，利用Windows Server® 2003 的網路存取隔離控制 (Network Access Quarantine Control) 功能來隔離遠端存取電腦，直到它的設定通過伺服器端指令碼的驗證為止。這無疑增添了另一層保護，因為它提供一種方法讓您先檢查遠端電腦上諸如防毒定義狀態和本機防火牆原則等項目，之後才允許它存取您的內部網路資源。
ISA Server 作為 VPN 方案所提供的主要管理優勢包括集中管理原則、監視、記錄和報告。對於日常的管理職責，這可說是無價的功能。尤其是即時監視和記錄檔篩選功能更能讓您深入洞察通過 ISA Server 的網路流量和連線。

VPN 通訊協定
ISA VPN 連線當中所採用的核心通道通訊協定為保障連線安全提供了第一道防線。ISA Server 支援三種通訊協定 — IPsec 上加第二層通道通訊協定 (L2TP)、點對點通道通訊協定 (PPTP)，以及 IPsec 通道模式。最後一種通訊協定只在網站間連線的情況下支援，而且主要是為了讓路由器與其他不支援 L2TP 或 PPTP 的作業系統交互操作。
L2TP 與 IPsec 搭配是因為 L2TP 自己並沒有提供資料私密性的機制。當與 IPsec 搭配使用時，它提供了穩固的驗證和加密方法，這樣的組合提供了陣容堅強的方案。PPTP 使用 Microsoft® Challenge Handshake 驗證通訊協定 (MS CHAP) 第 2 版或可延伸驗證通訊協定-傳輸層安全性 (EAP-TLS) 來進行驗證，以及使用 Microsoft 點對點加密 (MPPE) 來進行加密 (相信您也猜得到)。
組織該選擇 IPsec 上加 L2TP 還是 PPTP，往往取決於該組織相關的因素。IPec 上加 L2TP 可讓您使用較複雜且精緻的加密，它也支援比較多種的網路 (包括 IP、X.25、框架轉接和 ATM)。不過，PPTP 實作起來比較簡單，而且一般來說需求較少。換句話說，在沒有組織限制的情況下，實作 IPsec 上加 L2TP 被認為是最佳作法。

網站間 VPN 連線
ISA Server 2006 在簡化網站間 VPN 的設定方面有相當顯著的進展。在早期的版本中，牽涉的步驟相當地多。我將舉一個單一遠端站台的例子，它是使用 IPsec 上加 L2TP 連接到中央辦公室，兩個地點都有 ISA Server。整個程序要求您先設定中央辦公室 ISA Server 之後再設定遠端站台。
此程序的第一個步驟是設定本機使用者帳戶，兩邊的 ISA Server 都需要這麼做。此一使用者身份識別將在要進行的遠端或主要 ISA Server 連線下提供安全性內容。此帳戶的名稱應該與您在 ISA 管理主控台內建立的 VPN 連線名稱一致。譬如，作為良好的命名慣例，應該為位於總公司的 ISA Server (指向遠端站台) 取「Site VPN」的使用者名稱，為遠端 ISA Server 取名為「HQ VPN」。一旦建好這些帳戶，您需要存取帳戶屬性，開啟 [撥號] 索引標籤，然後確定已選取 [允許存取] 選項。
建立本機使用者帳戶之後，下一步是建立公開金鑰基礎結構 (PKI) 憑證，這將供兩個站台間進行驗證之用。您可以選擇使用預先共用金鑰，但使用憑證向來是較佳的方法。為 VPN 連線安裝憑證最簡單的方法是直接連接到您自己的企業憑證授權單位，並透過憑證伺服器的網站申請憑證。但是要這麼做，您可能必須建立存取規則，以允許 ISA Server 透過 HTTP 連線到憑證伺服器。
如果您熟悉舊版的 ISA Server，將會注意到 ISA Server 2006 介面 (如 [圖 1] 所示) 更為直覺化。當在左窗格選取 VPN 時，中間窗格和右窗格便會顯示即時相關設定和工作選項。
[圖 1] ISA Server 2006 具有更為直覺化的介面
[圖 1] ISA Server 2006 具有更為直覺化的介面
按一下右窗格中的 [建立 VPN 網站間連線] 來啟動網站間 VPN 精靈。當精靈啟動時，它會要求輸入網站間網路名稱，這個名稱應該與您稍早建立的使用者帳戶相符。輸入名稱後，按下 [下一步] 按鈕。在下一個畫面 (見 [圖 2])，選取要使用的 VPN 通訊協定 — 在我的範例中，這是 IPsec 上加 L2TP。按下 [下一步]，然後精靈會好心地警告您必須已存在與網路名稱相符的使用者帳戶 — 想必您已謹慎地這麼做了，所以只要按下 [確定] 前往下個畫面便可。
[圖 2] 選取要使用的 VPN 通訊協定
[圖 2] 選取要使用的 VPN 通訊協定
現在您必須建立 IP 位址集區。您在這裡有兩個選擇：您可以在 ISA Server 上建立靜態位址集區，或者您可以使用現有的 DHCP 伺服器來處理位址指派。既然兩種方法都可行，您應順著公司的程序來決定，因為它們跟這個特定的選項有密切的關聯。現在畫面會要求您輸入遠端伺服器名稱。輸入遠端伺服器的完整網域名稱 (FQDN)，然後輸入使用者認證以進行連線。請記住，您必須輸入您在遠端 ISA Server 上建立的使用者帳戶資訊。在此處的範例，這應該是使用者帳戶 HQ VPN，如 [圖 3] 所示。
[圖 3] 輸入遠端伺服器的 FQDN
[圖 3] 輸入遠端伺服器的 FQDN
在下一個畫面，選取傳出驗證方法 (前面有提到，使用憑證向來是較佳的方法)。接著，輸入在遠端站台的內部網路上使用的 IP 位址範圍。
這之後，如果您是使用 ISA Server 2006 Enterprise Edition，精靈將讓您設定遠端站台的網路負載平衡固定 IP 位址。如果您使用的是 ISA Server 2006 Standard Edition，請跳過負載平衡的步驟，直接繼續下個畫面 (見 [圖 4])，在這裡您可以建立用於將流量從遠端站台路由至區域網路的網路規則。
[圖 4] 建立路由流量的網路規則
[圖 4] 建立路由流量的網路規則
程序的下一步是建立存取規則。當設定存取規則時，有三個選項可允許使用通訊協定 — 您可以選擇允許所有的輸出流量，除了特定通訊協定之外允許所有的輸出流量，或者只允許特定的通訊協定。在大多數的情況下，您應該選擇所有輸出流量選項。
步驟就快完成了，精靈在此時會呈現您的設定的摘要，網站間 VPN 連線會在您一按下 [完成] 按鈕後馬上建立。您會看到一個對話方塊，當中會指出進行憑證撤銷清單下載需要啟用系統原則規則 — 按下 [是] 來啟用此規則。精靈接著會提供任何其他可能必要的設定步驟的相關資訊。完成設定主要站台的 ISA Server 後，您必須遵循相同的步驟來設定遠端站台。兩邊的步驟都完成後，兩個站台的使用者便能夠跨 VPN 進行通訊。

遠端存取 VPN 連線
設定用於用戶端存取的遠端存取 VPN 連線要簡單得多 (見 [圖 5])。第一個步驟是在 ISA Server 管理主控台的左窗格選取 VPN。接著在右窗格中選取 [啟用 VPN 用戶端存取] 工作。您會收到一則警告，表示這可能會造成路由及遠端存取服務重新啟動 (既然這可能會引起連線問題，您應當考慮在排定的維護期間來實作此項變更)。按一下 [確定] 關閉此警告，ISA Server 會啟用一條系統原則允許 VPN 用戶端流量存取 ISA Server。您可以在 ISA Server 管理主控台中選取 [防火牆原則]，然後選取 [顯示系統原則規則] 工作來檢視此規則。
[圖 5] 設定遠端存取 VPN 連線
[圖 5] 設定遠端存取 VPN 連線
另外還會啟用一條預設的網路規則，以允許在內部網路和兩個 VPN 網路 (VPN 用戶端和隔離的 VPN 用戶端) 之間進行路由。您可以在左窗格選取 [網路]，然後開啟中間窗格中的 [網路規則] 索引標籤來檢視和編輯這條網路規則。
現在您必須設定 VPN 用戶端存取，另外有三個參數需要設定：受到許可存取的 Windows 安全性群組，用戶端可使用的通訊協定，以及使用者對應。[圖 6] 顯示了設定這些參數的對話方塊。
[圖 6] 設定 VPN 用戶端存取
[圖 6] 設定 VPN 用戶端存取
在 [群組] 索引標籤中，您只需要選取哪個 Windows 群組應該獲得允許透過 VPN 進行遠端存取。從管理的觀點看來，我認為針對要授與的權限建立一個群組是個不錯的主意。這樣一來遠端存取管理起來就很得心應手。
[通訊協定] 索引標籤顯示只有預設已啟用的 PPTP。如果您的環境許可的話，肯定應該啟用 IPsec 上加 L2TP。
[使用者對應] 可讓您將命名空間的使用者帳戶，例如遠端驗證撥入使用者服務 (RADIUS)，對應到 Windows 帳戶，藉以確保存取原則已正確套用。一旦完成這些設定選項並將變更套用至 ISA Server 後，就大功告成了。用戶端現在應該能夠使用 VPN 連線不間斷地存取您的內部網路資料和應用程式。

ISA Server 2006 的增強功能
ISA Server 2006 加入了許多增強功能，使它的威力和效能比過去版本更優異。這些功能 — 包括 HTTP 壓縮、背景智慧型傳送服務 (BITS) 支援，以及服務品質 (QoS) — 提供了各種最佳化網路使用的方法。不用說，即使有了這些方法，您還是應該繼續使用標準的頻寬最佳化技術，包括快取在內，因為這是 ISA Server 的核心。
Microsoft 的不同產品支援 HTTP 壓縮由來已久 — 它自 Internet Explorer® 第 4 版，還有 Windows Server 自 Windows® 2000 以來就已存在。然而，這是第一個支援 HTTP 壓縮還有業界標準 GZIP 和 Deflate 演算法的 ISA Server 版本。
這有什麼意義嗎？有了 HTTP 壓縮的支援，遵守 HTTP 1.1 的網頁瀏覽器就可以從任何網站要求壓縮的內容。不過要記住，只有回應才會壓縮，用戶端發出的初次連出連線並不會壓縮。
HTTP 壓縮是一種全域 HTTP 原則設定，它會套用於通過 ISA Server 的所有 HTTP 流量，與跟特定網路規則產生關聯恰恰相反。不過，您倒是可以選擇依每個接聽程式來實作 HTTP 壓縮，而這是透過網頁接聽程式來設定。
HTTP 壓縮可透過左窗格的 [一般] 選項來存取，而且預設是啟用的。但是如 [圖 7] 所示，您必須設定要使用壓縮的網路元素。讓我們回到網站間 VPN 的範例，您必須選取 [傳回壓縮資料] 索引標籤，然後新增您稍早建立的 [Site VPN] 網路元素。您在這裡還可以選擇設定要壓縮的內容類型。ISA Server 2006 隨附許多標準內容類型，不過您可以透過 [工具箱] 索引標籤上的 [防火牆原則] 工作窗格來新增自訂內容類型。請記住，[傳回壓縮資料] 索引標籤指的是 ISA Server 會在資料傳回用戶端之前進行壓縮。為了讓 ISA Server 要求網頁伺服器在資料傳給 ISA Server 之前處理資料的壓縮，您必須使用 [要求壓縮資料] 索引標籤。
[圖 7] 設定 HTTP 壓縮
[圖 7] 設定 HTTP 壓縮
背景智慧型傳送系統是用於 HTTP 和 HTTPS 流量的非同步檔案傳輸服務。Windows Server 2003 包含 BITS 1.5 版，它支援下載和上載，不過上載還需要 Internet Information Services (IIS) 5.0 版或更新的版本。為智慧型檔案傳輸服務的 BITS，不但能夠分析網路流量，而且只會使用您網路頻寬的閒置部分。此外，檔案傳輸更是動態的，而且 BITS 還會藉著調節恢復到它的網路使用量，以正常的網路流量來回應尖峰 (Spike)。此點優勢是，BITS 可確保大型檔案的下載和上載不會對其他網路使用造成負面的衝擊。從系統管理員的觀點來看，這表示抱怨網路效能不佳的電話應該會減少許多。這是好消息！
BITS 還提供其他可改善使用者經驗，以及提升網路效能的優點。舉例來說，使用 BITS 的檔案傳輸是二進位，表示 BITS 可恢復因網路中斷這類的因素而遭中斷的檔案傳輸 (而不需要從頭開始重來)。另外，ISA Server 2006 也包含了對 Microsoft Update 快取功能的內建支援，它使用 BITS 快取來最佳化更新。
差異服務 (DiffServ) 通訊協定可針對 HTTP 和 HTTPS 流量提供封包優先處理 (或 QoS)。也就是說，視您的 ISA Server 設定而定，某些流量會優先處理。這在因流量或網路連線速度而造成頻寬有限的網路上很有用。根據網際網路工程任務推動小組 (Internet Engineering Task Force，IETF)，DiffServ 是以類別為基礎的流量管理機制。因此，DiffServ 可以區別流量類型，並適當加以管理，進而確保高優先順序的流量獲得優先處理。
為了提供這項功能，ISA Server 與支援 QoS 的路由器結合運作。很重要的一點是，如果您希望封包以相同的優先順序路由，應確保 ISA Server DiffServ 位元組與路由器上的優先順序相符。
因為在 ISA Server 中實作這類封包優先順序是一種全域 HTTP 原則設定，它會套用到使用 DiffServ 網頁篩選器通過 ISA Server 2006 的所有 HTTP 流量。這表示 ISA Server 並不支援 DiffServ 用於其他通訊協定，而且事實上，可能會將非 HTTP 流量上既有的 DiffServ 位元組移除。
如 [圖 8] 所示，DiffServ 是實作成網頁篩選器，而且可以透過選取左窗格中的 [增益集] 來存取。因為 ISA Server 需要在處理時偵查要求/回應的大小，所以請勿變更預設設定或 DiffServ 篩選器的優先順序。
[圖 8] 檢視 DiffServ 網頁篩選器
[圖 8] 檢視 DiffServ 網頁篩選器
如果您仔細看一下 [圖 8]，可能會注意到 DiffServ 篩選器預設並沒有啟用。若要啟用此篩選器，只要在 [工作] 窗格選取 [啟用選取的篩選器]，然後設定篩選器即可。由於 ISA Server 中的 DiffServ 封包優先處理是以特定 URL 或網域為依據，因此您必須將這項資訊加入 DiffServ 喜好設定中。方法是在管理主控台的左窗格選取 [一般] 索引標籤，然後在 [全域 HTTP 原則設定] 下，選取 [指定差異服務 (DiffServ) 喜好設定]。當指定這些喜好設定時，必須定義優先順序，以及應該優先處理的 URL 和網域。ISA Server 2006 提供強大的新功能，來建立 VPN 用戶端的遠端存取或網站間 VPN 設定。考慮要實作哪種 VPN 方案時，應該以它為優先考量。

Alan Maddison 是 MTI Technology Corporation 在 Microsoft 技術實習方面的一名資深顧問。他主要專精於 Active Directory、Exchange Server 和虛擬化技術。


 SQL Server: 最佳化 SQL Server 查詢效能
SQL Server Maciej Pilecki

最佳化 SQL Server 查詢效能
摘要:
  • 分析執行計畫
  • 最佳化查詢
  • 識別要微調的查詢

將資料庫伺服器最佳化不能少的就是微調個別查詢的效能。這跟微調伺服器安裝其他會影響效能的層面 (例如硬體和軟體組態) 一樣重要，甚至可能還要重要。
即使資料庫伺服器是在功能最強大的硬體上執行，它的效能還是可能因少數幾個不當的查詢而受到不良的影響。事實上，只要有一個錯誤的查詢 (又稱為「失控的查詢」)，就可能導致資料庫產生嚴重的效能問題。
反過來說，藉由微調一組佔用最多資源或最常執行的查詢，就能大幅提升資料庫的整體效能。我將在本文中探討一些技巧，讓您用來識別和微調伺服器上佔用最多資源和效能最差的查詢。

分析執行計畫
微調個別的查詢的第一步通常是了解查詢的執行計畫。執行計畫當中描述 SQL ServerTM 為了履行查詢和產生所要的結果集而執行的實體和邏輯作業順序。執行計畫是由一個稱為查詢最佳化工具的資料庫引擎元件，在處理查詢的最佳化階段內所產生的，這考量的因素有很多，例如查詢當中所用的搜尋述詞、牽涉的資料表及它們的聯結條件、傳回的資料行清單，以及是否有實用的索引可用作為資料的有效存取路徑等。
複雜的查詢可能有相當多的排列組合，因此查詢最佳化工具並不會評估所有的可能性，而是嘗試找出對於指定查詢來說「夠好」的計畫。這是因為尋找完美的計畫不一定永遠可行，即便可行，評估所有可能性來找出完美計畫的成本可能比所獲得的效能效益還高。從 DBA 的觀點看來，重要的是了解整個流程及當中的限制。
擷取查詢的執行計畫的方法有很多：
  • Management Studio 提供顯示實際執行計畫和顯示估計執行計畫等功能，這會以圖形的方式來呈現計畫。這些功能最適合用於直接檢視，而且是目前顯示和分析執行計畫最常使用的方法 (在本文中，我將採用以這種方式產生的圖形計畫來解說我的範例)。
  • 不同的 SET 選項，如 SHOWPLAN_XML 和 SHOWPLAN_ALL，會以 XML 文件或資料集的形式傳回執行計畫，前者是使用特殊的結構描述來描述計畫，而後者則會針對執行計畫中的各項作業提供文字說明。
  • SQL Server Profiler 事件類別，例如 Showplan XML，可讓您針對追蹤所收集的陳述式來收集執行計畫。
雖然以 XML 的格式表示的執行計畫可能不容易閱讀，但這個選項倒是可讓您撰寫程序和公用程式來分析執行計畫，以尋找效能問題的症狀以及較不理想的計畫。XML 表示也可以存成 .sqlplan 副檔名的檔案，然後在 Management Studio 中開啟來產生圖形表示。您還可以將這些檔案儲存起來供稍後分析之用，這樣一來，就不用在每次想要進行分析時重新產生執行計畫。這在您想要比較計畫來查看它們隨著時間的變動時尤其好用。

執行的估計成本
關於執行計畫，您必知的第一件事是它們是怎麼產生的。SQL Server 是採用以成本為基礎的查詢最佳化工具 — 也就是說，它會試圖產生估計成本最低的執行計畫。估計值是趁著最佳化工具評估查詢中所牽涉的每個資料表時，根據提供給最佳化工具的資料散佈統計資料得來的。如果漏掉該些統計資料，或是統計資料過時，查詢最佳化工具就缺乏重要的資訊來進行查詢最佳化程序，因而可能產生錯誤的估計值。在這種情況下，最佳化工具會高估或低估不同計畫的執行成本，而選擇不盡理想的計畫。
關於估計的執行成本有些常見的錯誤假設，特別是，人們往往假設估計的執行成本能夠清楚指出查詢要花多少時間執行，以為這樣的估計可讓您判別計畫是好是壞。這是錯誤的想法，首先，估計成本是用什麼單位來表示，還有它們與執行的時間有沒有直接的關聯都記載得很清楚。其次，既然這是估計，就表示並不一定正確，因此就 CPU、I/O 和執行時間而言，具有較高估計成本的計畫雖然有較高的估計值，有時候反而比較有效率。這種情況常常發生在牽涉資料表變數的查詢 — 因為資料表變數沒有可用的統計資料，所以即使資料表變數包含許多資料列，查詢最佳化工具總是假設資料表變數只包含一個資料列。結果，查詢最佳化工具將根據錯誤的估計來選擇計畫。因此，當比較查詢的執行計畫時，不應單獨仰賴估計的查詢成本。反而應將 STATISTICS I/O 和 STATISTICS TIME 選項的輸出包含在分析當中，以利了解 I/O 和 CPU 時間上的實際執行成本為何。
這裡有個特殊的執行計畫特別值得一提，它叫做平行計畫。如果您在含有一個 CPU 以上的伺服器上執行查詢，且該查詢可進行平行處理，那麼就可選擇平行計畫 (一般來說，查詢最佳化工具只會在查詢的成本超過特定可設定的閾值時才會考慮採納平行計畫)。因為管理多個執行的平行執行緒 (表示將工作分攤給不同執行緒，執行同步處理，以及收集結果) 會有額外的負荷，所以平行計畫的執行成本較高，而且這會反映在它們的估計成本上。那麼為什麼不選擇較便宜的非平行計畫呢？這都要拜使用多 CPU 的處理威力所賜，平行計畫產生結果的速度比標準計畫要來得快。視您特定的案例而定，將這類變數包括作為可用資源以及其他查詢的同時負載，這種計畫可能蠻適合您的情況。若是如此，您應該控制哪些查詢可以產生平行計畫，還有每個查詢可利用多少 CPU。要這麼做，您可以在伺服器層級上設定最大程度的平行處理選項，並在必要時在個別的查詢層級以 OPTION (MAXDOP n) 將它覆寫。

分析執行計畫
我現在要來探討一個簡單的查詢，包括它的執行計畫，還有提升它的效能的一些方法。假設我是使用 Management Studio 來執行此查詢，並在 SQL Server 2005 上的 Adventure Works 範例資料庫中開啟了 [包含實際執行計畫] 選項。
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
結果，我看到 [圖 1] 中所述的執行計畫。這個範例查詢會計算 Adventure Works 每位客戶所下的訂單總數。看一下執行計畫，便可以看出資料庫引擎是怎麼處理查詢和產生結果的。圖形執行計畫的閱讀方式是從上到下，從右到左。每個圖示都表示一項已執行的邏輯和實體作業，而箭號顯示出作業之間的資料流向。箭號的厚度表示作業之間傳遞的資料列數量 — 箭號越厚，表示牽涉的資料列越多。如果您將指標放到其中一個運算子圖示上，會有一個黃色的工具提示 (如 [圖 2] 中所示) 顯示該特定作業的詳細資料。
[圖 1] 範例執行計畫
[圖 1] 範例執行計畫
[圖 2] 作業的相關詳細資料
[圖 2] 作業的相關詳細資料
看看每個運算子，便可分析執行的步驟順序：
  1. 資料庫引擎在 Sales Customer 資料表上執行叢集索引掃描作業，然後傳回該資料表中所有資料列的 CustomerID 資料行。
  2. 它接著對 Sales.SalesOrderHeader 資料表中的其中一個索引執行索引掃描 (意指非叢集索引掃描)。這是 CustomerID 資料行上的索引，但它也隱含地包含了 SalesOrderID 資料行 (即資料表叢集索引鍵)。這兩個資料行上的值是掃描傳回的。
  3. 兩次掃描的輸出已使用「合併聯結」實體運算子聯結在 CustomerID 資料行上 (這是三種實際執行邏輯聯結作業可能的方法之一)。它的速度很快，但是要求兩邊的輸入都要在聯結的資料行上排序。在本例中，兩次掃描作業都已傳回 CustomerID 上排序的資料行，因此不需要執行額外的排序作業)。
  4. 接下來，資料庫引擎在 Sales.SalesOrderDetail 資料表上執行一次叢集索引掃描，從此資料表中的所有資料列擷取四個資料行 (SalesOrderID、OrderQty、UnitPrice 和 UnitPriceDiscount) 的值 (此作業估計會傳回 123,317 個資料列，您可從 [圖 2] 中的 [估計的資料列數目] 和 [實際的資料列數目] 屬性，看出實際上也傳回了此數目 — 因此估計非常正確)。
  5. 叢集索引掃描所產生的資料列會傳遞給第一個「計算純量」運算子，讓每個資料列可以根據公式中所包含的 OrderQty、UnitPrice 和 UnitPriceDiscount 資料行計算資料行 LineTotal 的值。
  6. 第二個「計算純量」運算子會依照計算資料行公式的要求，將 ISNULL 函數套用到前次計算的結果中。這便完成了 LineTotal 資料行的計算，並將它連同 SalesOrderID 資料行傳回給下一個運算子。
  7. 步驟 3 中「合併聯結」運算子的輸出會使用「雜湊比對」實體運算子，與步驟 6 的「計算純量」運算子的輸出聯結起來。
  8. 另外一個「雜湊比對」運算子接著會套用到從合併聯結由 CustomerID 資料行值傳回的資料列群組，並計算 LineTotal 資料行的 SUM 彙總。
  9. 最後一個節點 SELECT，既非實體亦非邏輯運算子，而是代表整體查詢結果和成本的預留位置。
在我的膝上型電腦上，這個執行計畫的估計成本是 3,31365 (如 [圖 3] 所示)。當在 STATISTICS I/O 處於 ON 的狀態執行時，查詢報告得出在三個牽涉的資料表間執行了 1,388 項邏輯讀取作業。每個作業下方顯示的百分比表示每個個別運算子的成本與整個執行計畫的整體估計成本的比數。看一下 [圖 1] 中的計畫，可以看出整個執行計畫的總成本大多與下列三個運算子有關：Sales.SalesOrderDetail 資料表的叢集索引掃描，以及兩個雜湊比對運算子。但是在繼續進行最佳化之前，我想要指出我在查詢當中做了一項非常簡單的變更，可讓我同時剔除兩個運算子。
[圖 3] 查詢的總估計執行成本
[圖 3] 查詢的總估計執行成本
既然我從 Sales.Customer 資料表傳回的唯一一個資料行是 CustomerID，而此資料行也包含在 Sales.SalesOrderHeaderTable 中的外部索引鍵中，因此只要使用這段程式碼，不需要變更查詢所產生的邏輯意義或結果，便可完全將 Customer 資料表從查詢中剔除：
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
這便產生不同的執行計畫，如 [圖 4] 所示。
[圖 4] 從查詢中剔除 Customer 資料表之後的執行計畫
[圖 4] 從查詢中剔除 Customer 資料表之後的執行計畫
兩項作業完全剔除掉 — Customer 資料表上的叢集索引掃描，以及 Customer 與 SalesOrderHeader 之間的合併聯結 — 而雜湊比對聯結則被效率高出許多的合併聯結所取代。不過，為了在 SalesOrderHeader 和 SalesOrderDetail 資料表之間使用合併聯結，兩個資料表的資料列都必須由 SalesOrderID 聯結資料行經過排序傳回。為了達到這個目的，查詢最佳化工具決定不使用非叢集索引掃描，而是在 SalesOrderHeader 資料表上執行叢集索引掃描，因為就牽涉的 I/O 而言，它的成本比較低。這是示範查詢最佳化工具實際運作的理想範例 — 既然變更執行聯結作業的實際方法所省下的成本比叢集索引掃描所產生的額外 I/O 還要高，因此查詢最佳化工具便選擇所得的運算子組合，因為它所給的總估計執行成本最低。在我的膝上型電腦上，即使邏輯的讀數很高 (達 1,941)，但耗用的 CPU 時間其實很短，而此查詢的估計執行成本也降低了 13% (2,89548)。
假設我還想要更進一步提升此查詢的效能，我現在看到 SalesOrderHeader 資料表的叢集索引掃描變成此執行計畫中最昂貴的運算子。既然在此資料表中只需要兩個資料行便可完成查詢，我可以建立一個只包含這兩個資料行的非叢集索引 — 以較小許多的非叢集索引掃描來取代掃描整個資料表。索引定義看起來可能像這樣：
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
請注意，我建立的索引包含了一個計算資料行。這不一定都能成立，要視計算資料行的定義而定。
建立好此索引然後執行相同的查詢之後，我得到新的執行計畫，如 [圖 5] 所示。
[圖 5] 最佳化後的執行計畫
[圖 5] 最佳化後的執行計畫
SalesOrderDetail 資料表上的叢集索引掃描已由 I/O 成本明顯低很多的非叢集索引掃描取代。我也剔除了其中一個計算純量運算子，因為我的索引包含的 LineTotal 資料行已經計算出值。估計的執行計畫成本現在是 2,28112，而查詢在執行時進行了 1,125 次邏輯讀取作業。

涵蓋索引
客戶訂單查詢練習
問：下面是客戶訂單查詢練習：請試著找出索引定義 — 要成為此查詢的涵蓋索引應該包含哪些資料行，還有索引定義內的資料行順序對效能是否有影響。
答：我提出挑戰要您找出針對本文中的範例查詢在 Sales.SalesOrderHeader 資料表上建立的最佳涵蓋索引。要接受挑戰，您應該要注意的第一件事是查詢只使用資料表的兩個資料行：CustomerID 和 SalesOrderID。如果您仔細地閱讀本文，應該會注意到在 SalesOrderHeader 資料表中，已經有一個現有的索引涵蓋此查詢 — 那就是 CustomerID 上的索引，而且它隱含也包含了 SalesOrderID 資料行，此資料行是資料表的叢集索引鍵。
當然，我也解釋了為什麼查詢最佳化工具決定不使用此索引。沒錯，您是可以強制查詢最佳化工具使用這個索引，但是這樣的解決方案比採用叢集索引掃描和合併聯結運算子的現有計畫還沒效率。這是因為您等於是強迫查詢最佳化工具選擇是要在另外執行排序作業以便繼續使用合併聯結，還是回頭使用效率較低的雜湊聯結。兩種選項的估計執行成本都比現有計畫要高 (進行排序作業的那個版本的效能特別差)，因此除非強制查詢最佳化工具，否則它不會使用這兩種選項。所以說，在這種情況下，唯一一個比叢集索引掃描執行要佳的索引是 SalesOrderID、CustomerID 上的非叢集索引。但要特別注意的是，資料行必須遵守下列順序：
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
如果您建立這個索引，則執行計畫將包含索引掃描，而不是叢集索引掃描運算子，這可是南轅北轍。在本例中，只包含兩個資料行的非叢集索引遠比以叢集索引的形式表示的整個資料表要小得多。因此，它讀取必要資料所需的 I/O 也比較少。
這個範例也說明了索引內的資料行順序深深左右著它對於查詢最佳化工具的有用程度。在設計多資料行索引時，要特別記住這點。

我在 SalesOrderDetail 上建立的索引是所謂的「涵蓋索引」。它是一種非叢集索引，包含了完成查詢所需的所有資料行，因而不需要使用資料表掃描或叢集索引掃描運算子來掃描整個資料表。這個索引基本上是資料表的小型副本，當中包含了資料表的資料行子集。只有那些需要回答查詢的資料行才會包含在索引中 — 換句話說，索引只包含「涵蓋」查詢所需的內容。
為最常執行的查詢建立涵蓋索引是用於查詢微調其中一個最簡單也是最常見的方法。這種方法特別適用於當資料表包含大量資料行，但查詢最常參考的只有當中少數的情況。您可以透過建立一或多個涵蓋索引，大幅提升受影響查詢的效能，因為它們存取的資料量小很多，轉而產生較低的 I/O。不過，在資料修改作業 (INSERT、UPDATE 和 DELETE) 期間維護額外的索引倒是得付出不易察覺的成本。視您的環境和 SELECT 查詢與資料修改之間的比率而定，您應該審慎判斷此額外的索引維護負荷與查詢效能提升比起來，是否值得。
別只建立單一資料行索引，勇敢試著建立多資料行索引。多資料行索引比單一資料行索引要有用得多，而且查詢最佳化工具也比較可能會用它們來涵蓋查詢。大多數的涵蓋索引都是多資料行索引。
我的範例查詢還是有改進的空間，在 SalesOrderHeader 資料表上放一個涵蓋索引可進一步最佳化這個查詢。此舉可消除叢集索引掃描，而採用非叢集索引掃描。這就留給您自己練習，試著找出索引定義 — 要成為此查詢的涵蓋索引的應該包含哪些資料行，還有索引定義內的資料行順序對效能是否有影響。答案請參閱「客戶訂單查詢練習」資料看板。

索引檢視
如果效能對於我的範例查詢來說很重要，我還可以進一步建立一個索引檢視，實際儲存查詢的具體結果。索引檢視有些先決條件和限制，但若可以採用，它肯定能大幅提升效能。要記住索引檢視的維護成本比標準索引還高。因此，理當謹慎使用。在本例中，索引定義看起來像這樣：
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
請注意 WITH SCHEMABINDING 選項和 COUNT_BIG(*) 函數，前者是在這類檢視上建立索引的必備選項，而若是索引定義包含彙總函數 (在本例中，即 SUM) 則需要用到後者。建立此檢視之後，我便可以在它上面建立索引，像這樣：
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
我在建立這個索引時，包含在檢視定義內的查詢結果會具體化，而且實際上會儲存在索引內的磁碟上。要注意的是，在基底資料表上進行的所有資料修改作業接著便會根據其定義自動更新檢視中的值。
如果我現在傳回查詢，接下來會發生什麼事完全要看我執行的 SQL Server 版本而定。在 Enterprise 或 Developer 版本，查詢最佳化工具會自動將此查詢與索引檢視定義相比對，然後使用索引檢視，而不是查詢所包含的基底資料表。[圖 6] 顯示此例中所產生的執行範例。當中只包含一項作業 — 即我在檢視上建立的索引的叢集索引掃描。估計的執行成本只有 0,09023，而它只執行了 92 項邏輯讀取作業。
[圖 6] 使用索引檢視時的執行計畫
[圖 6] 使用索引檢視時的執行計畫
您還是可以在其他版本的 SQL Server 上建立和使用這個索引檢視，但是要達成相同的效果，您得修改查詢，使用 NOEXPAND 提示直接參考檢視，像這樣：
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
如您所見，如果使用得當，索引檢視可說是相當強大的功能。它們在最佳化對大量資料執行彙總的查詢時特別實用。如果用在 Enterprise Edition 上，則不需要變更程式碼，就能使許多查詢受益。

識別要微調的查詢
我要如何識別值得微調的查詢呢？我會找最常執行的查詢 — 它們單次執行的成本可能不高，但是彙總起來的執行成本可能比鮮少執行的大型查詢要高許多。我不是說您不應該微調大型查詢，而是覺得您應該先把焦點放在最常執行的查詢。那麼您要如何識別它們呢？
可惜，最可靠的方法有點複雜，而且動作包括對伺服器追蹤所有已執行的查詢，然後依它們的簽章來分組 (也就是說，以預留位置取代實際參數值來查詢文字以便識別相同的查詢類型，即使它已使用不同的參數值執行也一樣)。這是相當複雜的程序，因為要產生查詢簽章很難。Itzik Ben-Gan 在他《Inside Microsoft SQL Server 2005:T-SQL Querying》的書中提出了一個解決方案，就是使用 CLR 使用者定義的函數和規則運算式。
另外有一個簡單許多但比較不可靠的方法。您可以仰賴在執行計畫中所保留的所有查詢統計資料，然後使用動態管理檢視來查詢它們。[圖 7] 中包含了一個範例查詢，顯示快取中邏輯讀取累加數字最高的 20 個查詢的文字和執行計畫。這個查詢對於快速識別產生最高邏輯讀數的查詢非常好用 — 但它也有限制。那就是，它只會顯示您在執行查詢時有快取它們的計畫的查詢。如果有內容沒有快取到，就會遺漏掉。
Figure 7 識別前 20 個在讀取 I/O 時耗用最多資源的查詢 (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
識別出那些效能低劣的查詢後，可以看看它們的查詢計畫，並使用我在本文中說明的一些索引技巧來尋找提升其效能的方法。如果成功了，您下的功夫肯定不會白費。
祝您微調愉快！

Maciej Pilecki 在 Solid Quality Mentors 擔任副顧問一職，這是一家專營教育訓練、顧問和諮詢的國際組織。他身兼微軟認證講師 (Microsoft Certified Trainer，MCT) 和 SQL Server 最有價值專家 (Most Valuable Professional，MVP)，經常講授有關 SQL Server 和應用程式開發許多方面的課程和研討會。


 編輯的話: 讓您有更多電可用
編輯的話
讓您有更多電可用

上個月我以「環保運算」為題， 抒發心理的想法，不過這只是起頭而已，接下來我還要再接再厲延續這個主題。說的是，我還沒給它明確的定義呢！(什麼是環保？如果我的愛車 1 加侖的油跑了 30 英哩，比起別人才跑 25 英哩，這算不算環保呢？其實啊，我有沒有車子根本不重要，聽好了，我住紐約，紐約人都用走的)。
從目前的趨勢來看，只要稍有口碑的公司，都會儘量在產品或服務貼上「環保」的標籤。環保問題的確值得一談，這也是上個月我們選它作為封面文章的原因 — 它的後勁的確驚人。
我們都知道，賺錢就跟拯救環境一樣重要。事實上，保護生態環境已經成為真正獲利的賣點了 (拜託，那是因為經濟的關係好不好！)。如果車行能夠讓車子節省成本而提高銷量，也未嘗不是好事。最重要的是，我們希望能夠在維持一定水準的健全環境上，建構健全的經濟體系。
那麼，這對 IT 專家有什麼影響呢？勞倫斯柏克萊國家實驗室 (Lawrence Berkeley National Laboratory) 研究員暨史丹佛大學專任教授 Jonathan Koomey 博士，最近剛發表一篇預估美國及全球地區伺服器總耗電量的研究論文。他在文中指出， 2005 年資料中心 (伺服器及其支援基礎結構，例如冷卻系統) 的耗電量約佔全美總耗電量的 1.2% — 足足為五個 10 億瓦特發電廠的耗電量，成本為 27 億美元。而全球成本則已躍升為 72 億美元 (足足為 14 個 10 億瓦特的發電廠耗電量)。看來我們要節省的金錢和電力可不是一筆小數目，而且光從資料中心就可以節省大部分了。
到底我們要如何規劃資料中心的用電量？如何配合需求來調整電量，但又無需整天以全速來耗用電量呢？(給您一個提示吧：虛擬化)。大家都知道監控伺服器上的網路連線量和記憶體使用量，但是耗電量有幾個人注意呢？舊伺服器的耗電量，是否遠高於新伺服器？增加的用電成本，是否已經高過更換機器的費用？
接下來的幾個月，我們將邀請一位專任專家 Dave Ohara (上月份的文章作者，該篇文章目前發表於 technetmagazine.com) 告訴您，Microsoft 位於華盛頓州昆西市及德州聖安東尼市的環保資料中心所採取的應變措施，並且解答上述的其中一些問題。另外，我們也想聽聽各位如何處理這些問題 (如果您選擇不處理，也請告訴我們原因)。您可以透過電子郵件地址 tnmag@microsoft.com 與我們聯絡，或者造訪我們的部落格，網址為 blogs.technet.com/tnmag。 —Joshua Hoffman

感謝下列 Microsoft 技術專業人員：Tim Carroll、Omesh Desai、Steve Jenness、Sam Kroonenburg、Mutlu Kurtoglu、KC Lemson、Tim Mintner、Jim Truher、Buck Woody 和 Sudarshan Yadav。


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

擷取畫面視訊
My Screen Recorder Pro
deskshare.com/msrpro.aspx
再過 20 分鐘就要開會了，卻還在新的系統設定上整理簡報。幾乎每天都要跟不同的使用者講解同樣的應用程式教學課程。如果這正是您的寫照，告訴您一個小秘訣：不妨試試 DeskShare 推出的 My Screen Recorder Pro。
光從名稱就看得出來，這個應用程式可以把桌面上的活動記錄成影片，方便您整理即席簡報，或者向客戶重複播放教學課程。另外，My Screen Recorder Pro 也支援錄音功能，可以同時錄製旁白。(提示：錄音前請先擬稿)。
建立新視訊很簡單。只要選取想錄製的區域 (整個桌面、桌面上一個可自訂區域、桌面上的固定區域，或是特定的應用程式視窗)，再按一下 [錄製 (Record)] 按鈕即可。
這個應用程式可以錄製成 AVI、Windows Media® Video (WMV) 或 Flash，因此便於散發，甚至可以將視訊內嵌在網頁或者廣泛公開。您也可以把視訊建立成一個執行檔，在大部分的 Windows® 電腦上播放。視訊內嵌在執行檔中可以簡化散發作業，一般使用者憑直覺就能夠播放它。
如果簡報或教學課程適合採用多個區段，您也可以將好幾場鏡頭組合在同一個影片中。如果需要對影片稍做編輯，也可以根據自己的需求來分割或剪輯片段。
雖然在一般情況下使用預設值就足夠了，不過您也可以改變畫面播放速率、音效品質以及壓縮設定，製作出最適合您的環境的作品，即使面對各種大小或頻寬限制都毫無問題。您也可以使用簡單的螢光影像擷取模式來建立錄製作業，有效壓縮長時間錄製的部分 (例如，緩慢移動的進度列)。另外，還有一項不錯的功能，您可以改變錄製的滑鼠游標並加上滑鼠指標效果，這樣播放錄製內容時可以強調正在發生的動作。舉個例說，每按一次滑鼠按鈕時就放大指標，或者在指標周圍出現多個小圈圈圍住它。此外，還可以在視訊配上字幕和時間戳記，作為存檔之用。
對於行跡詭密、疑心病比較重或是格外小心的人，My Screen Recorder Pro 還可以讓您設定錄製時間，再從命令列執行這個程式，就可以仔細監控工作站上的活動。最後一點，這個應用程式具有將視訊發佈到 FTP 站台的內建功能，只要跟排程器結合，就可以有效進行監控。

售價：單一授權為 $99 美元 (直接售價)。
錄製桌面動作來建立簡報

重組磁碟
PerfectDisk 8
raxco.com/products/PerfectDisk2k
任何一種 Windows 系統都必須執行磁碟重組。如果您像我一樣，那麼一定經常新增和移除應用程式、功能和軟體更新。磁碟重組公用程式有好幾種，其實我上個月才提到一種。但是磁碟重組實在太重要了，而且 Raxco Software 推出的 PerfectDisk 8 也絕對有討論的價值，所以不得不再囉唆一次。即使所有的 Windows 都附有重組工具，但是想要更精確的掌控重組作業，還是需要其他公用程式幫忙。如果您有這種需求，不妨參考一下 PerfectDisk。
PerfectDisk 8 與任何一種 Windows 重組工具一樣，都可以重組 FAT16、FAT32 和 NTFS 磁碟機，也可以重組 RAID 磁碟機。PerfectDisk 8 適用於桌上型電腦和伺服器，它具有 Windows Vista® 的認證，並且支援其他版本的 Windows，包括 Windows Server® 2003 和 Windows 2000 在內，甚至還支援 Exchange。
該公司推出的 SMARTPlacement 技術可以組織磁碟上的檔案結構，讓您更快速的進行存取。例如，它負責管理 Windows XP 系統上的 boot.ini 和 layout.ini 檔案，將它們妥善排列，縮短系統開機時的磁碟搜尋時間。除了重組整個磁碟機之外，您也可以選擇重組一個檔案，比方說，下載一個大型 ISO 檔之後，就可以利用它來重組這個檔案。
由於作業系統在執行時，無法應付那些頑固的系統檔案，因此這個應用程式採用離線模式，在下次系統啟動時執行，或者在適當的情況下卸載磁碟來執行重組。PerfectDisk 還有一個很棒的功能，就是螢幕保護程式重組模式，只要一執行螢幕保護程式，就會自動啟動重組作業。
另外，PerfectDisk 還有命令列版本，可讓您透過自己喜歡的工作排程器，很方便的排定重組時程，並且透過系統上任何一個執行中的系統管理代理程式來啟用遠端執行。如果您要進行規模較大的部署作業，可以下載免費的 PerfectDisk Command Center，在企業執行遠端部署、更新、排程，以及設定工作站應用程式。

售價：PerfectDisk 8 Professional (桌上型電腦用) 的單一授權為 $39.99 美元起。PerfectDisk 8 Server 的單一授權為 $239.99 美元起。
PerfectDisk 還提供若干設定選項。

書評
Network Warrior
oreilly.com
如果您的工作室是執行 Cisco 裝備，不妨買一本 Gary Donahue 寫的《Network Warrior》(O'Reilly，2007 年) 來看看。這本書的讀者群相當廣泛，無論您是剛剛接觸網路，或是最近才剛獲得 CCNA 憑證，或者是一位還想再更上層樓的傑出系統管理員，都可以從本書吸取對您有利的資源。
本書是以真實世界的網路技術應用為基礎，並且以網路專家的身分，讓您快速參考許多日常活動經常碰到的工作，這也是我特別喜歡它的原因。本書從入門寫起，一開始先深入淺出的說明組成網路的基礎元件，接著循序說明集線器、交換機、VLAN、中繼及 VLAN Trunk Protocol (VTP)，以及跨距樹狀目錄通訊協定 (Spanning Tree Protocol，STP) 的跨距樹狀目錄，和 Cisco System 的 EtherChannel 技術。
《Network Warrior》是以 Cisco Internetwork Operating System (IOS) 和 CatOS command-line interface (CLI) 命令的基本範例，搭配方法和技術的解說作為架構。它以現代方法論搭配少許歷史背景的方式，提出細微的觀點 (例如，為什麼有了 IOS 之後，CatOS 還是存在)。
本書並概略討論路由和路由器，讓您瞭解各種路由通訊協定從度量 (metrics) 到管理距離 (administrative distance) 的路由基本概念。另外，它也概略介紹幾種通訊協定，例如 Open Shortest Path First (OSPF)、邊界閘道通訊協定 (Border Gateway Protocol，BGP) 以及路由資訊通訊協定 (Routing Information Protocol，RIP)。
作者在說明 Cisco Hot Standby Router Protocol (HSRP) 的這一節中探索定址可用性，並且介紹若干基本設定，協助您保護網路基礎結構，使它免於停機的顧慮。接著就回顧部分 Cisco 的多層交換器功能 (包括 Cisco 6500 和 Catalyst 3750)，並且討論一些您可能會遇到的基本設定。
其中有關電信方面的資訊，我認為相當有用。本書會教您理解一些艱澀難懂的術語，以避免日後看到時只能點頭傻笑的尷尬。除此之外，它還詳細解說了 Channel Service Unit/Data Service Unit (CSU/DSU)、設定 DS3 連線，以及可利用電信技術實際操作的多節點框架傳送。
其中描寫安全性和防火牆的一節，我認為相當不錯。它不但告訴您如何設計和設定存取控制清單 (ACL)，另外也提到驗證、DMZ 和特定的 PIX 防火牆設定選項。我喜歡它以簡潔的方式描寫防火牆理論，像是「許可所要的，其餘的一律拒絕」，以及「安全性就是在方便和妄想之間取得平衡」，都是非常好的網路真言。
《Network Warrior》的最後一節則深入探討網路設計，說明一般網路基礎結構設計的基礎 (例如，三層電子商務設定，以及沒有分散層的崩解核心網路)，並且強調記錄與命名慣例的重要。

售價：定價 $44.99 美元。

管理檔案鎖定
WhoLockMe
dr-hoiby.com/WhoLockMe
如果每一個應用程式都能夠正確關閉檔案，那就天下太平了，可惜不然。發生共用衝突已經很頭痛了，要找出檔案目前被哪一個程序鎖定，可能會讓您更加傷腦筋。您怎麼想我不知道，不過如果只為了控制一個檔案就一一關閉應用程式，我可不想這麼做。幸好市面上有一種免費又簡單的 Windows 檔案總管擴充程式可以奧援，它叫 WhoLockMe。
這個應用程式可用於 Windows NT®、Windows 2000、Windows Server 2003 和 Windows XP，您可以藉它找出問題檔案是被哪一個程序鎖定。用法很簡單，只要按一下滑鼠右鍵，在 Windows 檔案總管快顯功能表選取項目即可。
WhoLockMe 會指出鎖定檔案的處理序名稱、處理序識別碼 (PID)、已開啟檔案的路徑、該處理序執行內容的網域和使用者，以及違規程序的完整路徑。如果您夠大膽的話，大可直接從 UI 移除這個處理序。
不過由於 WhoLockMe 最近沒有更新，所以還不能用在 Windows Vista 上。但如果您用的是舊版 Windows，它就可以快速有效的幫您找出是哪一位使用者或哪一個處理序鎖定您要移動、刪除或編輯的檔案。

售價：免費

DNS 工具
DNSStuff.com
www.dnsstuff.com
如果您面對的是外部式網際網路應用程式或網路，那就得靠 DNS 幫您管理它們，讓事情順利完成，同時它也容許外來者知道您和您應用程式的所在位置。我個人倒是很依賴一種工具集幫我解決 DNSstuff.com 的 DNS 問題。這個 Web 工具集在疑難排解和驗證基礎結構設定方面，絕對是不容置疑的資源。
該站台針對網域、IP、主機名稱、電子郵件、網站以及一般網路問題所提供的工具不下 45 種，工作項目從驗證郵件伺服器設定到檢查 DNS 主機速度，全部都能勝任。沒錯，這些工具大部分都能在您的基礎結構中找到功能相當的替代品，但是外部驗證卻可以提供重要資訊幫助您排解疑難。有了這些資訊，您就不必苦苦哀求別人幫您做反向 DNS 查詢了。
不過若說到該站台上最強大且最完整的工具，莫過於 DNSreport 了。您只要輸入一個網域名稱，按一下按鈕，就可以找到取之不盡的安裝資訊。每一個測試行項目都會顯示一個以顏色標示的狀態，幫助您快速掃描測試結果，找出可能的問題。這份報告會檢查網域的上層區域，顯示諸如名稱伺服器 (NS) 記錄等詳細資訊，以及是否要送出 IP 位址和主機名稱。同時也會檢查潛在的安全性漏洞，驗證您的 DNS 伺服器是不是開放伺服器、是不是都有相同的 NS 記錄，以及是不是沒有 NS 要求，絕不會洩露任何「秘密的」NS 記錄。
您也可以深入瞭解安裝可用性，因為 DNSreport 會測試多個名稱伺服器、公用 IP 連結，以及在檢查單一失敗點時遺漏的名稱伺服器。此外，DNSreport 會檢查您的授權啟動 (SOA) 明細，傳回 SOA 序號、重新整理、到期、重試和最低執行時間 (TTL) 值，以及檢查 MNAME 和 RNAME 記錄。
該報告的 Mail Exchange (MX) 記錄檢查會驗證反向 DNS 項目，並且確定您沒有重複的記錄，以及確定記錄的主機名稱有效。另外，這個工具會試著連接您的郵件伺服器，驗證諸如郵件伺服器的主機名稱是否列在問候語內，以及它接不接受 abuse@yourdomain 郵件 (就像各種 RFC 所指定的一樣)，以及 SMTP 伺服器目前是否設定為開放轉送 (因而吸引全世界濫發垃圾郵件的人上門) 等項目。最後，DNSreport 會傳回您的 www A 記錄，驗證所有的 IP 是否為公用 IP，以及判斷您的 CNAME 設定是否會導致額外的 DNS 查閱作業。
如果您覺得光是 DNSreport 還不夠，站台還提供一種查閱工具，讓您檢查郵件伺服器是否被列入知名垃圾郵件資料庫的黑名單中，另外還有一種工具，可以幫助您尋找網域濫用連絡人。您可以在主要 ISP 上執行 IP Whois 查閱、Tracerout 和 Ping，以及一般 DNS 查閱和快取 DNS 查閱。只要訂閱的話，您甚至可以執行 NETGEO IP 查閱、MAC 位址檢查，以及完整的區域檔案傾印。總歸一句話，這是一組值得擁有的工具。

售價：單一使用者成員每月 $3 元美金 (具有完整存取權及無限查閱權)。
DNSstuff.com 提供整套好用的監控工具

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


 Exchange 佇列問題與解答: 保障電子郵件通訊協定安全、不明垃圾郵件及其他
Exchange 佇列問題與解答
保障電子郵件通訊協定安全、不明垃圾郵件及其他
Nino Bilic and Scott Landry
本專欄部分內容是根據 Windows Server 2008 的搶鮮版所撰寫。本文包含的資訊均有可能變更。

問：我想要使用安全的 SMTP，要如何讓 Exchange Server 在連接埠 465 上接聽 SMTP 呢？
答：很抱歉，您不能這麼做。您是可以讓任何 SMTP 虛擬伺服器或接收連接器在連接埠 465 上接聽沒錯，但是這樣並不能達到保護 SMTP 安全 (SMTPS) 的目的。
為什麼呢？讓我們倒帶一下來看看，SSL 有兩種：明確和隱含。起初，大部分的 SSL 都是隱含的，也就是說使用的是 SSL 的專用連接埠。例如，HTTP 預設是位在連接埠 80 上，但 HTTPS (含 SSL 的 HTTP) 是在連接埠 443 上。幾年前，網際網路社群決定 SSL 並不需要專用連接埠。明確 SSL 於焉誕生。
Netscape 已選定 465 作為 SMTPS 連接埠，但是 Exchange Server 在 SMTP 中並不具 SSL 功能。不過，Exchange 小組看出明確 SSL 的優勢，也就是用戶端和伺服器可以平等使用它，於是選擇為 SMTP 支援明確 SSL。
對於 SMTP，明確 SSL 是使用 STARTTLS ESMTP 命令來發出現有的通訊端即將受到保護的信號。其他大多數 SMTP 伺服器和用戶端廠商也已經實作 STARTTLS 命令，因此不太需要支援連接埠 465，反正它已經不是官方網際網路標準了。
至今，還是沒有任何一版的 Exchange Server 針對 SMTP 支援隱含 SSL。告訴 Exchange 接收連接器或 SMTP 虛擬伺服器在連接埠 465 上接聽也於事無補。因此，您必須使用可在連接埠 25 上支援 STARTTLS 的用戶端。如果不能使用連接埠 25，下一個合理的選擇是 587，這是用戶端 SMTP 提交的標準連接埠。許多現代的用戶端在 25 上都支援 STARTTLS，因此沒有必要加入對隱含 SSL 的支援。
順帶一提，Exchange POP3 和 IMAP4 通訊協定一直以來都支援隱含 SSL。但是在 Exchange Server 2007 中，現在也為這兩種通訊協定加入了對明確 SSL 的支援。不過支援這個新標準的用戶端並不多，所以隱含 SSL 還會存在好一陣子。

問：我有一堆郵件佇列在許多網域裡面，而且都不是我的使用者寄的。怎麼會這樣，還有我要怎麼防範？
答：這種情況到處可見，任何一個在網際網路上有伺服器的人都可能碰到這個問題。基本上，可能的起因有兩種：第一個起因是您在某種情況下開放供他人轉送 (請參閱 support.microsoft.com/kb/304897)。可是想也知道，您不會這麼做，對吧？(自 Exchange Server 2000 以來，預設會停用開放轉送)，因此您比較有可能是遇到了所謂的未傳遞報告 (NDR) 垃圾郵件。在傳送來路不明之商業電子郵件 (UCE) 的過程中，濫發垃圾郵件者經常傳送到您網域中不存在的位址。您的伺服器試圖讓濫發垃圾郵件者知道使用者並不存在，但是不用說，濫發垃圾郵件者捏造了回傳位址。濫發垃圾郵件者可能捏造了無效的位址 (而導致 NDR 擱置一段時間直到逾時)，或者它可能試圖使您的伺服器代替他，藉伺服器所產生的 NDR，以附件的形式傳送垃圾郵件給其他網域。
您可以停用 NDR，但要是合法的使用者不小心打錯位址，他永遠不會知道電子郵件並沒有送出，而可能遺失重要的訊息。下面有其他更好的解決方案。
首先，確定您未開放轉送功能 (只是要再次叮嚀一下)。接下來，開啟防垃圾郵件篩選之類的功能，例如智慧型郵件篩選器 (IMF) 或 Exchange Server 2007 內容篩選器，另外也開啟一些即時封鎖清單 (RBL)。這可以是在 Edge Transport role 或 Hub Transport role 中，但應該在頭一個躍點完成，因為 90% 以上的郵件量都是垃圾郵件，您肯定不希望讓伺服器忙著處理這些有的沒的垃圾。
最後，在第一部接受郵件進入您的環境的 Exchange Server 上啟用收件者篩選功能。這可讓您的伺服器在郵件進入網路之前加以拒絕。不小心打錯合法的位址還是收得到 NDR，但是 NDR 將由寄件者的伺服器產生。

問：我有部伺服器執行 Exchange Server 2000，還有一部伺服器執行 Exchange Server 2003，兩部皆可成功傳送郵件到網際網路。但安裝 Exchange Server 2007 後，現在每部伺服器上的信箱卻沒辦法傳送郵件。
答：如果您在過去只有一部 Exchange Server，可能不太熟悉連接器的概念。Exchange 連接器是邏輯路由組態物件，會告訴 Exchange 要將電子郵件導向何處。當您將 Exchange Server 2007 引進現有的組織時，為了路由郵件，您一定要有路由群組連接器和 SMTP 連接器。
您需要兩個路由群組連接器，一個從 Exchange Server 2007 路由群組連到 Exchange Server 2003 路由群組，而另一個剛好相反。您可以將此當成安裝程序的一部分，但若是您遺漏了或不確定這項作業，可以使用 Exchange 管理命令介面來檢查，然後在該處修正問題。如果不這麼做，將無法在伺服器之間傳送郵件。郵件可能到最後會佇列到無法到達的目的地。
若要路由網際網路郵件，您只需要一個 STMP 連接器 (在 Exchange Server 2007 也稱為傳送連接器)。您在 Exchange Server 2000 和 Exchange Server 2003 應該也要有一個 STMP 連接器，不過可能不用也行得通。所有網域的位址空間應該是 SMTP:*，而且您可以指定成要使用智慧主機或 DNS 來傳遞郵件。您可以選擇是要 Exchange Server 2007 伺服器還是舊版的伺服器來處理外寄的網際網路郵件，或者如果您希望每部伺服器處理自己的郵件，可以在這兩個路由群組上建立連接器。如果您已安裝 Edge Transport server role，也可以建立其中一個連接器作為 Edgesync 程序的一部分。
假如您之前在 SMTP 虛擬伺服器上設置了智慧主機，現在正是移除它的好時機。它應該只存在於 SMTP 連接器，而不能放在虛擬伺服器上，因為這樣會中斷路由群組連接器。
您也應該要知道輸入電子郵件是由 MX 記錄或防火牆轉寄至的 IP 所控制。Exchange 這一端要設定的不多，不過如果您還是有問題，以下這份文件應該蠻有用的：msexchangeteam.com/archive/2006/11/17/431555.aspx。

問：為什麼我在 Exchange Server 2007 中收到同封郵件的多份日誌報告？
答：Exchange Server 2007 傳輸日誌代理程式會在分類後為郵件記錄日誌。分類程式將郵件分成兩部分 (也就是，複製郵件內文並在不同的副本上放置不同的信封收件者) 的理由有很多。當中一個例子是：因為日誌現在能夠告訴您通訊群組在郵件送出之時所屬的成員資格，因此您可能會收到多份報告的一種情況是由於巢狀通訊群組的關係。
報告多了這項功能，表示您可能會收到同封郵件的多份副本，各含有獨立的報告。實在沒什麼保證的方法可以確定某郵件的全部報告是否都已抵達，不過若是您要進行封存，記得與封存廠商合作，確定他知道您所做的變動。

問： Exchange Server 2007 中將未解析的郵件轉寄到主機的功能跑到哪裡去了？我現在該怎麼做？
答：被狗吃掉了。
這項特定功能在您擁有一部以上的 Exchange Server 時，成效其實不怎麼彰顯。不過，Exchange 已經有其他方法可以達成相同的效果，而且該方法的功能要強大許多。更具體的說，它可讓您與其他系統共用個別的 STMP 網域。於是拿掉了「轉寄未解析」功能，並更進一步發揮和簡化共用網域概念。在 Exchange Server 2007 中，只要前往 [組織] | [Hub Transport] | [已接受的網域]，然後把網域類型從 [授權] 變更為 [內部轉送] 就可以了。對於某些環境來說，實際操作可能稍微更複雜一點，我們正努力更新一些說明文件。不過目前這應該可以幫得上忙。

問：我試著準備根網域進行 Exchange Server 2007 安裝，我嘗試執行 Exchange Server 2007 安裝程式的伺服器裝有 Exchange Server 2003 Exchange 系統管理員 (ESM)，結果安裝程式失敗了。問題是出在哪裡？
答：簡單的說，在裝有任何 Exchange Server 2000 或 2003 元件的機器上執行任何一部分的 Exchange Server 2007 安裝程式並沒有受到支援。Exchange Server 2007 安裝程式會看到已安裝 Exchange Server 2003 ESM，因此安裝程式必要條件檢查便會失敗，並告訴您「這部電腦上已安裝舊版的 Exchange Server。請從不同的電腦執行 Exchange Server 2007 安裝程式，或移除舊版的 Exchange Server。」
應付這個問題最簡單的方法可能是直接從根網域中的其他伺服器執行 Exchange Server 2007 安裝程式，然後依此法來準備網域。如果這不可行，就必須先解除安裝 Exchange Server 2003 元件，才能繼續執行 Exchange Server 2007 安裝程式。
請記住，您可以使用 32 位元版本的 Exchange Server 2007 來準備網域，所以根網域中任何一部 32 位元伺服器通常都可行。如需有關此主題的詳細資訊，請參閱 technet.microsoft.com/library/bb232170.aspx。
順帶一提，這表示您不能將 Exchange Server 2003 ESM 和 Exchange Server 2007 Exchange 管理主控台安裝在相同的機器上，因為並不支援 Exchange Server 2003 和 Exchange Server 2007 管理工具共存於相同的機器上。如果您試圖將 Exchange Server 2007 安裝在已裝有任何 Exchange Server 2000 或 Exchange Server 2003 元件的機器上，它將會封鎖安裝程式。
最後要注意的是，您不應嘗試先安裝 Exchange Server 2007 管理工具，然後在相同機器上隨後安裝 Exchange Server 2003 工具。這是未經測試過的組態，而且可能會在您嘗試管理伺服器時產生非預期的結果。如果您需要從單一機器管理兩個伺服器版本，可以使用遠端桌面連線到其中一個版本，或使用虛擬機器在隔離環境內主控不同版本的管理工具。

問：我到底何時才能在 Windows Vista® 工作站上執行 Exchange Server 2007 管理工具？
答：Windows Vista 將在 Exchange Server 2007 SP1 發行時正式支援 Exchange Server 2007 管理工具。發行 Exchange Server 2007 SP1 時，將有一個包含 Exchange Server 2007 SP1 管理工具的套件供您下載。

問：那麼在 Windows Vista 或 Windows Server 2008 上執行 Exchange Server 2003 ESM 呢？這也辦得到嗎？
答：很遺憾這辦不到。Exchange Server 2007 SP1 之前任何版本的 Exchange Server 的管理工具在 Windows Vista 或 Windows Server 2008 上都沒有受到支援。這表示即使在 Windows Server 2008 發行後，也不支援在其上安裝 Exchange Server 2003 ESM。管理 Exchange Server 2003 伺服器必須從 Windows Server 2003 或 Windows XP 工作站來進行，或者，您可以改從任何 OS 進行遠端桌面連線。

問：我的網域中執行了好幾部 Exchange Server 2003 伺服器，我能夠將網域控制站升級至 Windows Server 2008 網域控制站嗎？
答：當然可以，在擁有 Windows Server 2008 網域控制站的網域內執行 Exchange Server 2003 SP2 有受到支援。請注意 Exchange Server 並不能使用 Windows Server 2008 唯讀網域控制站 (RODC) 或唯讀通用類別目錄伺服器 (ROGC)。手動指定 (寫在程式中) Exchange Server 來使用 Windows Server 2008 RODC/ROGC 可能會導致未預期的行為。

Nino Bilic 是 Exchange Server 的技術支援專案經理，他把閒暇時間都花在探索伺服器對伺服器通訊的美妙之處，每晚睡前必讀大量的網路監視器追蹤 (Netmon trace) 資料。
Scott Landry是 Exchange Server 的支援高階工程師，他隨身必帶毛巾、一本指南，還有他最信賴的 Windows Mible 電話。


 公用程式焦點: Windows PowerShell 的 SMS Cmdlet
公用程式焦點
Windows PowerShell 的 SMS Cmdlet
Don Brown
下載本文程式碼: Utility2007_11.exe (1211KB)

過去要從命令列管理 Microsoft System Management Server (SMS) 2003 用戶端是不可能的事，幸好最近陸續出現許多協助系統管理員管理複雜性、變更和設定的優秀技術，其中尤以 Windows PowerShell 最能解決問題。
為了好好運用這項技術，我寫了一個小小的「公用程式」：SMS2003PowerShellSnapinSample (您可以從本專欄隨附的程式碼下載中取得這個指令碼，網址是 technetmagazine.com/code07.aspx)。這個公用程式其實是由六個 Cmdlet 組成一個 Windows PowerShellTM 嵌入式管理單元。您可以使用這些 Cmdlet，從 Windows PowerShell 設定本機電腦或遠端電腦群組的 SMS 用戶端本機原則。
由於 SMS 用戶端本機原則越用越上手，促使我更進一步學習 SMS 的操作方式，把它當作額外的收穫。也因此瞭解，只要審慎運用 SMS 用戶端本機原則，就可以用全新的方式控制 SMS 用戶端：比方說，向同一個站台報告的電腦，不一定具有相同的設定。而您可以設定幾部特定的電腦，讓它們直接從遠端控制電腦、改變用戶端檢查新原則的頻率，或者在當天多次停用特定的元件等等 — 您會發現 SMS 用戶端本機原則在使用上是海闊天空，沒有限制的。現在就讓我們來深入探討吧。

關於 SMS 進階用戶端本機原則
程式設計資源
  • 介紹 Windows PowerShell 適合 Windows PowerShell 新手閱讀的入門文章
  • 使用本機原則自訂 SMS (Technet 論壇) 將 SMS 進階用戶端本機原則應用在 MOF
  • 建立您的第一個 Cmdlet
  • 如何建立 Windows PowerShell 嵌入式管理單元
  • Windows Server 2008 的網路存取保護 (NAP)
  • Windows PowerShell 程式開發員指南 適合需要撰寫 Cmdlet、嵌入式管理單元、主機以及其他有關 Windows PowerShell 程式設計說明之資訊的讀者
  • Windows Server 2008 Beta 3 逐步指南

所有正常運作的 SMS 2003 進階用戶端都有一個設定原則，這個設定原則基本上是一份驅動各種元件的設定清單。所有的用戶端、清查彙總及軟體散發設定 (尤其是這一項) 都包含在這些設定原則中。這些原則本身是在站台伺服器上建立，然後經由 SMS 管理點傳給進階用戶端。
SMS 原則的實際本文部分很類似 Managed 物件格式 (MOF) 檔，因為它所包含的一組執行個體，會編譯到進階用戶端上的 \\.\root\CCM WMI (Windows® Management Instrumentation) 命名空間中。其他各種代理程式會讀取這些位於 \\.\root\ccm\policy\machine\requestedconfig 命名空間的設定。但是，當您透過 MOF 套用本機原則時，一部電腦只能編譯一個 MOF，而且它必須在本機執行 (否則您就必須直接登入電腦)。而 WMI 因為具備分散性質的關係，可以從本機和遠端存取它，因而有更多方式可以協助 SMS 管理員。也就是說，只要具備適當的管理權限，就可以像連接本機電腦的 WMI 一樣，連接遠端電腦的 WMI。
SMS 用戶端原則是由適用於各種用戶端元件的設定所組成，不過它也可以包含執行軟體套件內容的相關指示。就像 Active Directory® 群組原則一樣，從 SMS 管理點取得的 SMS 2003 進階用戶端原則也可以覆寫成 SMS 用戶端本機原則。雖然無法將原則全部覆寫，不過仍然可以覆寫一些相當有趣的屬性。這一點讓 SMS 管理員有更大的空間可以控制 SMS 用戶端的設定與作業，因為它容許將標準設定的例外套用在 SMS 站台上。
假設現在有一個整合的安全環境，在這個環境中，SMS 管理員把伺服器和工作站都當作一個 SMS 主要站台的用戶端來管理。在這個虛構的環境中，安全性原則可能會規定技術支援工程師必須先獲得使用者允許之後，才能在遠端控制他們的機器。如果技術支援工程師希望使用遠端控制來連接伺服器，那就做不到了：因為在一般情況下不會有使用者登入伺服器，所以也沒有人可以授予遠端控制權。雖然只要審慎套用本機原則，或許可以在某些特定用戶端上覆寫必須獲得使用者允許的規定，但是談何容易呢？您大概可以想像得出其他許多 SMS 本機原則有用處的情況，允許特定 SMS 用戶端代理程式的設定有所例外。

Windows PowerShell 嵌入式管理單元的內幕
熟悉 Windows PowerShell 的基本原理之後，您就可以加入本專欄所提供的原始程式碼範例，從命令列擴充您對 SMS 用戶端本機原則的權限。有些屬性在開放給 Windows PowerShell 之前，最好先將它們套用到類別。您必須決定 Cmdlet 的目的，以及應該採取的動作。這就是所謂的「動詞-名詞」組合。一般在 Windows PowerShell 出現的動詞有 Add、Get 和 Set。名詞部分則代表您要採取動作的物件。Cmdlet 通常附有參數，這些參數在 Cmdlet 類別中被宣告為各種型別的公用屬性。還有一點，ProcessRecord 函數是主要的工作區，您大部分的工作都是在這裡執行。[圖 1] 是您可以用在自己專屬 Cmdlet 的一般範本。
Figure 1 Cmdlet 範本 (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
當嵌入式管理單元編譯完成之後，您就可以在定義 RunInstaller 屬性集和一些特定屬性的專案中加入一個類別，將它登錄到 Windows PowerShell。如需相關細節，請參閱本文所附的原始程式碼。若要登錄您的嵌入式管理單元，必須使用 Microsoft® .NET Framework 附隨的 InstallUtil.exe 工具。[圖 2] 是登錄嵌入式管理單元所用的語法。請注意，如果您是使用 Windows Vista®，則必須提高權限才能執行這項作業，您可以選擇「以系統管理員的身分開啟」，或者使用 Script Elevation PowerToys for Windows Vista (可在 technetmagazine.com/issues/2007/06/UtilitySpotlight 下載)，來開啟 Windows PowerShell。
Figure 2 從 Windows PowerShell 安裝嵌入式管理單元 (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
接著就是判斷 Windows PowerShell 是否認可您的嵌入式管理單元。只要使用附有已登錄參數的 Get-PSsnapin cmdlet，Windows PowerShell 就會總結列出目前載入的嵌入式管理單元，後面附加一份即將加入的已登錄嵌入式管理單元清單。您的嵌入式管理單元應該就列在這份清單當中：
PS> Get-PSsnapin -registered
現在您就可以使用 Add-PSsnapin Cmdlet，將 Windows PowerShell 嵌入式管理單元加入命令介面中，如下所示：
PS> add-pssnapin SMS2003PowerShellSnapinSample
完成這項作業之後，應該就能在您的 Windows PowerShell 嵌入式管理單元中執行 Cmdlet 了。
若要查看任何 Windows PowerShell 嵌入式管理單元所能使用的 Cmdlet，只要以 Get-Command Cmdlet 指定特定的嵌入式管理單元，並且將嵌入式管理單元的名稱作為 PSsnapin 參數的值傳遞即可。本專欄所附的這個嵌入式管理單元範例，一共有六個 Cmdlet，其中包括「動詞-名詞」Cmdlet 範本在內，如 [圖 3] 所示。
[圖 3] 將 Cmdlet 顯示在嵌入式管理單元中
[圖 3] 將 Cmdlet 顯示在嵌入式管理單元中
我在原始程式碼範例中，專門為 Get-SMSServerConnection Cmdlet 寫了說明來解說它的架構。如果您要擴充說明，可以參考 XML 檔中的範例。[圖 4] 所顯示的是說明輸出。
現在您已經知道如何安裝 Windows PowerShell 嵌入式管理單元、如何找出嵌入式管理單元中有哪些命令，以及如何取得標準 Cmdlet 的說明了，接著我們就開始使用 Cmdlet 吧。您可以使用下面這個命令，列出 SMS 主要站台伺服器中所有的集合：
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
請注意管線。這是讓 Windows PowerShell 運作的核心部分，它是功能相當強大的工具。只要一行就足以在 Windows PowerShell 做任何事情。Get-SMSServerConnection Cmdlet 會連接 SMS 伺服器。Get-Collections Cmdlet 有一個 Get-SMSServerConnection 傳回的型別的輸入參數，因此您只要把 Get-SMSServerConnection Cmdlet 的輸出傳到 Get-Collections Cmdlet 即可。這就是管線運作的方式。此外，它也很清楚的告訴您，如何將複雜物件從一個 Cmdlet 傳到另一個 Cmdlet。您也可以將物件儲存在變數中，如果您在 Windows PowerShell 指令碼中寫了這個動作，結果將如下所示：
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
如果不將輸出好好格式化一番，大概很難看懂，因為 Get-Collections 傳回的是 SMSCollections 型別的物件 (基本上是 SMSCollection 型別的物件陣列)。簡單的說，除非過濾掉不感興趣的集合，或者把只含有中意屬性的表格加以格式化，否則這個畫面不會太好看。而作法是將輸出透過管線，從 Get-Collections Cmdlet 傳到 Format-Table Cmdlet，這樣就只會顯示您所指定的屬性了。舉個例說，您可以附加 | Format-Table Name, Members。
其實要顯示某一個集合的所有成員，還有一個更好的方法，在本例當中這個方法就是 Get-CollectionMembers。這個 Cmdlet 會傳回一個字串陣列，代表集合中每一個成員的名稱。或許您已經猜到，這就是將管線傳給下一個 Cmdlet 的絕佳人選。
到目前為止，我們還沒有用到 SMS 進階用戶端本機原則，而只是連接到 SMS 主要站台伺服器，以及列舉集合與集合成員而已。Windows PowerShell 嵌入式管理單元範例最後出場的兩個 Cmdlet (名稱分別為 Enable-SoftwareDistribution 和 Disable-SoftwareDistribution)，才是 SMS 用戶端本機原則要派上用場的地方。最後這兩個 Cmdlet 的用途，是針對 SMS 進階用戶端上的軟體散發用戶端代理程式元件，來操作 SMS 用戶端本機原則。也許您已經從 Cmdlet 的動詞部分猜到了，Disable 會佈下一個用戶端本機原則覆寫項，指定同時停用軟體散發用戶端代理程式。同樣的，動詞 Enable 則會移除所有的用戶端本機原則覆寫項，將軟體散發用戶端代理程式還原為正常狀態，這是由 SMS 管理點交付的 SMS 原則所定義。[圖 5] 顯示了 Windows PowerShell 單行指令的範例，在軟體散發用戶端代理程式上佈下一個 SMS 用戶端本機原則覆寫項，強迫 Windows Server 2003 系統自訂集合的所有成員都停用它。移除同一集合軟體散發用戶端代理程式的所有 SMS 用戶端本機原則覆寫項的單行指令，也會一併列出。如果您只想用幾部電腦來操作 SMS 用戶端本機原則，也可以單獨使用 Disable-SoftwareDistribution 和 Enable-SoftwareDistribution Cmdlet。
Figure 5 組合 cmdlet — 範例 (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

下一步
如果您想學習將 SMS 用戶端本機原則覆寫項套用到電腦群組，本文所附的原始程式碼範例可以提供您一個好的起點。此處提供的範例只跟 SMS 軟體散發用戶端代理程式有關，而且只用到 Enabled 屬性。其他用戶端代理程式還有許多屬性，也可以用同樣的方式套用覆寫項。有了初步瞭解之後，接下來就要看看 SMS 用戶端本機原則的其他部分了。您可以想一想哪些管理系統群組可以用在 SMS 用戶端本機原則覆寫項，以及哪些本機原則覆寫項值得使用。最後的叮嚀：無論做什麼都要先明確釐清自己的方向，因此在實驗室環境中，一定要徹底測試每一個項目。

Don Brown 在 Microsoft 擔任資深首席外勤工程師，從有印象以來便開始研究並支援 SMS (就是 SCCM)，至今仍未間斷。他的連絡方式為：donbrown@microsoft.com。


 The Cable Guy: 無線單一登入
The Cable Guy
無線單一登入
Joseph Davies

使用者在建立無線連線之後，還必須以私人網路進行驗證，這對使用者和系統管理員來說都是額外的負擔。而身為 Active Directory 網域成員的 Windows 無線用戶端，必須執行 IEEE 802.1X 驗證，才能取得受保護的
無線連線和網域登入權。此外，由於驗證需要用到電腦認證或使用者認證，而且網域登入須視網路連線而定，因此在設定驗證的執行順序以及指定要使用的認證時會產生問題。凡此種種都會影響網域登入權，迫使系統多次要求使用者提出認證。
幸好，Windows Vista® 的無線單一登入可讓您指定在進行使用者登入之前，先以 Wi-Fi Protected Access 2 (WPA2)-Enterprise 和 WPA-Enterprise 進行 IEEE 802.1X 驗證，以及以無線等位私密 (WEP) 進行 802.1X 驗證，幫您解決特定設定中的網域登入問題。無線單一登入也將無線驗證與 Windows® 登入密切整合，滿足使用者的整體要求。因此，本月份我想探討一下無線單一登入的功能、如何設定無線單一登入，以及它在使用者登入時如何運作。

單一登入的基本功能
Windows 無線用戶端可以單用電腦認證或使用者認證 (或兩者兼用)，向無線網路驗證自己的身分。單用電腦認證時，Windows 會在出現 Windows 登入畫面之前執行 802.1X 驗證，這樣無線用戶端電腦可以早點存取 Active Directory® 網域控制站等網路資源。
單用使用者認證時，沒有單一登入功能的 Windows 必須等到使用者登入完畢之後，才執行 802.1X 驗證。[圖 1] 所示的是本案例的啟動和登入時間表。
[圖 1] 單用使用者認證執行無線驗證的時間表
[圖 1] 單用使用者認證執行無線驗證的時間表
如果單用使用者認證執行無線驗證，一方面沒有使用者帳戶用的本機快取認證，另一方面沒有網域控制站的連線可以驗證新的登入認證，因此使用者無法在電腦進行起始網域登入。另外，由於此時尚未連接 Active Directory 網域的網域控制站，因此無法執行部分網域登入作業，導致登入指令碼、群組原則更新，以及使用者設定檔更新失敗，產生 Windows 事件記錄錯誤。
如果同時使用電腦認證和使用者認證，Windows 會在 Windows 登入畫面出現之前，先以電腦認證執行 802.1X 驗證。待使用者登入之後，Windows 再以使用者認證執行另一個 802.1X 驗證。有的網路基礎結構會針對已經用電腦認證驗證過的電腦，以及用使用者認證驗證過的電腦，分別使用不同的虛擬 LAN (VLAN)。如果以使用者認證對無線網路進行驗證，而且使用者驗證的 VLAN 是在使用者登入程序之後進行切換，那麼 Windows 無線用戶端就無法在使用者登入時，存取經過使用者驗證的 VLAN 上的網路資源 (例如，Active Directory 網域控制站)。同樣的，這也會導致網域登入作業失敗。
如果以使用者認證執行的無線驗證，所使用的安全憑證與使用者登入認證不同，這時候會產生另一個問題。遇到這類設定，Windows 會在開始執行無線驗證時，要求使用者另外提出其他的使用者認證，這麼一來反而容易混淆視聽。
Windows Vista 中的單一登入功能，是針對解決網域登入、由電腦和使用者分別驗證 VLAN，以及在不同時間提示使用者提供不同認證等問題而開發。網路管理員可以利用單一登入，指定在使用者登入之前，先以使用者認證執行無線驗證。如果使用者登入和無線驗證所需的使用者認證不同，則 Windows 登錄畫面會要求並且收集所有必需的認證。
您可以利用單一登入，設定讓 Windows Vista 無線用戶端在使用者登入之前，以使用者認證執行無線網路驗證。[圖 2] 所示的是新的啟動和登入時間表。
[圖 2] 在使用者登入之前，以使用者認證執行無線網路驗證的時間表
[圖 2] 在使用者登入之前，以使用者認證執行無線網路驗證的時間表
這麼一來，您就可以設定單用使用者認證，或者使用電腦與使用者認證分別驗證不同的 VLAN，而且不會遺失任何功能。由於無線用戶端在使用者登入之前就有網路連線，或者有使用者驗證的 VLAN 連線，因此網域登入作業得以順利完成。如需參考範例，請參閱＜將 Windows Vista 無線用戶端加入網域＞，網址是 microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx。
根據無線設定檔的設定，單一登入會將用於無線驗證的使用者認證的輸入欄位合併起來，然後將它們加到 Windows 登入畫面中。因此，所有利用使用者認證進行使用者登入和無線驗證的使用者認證，將由使用者同時提供。
專為 Windows Vista 新 EAPHost 架構所寫的可延伸驗證通訊協定 (EAP) 方法，可以使用 EAP Pre-Logon Authentication Provider (PLAP) Support API，把驗證所需的輸入欄位加入 Windows 登入畫面中。如需詳細資訊，請參閱 SSO 和 PLAP API，網址為 msdn2.microsoft.com/bb530584。
舉一個單一登入工作階段的例子，假設 Windows Vista 無線用戶端是單用使用者認證來執行驗證，並且使用使用者名稱和密碼來執行網域登入和 802.1X 驗證。當使用者在最初的 Windows Vista 畫面上按 Ctrl+Alt+Del 時，單一登入會決定 802.1X 驗證必須在使用者登入之前執行。當使用者輸入他的使用者名稱和密碼時，單一登入會先執行使用者無線網路驗證，接著顯示一則訊息，指出它正以名稱連接無線網路。執行無線驗證之後，Windows Vista 會執行使用者登入，顯示使用者的桌面。

設定單一登入
幕後花絮
為了幫助您更加瞭解無線驗證程序，讓我們再進一步看看當使用者主動登入時，會發生什麼情況。當使用者在執行 Windows Vista 的無線用戶端上，按 Ctrl+Alt+Del 鍵要求進行使用者登入時，系統會執行下列步驟：
  1. 無線自動設定會決定使用哪一個無線網路設定檔。如果無線用戶端已經順利的以電腦認證執行驗證，則無線自動設定會使用目前連接的無線網路設定檔。如果決定採用的無線設定檔被設定成僅以電腦認證執行驗證，就不需要再以使用者認證執行無線驗證。步驟 2 到 6 假設所選的無線設定檔是設定成以使用者認證執行驗證、已啟用單一登入，以及執行設定之後立即選取使用者登入。
  2. 必要時，使用者必須輸入他的認證以執行使用者登入和無線驗證，然後起始使用者登入。
  3. Windows 會顯示一則訊息給想要連接無線網路名稱的使用者。
  4. Windows 嘗試以使用者認證執行無線網路驗證。如果啟用了 [單一登入期間允許顯示其他對話方塊] 設定，而且 EAP 類型需要對使用者顯示其他對話方塊，Windows 就會顯示這些對話方塊。如果無線驗證未能在連線延遲時間上限 (以秒為單位) 內順利執行，便放棄無線驗證。如果選取 [此網路是使用不同的 VLAN 來驗證機器和使用者的認證] 設定，則當無線驗證順利執行之後，Windows 會對無線網路介面卡執行 IP 位址設定的 DHCP 更新。
  5. Windows 會執行使用者登入程序。
  6. Windows 顯示桌面。
如果選取 [在使用者登入後立即執行] 設定，Windows 會以下列順序執行步驟：1, 2, 5, 3, 4, 6.

若要啟用和設定單一登入，可以使用無線網路 (IEEE 802.11) 原則群組原則擴充，以及針對 Windows Vista 原則的無線設定檔，設定進階安全性設定。如需相關資訊，請參閱＜Windows Vista 的無線群組原則設定＞一文，網址為：technetmagazine.com/issues/2007/04/CableGuy。
必要時，請在 [進階安全性設定] 對話方塊中，選取 [對此網路啟用單一登入]， 並在必要時設定單一登入選項。[圖 3] 所示範的是以預設值啟用的單一登入範例。
[圖 3] 預設單一登入設定值
[圖 3] 預設單一登入設定值
您會看到好幾個單一登入設定，這些設定會在使用者登入程序之前或之後，立即執行 802.1X 無線驗證，並指定使用者登入程序開始前完成 802.1X 驗證的延遲秒數。您也可以指明是否要在 Windows 登入畫面上，將對話方塊顯示在合併的輸入欄位之外。比方說，如果在進行驗證時，EAP 類型要使用者確認遠端驗證撥入使用者服務 (RADIUS) 伺服器傳來的憑證，該 EAP 類型就可以顯示這個對話方塊。
您也可以指定在執行使用者驗證之後，無線用戶端應該起始無線介面卡的 TCP/IP 設定的動態主機設定通訊協定 (DHCP) 更新。如果電腦和使用者驗證的無線用戶端各有各自的 VLAN，而那些 VLAN 是不同的 IPv4 或 IPv6 子網路，請選取這個選項。
在您建立了無線設定檔，將單一登入設定包含在原則內之後，也可以在 Windows Vista 無線用戶端上，將設定檔匯出成 XML 檔，然後再匯入 XML 設定檔，以這種方法來設定 Windows Vista 無線用戶端。
若要建立單一登入 XML 無線設定檔，請以適當的單一登入設定，建立一個無線設定檔。請在 Windows Vista 無線原則的 [一般] 標籤上，按一下具有單一登入設定的無線設定檔，然後再按一下 [匯出]。當畫面出現提示時，請指定設定檔 XML 檔案名稱及其位置。
若要使用單一登入 XML 設定檔來設定其他 Windows Vista 無線用戶端，請以下面這個命令匯入 XML 設定檔：
netsh wlan add profile filename=
    "[FileName].xml"
若要決定無線設定檔是否已經啟用單一登入，請使用：
netsh wlan show profile=[ProfileName]
單一登入設定是列在 netsh wlan show profile 命令顯示畫面的「安全性設定」區段中，以及在 Windows 事件記錄中的無線連線事件文字中。您也可以使用事件檢視器嵌入式管理單元來檢視位於應用程式和服務記錄檔的 Microsoft\Windows\WLAN-AutoConfig 資料夾中，原始碼為 "WLAN-AutoConfig" 和事件識別碼為 13001、13002、13003 和 13004 的事件。
如需相關資訊，請參閱 microsoft.com/wifi 的無線網路網頁。如需單一登入程序的詳細資訊，請參閱「幕後花絮」資訊看板。

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


 研究筆記: 使用高效能運算對抗 HIV
研究筆記
使用高效能運算對抗 HIV
Kristin Firth 和 Mia Matusow

一提到從事醫學研究工作者，您是否聯想到身穿白袍拿著試管及使用顯微鏡的男男女女？也許是大學或藥廠中的一群化學家？這些都是對於醫療研究普遍而且真實的印象，不過只能代表
這個領域的其中一個面向。在現實生活中，某些醫療研究的工作是在極端不同的情境下進行。
您也許會很訝異，其實 Microsoft Research 在研發人類免疫缺乏病毒 (HIV) 的疫苗方面扮演舉足輕重的角色。而且，Microsoft 在進行這項工作時可沒有使用任何實驗用的本生燈。工作場景就像其他常見的辦公室格局，再加上幾張普通的桌子和很多台電腦。
那麼，Microsoft 在整個研究中到底扮演什麼角色呢？身穿白袍遍佈在各所大學和研究中心的研究者 (包括美國波士頓的麻州醫院、英屬哥倫比亞大學、美國佛瑞德亨崔森癌症研究中心 (Fred Hutchinson Cancer Research Center)，以及澳洲的梅鐸大學) 都收集了大量的專案資料。由六人左右組成的 Microsoft Research eScience 小組成員大部分都在華盛頓州雷德蒙市工作 (有一人在新墨西哥州)，此 eScience 小組協助這些研究人員處理和分析龐大的資料量。Microsoft Research 於 2003 年首次接觸這類專案，今日的 eScience 小組與科學家攜手推動處理攸關社會問題的各種專案。這個小組與組織外的科學家密切合作，針對各個專案建置自訂解決方案、統計數據和分析結果。
在其中一項優先專案中，Microsoft 協助分析與 HIV 變異模式相關的資料。根據 Microsoft 的資深研究員 David Heckerman 醫學博士的說明，HIV 在受到感染者免疫系統攻擊時會急速變異。「我們目前進行的研究是要確定 HIV 如何回應宿主的免疫系統。為此，我們正在尋找個人免疫系統類型與宿主所感染的 HIV 蛋白質序列之間的關聯性。」
科學家利用 HIV 感染者的取樣來確定免疫系統類型與 HIV 序列。數據統計就在這時派上用場。這項研究需要找出 3,000 種 HIV 氨基酸與好幾百名參與者的上百種免疫系統類型之間的關聯性。「我們所設計的統計考驗可以提供更可靠的關聯性，可減少假陽性及假陰性的數目，」擔任 Microsoft 的 Principal Research Software Development Engineer 的 Carl Kadie 博士這麼說。「然而，進行這些統計考驗需要大量的運算能力，而且如果能納入越多實驗對象越好。我們的想法是要執行數百萬次的模擬來發掘最可靠的關聯性。」

使用 HPC 對抗 HIV
就在幾年前，研究成果由於運算處理的限制而受到妨礙。參與此專案的 Microsoft 研究人員只配備了六台電腦，因此缺乏足夠的運算處理能力在合理的時間內執行分析。單就 200 的實驗對象而言，尋找疫苗的基因組中的所有部位以及各種不同的免疫類型可能需要花上一整年的時間。即使研究人員有 20 台專門用來分析的電腦，仍須面對一個根本的問題，就是分別在 20 台電腦上手動執行統計考驗，接收 20 組個別的結果，而且需要其他程式 (還有更多時間) 將個別的結果組製作成表格。管理多項工作、收集部分輸出，以及其他所有相關的各項任務都需要花費太多時間。因此他們向 Microsoft 的高效能運算 (High-Performance Computing，HPC) 小組尋求協助。
在 2006 年，研究人員實作了 Windows® Compute Cluster Server 2003。此 HPC 解決方案為研究人員提供一個直接了當的方法來管理多台同時作業的電腦。基本上，Windows Compute Cluster Server 可將工作分散到平行執行的數個伺服器節點上。將資料分散到各節點、管理資料和合併結果等任務全都自動化完成。這個解決方案包括安裝程序、管理工具套件以及整合的工作排程器。
最後，有了這套解決方案，便可克服最大的技術障礙：運算能力不再受限，且分散工作和管理資料的作業皆已完全自動化。

安裝
對 Microsoft Research 來說，運算叢集方法非常理想。Windows Compute Cluster Server 2003 特別適合需要應用程式不斷執行相同作業的專案；例如當平行執行任務可加速問題解決與分析的情況時。不過，此解決方案的部署作業不能輕忽，因為高效能運算可能需要大筆資金 — 尤其是在電源和冷卻方面。這個解決方案往往需要多部伺服器接連幾週都以 100% CPU 使用率的狀態執行。
接下來的步驟是確定組織所能負擔的最大叢集，以及存放叢集的位置。如果環境中已具備 Windows 架構且 Active Directory® 也已就緒，系統管理員就具有安裝、部署和支援叢集所需的基礎結構。至於在尚未使用 Active Directory 的環境中，則需要進行一些額外的設定步驟。
您還必須決定如何在運算叢集中佈建節點，這意味著選擇是否要使用 Windows Compute Cluster Server 2003 隨附的工具，或使用自己內部的部署方法。您需要部署 Windows Compute Cluster Server 2003 本身以及您要在叢集上執行的軟體應用程式。此外還必須建立叢集的使用者存取，好讓使用者能夠連線到叢集並提交工作，這個步驟可以透過內含的圖形 UI 或經由命令列介面來完成。
Windows Compute Cluster Server 2003 是 64 位元的作業系統 (Windows Compute Cluster Server 2003 環境的典型架構如 [圖 1] 所示)。在撰寫本專欄時 (2007 年 6 月)，Microsoft Research 正於由 25 部 IBM eServer 326 伺服器所建置的叢集上執行各式各樣的應用程式。其中的每一部伺服器都配備了兩顆以 2.6 GHz 執行的 AMD Opteron 處理器。
[圖 1] 使用 Windows Compute Cluster Server 2003 駕馭運算能力
[圖 1] 使用 Windows Compute Cluster Server 2003 駕馭運算能力
完成 Windows Compute Cluster Server 的部署之後，小組更新了用在叢集上執行以進行基因關聯性的應用程式。運算叢集在部署應用程式時所面對的複雜度可能不盡相同。應用程式本身會影響需要進行多少程式設計作業。
首先，小組使用 Windows Compute Cluster Server 內建的工具以快速建立一般 UI。但這只是一個緩衝之計，因為小組很快地便建立了自訂的 Web 應用程式，以便提供更大彈性並支援將部分叢集節點的選項公開給 Microsoft 組織以外的科學家。事實上，Microsoft 屬於開放式網格運算論壇的 (Open Grid Forum) 的一員，有些 Microsoft Research 叢集可提供來自世界各所大學的使用者存取，藉此促進研究人員的合作以及分擔工作量。
除了圖形 UI，Windows Compute Cluster Server 也支援命令列作業，讓使用者撰寫指令碼。而且它還提供豐富的 API，可用來撰寫直接與 Windows Compute Cluster 工作排程器互動的程式 — Microsoft Research 也採用了這項技術。

獲得成效
多虧運用了高效能運算，Microsoft Research 的 eScience 小組在開發 HIV 疫苗的競賽中大幅超前。「藉由高效能運算，我們終於能夠更快速地掌握分析結果，」Heckerman 如是說。「與我們共同合作的好幾個外部團體現在都使用我們的統計技術並分享他們的發現成果。而科學家也因此提出新的假設來讓我們進行驗證。過去，光要取得每一個程序步驟的結果就得花上一年，現在卻只要一天。」
Windows Compute Cluster Server 出現之前，Microsoft Research 使用的方法執行分析所需的時間過長，因此不切實際。Kadie 說，「有了 Windows Compute Cluster Server，我們可以執行含 200,000 個工作項目的 50 項工作，以前花同樣的時間只能執行 1 項工作。」
現在 eScience 小組擁有唾手可得的強大運算功能，便可以大量執行模擬資料來進行統計考驗。在模擬資料上執行的作業，是判斷哪些真實資料的結果值得注意的關鍵。所執行的模擬越多，所得到的結果也就越可靠。

心得
Microsoft Research 明顯受惠於使用 Windows Compute Cluster Server，但彼此之間的關係是共生共榮的。高效能運算 (High-Performance Computing) 小組中的開發人員目前正在研發第二版的 Windows Compute Cluster Server，他們將繼續吸收 eScience 小組提供的寶貴意見。
最重要的是，透過監視與分析 Microsoft Research 叢集的行為以便找出最好的方式來平衡多位使用者間的叢集資源，HPC 小組學習到許多關於資源配置的知識。比方說，在這個專案中，使用者通常一次會建立一項工作，而且每項工作平均包括 50 個相關任務。使用者提交工作，Windows Compute Cluster Job Manager 接著會配置足夠的資源來管理這 50 項任務。為了這麼做，它會立刻要求叢集上所有可用的節點都用來處理這些任務。這在單一使用者的環境中可能不會造成問題，但是在多位使用者的設定中，各項專案必須同時進行，因此會產生問題。
以目前來說，當工作的 50 個任務中的 10 個任務完成時，並不會馬上釋放 10 部伺服器。作業管理員會等待這個工作內的 50 個任務全都完成，才會釋放伺服器以處理另一項工作。HPC 開發人員現在正設法在每個任務 (而非整個工作) 完成時重新配置資源。
Microsoft Research 也期望 HPC 小組能夠針對研究人員希望使用 Windows Compute Cluster Server 的方式而產生的特定問題，提供解決的方法。值得一提的是，研究人員想要設定安全性，好讓使用者憑證從 Web 前端自動傳播到電腦叢集中。解決方案是在 Microsoft® .NET Framework 內部進行處理，並延伸 ASP.NET 表單驗證，如此一來，Web 應用程式就能夠在每次使用者提交工作時，提供完整的使用者驗證給叢集節點。
Microsoft Research 的 eScience 小組成員與來自世界各地的同仁現在能夠專注在最重要的工作環節上，至於處理和管理資料的相關任務就交由電腦執行。「因此，我們能夠以團隊方式往前邁進，」Heckerman 這麼說。「我們擴展了 HIV 的相關知識領域，並且在對抗這個疾病的努力上有長足的進展。」

Kristin Firth 和 Mia Matusow 均任職於 Blue Line Writing & Editing，過去十年來致力於為三大洲的企業組織公私領域打造策略內容。


 Windows PowerShell: 撰寫規則運算式
Windows PowerShell
撰寫規則運算式
Don Jones

192.168.4.5，\\Server57\Share，johnd@contoso.com，不用說，您一定認得出這三個項目分別是 IP 位址、通用命名慣例 (UNC) 路徑，以及電子郵件地址。您的大腦辨識出它們的格式，四組數字、反斜線、@ 符號，以及其他線索指出了這些字元所代表的
資料類型。不用多想，您很快就能辨識出 192.168 本身並不是有效的 IP 位址，7\\Server2\\Share 不是有效的 UNC，還有 joe@contoso 不是有效的電子郵件地址。
不幸的是，電腦要下更多的功夫，才能了解這類的複雜格式，而此時規則運算式就派上用處了。規則運算式是使用特殊的規則運算語言寫成的字串，它可幫助電腦識別特定格式的字串 — 例如 IP 位址、UNC，或是電子郵件地址。撰寫得當的規則運算式能夠讓 Windows PowerShellTM 指令碼接受為有效資料，或將不符合您指定格式的資料拒絕為無效。

進行簡單的比對
Windows PowerShell –match 運算子會將字串與規則運算式 (或稱 regex) 相比較，然後根據字串是否符合 regex 傳回 True 或 False。一個極為簡單的 regex 甚至根本不需要包含任何特殊語法 — 文字字元就綽綽有餘。例如：
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
在 Windows PowerShell 中執行時，前兩個運算式會傳回 True，而第三個運算式會傳回 False。每個當中的字串後面都會加上 –match 運算子，隨後再加上 regex。根據預設，regex 會在字串間浮動以尋找相符的項目。Software 和 Microsoft 中同時可以找到「soft」字元，但位於不同的位置。另外也要注意的是，regex 依預設不區分大小寫 — 「Software」中的 S 儘管是大寫，還是在當中找到「soft」。
但是如果必要的話，可使用不同的運算子 –cmatch，它提供有區分大小寫的 regex 比較，如下所示：
"Software" –cmatch "soft"
由於「soft」字串在區分大小寫的比較當中與「Software」不符，因此這個運算式傳回 False。請注意，儘管 –match 的預設行為是不分大小寫，您還是可以使用 –imatch 運算子作為明確不分大小寫的選項。

萬用字元和重複項
Regex 可包含數個萬用字元，舉例來說，句點對應任何字元的一個例項。而問號則對應任何字元的零或一個例項。下面有幾個說明的範例：
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
在第一個運算式中，句點代表單獨一個字元，所以比對為 True。在第二個運算式中，句點找不到可以包含它的字元，所以比對為 False。如第三和第四個運算式所示，問號可以對應單一未知的字元或完全不對應任何字元。最後，在第四個範例中，找到「D」和「n」因為它們之間沒有任何字元，所以比對為 True。因此，問號可以想成是代表選用字元，所以即使該位置中沒有出現任何字元，比對還是 True。
Regex 也可以將 * 和 + 符號視為重複項。不過這些需要跟隨在一些字元後面。* 對應零或更多的指定字元，而 + 符號則對應一或多個指定字元。這裡列出一些範例：
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
請注意 * 和 + 兩者都比對「Do」，而不只是「o」。這是因為這些重複項是針對一連串字元，而不只是一個字元而設計的。
要是您需要對應句點、*、? 或 + 符號本身呢？只要在它們前面加上反斜線就行了，這是 regex 的逸出字元：
"D.n" -match "D\.n" (True)
請注意，這跟 Windows PowerShell 的逸出字元 (反向簡縮號) 不同，但遵循的是業界標準的 regex 語法。

字元類別
字元類別是範圍更廣的萬用字元，代表著整個字元群組。Windows PowerShell 可識別出好幾種字元類別，例如：
  • \w 對應任何文字字元，包括字母和數字。
  • \s 對應任何空白字元，例如定位點、空間等。
  • \d 對應任何數字字元。
另外還有否定的字元類別：\W 對應任何非文字字元，\S 對應非空白字元，還有 \D 對應非數字字元。這些類別的後面可以加上 * 或 + 來表示可以接受多重符合項。這裡列出一些範例：
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
本月 Cmdlet
Write-Debug Cmdlet 用在寫入物件 (例如文字字串) 至 Debug 管線時相當實用。不過將這個 Cmdlet 用在命令介面中時可能會讓您有點失望，因為它看起來無所事事。
問題出在 Debug 管線預設是關閉的 — $DebugPreference 變數是設定為 "SilentlyContinue"。不過將它設為 "Continue"，您使用 Write-Debug 傳送的所有內容就會以黃色文字顯示在主控台上。這是在指令碼中新增追蹤程式碼的最佳方法，讓您能夠遵循複雜指令碼的執行動向。黃色有助您將追蹤行跡和指令碼的正常輸出相區別，並且您可以隨時關閉偵錯訊息，而不需要移除所有的 Write-Debug 陳述式。只要再次設定 $DebugPreference = "SilentlyContinue"，偵錯文字就會隱藏起來。

雖然兩種運算式都會傳回 True，但它們比對的內容是天差地別。所幸，有種方法可以看出 –match 運算子骨子裡到底在打什麼主意：每次找出相符的項目，符合的結果中 — 也就是運算子針對您的 regex 在字串中找到的任何字元 — 會隨著填入一個稱為 $matches 的特殊變數。$matches 變數會保留它的結果，直到使用 –match 運算子進行另一次比對符合為止。[圖 1] 說明剛剛提到的兩個運算式之間的差別。如您所見，\w 對應到「Shell」中的「S」，而重複的 \w* 對應到整個字。
[圖 1] 用不用 * 的差別有多大
[圖 1] 用不用 * 的差別有多大

字元群組、範圍和大小
Regex 也可以包含字元群組或字元範圍，以方括弧括住。例如，[aeiou] 表示當中任何一個內含的字元 — a、e、i、o 或 u — 都算是相符項目。[a-zA-Z] 指出介於範圍 a-z 或 A-Z 間的任何字母都可接受 (不過假如您是使用不分大小寫的 –match 運算子，那麼只要使用 a-z 或 A-Z 就夠了)。請看以下範例：
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
您也可以使用大括弧來指定字元的最小和最大數量。{3} 表示您只想要三個指定的字元，{3,} 意謂您想要至少三個或以上，而 {3,4} 則表示您想要至少三個但不超過四個。這是為 IP 位址建立 regex 的理想方法：
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
這個 regex 想要四組的數字，每個各含一到三個數字，全都以文字句點分隔。但是先考慮一下這個範例：
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
這顯示出 regex 的限制，雖然此字串的格式看起來像 IP 位址，但它顯然不是有效的 IP 位址。Regex 不能判斷資料是否真的有效，它只能判別資料看起來對不對。

停止浮動
疑難排解 regex 的問題可能需要點技巧。舉例來說，這裡有一個以 \\Server2\Share 格式來測試 UNC 路徑的 regex：
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
這裡的 regex 本身並不容易閱讀，因為我想要測試的每個文字反斜線都必須使用第二個反斜線逸出。這看起來似乎沒問題，其實不然：
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
第二個範例很清楚地 (至少對您對我來說) 不是有效的 UNC 路徑，但是 regex 卻舉旗通過。為什麼呢？記得 regex 預設會浮動嗎？這個 regex 只是尋找兩個反斜線，一或多個字母和數字，另外一個反斜線，以及更多字母和數字。字串中反覆著這種模式 — 加上前面有多餘的數字，使它成為無效的 UNC。訣竅是告訴 regex 從字串的開頭開始比對，而不要浮動。我像下面這麼做來達到這個目的：
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
^ 字元指出這是字串開始的位置。加上這個字元，這個無效的 UNC 路徑就不符合條件，因為 regex 現在會尋找前兩個字元必須是反斜線，而在此例中，它們並不是。
同樣地，$ 符號可用來表示字串的結尾。這在 UNC 路徑的例子不是很有用，因為 UNC 路徑可以包含額外的路徑區段，比方說 \\Server2\Share\Folder\File。不過，我確定您想要指定字串結尾的情況多得很。

提供規則運算式的協助
在 Windows PowerShell 中，about_regular_expressions 說明主題提供了 regex 語法的基本語法協助，但是線上資源提供的資訊更多更豐富。譬如，我最喜愛的網站之一，www.RegExLib.com，提供了免費的規則運算式程式庫，這些針對不同目的寫成，而且是由同好者貢獻的。您可以搜尋關鍵字，例如「e-mail」或「UNC」，迅速找出符合您需要的 regex — 或者至少提供一個不錯的出發點。如果您恰好建立了一個很棒的 regex，可以將它貢獻到程式庫，讓其他人也可以利用。
我也蠻喜歡 RegexBuddy 的 (www.RegexBuddy.com)，這是一個花費不多的工具，提供圖形化的 regex 編輯器。RegexBuddy 使複雜的 regex 組合起來更加容易，這項工具也讓測試 regex 更加簡單，確定它確實接受有效的字串並拒絕無效的字串。還有許多其他軟體開發人員也建立了免費的、分享的及商用的 regex 編輯器和測試工具，使用者肯定會覺得實用。

使用規則運算式
您可能會質疑在真實生活中怎麼用得到 regex。想像您正從 CSV 檔案讀取資訊，然後使用該資訊在 Active Directory® 中建立新使用者。如果 CSV 檔案是由別人產生的，您會想要驗證當中資料的正確性。而 regex 正適合執行這類工作。舉例來說，一個像是 \w+ 的簡單 regex，可以確認姓氏和名字沒有包含任何特殊的字元或符號，而比較複雜的 regex，則可以確認電子郵件地址符合您的公司標準。例如，您可以使用：
"^[a-z]+\.[a-z]+@contoso.com$"
這個 regex 要求電子郵件地址必須是 don.jones@contoso.com 的格式，當中姓氏和名字只能包含字母，而且它們必須以句點分隔。順帶一提，寫電子郵件地址的 regex 很麻煩。如果您可以將範圍縮小到特定的公司標準，就比較省事。
別忘了那些開始和結束錨點 (^ 和 $)，它們可確保 contoso.com 後面沒有任何字元，還有組成使用者姓氏的字元前面也沒有其他字元。
在 Windows PowerShell 中實際運用這個 regex 相當簡單。假設變數 $email 包含您從 CSV 檔案讀取的電子郵件地址，像下面這樣的內容可以檢查它是否有效：
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
您在這個範例中學到了一個新運算子，如果字串不符合提供的 regex，-notmatch 會傳回 True (另外有一個 –cnotmatch 用於區分大小寫的比較)。
關於規則運算式，我在這裡還有很多都沒有提到 — 其他字元類別，更進階的作業，其他運算子。另外還有 Windows PowerShell 支援的 [regex] 物件類型。不過，這裡大略介紹的 regex 語法應該就足以讓您動手試試。如果您需要幫忙解決特別麻煩的 regex 難題，歡迎您隨時到 www.ScriptingAnswers.com 來拜訪我。

Don Jones 是《Technet Magzine》的特約編輯，也是《Windows PowerShell:TFM》(SAPIEN Press) 的作者之一。他教授 Windows PowerShell (www.ScriptingTraining.com)，您可以透過 ScriptingAnswers.com 網站與他連絡。


 嗨，Scripting Guy！: 遠從墳墓裡執行桌面管理
嗨，Scripting Guy！
遠從墳墓裡執行桌面管理
Microsoft Scripting Guy
下載本文程式碼: HeyScriptingGuy2007_11.exe (151KB)

為了回應廣大讀者的 要求，本月我們打算來點不一樣的：文章一開始我們不討論任何系統管理指令碼，而是要講一個鬼故事 (恐怖的配樂響起)！
附註：好吧，嚴格來說，如果本月真的要做一點與眾不同的事，那麼開頭就應該先來談一談系統管理指令碼。不過配合我們演一下，好嗎？謝謝啦！
多年前，有一位 Scripting 曾曾曾祖母過世了。就在祖母躺進儉樸的木製棺材後，祖父開始作惡夢，在惡夢中，他的愛妻拼命想要爬出墳墓。經不起惡夢連連的祖父不斷哀求，相關單位終於同意挖出屍體。棺木打開時，眾人驚見祖母的指甲都已折彎，而且棺材內部佈滿抓痕！
好啦，這個故事不見得百分之百真實；事實上，這個故事越想越覺得不可能是真的。不過，它還是告訴我們一個很重要的教訓。是什麼教訓我們不曉得，不過一定有。
等一下，想起來了！棺材原本的用意是要保護往生者免受打擾，也是為了防止軀體分解。不幸的是，這些棺材可能造成無心之過：理論上，棺材可讓您活埋生人，而且他永遠逃不出來。Scripting 曾曾曾祖母的故事清楚地告訴我們，人算不如天算，再周詳的計畫也可能以災難收場，還可能生人活埋！(恐怖的配樂再度響起。)
請注意：當然，除非您選用 1860 年 Franz Vester 發明的「改良式棺材」，這又另當別論。這副棺材裡有一條線連接到地面上的鈴鐺；如果有人一息尚存卻被埋進土裡，那麼「死者」只要搖一下鈴就可以求救。「改良式棺材」還配備一個摺疊梯，只是我們不太清楚您要怎麼使用摺疊梯，從六呎深的地底逃出生天就是了。如果您碰巧埋在某人的車庫屋頂上，此時摺疊梯就很有用了。不然的話 ....
同樣的事情 (也就是人算不如天算引發災難的事情) 也印證在網際網路防火牆上(嗯，也算是啦)。防火牆的設計初衷是要把壞人擋在門外：封鎖連入網路流量，藉此讓駭客和入侵者遠離您的電腦。這是很棒的功能，但是 — 就像活埋的問題一樣 — 也會造成無心之過：防火牆也會把好人擋在門外。尤其當 Windows® Management Instrumentation (WMI) 依賴 DCOM 在遠端電腦上執行系統管理工作時，更是如此。防火牆傾向封鎖所有連入 DCOM 流量，因此要透過程式設計的方式在網際網路上管理電腦很難，甚至是根本不可能。事實上，若未開放額外的連接埠，因而讓您更容易遭受駭客與怪客 (Cracker) 的入侵，就完全不可能執行這項作業。當然，除非您選擇 WinRM：Windows 遠端管理 (不附摺疊梯)。

什麼是 Windows 遠端管理？
根據 WinRM SDK (msdn2.microsoft.com/aa384426)，Windows 遠端管理是「Microsoft 的 WS-Management 通訊協定實作，它是以 SOAP 為主且與防火牆互動良好的標準通訊協定，可讓不同廠商的硬體與作業系統交互操作」。怎麼樣，厲害吧？本月專欄不會討論 WS-Management 通訊協定的細節，因此建議您閱讀 WinRM SDK 以瞭解詳細資訊。目前我們只在乎 WinRM 可以用於 Windows Server® 2003 R2、Windows Vista® 及 Windows Server 2008，還可讓您透過網際網路管理電腦。WinRM 使用連接埠 80 來執行這項工作，連接埠 80 是大部分防火牆都開放的標準網際網路服務連接埠 (不過，WinRM 使用的連接埠和預設的傳輸機制 HTTP 可以視需要變更)。
我們也不會在本月專欄中討論如何安裝及設定 WinRM。因為已經有很多資訊可以協助您 (msdn2.microsoft.com/aa384372)。但是，我們要強調一個重點：若您要使用 WinRM 從遠端電腦擷取資訊 (當然，這是之所以開始使用 WinRM 的主要原因)，那麼本機電腦和遠端電腦都必須執行 WinRM。
這是什麼意思呢？意思是，如果您未升級用戶端電腦到 Windows Vista (您不會還沒升級吧！)，或者您的伺服器尚未升級到 Windows Server 2003 R2 或 Windows Server 2008，您就不會覺得 WinRM 特別好用，至少目前是如此。而且不用說，未來也不見得會變得好用 (當然，只要防火牆允許的話，您始終可以使用 WMI 和 DCOM 管理遠端電腦)。

傳回類別的所有屬性和執行個體
雖然有這些林林總總的限制和規定，但是誰在乎呢？撇開這些胡言亂語不談，我們來試試看如何撰寫使用 WinRM 的指令碼。還真巧，我們剛好有一小段指令碼是使用 HTTP 通訊協定和連接埠 80 來連線到名為 atl-fs-01.fabrikam.com 的電腦，然後傳回有關該電腦所安裝的全部服務的完整資訊。請參閱 [圖 1] 中這段了不起的指令碼。
Figure 1 Silverlight 專案元件 (Close Figure 1)

檔案 | 描述
CreateSilverlight.js | 這是指定起始 Silverlight 開機設定所用的 JScript 指令碼 (初版的 Silverlight 只支援 JScript 指令碼)，其中包括設定使用者介面和圖形物件所用的 XAML 檔。
SampleProject.js | 這是讓您放置 JScript 函數用的一個空檔。
Silverlight.js | 這個檔案的目的，是將 Silverlight 控制項初始化。
SampleProject.html | 這就是做出所有好玩效果的地方。SampleProject.html 只是一個 HTML 檔，其中包含讀取三個 .js 檔的程式碼。同時它也包含將 Silverlight 控制項具體化的程式碼。
SampleProject.xaml | 這是做什麼用的？想知道答案，就回到本專欄的本文吧。
Figure 1 列出遠端電腦上的服務 (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
如您所見，我們一開始先將電腦 (atl-fs-01.fabrikam.com) 的 DNS 名稱指派到稱為 strComputer 的變數。或者，我們可以使用電腦的 IP 位址 (甚或是 IPv6 位址) 來建立連線。例如：
strComputer = "192.168.1.1"
指派 strComputer 的值之後，我們接著建立 WSMan.Automation 物件的執行個體，然後呼叫 CreateSession 方法以連線至遠端電腦，在此是使用 HTTP 通訊協定 (就像我們剛才說過的)：
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
之前提到，我們要傳回遠端電腦上安裝的服務資訊。此外，至少就這個範例來說，我們還想取得關於每個服務的所有屬性資訊。這是什麼意思呢？這表示我們必須指定一個 URI 資源，以便將我們繫結到遠端電腦上的 Win32_Service 類別：
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
即使這個 URI 不算是我們見過最漂亮的 URI (但是仔細想想，我們好像還沒看過什麼漂亮的 URI)。不過還好，大部分的 URI 都是現成的；您只需要注意結尾處的 WMI 路徑即可：
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
這個部分應該蠻簡單明瞭的。假如您想要連接到 root/cimv2/Win32_Process 類別，該怎麼做？只要照此修改 URI 路徑就好了：
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
對 root/default/SystemRestore 類別感興趣？還是一樣，只要修改 URI 類別，小心指定預設的命名空間 (而非 cimv2 命名空間)：
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
然後依此類推......有點麻煩的是您也必須加入 URI 的 http://schemas.microsoft.com/wbem/wsman/1/wmi 部分，但也無可奈何......
我們現在已經準備好取回某些資料。為此，我們直接呼叫 Enumerate 方法，將變數 strResource 當作單一方法參數傳送：
Set objResponse = _
  objSession.Enumerate(strResource)
這一行程式碼真的會將電腦 atl-fs-01 上安裝的服務相關資訊填入 objResponse 中嗎？當然會。但是與標準 WMI 指令碼不同，您將不會取回一連串的物件，而且每個物件都包含自己的屬性及屬性方法。相反地，您取回的是一個大型的舊 XML Blob，看起來有點類似 [圖 2]。
Figure 2 漂亮的顏色 (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Figure 2 大型的舊 XML Blob (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
如果您是 XML 老手，這就難不倒您；熟悉 XML 的人應該都能夠輕而易舉地剖析和輸出此資訊 (即便如此，根據 WinRM SDK 的描述，此資訊仍然不屬於「適合人類閱讀的格式」)。但是，萬一您不是 XML 老手呢？在這種情況下，您有兩個選擇。第一個選擇是，您可以等到下個月，到時我們會示範幾個處理 WinRM XML 的技巧。或者您可以套用我們在範例指令碼中的做法：使用與 WinRM 一起安裝的 XSL 轉換。

XSL 轉什麼換？
XSL 轉換只是一個描述如何顯示 XML 檔案的範本。XSL 檔案的詳盡說明不屬於本月專欄的討論範圍 — 而且就算是簡略介紹 XSL 檔案也超出本月專欄的篇幅。因此，我們不打算解釋 WsmTxt.xsl (內建轉換的名稱) 的實際運作方式。相反地，我們只要示範如何在您的指令碼中使用此轉換。
呼叫 Enumerate 方法時，WinRM 傳回資料流。處理此資料最簡單的方法就是設定一個 Do Until 迴圈，這個迴圈會持續執行直到達到資料流尾端為止。在此我們就是這樣執行：
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
如您所見，我們在迴圈中呼叫名為 DisplayOutput 的副程式。當我們呼叫此副程式時，我們也一起傳送資料流的 ReadItem 方法值做為副程式參數 (從這整個過程可以看出，XML 資料流將會分成不同部分傳回，而非一整個大型的資料 Blob。於是我們的指令碼會逐個部分或逐個項目讀取 XML 資料)。
另一方面，DisplayOutput 副程式如下所示：
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
總而言之，我們一開始先建立 MSXml2.DOMDocument.3.0 物件的兩個執行個體；將 XML 資料流 (strWinRMXML) 載入其中一個物件中，再將 XSL 檔案 (WsmTxt.xsl) 載入另一個物件中。這時，我們呼叫 TransformNode 方法來使用 XSL 檔案中的這些資訊進行格式化並顯示從 XML 抓取的資料。
沒錯，的確有點複雜。不過至少輸出 (雖然離完美還很遠) 比較容易讀懂 (見 [圖 3])。
Figure 3 為文字上色 (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Figure 3 整齊的 XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
我們說過了，這個結果還可以，但不是最棒的，因此您更要密切注意下個月的專欄，我們會教您幾個方法來自行操控 XML 輸出。

傳回類別的選定執行個體和屬性
毫無疑問地，以上所說的的確很精彩，但是有個問題：這可能並不完全符合您平常工作的模式。沒錯，有時候您會想要傳回類別的所有執行個體的所有屬性；不過，有時候 (而且可能這種時候更常見) 您只想要傳回類別的選定屬性或執行個體。舉例來說，您可能只想要傳回執行中服務的相關資訊，這時您會使用如下的程式碼在一般 WMI 指令碼中這麼做：
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
還不錯，但是您要如何修改 Resource 字串才能達到相同的目的？
老實說，您不用將 Resource 字串修改的像 ExecQuery 陳述式一樣。您確實需要修改 Resource 字串，而且還需要採取其他一些動作。
知道這一點之後，讓我們來看一下 [圖 4]。其中的 WinRM 指令碼會傳回在電腦上執行的服務的相關資訊 (而非安裝在電腦上的所有服務)。
Figure 4 TextBlock 竅門 (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Figure 4 尋找執行中的服務 (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
乍看之下，這個指令碼可能與之前顯示的第一個 WinRM 指令碼完全相同；但其實有一些重大差異。首先來看一下我們指派給 Resource 字串的值：
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
請注意，在撰寫篩選查詢時，我們並未指定要處理的實際類別名稱 (Win32_Service)；而是直接連接到該類別所在的命名空間 (root/cimv2)。只要記得在結尾加上星號 (*)。若未加上星號，指令碼將會失敗並出現「......類別名稱必須是 '*' (星號)」，也就是說必須以 * 表示類別名稱。
此外，我們還需要定義 Filter 和 Dialect：
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
Filter 應該很容易理解；我們會在此放入 Windows Management Instrumentation 查詢語言 (WQL) 查詢 ("Select * From Win32_Service Where State = 'Running'")。另一方面，Dialect 則是用於建立 Filter 的查詢語言。這時候只允許一種查詢語言：WQL。但是必須指定 Dialect，否則指令碼就會失敗並附註「不支援篩選器方言......」。
請注意：有趣的是，此錯誤訊息建議您在呼叫 Enumerate 方法時移除 Dialect。您最好不要聽取這個建議。執行篩選查詢時，一定要指定 Dialect，而且必須是 WQL。就這麼簡單。
我們只需要在呼叫 Enumerate 方法時再進行另一項變動。屆時，我們需要傳送代表 Filter (strFilter) 和 Dialect (strDialect) 的變數，以及代表 Resource (strResource) 的變數：
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
試試結果如何吧。
那麼，要如何只傳回選定的類別屬性呢？舉例來說，假設您只想要傳回在電腦上執行的所有服務的 Name 及 DisplayName。那該怎麼做？
在這種情況下，您可以嘗試操控 XML，以便只顯示 Name 和 DisplayName。這是可行的，但絕對比較困難。比較簡單的方法是在指派 Filter 時，只指定那些屬性：
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
這麼做之後，您就只會取得每個服務的 Name 及 DisplayName，如下所示：
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
不過，這個格式好像有點蠢。(XmlFragment 到底怎麼了？)這也是下期專欄非看不可的好理由。

靜心等待
還好，本月專欄的內容應該可以讓您開始探索 WinRM 奇幻世界。當然，在 WinRM 專欄結尾之前，我們不得不提一下在德國一度盛行的「等待期太平間」(Waiting Mortuaries)。設立等待期太平間的城市不會立刻埋葬屍體。相反地，屍體會放置在溫暖的房間裡，並在手腳指頭上纏上細線。當然，這麼做的用意為了讓任何輕微的動作都可觸發警鈴以求助。屍體會停放在這些溫暖的太平間，直到這些人顯然回天乏術，再也動不了為止。
這麼一說，等待期太平間跟被派到 Scripting Guys 小組頗有異曲同工之妙，不是嗎？當然，等待期太平間從來無人復生，反倒是被派到 Scripting Guys 小組的人則......

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
2007 年 6 月，Scripting Guy 參加佛羅里達州奧蘭多市舉辦的 2007 年 TechEd 會議。光是參加會議不能滿足我們，因此我們決定找點樂子。不只如此，我們覺得大家也都需要調劑一下。因此我們發明了 Dr. Scripto 的遊戲書 (Fun Book)，這本小冊子裡充滿與指令碼有關的猜謎以及其他各種小知識。我們夥同《TechNet Magazine》 — 也就是說，我們說服他們讓出他們在展覽會場攤位的一個小角落 — 然後分發這本遊戲書給經過的人。
結果證明，遊戲書大受好評 (雖然可能沒有 Dr. Scripto 搖頭玩偶那麼受歡迎，不過也很接近了)。這些親切又投機的《TechNet Magazine》同事，馬上看到又多了個機會可以利用 Scripting Guy 的成功謀利 (因為 Scripting Guys 總是沒辦法從自己的成功上獲利)，因此拜託我們替他們設計一些猜謎。當 Scripting Guy Jean Ross 才一轉身沒多久的時間，Scripting Guy Greg Stemp 馬上就說：「沒問題，交給我們！」。隆重介紹：Dr. Scripto 的指令碼謎題 (Scripting Perplexer)。好好享受吧。

掉落指令碼
在這個猜謎中，上半部的所有字母恢復原狀後可建立一個指令碼 (VBScript)。不過別擔心，您不需要將整個指令碼恢復原狀；而是只要一次恢復一欄。在上半部的每一欄中的字母填入下半部相同欄的空格中。請看以下範例：
如您所見，在第 1 欄中有字母 S、C 和 T。這三個字母應該以某種順序置入底下的格子中。當所有字母都以適當的順序落下，底端的格子 — 閱讀方向從左到右 — 就會產生邏輯。請看一下解法：
您可以看到，第 1 欄中的字母 S、C 和 T 依照 T、S 和 C 的順序落下。結果就成了「The Script Center」這幾個字的首字母。實際的猜謎比較困難一點，因為長度較長，而且最後的解答會是完整的指令碼。
提示：最後的指令碼答案一開始是檔案完整路徑，接著剖析並顯示檔案名稱。
祝您好運！

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：掉落指令碼，2007 年 11 月
在這個猜謎中，您需要讓欄中的字元掉入底下正確的方塊中，好讓底部形成一列指令碼。獨立指令碼如下：
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
在猜謎格子中看起來像是：

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


 安全性監控: 安全地隨處存取
安全性監控
安全地隨處存取
John Morello

連線和行動工作力日益增加，是現今科技發展不容否認的趨勢。許多公司的工作人員，不是坐陣在遙遠的辦公室，就是使用電腦在家工作，再不然就是經常外出拜訪客戶。如果能夠讓這些使用者更方便的存取應用程式和資料，不受地點限制，應該可以提高他們的
產能。不過，在不久前，一般人還是認為所謂安全的遠端存取，是安裝用戶端軟體、輸入 arcane 命令，以及長時間的連線。
過去數年來的確發展出幾種方便遠端存取的方法。Outlook® Web Access (OWA) 就是其中一種，它不像完整的第 3 層 VPN 這麼複雜，使用者只要使用它所提供的瀏覽器，就能存取電子郵件、行事曆和連絡人資訊。這類技術對於「隨處存取」解決方案的確有相當大的助益，不過企業大多擁有許多重要的應用程式，無法容許這種整合式瀏覽器。遇到這種情況，可以派上用場的就是終端機服務這一類的解決方案，一樣可以讓使用者隨處有效存取自己的應用程式。
Microsoft 在 Windows Server® 2008 大大加強了終端機服務的「系統內附」功能組合。現在，終端機服務納入了使用流暢的視窗、稱為 RemoteApp 的應用程式專屬發佈功能、EasyPrint 所附的通用列印驅動程式功能，以及稱為 TS Web Access 的瀏覽器入口網站。另外，Windows Server 2008 還附隨 TS 閘道元件，這個元件所提供 SSL 封裝，透過它，遠端桌面通訊協定 (RDP) 能夠更方便而安全地周遊在防火牆和網路位址轉譯 (NAT) 裝置之間，這一點對於隨處存取案例相當重要。TS 閘道功能還也整合了 Windows Server 2008 的另一項新技術 — 網路存取保護 (NAP)，用於端點用戶端的健康檢查。當這些元件全部結合起來時，就賦予公司建立解決方案的能力，幫助使用者更方便且更安全的從任何地方存取他們的應用程式和資料。
本專欄將側重隨處存取解決方案的網路和安全性設計，有關管理終端機服務元件等細節則暫不討論。本文將透過 Windows Server 2008 的幾項技術，說明建立這類解決方案的方法和最佳作法。

第 3 層虛擬私人網路有哪些問題？
不管是哪一種新技術，都必須透過與當前方法比較，瞭解優勢，看出新技術的價值。以傳統的第 3 層 VPN 為例，它有兩個主要問題需要解決：安全性與方便性。
把當前許多第 3 層 VPN 的安全性視為問題，似乎自相矛盾。VPN 不就是在提供網際網路的安全通道嗎？為了瞭解這一點，讓我們把視界提高，想想看有哪些是 VPN 威脅。我並不是暗示通過這些 VPN 的資料有攔截或篡改的風險，其實現今大部分第 3 層 VPN 所提供的資料流加密技術都相當優秀。我只是要提醒您來自遠端機器的威脅，這些遠端機器對於貴公司的網路具有完整的「全連接埠、全通訊協定」存取權。問題並不在於由第 3 層 VPN 加密且藉由網路傳送的資料流，而在於透過這些通道連線的遠端用戶端，它們對您的內部網路已經造成日益重大的威脅。您可以回想一下，大部分遭到 Slammer 或 Blaster 等惡意程式碼染指的公司，都不是被內部網路機器感染，也不是被周遊於防火牆的駭客攻擊，而是受到透過 VPN、從受感染的機器連線到公司網路的遠端工作者所拖累。這些 VPN 一旦建立完全路由的第 3 層連線時，遠端機器就握有相當於資料中心機器對於內部資料的存取權了 (不分好壞)。
此外，由於第 3 層 VPN 需要在不是由公司 IT 群組管理的機器上進行軟體安裝和設定，因此運作成本都相當昂貴。舉例來說，在使用者的家用電腦安裝 VPN 用戶端，不但要建立自訂安裝套件、提供詳細的安裝指引供使用者參考，還要排解使用者機器上的應用程式衝突等疑難雜症。如果需要部署新版用戶端，或者需要更改設定資料 (如加入新 VPN 端點)，管理成本還會往上提高。對使用者來說，透過 VPN 工作往往不太自然，這種作業方式只提供第 3 層連線，使用者無法直覺取用或看見商務應用程式和資料。

解決終端機服務的問題
為了因應這兩個問題，於是出現了終端機服務和其他所謂第 7 層或應用程式層的 VPN 技術，這種技術能夠更精準地操控使用者所能存取的資源和通訊協定，能給予使用者更簡單、更直覺化的操作體驗。
從安全性的觀點來看，「第 3 層 VPN」與「使用終端機服務和 TS 閘道」重要的差別，在於後者與內部網路的連線為非完全開放的管線。更具體的說，第 3 層 VPN 方法會在本機電腦上建立一個在內部網路具備完整路由能力的虛擬介面，相較下 TS 閘道方法只容許 RDP 封包存取內部網路，因而大幅減少整體的攻擊面積，並且在 RDP 具有更細微的控制權。舉個例說，由於 RDP 提供磁碟機重新導向的原始支援，因此公司可以將 TS 閘道設定成與 NAP 整合，而且除非遠端機器能證明持有最新的防毒軟體，否則一律不允許這項功能。
就一般使用者來看，第 3 層 VPN 和終端機服務方法之間最明顯的差異，是後者的設定明顯簡單許多 (通常根本不用設定)，而且存取應用程式和資料的方法更加容易且更加直覺化。由於遠端桌面連線用戶端是內建在 Windows，並且透過像 Windows® Update 的一般服務技術隨時更新，因此通常不用安裝用戶端軟體。另外，有了 TS Web Access，使用者只需造訪一個 URL，就可以找到自己所有的應用程式和資料。而且只要按一下適當的應用程式，就可以啟動 TS 閘道為網際網路連線建立穩固的通道，將應用程式順利傳送到使用者的桌面。換句話說，應用程式的外觀和反應 (包括複製、貼上和最小化成工作列等功能) 簡直像是安裝在本機上。終端機伺服器方法因為能幫助使用者輕鬆取用應用程式和資料、設定快速，成功提高了使用者的滿意度，也降低了支援成本。

網路架構選項
將 TS 閘道伺服器應用在網際網路上的基本網路設計方法有兩種。第一種方法是將 TS 閘道置於第 3 層/第 4 層防火牆之間的周邊網路，形成三角架構。第二種方法是把 TS 閘道留在內部網路，改以應用程式層防火牆 (例如，Microsoft® ISA Server、Microsoft Intelligent Application Gateway 或各種協力廠商解決方案) 坐陣周邊網路，審察輸入的 HTTPS 框架。等輸入工作階段分析完畢之後，再將封包轉送到內部 TS 閘道伺服器。
如果公司只有第 3 層/第 4 層防火牆，也具備基本可設定狀態的封包審查功能，不妨將 TS 閘道裝置直接置於周邊網路中，如 [圖 1] 所示。這個設計的網際網路對向防火牆只容許來自網際網路的 HTTPS 資料流到達 TS 閘道。不過，這種防火牆並不會檢查應用程式層的資料流，只是將資料流轉送到 TS 閘道。TS 閘道伺服器會接著將 HTTPS 封包的 RDP 框架解壓縮，然後轉送到適當的後端伺服器。這些後端伺服器通常由第二道防火牆與周邊網路互相區隔，而這道防火牆則容許來自 TS 閘道的 RDP 框架到達適當的內部伺服器。
[圖 1] 採用第 3 層/第 4 層防火牆的 TS 閘道置於周邊網路內
[圖 1] 採用第 3 層/第 4 層防火牆的 TS 閘道置於周邊網路內
雖然這是一個完全支援的案例，對許多公司來說可能也相當有用，但它有兩個重大缺點。第一，由於 TS 閘道是直接接收來自網際網路的資料流，因此遭到外部惡徒入侵的風險相對地高。這些心懷不軌的傢伙可能會透過 SSL 工作階段趁機攻擊閘道，而且由於前端防火牆只檢查標頭而不檢查裝載部分，因此這些工作階段可以直達閘道。我並非質疑 TS 閘道防禦薄弱，畢竟它也和 Windows Server 2008 產品的其他元件一起通過同樣嚴苛的安全設計和測試。但是，正由於它面對的是直接來自網際網路、未經篩檢的資料流，風險也相對提高。第二個重大缺點是，由於閘道和後端防火牆之間的資料流日益增加，為了驗證使用者，TS 閘道需要藉由 Active Directory® 進行通訊。因此後端防火牆就必須網開一面，接受 HTTPS 以外的連接埠和通訊協定。通訊量增加，相對也代表風險的增加。
防治 TS 閘道暴露於網際網路的因應之策，就是在輸入 HTTPS 工作階段到達閘道之前，先由應用程式層 (第 7 層) 防火牆加以處理 (見 [圖 2])。這個設計仍由傳統的第 3層/第 4 層防火牆形成周邊網路，只是將周邊網路中的 TS 閘道換成第 7 層防火牆。當資料流到達外部式防火牆時，該防火牆會刷掉 HTTPS 框架以外的資料流，再將框架轉送到第 7 層防火牆。接著第 7 層防火牆會終止 SSL 工作階段、檢查未經加密的資料流內容、封鎖惡意資料流，然後再將 RDP 框架經由後端防火牆傳到 TS 閘道。請注意，必要時，第 7 層防火牆也可以將框架重新加密之後，再傳到 TS 閘道。這個方法在公司私人網路上也許派不上用場，但是在代管的資料中心或共用網路上就很有用。
[圖 2] 將應用程式層防火牆搭配使用 TS 閘道裝置
[圖 2] 將應用程式層防火牆搭配使用 TS 閘道裝置
這個設計沒有前一個解決方案的兩大缺點。TS 閘道伺服器只接受經過第 7 層防火牆檢查的資料流，因此沒有直接來自網際網路的攻擊風險。第 7 層防火牆應該會刷掉這些攻擊，只保留經過檢查的乾淨資料流，將它們傳回閘道。
另外，這個設計的閘道位置是根據內部網路來安排，這是第二個重要優點。由於來自網際網路的資料流在到達閘道之前，會先經過第 7 層防火牆檢查，因此它可以留在內部網路，並且對於接受驗證的網域控制站以及使用者工作階段所用的 RDP 主機，具有直接存取權。此外，後端防火牆的原則限制更加嚴苛，它只讓經過第 7 層防火牆檢查的 RDP 工作階段到達 TS 閘道，連 RDP 和目錄驗證資料流都過不了關。把第 7 層防火牆作為 TS 閘道部署的前端，可以提供更安全的解決方案，而且管理容易，不必將現有的周邊網路重新設計。

NAP 整合
終端機服務資源
  • Windows Server 2008 中的終端機服務
  • Windows Server 2008 終端機服務 TechNet 論壇
  • 終端機服務小組部落格
  • Microsoft Intelligent Application Gateway 2007
  • Windows Server 2008 的網路存取保護 (NAP)
  • 網路存取保護 (NAP) 部落格
  • Windows Server 2008 Beta 3 逐步指南

雖說好的周邊設計是隨處存取解決方案的重要元素，但是確保端點裝置的合格性與安全性也一樣重要。RDP 是一個完整的通訊協定，它可以接受多種像 RDP 工作階段和印表機等裝置重新導向，因此，連接您解決方案的用戶端，必須符合貴公司的安全性原則才行。舉個例說，即使公司具備以前述最佳作法為基礎的安全網路拓樸，但是從不安全的機器連接到終端機伺服器的一般使用者，仍有可能遺失機密資料，或者將惡意檔案置於終端機伺服器上。即使 RDP 的連線數量和毀損可能性，遠低於透過第 3 層 VPN 連線的方法，但仍然必須管理遺失資料的風險，而且必須遵守您的 IT 原則。
網路存取保護 (NAP) 是 Windows Server 2008 所提供的一項新技術，這項技術不只能夠讓您控制誰可以連接您的網路，同時還能夠控制他們可以從哪些系統連線。舉個例說，您可以使用 NAP，只容許具有運作防火牆以及最新防毒軟體的機器連接網路。NAP 是一種可以擴充的解決方案，它不只涵蓋公司的內部網路，同時也涵蓋遠端使用者，包括透過第 3 層 VPN 和 TS 閘道連線的使用者皆是。您可以整合 NAP 與 TS 閘道設計，確保只有符合您安全性原則的系統才能與它連線。如需有關 NAP 的詳細資訊，請參閱我在 2007 年 5 月號《TechNet Magazine》的《安全性監控》專欄，網址為 technetmagazine.com/issues/2007/05/SecurityWatch。
將 NAP 整合到 TS 閘道部署的程序非常簡單，只要在設計當中多加一個服務即可。這個服務是網路原則伺服器 (NPS)，它可以安裝在 TS 閘道伺服器本身，也可以安裝在另一個作業系統執行個體。接著您再使用 TS 閘道 MMC 建立連線授權原則 (CAP)，定義目前的健康狀態能夠接受哪些 RDP 功能。只要有新連線想要建立，TS 閘道伺服器就會詢問 NPS，並且將該連線的健康狀態聲明 (SoH) 轉送給 NPS。網路原則伺服器會比對 SoH 及其原則，然後通知 TS 閘道，根據用戶端的健康狀況來看，是否可以接受這個連線。
根據 [圖 3] 所示，如果公司沒有設定讓不合格的系統使用 Windows Update，但是安全性原則又要求啟用自動更新，那麼當使用者想要連接 TS 閘道時，他的機器便會產生和轉送一份 SoH。這份 SoH 的內容大概是「我有開啟防火牆，也有隨時更新防毒軟體，但是沒有啟用自動更新」。TS 閘道會直接將這份 SoH 轉送給 NPS (TS 閘道無法自行將 SoH 解碼)，由 NPS 比對 SoH 和管理員所定義的原則。由於自動更新是在停用狀態，因此 NPS 會判斷該連線符合「不合格」原則，然後通知 TS 閘道不接受連線。TS 閘道會中斷連線，通知使用者該機器不符合公司的安全性原則。使用者可以再採取任何必要的更正措施 (在這個案例中，只要啟用自動更新即可)，然後重新建立連線。這時候它會產生一份新的 SoH，NPS 會判斷它合格，接著 TS 閘道就讓它過關。
[圖 3] 只有合格的系統才能連線
[圖 3] 只有合格的系統才能連線

結論
Windows Server 2008 含有對於安全隨處存取解決方案來說相當重要的建置組塊。TS 閘道提供一個安全的方法，讓您透過網際網路為遠端桌面工作階段建立通道，並且給予公司相當大的彈性，讓它們選擇要如何整合到現有網路。這些選擇包括將 TS 閘道直接置於周邊網路上，或者在它前面安置一個像 ISA Server 或 Intelligent Application Gateway 等的第 7 層防火牆。NAP 可以結合 TS 閘道，將端點健康檢查功能加入解決方案中。端點檢查可以幫助公司確保遠端連線是來自有效的使用者，同時也是來自符合 IT 安全性原則的機器。兩者結合之後，這些技術便能提供更安全、更有效率，並且讓一般使用者享有更佳體驗的遠端存取功能。您可以探索「終端機服務資源」資訊看板所列的網站，尋找更多相關資訊。

John Morello 自 2000 年便任職於 Microsoft。身為資深的顧問，他曾為美國財星前百大 (Fortune 100) 企業及民間和國防部門設計安全解決方案。他目前擔任 Windows Server 小組的資深專案經理，負責開發隨處存取技術。您可以在 blogs.technet.com/WinCAT 閱讀他的小組部落格。


 桌面檔案: 磁碟重組的真相
桌面檔案
磁碟重組的真相
Wes Miller

我必須強調一點，只要使用硬碟，必然會有磁碟分散。如果您真的關心系統的健康，就該定期執行磁碟重組。這句話是不是很像牙醫師每年都督促您要使用牙線呢？他的叮嚀應該不陌生吧。沒錯，磁碟重組就是這麼重要。
除非電腦一直被晾在一邊不開機，否則硬碟分散的情形一定會越來越嚴重。待會兒我就說明這種情形如何發生，不過現在先讓我們稍微回顧一下磁碟重組的歷史。

磁碟重組和 Windows NT
Windows NT® 並沒有內建的磁碟重組公用程式，而當時也普遍認為沒這個必要，反正 NTFS 的架構已經夠完善，不像 FAT 磁碟區老是為劇烈的磁碟分散所苦。但即使完善如 NTFS，日積月累下，有朝一日也會被不完善的檔案配置所連累。於是磁碟重組工具市場因此應運而生，並且繁榮壯大。 其中 Executive Software (現在是 Diskeeper Corporation) Diskeeper 產品，可說是 IT 專家最愛用的一種。最初 Windows 2000 整合磁碟重組功能時，Microsoft 是向 Executive Software 取得技術授權。Windows® 2000 磁碟重組功能過去是附隨在自家產品 Microsoft® Management Console (MMC) 嵌入式管理單元 (dfrg.msc) 中，可以按一下任一磁碟區或手動從命令列執行 defrag.exe 來啟動這項功能。這項功能只能以簡單的命令列加以執行，無法事先排定執行時間，於是許多 IT 專家便自行撰寫功能指令碼，讓這個內建產品自動執行磁碟重組。到了 Windows XP 和 Windows Server® 2003，Defrag.exe 就更進步了，不過它的自動功能仍然有限 — 想要它自動執行重組，還是得靠自己撰寫指令碼才行。
雖然有些廠商 (包括我的前一任雇主 Winternals Software 在內) 也製造專供企業磁碟重組空間使用的軟體，但是這些產品多半大同小異，都有一個中央主控台、有一個安裝在用戶端系統的代理程式 (有時候全天候工作，有時候您要它工作它才工作)，還有一個語音輸入結構，可以聽從使用者指定執行磁碟重組工作的時間和方式。
而 Windows Vista® 則仍保有一脈相傳的單系統重組，另外再把重組工具最佳化，加入重組小檔案片段 (64MB 或更小) 等選項。這種做法雖然可以加速重組作業的進行，但缺點是大型檔案片段都被留置磁碟上沒有處理。Windows Vista 和 Windows Server 2008 的磁碟重組引擎本身比舊版 Windows 更加強大，而且可以自動執行重組，不必手動排定時間。不過如果您所經營的是大型公司，或者您想要以重組工具所未提供的方式將系統最佳化，還是需要取得其他廠商軟體的授權才行。舊版軟體無法對啟用並廣泛使用 NTFS 壓縮功能的磁碟區進行重組。這時候其他廠商工具就可以彌補這個不足。

磁碟分散是怎麼發生的？
磁碟分散主要是因為檔案日積月累產生變化所導致。在理想狀態下，Windows 檔案本身不會改變，或者至少變化頻率不高，只有在安裝 Service Pack 和軟體更新項目時才會發生。如果沒有執行這兩項作業，系統檔案基本上不會產生什麼變化。然而，執行大規模的更新作業 (如安裝 Service Pack) 後磁碟分散就自然產生，因為被更新的檔案通常無法在其所在的位置被覆寫，再加上可能需要重新開機才能讓更新生效，使得分散情形更加嚴重。
另一方面，使用者的檔案和資料 (以及 Windows 登錄) 也會隨著持續不斷的改變而變化。不斷的讀取、寫入、編輯、複製和刪除檔案，都會導致磁碟大量分散，尤其當磁碟機容量已滿時更是明顯。
讓我具體說明這種情況：假設現在有一個排列完善的磁碟，磁碟的檔案與檔案之間緊密相鄰，毫無空隙。您開啟並編輯其中一個檔案，然後存檔。如果檔案變大，Windows 就必須把整個檔案儲存在磁碟的另一處 (假設儲存在第 N 個檔案後面)，或者把最新資料儲存在第 N 個檔案後面，但是這麼一來，第 2 個檔案就分散兩處了。如果現在再編輯第 1 個檔案，就會出現兩個分散的檔案。同樣的動作不斷重複執行，時間一久，系統自然變得七零八落。每當存取一個檔案，磁碟機就必須跑遍各處尋找這個檔案。如果資料檔案很大，或者硬碟檔案因為虛擬運算技術而膨脹，或者磁碟佈滿大量的影音視訊檔案，磁碟分散就成為家常便飯了。當然嘍，持續擴充硬碟的確可以減輕問題，但並不能解決問題。如果您用的是硬碟較小、無法擴充的舊型膝上型電腦，電腦反應就會越來越遲鈍，開機越來越慢，開啟和儲存檔案的時間也會越來越長。
其實您最該擔心的不是系統的分散情形，而是檔案的分散情形。自從磁碟重組工具問世以來，使用者的感想難道就只能是「喜歡看見重組後整齊的色塊」嗎？不是吧。有的產品是以兩個區塊代表磁碟，一個彩色 (代表檔案資料)，一個白色 (代表可用空間)。不過，要盡量降低重組的頻率和成本，最不該選的就是這個產品了。如果把所有的檔案資料全部壓縮到磁碟前端，再次編輯時要是佔用大多數的可用空間，編輯內容只好全部寫到檔案資料結尾，結果這種重組方式從再次編輯的那一刻反而助長了分散。好的磁碟重組並不是兩個排列整齊的檔案資料區塊而已，而是看起來並不怎麼完美的圖案。您可以參閱 [圖 1] 所示的範例，看看重組前的測試系統。然後再參閱 [圖 2]，看看 Windows 完成重組之後的同一個系統。
[圖 1] 重組前的磁碟機
[圖 1] 重組前的磁碟機
[圖 2] 重組後的磁碟機
[圖 2] 重組後的磁碟機
請注意，Windows 不是把重點擺在磁碟檔案的分散，而是擺在個別檔案本身的分散 (如果您想看看在重組系統之前，針對分散最嚴重的檔案所做的重組報告那個區段，請參閱 [圖 3])。
[圖 3] 磁碟重組報告
[圖 3] 磁碟重組報告
您會發現，即使在重組之後，Windows 也不會把檔案資料完全壓縮到磁碟前端。另外要注意的是 [圖 1] 和 [圖 2] 所示的大塊綠色資料。那是 Windows 分頁檔，接下來我會討論這個部分。如果您在 Windows 系統有啟用休眠，那麼在進行重組時，會出現類似的動作。

記得定期重組
就像人類每天都要用牙線一樣，機器也要定期進行磁碟重組。使用度高的系統 (例如伺服器) 更需要經常重組，因為只要稍一怠慢，重組程序就會拖得很長，導致伺服器無法使用或者沒有反應 (因為重組作業可能會花費大量時間，有的重組階段也會耗用 CPU 資源)。
即使最好的線上重組工具，也沒辦法重組所有的項目。例如，開啟的檔案或已鎖定的檔案 (例如，分頁檔或登錄檔) 就不一定能夠重組得到，如果有休眠檔，就必須避開休眠檔 (因為它跟系統正在使用的 RAM 一樣大)。如果要將鎖定的檔案最佳化，請參閱接下來討論重組陷阱的這一節。
瞭解磁碟重組的迷思和真相是非常重要的一環。[圖 4] 和 [圖 5] 將會示範幾個在討論磁碟重組時經常提到的主題，並且解說這些問題真正發生的時機。
Figure 5 磁碟重組的迷思 (Close Figure 5)

迷思 | 可能性
系統當機。 | 不可能 — 當機通常是因為驅動程式或硬碟問題所導致 (記憶體損毀、因熱力問題導致重新開機，或是因為濫用磁碟熱能而使磁碟失效)。
應用程式當掉。 | 不可能 — 以整個系統來說，一個設計精密的應用程式，不會因為磁碟重組而當掉。除非確實可疑，否則不應假設磁碟重組就是元兇。
登錄損毀。 | 不可能 (請參閱上文) — 分散不會導致登錄損毀。
在進行磁碟重組時，畫面會出現代表磁碟的實心直條。 | 不可能 — 平常最好不要把系統上所有的檔案全部壓縮在一起，除非您特別打算使用磁區型映像工具來反映系統映像，而不排除可用空間，或者縮小或分割磁碟分割。建議您最好將檔案置於磁碟前端，否則，過度合併檔案只會讓檔案更加分散。
Figure 4 磁碟重組的一般疑慮 (Close Figure 4)

疑慮 | 可能性
折損系統效能。 | 高 — 尤其視系統的使用情形而定。
很難或者無法修復不慎刪除的檔案。 | 高 — 大部分的修復工具都要視啟發學習法 (Heuristic，以判斷資料類型) 和檔案叢集接近度而定。檔案散亂，會使修復作業更加複雜，或者無法執行，
而加重系統重組的成本。 | 中 — 系統的使用量，與系統日積月累的檔案變化量，兩者之間有直接的關聯。比方說，使用者雖然經常編輯檔案，卻只把檔案儲存在伺服器共用區，那麼即使經過一段時間也不會有太多折損。
使磁碟受損。 | 低 — 不太可能。跟前面一樣，系統愈被濫用 (一直讓磁碟保持在開啟狀態，不斷的編輯、修改或刪除檔案)，磁碟就愈容易受損。不過以現今的硬碟來說，光是編輯檔案還不至於會損毀磁碟。

把磁碟重組當作基礎結構的一部分
可以的話，我勸您在所有系統上都定期執行磁碟重組。您可以選擇使用 Windows 內建的重組工具，也可以另外採用其他廠商推出的重組工具。基本上，它是根據您想要進行多少工程作業而定。如果您是用 Windows XP 和更新的版本，可以把 defrag.exe 加入作為排定的工作 (相關步驟請參閱 support.microsoft.com/kb/555098 這篇知識庫文章)。請注意，膝上型電腦的重組作業還附帶一些特殊的考量事項。您想在使用者系統開機狀態時進行重組 (理想狀態是透過 AC 電源)，但是當行動使用者想要完成工作時，又不想耗用 CPU 或磁碟週期。怪就怪在當行動使用者不在系統上工作時，它會切斷與 AC 電源的連線，然後在一旁待命或休眠 (從電源管理和「排定的工作」的角度來看，它是在關機狀態)。當我還服務於 Winternals 時 (其實其他公司也一樣)，大家曾經花過許多時間來設計理想的行動使用者實務。如果您是使用 Windows Vista，不妨使用內建的磁碟重組工具和「排定的工作」，因為它的電源感知能力比舊版更好，絕對是不錯的解決方案。如果不是使用 Windows Vista，就必須尋求其他廠商開發的行動系統專用產品了。有的產品還會正式展開磁碟重組工作，並且告訴您它執行什麼、何時執行 (還有多常執行)，以及執行多久。
除了行動產品的重組之外，我們還要討論檔案系統的重組。其實不只桌上型系統或行動系統需要關心這個問題，伺服器、Microsoft Exchange、SQL ServerTM 或其他資料存放區也需要執行磁碟重組。如果您使用的是後者，就必須決定要在執行檔案系統重組之前還是之後進行重組。
如果您要使用其他廠商的磁碟重組工具，必須選擇使用 Windows 磁碟重組 API 的重組工具。為了預防不慎遺失資料，Windows 自 Windows NT 4.0 開始就擁有自己的磁碟重組 API。比方說，如果您在移動檔案時，系統突然斷電，這時候最怕的就是分散移動不完整，因為這樣可能會導致資料遺失，其至再也無法開機。
最後一點，如果您有使用任何虛擬運算技術，也得學習管理虛擬磁碟的重組。虛擬磁碟的重組頻率並不下於實體磁碟，而且由於大小限制的關係，它們的情況會更嚴重。另外，如果您的虛擬解決方案容許您縮小磁碟或磁碟分割，可能得先執行重組來清出空間 (至少能夠減少縮小作業所花的時間)。

其他工具
說到現在，您應該不會懷疑磁碟重組的重要性了吧。即使您不使用其他廠商的工具來進行磁碟重組本身，也可以考慮使用由 Mark Russinovich 開發的一種名叫 PageDefrag 的工具，這個工具可以從 Microsoft Sysinternals 工具網站取得 (請參閱 microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx)。我在前面提過，只要 Windows 在線上，就不能對 Windows 分頁檔進行磁碟重組。其實 Windows 登錄檔和事件記錄也一樣。但是 PageDefrag 就可以讓您在 Windows 完成開機和鎖定這些檔案之前，先使用一個小型驅動程式重組鎖定的檔案。使用的方法很簡單，只要執行 PageDefrag，將它設為在下次重新開機或每次重新開機時執行即可。每當系統重新開機時 (您之前可能看過，開機程序中執行磁碟檢查的那個時間點)，就會重組清單指定的檔案 (見 [圖 6])。
[圖 6] 在 PageDefrag 中重組的檔案
[圖 6] 在 PageDefrag 中重組的檔案
PageDefrag 完成之後，正常的系統開機就告完成。如需 PageDefrag 的其他相關資訊，請參閱 Lance Whitney 在 9 月號所寫的《公用程式焦點》 (請參閱 technetmagazine.com/issues/2007/09/UtilitySpotlight)。請注意，目前只有 Windows NT 4.0、Windows 2000、Windows XP 和 Windows Server 2003 支援 PageDefrag，Windows Vista 並不支援。
除了 PageDefrag 之外，您還可以從 Sysinternals 取得另一種名叫 Contig 的工具，這個工具可讓您以手動方式，針對特定的檔案進行重組 (請參閱 microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx)。如果只有某個檔案無法透過正常重組工作進行重組，或者如果只有該檔案分散，而磁碟區的其他部分都很完整，就可以使用 Contig。
如果您想重組整個目錄或子目錄，Contig 也可以利用萬用字元辦到。下面這個程式碼的任務，就是重組 Windows 目錄下所有的檔案，無論這些檔案在哪裡都無所遁形。
Contig –s c:\Windows\*.*
套用 –v 參數，表示詳細的執行作業，而套用 –q 則表示在背景執行作業。

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


 現場筆記: 鱈魚教官
現場筆記
鱈魚教官
Betsy Aoki

有時候 您需要的可能不是更龐大的伺服器，或是更有教養的使用者群體 (不會在您想要早點去度週末的時候不斷打擾您)。有時候問題不在於管理程式碼；您真正需要的是一條大魚。
一年前，我負責處理 Live QnA 網站 (qna.live.com) 的濫用報告。我們操縱 [刪除 (Delete)] 按鈕並監視網站上的愚蠢攻擊和不當行為。我們不但有內部工具，也有外部原則。我們也和一些瘋子交手過，這些人想要用不堪入目的內容來破壞我們的問答。
我一方面逐漸失去幹勁。畢竟，健全的網站社群是我的職責所在。當初我曾參與擬定管理辦法來為網站定調。我是守門員，其他人最好都乖乖聽話。
但是他們會聽話才怪。江山難改，本性難移 — 也就是說，人類能做出最惡劣的背叛和最不可思議的善行 — 我的想法也無法阻止人們互罵豬頭。
某個星期六，我坐在廚房裡，思考著我所捍衛的管理辦法。我拿著筆亂畫，我的腦袋開始天馬行空地胡思亂想。如果沒有管理辦法 (code of conduct)，只有鱈魚教官 (cod of conduct)，那會怎麼樣？那麼，這隻鱈魚看起來怎麼樣，又會怎麼做？我從小在新英格蘭長大，常吃鱈魚。白白、薄薄的一片，沒什麼味道。我希望能夠偷天換日，以鱈魚般苛刻、實事求是的語調來哄騙 QnA 成員。我不想再像敲法官槌一樣使用 [刪除 (Delete)] 按鈕 (我最近實在使用得太頻繁了)，而是透過尖酸又風趣的回答，讓人即使在發誓絕不再逾矩的同時也忍不住發笑。鱈魚教官 Norbert 於焉誕生。我本來想讓他叼根煙斗，但還是決定領結就夠了。
鱈魚教官
我將我畫的鱈魚上載成新的 LiveID，為他取一個 QnA 使用者名稱，接下來 Norbert (QnA 鱈魚教官) 就可以開工了。提醒您，他不見得一定代表我。有時候，其他小組成員會化身為鱈魚來斥責壞蛋。鱈魚教官是誰？請參閱 go.microsoft.com/fwlink/?LinkId=99044。鱈魚教官說話會傷人嗎？請參閱 go.microsoft.com/fwlink/?LinkId=99045。
QnA 社群成員喜愛他的程度就像 ... 呃 ... 魚愛水一樣。他們會跟他開玩笑，呼喚他，或是對他產生好奇心。他會教育新來的成員，指責那些我們認為可能棄暗投明的傢伙，還會提供一種輕鬆愉快的方式來提示規則，而不只是宣讀艱澀難懂的法律術語網頁。
規則 — 無論是公司政策、部落法或是遊樂場順位 — 全都有賴於感受到規則實施效力的成員發揮善意。身為 IT 人員或社群網站開發人員，您可以建立工具來強制執行這些規則，但是有時候最能輔助工作的工具也許是能夠表現出您的個性，或族群全體人性光輝的事物。除了技術工程以外，不妨利用社交工程整頓一番更有效果。在我們的案例中，除了整頓，別忘了還有一條魚。

Betsy Aoki 在 Microsoft 擔任 Xbox 小組的社群專案經理 (Community Program Manager)。她稍微神經質的天性在她的電子郵件、部落格張貼上都展露無遺，希望這也展現在 XNA Framework 中。


 Windows 機密文件: 檔案系統矛盾說
Windows 機密文件
檔案系統矛盾說
Raymond Chen

如果您稍微看看 自己的硬碟，應該會注意到在開機磁碟機的根目錄中，有不少作業系統檔案根本無所事事。如果再仔細看看那些檔案，就會發現一個重點：boot.ini、NTLDR 和 NTDETECT.COM 是關鍵開機檔，hiberfil.sys 是休眠檔。其實，在啟動作業系統前幾個關鍵階段，以及從休眠回復正常作業 (hiberfil.sys 檔) 時，最重要的就只有這幾個檔案，而這些檔案都必須放在開機磁碟機的根目錄下。為什麼不能把它們移到其他地方呢？
下面是我同事 Adrian Oney 的解釋：如果要從磁碟外面讀取開機檔，必須借助檔案系統驅動程式才行，但是檔案系統驅動程式存在於磁碟上，必須等它們載入之後才能讀取。這不是自相矛盾嗎？
其實要解開這個矛盾，只需在那些關鍵開機檔內建一個迷你檔案系統驅動程式就行了。這個迷你驅動程式唯一的本事就是在根目錄尋找檔案，把它們載入到記憶體中。之後就由那些檔案啟動作業系統，然後再由真正的檔案系統驅動程式接手，到更特別的地方 (例如，子目錄) 尋找檔案。
休眠的情況也很類似。讓作業系統休眠，就是把整個記憶體內容倒進休眠檔中，而從休眠恢復正常作業，就是把檔案再塞回記憶體，假裝什麼都沒發生過。這跟開機一樣，也是一個雞生蛋蛋生雞的問題：要載入休眠檔，必須借助檔案系統驅動程式，但是檔案系統驅動程式卻在休眠檔中，該怎麼辦呢？如果休眠檔仍然留在開機磁碟機的根目錄，這時候就可以改用迷你檔案系統驅動程式。
使用舊版 MS-DOS® 的人，都很清楚作業系統開機檔的位置限制。舊的 SYS 命令將無趣的舊式磁片做成神奇的開機磁片。但是如果您在已有資料的磁片上執行它，可能無法進行轉換作業，因為舊版 MS-DOS 的開機檔必須放在磁片的特定位置上，開機磁區才找得到它們。 較新版的 MS-DOS 雖然改善了開機載入器，放寬限制，但是系統檔案仍舊必須放在根目錄下。
就有一位客戶問我：「我能把休眠檔移到子目錄嗎？」，反正檔案在哪裡還不都一樣嗎？無論把它放在哪裡，檔案上的 ACL 都是一樣的。但是當他們想把檔案放在開機磁碟機以外的磁碟機時，卻被告知行不通。那是因為他們沒有真正明白這項限制的原因，所以才會規避正常程序：如果我把它移到子目錄下，就可以建立一個目錄，把它作為連接點，指向我真正希望放置休眠檔的地方。嘩~ 我把休眠檔移位了！
當然嘍，迷你檔案系統驅動程式是不會認得掛接點的，因為掛接點的任務是要和磁碟管理服務交談，而在系統開機時，電腦連作業系統都尚未載入，更別提其他知道如何將磁碟機代號對應回 ARC 路徑的進階服務了。即使碰巧執行了這個服務，也要找出其他硬碟的裝置驅動程式，載入對應的檔案系統驅動程式才行。
其實這些矛盾都有解決的一天，一切只是時間問題罷了，就算哪天有人把休眠檔放在 DFS 連接點上，也不是不可能的對吧。

Raymond Chen 的網站「The Old New Thing」以及同名著作(Addison-Wesley，2007 年) 均探討 Windows 的歷史和 Win32 程式設計。他在 Web 2.0 所用的名字是 Raymond，要不然就是 Chester。