8 月 2008 8 月 2008
SQL Server: 有效維護資料庫的最佳秘訣
非專業資料庫系統管理員的人們常常因某種理由而接下資料庫的重任。他們缺乏適當的訓練和知識來維護資料庫，問題便接踵而來。以下針對這些需要上資料庫維護最佳作法速成班的所有非自願 DBA，提供一篇入門文章。 Paul S. Randal
Windows 系統管理: 為您的伺服器把脈
您的使用者在抱怨伺服器動作太慢 — 您知道要從哪裡著手診斷問題嗎？PerfMon 是一個不可缺少的工具，因為它具有許多診斷功能。您應該使用這個重要的指示器來診斷各種降低伺服器速度的常見瓶頸，請看看它的概略說明。 Steven Choy
System Center: System Center Operations Manager 中的 Windows PowerShell
Windows PowerShell 已整合至 System Center Operations Manager 2007，提供一種功能強大的方法來執行和自動化一般管理工作。初步了解一下您如何能夠在 OpsMgr 中使用 Windows PowerShell 來執行例行的維護作業，管理代理程式，以及其他工作。 Marco Shaw
網際網路資訊服務: 調整 ASP.NET 應用程式：心得
成功調整 ASP.NET 應用程式的關鍵，是在應用程式的生命週期一開始，就讓開發人員和網路系統管理員協力合作。一同認識調整應用程式的要素，並了解共同作業如何能夠確保應用程式如預期般執行。 Richard Campbell
Columns
編輯的話: Tech•Ed 的現場報導: | 讀者來信: 讀者有話直說: | 工具箱: 適合 IT 專家的新產品:
SQL 問答集: 磁碟分割、一致性檢查及其他: Paul Randal 將解答您的 SQL Server 疑問，說明如何在非常大型的資料庫上執行一致性檢查及其他維護作業， 以及如何處理意外升級等等。Paul S. Randal | 公用程式焦點: Windows Installer CleanUp 公用程式: 當您嘗試更新或解除安裝應用程式時，殘存的 Windows Installer 設定資訊可能會產生問題。您可以使用 Windows Installer CleanUp 公用程式來解決這些問題，Windows Installer CleanUp 會協助您移除應用程式的 Windows Installer 資訊，然後重新安裝應用程式。Lance Whitney | Sharepoint 內幕: 疑難排解訊息整合: 將 SharePoint 整合至安全的訊息環境並非易事，但是對產能方面的正面影響將值回票價。以下是關於如何排解在設定環境時可能會發生的疑難的一些指引。Pav Cherny
Windows PowerShell: 一窺 2.0 版中的遠端管理: Windows PowerShell 2.0 正籌畫推出中，而最新版的 CTP 更提供了一些超棒的新功能。從中瞧一瞧遠端功能，這是您可在 Windows PowerShell 2.0 CTP2 中發現的最刺激的新功能之一。Don Jones | 嗨，Scripting Guy！: 搭乘特快車: Windows Vista 已經沒有開啟 [開啟舊檔] 對話方塊所用的 UserAccounts.CommonDialog ActiveX 控制項了。下面我們將介紹如何以 Visual Basic Express Edition 來解決這個問題。Microsoft Scripting Guy | 桌面檔案: Windows 部署服務 101: 探索不同版本的 Windows 部署服務，看看如何擷取自訂 OS 映像，並了解執行更自動化的安裝的必備條件。Wes Miller
安全性監控: 密碼與信用卡 - 第二篇: 在本系列三篇的最後一篇，Jesper Johansson 探討軟體廠商、安全性套件和宣傳效果如何阻礙為可靠的安全性所做的努力，他並且警告我們，這些作法將如何導致技術安全性生態系統的崩潰。Jesper M. Johansson | 永續型運算: 過濾不實環保: 就管理 IT 基礎結構而言，了解耗電量是不可或缺的一部份。一同來了解您可以採用的各項策略，透過實作環境中的電源監測來進一步掌握組織內的裝置用電量。Dave Ohara | 現場筆記: IMAP 拯救世界: 您是否把電子郵件用不同的格式，到處儲存在不同的地方，甚至不同的作業系統呢？Dara Korra’ti 將告訴您，如何利用 IMAP4.，集中從一個地方存取所有的郵件。R'ykandar Korra'ti
Windows 機密文件: 建置在過去的基礎上: Raymond 講述曾經風靡一時的 Alpha AXP 系統如何再次披掛上陣，協助開發新一代 64 位元系統。Raymond Chen


SQL Server
有效維護資料庫的最佳秘訣
Paul S. Randal
綜覽：
  • 管理資料和交易記錄檔
  • 消除索引片段
  • 確保準確、最新的統計資料
  • 偵測損毀的資料庫頁面
  • 建造有效的備份策略

目錄
資料和記錄檔管理
索引片段
統計資料
損毀偵測
備份
總結
每個禮拜有好幾次我都會被要求對要如何有效維護實際執行資料庫提出建議。有時候，提出問題的是正在實作新解決方案，並且想要幫助微調維護作法，
以配合新資料庫特性的資料庫管理員 (DBA)。但更常發問的人其實是那些因故擁有和負責資料庫的非專業 DBA。我在此把這種角色稱為「非自願 DBA」。本文的重點是要為所有的非自願 DBA 提供資料庫維護最佳作法的入門。
就跟 IT 世界裡大多數的工作和程序一樣，有效維護資料庫也沒有所謂一體適用的解決方案，但有一些重點區域始終需多加注意。我的前五大重點區域為 (不分重要性)：
  • 資料和記錄檔管理
  • 索引片段
  • 統計資料
  • 損毀偵測
  • 備份
未加維護 (或維護不良) 的資料庫可能會在上述當中一或多個區域內發生問題，而終究導致應用程式效能不佳，甚或停機和資料損失。
在本文中，我將解釋這些問題的重要性，並示範一些簡單的方法來舒緩問題。我將以 SQL Server® 2005 作為論述的基礎，但是我也會點出 SQL Server 2000 與即將推出的 SQL Server 2008 的主要差異。

資料和記錄檔管理
接掌資料庫時，我向來建議檢查的第一個區域，就是與資料和 (交易) 記錄檔管理相關的設定。更具體的說，您應該確定：
  • 資料和記錄檔除了彼此區隔外，也與其他任何項目隔離
  • 自動成長的設定正確
  • 已設定立即檔案初始化
  • 未啟用自動壓縮，而且壓縮不屬於任何維護計畫的一部分
當資料和記錄檔 (理想的情況下，應該是分別位在不同的磁碟區上) 與其他建立或擴充檔案的應用程式共用磁碟區時，就可能產生檔案分散。在資料檔案中，過度的檔案分散可能是致使執行查詢不佳 (尤其是那些掃描非常大量資料的查詢) 的一小部分導因。而在記錄檔案中，它對效能所造成的衝擊可能大得多，特別是如果自動成長是設定成每次在有需要時每個檔案才增加一點點大小的話。
記錄檔的內部分成幾個稱為虛擬記錄檔 (VLF) 的區段，一個記錄檔內的片段越多 (我在這裡使用單數，因為擁有多個記錄檔並沒有好處 — 每個資料庫應該只有一個記錄檔)，VLF 就越多。一旦記錄檔包含超過 200 個 VLF，就會拖累記錄相關作業的效能，例如記錄讀取 (比方說用於交易式複寫/復原)、記錄檔備份，甚至是 SQL Server 2000 中的觸發程序 (觸發程序的實作在 SQL Server 2005 已變更為資料列版本控制架構，來取代交易記錄檔)。
關於調整資料和記錄檔大小的最佳作法，是以適當的初始大小來建立它們。對於資料檔案，初始大小應該將短期內可能另外加入資料庫中的資料列入考量。譬如，假若資料的初始大小是 50GB，但是您知道在未來六個月內會另外加入 50GB 的資料，那麼一開始將資料檔案建立為 100GB 就很合理，這樣一來，就不用為了達到這樣的大小而一連增加好幾次。
不幸的是，記錄檔就沒那麼簡單了，您還必須考慮像是交易大小 (長期執行的交易要等到完成之後才能從記錄檔清除) 和記錄備份頻率 (因為這是用來移除記錄檔中的非作用部分) 等因素。如需詳細資訊，請參閱由內人 Kimberly Tripp 在 SQLskills.com 上撰寫的熱門部落格文章：＜提高交易記錄輸送量的 8 個步驟＞。
設定好之後，應該在不同的時候監視檔案大小，並且在一天適當的時間內主動手動增加大小。為了以防萬一，應該將自動成長保持開啟狀態，這樣一來，發生異常事件時，檔案還是可以視需要成長。反對讓檔案管理交由自動成長全權處理的原因是，小量的自動成長會導致檔案分散，而且自動成長可能很耗時，會在非預期的時候拖延應用程式工作負載。
自動成長應該設定為特定的值，而不是設成百分比，以限制執行自動成長所需的時間和空間 (如果真的發生的話)。比如，您可能會想要把 100GB 的資料檔案設定為固定 5GB 的自動成長大小，而不是 10%。這表示無論檔案最後變得多大，它始終只會成長 5GB，而不是在每次檔案變大時不斷增加數量 (10GB、11GB、12GB 等)。
當交易記錄增長時 (無論是手動或是透過自動成長而增加)，永遠都是以零初始化。資料檔案在 SQL Server 2000 中也有相同的預設行為，但自 SQL Server 2005 開始，您可以啟用立即檔案初始化，也就是跳過以零初始化檔案，因此實際上是立即進行成長和自動成長。與一般的認知剛好相反，這項功能在所有 SQL Server 版本內都可用。如需詳細資訊，請在 SQL Server 2005 或 SQL Server 2008 的《線上叢書》索引內輸入「立即檔案初始化 (instant file initialization)」。
最後還要特別注意，無論如何都不能啟用壓縮。壓縮可用來減少資料或記錄檔的大小，但是它是個極度干擾又耗用大量資源的程序，它會導致資料檔案中大量的邏輯掃描片段 (細節請見下文)，並且致使效能不佳。我改了 SQL Server 2005《線上叢書》記載的壓縮功能，以警告此副作用。然而，在特殊的情況下手動壓縮個別的資料和記錄檔是可接受的。
影片
觀賞 Paul Randal 示範壓縮和自動壓縮如何造成資料庫的嚴重分散問題。

自動壓縮是再糟也不過了，因為它每 30 分鐘就會在背景啟動，試圖壓縮自動壓縮資料庫選項設為 true 的資料庫。這個程序有點難以捉摸，因為它只壓縮擁有 25% 以上可用空間的資料庫。自動壓縮會使用大量的資源，並且會導致效能低劣的分散情形，因此無論如何都是不良的計畫。您應該使用下列命令永遠關閉自動壓縮：
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
若定期維護計畫內包含手動資料庫壓縮命令的話，也沒有好到哪裡去。如果您發現資料庫在維護計畫壓縮它之後還是繼續成長，那是因為資料庫需要其中的空間來執行。
最佳的辦法是允許資料庫成長到穩定狀態的大小，然後全然避免執行壓縮。您可以在我舊的 MSDN® 部落格上找到關於使用壓縮的缺點的詳細資訊，還有一些關於 SQL Server 2005 中新演算法的說明，網址是 blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx。

索引片段
除了檔案系統層級還有記錄檔內部的片段之外，資料檔案裡面存放資料表和索引資料的結構內也可能產生片段。資料檔案可能發生的片段有兩種基本類型：
  • 個別資料和索引頁的片段 (有時候稱為內部片段)
  • 由頁面組成之索引或資料表結構內部的片段 (稱為邏輯掃描片段和範圍掃描片段)
內部片段是頁面中有很多空白空間的地方。如 [圖 1] 所示，資料庫中的每一頁大小是 8KB，而且有 96 個位元組的頁首；因此，一頁大約可以儲存 8096 個位元組的資料表或索引資料 (資料和資料列結構內部特定的資料表和索引，可在我的部落格上的「深入儲存引擎 (Inside The Storage Engine)」類別中找到，網址是 sqlskills.com/blogs/paul)。如果每個資料表或索引記錄的大小超過頁面的一半，就可能發生空白空間，因為在這種情況下，每頁只能存放一筆記錄。要修正這個問題可能相當困難，甚或不太可能，因為這需要變更資料表或索引結構描述才辦得到，譬如將索引鍵變更成像 GUID 一樣不會產生隨機插入點。
[圖 1] 資料庫頁面結構 (按一下以放大影像)
內部片段比較常起源於資料修改，例如插入、更新和刪除等，這些修改都可能在頁面上留下空白空間。管理不善的填滿因數也可能導致片段；如需詳細資訊，請參閱《線上叢書》。視資料表/索引結構描述和應用程式的特性而定，空白空間一經建立後可能就完全無法重複使用，而且可能導致資料庫內無法使用的空間不斷增加。
比方說，假設有個內含一億個資料列的資料表，且平均的記錄大小是 400 個位元組。經過一段時間後，應用程式的資料修改模式在每一頁留下了平均 2800 個位元組的可用空間。資料表所需的總空間大約是 59GB，計算的方式是每 8KB 的頁面可放 8096-2800 / 400 = 13 筆記錄，然後將一億除以 13，以求得頁數。如果空間沒有浪費掉，那麼每頁應該可容納 20 筆記錄，將所需的總空間減少為 38GB。這可省下不少的空間！
資料/索引頁上面浪費掉的空間，可能為此需要更多頁面來容納相同的資料量。這不僅會佔用更多磁碟空間，也表示查詢需要發出更多的 I/O 來讀取相同的資料量。而且所有這些額外的頁面在資料快取中也會花更多的空間，因而佔用更多的伺服器記憶體。
邏輯掃描片段是由一個叫做頁面分割的作業所引起。當某記錄必須插入特定的索引頁 (根據索引鍵定義)，而頁面上沒有足夠的空間來容納要插入的資料時，便會發生這種現象。頁面於是一分為二，而大約 50% 的記錄會移到新配置的頁面。在實體上這個新頁面通常不與舊頁面相鄰，因此稱為片段。範圍掃描片段在概念上與此類似。資料表/索引結構內的片段會影響 SQL Server 進行有效的掃描，無論是對整個資料表/索引，或受到查詢 WHERE 子句繫結限制 (例如 SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000) 都一樣。
[圖 2] 顯示含 100% 填滿因數且無片段的新建索引頁 — 這些頁面都已滿，而且頁面的實際順序與邏輯順序相符。[圖 3] 顯示在隨機插入/更新/刪除作業後可能產生的片段。
[圖 2] 不含片段的新建索引頁；頁面 100% 填滿 (按一下以放大影像)
[圖 3] 在隨機插入、更新和刪除作業之後顯示內部和邏輯掃描片段的索引頁 (按一下以放大影像)
分散的情形有時候可以透過變更資料表/索引結構描述加以避免，但是我在前文有提到，這可能非常困難，甚或是不可能的。如果預防措施不可行，還是有辦法在發生片段後加以移除 — 特別是透過重建或重新組織索引。
重建索引牽涉到建立一份新的索引複本 — 經過適當壓縮，而且盡可能相鄰 — 然後丟棄分段的舊索引。當 SQL Server 在移除舊索引之前建立新索引複本之時，它在資料檔案內需要有大約與索引大小相當的可用空間。在 SQL Server 2000 中，重建索引向來是離線作業。而在 SQL Server 2005 Enterprise Edition 中，索引重建可在線上進行，不過有幾項限制。另一方面說來，重新組織則是使用就地演算法來壓縮和重組索引，它只需要 8KB 的額外空間就可執行 — 而且永遠是在線上執行。事實上，在 SQL Server 2000 中，我特別將索引重新組織程式碼寫成是替代重建索引且不佔空間的線上方案。
在 SQL Server 2005 中，要調查的命令為 ALTER INDEX … REBUILD 以重建索引，還有 ALTER INDEX … REORGANIZE 以重新組織索引。此語法分別取代了 SQL Server 2000 命令 DBCC DBREINDEX 和 DBCC INDEXDEFRAG。
這些方法之間有許多需要取捨，例如產生的交易記錄量，資料庫當中所需的可用空間量，以及處理序是否能在不損失工作的情況下中斷。您可以在 microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx 找到討論這些取捨，以及其他內容的白皮書。此白皮書是以 SQL Server 2000 為基礎，但其中的概念也適用於之後的版本。
與其抓破頭想搞清楚哪些索引產生片段，還有移除片段是否有任何好處，有些人乾脆選擇每晚或每週重建或重新組織所有索引 (比如，使用維護計畫選項)。雖然這對於只想要盡可能不多花力氣安置對策的非自願 DBA 來說可能是不錯的解決方案，但要注意的是，對於大型資料庫或資源非常昂貴的系統來說，可能是下下策。
比較聰明的方法是使用 DMV sys.dm_db_index_physical_stats (或是 SQL Server 2000 中的 DBCC SHOWCONTIG) 定期判斷有哪些索引產生片段，然後決定是否以及如何在這些索引上操作。白皮書也討論到使用這些目標更明確的抉擇。除此之外，您可以參考一些進行此篩選動作的範例程式碼，如果是 SQL Server 2005 中的 DMV sys.dm_db_index_physical_stats，請參閱《線上叢書》的範例 D (msdn.microsoft.com/library/ms188917)，如果是 SQL Server 2000 及之後版本，請參閱《線上叢書》的範例 E (msdn.microsoft.com/library/aa258803)。
無論您採用哪種方法，都強烈建議您定期調查和修正分散情形。
查詢處理器是 SQL Server 中描述查詢應該如何執行的部分 — 特別是要使用哪些資料表和索引，以及在上面要執行哪些作業以取得結果，這就稱為查詢計畫。影響此決策程序最重要的一些資訊，是描述資料值在資料表或索引內的各資料行的散佈情況的統計資料。很顯然地，統計資料必須要準確且是最新的，對查詢處理器才有用，否則可能會選擇成效不彰的查詢計畫。
統計資料是藉由讀取資料表/索引資料，然後判斷相關資料行的資料散佈情形而產生的。統計資料除了可以透過掃描特定資料行的所有資料值 (完整掃描) 來建置之外，也可以根據使用者指定的資料百分比 (取樣掃描) 來建置。若資料行內的值散佈的非常平均的話，那麼取樣掃描就綽綽有餘了，而且這也會使建立和更新統計資料的速度比完整掃描快。
請注意，您可以透過開啟 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS 資料庫選項來自動建立及維護統計資料，如 [圖 4] 所示。這些選項預設會開啟，但要是您才剛剛繼承資料庫，應該再確認一下。統計資料有時候可能會過期，在這種情況下，可在特定統計資料集上使用 UPDATE STATISTICS 作業來手動更新它們。或者，也可以使用 sp_updatestats 預存程序，這會更新所有過期的統計資料 (在 SQL Server 2000 中，無論使用期限為何，sp_updatestats 都會更新所有統計資料)。
[圖 4] 透過 SQL Server Management Studio 變更資料庫設定 (按一下以放大影像)
如果您想要把更新統計資料的工作當作定期維護計畫的一部分，有一點應該要注意。那就是，UPDATE STATISTICS 和 sp_updatestats 預設都會使用之前指定的取樣等級 (若有指定的話) — 而這可能低於完整掃描。索引重建作業會以完整掃描自動更新統計資料。如果您在索引重建之後手動更新統計資料的話，最後可能會得到比較不準確的統計資料！如果透過手動更新進行的取樣掃描覆寫索引重建產生的完整掃描的話，就可能發生這種情況。另一方面，重新組織索引則完全不會更新統計資料。
同樣地，很多人的維護計畫都會在重建所有索引前後的某段時間內更新全部的統計資料 — 最後也可能得到比較不準確的統計資料而完全不知情。如果您真的決定不時重建所有索引，這也會一併處理統計資料。若是您決定採取較複雜的途徑來移除片段的話，也應當依照相同的方式來維護統計資料。以下是我的建議：
  • 分析索引，並判斷要在哪些索引上操作，以及如何移除片段。
  • 對於所有未重建的索引，更新統計資料。
  • 針對所有未編列索引的資料行更新統計資料。
如需有關統計資料的詳細資訊，請參閱白皮書《Microsoft® SQL Server 2005 中查詢最佳化工具所使用的統計資料》(英文) (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx)。

損毀偵測
討論過效能相關的維護工作之後，我想換一下話題，探討損毀偵測和緩和措施。
要說您管理的資料庫包含的全是乏人問津的無用資訊幾乎是不可能的 — 所以您要怎麼在發生嚴重損壞的情況下，確保資料仍舊未遭損毀而且可以復原呢？籌措完整的嚴重損壞修復和高可用性策略的細節，已超過本文的討論範圍，但是有幾件簡單的事您可以開始著手進行。
大部分難以制止的損毀都是因「硬體」而起。為什麼要特別強調是「硬體」呢？這裡所謂的硬體其實是指「在 SQL Server 之下 I/O 子系統內的某個東西」。I/O 子系統是由各種元素組成，例如作業系統、檔案系統磁碟機、裝置驅動程式、RAID 控制器、纜線、網路，以及實際的磁碟機本身。看來，可能 (還有真的) 發生問題的地方還真不少。
最常見的問題之一，是當電源發生中斷而磁碟機正寫出資料庫頁面的時候。如果磁碟機無法在電源中斷之前完成寫入 (或是寫入作業已經快取，但沒有足夠的電池電源可以清除磁碟機的快取)，結果可能會在磁碟上產生不完整的頁面映像。會發生這種情況是因為 8KB 資料庫頁面實際上是由 16 個連續的 512 位元組磁碟磁區所構成。不完整的寫入作業可能寫入了新頁面的部分磁區，卻留下前一頁面映像的一些磁區。這種情況就稱為損毀頁。當發生這種情況時，您要如何偵測出來呢？
SQL Server 有個機制可以偵測這種狀況。它會從頁面的每個磁區儲存幾個位元，然後在它們的位置內寫入特定的模式 (這是發生在頁面寫入磁碟之前)。如果當讀回頁面時發現模式不同，SQL Server 就知道頁面已「損毀」，並且會產生錯誤。
SQL Server 2005 及之後的版本提供一個較為完善的機制，稱為頁總合檢查碼，它可偵測頁面上的任何損毀。動作包括在寫出頁面之前於頁面上寫入全頁總合檢查碼，然後在讀回頁面時進行測試，就跟偵測損毀頁一樣。啟用頁總合檢查碼之後，必須將頁面讀入緩衝區集區，經過某種方式的變更，然後再次寫出磁碟後以頁總合檢查碼保護。
因此，最佳的作法是對 SQL Server 2005 之前的版本啟用頁總合檢查碼，並對 SQL Server 2000 啟用損毀頁偵測。若要啟用頁總合檢查碼，請使用：
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
若要對 SQL Server 2000 啟用損毀頁偵測，請使用此命令：
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
這些機制可讓您偵測出頁面上發生的損毀，但只有在讀取頁面時才偵測得出。要如何輕鬆地強制讀取所有配置的頁面呢？這麼做 (還有找出其他損毀類型) 的最佳方法是使用 DBCC CHECKDB 命令。無論指定何種選項，這個命令始終會讀取資料庫中的所有頁面，藉此確認任何頁總合檢查碼或損毀頁偵測。您也應該設定警示，如此一來，當使用者在執行查詢時碰到損毀問題時，您就可以獲知。使用嚴重性 24 錯誤的警示，您就可以收到上述所有問題的通知 ([圖 5])。
[圖 5] 設定所有嚴重性 24 錯誤的警示 (按一下以放大影像)
所以，另外一個最佳作法是在資料庫上定期執行 DBCC CHECKDB，以查驗它們的完整性。這個命令有許多種變形，執行的頻率也有許多疑問。不幸的是，目前並沒有任何白皮書討論此主題。不過，因為 DBCC CHECKDB 是我為 SQL Server 2005 所寫的主要程式碼，所以我在部落格上也寫了很多與其相關的內容。請參閱我的部落格中「從各種角度看 CHECKDB (CHECKDB From Every Angle)」類別 (sqlskills.com/blogs/paul)，即可找到許多關於一致性檢查、最佳作法和 How-to 建議的深度文章。給非自願 DBA 的基本原則是，以進行完整資料庫備份的頻率來執行 DBCC CHECKDB (下文有詳細說明)。我建議您執行下列命令：
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
如果此命令有任何輸出的話，表示 DBCC 在資料庫中找到了一些損毀。因此，現在的問題是，當 DBCC CHECKDB 找到損毀時該怎麼辦。這正是備份派上用場的地方。
發生損毀或其他嚴重損壞時，最有效的復原方法是從備份還原資料庫。這是假設您原本就有備份，而且備份本身並未損毀。但人們往往想知道如果沒有備份的話，該怎麼讓嚴重損毀的資料庫恢復執行狀態。答案很簡單，您沒有辦法這麼做，一定會有某種形式的資料損失，而這些資料損失可能會破壞您的商務邏輯和相關的資料完整性。
因此定期製作備份非常重要。使用備份和還原的複雜細節已超出本文討論範圍，但且讓我提供如何建立備份策略的快速入門。
首先，您應該定期製作完整的資料庫備份。這提供您一個時間點以便稍後還原。您可以使用 BACKUP DATABASE 命令製作完整的資料庫備份。相關範例請查看《線上叢書》。若要多添一層保護，您可以使用 WITH CHECKSUM 選項，它會驗證要讀取之頁面的頁總合檢查碼 (如果有的話)，並計算整個備份的總合檢查碼。您選擇的頻率應該反映您的業務能夠承受損失的資料或工作多寡。比方說，每天製作一份完整資料庫備份表示您在發生嚴重損壞的情況下，可能損失最多一天的資料。如果您只使用完整資料庫備份，就應該處於 SIMPLE 復原模式 (通常稱為復原模式)，以避免與交易記錄成長管理相關的複雜性。
其次，始終將備份多保留幾天的時間，以防備份損毀 — 幾天前的備份總比完全沒有備份好。您也應該使用 RESTORE WITH VERIFYONLY 命令 (請同樣參閱《線上叢書》) 來查驗備份的完整性。如果您在建立備份時使用 WITH CHECKSUM 選項，執行驗證命令將檢查備份總合檢查碼是否仍舊有效，另外也會重新檢查備份當中各頁面的所有頁總合檢查碼。
第三，如果每日完整資料庫備份不符合業務所能承受的最大資料/工作損失，您應該考慮採用差異資料庫備份。差異資料庫備份是以完整資料庫備份為基礎，並且包含自前次完整資料庫備份以來的所有變更記錄 (常有人誤以為差異備份會遞增 — 其實不然)。每天製作完整資料庫備份，然後每四個小時製作差異資料庫備份，是可行的策略之一。差異備份提供了額外的時間點復原選項。如果您只使用完整資料庫和差異資料庫備份，還是應該繼續使用 SIMPLE 復原模型。
最後，最終的復原能力來自使用記錄備份。這只能在 FULL (或 BULK_LOGGED) 復原模型下使用，並且提供了自上次記錄備份以來產生的所有記錄備份。透過定期的完整資料庫 (或許加上差異資料庫) 備份來維護一組記錄備份，便有無限量的時間點可供復原 — 包括最新狀態的復原。唯一要權衡的是，除非製作記錄備份來「釋放」交易記錄，否則它會不斷增長。此處的理想策略是每天進行完整資料庫備份，每四個小時進行差異資料庫備份，然後每半個小時進行記錄備份。
決定和履行備份策略，可能是項複雜的工作。您至少應該有定期的完整資料庫備份，以確定您至少有一個時間點可以從中復原。
如您所見，要確保資料庫保持健全與可用，有幾項「必做」的工作。以下是我為接掌資料庫的非自願 DBA 所提供的最終檢查清單：
  • 移除過多的交易記錄檔案片段。
  • 正確設定自動成長。
  • 關閉任何已排定的壓縮作業。
  • 開啟立即檔案初始化。
  • 設立標準程序來偵測和移除索引片段。
  • 開啟 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS，另外設定一個標準程序來更新統計資料。
  • 開啟頁總合檢查碼 (或至少在 SQL Server 2000 上開啟毀損頁偵測)。
  • 採用標準程序來執行 DBCC CHECKDB。
  • 設立標準程序製作完整資料庫備份，另外進行差異和記錄備份以利時間點復原。
我在本文中已提供 T-SQL 命令，但您也可以從 Management Studio 進行很多動作。希望我為您提供了一些實用的指標來進行有效的資料庫維護。如果您有任何意見或疑問，請寄信到 paul@sqlskills.com。

Paul S. Randal 是 SQLskills.com 的常務董事，同時也是 SQL Server MVP。他在 1999 年 2007 年間服務於 Microsoft 的 SQL Server 儲存引擎 (SQL Server Storage Engine) 小組。Paul 是嚴重損壞修復、高可用性和資料庫維護方面的專家。他的部落格位於 SQLskills.com/blogs/paul。

© 2008 Microsoft Corporation and CMP Media, LLC.著作權所有，並保留一切權利。未經許可，不得部分或全部重製。


Windows 系統管理
為您的伺服器把脈
Steven Choy
綜覽：
  • 自訂效能監視器
  • 關於測量內容與測量頻率的指導方針
  • 重要計數器的概觀以及要尋找什麼資訊

目錄
讓結果一目瞭然
測量的內容與時機
硬碟瓶頸
記憶體瓶頸
處理器瓶頸
網路瓶頸
處理序瓶頸
總結
如果星期一一早剛到辦公室，就碰到一位使用者在那裡等著，氣急敗壞的抱怨伺服器慢得跟老牛拉車一樣。這時候您該怎麼幫他呢？效能
監視器 (內建在 Windows® 的工具，相當好用) 可以幫助您診斷問題。
您可以在命令提示字元輸入 perfmon，或者從 [系統管理工具] 功能表，選取 [效能] 或 [可靠性]，然後選取 [效能監視器] (在 Windows Vista® 和 Windows Server® 2008)，來存取效能監視器。如果要加入效能計數器以及您要監視的物件，只要按一下加號，然後從許多選項當中選擇即可。
那麼，您該如何為伺服器把脈呢？伺服器有超過 60 個基本效能物件，每一個物件都含有多個計數器。我將在本文討論揭示伺服器重大徵兆的計數器，同時也將說明 Microsoft® 服務支援工程師在排解效能相關問題時最常用的標準取樣間隔。
當然，排解疑難時，基準線也是非常重要的參考點。由於伺服器負載得視商務需求而定，有時候也會隨著商務週期改變，因此每隔一個指定時段，就要根據標準工作負載建立一個基準線。這樣不但可以觀察變化的情況，也可以找出它的趨勢。

讓結果一目瞭然
在分析代表伺服器重大徵兆的計數器之前，先告訴您兩個竅門，更方便您使用效能監視器來測量伺服器的重大徵兆。附帶一提，雖然 Windows Vista 和 Windows Server 2008 用不著，不過如果您是在舊版 Window 上執行效能監視器的話，這兩個竅門還是派得上用場。
首先，您可以移除所有令人分心的取樣雜訊，這些取樣雜訊會混淆趨勢線的圖形檢視。在 Windows Vista 和 Windows Server 2008 中，效能監視器在圖形檢視中可以顯示多達 1000 個資料點，但是在舊版的 Windows 上，最多只能顯示 100 個，一旦超過 100 個資料點，效能監視器就會把這些資料點放在「值區」內。值區是以一條垂直線表示，指出值區內含的取樣點最小值、平均值以及最大值。
您可以從 [圖 1] 所示的圖形看出，同時顯示這麼多資料，很難看出趨勢線。而 [圖 2] 的圖形則顯示，當您把所有不相干的視覺資訊全部關閉之後，要掌握資料就容易多了。有關如何關閉這些垂直線的詳細資訊，請參閱知識庫文章 ( support.microsoft.com/kb/283110)。
[圖 1]與令人分心的值區同時顯示的效能資料，並沒有用逗號加以區隔(按一下以放大影像)
[圖 2]以逗號加以區隔的資料檢視較為清楚明確(按一下以放大影像)
第二個竅門是在數字當中加入逗號加以區隔，讓計數器所顯示的數值更容易分辨。Windows Vista 和 Windows Server 2008 預設都有啟用逗號，但是舊版 Windows 的效能監視器就沒有。
也許在您聽來沒什麼不同，可是只要看看 [圖 1] 當中沒有逗號的效能計數器，再看看 [圖 2] 當中有逗號的計數器，馬上就發現後者更清晰易懂。如需在 Windows XP 效能計數器加入逗號分隔字元的簡明指示，請參閱知識庫文章 (support.microsoft.com/kb/300884)。

測量的內容和時機
當資源到達容量上限時，就會產生瓶頸，使整個系統的效能降低。瓶頸通常是因為資源不足或配置不當、元件無法正常運作，以及程式要求資源不當所致。
會產生瓶頸而影響伺服器效能的資源區域主要有五個：實體磁碟、記憶體、處理序、CPU 和網路。如果上述任何一項資源使用過度，伺服器或應用程式就可能明顯變慢，或甚至當機。接下來我會一一解說每一個區域，針對您應該使用的計數器給予指引，並提供建議閾值來為伺服器把脈。
由於取樣間隔對於記錄檔和伺服器負載的大小有明顯的影響，因此最好能夠根據平均耗用時間來設定問題發生的取樣間隔，建立基準線，以避免問題再次發生。這樣可以幫助您找出導致問題的趨勢走向。
不消 15 分鐘的時間，就可以提供一個不賴的視窗，在進行一般作業時用來建立基準線。如果發生問題的平均耗用時間是四小時左右，請將取樣間隔設為 15 秒。如果發生問題的取樣間隔時間是八小時或八小時以上，取樣間隔就不要短於 5 分鐘；否則，最後記錄檔會變得巨大無比，而很難分析資料。

硬碟瓶頸
由於磁碟系統會儲存和處理伺服器的程式與資料，因此影響磁碟速度和使用情形的瓶頸，勢必會使伺服器的整體效能大打折扣。
請注意，如果伺服器尚未啟用磁碟物件，必須使用命令列工具 Diskperf 來啟用它們。另外還有一點，% Disk Time 可能會超過 100%，因此我比較喜歡使用 % Idle Time、Avg. Disk sec/Read 和 Avg. Disk sec/write 讓我更準確的瞭解硬碟的忙碌程度。您可以在知識庫文章 (support.microsoft.com/kb/310067) 找到更多關於 % Disk Time 的資訊。
下面是 Microsoft 服務支援工程師在監視磁碟所用的計數器。
LogicalDisk\% Free Space 它會測量所選邏輯磁碟機上的可用空間百分比。如果此值低於 15%，就要注意了，因為這表示儲存重要檔案的作業系統可用空間快要用完了。解決方法很簡單，就是增加磁碟空間。
PhysicalDisk\% Idle Time 它會測量在取樣間隔期間，磁碟閒置時間的百分比。如果這個計數器低於 20%，就表示磁碟系統已達飽和狀態。您可以考慮把目前的磁碟系統換成速度較快的磁碟系統。
PhysicalDisk\Avg.Disk Sec/Read 它會測量從磁碟讀取資料的平均時間 (以秒為單位)。如果此值大於 25 毫秒 (ms)，就表示磁碟系統從磁碟機讀取的速度有所延遲。如果是掌控 SQL Server® 和 Exchange Server 的重要伺服器，則能夠接受的閾值就更遠低於此，大約 10 毫秒左右。最符合邏輯的解決方案，是把磁碟系統換成速度更快的磁碟系統。
PhysicalDisk\Avg.Disk Sec/Write 它會測量將資料寫入磁碟的平均時間 (以秒為單位)。如果此值大於 25 毫秒，就表示磁碟系統寫入磁碟的速度有所延遲。如果是掌控 SQL Server 和 Exchange Server 的重要伺服器，則能夠接受的閾值就更遠低於此，大約 10 毫秒左右。最可能的解決方案，是把磁碟系統換成速度更快的磁碟系統。
PhysicalDisk\Avg.Disk Queue Length它會指出目前有多少個 I/O 作業正在等候使用磁碟機。如果此值大於磁針數再加上 2，就表示磁碟本身可能就是瓶頸所在。
Memory\Cache Bytes 它會指出檔案系統快取正在使用的記憶體量。如果此值大於 200MB，就表示可能發生磁碟瓶頸了。

記憶體瓶頸
記憶體不足通常是因為 RAM 不足、記憶體流失或是將記憶體參數置於 boot.ini 內。在探討記憶體計數器之前，我應該先討論 /3GB 參數。
記憶體越多，越能減少磁碟 I/O 活動，並且提升應用程式效能。/3GB 參數當初是在 Windows NT® 中引進，它的作用是為採用使用者模式的程式提供更多記憶體。
Windows 所用的虛擬位址空間有 4GB (這與系統擁有多少實體 RAM 無關)。根據預設，較低層的 2GB 是保留給採用使用者模式的程式，而較上層的 2GB 則是保留給採用核心模式的程式。若使用 /3GB 參數，則會提供 3GB 給使用者模式的處理序。當然，如此一來會佔用到核心記憶體，使它只剩 1GB 的虛擬位址空間。而這樣可能會產生問題，因為 Pool Non-Paged Byte、Pool Paged Byte、Free System Page Tables Entries 和桌面堆積全部都擠在 1GB 的空間當中。因此，/3GB 參數應該只在環境中經過徹底測試之後再使用。
如果您懷疑您遇到的瓶頸與記憶體有關，可以考量這一點。如果 /3GB 參數不是問題癥結所在，則可以使用這些計數器來診斷可能的記憶體瓶頸。
Memory\% Committed Bytes in Use它會測量已被認可的位元組數與認可限制之間的比例 — 換句話說，就是使用中的虛擬記憶體量。如果此值大於 80%，就表示記憶體不足。解決方法很簡單，就是增加記憶體。
Memory\% Available Mbytes它會測量執行處理序所能使用的實體記憶體量 (以 MB 為單位)。如果此值小於總實體 RAM 的 5%，就表示記憶體不足，可能會增加分頁活動。解決這個問題的方法很簡單，只要增加記憶體就行了。
Memory\Free System Page Table Entries 它會指出系統目前未在使用中的分頁表項目數。如果此值小於 5,000，就表示有記憶體流失的現象發生。
Memory\Pool Non-Paged Bytes 它會測量非分頁集區的大小 (以位元組為單位)。這是系統記憶體區域，專門容納無法寫入磁碟、而必須留在實體記憶體的物件 (只要有配置物件的話)。如果此值大於 175MB (若使用 /3GB 參數的話，則為 100MB )，就表示可能有記憶體流失的現象發生。這時候系統事件記錄檔會記錄一般事件識別碼 2019。
Memory\Pool Non-Paged Bytes 它會測量分頁集區的大小 (以位元組為單位)。這是系統記憶體區域，專門容納在不使用的時候可以寫入磁碟的物件。如果此值大於 250MB (若使用 /3GB 參數的話，則為 170MB )，就表示可能有記憶體流失的現象發生。這時候系統事件記錄檔會記錄一般事件識別碼 2020。
Memory\Pages per Second 它會測量從磁碟讀取網頁或者將網頁寫入磁碟以解決硬體分頁錯誤的速率。如果此值大於 1000 (因為過量分頁的關係)，就表示可能有記憶體流失的現象發生。

處理器瓶頸
如果處理器體力透支，可能是因為處理器本身沒有提供足夠的電源，或者因為應用程式不足的關係。您必須再三檢查處理器是否耗費太多時間在分頁上面，而導致實體記憶體不足。下面是 Microsoft 服務支援工程師調查可能的處理器瓶頸所用的計數器。
Processor\% Processor Time它會測量處理器在執行非閒置執行緒時，已耗用時間的百分比。如果此百分比大於 85%，就表示處理器已經筋疲力盡，伺服器需要換一個速度較快的處理器。
Processor\% User Time 它會測量處理器在使用者模式所耗用時間的百分比。如果此值很高，表示伺服器正忙著處理應用程式。也許您可以把即將用完處理器資源的應用程式最佳化，來解決這個問題。
Processor\% Interrupt Time 它會測量處理器在特定的取樣間隔期間，花在接收和處理硬體中斷的時間。如果此值大於 15%，就表示這個計數器可能有硬體問題。
System\Processor Queue Length它會測量處理器佇列中的執行緒數目。如果此值大於延伸時段所用的 CPU 數目的兩倍，就表示伺服器沒有足夠的處理器電源。

網路瓶頸
網路瓶頸肯定會影響伺服器透過網路收送資料的能力。這可能是伺服器的網路卡問題，也可能是網路已經飽和，需要加以分段。您可以使用下列計數器來診斷可能的網路瓶頸。
Network Interface\Bytes Total/Sec 它會測量每一張網路介面卡收送位元組的速率 (包括結構字元在內)。如果您發現耗用的介面超過 70%，就表示網路已飽和。如果是 100-Mbps NIC，則耗用的介面是 8.7MB/秒 (100Mbps = 100000kbps = 12.5MB/秒* 70%)。碰到這種情形，可以安插一個較快的網路卡，或者將網路分段。
Network Interface\Output Queue Length 它會測量輸出封包佇列的長度 (以封包為單位)。如果此值大於 2，就表示網路已飽和。您可以安插一個較快的網路卡，或者將網路分段，來解決這個問題。

處理序瓶頸
如果您的處理序行為不當，或者沒有最佳化，就會使伺服器的效能大打折扣。執行緒和控制碼外洩最後會使伺服器當掉，而過度使用處理器，則會使伺服器變得如老牛拉車一樣慢。下面是診斷處理序相關瓶頸時不可或缺的計數器。
Process\Handle Count 它會測量處理序目前開啟的控制碼總數。如果此值大於 10,000，就表示可能有控制碼外洩的現象發生。
Process\Thread Count 它會測量處理序中目前有多少執行緒在作用中。如果此值介於執行緒數的上限和下限之間，並且大於 500，就表示可能有執行緒外洩的現象發生。
Process\Private Bytes它會指出這個處理序已經配置、而且不能與其他處理序共用的記憶體量。如果此值介於執行緒數的上限和下限之間，並且大於 250，就表示可能有記憶體流失的現象發生。

總結
現在您知道 Microsoft 服務支援工程師是使用哪些計數器來診斷各種瓶頸了。當然，您很有可能會找到自己最愛用、並針對您特定需求而量身打造的一組計數器。您一定希望每次需要監視伺服器時，都不必手動加入所有您最愛用的計數器。還好，效能監視器可讓您選擇將您所有的計數器儲存在範本中，供日後使用。
也許您還在納悶，應該在本機還是遠端執行效能監視器。而且在本機執行效能監視器時，對效能會有什麼衝擊？這全看您的環境而定。如果您將間隔至少設定為 5 分鐘，對伺服器效能的衝擊可說是微乎其微。
如果您知道伺服器上有效能問題，可能要選擇從本機執行效能監視器，因為伺服器上的資源要是耗盡，效能監視器可能無法從遠端電腦擷取資料。當您要監視或設定多部伺服器的基準線時，最適合的方法就是從中央電腦進行遠端執行。

Steven Choy 是 Microsoft 專業領域工程的資深專業領域工程師。他曾支援政府機構和商務客戶有關桌上型電腦部署與移轉、修補程式管理以及群組原則等專案。他目前致力於伺服器虛擬化與伺服器健康狀態的研究。


System Center
System Center Operations Manager 中的 Windows PowerShell
Marco Shaw
綜覽：
  • OpsMgr 命令殼層
  • OpsMgr 監視提供者
  • 自動化一般管理工作
  • 一些 Windows PowerShell 的實例

目錄
Operations Manager 命令殼層
OpsMgr 監視提供者
自動化一般工作
真實世界
總結
System Center Operations Manager 2007 (OpsMgr) 讓系統管理員能夠存取 Windows PowerShell，這是用於自動化工作的超強新指令碼語言。它自 2006 年 11 月公開發行以來，下載次數已超過兩百萬次。
在本文中，我將討論 Windows PowerShell®，並探討如何將它應用到 Operations Manager 中。我會說明一些可透過 Windows PowerShell 幫助您以更加簡單及更自動化的方式來完成的一般工作，並介紹幾個提供實用指令碼和說明的網站。我也整理了當今許多使用 Windows PowerShell 的專家們的見解和部落格文章。
雖然 Microsoft 已相繼發行了 Windows PowerShell 2.0 的 Community Technology Preview (CTP) 版本，但這些版本既不適用於生產環境，也未經過 OpsMgr 的測試，因此不應該安裝在生產系統上。

Operations Manager 命令殼層
在 OpsMgr 中，您是透過命令殼層存取 Windows PowerShell，這跟預設的 Windows PowerShell 環境很類似，差別在於它會載入主控台檔案，另外也會載入指令碼，這個指令碼會利用 OpsMgr 指令程式、函數和預設連線將環境初始化。
您可以從 OpsMgr [開始] 功能表上的圖示，或是在 OpsMgr UI 主控台中的電腦名稱上按右鍵來啟動命令殼層 (見 [圖 1])。這會直接把您帶到 OpsMgr 監視磁碟機路徑中 (我稍後會討論到)。
[圖 1] 從 OpsMgr UI 開啟命令殼層 (按一下以放大影像)
Windows PowerShell 是透過 OpsMgr SDK 與 OpsMgr 互動。幸運的是，對系統管理員來說，您一般想要從命令列自動化或完成的許多工作，都已經有提供指命程式。如果特定的工作沒有可用的指令程式，您可以使用 Windows PowerShell 與 SDK 互動。
Operations Manager 命令殼層所提供的命令都包含在嵌入式管理單元中 — 這是由 Windows PowerShell 載入的 DLL，當中包含了用於 OpsMgr 系統管理的指令程式。這個嵌入式管理單元也包含了 OperationsManagerMonitoring Windows PowerShell 提供者，亦稱為監視提供者，這項工具可讓您瀏覽連線、群組和監視物件，跟瀏覽檔案系統很像。
您可以使用 Get-OperationsManagerCommand 指令程式取得 OpsMgr 專用的完整指令程式清單，如 [圖 2] 所示 (它在第一版是個函數，因為不支援 Tab 鍵自動完成功能，所以在 SP1 變成指令程式)。Operations Manager 的原始版包含 74 個指令程式，而 OpsMgr SP1 則有 87 個。
[圖 2] 取得 OpsMgr 指令程式的清單 (按一下以放大影像)

OpsMgr 監視提供者
藉著使用 Set-Location 指令程式，或是 alias cd，您可以一一瀏覽群組和電腦的配置。預設 Monitoringdrive 的基本配置看起來如下：
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
您可以從這裡接觸到更特定的物件。請注意，我在此案例中處理的是簡單的環境，也就是只有一部管理伺服器。安裝在管理群組內的第一部管理伺服器稱為 Root Management Server (RMS)。
命令殼層啟動時會建立一個稱為 Monitoring 的磁碟機，將該磁碟機對應到 OperationsManagerMonitoring 提供者的根目錄，最後將目前的位置或路徑設定為 Monitoring 磁碟機的根目錄。命令殼層接著會搜尋登錄，尋找要連接之預設 RMS 的名稱。如果與 RMS 的連線成功，則目前的位置或路徑便會設為該連線或 RMS 的名稱，如 [圖 3] 所示。
[圖 3] 命令殼層位置設為 RMS (按一下以放大影像)

自動化一般工作
讓我們來瞧瞧 Windows PowerShell 如何處理一些最常見的管理工作。
控制維護模式 無論您處理的是哪項工作，通常都要指定該工作應該發生的日期和時間。我將簡單介紹一下 Get-Date 指令程式，向您說明要這麼做有多簡單。[圖 4] 顯示了幾個範例。
[圖 4] 使用 Get-Date 指令程式 (按一下以放大影像)
如您所見，我建立了一個 $date 變數，當中包含了表示目前時間的物件。我接下來使用該物件支援的一些記錄方法來說明您如何能夠輕易地在五分鐘及五小時之後，分別取得日期和時間。如果我想要取得過去的值，只要使用 (-5) (-5) 來取代 (5) 就成了。
當您需要封鎖來自某電腦的所有警示時，可啟用維護模式。OpsMgr 2007 可讓您將 Windows® 服務，甚或是特定的資料庫，而不是整部電腦或群組置於維護模式。專門處理維護模式工作的指令程式有三種：Get-MaintenanceWindow、New-MaintenanceWindow 和 Set-MaintenanceWindow。
若要從命令殼層內部將電腦置於維護模式，請使用監視提供者瀏覽至所要的電腦或監視物件，然後叫用 New-MaintenanceWindow 指令程式，如 [圖 5] 所示。如您所見，這個動作會將稱為 Denver.contoso.com 的電腦置於維護模式。我同時也定義了維護視窗的開始時間立即生效，而結束時間則在整整一個小時之後生效。請注意，使用這種方法將電腦置於維護模式並不會停止所有警示，因為這個物件的 HealthService 和 HealthServiceWatcher 執行個體仍舊處於啟用狀態。
[圖 5] 使用 New-MaintenanceWindows 指令程式 (按一下以放大影像)
Microsoft OpsMgr 小組的專案經理 Boris Yanushpolsky 提供了一些非常實用的 Windows PowerShell 程式碼，這些程式碼可用來將所有參考電腦的物件設定成維護模式，他也解釋了如何在建立好指令碼之後使用這個程式碼。若要閱讀相關的詳細資訊，請參閱他的部落格，網址是 blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx。
有時候您必須判斷處於維護模式的物件是否真的應該處於該狀態。然而，一一巡視所有的物件來試著做出判斷可能是項相當艱鉅的任務。所幸，Boris Yanushpolsky 對此也有良策，那就是透過使用 OpsMgr SDK 的 Windows PowerShell 指令碼。您可以直接從他的部落格文章 (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) 將這段程式碼貼到命令殼層視窗，來取得所有處於維護模式的物件清單。
當某物件處於維護模式時，您應該在原始指定的結束時間之前結束維護期間。如果您對 Windows PowerShell 不陌生，可能會預期這樣的指令程式應該含有 Stop 或 Remove 等動詞，但實際上您必須使用 Set-MaintenanceWindow，如 [圖 6] 所示。
[圖 6] 使用 Set-MaintenanceWindows 來變更結束時間 (按一下以放大影像)
管理代理程式 系統管理員經常用到代理程式，就目前版本而言，有六個指令程式和一個函數可用來處理各種與代理程式相關的工作。您可以使用以下命令取得這份清單：
Get-Command *-agent*
自 SP1 版起，Install-AgentByName 不再是函數，而改成封裝為指令程式。因此建議您使用 Install-AgentByName 指令程式，因為它在支援和一致性方面提供較佳的基礎。
命令殼層所含的內建說明提供了一些使用 Install-Agent 和 Uninstall-Agent 指令程式的不錯範例。Microsoft OpsMgr 小組的資深軟體設計工程師 Roger Sprague，在他的部落格上也發表了一個替代方法，[圖 7] 中重現了此方法 (請參考他的原始文章，網址是 blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx)。
這段指令碼用在 OpsMgr RTM 沒什麼問題 (您必須位在監視提供者的根目錄 — 在本文中，即 monitoring:\oxford.contoso.com)，但不能用於 OpsMgr SP1。若要讓它能夠用在 OpsMgr SP1 中，應該將 [圖 7] 中的第一個命令變更如下：
$managementServer = Get-RootManagementServer
[圖 7] 安裝代理程式
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
到目前為止，代理程式是安裝在應該要監視的遠端系統上，但最後還有一個步驟，就是管理伺服器必須實際接受新代理程式，才能完整進行監視。如果沒有採取任何後續的動作，監視伺服器會自動接受新代理程式以進行監視。不過使用 Get-AgentPendingAction 指令程式也可以快速追蹤到這個接受程序。這一行程式碼可快速追蹤代理程式接受程序：
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
將這一行代入 Reject-AgentPendingAction，而不是 Approve-AgentPendingAction，您就可以在動作仍處於待決狀態時，封鎖 OpsMgr 伺服器接受這個代理程式。如果動作已決，請改用 Uninstall-Agent 指令程式。
如前所述，您也可以使用 Install-AgentByName，從命令列直接在要安裝代理程式的地方指定電腦。
使用管理套件 有四個指令程式可幫助您處理各種管理套件工作。您可以使用這個命令將它們列出：
Get-Command –noun ManagementPack
這個簡單的命令會提供目前安裝的管理套件，及其版本號碼：
Get-ManagementPack | Format-Table –autosize
現在我要使用命令殼層來安裝兩個使用這些安裝程式的一般管理套件：
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi
既然此處的目標是要展示命令殼層如何能讓常規的工作更加簡單，因此我要盡可能用最少的命令來進行此動作 (如 [圖 8] 所示)。我其實可以變更這個安裝程序，將無訊息旗標傳遞給安裝程式 (.msi 檔案)，但是我想要選擇可手動解壓縮的檔案位置。
[圖 8] 安裝管體套件 (按一下以放大影像)
接下來，我必須安裝通用程式庫，這可以使用下面的命令來進行：
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
然後我安裝了其他必要的管理套件：
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
如 [圖 9] 所示，內建的命令殼層說明提供了絕佳的範例，示範使用 Export-ManagementPack 指令程式來匯出未密封的管理套件。如果您想要匯出所有管理套件，請變更此行：
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
[圖 9] 匯出管理套件 (按一下以放大影像)
操控使用者角色 Get-UserRole 指令程式提供了一些可用來管理使用者的功能，但奇怪的是，它並沒有附隨補充的 Set 指令程式，因此您通常不會使用它來進行編輯或更新作業 (根據 Windows PowerShell SDK 說明文件)。如您在 [圖 10] 中所見，我先取得一份目前使用者角色的清單，然後新增一名使用者到「唯讀操作員」群組 (見 [圖 11])。
[圖 10] 顯示使用者角色 (按一下以放大影像)
[圖 11] 新增使用者 (按一下以放大影像)
啟用稽核收集服務 (ACS) ACS 是 Operations Manager 2007 中全新的選用功能，簡單的說，它提供了一種集中化方法來處理安全性稽核資訊。ACS 根據預設並不會啟用，一般來說，之後可以在未來的 OpsMgr 部署階段中設定。
需要針對 ACS 啟用大量代理程式時，Windows PowerShell 就派上用場了，它可以幫助自動化安裝程序。在 OpsMgr 的 Beta 測試期間，Microsoft 提供了一個指令碼來啟用所有代理程式上的 ACS。SystemCenterForum.org 的撰文者和部落格作者 Neale Browne 則進一步發揚光大，加入了對其他參數的支援。
SystemCenterForum.org 網站 (提供 Microsoft® System Center 解決方案的社群網站) 提供了兩種不同的 Windows PowerShell 指令碼，用於自動化 ACS 的安裝程序。若要設定特定群組內的所有代理程式，請使用 systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip。若要設定所有監視的代理程式，請下載 systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip。
啟用代理程式 Proxy 處理 您的 OpsMgr 環境可能包括無代理程式監視的裝置。這些裝置必須指派給管理伺服器，或是指派給由代理程式管理且提供遠端監視的裝置。您可以在 systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell 找到關於使用 Windows PowerShell 指令碼設定大量代理程式的詳細說明。指令碼的更新版本可自 systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip 取得。
還有其他條件，就是特定管理套件要求必須將代理程式設成 Proxy。如需詳細資料，請查閱管理套件說明文件。

真實世界
以下是進一步示範 Windows PowerShell 如何促進自動化的一些實例。
解析警示 您曾碰過必須刪除特定電腦上好幾個警示的情況嗎？或許是因為應用程式出錯，或是警示未經積極解析。以下這行命令將解析所有解析狀態為零的警示：
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
下一個範例的作用與前者一樣，但是它在擁有較多待決警示的較大規模環境內執行起來要快速許多：
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
效能方面之所以會有此差別，背後的原因是，當使用條件參數時，傳遞的值是直接提供給 SQL Server® 資料庫，而且只會傳回相關的資料。這減少了必須一路傳回 Windows PowerShell 主控台的物件數量。
現在您有一個快速的方法可以移除單一電腦所有待決的警示。您可以根據您的需求將此設為自動執行。
最後，下面這個快速命令可讓您檢視特定一天內的所有警示：
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
您可以輕易變更日期值，並將輸出代入 Resolve-Alert 指令程式。
測試警示 您有時候會希望能夠監視 Windows 事件檢視器裡面的特定事件，然後進行測試。這兩行可快速建立事件日誌項目：
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
不過，這預設會寫入 Operations Manager 事件日誌，您平常可能不會到這裡查看特定的事件記錄。所幸，Microsoft 的專案領域工程師 Stefan Stranger 寫了一個指令碼，可在 Windows 事件檢視器內建立事件，而且它還提供較高的彈性讓您寫入特定記錄檔。您可以在 go.microsoft.com/fwlink/?LinkId=120308 找到此指令碼 (Stefan 已將此指令碼封裝成 .cab 檔案。您必須下載該檔案，然後以滑鼠右鍵按一下此檔案來解壓縮他的指令碼)。
對於 Stefan 的指令碼，唯一要特別注意的是，為事件來源輸入的值會決定要將項目寫入哪個記錄檔。若要確保警示確實導向適當的記錄檔，最簡單的方法可能是開啟 Windows 事件檢視器，然後尋找最新項目的來源。
設定所有人 自動設定警示的所有人有時候可能蠻有用的。以下是從命令殼層進行此動作的簡單方法：
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
此程式碼的第一行會取得特定警示物件的識別碼，然後將它傳遞給 $alert 變數。在第二行中，會使用該變數設定所有人，最後會將更新套用到 OpsMgr 資料庫。如果您使用下列命令來檢查警示的所有人，會看到它已變更：
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
若要設定整組警示的所有人，您可以將程式碼簡化如下：
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
還原監視狀態 您很有可能會碰到處於「未監視」狀態的代理程式。發生這種情況時，您可能必須快速地將所有代理程式還原成完整的監視狀態，然後嘗試判斷發生了什麼情況。直接從命令殼層執行 [圖 12] 中的指令碼應該可還原任何受影響代理程式的完整監視狀態。
[圖 12] 重設健全狀況服務儲存區
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
請看一下 [圖 12] 中的程式碼。宣告變數之後，我取得了這個 RMS 上所有代理程式的清單，然後篩選出看似有問題的代理程式。接著，我以非同步的方式呼叫了一項工作，藉此重設篩選清單中所有代理程式上的健全狀況服務儲存區。
建立警示與管理套件的關聯 [圖 13] 說明如何取得所有新警示，以及各自相關聯的管理套件清單。
這段程式碼需要一些技巧，以確定所有管理套件名稱都可以解析。所用的指令程式將視警示是來自規則或是監視器而異 (請注意在 [圖 13] 中，我需要為 Get-Monitor 指令程式實作一個小小的變通辦法。自 OpsMgr SP1 開始，這個指令程式支援新的 ID 參數，可稍微簡化此程式碼)。
[圖 13] 尋找管理套件
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
簡易報告功能 將環境升級時，稽核所有安裝的代理程式版本可能蠻有用的。只要一個簡單的指令碼，就可以列印出一份不錯的報告：
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
[圖 14] 顯示指令碼的輸出。這個指令碼是 systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell 中提供的範例的擴充版。
[圖 14] 顯示部分代理程式版本的輸出 (按一下以放大影像)
排定工作 您可能會想要定期執行 Windows PowerShell 指令碼。假設您使用一部用戶端電腦連接並管理您的 OpsMgr 伺服器，而您將 OpsMgr 系統管理工具安裝在本機。再假設，您想要每天執行代理程式版本報告，而且將輸出儲存到檔案，並使用目前的日期作為檔名。您可以使用 Windows 內建工作排程器從本機電腦執行指令碼。
要這麼做，只要使用設定為 powershell.exe (一般是位於 C:\Windows\System32\WindowsPowerShell\v1.0) 的程式建立新工作就行了。建立工作之後，進行編輯，然後將要執行的命令設定如下：
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
結果我必須對原始的 Windows PowerShell 程式碼多做好幾項變更，如您在 [圖 15] 中所見。我必須新增 OpsMgr PowerShell 嵌入式管理單元，建立對應到 OperationsManagerMonitoring 提供者的 Monitoring 磁碟機，以及建立與 RMS 的連線。我另外還載入了 OpsMgr 自訂 Windows PowerShell 指令碼 (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) 以載入 OpsMgr 專用的函數。
[圖 15] 排定代理程式版本指令碼
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
但不止於此，您可能還會注意到工作每次一執行時，如果有人登入正在執行指令碼的系統，畫面上都會出現一個黑色的主控台視窗。您可以參考由 Sapien 的 Don Jones 與 Jeffery Hicks 所提供的些小秘訣來解決這個問題，網址是 blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell。
基本上，您必須將指令碼包裝在 VBScript 內。要這麼做，您使用如 [圖 16] 中的程式碼，而不是從排定工作呼叫下列命令：
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
[圖 16] 隱藏快顯畫面
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
此工作現在會使用 wscript.exe 程式，而呼叫的內容看起來像這樣：
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
最後，我可以建立自動化報告，而且登入的使用者看不到整個過程。

總結
本文針對 OpsMgr 2007 的自動化新功能提供快速導覽，不過這些只是使用 Windows PowerShell 來處理 OpsMgr 系統管理的皮毛而已。
我想要藉此感謝在文中提及的所有人員，以及 Pete Zerger、MOM MVP 和 SystemCenterForum.org 的創辦人，他們為本文提供重要協助。

Marco Shaw 是加拿大電信公司的 IT 系統分析師。他在 IT 產業工作已有 10 年以上的資歷，並且最近剛榮獲 Windows PowerShell MVP 頭銜。Marco 也是新 PowerShell 社群網站的社群助理董事，網址是 powershellcommunity.org。他的部落格位於 marcoshaw.blogspot.com。


網際網路資訊服務
調整 ASP.NET 應用程式：心得
Richard Campbell
綜覽：
  • 開發人員/IT 共同作業的重要性
  • 了解主體調整策略
  • 在小組間分享知識
  • 在核心知識組上達成共識

目錄
調整的基礎
達成共識
網路小組須知的開發資訊
開發小組須知的網路資訊
回到調整
合作交火戰
身為顧問，我曾合作參與的每個成功調整的 ASP.NET 應用程式，都是開發人員 (建置者) 與網路系統管理員 (實際執行者) 之間共同努力的成果。可惜，在應用程式的生命週期剛開始，
共同作業的必要性不見得很明顯。這也使得我幾乎沒有機會在應用程式生命週期的初期參與 — 總是等到最後有問題的時候。
事實很簡單，沒有任何應用程式第一次調整就成功的 — 要一切剛開始就恰到好處是不可能的。若要成功調整應用程序，您不但必須了解應用程式是怎麼建置而成的，還必須知道它執行的作業環境是如何運作的。換句話說，您需要開發同仁和網路同仁兩方提供資訊。缺少知識交流，就無法成功。

調整的基礎
在深入探討之前，讓我們先談談實際調整 ASP.NET 應用程式的必備條件。一般採納的基本策略有兩種 — 專門化和分散化 — 而大多數大型調整的 ASP.NET 應用程式兩種都適用。另外，書中幫助您進行 ASP.NET 應用程式調整的竅門都不出這兩者。
專門化需要分隔應用程式的元素，以利獨立進行調整。比方說，您可能建置專用的映像伺服器，而不是使用相同伺服器來轉譯 ASP.NET 網頁。映像伺服器的最佳設定與 ASP.NET 伺服器大不相同。另外，將映像要求與應用程式其餘部分相區隔，也開啟了使用協力廠商資源來提供映象服務的可能性。相同的方法也適用於其他資源檔案。
另一方面，分散化則牽涉到把應用程式對稱地散置在多部伺服器間，一般稱為 Web 伺服陣列。ASP.NET 應用程式特別適合分散化，因為每個個別的頁面要求都相當的小，而且特定使用者的互動大多不受其他使用者影響。分散化可謂是「向外延展」原理的化身，當中是由多部中級效能伺服器合作來服務使用者，而不是像「升級延展」策略，是由一部大規模的伺服器包辦。
結合專門化和分散化可提高效率 — 您可以只分散需要額外效能的應用程式元素。例如，如果您已建立專門化映像伺服器，但是提供的映像不足，與其為整個應用程式新增伺服器，您可以直接新增映像伺服器。在您埋頭於提升 ASP.NET 應用程式的效能和延展性時，請務必將這些策略謹記在心。

達成共識
開發人員與網路/IT 人員可能會在每個 ASP.NET 應用程式的生命週期中的某段時期碰面。運氣好的話，他們會在應用程式部署之前碰面，但有時候這只發生在大難臨頭的時候 — 譬如，當應用程式在測試環境下執行順暢，然後發行給使用者，卻慢如老牛拉車 (此時正是像我一樣的顧問現身的時候)。
當開發人員與網路人員會面時，主要的目的是交換資訊。開發人員握有關於應用程式的重要知識，而網路人員則持有作業環境的資訊。每個群組都必須了解另一個群組的資料，而且他們在應用程式生命週期內越早碰面越好。
第一次會面不應該在發生危機時才進行。兩個團隊之間若沒有基本的了解，要找出應用程式的執行為何未達要求將非常的困難。此外，也可能為了自衛而輕易判定問題完全出在另一個小組身上。而且那樣的斷論向來不實 — 要解決任何複雜的問題必定需要雙方的合作。
然而，即使是在相安無事的時刻，這類的會面也可能充滿挑戰。我主持過的那些會議一般是網路同仁坐在會議桌的一邊，開發同仁則坐在另一邊。接著是兩邊彼此乾瞪眼。為了打開話匣子，我簡述了會議的目標，特別強調交換知識。由誰開頭並不重要，我打算從網路小組應知的開發資訊下手。

網路小組須知的開發資訊
每個 ASP.NET 應用程式都有自己的怪癖，但每種案例中都有通用的主要元素。而 web.config 檔案就是其中之一 (見 [圖 1])。Web.config 是開發和網路之間的交叉點。有時候它是由開發人員設定，有時候是由網路同仁設定。無論由誰設定，web.config 的內容都會限制硬體和網路設定，並且直接影響應用程式的運作方式。若要詳細探索 web.config 檔案的每個小細節，很容易就會佔滿整本書的篇幅，這裡的重點是，雙方各組必須研究 web.config 檔案，並對設定所代表的意義，以及各種設定對應用程式還有環境有何衝擊等方面達成共識。
[圖 1] 顯示一些應用程式設定和自訂錯誤設定的基本 web.config (按一下以放大影像)
譬如，web.config 的 <authorization> 區段指出在應用程式中要如何驗證使用者，進而定義相依性。如果應用程式使用 Windows® 驗證，可能得仰賴 Active Directory®。如果是使用表單式驗證，那麼使用者帳戶的資料存放區上就存在相依性。這肯定值得一談。
<customErrors> 區段也值得注意，因為它會影響失敗情況呈現給使用者的方式。這不是複雜的設定，但是值得討論，藉此來了解會碰到什麼錯誤頁面。在合作的早期，可能沒有自訂的錯誤頁面 — 這也值得好好談一下。
web.config 的 <appSettings> 區段可能特別重要。這通常是開發人員藏匿全域值的地方，像是資料庫的連接字串。這不僅是相依性的絕佳來源，也是為容錯移轉、移轉等作規劃的重要一部分。但由於 <appSettings> 區段是完全自訂的，因此內容雜陳，而且可能需要許多解釋來了解當中的內容。遺棄的項目往往是被放在這個區段 — 也就是應用程式中沒有什麼用處的值。
即使開發人員沒有使用 <appSettings>，網路/作業同仁可能會希望他們使用 — 將所有資料庫連接字串都放在該處，是建立簡單容錯移轉策略的有效方法。如果資料庫伺服器故障了，便可插入替代字串以指向不同的資料庫伺服器。在開發週期早期抓住此良機，可提高應用程式的可靠性和易管理性。
最後，從調整的觀點來看，您在 web.config 中應該注意的一個絕對重要的值，就是 <sessionState> 標記，這個標記可決定存放應用程式的工作階段資料的地方。根據預設，工作階段資料是存放在「InProc」，或是 ASP.NET 應用程式的處理序空間內。如果工作階段資料是設定用於同處理序，表示所有負載平衡都必須「連在一起」 — 必須始終將指定使用者送回工作階段所在的相同伺服器。這在開發人員和網路同仁之間可說是很重大的會談，因為它會對您要如何調整以及如何容錯移轉產生直接的影響。對此及早進行討論可在試圖偵錯應用程式時，省下不少的麻煩。
會談一談到工作階段狀態，話題就很容易轉到應用程式的一般負載平衡需求。有些環境具有專用的負載平衡硬體，而且有特定的功能 — 但要是應用程式無法處理這些功能，也無用武之地。我就碰過硬體負載平衡被用在具有同處理序工作階段資料的 ASP.NET 應用程式的情況。產生的後果是工作階段偶爾會無緣無故的消失。看起來像是應用程式的錯誤，但不然 — 這其實是設定有誤的關係。
網路同仁必須清楚地從開發小組確知到底什麼樣的負載平衡配置才適合應用程式。這基本上是雙向溝通，除了需要知道有什麼負載平衡配置可用外，還得了解應用程式可以容錯的程度。在應用程式的生命週期早期進行此溝通，有相當的優勢，因為這樣一來，您便可以事先規劃改採跨處理序、非相似性的負載平衡配置。
等到 ASP.NET 應用程式準備好進行部署 (或是已處於初始的部署階段)，開發人員將可對應用程式速度快和速度慢的區域一清二楚。最重要的是，他們將能判斷系統內的瓶頸或潛在的危機點。如果網路/作業小組知道這些瓶頸的話，便能事先針對問題作好準備，甚至防範未然。
例如，我就曾處理過一個應用程式每晚在應用程式停頓的時候有個龐大的資料負載處理序。開發人員於是建置了資料負載機制，進行測試，並了解它的運作方式。他們知道這對資料庫來說負擔很沉重，但卻是有效解決問題的好方法。
但是他們從未告訴網路小組這個處理序的存在，也沒提他們把它排在凌晨 1 點執行 — 剛好是資料庫備份執行的時間。資料庫繼續保持線上狀態，但它在備份時的執行速度慢很多，因為送到資料庫的所有交易都扣留在交易記錄中。
衝突一直等到同時執行的資料負載和備份導致資料庫交易記錄量用盡了磁碟空間才被發現。將資料負載移到凌晨 3 點再開始，便徹底解決了問題 — 但是在危機發生後的幾天才解決。
及早針對應用程式中這類工作負載項目進行討論，可為將來省下不少麻煩。

開發小組須知的網路資訊
當會談進行到網路同仁向開發同仁解釋他們的國度時，我最喜歡從網路圖開始談起。開發人員眼裡的網路往往像 [圖 2] 一樣 — 也就是沒有網路，只有網頁伺服器、瀏覽器和網際網路。
[圖 2] 開發人員眼中簡單的網路 (按一下以放大影像)
不用說，真實的世界要複雜許多。雖然已經過簡化，但 [圖 3] 還是比較接近事實。看一下 [圖 3]，您馬上會滿腹疑問，例如「虛擬私人網路 (VPN) 使用者要如何使用應用程式？」或是「內部使用者與公用使用者之間進行驗證有何差別？」等。
[圖 3] 開發人員必須了解的真正網路 (按一下以放大影像)
光提供網路圖很顯然是不夠的。詳細解釋網路也很重要，因為光看圖表是不可能知道到底有哪些元素會影響應用程式。您必須一一解說公用使用者、VPN 使用者和內部使用者的實際連線程序。而討論現存的各種防火牆規則，尤其是在更複雜的 DMZ 式網路架構中，將自然而然地帶出應用程式的潛在問題。
在應用程式部署之前，甚或是在開發程序開始之前進行所有這些討論顯然是有利的 — 但無論如何，討論終究需要進行，而且關鍵在於讓會議桌邊的每個人都了解整個網路圖。
網路也是容錯移轉和備援模型的競技場，但若沒有一些軟體支援，或對行為有最基本的認識，這些模型很難如預期運作。因此，詳細討論各種不同的失敗案例的情況是不可少的。如果資料庫上設有叢集，這將影響與存取資料庫相關的程式碼。例如，查詢可以在伺服器轉換後重試嗎？如果有可用的備援網站，資料要怎麼複寫到該網站呢？網站之間要如何進行轉換呢？
再次強調，及早進行會談是有幫助，但遲做總比不做好 — 所有參與應用程式的相關同仁都必須對這些事情是怎麼運作的有所了解。沒有什麼比備有容錯移轉方案，卻在需要的時候不能用更令人挫折的了。
最後，還有另外一項重要的網路資源需要分享 — 實際執行記錄。我總是建議將實際執行記錄提供給開發小組。網路同仁對於這項要求的反應通常是「只要開口，我就會寄給你」。我覺得這樣是不夠的 — 讓開發人員能夠自行擷取記錄檔 (通常是從備份網站) 會更有效。
在發生危機時，實際執行記錄是不可少的。要了解實際上發生什麼事，實際執行記錄往往是有經驗的真實資料的最佳 (而且是唯一) 來源。但是它們在更普通的情況下也一樣重要。當開發人員可例行存取實際執行記錄時，他們便能逐一檢查來觀察新功能的行為。而這是找出您的功能未如預期運作，並在它造成危機之前加以修正的絕佳辦法。如果每個人都可以存取記錄檔，您就能更快對問題作出回應，修正的速度也會更快。

回到調整
網路與開發小組之間的會面重點，在於了解調整 ASP.NET 應用程式相關的完整問題範圍。應用程式操作的實際環境會直接影響應用程式執行的程式碼的運作方式。所有與調整相關的策略都將左右它在環境內的行為。採用專門化策略，例如區隔應用程式的 SSL 相關部分，可能需要變更網路環境，也可能對伺服器本身進行變更。
即使很明顯是以程式碼為主的變更，像是使用快取，也會對環境產生影響。這是因為當您將資料快取新增到 ASP.NET 應用程式時，等於是減少資料庫呼叫的數目來交換更高的記憶體使用量。最後，您可能增加了您所需的 ASP.NET 伺服器數量，或增加了伺服器上工作者執行緒的再利用數目，因而在網路監視端引發了事件。
調整 ASP.NET 應用程式確實會影響開發與網路雙方的人員 — 因此邀請兩批人馬投入決策過程是值得的。共同作業往往會產生小組在獨立作業時察覺不到的全新解決方案。比方說，網路同仁可能知道公司內有現成的硬體方案可幫助開發人員達成效能和調整需求。深入談論應用程式和環境的細節將可揭開這些機會。

合作交火戰
調整 ASP.NET 應用程式的資源

  • 開發高效能 ASP.NET 應用程式 (英文)
  • How To：調整 .NET 應用程式 (英文)
  • How To：微調和調整以 .NET Framework 為基礎建置而成的應用程式效能 (英文)
  • 實作可擴充的架構 (英文)
  • 充分發揮 IIS 效能 (英文)
  • ASP.NET 應用程式的調整策略 (英文)
調整時發生危機不見得就是壞事 — 事實上，這通常是件好事，畢竟這也是因為有太多使用者想要執行您的應用程式才發生的，無疑證明了應用程式的價值！不過，現在您必須解決危機。
有時候調整危機是因其他事件引起的 — 或許是貴公司正在舉辦宣傳活動，或是有部落格文章報導您，或是社群網站一次將人數龐大的網友指向您的網站。突然間，您身陷重圍，努力讓應用程式順利執行。跟您猜得一樣，最好是在這種情況真正發生前先演練一下。而示範共同作業如何協助組織在這類的危機中存活下來，是讓開發人員和網路同仁會議落幕的最佳方式。
管理危機的首要問題是：「我們要怎麼偵測出網站已經超載？」答案往往是：「我們接到 CTO 的電話。」如果網站出問題的第一個症狀是外部的人來電告知，那麼您麻煩可大了。有些適當的計量功能應該可以在電話響起前告知您發生了問題。它當然無法制止電話響起，不過至少可以讓您預先準備要怎麼回答。回答 CTO「喔，真的嗎？」對您的前途並沒有什麼幫助。
下一個問題 — 電話應該先由誰接聽？由誰對事件作出回應？網路人員通常會先接到警告，但該人員可能缺乏相關經驗，因此應該要有清楚的升級計畫。接下來該收到通知的是誰？挑戰在於進行初期迅速的診斷，以找出所面臨的是哪種問題。網路中斷是一回事，調整問題又另當別論。關於調整問題，最好邀請開發小組儘早參與。
參與交火戰的每個人都需要有充足的資訊，因此有效的存取權限是關鍵。目標是要盡可能多傳播資訊，以利有效的診斷，而且這最終應該指明解決方案的範圍。
如果唯一的解決方法是編寫程式碼，事件往往在程式碼編寫好前就已結束。為了建立未來的開發優先順序，小心觀察事件是理所當然的，但是試著寫一長串程式碼，並且不仔細測試就在生產環境下執行，可謂不智之舉。交火戰的首則 — 不要火上加油。
碰到調整問題，有時候耐心等候才是解決之道。但這也是您要作的決策。
同時，針對這些偶發事件作規劃，意謂著可迅速採取不同的因應措施。結合網路和開發資源來因應調整問題，通常可及時加以解決，成效之快或許還可讓宣傳活動的成效更加彰顯。
總括來說，從網路一方獲得的心得是，高度調整、有效執行的 ASP.NET 應用程式，代表建置應用程式的同仁與部署和操作它的人之間共同作業有成。
共同作業是不可避免的，因此各組之間最好及早會面來分享資訊。會面的目的是要對應用程式的元素、作用、運作方式、仰賴的基礎、負載下的行為模式，以及應用程式如何應付不時產生的問題有所了解和達成共識。
這類的共同作業除了成效驚人外，還能使公司更加靈活，不僅可以更迅速地回應問題，還能針對應用程式的需要溝通明確的目標，以便在未來順利執行。

Richard Campbell 身兼 Microsoft 地區主管與 ASP.NET 的 MVP，他同時也是《.NET Rocks》的主持人之一，這是以 .NET 開發人員為主的網際網路廣播脫口秀 (請前往 dotnetrocks.com)。他花了好幾年的時間與公司合作磋商 ASP.NET 的效能和調整作業，他也是 Strangeloop Networks 的創辦人之一。


編輯的話 Tech•Ed 的現場報導
Joshua Hoffman

我在撰寫每月份《編輯的話》時，總會碰上一個難題。要想出話題並不難，反正隨時隨地都有很多有趣的話題可談。難的是《編輯的話》必須在送到讀者手上的前六週寫好 (部分原因是為了讓雜誌有時間印出，不過最主要的原因還是為了讓審稿員來得及更正我犯的錯誤啦)。它跟部落格不同，部落格可以完全反映當下的事件，但是我們就很難反映「新聞」了，因為等到您讀這篇文章的時候，它已經不是新聞了。
但是此時此刻的我，正身處「風和日麗」的奧蘭多的 Tech•Ed 2008 現場，見證全球最重要的事件發生 (也許您看到這篇報導的時候已經稍微過期了…不過…這也是沒辦法的事)。
對我們來說，Tech•Ed 絕對是一場令人興奮的盛事，原因有很多。其中一個原因是，這是當年度唯一能夠親眼見到這麼多讀者 (甚至是作者) 同時出現的機會！雖然我們有幸全年都能接獲許多電話、電子郵件和立即訊息，但是再怎麼樣也比不上親耳聽到這麼多人共同激發出源源不絕的點子和妙趣橫生的對話。
另外，Tech•Ed is 也是一個放眼來年的絕佳機會。現場會有高級主管蒞臨發表展望策略，內容相當精采，包括虛擬化的新方向、下一代的網路、系統管理的革命性概念等等，不勝枚舉。
不過，此行我還有更重要的事情要辦。Mark Russinovich 是 Microsoft 的技術人員，也是一位特約編輯，他將在會中主講重新定義的安全性界限。另一位特約編輯 Steve Riley 則主講整體網路界限的消失 — 這可是超級有趣創新的概念哦！另外，Mark Minasi、Romi Mahajan、Dharmesh Godha 還有小弟我也將負責帶動 IT 消費化的小組討論。
如果您有意為《TechNet Magazine》撰寫文章，我也會向各位報告入門途徑。過去幾年來，我一直對提供這份簡報樂此不疲，而這份簡報也確實鼓舞了不少新手作者。我的演講內容投影片會在送達讀者手上之前，提早公佈在我們的部落格上供大家參閱 (網址是 blogs.technet.com/tnmag)，歡迎上網一覽。誰曉得呢？或許您會以作者身分出席明年的 Tech•Ed 也說不定呢！
對了，別忘了 Tech•Ed 派對，我們對這也是滿心期待。
—Joshua Hoffman

感謝下列 Microsoft 技術專家： Sunil Agarwal、Eric Charran、Trina Gorman、Sanjeev Nair、Isaac Roybal、Jez Sadler、Roger Sprague、Stefan Stranger、Kevin Sullivan、Jim Truher、Alan von Weltin、Michael Walsh 以及 Buck Woody。


讀者來信 讀者有話直說

SharePoint 內容類型
我想找一些資料來協助我深入了解如何使用 Microsoft® SharePoint® 中的內容類型。我可以在何處取得這些資訊？
—E.A.

如需這些資訊，Microsoft SharePoint 產品及技術小組部落格是不錯的參考來源 (網址是 blogs.msdn.com/sharepoint)，Pav Cherny 撰寫了一篇文章，說明如何使用自訂內容類型標準化資料管理，您可在以下網站找到這篇文章：technet.microsoft.com/magazine/cc194408。還有一份白皮書是關於管理企業中繼資料 (網址是 technet.microsoft.com/library/cc262729)，可能也蠻有幫助的。
另一個您可能感興趣的參考資源是 Andrew May 的部落格，網址是 blogs.msdn.com/andrew_may。Andrew 是 Microsoft 的程式設計作家，專門撰寫 Windows® SharePoint Services 3.0 和 Microsoft Office SharePoint Server 2007 中的企業內容管理功能方面的開發人員文件。他在部落格中有討論到內容類型，並提供技術插圖的海報，這些有關內容類型的海報可說明在 SharePoint 環境中企業內容管理的各種複雜層面。

進一步加強安全性
我很喜歡《世紀大爭論：透過隱匿來實現安全》這篇文章 (2008 年 6 月，technet.microsoft.com/magazine/cc510319)。不過，文中的重點都只放在變更系統管理員名稱，讓我稍感失望。我非常贊同 Roger Grimes 和 Aaron Margosis 對於系統管理員名稱的論點，因為我認為聊勝於無，而且它也不致造成管理的麻煩。但是更耐人尋味的挑戰還有很多 — 文中提到系統管理員共用但並未詳加探討，還有當系統管理員共用被封鎖時，的確會碰到一些嚴重的管理問題。
我也很希望見到這組人馬辯論嘗試「縮小攻擊面」的利弊。縮小攻擊面可說是透過隱匿來實現安全的分身，因為大多數東西都是為了阻擋任何會廣播位置或身分識別的東西而拿掉的。比方說，我有許多客戶就為了透過隱匿來實現安全而拿掉 IPv6。移除服務往往就跟中世紀醫生動手術沒兩樣 — 閉上眼睛，手伸進去，然後祈禱病人沒死。
—Shelly B.

您說到文章內容侷限在變更系統管理員名稱，我們完全同意。起初的草稿中包含其他幾個範例，但是我們不得不刪減一些內容，免得文章長達 20 頁！因此我們只挑選了一個主要範例，而系統管理員帳戶問題似乎是最多人提起的問題。不過別擔心 — 我們已經開始向作者下通牒，要他們盡快推出有關此一主題的文章。

不夠隱匿
《世紀大爭論：透過隱匿來實現安全》是一篇很棒的文章。從中我思索出兩件事。首先，我相信只要隱匿的投資報酬率 (ROI) 夠高，那麼隱匿就是很好的作法。其次，我發現大部分的 IT 安全性總有個隱匿元件。
以密碼為例，我們設定越來越隱匿難解的密碼。在早期大部分的 PC 上並不一定要設密碼。之後，隨著電腦的連接變得更加緊密，使用簡單的密碼也已綽綽有餘。而跟著連接性提高，使用至少八個字元的密碼也變得很重要。當這麼做也不夠安全時，我們必須採用混合字元，然後是複雜密碼等諸如此類。我想我們始終會覺得舊的隱匿保護永遠都不夠隱匿。
—Tom B.

Tom，謝謝您提出這麼精闢的見解。這項趨勢的走向值得好好觀察，尤其是多重要素驗證 (例如，智慧卡加上密碼) 等安全性概念已經越來越普及。

《TechNet Magazine》海報
我想為公司內的開發人員買一些某幾期《TechNet Magazine》中隨附的 Microsoft 海報。可以告訴我如何購買嗎？
—Helen G.

這三張海報分別是：Microsoft Exchange Server 2007 元件架構、Windows Server® 2008 Active Directory® 功能元件及 Windows Server 2008 功能元件。您可以電洽 800-444-4881 (美國和加拿大) 或 785-838-7500 (其他所有國家) 來購買這些海報。


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

監視您的伺服器
PA Server Monitor Pro
poweradmin.com/servermonitor
基礎架構中的各個部分您都必須監控。在使用者發現之前就先察覺異常情況，對於損害控制與溝通的影響至關重大 (再說，被老闆盯上可不好玩)。有一個工具能協助您密切注意伺服器基礎架構，就是 Power Admin LLC 推出的 PA Server Monitor Professional Edition。
安裝及使用 PA Server Monitor 的方法很簡單，而且這個應用程式還內建了智慧型設定程序 (Smart Configuration Process)，它會探索 LAN 上的機器，並自動為這些機器設定個別的監視器。若您不想執行探索程序，可以匯入要設定監視檢查的機器清單。設定好機器之後，您可以經由 GUI 匯出該設定，以便在其他機器上重複使用這個設定範本，或是在需要重新安裝時當作備份。
PA Server Monitor 提供 18 種不同的監視器，供您指派給各部伺服器。這些監視器包括標準檢查，例如監視磁碟空間、事件日誌錯誤、遠端指令碼執行、檔案和目錄變更、CPU 及記憶體使用率、網際網路控制訊息通訊協定 (ping) 回應，以及 Windows® 服務狀態。
其他還有一些特別有用的監視器，包括 TCP 連接埠監控，它可檢查基本的連接埠狀態，還能傳送命令文字，並根據預先決定的值來檢查回應。記錄檔監控可檢查在記錄檔中您定義為規則運算式或簡單文字的一段文字。目錄配額監視器可協助您確保使用者未超過限額，並在使用者超過限額時以電子郵件通知他們。您可以針對要執行的任何自訂工作監視指令碼執行。最後，您可以使用檔案存留時間監控來觀察郵件佇列，以確保沒有囤積郵件。
為伺服器定義監視器之後，您需要定義在達到監視器的閾值時，要採取什麼行動。PA Server Monitor 提供 15 種內建動作，包括電子郵件、事件日誌、訊息方塊、記錄檔、重新啟動服務、Simple Network Paging Protocol (SNPP)，以及用於自訂動作的自訂指令碼。定義動作時，您也可定義動作升級鏈，如此一來，當監視器的錯誤狀態超出指定的時間長度時，便會執行其他動作。比方說，首先您可以設定動作來自動重新啟動網站。接著，如果過了五分鐘後，檢查還是失敗，便會傳送電子郵件訊息到您的掌上型裝置，通知您網站的狀態。
經過一段時間，您會想要檢視所設定的監視器的統計資料。PA Server Monitor 具有內建的報告功能，可輔助您為有需要的人提供這類資訊。內建報表包含顯示各種狀態和特定伺服器狀態的伺服器摘要、針對監視的機器分別提供短評的一般摘要，還有圖形式狀態圖可顯示分散各地的安裝的狀態指標。產生的報表會採用 HTML 格式，以便利用網頁瀏覽器來存取，讓您的作業中心更出色。此外，您也可以產生內含圖形和圖表的特定報表，或匯出成 CSV 檔案以供日後使用。您還可以排程報表，讓應用程式定期將伺服器的最新狀態直接以電子郵件的方式自動寄送給您。
PA Server Monitor 沒有代理程式。這樣有一個好處：只要應用程式的服務內容在執行時具備足夠的授權連線到網路上的機器，以便透過 Windows Management Instrumentation (WMI) 與其他遠端管理服務 (例如遠端程序呼叫 (RPC)) 來執行，您就能夠迅速地啟動並部署這項工具。但是它的其中一項缺點就是您必須提高帳戶層級，才能連線到遠端機器。當然，也有一些不需要提高權限的伺服器通訊監視器類型，包括 HTTP 與 SMTP。
另一項可能的缺點是，在複雜且分散的基礎架構和網路拓撲上連線到機器也許並不容易，而且得依賴網域及網路信任。這麼說起來，您的環境是否適用這種無代理程式的方法，需視您的基礎結構配置，以及您對伺服器監控解決方案的確實計劃而定。
價格： 20 部使用中監視器為 $99 美元 (直接售價)，或 100 部使用中監視器為 $349 美元 (直接售價)。
使用 PA Server Monitor Professional Edition 監視您的伺服器(按一下以放大影像)

清除重複的檔案
dupeGuru
hardcoded.net/dupeguru
如果您與使用者一起工作或管理共用的使用者磁碟空間，一定會發現使用者空間不時就變得雜亂不堪。原因往往是某位使用者將相同檔案存放在多處，甚至是多位使用者將相同檔案存放在多個位置上也會造成這種現象。為了整合及清除這樣的使用者空間，重複檔案搜尋工具是不可或缺的。Hardcoded Software 的 dupeGuru 就是不錯的解決方案。
此工具會掃描您的目標資料夾或磁碟機上的重複檔案，搜尋檔名和內容。但是 dupeGuru 不僅進行基本的字串比較，更會使用模糊比對演算法來尋找可能遺漏的重複檔案。您的重複檔案一旦被標記，就可以選擇將這些檔案傳送到資源回收筒、永久刪除它們、將它們移到其他資料夾，或是使用預設的應用程式來開啟這些檔案，以便進行最後的確認。若要稍後檢視結果，您還可以將結果匯出到 XHTML。
在喜好設定中，您可以決定檔名和內容篩選器在掃描檔案時的嚴格程度：這麼做可以增加所找到的重複檔案數量，但也可能提高誤判的機率。dupeGuru 也能夠標示檔名中包含特定字詞的所有重複檔案。如果想要尋找使用者不小心建立的所有檔案「副本」，以及四散在目錄中名為「新資料夾」的空資料夾，這項功能就非常實用。
dupeGuru 的版本適用於 Windows 2000 與更新版本以及 Mac OS X。若您正設法減少音樂或照片中的重複檔案，不妨分別參考一下名為 dupeGuru ME 和 dupeGuru PE 的訂製版本。
價格： $19.95 美元 (直接售價)。
使用 dupeGuru 清除重複檔案 (按一下以放大影像)

掌控您的環境
pt360 Tool Suite PRO
packettrap.com
若能有一個單一介面讓您檢視和管理各式各樣的網路監控及管理工具，肯定很有幫助。除了省下許多時間 (和桌上型電腦資產)，整合套件還可簡化在不同監控工具之間共用資料的作業，並讓您一次查詢多個監視器，藉此提供更周詳的基礎結構狀態檢視。
如果您覺得中聽，就試試看 PacketTrap Networks 推出的 pt360 Tool Suite PRO。此應用程式為 PacketTrap Networks 工具提供整合式 UI，另外還具備集中化的統一報表功能。您可以建立工具檢視並將之排列成自訂的儀表板，以便立即存取最常用的工具和基礎結構狀態資訊。pt360 儀表板也有全螢幕模式顯示的功能。這點在作業中心很管用，任何小組成員只要望螢幕一眼，就可以監看各種網路和伺服器資源的狀態。此應用程式支援多個儀表板，因此您可以視需求在環境中建立各種檢視。
若要設定儀表板，只需從下拉式清單中選取一些小工具，然後再分別按這些小工具進行設定即可。這些小工具分成五大類 — 應用程式 (Application)、網路 (Networking)、裝置 (Devices)、可用性 (Availability) 及其他 (Other) — 它們需依賴 Simple Network Management Protocol (SNMP) 和 WMI 來監視您的伺服器、應用程式與網路裝置。應用程式 (Application) 小工具可關聯到 Active Directory®、Microsoft® Exchange Server 和 SQL Server®，另外也提供一個瀏覽器工具。網路 (Networking) 小工具可讓您詳細檢閱裝置介面，並提供平均封包遺失、最高延遲和每一用戶端的介面使用情況的前十大檢視。裝置 (Device) 小工具提供有關 CPU 和記憶體使用量、可用磁碟空間、磁碟區列表、網路介面使用率及其他的效能指標。這些功能很棒，可讓您經由可設定的 WMI 查詢來即時掌握伺服器的表現。可用性 (Availability) 監視器以圖表、量表、文字或清單格式來顯示機器的執行時間。最後的其他 (Other) 小工具具有一個大型的數位時鐘。
除了儀表板之外，pt360 工具套件也為您提供網路工具。譬如說，您可以使用 Cisco Configurator。它可讓您從 Cisco 設備保存、修改、上載、下載和比較設定檔。您還有三個不同的 ping 工具 — 一個提供可排序的表格檢視，另一個顯示圖形檢視，第三個則讓您針對 IP 位址群組進行快速的偵測掃描 (ping-scan) 動作。其他可供使用的掃描工具類型包括 MAC 位址掃描器、通訊埠掃描工具、SNMP 掃描器及 WMI 掃描工具。
此工具套件也可以當作 Syslog 伺服器，與網路上支援 Syslog 的任何裝置傳送、接收、記錄和顯示 Syslog 訊息。顯示也支援篩選，因此您可以很快地區隔所需的訊息，進而加速移難排解程序。
當作簡單檔案傳輸通訊協定 (TFTP) 伺服器的套件可讓您在網路上的裝置間來回快速移動檔案。其他工具包括追蹤路由、Whois 和遠端喚醒 (Wake-On-LAN) 功能。當然，由於此集中式管理解決方案會透過 WMI 和 SNMP 與您的主機連線，套件如何存放連線所需的認證就變得很重要。還好，套件使用經過 256 位元先進加密標準 (AES) 加密的認證存放區，您可在此新增、更新和刪除監控基礎結構所需的資訊。
價格： 單一授權為 $999 美元 (直接售價)。
[圖 36] 使用 pt360 Tool Suite PRO 監視您的系統 (按一下以放大影像)

管理磁碟使用狀況
TreeSize Professional
jam-software.com/treesize/index.shtml
「什麼東西佔用了伺服器上的所有磁碟空間！」聽起來很耳熟嗎？您的監控應用程式剛寄給您一封電子郵件，通知您已達到磁碟空間不足的閾值。您可能會問，該如何清理這部機器。還有要如何快速判斷什麼項目最適合永久刪除 (Shift-Delete) (Shift-Delete 是跳過資源回收筒來刪除的快速捷徑)。有一項工具可協助您維持主機監視器的綠燈狀態，就是 JAM Software 的 TreeSize Professional。
此應用程式在 Windows 2000 和更新版本上執行，且適用於 32 與 64 位元的 Windows 版本，可提供深度檢視來了解哪些檔案正在佔用磁碟機上的空間。您只需要選取要調查的磁碟機，應用程式就會自動掃描資料夾結構。這個動作一旦完成後，您可以存取七種不同的磁碟機檢視。第一個是「圖表 (Chart)」檢視，這裡會提供三種圖表來進行剖析：圓形圖、橫條圖和相對大小方塊圖。這些圖表分別都讓您探索不同的資料夾，以便快速識別耗用空間的罪魁禍首。您也可以自訂圖表上的色彩及樣式。
下一個是「詳細資料 (Detail)」檢視，提供可排序的檔案表格檢視，在此檢視中，您可以選擇顯示多種不同的欄位。在使用者中最值得注意的選項包括 Microsoft Office 檔案的作者、資料夾中的平均檔案大小、被此檔案或資料夾佔用的上層目錄百分比，以及永久連結。
「副檔名 (Extensions)」檢視指出哪些檔案類型在您展開的資料夾中，佔用各個目錄的最多空間。「使用者 (Users)」檢視顯示使用者或系統帳戶的檔案目前佔用多少空間的複合檢視，這特別有助您找出問題使用者。「檔案存留時間 (File Ages)」檢視提供關於過去日、月、年 — 依據您偏好的時間範圍 — 所修改、建立或存取的檔案百分比的圖形檢視，好讓您安全地識別可以保存或刪除的舊檔案。接下來是「前百大 (Top 100)」檢視，可識別磁碟機上前一百個最大的檔案。最後還有一個「歷程記錄 (History)」檢視，可提供一段期間的磁碟機使用模式。
這七種檢視各自都可以列印、儲存或複製到剪貼簿以供日後使用。再者，TreeSize 可讓您利用檔案搜尋功能迅速隔離最大的檔案、最舊的檔案、暫存檔案、網際網路快取檔案及重複的檔案，因此能加速經由工具列進行的常見清除維護工作。TreeSize Professional 也能夠透過 UNC 共用來掃描網路，但由於牽扯到網路負荷，因此會明顯折損效能。
此外，應用程式也支援命令列模式，因此很適合用來排程和執行夜間工作。您也可以建立「排定的工作」掃描，將它設為掃描路徑，並根據標準排程產生一組報表。這項功能很有用，特別是對於每晚監控共用使用者空間，以及注意磁碟空間使用狀況時。
若您還在疑惑數以 TB 計的整個使用者空間怎麼會被佔滿，也許 TreeSize 能助您一臂之力，幫您了解磁碟空間的使用情形，並開始更有效地加以管理。
價格： 單一授權為 $49.95 美元 (直接售價)。
使用 TreeSize Professional 管理磁碟使用狀況 (按一下以放大影像)

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


SQL 問答集 磁碟分割、一致性檢查及其他
Paul S. Randal

問：我不小心把實際執行資料庫附加到 SQL Server® 2005 伺服器，現在要把它附加到正確的伺服器，也就是執行 SQL Server 2000 的伺服器。我試過單純把資料庫卸離，然後再附加到 SQL Server 2000 伺服器，也試過透過備份和還原來進行相同的動作，但是兩種方法都沒有用。為什麼在我的 SQL Server 2000 伺服器就行不通呢？我就這麼一個資料庫。
答：在這裡要注意的第一件事，是了解備份的重要性。資料庫管理員 (DBA) 常常認為需要備份，是為了從損毀或其他破壞性的嚴重損壞復原。但是您碰到的是比較不明顯的嚴重損壞 — 升級時出錯 (雖然在這個案例中是意外升級)。不過，重點是無論如何一定都要保留一份最近的完整資料庫備份，以防萬一。
無論是刻意升級還是意外升級都屬於單向作業，要反轉結果比登天還難。當您在 SQL Server 各版本間進行升級時，資料庫上會進行一連串的升級步驟。每個步驟通常都牽涉到對資料庫的一些實體變更，而且每個步驟都會增加資料庫的版本號碼。
例如，當您將資料庫從 SQL Server 2000 升級到 SQL Server 2005 時，其中一項重大變更，就是對資料庫系統目錄 (常常稱為系統資料表或資料庫中繼資料，內存各種關於資料表、索引、資料行、配置的中繼資料，以及其他與關聯性和資料實際結構相關的詳細資料) 結構所做的變更。
隨著各個升級步驟的執行，資料庫版本號碼也會跟著增加。例如，SQL Server 7.0 資料庫的版本號碼是 515，SQL Server 2000 資料庫的版本號碼是 539，而 SQL Server 2005 資料庫版本號碼則是 611 (如果有啟用 Vardecimal 功能的話，則為 612)。這樣可以讓 SQL Server 知道在資料庫上所執行的最後一個升級步驟是什麼。
SQL Server 發行版無法讀取升級到較新 SQL Server 版本的資料庫 (譬如，SQL Server 2000 無法讀取升級至 SQL Server 2005 的資料庫)。這是因為較舊的版本並沒有所需的程式碼來解譯已升級的結構和資料庫配置。而這也正是您已升級至 SQL Server 2005 的資料庫，所碰到的問題癥結所在：不能附加回 SQL Server 2000。
由於沒有完整的資料庫備份，因此除了從升級的資料庫匯出所有資料，然後手動將它傳送到新的 SQL Server 2000 資料庫之外，別無他法。只要您還沒有使用 SQL Server 2005 中的任何新功能，就可以編寫資料庫結構，在 SQL Server 2000 上建立資料庫，然後匯出/匯入資料。
若要在 SQL Server 2005 中編寫資料庫，可以使用 SQL Server Management Studio (在資料庫上按右鍵，接著依序選取 [工作] 和 [產生指令碼] 選項) 中的物件總管。精靈很簡單明瞭，它會產生一個指令碼來建立所有物件、索引、條件約束、觸發程序等等。
問：我們最近剛剛將結構描述重新設計，以採用主資料表上的資料表磁碟分割 — 聽說這麼做可以提升效能。資料庫是存放在單一的 120GB 磁碟機上，而資料表是內含在單一檔案群組中。除了每週加入新的磁碟分割之外，並沒有進行任何滑動視窗 (sliding-window) 作業，而且所有資料都必須能夠在線上存取。我們大半的查詢都是在處理一週以內的資料，只有少數還在處理去年的資料。這在單一檔案群組中似乎比較容易進行，我這樣說對嗎？還是事實不止於此？
答：使用單一檔案群組看起來似乎比較簡單，但是這麼一來，使用磁碟分割可能就看不到什麼效益了。磁碟分割的主要用途是為了達成更有效率的資料庫維護，以及在發生嚴重損壞的情況下增加資料的可用性，另外您還可以建立結構描述來促進效能。
磁碟分割的典型範例是用於銷售資料表，內含 12 個磁碟分割，各自代表去年銷售資料的每一個月。每到月底，最舊的磁碟分割會被換掉 (並且封存起來或刪除掉)，然後換上新的磁碟分割，這就是您所提到的滑動視窗案例。當月的磁碟分割設為可讀寫，而較舊的月份則設為唯讀。每個磁碟分割都是存放在個別的檔案群組中。這種結構描述可達成磁碟分割的功效，但並不是最理想的做法。
內人 Kimberly 想出一個妙計，可以更有效的編列上述結構描述索引。那就是把銷售資料表分割成兩個資料表 — 一個用來存放單一可讀寫磁碟分割，另一個用來存放 11 個唯讀的磁碟分割，另外可分割檢視兩個資料表。
這可讓可讀寫資料表擁有較少量的索引，而讓唯讀資料表擁有較多量的索引來支援報告查詢。如此一來，便可讓可讀寫資料上的資料操作語言 (DML) 作業更具效率，因為它們不用維護那麼多非叢集索引。
此外，可讀寫資料上的查詢也不必處理唯讀資料。查詢計畫中的磁碟分割銷除在 SQL Server 2005 中還不甚完美，尤其是在有複雜述詞的情況下更是，但在 SQL Server 2008 中已經過改良。相關詳細資訊，請參閱 Kimberly 的部落格文章，網址是 sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93。
為了闡明我的意思，我將說明一些透過在多個檔案群組上磁碟分割所提供的功能。
部分資料庫可用性 這項功能可讓資料庫保持在線上狀態，而且可被存取，只要主要檔案群組在嚴重損壞修復的情況下還在線上就行了。如果您只有一個檔案群組，那麼整個資料庫就會在還原時停擺。若將資料分散到多個檔案群組，還原期間就只有受損的檔案群組會離線，而應用程式還是可以繼續運作。
分次還原 此種配置與部分資料庫可用性雷同。如果只有一個檔案群組時，還原的單位不是單頁，就是整個資料庫。如果有多個檔案群組時，就可以只還原一個檔案群組 — 這樣就有部分資料庫可以使用。
分割式資料庫維護 針對上述的任何一種磁碟分割案例，您可以依磁碟分割執行索引片段移除作業，即便所有磁碟分割都位在同一個檔案群組也可行。但是對於單一檔案群組，就無法進行依檔案群組的一致性檢查，而這可大幅減少資料庫一致性檢查 (DBCC) 需要處理的資料量，轉而降低所用的 CPU 和 I/O 資源量。
簡單的說，雖然您可以在相同的檔案群組內擁有多個磁碟分割，但是在磁碟分割與檔案群組之間擁有一對一對應關係也有很多優點。
問：我們有部高階資料庫伺服器最近發生了嚇人的情況 — 其中有張記憶體電路板因為運作不良而導致損毀情況。這種情況是應用程式開始出現隨機資料時發現的。我們在執行 DBCC CHECKDB 之後，發現了各種損毀情況。糟糕的是，備份也發生同樣的情形，因此我們不得不手動清除受損的資料。
長話短說 — 我們替換了受損的硬體，然後啟動頁總合檢查碼。本來想要定期執行一致性檢查，但是維護窗口的時間不夠長，而且要檢查 2.4TB 的資料庫也會花上好一段時間。該怎麼辦呢？
答：如何在 VLDB (非常大型的資料庫) 上執行一致性檢查和其他維護作業的問題，已變得越來越普遍。許多 DBA 在發現 DBCC CHECKDB 執行的時間比維護窗口允許的時間還長時，都乾脆舉白旗投降 (在有些情況下，資料庫是 24 小時全天候使用，因此沒有有效的時間可以讓出 CPU 和 I/O 供 DBCC CHECKDB 佔用一段持續的時間)。
除了放棄不執行任何一致性檢查之外 (我絕對不建議這麼做)，您還有四種方法可以採用。我個人就曾經幫客戶採用過這四種方法。
使用 DBCC CHECKDB 的 WITH PHYSICAL_ONLY 選項 標準的 DBCC CHECKDB 會執行大量的邏輯一致性檢查，而佔用相當高的 CPU (而且基本上是繫結 CPU 的作業)。使用 WITH PHYSICAL_ONLY 選項會限制檢查作業執行非常快速的 DBCC CHECKALLOC 配置點陣圖一致性檢查，然後讀取和稽核資料庫中每個配置的頁面，進而強制測試頁面上所顯示的任何頁總合檢查碼。這麼一來就會把 DBCC CHECKDB 轉換成繫結 I/O 作業，大幅減少執行的時間 (事實上，有時候甚至比完整的 DBCC CHECKDB 還要快速，換句話說，真的可省下不少時間)。
分散一致性檢查工作負載 您需要把資料庫中的資料表分割成相同大小的群組 (最簡單的方法是依頁面數量來分割)，然後每晚使用 DBCC CHECKTABLE 命令，對單一檔案群組中的所有資料表進行一致性檢查。因此，比方說，如果以每天一個群組來檢查七個群組，一週進行一次 DBCC CHECKALLOC 和 DBCC CHECKCATALOG，即使是分散在一週間進行，還是相當於完成了 DBCC CHECKDB。
使用資料表分割搭配多個檔案群組 VLDB 中最大的資料表可分割為好幾個檔案群組。讓我們舉個一致性檢查結構描述的例子，比方說，每天在存放可讀寫磁碟分割的檔案群組上執行 DBCC CHECKFILEGROUP，然後每週在存放唯讀磁碟分割的檔案群組上執行 DBCC CHECKFILEGROUP。這個做法所依據的邏輯是，唯讀資料已經完全備份，而且在日常處理作業中也不會用到。因此並不需要經常進行一致性檢查，因為這些資料的損毀狀況並不是那麼危急。
將一致性檢查的負載卸載到其他伺服器 這個選項所牽涉的步驟包括將標準完整資料庫備份還原到不同的伺服器上，然後在該伺服器上執行 DBCC CHECKDB。這麼做的確可以完全卸載實際執行伺服器的一致性檢查工作負載，只不過，如果發現有損毀狀況，就必須在實際執行伺服器上執行一致性檢查 — 但這應該不常發生。
如您所見，DBA 要在 VLDB 上執行一致性檢查其實有很多選擇，可以減少執行完整 DBCC CHECKDB 時所需的額外資源負載。我剛才在前面提到，我個人就幫過客戶採用過全部四種方法，相信這些選擇也會適用您的情況。
提示：使用觸發程序來實作伺服器端邏輯
在某些情況下，您需要使用觸發程序來實作伺服器端邏輯，但是必須特別注意一些陷阱。下面就是幾件應該銘記在心的事。
  • 觸發程序是由陳述式引發，而不是在每一個資料列引發。也就是說，如果要處理受陳述式影響的多資料列情況，或是沒有任何資料列受陳述式影響的情況 (觸發程序是在每一個陳述式引發，即使沒有任何資料列受影響也一樣)，您一定要將額外的邏輯放在觸發程序邏輯裡面。受影響的資料是放在資料操作語言 (DML) 陳述式的虛擬資料表中。您可以將這些資料表聯結起來，以便處理資料。
  • 觸發程序可在交易當中同步執行。每當您要呼叫外部應用程式或存取外部資源，但又不確定是否會在合理的時間內獲得回應時，都應該記住這一點。比方說，如果您對資料表引發一個 Update 陳述式，而在該動作內引發一個觸發程序，那麼該交易 (Update 陳述式的隱含) 會等到觸發程序的全部邏輯都完成之後才會結束。如果外部應用程式或處理序傳回錯誤碼，SQL Server 可能會取消交易，並將交易復原 (端視實作的錯誤處理和錯誤碼而定)。所以，如果您需要在觸發程序內進行外部作業，而此作業對交易來說不重要的話 (或者不需要在相同的領域內執行)，應該將它向外擴展到另一個處理序，以非同步的方式挑出資料。SQL Server 2005 引進了 SQL Server Service Broker，它可以非同步地進行這類動作。
  • 要找出觸發程序內因陳述式導致的錯誤非常困難。如果交易內涵蓋多個資料表，一定要記得在發生錯誤及實作適當錯誤處理的情況下偵測觸發程序。如果您在資料庫內變更結構描述，也別忘了追蹤觸發程序邏輯 — 否則即使是小小的觸發程序，也會大大影響整體的效能和穩定性。大多數與結構描述變更相關的隱含式都可以使用 Visual Studio® for Database Professionals，在編輯專案時進行自動結構描述檢查，以及進行靜態程式碼分析來檢查是否有資料類型不一致的情形。
─ Microsoft 的資料庫顧問 Jens K. Suessmeyer

Paul S. Randal 是 SQLskills.com 的常務董事，同時也是 SQL Server MVP。他在 1999 年 2007 年間服務於 Microsoft 的 SQL Server 儲存引擎 (SQL Server Storage Engine) 小組。Paul 為 SQL Server 2005 寫了 DBCC CHECKDB/修復，並且在 SQL Server 2008 開發期間負責核心儲存體引擎。身為嚴重損壞修復、高可用性及資料庫維護方面的專家，Paul 經常在研討會發表演說。他的部落格網址是 SQLskills.com/blogs/paul。


公用程式焦點 Windows Installer CleanUp 公用程式
Lance Whitney

您試圖解除安裝或更新環境中某台電腦上的應用程式，但您的命令卻無法執行。不僅如此，還出現錯誤訊息，告知您無法解除安裝或更新應用程式。聽起來很熟悉嗎？若是如此，您一定很好奇是什麼造成這個小突槌。
使用 Microsoft® Windows® Installer (MSI) 技術安裝的軟體會寫入特定檔案與登錄設定。如果這些檔案或設定發生任何遺失或損毀，您可能就無法移除、更新，甚至是重新安裝程式。解決這種情況的方法就是移除所有 Windows Installer 資訊，好讓程式能夠重新進行全新安裝。為此，Microsoft 提供了免費的 Windows Installer CleanUp 公用程式。
Windows Installer CleanUp 公用程式會刪除與程式的 Windows Installer 設定相關聯的所有檔案和登錄設定。要注意的是，這個工具並不會移除程式的實際安裝檔案或登錄設定，也不會取代 [新增/移除程式] 命令。
而是在您無法使用 [新增/移除程式] 或其他方法來解除安裝或更新應用程式時，讓這個公用程式代勞。藉由刪除 Windows Installer 資訊，您應該能夠重新安裝應用程式。接著您可以照常安裝程式、更新程式，甚至是移除程式。
Windows Installer CleanUp 公用程式顯示電腦上所有以 Windows Installer 為基礎的應用程式清單 (按一下以放大影像)
有些人可能很熟悉 Microsoft 命令列程式 msizap，它可移除程式的 Windows Installer 資料。其實這裡仍然用到這個命令：Windows Installer CleanUp 只是 msizap 的易用前端，讓您無須再與繁雜的命令列選項奮戰。
安裝此公用程式之後，您會看到位在 Program Files 底下名為 Windows Installer Clean Up 的子目錄。這個子目錄中包含三個檔案：msicuu.exe、msizap.exe 及 readme.txt。msicuu.exe 檔案顯示電腦上所有以 Windows Installer 為基礎的應用程式清單，供您選取、取消選取和移除這些應用程式。這個程式接著將您的選項傳送到 msizap.exe 命令，並依此移除所選應用程式的 Windows Installer 資訊。
若要執行 Windows Installer CleanUp，請到 [開始] 功能表 | [所有程式]，找到此公用程式的資料夾，然後按一下 Windows Installer Clean Up 捷徑。Windows Installer CleanUp 公用程式顯示電腦上所有以 Windows Installer 為基礎的應用程式清單 (按一下以放大影像)選取有問題的應用程式，然後按一下 [移除] 按鈕。該應用程式便會從 Windows Installer 資料庫中刪除，讓您有機會重新進行全新安裝。
執行 CleanUp 工具之後，您會看到該應用程式已經不再出現在 [新增/移除程式] 中。因此，如果您的最終目的是要移除應用程式，就必須先重新安裝它。Windows Installer CleanUp 只適用於使用 Windows Installer 技術的軟體，其中通常涵蓋封裝成 MSI 檔案的安裝。
最後要注意的是，您必須以系統管理員的身份登入，才能執行 Windows Installer CleanUp。這項工具與所有 32 位元和 64 位元版本的 Windows 相容。如需公用程式以及下載軟體的詳細資訊，請在瀏覽器輸入以下網址：support.microsoft.com/kb/290301。

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


SharePoint 內幕 疑難排解訊息整合
Pav Cherny

程式碼下載： SharePoint2008_08.exe (416 KB)
目錄
一般疑難排解方法
SharePoint 訊息架構
取得診斷資訊
輸出訊息傳輸
輸入訊息傳輸
目錄管理
結論
在設計良好的 SharePoint 環境中，資訊工作者不必為了共同作業而改變他們的通訊習慣或是工作常規。他們可以利用 SharePoint，將文件和其他資訊 (例如警示和提醒) 直接送到他們的信箱，而不必不斷手動檢查共同作業站台。
使用者也可以藉由回覆這些郵件，或是以電子郵件將新項目傳送到文件庫和清單等方式，來參與工作流程。
然而，將 SharePoint® 整合至安全的訊息環境中除了有其挑戰性之外，也讓非 SharePoint 元件有機可乘，而影響以 SharePoint 為基礎的共同作業。挑戰在於，要如何在整合環境內發生問題的地方，有效地隔離和消除問題的根源。
在本專欄中，我會根據一套經過實證且可快速獲得成效的疑難排解策略，來探討 SharePoint 訊息整合。原則是要有效地找出問題點，然後以更詳盡明確的疑難排解步驟，進一步鎖定問題所在。
在大型組織中，這類分階段調查可能表示在進行初步分析之後，把案子交由其他專家辦理，尤其當問題是與非 SharePoint 元件相關時更是。另一方面，在中小型組織中，單由一名 IT 系統管理員直接包辦疑難排解所有相關系統的工作是很常見的，這也更加指出使用結構化方法的需要。
為了讓本專欄利於練習，我使用了裝有 Active Directory®、Exchange Server 2007 和 WSS 3.0 的測試環境。建置此測試環境的逐步說明，以及在本專欄中提到的疑難排解工具，皆可在附隨的材料中找到，這些材料位於 TechNet Magazine 網站的「程式碼下載 (Code Downloads)」區段。

一般疑難排解方法
疑難排解 SharePoint 訊息整合，或許比其他互通性的案例還需要高度結構化的方法。而使這樣的企圖更為複雜的因素有好幾個。
很顯然地，您得處理複雜的技術，而光是訊息傳輸的問題、訊息格式轉換、安全性層面，以及目錄管理問題就已經夠惱人了，有些令人困惑的 SharePoint 錯誤訊息更是雪上加霜。網際網路新聞群組到處充斥著未經澄清的往來討論和建議，這些內容很可能會誤導您 — 像是建議在 SharePoint 中央系統管理的應用程式集區識別下執行所有 Web 應用程式，以便讓訊息整合能夠順利運作就是一例。
不過，還是有正面影響可言，那就是 SharePoint 極具彈性。事實上，如果您知道要往哪裡找的話，它可以提供您詳盡的疑難排解資訊。只要幾個基本的指令碼，您就可以大大提升疑難排解的效率。
疑難排解的首要目標，是了解您要應付的是什麼問題。您必須識別出問題的所在，以及它所牽涉的元件。您也可以在不同的系統設定下重現問題，然後研究 Windows® 事件記錄檔和文字記錄檔。但因為有些問題是偶發性的，可能需要一點技巧。儘管如此，越是能重現問題，就越能更快識別和消除它的根源。另外一個常受到忽視的重要目標，是將所有設定變更和修正動作全部記錄下來，並確定將它們套用到環境內所有相關的系統上 (例如 Web 伺服陣列中所有的前端伺服器)。

SharePoint 訊息架構
每當您碰到與訊息整合相關的問題時，不妨先喝杯咖啡或茶，檢閱一下 SharePoint 訊息整合架構，再進行疑難排解。不然，可能到最後修正的是錯誤的問題或元件也說不定。例如，阻止您在 Active Directory 中建立連絡人物件的「拒絕存取」錯誤，不見得表示您必須修正 Active Directory 中的存取權限，您稍後就會明瞭。
無論是哪種情況，重要的是了解訊息整合當中相關各個元件的角色，以及個別元件彼此互動的方式。您可從 [圖 1] 看出 SharePoint 與 Exchange 連線案例的重要元件，這在下一節會詳細說明。
[圖 1] SharePoint 訊息整合架構 (按一下以放大影像)

取得診斷資訊
可靠的診斷資訊是最重要的疑難排解工具之一。而最經典的，非 Windows 事件記錄檔莫屬。另外，您還可以使用 SharePoint 中央系統管理 (在 [作業] 頁面上的 [記錄與報告] 下，按一下 [診斷記錄]) 來控制 SharePoint 寫入網頁伺服器上的 Windows 事件記錄檔的詳細程度。您可以指定將最不重要的事件報告到事件記錄檔以及追蹤記錄。如果您要的是低層資訊，那麼追蹤記錄 (預設位於 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs 下) 將非常管用，但是它填滿的速度很快，所以請節制使用此功能。
另外一種取得診斷資訊的方法，是設定相對應的 web.config 檔案來啟用受影響的 Web 應用程式的偵錯功能，如附隨資料中的 Web Application Config.pdf 所述。SharePoint 會將詳盡的追蹤資訊直接顯示在使用者介面中。這種方法的優點在於，您不用一一剖析好幾個 MB 的追蹤資料，就可以查看相關的錯誤資訊。缺點是您必須變更 Web 應用程式的系統設定。別忘了備份原始的 web.config 檔案，然後在完成疑難排解之後，還原成原始的設定。
您也可以設定 SMTP 服務，將詳細的處理資訊寫入 SMTP 通訊協定記錄檔 (在 IIS 管理員中，選取 [一般] 索引標籤上的 [啟用記錄] 核取方塊)。請務必如附隨資料中的 SharePoint Messaging Integration.pdf 所述，將 ODBC 記錄隨同 SMTP 服務功能一起安裝，即使您不打算使用 ODBC 記錄也一樣。否則，SMTP 服務將不會寫入通訊協定記錄檔。根據預設，SMTP 通訊協定記錄檔是位於 %SystemRoot%\System32\LogFiles\SmtpSvc1。它是一個文字檔，可讓您詳細分析 SMTP 通訊，並判斷訊息是否已離開 SharePoint 伺服器。
在 Hub Transport Server 與 SMTP 服務的通訊期間，您也可以在 [傳送連接器] 和 [接收連接器] 設定中啟用通訊協定記錄 (請參閱 SharePoint Messaging Integration.pdf)。您可以使用其他各種工具，來追蹤訊息在 Exchange Server 2007 環境中跨越 Hub Transport Server 和 Mailbox Server 所採用的路徑，例如訊息追蹤、佇列檢視器，以及管線追蹤。如果您想要關於疑難排解 Exchange Server 2007 郵件流程問題的詳細資訊，請參閱＜傳輸與郵件流程問題＞，網址是 go.microsoft.com/fwlink/?LinkID=120145。
在 Active Directory 網域控制站上，您可以啟用目錄存取和其他類別 (透過設定 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics 下相對應的登錄項目) 的診斷記錄，來收集詳細的疑難排解資訊。值為 0x0 的類別表示只會記錄重要的事件，而 0x5 的值則代表所有事件，包括偵錯資訊在內。使用高於 0x3 的記錄層級可能會折損伺服器效能，並且很快會填滿 Windows 事件記錄檔。在正常的操作期間，所有值都應該設為 0x0。
在疑難排解的情況下收集 SharePoint、Exchange 和 Active Directory 伺服器上的詳細診斷資訊，有利您迅速且可靠地找出問題點。其他疑難排解工具，像是 TCP/IP 工具 (ping、tracert、telnet 等等) 和網路監視器可能也很管用，因為這些系統之間的大部分通訊都是在電腦網路上進行。Microsoft® Network Monitor 3.1 可在 go.microsoft.com/fwlink/?LinkId=120143 上取得。

輸出訊息傳輸
資源
  • SharePoint 產品和技術網站
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services 開發人員中心
  • Microsoft SharePoint 產品和技術小組部落格
配備了事件記錄檔、追蹤記錄、通訊協定記錄檔、訊息追蹤記錄和網路追蹤後，就可以開始排解 SharePoint 訊息整合的疑難了。讓我們先從簡單的部分下手：輸出訊息傳輸。SharePoint 支援各種不同設定的輸出訊息傳輸，而且網頁伺服器上不需要有本機 SMTP 服務。不過，在完整的訊息整合案例中，還是建議使用本機 SMTP 服務。[圖 2] 顯示了此案例中的主要元件。
[圖 2] 輸出訊息傳輸 (按一下以放大影像)
此訊息案例包含四個階段：SharePoint 必須將訊息傳輸給 SMTP 服務，SMTP 服務必須處理訊息，Hub Transport Server 必須接收訊息，然後 Exchange Server 2007 必須將訊息傳輸到最終目的地。
如果 SharePoint 無法將訊息傳輸到 SMTP 服務，通常您會在使用者介面中收到錯誤，例如無法傳送電子郵件通知。原因可能是 SMTP 服務不在執行中的關係。或者，SMTP 通訊協定記錄有可能會以錯誤碼 550 (未採取要求的動作：無法使用信箱) 來告訴您它拒絕提交嘗試，這表明了問題是出在 SMTP 服務身上。
若要確認這不是 SharePoint 的問題，您可以使用一個基本指令碼 (請參閱附隨資料中的 SMTP.vbs)，以相同的寄件者和收件者資訊，提交一個測試訊息。如果是 SMTP 服務的問題，指令碼就會失敗。實際上，這個指令碼可提供您寶貴的線索找出問題的根源，因為不幸的是，即使啟用偵錯功能，SharePoint 也不會揭露這項資訊，如 [圖 3] 所示。
[圖 3] 無法轉送訊息 (按一下以放大影像)
您可以透過在 SMTP 服務設定中授權讓網頁伺服器進行轉送，然後重新啟動 SMTP 服務，來解決 SharePoint 訊息提交的問題。現在訊息既然可以抵達 SMTP 服務，下一個重要的問題是，SMTP 服務是否能將訊息路由到 Hub Transport Server。
如果訊息仍留在 [佇列] 資料夾，SMTP 服務便無法聯繫 Hub Transport Server。原因可能是 Microsoft Exchange Transport 服務不在執行中，或是網路通訊或設定的問題。不過只要利用 Telnet 用戶端，便可以迅速且輕易地查驗您是否可以連接到接收連接器的目的地連接埠，這個連接器是為了進行內部通訊而設定的。
這並不一定是 TCP 連接埠 25。事實上，如果 SMTP 服務使用這個連接埠，您可將訊息傳輸到 Hub Transport Server 的預設接收連接器，這個接收連接器是為了封鎖匿名訊息提交而設定的。在本例中，您會在 [放置] 資料夾中看到一個訊息檔案 (Windows SharePoint Services 計時器服務必須停止，否則訊息會在幾秒鐘之後消失)。訊息檔案是一種傳遞狀態通知，它會指出訊息已遭拒，並產生「診斷碼：smtp;530 5.7.1 用戶端未經驗證。」
為了解決這個問題，您應該為 SharePoint 伺服器建立專用的接收連接器。由於 SharePoint 伺服器是內部系統，因此請選取 [以外部方式保護安全] 驗證選項。這樣一來，您就不用授與匿名登入帳戶延伸的權限了。另外，也可以考慮使用 IPsec 來保護 SharePoint 伺服器與 Hub Transport Server 之間的通訊。
如果訊息離開 SMTP [佇列] 資料夾，而且 SharePoint 伺服器及 Hub Transport Server 上的 SMTP 通訊協定記錄 (請查閱 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive 資料夾) 指出訊息順利傳輸，就算大功告成，只要 Exchange Server 2007 可以將訊息路由到目的地就行了。如前文所述，如果訊息沒有送達指定的 Exchange 收件者，請使用 Exchange Server 2007 內含的郵件流程疑難排解工具來調查任何問題。要注意的是，在這個階段，錯誤的收件者資訊、垃圾郵件篩選器和訊息大小限制都可能阻礙最終的傳遞。

輸入訊息傳輸
反方向的訊息傳輸則稍微複雜一些，因為潛在的問題更加難以捉摸。舉例來說，SharePoint 產品說明文件建議針對 SharePoint 電子郵件網域，設定 DNS 中的 MX 記錄，這很容易在 Exchange 的組織中誤送訊息。
Exchange Server 2007 是使用傳送連接器與相關的位址空間來傳輸訊息。即便您的 SharePoint 是內部的，它還是可能將 SharePoint 訊息路由到 Edge Transport Server，以便在網際網路上傳輸。對於內部訊息傳輸，請改用傳送連接器與詳細的位址空間，並在連接器設定中，將執行 SMTP 服務的 SharePoint 伺服器指定為智慧主機 (請參閱隨附的下載中的 SharePoint Messaging Integration.pdf)。以專用的 Bridgehead 伺服器來建立定義完備的路由拓樸，有助於達成 Exchange 至 SharePoint 間可靠的訊息傳輸。
為了查驗訊息確實抵達您的 SharePoint 伺服器，請停止 Windows SharePoint Services 計時器服務。如果不這麼做，訊息會堆積在 [放置] 資料夾中，因為計時器服務會處理訊息，並將檔案附件放到與收件者電子郵件地址相關的文件庫，如 [圖 4] 所示。假如訊息沒有抵達 [放置] 資料夾，請使用 Hub Trasnport Server 上的佇列檢視器來查看 Exchange 是否正確地路由訊息。之後再調查可能阻礙 Hub Transport Server 與 SharePoint 伺服器上的 SMTP 服務進行通訊的網路通訊問題。
[圖 4] 輸入訊息傳輸 (按一下以放大影像)
重新啟動計時器服務時，應該會看到訊息項目從 [放置] 資料夾消失。然而，若是 SharePoint 在 Windows 事件記錄檔中指出訊息處理順利，但訊息附件最後在目的地文件庫裡面卻沒有顯示成文件，這表示 Exchange 是以 Exchange RTF 格式來傳送訊息。若要調查這個問題，請再次關閉計時器服務，從 Outlook® 用戶端傳送另外一封含附件的訊息，然後等訊息抵達 [放置] 資料夾後，在記事本中開啟它。接下來請搜尋「winmail.dat」字串。如果找到此字串，表示 Exchange Server 傳送訊息的格式有誤。
SharePoint 要求訊息附件必須以 MIME 或 UUENCODE 格式編碼。此外，SharePoint 也不會在 Windows 事件記錄檔中顯示任何 winmail.dat 相關的處理問題 (見 [圖 5])。因此，檔案附件根本就不會顯示在文件庫中。您可以利用記事本作為疑難排解的工具，然後針對 SharePoint 電子郵件網域，在 Exchange 管理主控台中設定遠端網域定義，來消除格式化的問題。請在 [以日誌報告附件型式來傳送的原始郵件格式] 索引標籤的 [Exchange RTF 格式] 下，選取 [永不使用 (Never use)]。
[圖 5] Winmail.dat 訊息處理 (按一下以放大影像)

目錄管理
其中一個比較實用的計時器服務事件是事件 6873，它會指出處理內送電子郵件檔案時，因為別名不明而發生錯誤。如果 Exchange 使用者在傳送訊息時指定的 SharePoint 電子郵件地址有誤 (例如不存在的文件庫)，就會發生這個錯誤。
您可以在 SharePoint 中央系統管理內的 [內送電子郵件] 設定中，設定 [目錄管理服務]，以便在 Active Directory 中針對有啟用郵件的文件庫建立收件者物件，藉此緩和這個問題。Exchange 使用者隨後就可以方便地從通訊錄選取這些含有正確地址資訊的收件者物件了。
不過，要注意的是，您這樣等於是開了一大罐全新的疑難排解蟲。根據最低權限的原則，目錄管理服務會在保全的系統設定中失敗，因為這項功能在網頁伺服器上必須要提高權限才能使用。更麻煩的是，產品說明文件 (例如 technet.microsoft.com/library/cc262947.aspx) 在建議您必須在 Active Directory 中針對 SharePoint 收件者物件指定的 OU 裡面，授與中央系統管理應用程式集區帳戶「建立、刪除和管理使用者帳戶」的權限，也誇大其詞了些。
目錄管理服務會建立連絡人和群組物件，因此中央系統管理應用程式集區帳戶對這個 OU 中的連絡人和群組物件需要具備完整控制權，但它對使用者帳戶並不需要系統管理權限。假如您是據此在 Web 伺服陣列中設定目錄管理服務，然後試著啟用文件庫的郵件功能，就非常有可能會遇到「拒絕存取」錯誤。
錯誤資訊將問題的矛頭指向 Active Directory 權限，於是 SharePoint 系統管理員便迅速指派完整控制權給 SharePoint OU 的任何人。但是，這不但只會削弱 Active Directory 安全性，更不能解決問題。
結構化疑難排解要求您先找出問題點，然後套用鎖定目標的設定變更。如果您遵循這套方法，然後檢查網域控制站上的 Windows 事件記錄檔，或許也使用網路監視器來追蹤網路通訊，您可能會發現 SharePoint 在發生這個問題時，並沒有存取 Active Directory。因此，變更 Active Directory 設定不太可能會修正這個問題。問題是出在 SharePoint 伺服器身上。
不幸的是，要取得更多關於此權限問題的實用資訊比登天還難。SharePoint 並不會在 Windows 事件記錄檔中記錄任何額外的資訊。不過，如果您啟用 SharePoint 偵錯的話，可看到呼叫堆疊 (如 [圖 6] 所示)，它會建議目錄管理服務使用 SharePoint Web 服務的 CreateContact 方法。SharePoint SDK 會告訴您這是「電子郵件整合 Web 服務」(<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx)。
[圖 6] 偵錯輸出
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
讓我們以網頁瀏覽器瀏覽 SharepointEmailWS.asmx，看看受到支援的作業清單。您會看到 CreateContact 方法，如果您想要在 Active Directory 中建立連絡人的話，按一下 CreateContact 連結即可顯示您必須傳送到此 Web 服務的 SOAP 訊息。這一步相當管用，因為現在您就可以建立以指令碼為基礎的疑難排解工具 (請參閱附隨材料中的 SharepointEmailWS.vbs)，在 SharePoint 使用者介面外面工作，以方便在進行測試期間指定不同的使用者。[圖 7] 顯示您在中央系統管理應用程式集區帳戶 (左方) 下，以及在 SharePoint 系統管理員帳戶下 (右方) 執行此指令碼所傳回的資訊。
[圖 7] 兩種不同的「拒絕存取」錯誤 (按一下以放大影像)
錯誤訊息竟不相同！兩個訊息都指明存取遭拒，但是左方的錯誤表示是處理問題，而右方的錯誤則不然。那麼應用程式集區帳戶與 SharePoint 系統管理員帳戶之間到底有什麼差別呢？
SharePoint 系統管理員在 SharePoint 伺服器上是本機系統管理員，而應用程式集區帳戶則不是。雖然將 Web 應用程式的應用程式集區帳戶新增到本機 Administrators 群組，然後重新啟動網頁伺服器可以解決問題，但並不是什麼好主意。我認為在實際執行網頁伺服器上執行具備系統管理權限的應用程式集區帳戶並不妥當。
為什麼應用程式集區帳戶需要這些提高權限呢？同樣地，答案在於指令碼。如果您基於測試目的，在網頁伺服器上授與所有使用者本機系統管理員權限，您會發現即使所有其他帳戶 (包括 SharePoint 系統管理員在內) 都被拒絕存取，應用程式集區帳戶還是可以使用「電子郵件整合 Web 服務」。這表示「電子郵件整合 Web 服務」是根據應用程式集區設定來作出存取控制的決策。
應用程式集區設定是 IIS Metabase (在 IIS 7.0 中為 applicationHost.config 檔案) 的一部分，而 Metabase 預設只限本機系統管理員存取。所幸，您可以使用 IIS 6.0 Resource Kit 工具內含的 Metabase Explorer，授權讓非系統管理員帳戶存取 Metabase。在 IIS 7.0 上，要授與 applicationHost.config 檔案的完整控制權更加簡單，只要執行下列命令就行了：
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
總而言之，為了在 Active Directory 建立連絡人物件，中央系統管理應用程式集區對於目標 OU 中的連絡人和群組物件，必須具備完整控制權。而 Web 應用程式的集區帳戶在 Web 伺服陣列中的 SharePoint 伺服器上，必須能夠完整存取 Metabase。現在您可以開始使用 SharePoint 使用者介面來建立連絡人物件了。
等等，還不止這些呢！在 Active Directory 中建立收件者物件，只不過是目錄整合故事的前半段。後半段是產生 Exchange 相關的收件者屬性，然後更新以伺服器為主的通訊錄。比方說，如果您使用 Exchange 管理命令介面命令 Update-GlobalAddressList "Default Global Address List" 來更新 Exchange 伺服器上的全域通訊清單，可以在 Outlook 通訊錄中找到針對 SharePoint 文件庫新建的收件者物件。但是傳送訊息到這些收件者可能會產生因地址資訊錯誤而無法送遞的報告，如 [圖 8] 所示。
[圖 8] 無法送達文件庫的訊息 (按一下以放大影像)
IMCEAEX 是 Internet Mail Connector Encapsulated Address for Exchange 的縮寫。它表示舊版 Exchange Internet Mail Connector 其實可以處理封裝的非 Exchange 收件者地址的格式。但我們如今處理的是 Exchange Server 2007 和原生 SMTP 架構的傳送連接器。
重點是，SharePoint 電子郵件整合 Web 服務並不會寫入 Exchange Server 2007 進行訊息傳輸所需的地址屬性。它只會寫入名字、姓氏、顯示名稱和目標地址以及 ms-ExchRequireAuthToSendTo 屬性 (不過最後一項屬性可有可無)。但是它不會設定郵件別名，或是舊版 Exchange DN 或 Proxy 位址，也不會將收件者物件與 Exchange 收件者原則相關聯。
若要解決此問題，請使用 Exchange 管理命令介面中的 Get-Mailbox 指令程式，取得內含指向 SharePoint 電子郵件網域之目標位址的所有收件者物件。然後將輸出代入 Set-MailContact 指令程式，來啟動 Exchange 收件者原則，如下所示：
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
或者，您可以使用 Exchange 管理命令介面，並選取連絡人物件屬性中的 [依照電子郵件地址原則自動更新電子郵件地址] 核取方塊。

WSS 3.0 和 MOSS 2007 都支援現成的完整訊息整合，以啟用以電子郵件為主的警示和通知、工作流程和文件提交。正確設定系統雖然不是一件易事，但訊息整合可提升工作者的產能。更具體的說，您必須確定輸入和輸出訊息傳輸都能正常運作，同時也應該確保目錄整合能夠運作。
SharePoint 錯誤訊息不一定都很直觀，也不一定能提供參考資訊。但是我已經示範一些方法，可以找出整合問題根源、確定起因，以及如何在不危及 SharePoint 伺服器安全性的情況下可靠地消除問題。

Pav Cherny 是 IT 專家兼作者，專攻 Microsoft 共同作業與整合通訊技術。其著述包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。同時 Pav 也是專營管理文件與本土化服務之 Biblioso Corporation 的總裁。


Windows PowerShell 一窺 2.0 版中的遠端管理
Don Jones

本專欄是根據 Windows PowerShell 的搶鮮版所撰寫。本文包含的所有資訊均有可能變更。

目錄
兩種遠端處理類型
同步與非同步比較
可重複使用的 Runspace
收合傳送遠端處理
2.0 中的超級應用程式
您有機會嘗試 Windows PowerShell 2.0 最新版的 Community Technology Preview (CTP)嗎？最新版 CTP2 更進一步強化了遠端管理，而現在正是開始著手了解它的新功能的好時機。開始之前，您應該花點時間
從 go.microsoft.com/fwlink/?LinkID=119707 下載這個新版本。
首先，讓我釐清一下幾個重點。CTP 是 Beta 測試版前的程式碼，Microsoft 專為像我這種迫不及待的使用者提供 CTP，來稍微了解 Microsoft 在下一版的應用程式所朝的方向。每個 CTP 里程碑或 Drop (他們在業界都這麼稱呼) 可能與前一個 Drop 完全不同。這是因為開發小組會收集意見反映，仔細檢討，然後根據這些使用者意見來修改應用程式。這套方法針對 CTP 的使用帶來了重要的好處和警告。
影片
觀賞 Don Jones 示範 Windows PowerShell 2.0 CTP2 中全新的遠端管理功能。

好處是，當您使用 CTP 時，您能在開發期間提供產品相關的意見反映 (透過 connect.microsoft.com 網站)，也就是說開發小組仍然能夠針對您的意見反映採取行動！如果您等到 Beta 測試版，甚至拖到 Release Candidate 階段，要實現您的意見就難得多了。在 CTP 期間，任何事情都可能發生，而且開發小組能夠在必要時，進行龐大且廣泛的變更。
這就把話題帶到警告的部分，那就是 CTP 還不適合用於生產環境。沒錯，Windows PowerShell™ 2.0 CTP2 可能是您看過最穩定的預先發行程式碼之一，但是別忘了，下一個 CTP 的 Drop 可能又是個截然不同的應用程式。因此，不要這麼倚賴 CTP2，因為在下一版，您可能又要重新來過。
要注意的是，CTP 並不能與 Windows PowerShell 1.0 並行安裝。系統還必須安裝 Microsoft® .NET Framework 3.5，以啟用所有可用的功能，才算是理想的設定。否則，有些功能可能會受到限制。
再加上 CTP 是非常初期的程式碼，因此 Microsoft 目前主要把重點放在應用程式在最新版作業系統上的運作情況，也就是 Windows Vista® 和 Windows Server® 2008。目前的 OS 相容性並不等於在最終發行程式碼提供的 OS 相容性。回溯移植在開發週期後期才會考慮。

兩種遠端處理類型
在遠端管理的世界中，您通常會看到兩種類型的遠端處理：收合傳送和展開傳送。收合傳送遠端處理包含多名系統管理員與單一伺服器進行安全殼層連線。Windows PowerShell 是為了在安全、分隔的方式下進行這個作業而設計的，舉例來說，像 Exchange Server 虛擬主機公司便能為客戶提供系統管理存取權，存取屬於客戶部分的伺服器。透過收合傳送遠端處理，您便能對遠端伺服器上安裝的 Windows PowerShell (僅限 2.0 版！) 進行安全、遠端、互動式存取。
當您一次對一整組遠端伺服器發出一組命令時，便會進行展開傳送遠端處理。從工作站對伺服器組發出的「展開傳送」命令是並行進行的。命令會在每部伺服器上執行，而且結果 — 以 Windows PowerShell 物件的形式 — 會傳回到您的工作站，供您檢閱與使用。Windows PowerShell 支援兩種核心技術來進行展開傳送遠端處理 — Windows® Management Instrumentation (WMI) 與 Windows Remote Management (WinRM)，這首先是跟著 Windows Server 2008 一同發行，隨後在 Windows PowerShell 2.0 CTP 中更新。

同步與非同步比較
其實 Windows PowerShell 1.0 也有一些基本的展開傳送功能是繫結到 WMI。比如，您可以輕易建立電腦名稱陣列，然後從各個當中擷取 WMI 類別：
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
執行方法 — 例如重新開機 — 就需要多費點力，因為 1.0 版並沒有提供大量執行 WMI 方法的管道。不過，這在 2.0 版的 CTP 已經改觀，都要歸功於 Invoke-WmiMethod 指令程式。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
但是這項技術有個問題，那就是它是同步的，換句話說，一次只會聯繫一部電腦，而且您必須等到每部電腦完成後才能執行其他命令。而 CTP 引入了新概念 — 背景工作 — 允許這類的命令在背景執行。最簡單的用法是，直接加入 –AsJob 參數讓 WMI 命令在背景執行：
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
您可以執行 Get-PSJob 來檢閱所得的工作狀態，執行 Receive-PSJob 來查看工作的最後結果 (我會在下期專欄深入探討工作管理背後的細節)。而 Invoke-Command 指令程式則提供更佳的管道在背景執行命令，像這樣：
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
這其實是將 Get-WmiObject 命令向外推入指定的每部電腦，然後它會在本機執行。它的執行速度通常快得多，而且不用仰賴 WMI 遠端程序呼叫 (RPC) 連線。Invoke-Command 反而是利用 WinRM，它預設是使用連接埠 80 或 443。這些連接埠不但方便瀏覽防火牆，而且完全可設定。Invoke-Command 也支援其他參數以採用替代的憑證和節流，允許您鎖定上百部電腦為目標，但只平行執行其中的少數。這可避免壅塞及過多的負荷。

可重複使用的 Runspace
如果您打算多次從遠端管理一組特定電腦，應該考慮使用 Runspace，而不是簡單的電腦名稱清單。在 Windows PowerShell 中，無論是在電腦上從本機作為殼層主控台視窗執行，或是在遠端電腦的背景執行，Runspace 都只是殼層引擎的執行個體。啟動遠端 Runspace 很簡單：
$names = @("server1","server2","server2")
New-RunSpace –computer $names
因為 Runspace 也使用 WinRM，所以它們預設也是使用連接埠 80 (或是 443，如果您指定 –UseSSL 參數的話)，而且也可以接受替代憑證等。如果您擷取產生的 Runspace 物件，可以將它們傳遞給 Invoke-Command，而 Windows PowerShell 會將該命令向外推入那些 Runspace 所存在的電腦上：
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
這裡的好處是，只要殼層處於開啟狀態，Runspace 會一直保持作用狀態，因此您可以直接將它們重複用於其他命令。

收合傳送遠端處理
Runspace 也是收合傳送遠端處理的關鍵。例如，[圖 1] 說明我在遠端電腦上已建立了一個 Runspace，擷取了該 Runspace 的參考，然後使用 Push-Runspace 指令程式來啟動 Runspace。此時，我是在遠端電腦上執行命令，跟 SSH 或其他遠端殼層公用程式允許進行的動作沒什麼兩樣。執行 Pop-Runspace 帶回了我原始的「本機」Runspace，而且殼層提示還幫我隨時追蹤我所在之處。
[圖 1] 使用 Runspace 在遠端電腦上執行命令 (按一下以放大影像)
我執行的實際命令順序如下：
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
這項技術之所以稱為收合傳送，是因為多名系統管理員可以同時在相同的伺服器上開啟遠端互動式 Runspace — 他們從個別的工作站「收合傳送」到伺服器。Windows PowerShell 2.0 中全新的安全性模型可讓您建立限制的殼層和指令程式，以防止各個系統管理員進行全域修改。每名系統管理員都僅限修改自己的殼層區域 (這些新安全性技術需要以 .NET Framework 為目標的語言進行一些自訂軟體開發。這已超過 Windows PowerShell 專欄的討論範圍，不過知道有這些功能挺不錯的)。

2.0 中的超級應用程式
Windows PowerShell 2.0 CTP 有一長串出人意表的新功能。我個人認為遠端處理是最棒的應用程式。幾乎各種環境內的每個系統管理員都可以從中受益。
您應該讓自己熟悉這些功能，這樣才能提供建議給產品小組。您希望透過群組原則來管理 WinRM 預設連接埠嗎？指令程式應該以不同的方式運作嗎？有任何效能方面的問題嗎？WinRM 容易設定嗎？您可以將意見送到 connect.microsoft.com 或是與 MVP 得獎人 (包括我本人在內，若要與我連絡，請將您的意見送到 ScriptingAnswers.com 上的論壇) 分享您的意見，藉此發揮影響力。所以，趕快共同加入來協助建置下一代 Windows PowerShell 的超級應用程式！
本月指令程式：Select-Object
試試看：Get-Service | ConvertTo-HTML | Out-File Services.htm。現在到網頁瀏覽器中看看產生的 HTML 檔案。資訊一籮筐，對吧？要是有方法可以只選取您感興趣的資訊來精簡資料的話，該有多好。這正是 Select-Object 可以幫上忙的地方。譬如，假設您只想要服務名稱及其目前狀態的清單。可以使用：Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm。
不過，有件事您要記得，那就是 Select-Object 會丟棄原始物件 — 在本例中，亦即服務 — 而且會產生當中只包含您指定屬性的自訂物件 (實際上是 PSCustom 物件類型)。原始物件的任何功能都不能再存取，因此您可能會想要把 Select-Object 留在管線的尾端，盡可能充分利用原始物件。

Don Jones 是《Windows PowerShell v2.0:TFM》的作者之一，並且是 ScriptingAnswers.com「Special Forces」課堂訓練課程背後的培訓講師 (scriptinganswers.com/training.asp)。您可以透過電子郵件與他連絡：jeepdon@mac.com。


嗨，Scripting Guy！ 搭乘特快車
Microsoft Scripting Guy

過去幾個月，有一位 Scripting Guy 在我們西雅圖地區經歷了新的體驗。那是一個目前在全美各城接受測試、名叫電子收費的程式。不過它在華盛頓州，稱為 Good to Go！(準備動身了！)。
它的運作方式如下：您付費取得一個裝在擋風玻璃上的電子裝置，並且開啟一個帳戶，在裡面匯入少許的錢。每當您通過高速公路其中一個監視裝置時，它就會從您的帳戶自動扣款。簡單說，就是不必停在收費站付費，就能夠在高速公路上開車 (高速公路 freeway 的 free 實在名不符實，應該改稱高速公路為 highway 了吧 ─ 不過有的路段最近都積了幾呎深的水，好像也不是那麼高速啦)。
目前有許多收費地區規定，只要多人共乘就不必付費。不過 Good to Go! 有意思的地方在於，它只用於共乘路段。這樣做有什麼意義呢？要努力找人共乘，還要付費，有誰願意做這種事呢？沒錯，的確沒人會做這種事。其實這個系統是向那些在共乘路段開車卻不共乘的人收費。想要在共乘路段開車，顯然是因為這條路段車子較少；有時候共乘路段甚至是車子動得了的唯一路段。
前面我們也提過，這個系統目前還在實驗階段，不過已有數千人為它聯名簽署了。西雅圖地區有很多人非常願意付錢搭乘這種特快車，飆到他們的目的地。
在本月份的專欄中，Scripting Guy 決定自己做一個小小的實驗。我們決定介紹一種名叫 Microsoft® Visual Basic® Express Edition 的特快車。先告訴您，這種特快車最棒的一點，就是它可以免費使用；無論您在哪裡使用這項資訊、有多少人使用，或者什麼時間使用，都不必付費。怎麼樣，不賴吧？當然嘍，您可能得意思意思付點代價，來學習一些新東西，不過這也是值得的。
在開始之前，我們要先提一下，我們知道介紹這些內容是有點越界。通常像 Visual Basic 和 Visual C#® 這類的 Visual Studio® 產品，應該是《MSDN® Magazine》而不是《TechNet Magazine》負責的範圍。不過，MSDN 和 TechNet 似乎越來越像一個溝通不良 — 啊，我是說，快樂的 — 大家庭，所以我們希望不必分得那麼清楚。另外，即使我們討論的主題在傳統上是被當作開發人員工具，但是討論的對象還是 Windows® 系統管理員。別走開，再聽個幾分鐘，您就會明白我們在說什麼了。
首先，您必須先安裝 Visual Basic。等等！先別說「我沒有！」或「我買不起！」這種話，Microsoft 已在 microsoft.com/express/download 提供精簡版的 Visual Basic，供您免費下載。
我們不打算詳細解說如何使用 Visual Basic Express。這些部分您可以參考 [說明] 中的教學課程，而且 [說明] 本身寫得還真不錯 (很難相信吧？) 我們要告訴您的是，如何使用 Visual Basic Express 來解決一個特殊的 Windows Vista® 問題 (不過這個例子也適用於舊版的 Windows)，接下來您就可以自己動手試玩。下面就是我們要解決的問題：要如何開啟 Windows Vista 中的 [開啟舊檔] 對話方塊？
我們在幾年前曾經解說過如何從指令碼開啟 [開啟舊檔] 對話方塊 (請參閱 microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx 的《如何向使用者顯示一個可讓他們選取檔案的對話方塊》(英文) 專欄。那篇文章早在 Windows Vista 問世前的 2005 年 1 月就出版了。解決的辦法是使用 UserAccounts.CommonDialog ActiveX® 控制項來開啟 [開啟舊檔] 對話方塊，讓您瀏覽您要開啟的檔案。不過，Windows Vista 已經移除這個控制項，換句話說，這個解決方案在新版系統是行不通的 (其實，根本就沒人問我們移除這個控制項是不是個好主意)。意思就是說，就我們所知，目前沒辦法用 VBScript 開啟 [開啟舊檔] 對話方塊。所以，我們打算使用 Visual Basic 而不是撰寫指令碼，來撰寫應用程式。而這個應用程式的其中一項功能就是開啟 [開啟舊檔] 對話方塊。
沒錯，接下來我們要示範的例子，是在 Visual Basic 建立一個完整的應用程式。這剛開始聽起來工程不免稍嫌浩大，不過接下來您就會見識到 Visual Basic Express 撰寫完整應用程式的本事，絕不會輸給指令碼。這個應用程式含有一個視窗 (或表單)，您可以在裡面按其中一個按鈕，開啟 [開啟舊檔] 對話方塊，再從這個對話方塊選取文字檔，接著應用程式會從那些文字檔讀取文字，再從其中選取部分內容顯示在表單內。
好了，讓我們做做看吧。要開始，先開啟 Visual Basic Express。第一件事就是從 [檔案] 功能表選取 [新增專案]，建立新專案。此舉會顯示 [新增專案] 對話方塊 (請注意，如果您所用的 Visual Basic Express 版本早於 2008，那麼您所看到的畫面會與我們在此提供的不太一樣)。我們要建立一個 Windows 表單應用程式，接著選取 Windows 表單應用程式範本，然後輸入您要的專案名稱。我們取名為 ReadFiles，如 [圖 1] 所示。
[圖 1] 在 Visual Basic 建立一個新專案(按一下以放大影像)
專案第一次建立時，會自動提供新表單讓您使用。我們要建立的應用程式，會提供如 [圖 2] 所示的表單給使用者。 我們之前提過，這份表單包含一個按鈕，按一下這個按鈕，就會顯示 [開啟舊檔] 對話方塊，開啟到 C:\Scripts 資料夾。使用者可以從檔案系統的任何地方選取一或多個文字檔。接著應用程式就會讀取每一個所選文字檔的第一行，把結果顯示在表單的清單方塊中 (如果您覺得這個步驟聽起來很熟悉，那您一定參加過「2008 年指令碼比賽」的初學者組別：microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx)。
[圖 2] 提供給使用者的 ReadFiles 表單
要建立表單，必須將 [工具箱] 的控制項拖曳到專案表單上。根據預設，[工具箱] 是在 Visual Basic 視窗的左手邊開啟 (如果 [工具箱] 沒有開啟，請按一下 Visual Basic 工作區左手邊的 [工具箱] 按鈕，然後展開 [所有的 Windows 表單 (All Windows Form)])。請按一下 [工具箱] 的 [按鈕]，然後將滑鼠拖曳到表單上面，以您要的大小建立按鈕。如果要在按鈕當中加入標籤，請按一下您剛剛加到表單中的按鈕，然後輸入您要的標籤 (您也可以編輯 [內容] 對話方塊中的 [文字] 內容，它預設位於 Visual Basic 工作區的右下角)。此處我們把按鈕的標籤設為 [瀏覽檔案]。接著請按一下 [清單方塊]，再按一下表單，然後拖曳滑鼠來建立清單方塊。我們會使用這個清單方塊來顯示我們從文字檔讀取的字行。
建立表單要做的就是這些了。接下來好戲才要上場：我們希望在按一下按鈕之後，發生一些事情。開始先按兩下表單中的 [按鈕] 控制項，這會開啟程式碼編輯器，而且也幫您建好了一個新的副程式 (Button1_Click 副程式)：
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
每當有人按一下表單中的這個按鈕時，就會執行這個副程式。如您所見，此時副程式還是空的；我們需要加入程式碼，告訴應用程式，當我們按了該按鈕時，它該做什麼。我們到底要做什麼呢？首先，要做的是我們在本專欄一開始所承諾的事：開啟 [開啟舊檔] 對話方塊。就像我們用 Visual Basic 做每一件事一樣，這一次我們要用 Microsoft .NET Framework 來進行。
我們先在副程式上面加入幾個 Imports 陳述式：
Imports System
Imports System.IO
這些陳述式會指定 .NET Framework 命名空間。我們要使用位於這些命名空間當中的類別，在此匯入它們，以便參照我們想要的類別。請注意，我們說過要把這些陳述式加在副程式上面。Imports 陳述式是全域通用，也就是說，它們不能放在副程式或函數當中，必須單獨留在外面。
在 VBScript 中，除非您把 Option Explicit 陳述式加在指令碼前面，否則不必明確宣告變數。但在 Visual Basic 中它會自動加入，所以您必須宣告所有的變數。我們需要一個變數來保留 OpenFileDialog 物件的參照 (該物件剛好代表 [開啟舊檔] 對話方塊)：
Dim dlg As Windows.Forms.OpenFileDialog
宣告 (Dim-ed) OpenFileDialog 型別的變數之後，我們就可以為這個物件建立新的執行個體了，如下所示：
dlg = New OpenFileDialog()
但是，我們還沒有顯示這個對話方塊。首先，我們需要設定一些屬性：
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Multiselect 屬性會指定使用者是否可以從 [開啟舊檔] 對話方塊選取一個以上的檔案。我們希望可以，所以把這個屬性設為 True，然後再把 InitialDirectory 屬性設為 C:\Scripts。如果不設定這個屬性，對話方塊就會開啟到主要電腦目錄。
最後 (而且肯定也很重要)，我們再設定 Filter 屬性：
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
我們要在這裡篩選對話方塊顯示給使用者看的檔案。我們只要顯示 .txt 檔。設定這些屬性會讓我們的 [開啟舊檔] 對話方塊如 [圖 3] 所示。
[圖 3] 只顯示文字檔的 [開啟舊檔] 對話方塊 (按一下以放大影像)
接下來終於要顯示對話方塊了。這個步驟我們以 ShowDialog 方法來執行：
dlg.ShowDialog()
ShowDialog 方法會傳回一值，指出使用者是按了 [開啟舊檔] 來開啟所選的檔案，還是按了 [取消]，關閉對話方塊。如果是按 [取消]，我們就不必做任何動作。因此我們將 ShowDialog 的呼叫置於 If 陳述式當中，確保他們按了 [開啟舊檔] 之後再繼續進行：
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
沒錯，我們勾選的是 OK 屬性，而不是 Open 屬性。[開啟舊檔] 按鈕在幕後其實跟 [確定] 按鈕一樣 — 只不過顯示 [開啟舊檔] 顯得更有意義。
接著我們必須知道使用者從對話方塊選了哪個 (或哪些) 檔案。檔名是包含在 OpenFileDialog 物件的 FileNames 屬性當中，因此我們設定 For Each 迴圈，一一讀過該屬性所含的檔名。
For Each strName In dlg.FileNames
糟糕，忘了宣告 strName：
Dim strName As String
現在我們需要開啟每一個檔案，從這些檔案讀取。我們在 Visual Basic 所採取的方法是 Using 區塊：
Using sr As StreamReader = File.OpenText(strName)
VBScript 指令碼人員不會使用 Using 區塊，因為 VBScript 根本就沒有這個東西。Visual Basic 在管理系統資源方面，比起 VBScript 略勝一籌 (好吧，在許多方面其實都遠超過 VBScript 啦)。Using 陳述式最重要的工作是，在我們結束區塊時，確保系統資源皆已全部釋出。在本例中，我們只要確定別緊抓著檔案內容以及大型記憶體區塊不放就行了。
沒錯，聽起來好像有點複雜。不過，只要把它當作 Set 陳述式來看就行了。我們只要建立一個新物件 (在本例中是 StreamReader 物件) 的執行個體，然後把 File.OpenText 方法傳回的文字資料流指派給它。請注意，我們是把要開啟之檔案的名稱傳給 OpenText，這個檔案是來自目前正在重複執行的 FileNames 集合。
而 StreamReader 變數 sr 含有該檔案的內容。接下來需要另一個變數：
Dim strLine As String
這個變數是用來儲存剛剛開啟的檔案的第一行：
strLine = sr.ReadLine()
我們在 StreamReader 物件呼叫 ReadLine 方法，從檔案讀取第一行 (記住，StreamReader 物件含有我們檔案的內容)，然後再把這行文字儲存到變數 strLine 當中。
接著，只要在 ListBox 物件呼叫 Add 方法，將這一行加到清單方塊就行了：
ListBox1.Items.Add(strLine)
以這個例子來說，我們只需要用到文字檔的第一行 (不需要整篇文字內容) 來關閉 StreamReader，然後再關閉 Using 區塊：
sr.Close()
End Using
接下來，再執行一次迴圈尋找從 [開啟舊檔] 對話方塊選出的下一個檔案，直到讀完所有選取的檔案，並且將所有的文字行加到清單方塊為止。完成的程式碼如 [圖 4] 所示。
[圖 4] 完整的 ReadFiles 程式碼
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
  End Sub
End Class
我們說得沒錯吧，建立應用程式，不比建立指令碼難多少。
您可以按 F5 (或者按 [偵錯] 工具列上的 [開始偵錯] 按鈕)，來測試應用程式。當您按下該按鈕，然後在 [開啟舊檔] 對話方塊選取一或多個檔案之後，結果應該如 [圖 5] 所示。
[圖 5]顯示在清單方塊中的選定檔案的第一行
如果應用程式按照您的意思順利執行時，請從 [建置] 功能表選取 [建置 ReadFiles (或是您的專案名稱)]，建立一個名叫 ReadFiles.exe 的 .exe 檔，您可以像執行其他任何應用程式一樣來執行這個檔案，也可以把它發佈給您的使用者。
也許使用 [開啟舊檔] 對話方塊，不像搭特快車那麼快，不過當您想到從 Windows Vista 開始，就不能靠撰寫指令碼這麼做之後，撰寫簡單的應用程式也算是值得付出的小小代價啦。就像在高速公路上得付錢才能到目的地一樣：雖然有點麻煩，不過終究還是到得了您要去的地方。
使用 Visual Basic 還有一個優點，就是這個工具比 VBScript 更強大，而且還有一個好用的使用者介面，讓您建立應用程式起來更輕鬆；這就是它振奮人心的地方。系統管理員還會發現到 Visual Basic 能夠完成其他許多任務。
記住，改走一條新的收費路段，不必重新學習開車，只要習慣您前面的車子其實有在動就行了。同樣的，如果您懂 VBScript，那麼要改用 Visual Basic，也不必重頭學習全新的語言，只要習慣您能做的事情變多了就行了。
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
這個每月一次的挑戰不僅測試您的解謎功力，更要測試您的指令碼技巧。

2008 年 8 月：Scripting 字母表
在本月份的謎題中，您必須在藍色空格中插入 A 到 Z 的字母，來顯示一個與 Scripting 多少有點關聯的字。每個字母 (A 到 Z) 都只能用一次，而且這些字母不會按照字母順序顯示。插入的字母可以是該字的開頭、結尾，或是中間任何位置。比方說，在第一行插入字母 C，就得出 SCRIPT 這個字了：

答案是：
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：Scripting 字母表，2008 年 8 月

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


桌面檔案 Windows 部署服務 101
Wes Miller

目錄
Windows Server 2003 中的 WDS
Windows Server 2008 中的 WDS
作抉擇
考量因素
WDS 入門
擷取映像
擷取 101
映像移轉
自動安裝
上個月的專欄回顧了 Microsoft 以開機前執行環境 (PXE) 為基礎的部署工具的歷史。這個月，我將深入探索 Windows 部署服務 (WDS)，特別針對隨 Windows Server 2003 一起發行的版本，以及隨 Windows Server 2008 一同發行的更新版本進行討論。
之後，我將帶您動手操作 WDS。
把 WDS 想成是經過重寫的遠端安裝服務 (RIS) 再適合也不過了。雖然兩者共用一些主要元件，但其實 Windows Server® 2003 上的 WDS 版本有個傳統模式在功能上與 RIS 如出一轍，而以原生模式，以及以 50% 的混合模式執行的實際 WDS 基礎結構則是全新的。

Windows Server 2003 中的 WDS
WDS 是在 Windows Vista® 發行的同時提供的。之所以這麼做，是因為 Windows Vista 安裝已經使用 Windows® Imaging Format (WIM) 架構重新設計過，使得 RIS 無法部署 Windows Vista (也終將無法在 Windows Server 2008 部署)。之後 WDS 就被當做頻外 (out-of-band) 下載，提供給執行 Windows Server 2003 SP1 的客戶使用。RIS 在 SP2 中已完全被 WDS 取代。
您應該記住，因為 Windows Server 2003 中的 WDS 具備完整的回溯相容性，所以您在 Windows Server 2003 SP2 系統上安裝 WDS 時，不用移到原生模式。您可以繼續在傳統模式 — 在功能上是當作 RIS 伺服器執行 — 或混合模式中執行，以利將 WDS 或 RIS 初始化。
除了能夠部署 Windows Vista 和 Windows Server 2008 之外，在原生模式或半原生混合模式中執行的 WDS 還有其他幾項功能。它並不會利用我在上個月討論到的 Windows 核心模式安裝引擎和傳統安裝核心 (technet.microsoft.com/magazine/cc645015)，而是使用 Windows PE 作為它的開機預先安裝環境，它還會部署 WIM 式映像，而不是使用 RISetup 或 RIPrep 式安裝。這麼做可讓部署更快速、更簡單，也更可靠。
再者，由於 Windows PE 能夠顯示跟 Windows 完整安裝一樣的字元集，因此我在上個月提到的許多限制 (像是必須使用美國國家標準局 (ANSI) 為主的字元) 都沒了。
此外，WDS 也得到了幾項 RIS 嚴重缺乏的工具 — Microsoft® Management Console (MMC) 嵌入式管理單元來協助管理工作，以及廣泛的命令列設定工具提供遠遠超越 RIS 的設定功能。
由於傳統和混合兩種模式都允許部署 RISetup 和 RIPrep 式的 Windows 映像，因此有件事您應該要謹記在心。那就是 RIS 在過去為了最佳化磁碟上的映像儲存，使用了一個叫做 Single Instance Storag (SIS) 的元件。之後作為 Windows Storage Server 2003 一部分發行的 SIS，利用了稱為 Groveler 的服務，這項服務會在 RIS (和 WDS) 伺服器上的背景執行，尋找相同的檔案。如果找到相符的任何檔案大小和雜湊，SIS 就會儲存一個複本到自己的 SIS 公用存放區資料夾中，然後為它找到的每個原始版本建立 Hardlink。
SIS 是為了盡可能降低對處理器用量的衝擊並同時大幅節省儲存空間而設計的。它是個宏大的概念，最先是由 RIS 採納，之後廣泛用於 Windows Server 平台上。但是 SIS 已經不再用於 WDS 未來的版本。
因為 Windows Server 2003 上在原生模式中執行的 WDS — 在 Windows Server 2008 中一向是在原生模式中執行 — 利用 WIM 映像來進行安裝，所以它有自己的壓縮，更重要的是，它有自己的單一執行個體檔案儲存模型，而且它完全不使用 SIS。映像存放區會將 RIS 使用的儲存模型換成適用於 WDS 的全新 WIM 式設計。關於 SIS 其他詳細資訊，可在 go.microsoft.com/fwlink/?LinkId=120302 上找到。

Windows Server 2008 中的 WDS
在 Windows Server 2008 中，WDS 已同時變成 Windows Server 2003 中的功能超集和子集。它現在可以使用傳輸伺服器在獨立模式中透過多點傳送來部署映像，傳輸伺服器是一部全新的簡單式檔案傳輸通訊協定 (TFTP) 伺服器，不僅效能更佳、支援以可延伸韌體介面 (EFI) 為主的 x64 系統，更具備增強的安裝公制報告功能。這些我都會在下個月的專欄中討論。
您應該要注意 Windows Server 2003 中有個 WDS 的功能在 Windows Server 2008 已經停用 — 那就是傳統安裝支援。部署 RISetup/RIPrep 映像或使用傳統 RIS OS 選擇器來啟動安裝的功能已經不再提供。

作抉擇
自 Windows Server 2008 發行以來，我最常被問到的問題之一就是：「我應該使用哪個版本的 WDS 呢？」。答案要看您是否正在部署 Windows 的 Windows Vista 搶鮮版而定，如果是，則要看您是否已準備好從 RISetup 及/或 RIPrep 式映像轉換成明確使用 WIM 式安裝。
即便是在 Windows Server 2008 中，只要是在 WIM 映像內，WDS 都能夠將 Windows 完全部署回 Windows 2000 — 而且可以使用多點傳送來進行。因此，若是您現在正準備從 RIS 轉換成 WDS，並且考慮在基礎結構中採用 Windows Server 2008 — 而且您願意從 RIS 式移轉成 WDS 式映像的話 — 那麼移轉到 Windows Server 2008 中的 WDS 對您來說可能再合適也不過了。
您也可以在 Windows Server 2003 系統本身從 RIS 移轉到 WDS，基本上只要安裝 SP2，然後轉換成 WDS 式映像就行了。接下來，您就可以直接升級到 Windows Server 2008 WDS，然後開始使用。
不過，我不建議採用這種模型。因為對於 2008 前的許多 Windows Server 版本，Microsoft 都建議從 Windows Server 其中一個版本移轉到另一版本 (與就地升級相比之下)。
而且跟我之前提到的一樣，在您的基礎結構中考慮採用 x64 版本的 Windows Server 2008，可能比使用 x64 版本的 Windows Server 2003 還合理得多。如果您決定進行轉換，那麼執行 WDS 的伺服器對伺服器移轉，從 Windows Server 2003 移轉到 Windows Server 2008 不但相當容易，而且與就地升級比起來也可靠許多。

考量因素
以下是在處理 WDS 部署時應謹記在心的幾個重點。請注意，這些其實並不是 WDS 的新需求 — RIS 也有許多相同的考量因素 — 但無論您是建置單一的 WDS 伺服器或是整個基礎結構，都應該將它們列入考量。
權限 在管理 WDS 伺服器時，要牢記兩個主體項目。就跟對 RIS 一樣，您也必須在 Active Directory® 中授權 WDS 伺服器。但是您在樹系的根網域中必須是網域系統管理員，或是企業系統管理員，或者必須被委派適當的權限，才能這麼做。另外，您還必須是網域系統管理員才能管理 WDS 伺服器，而且在 WDS 伺服器本身也必須是系統管理員才行。
虛擬化 若是在 Microsoft Virtual PC 或 Virtual Servre 下虛擬化的 Windows Server 2003 或 Windows Server 2008 執行個體上執行，而且在安裝相同 Virtual PC 或 Virtual Server 上的用戶端電腦上通訊，則 PXE 剛開始開機的時候可能會發生競爭狀況，而使用戶端異常緩慢，甚至可能停頓。因此，建議您將用戶端或伺服器其中一個虛擬化就行了，不要兩者同時虛擬化 — 尤其是在相同的主系統上。我個人不建議將 WDS 伺服器虛擬化用於實際執行環境 — 這主要是因為下一個重點之故。
其他服務 WDS 就跟 RIS 一樣，不一定能與其他實際執行服務妥善互動。尤其我就看過在執行 RIS/WDS 的實際執行系統上，也同時執行 Microsoft Exchange Server、Systems Management Server (SMS) 和 System Center Configuration Manager (SCCM)，因而發生問題的案例。
一般來說，如果您將 WDS 用於實際執行環境中為數不少的用戶端，我建議您將它設為伺服器上唯一的角色。這對 WDS 並不罕見 — 您應該審慎考慮是否應該混合 Windows Server 產品的角色，並且在部署之前先行測試。
低延遲或高延遲連結 與 RIS 一樣，WDS 也不適合用於低頻寬連線或高延遲連線 (例如衛星連線)，不但 PXE 信號交換可能會出問題，下載映像也可能會慢到不行 (如果真的可以用的話)。

WDS 入門
更多 WDS 相關資訊

  • Windows Server 2003 中的 WDS 逐步指南 (英文)
  • Windows 部署服務逐步指南 (Windows Server 2008) (英文)
  • 部署和管理 Windows Server 2003 上的 WDS 更新 (英文)
  • Windows Server 2008 中的 Windows 部署服務說明文件 (英文)
  • 技術參考資料：Windows 部署服務 (Windows Server 2008) (英文)
開始時，您必須決定是要在 Windows Server 2003 上還是 Windows Server 2008 上使用 WDS。如果您使用的是 Windows Server 2003，我建議從 SP2 開始，而不要使用 SP1 和之前可在 Windows 自動化安裝套件 (WAIK) 中選擇下載的 WDS，因為 SP2 本身已包含 WDS，它在裡面是選用元件 (取代 RIS)。
無論您用的是哪一個版本的 Windows Server，都應該擴建伺服器系統。您應該使用至少能處理 100Mbps 或更快的高品質網路介面卡 (NIC)，而不要使用 NIC 小組，因為 WDS 的 PXE 基礎結構可能會產生問題。請注意，如果您使用的是 Windows Server 2008，可以在 Windows Server 2008 的 Server Core 或完整安裝上安裝 WDS。
WDS 在 Windows Server 2003 上是安裝成選用元件 (在之前是 RIS)。您可以在 OS 的安裝期間或之後透過執行 [新增/移除程式] | [新增/移除 Windows 元件] (或從命令列執行 sysocmgr.exe) 來安裝它。WDS 在 Windows Server 2008 中是安裝成角色，而且可以透過初始設定精靈 (按一下 [新增角色] | [下一步] | 然後選取 [Windows 部署服務])，透過伺服器管理員 (步驟跟初始設定精靈相同)，或是執行 ServerManagerCmd –install WDS 從命令列等方式來進行安裝。
WDS 安裝好之後，必須加以設定。您可以在 Windows [開始] 功能表下，前往 [系統管理工具]，並選取 [Windows 部署服務]。當 MMC 啟動時，請以滑鼠右鍵按一下伺服器，然後從功能表中選取 [設定伺服器]，以啟動設定精靈。
如果您是安裝在 Windows Server 2003 上，然後升級現有的 RIS 伺服器，應該要指定現有的 RemoteInstall 目錄，以便讓傳統安裝能夠升級至混合模式。對於這種情況，您應該確保 RemoteInstall 目錄並不是位在系統磁碟分割上，因為這樣會影響效能。
[圖 1] 顯示的是完成設定精靈之前，Windows Server 2008 上的 WDS 主控台。[圖 2] 顯示的是 Windows Server 2008 上 WDS 設定精靈的歡迎畫面。[圖 3] 則顯示 WDS 設定精靈的 PXE 設定步驟。在這個步驟中，您可以指定伺服器應該回應任何用戶端 (對於初始的擴建相當有用)，還是應該只回應已知的用戶端電腦 (亦即在 Active Directory 中已預先接移的電腦)，或是應該回應所有的用戶端 (而且是否應該選擇保留所有已知的用戶端，讓系統管理員能夠選擇進一步的動作)。
[圖 1] 已安裝但未設定的 WDS
[圖 2] WDS 設定精靈
[圖 3] 選擇 PXE 伺服器的回應原則
[圖 4] 顯示的是在 Windows Server 2008 上設定完整且 [內容] 頁處於開啟狀態的 WDS (但尚未安裝映像)。如果您使用的伺服器已經是動態主機設定通訊協定 (DHCP) 伺服器，請務必將 DHCP 選項 60 設為 PXEClient，並將 WDS 設為 [不要接聽連接埠 67]。這麼做可讓您的 WDS 伺服器在 PXE 探索程序期間跳過一個步驟 (跟我在上個月的專欄裡面討論到的一樣)。
[圖 4] Windows Server 2008 上設定完整的 WDS
精靈完成後，您就可以加入新映像了。您可以新增兩種類型的映像到以混合或原生模式執行的 WDS 伺服器。
  • 開機映像：這些是包含 Windows PE 2.x 的映像，一般是從 Windows Server 2008 或 Windows Vista SP1 安裝 DVD 複製而來的。請注意，如果您要使用多點傳送，應該使用 Windows Server 2008 的 \Sources\Boot.wim 檔案作為開機映像 (即使是部署 Windows Vista 或傳統作業系統也一樣)。開機映像一般包括 Windows PE、Windows Setup.exe 和其他相依性。
  • 安裝映像：安裝映像包括了 Windows OS 映像，通常是 Windows Vista 或 Windows Server 2008 的 \Sources\Install.wim 檔案。
新增預設開機映像與新增預設安裝映像的步驟幾乎一模一樣，都是在映像類型上按右鍵，然後選擇新增該類型的映像來開始每個程序。
如果是安裝映像，您必須先為映像群組指定名稱 (因為 Windows DVD 上的預設 WIM 包含了不只一種 OS 類型)，接著瀏覽至您要新增的適當 boot.wim 或 install.wim，再按一下 [開啟]。如果是安裝映像，接著則可以清除任何您不想新增到 WDS 伺服器的磁碟區映像 (OS 映像)。最後，您可以使用這些預設映像，透過 PXE 來安裝用戶端。

擷取映像
若要建立自訂 OS 映像，必須建立擷取映像 — 這是為了讓您將 Windows 系統擷取成 WIM 映像而設計的 Windows PE 映像。進行這個動作最簡單的方法，是使用您稍早安裝的 boot.wim 映像。
請先在所要的映像上按右鍵，再按一下 [建立擷取開機映像]。接著指定要用於映像的名稱和描述，再指定萬一在部署擷取映像時發生網路連線問題的話，要儲存 .wim 檔案本機複本的位置。接著再遵循精靈指示完成之後，按一下 [完成]。
接下來，請以滑鼠右鍵按一下 WDS MMC 中的 [開機映像] 資料夾，再按一下 [新增開機映像]。然後跟前面一樣，遵循精靈中的指示進行。完成時，就準備好擷取 Windows 安裝映像了。

擷取 101
當然啦，在擷取作業系統映像之前，必須先安裝 Windows，並確定它包含所有您所要的應用程式、自訂和更新。接下來就是在系統上執行 Sysprep，您可以只向利用 Sysprep 準備的系統擷取 Windows 安裝映像。除了必須指定有效的本機位置來儲存新映像 (以避免可能的損毀) 之外，還必須指定 *.wim 副檔名。
在設定好系統並複製正確的 sysprep.exe 版本到系統之後，必須遵守下列步驟：
  1. 從參考電腦上的命令提示，變更到 sysprep.exe 所在的目錄。
  2. 啟動 Sysprep (您也可以按兩下 sysprep.exe，以手動方式指定選項來啟動)，然後在執行 Windows Vista 或 Windows Server 2008 的電腦上，執行 sysprep /oobe /generalize /reboot 命令。在執行 Windows Vista 之前版本的電腦上，請執行 sysprep -mini –reseal –reboot。
  3. 當電腦重新啟動時，PXE 會將它開機 (程序可能會視您的用戶端系統而異)。
  4. 從開機功能表選取您的 WDS 擷取映像，然後按 [下一步]。
  5. 選取磁碟機，以及映像的名稱和描述。
  6. 如前所述，您只看得到經過 Sysprep 處理的系統。這是系統本身的設計，無法改變。
  7. 按一下 [瀏覽]，然後瀏覽至您要存放已擷取之安裝映像的本機資料夾。您選擇的位置可以是對應的網路磁碟機。
  8. 選取 [將映像上載到 WDS 伺服器]。
  9. 輸入 WDS 伺服器的名稱，然後按一下 [連線]。
  1. 從 [映像群組] 清單中，選取您要存放映像的映像群組，然後按一下 [完成]。
您現在就可以從 WDS 伺服器部署這個映像了。身為 RIS 老手的各位，可能已經注意到一件事 — 那就是我並沒有即時擷取這個 Windows 映像。因為 WDS 要求目前正在擷取的系統，必須處於離線狀態。
雖然 RIPrep 在 RIS 中能夠擷取線上系統 (事實上，這是必備條件)，但其實這樣的程序非常不牢靠。我相信您一定會發現 WDS 的擷取程序更加簡單，而且肯定更加強固。

映像移轉
如果您曾經用過 RIS，一定會有一些映像放著不用。雖然那些以 RISetup 為基礎 (指令碼式安裝) 的映像已經無用武之地了，不過，您還是可以將 RIPrep 映像移轉到 WDS WIM 式映像。事實上，WDS 甚至還能讓您透過 WDSUtil 來移轉映像 (下個月我會深入探討這個主題)。
除非您對某個相當珍惜的映像投入相當長的時間，否則通常我不會建議您這麼做。雖然程序運作起來沒什麼問題，但是我也聽過在轉換時曾經發生過一些錯誤 — 只要一發生錯誤，通常就得從頭建立映像。

自動安裝
用我之前的方法所建立的映像，其實也可以手動安裝。若要進行更自動化或完全自動化的安裝，必須使用兩個自動安裝檔案。WDS 本身需要一個回應檔 (unattend.xml，存放在您 WDS 伺服器上的 \RemoteInstall\WDSClientUnattend 目錄下) 來自動化 WDS 安裝程序。第二個檔案則是真正的映像自動安裝檔案。如果您所用的是 Windows Vista 或之後的版本，這個檔案是 unattend.xml 檔。如果是舊版的 Windows 映像，則是 sysprep.inf 檔，存放在 $OEM$ 目錄結構中或每個映像目錄的 \Unattend 下。WDS 完成之後，就會使用這個檔案來自動化實際的 Windows 安裝作業。
若要建立 WDS 自動安裝檔案，請使用 WAIK 為 WDS 建立 unattend.xml 檔案。請將這個檔案複製到 RemoteInstall 目錄或子目錄，然後以滑鼠右鍵按一下您要使用自動安裝檔案的安裝映像，再按一下 [內容]。接著在 [用戶端] 索引標籤下，選取 [啟用自動安裝模式]，並提供稍早指定的 unattend.xml 檔案。
若要為 Windows Vista 之前的映像建立映像自動安裝檔案，請將 sysprep.inf 檔案複製到映像的 $OEM$ 目錄 — 例如，D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf。如果是 Windows Vista 映像，請指定您要建立關聯的映像，先按一下 [內容]，然後在 [一般] 索引標籤下，按一下 [允許在自動安裝模式下安裝映像]。接著再指定要用於安裝的 unattend.xml 檔。
到目前為止我們已經完成一大半了，所以看完這篇專欄之後，您應該就可以開始著手使用 WDS 了。下個月我會進一步探討 WDSUtil、映像存放區和多點傳送等相關細節。接下來，我將深入探索以 WDS 為基礎建置自訂部署方案的方法和理由 (也許您會考慮採用)，為本系列畫下句點。在這之前，不妨瞧瞧本專欄隨附的「更多 WDS 相關資訊」資訊看板。

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


安全性監控 密碼與信用卡 - 第二篇
Jesper M. Johansson

目錄
虛擬多重要素登入程序
瀏覽器增益集的問題
驗證者絕不能變
降級為較不安全的密碼
略過虛擬多重要素登入
受侵密碼的問題
一些好處
以視覺指標誤導使用者
要開還是不開
提供安全通訊
攸關隱私
歡迎閱讀我三篇一系列文章的第二篇，本系列探討的是 IT 產業在安全性問題上如何混淆消費者，而不是幫助消費者。在 2008 年 7 月號的《TechNet Magazine》，我討論到無用和錯誤的安全性建議，以及令人困惑的登入工作流程 (如果您還沒讀第一篇，可以在
technet.microsoft.com/magazine/cc626076 上找到)。我提出論點指出，甚為普遍卻不當的安全性建議，以及不良的登入工作流程，如何混淆消費者以及阻礙他們保護個人資訊。
在本期內容中，我將繼續探討更多採自消費者安全性世界的實例。本系列的最後一篇將在下一期的《TechNet Magazine》發表，當中將包括安全性專家世界的「召集令」。

虛擬多重要素登入程序
聯邦金融機構檢查委員會 (Federal Financial Institutions Examination Council，FFIEC) 在 2005 年 10 月發佈了它的「在網際銀行的環境內進行驗證」指導方針 (請參閱 www.ffiec.gov/press/pr101205.htm)。履行的期限只有 14 個月，而美國金融機構馬上爭先恐後地想要知道如何達成這些新指標。
大多數的機構都無法在這段期限內完成。當中許多最後達成指標要求的機構都是為了遵守而遵守。換句話說，機構所採取的措施並沒有讓客戶更加安全 (它們不過是「安全性迷思」的作法)。這些無用的解決方案當中一些最有趣的例子，當屬實際上不是多重要素而試圖建立多重要素驗證的作法。
譬如說，試想一下使用者在打密碼時測量打字韻律的技術。這種方案用在網站上會呈現一個登入對話方塊，看起來就跟舊式登入對話方塊一模一樣。不過，這個對話方塊現在是個 Adobe Flash 物件。
Flash 物件會記錄使用者的打字韻律，包括特性，例如按住按鍵的時間，以及按下不同按鍵之間花多久的時間等。這項資料會隨著密碼一同提交到網站，並在該處與存放的值相比較。只要打字韻律的資料符合存放資料的特定變化，而且密碼也相符的話，就會接受登入。這大致上的構想是允許網站不用在用戶端上安裝協力廠商硬體，便可使用虛擬生物測量驗證方法。
我將把這稱為虛擬多重要素驗證。它並不是真正的多重要素驗證，真正的多重要素驗證會測量下列兩個或以上的標準要素：
  • 使用者持有的東西 (例如智慧卡)
  • 使用者知道的東西 (例如密碼)
  • 使用者的身分 (例如指紋)
虛擬多重要素驗證在驗證程序中實際上並不包括多重要素，而是只針對單一要素 — 密碼 — 讀取多重參數，接著再使用那些額外的參數來推論使用者的身分。
虛擬多重要素驗證所採用的技術受許多缺點之苦。這些缺點加總起來，讓這項技術在解決它自稱能解決的安全性問題方面相當沒有效率。

瀏覽器增益集的問題
虛擬多重要素驗證系統是仰賴瀏覽器增益集來提供它們所需的精密用戶端處理功能。想當然爾，所有軟體都有錯誤，而當中有些錯誤會導致漏洞。當軟體無法更新，而且使用者不確定更新到底有沒有安裝時，這些漏洞就會演變成真正的問題。
軟體既難更新，又不提供使用者充裕的資訊確定安裝的版本是不是最新的，其實都要怪瀏覽器增益集。這使得使用者必須向網際網路公開一小部分在其他情況下可能不需要的軟體。
在有些情況下，要保持增益集的最新狀態，必須經常造訪增益集網站以取得更新。想也知道，大部分使用者不太可能會這麼做。單純為了提供安全性功能而要求使用者向網際網路公開額外且不相關的軟體，這樣的系統都應該慎重加以考量。

驗證者絕不能變
「您的身分」要素有個特徵 (甚至可能是缺點)，這個特徵並不會影響其他兩個要素。雖然您可以變更密碼 (您所知的東西) 並製造新的安全性權杖 (您所有的東西)，但是您可以使用的生物測量驗證者其實相當有限。例如，一般來說，您終生只能取得十個指紋。而且如果您在意外當中失去其中一個手指頭，通常無法加以取代。
現在試想一下這要怎麼應用於虛擬多重要素登入範例。作為另一個要素的一部分而收集的測量資料，要替換或修改並不容易。當然，當密碼變更時，使用者輸入密碼的方式也會跟著改變，但是他在鍵盤上按下按鍵的方式並不會變，而這正是這套方法的基礎。若是這些測量資料遭到入侵，就有可能可以合成它們。攻擊者至少都可以擷取這些測量資料，並重複執行。

降級為較不安全的密碼
使用長密碼，並經常更換密碼是個不錯的主意。另外，如我在這一系列的第一篇中提到的，把密碼記錄下來也是恰當的作法 (與一些建議恰恰相反) — 當然是以安全的方式記錄。不過，這些作法跟您用手輸入密碼並沒有關係。要輸入長密碼是比較困難，但是記錄起來的密碼，因為您能進行複製和剪貼，所以要來得實用得多。追蹤上百個或以上的密碼，最佳的辦法之一就是使用軟體公用程式，例如 Password Safe (網址是 sourceforge.net/projects/passwordsafe)。有了這樣的工具，您就可以產生完全隨機的密碼，以加密的方式儲存它們，然後把它們直接貼到登入對話方塊中。事實上，透過這樣的工具，您甚至不用知道密碼是什麼。
但是難處在於：除非使用者輸入密碼，否則您無法測量打字韻律。而且如果您必須將密碼輸入一個物件來測量打字韻律的話，這種管理密碼的方法便會開始瓦解。要正確輸入含 15 個完全隨機字元的密碼，並不是件易事。也因此使用者在面臨這樣的系統時，一般會選擇簡化他們的密碼。但是，含 15 個完全隨機字元的密碼本身跟搭配虛擬多重要素驗證系統的短密碼比起來，要安全許多。
實際上，單獨實作虛擬多重要素驗證會強迫使用者使用較不安全的密碼。不幸的是，您待會兒就會看到，順應採用適當密碼管理方法的使用者，基本上等於是貶損了虛擬多重要素驗證系統所提供的任何價值。

略過虛擬多重要素登入
即使網站真的實作虛擬多重要素驗證，它還是必須支援一種方法來略過虛擬多重要素系統。首先，能要求它所有使用者安裝「第四方」技術以便存取網站的網站寥寥無幾。有部分使用者 (比方說，一些《TechNet Magazine》的作者) 肯定不會安裝這類的軟體。
其次，打字韻律可能基於很多理由而發生變更，因此網站也必須順應這樣的變動。例如，像使用者的手扭到了，使她的打字韻律暫時有所改變。如果網站分析她的韻律，然後認為她是別人試圖冒用使用者憑證登入的話，她要怎麼存取網站呢？如果傷害是永久的，使用者可重設已儲存的韻律值。但如果只是暫時受傷，使用者可能不想重設已儲存的值，因為她認為她的打字韻律不久後大概就能恢復之前的樣子了。
最後，並非所有使用者都有能力使用虛擬多重要素驗證系統。舉例來說，透過語音辨識介面與電腦互動的殘障人士可能無法填寫對話方塊，要視電腦是否允許以程式的方式輸入而定。在這種情況下，法律可能會要求採用替代的系統來配合殘障使用者。
配合所有這些案例最簡單且最直接的方式，是同時支援以標準密碼為基礎的驗證。

受侵密碼的問題
虛擬多重要素驗證系統旨在解決與以密碼為主的驗證相關的各種問題。然而，這些系統無法徹底一一處理密碼可能受侵的各種方式。仰賴以密碼為主的驗證的系統可能受到入侵的方法有五大種，所謂「受到入侵」是指攻擊者已獲取並使用其他使用者的密碼：
  • 密碼猜測
  • 按鍵輸入記錄器
  • 網路釣魚攻擊
  • 詢問使用者
  • 入侵儲存密碼或密碼雜湊的任何系統
密碼猜測在罪犯間已不再是特別常見的攻擊方法，而且它與按鍵輸入記錄器和網路釣魚相形之下已大為失色。虛擬多重要素驗證也不能完全緩和密碼猜測。傳統的密碼猜測方法不太可能用來破解虛擬多重要素驗證系統，畢竟攻擊者除了必須猜測密碼之外，還得猜測打字韻律。雖然理論上合成打字韻律是可行的，但這麼做幾乎是沒有必要，因為實際的資料通常透過網路釣魚攻擊或按鍵輸入記錄器就可以擷取得到。此外，若是系統也提供標準僅輸入密碼的登入介面，攻擊者也能使用該系統來猜測密碼。
另外，使用強式密碼其實就足以抵擋密碼猜測攻擊。如果我們可以教導使用者使用更強式的密碼，也許再加上工具的協助，那麼虛擬多重要素驗證就沒有存在的意義了 (相反地，一般與虛擬多重要素系統搭配使用的較簡單的密碼，反而讓密碼猜測更有機可乘)。因此，如果舒緩密碼猜測真有價值可言的話，也只有在實作不支援僅需密碼的登入才有附加價值。而我在前文有指出，這幾乎是不可能的。換句話說，如果使用者在有虛擬多重要素驗證系統時使用較脆弱的密碼，密碼猜測可能會再次變成有效的攻擊，虛擬多重要素驗證反而不會提高安全性，而是降低安全性。這方面的疑問需要進行更深入的研究。
虛擬多重要素驗證也無法解決按鍵輸入記錄器的問題。我不知道當今普遍使用的按鍵輸入記錄器有哪個可擷取打字韻律，但這並不表示它就不存在。按鍵輸入記錄器是位於鍵盤和電腦 (或是擷取按鍵輸入的軟體) 之間的硬體。無論如何，記錄器都可以完整存取虛擬多重要素驗證方案所使用的全部資料。
事實上，因為驗證方案是在使用者模式中執行，而按鍵輸入記錄器遠遠位於其下，它甚至可以存取更多資料。鍵盤與用於擷取密碼的 Web 物件之間若無信任的路徑，要預防這類的入侵簡直是不可能的。如果虛擬多重要素驗證方案變得夠普及的話，建立這樣的按鍵輸入記錄器就大有人在。
同樣地，虛擬多重要素驗證也無法擊敗網路釣魚攻擊。與其使用假的登入畫面，攻擊者可以改用 Flash 物件來擷取密碼，以及打字韻律。
沒錯，如果攻擊者唯一採取的手段是提供使用者密碼，那麼虛擬多重要素驗證在這些案例下是有幫助的。例如，要向使用者取得密碼，最簡單的方法是詢問使用者。誇張的是，經過證明這竟然是最有效的手段，無論是當面詢問、透過電話，或是透過網路釣魚的訊息都一樣。
不用說，比起來，要向使用者取得他的打字韻律，較不切實際得多。同樣地，如果公司的密碼資料庫遭到入侵，攻擊者很可能只能存取密碼。但再次強調，要舒緩這些攻擊，也要系統不提供任何僅需標準密碼的驗證才行得通。
我也應該指明，如果密碼資料庫本身事實上已遭入侵，表示攻擊者入侵系統的程度可能遠比光用單一或甚至許多一般使用者帳戶密碼入侵系統要來得深層。因此，試圖舒緩持有密碼資料庫的攻擊者可能採取的行動，其實沒什麼效用。

一些好處
老實說，還是有幾個虛擬多重要素驗證可以幫忙解決的問題 (假設系統沒有提供任何僅需標準密碼登入選項的話)。比方說，它可用來防止密碼共用。不過，對於多名使用者可合法共用帳戶的系統來說，例如綜合銀行帳戶，這可能是個缺點。
此外，如果使用者的打字韻律不符，建構適當的互動式登入對話方塊 (而不是網站登入) 還是可以強制她完成額外的驗證步驟。這可提供額外的安全性，在高度機密的環境中防止帳戶受侵。

以視覺指標誤導使用者
最能混淆使用者視聽的方法之一，就是提供錯誤的安全性建議。最常見的大概要算在網頁上顯示鎖的圖像，如 [圖 1] 所示。這個網頁甚至還在鎖上顯示「保全」字樣。
[圖 1] 誤用鎖圖示的範例，這是令人擔憂的趨勢 (按一下以放大影像)
您肯定都知道，光在網頁上放個鎖圖像和「保全」字樣，並不表示網頁就是安全的。但這種做法已經普遍到令人不安的地步，連最具名聲且最受歡迎的網站也在此列。結果使得許多使用者都被訓練成在網頁的內文尋找這些視覺安全線索，而不是查看這些線索具備真正意含的地方：也就是位址列 (W3C Web 安全性內容 Wiki 有記載這個問題，相關資訊可自 w3.org/2006/WSC/wiki/PadlockIconMisuse 取得)。
不幸的是，這類的誤用範例不勝枚舉。相關研究指出，即使憑證很明顯，使用者還是無法識別出惡意網站 (請參閱 www.usablesecurity.org/papers/jackson.pdf)。重點在於，即使沒有真品可比對，也要具備輕鬆分辨真假的能力。這需要一點技巧，但網頁上誤導的安全性視覺指標，妨礙了這項技巧的發展，因為使用者都受到錯誤資訊的吸引了。
[圖 2] 顯示了這個問題特別惱人的變形。在本例中，顯示資訊的網頁實際上並不安全。如果您看一下位址列，會看到「http」代表通訊協定。這個網站使用的是相當常見的最佳化作法 — 它並沒有加密包含登入表單的網頁，而只加密表單提交。只要您認為「安全」就是「加密」的話，那麼就如同網頁所指出，登入就是安全的。然而 — 而且這點非常重要 — 使用者在憑證送出之前，完全沒有辦法確認它們送達的目的地！網站要等到表單提交之後，才會向使用者顯示驗證網站的認證。這就跟玩信任遊戲一樣，您先往後倒，然後假定您背後的人會接住您。如果等到表單提交，可能早已傷痕累累了。
[圖 2] 不安全網頁上的安全性視覺指標 (按一下以放大影像)
安全通訊端層 (SSL) 是在 HTTPS 中提供安全性的通訊協定，它有兩大重要目的。第一，它會向使用者驗證伺服器。第二，它會提供一個簡單的機制來交涉工作階段加密金鑰，用於用戶端和伺服器之間。
雖然只有實際的表單提交會進行加密，但第一個也是最重要的目標並未就此達成。採用這種最佳化的網站，只是使用 SSL 作為交涉金鑰的一種方法。諷刺的是，它們其實只要採用標準金鑰交涉通訊協定就可以達成同樣的目的，藉此避免 SSL 的成本和額外負荷。
[圖 2] 中所示的網站並不罕見。許多網站都只針對表單提交，而不是表單本身提供 SSL 保護。不過，這個特定的網站示範了更令人困擾的特徵。如果您在位址列中輸入 https://www.<site>.com (請留意安全的 https 指標)，該網站會將您重新導向到非 SSL 版本的網站！即便您嘗試在傳送憑證到網站之前先審查認證，網站還是會拒絕顯示認證。
雖然並非所有的網站都這麼壞，但有很多都是如此。而且在美國有兩大信用卡發行商更是不在話下。事實上，我所用的三大信用卡公司當中，只有美國運通在登入表單上有提供認證。美國運通甚至還將 HTTP 要求重新導向到 HTTPS，真是太厲害了！
關於無意義的安全性視覺指標，以及登入表單上缺乏認證，最後值得一提的是，您可能不清楚網站為什麼要這麼做。理由很簡單，是經濟方面的考量。呈現認證需要加密網頁，而加密網頁會產生額外的處理負荷，額外的處理負荷表示需要有更多的電腦來處理相同的負載，而更多電腦要花更多的錢。不幸的是，當必須在保護客戶隱私與增加利潤之間作抉擇時，許多組織都選擇增加利潤。

要開還是不開
我最近收到了一封健保公司寄來的電子郵件讓我有點吃驚。過去 10 年來有用過電腦的人都知道，他們不應該打開來路不明的電子郵件附件。所以想想看當我收到如 [圖 3] 所示的訊息時有多驚訝。
[圖 3] 包含「安全附件」的電子郵件訊息 (按一下以放大影像)
很顯然地，我在健保公司的網站上提出一個問題 (可疑的信件抵達時，我早已忘得一乾二淨)，而這正是這家公司回應的方式。剛開始我以為這是高明的網路釣魚陰謀，直到我發現這是合法的信件時，才開始毛骨悚然。
最先的指示是按兩下附件，開始解密訊息。大部分的安全性社群和 IT 系統管理員，在過去 10 年來一直努力教導大眾不要按兩下開啟附件。然後有這麼一家公司 (順帶一提，我的健保提供者並不是唯一使用這套方法的公司) 進來說，為了我的安全，我必須按一下附件。這要使用者作何反應？他因此學到或忘卻了什麼行為？
隨後，我使用 Microsoft® Office Outlook® 2007 中的預覽功能來查看訊息。如您在 [圖 4] 中所見，Outlook 認為這封郵件可能有害，並警告我不要打開它！
[圖 4] Outlook 2007 認為安全文件有害 (按一下以放大影像)
健保公司違反了世界上最受歡迎的電子郵件用戶端所使用的最基本安全性檢查，實在很諷刺，也很可悲。想到這家公司連在 Outlook 中測試它的新安全性方案都懶了，我不得不質疑它還會做什麼來保護我的私密資訊。或者，更直言不諱些，這家公司不知道為了避免因未充分保護客戶隱私而遭到控告，還實作了哪些其他解決方案？這跟金融機構執行的安全性迷思沒什麼兩樣。在本例中，我認為避免被控是此解決方案的主要目標 — 而不是真正保護客戶。
我想要看看附件到底是什麼。結果是 ActiveX® 控制項物件。為了查看附件，我必須在 Internet Explorer® 中開啟它，然後安裝該物件。我看到了 [圖 5] 中所示的擔保畫面。如您所見，設計人員大費周章地讓訊息看起來像一般的信封，上面甚至還有個戳記，宣稱信封是受信任的。
[圖 5] 顯示一個含「信任」戳記的信封的安全文件 (按一下以放大影像)
這種技術令人擔憂的理由有很多。首先，它在使用者身上強化了一種非常不當的行為：開啟來路不明的附件。其次，在實際的郵件中，它提供了非常不良的指引，將系統設定成永遠不提示就開啟附件。第三，電腦上顯示的衝突訊息中，電子郵件說它是可信任的，而 Outlook 則不這麼認為，使得郵件看起來非常可疑。最後，實際的附件包含了無意義的安全性視覺指標，來說服使用者它實際上是可信任的。如果使用者學會信任這類的郵件，假以時日，使用者很快就會信任具備類似外觀的惡意郵件。

提供安全通訊
沒錯，這項技術聲稱要解決的問題，確實是非常重要。以信任的方式與客戶溝通並不容易。但這個特定的解決方案其實過度工程化了。它很可能混淆客戶，因而可能產生反效果：使得客戶的系統變得危機四伏。
較為妥善工程化的網站現在則採用「訊息中心」。在這種設計下，當公司需要與客戶溝通時，它會傳送一封電子郵件表明用意：「您在訊息中心有封郵件，請前往我們的網站，登入後按一下 [訊息中心] 連結來查看訊息。」若公司使用安全多用途網際網路郵件延伸 (S/MIME) 來簽署所有面向客戶的電子郵件訊息，讓使用者可以驗證來源的話更好。如果訊息在電子郵件內不包括任何「請按一下此連結」的項目的話，又多加一分。使用者應該用手輸入公司的 URL，以確保她是要前往預期的網站。
有了訊息中心和經過簽署的訊息，公司便可以打造信任的管道與客戶溝通。客戶在訊息工作流程期間看到的一切都會經過驗證，而且公司也不會提倡不良的安全性作法。

攸關隱私
到目前為止，我利用了本系列的前兩篇來說明安全性專家其實是在幫使用者倒忙。維護安全性是我們的責任，但許多決策和實作的解決方案都讓使用者不知所措，教導他們做出不當的決策，並給他們一種錯誤的安全感。我們不應該以這些相衝突的想法，讓使用者無所適從。
我之前有提到，對於主流使用者來說，安全性只不過是保護密碼和信用卡號碼。他們希望技術除了可行之外，也值得信任。可惜，他們必須做決定，而確定他們所做的是明智的決策，正是我們的責任。
在本系列的最後一篇，我將探討一些供消費者使用的最重要的技術，如何令人大失所望。我也會公佈我的召集令。所以，敬請期待 2008 年 9 月期的《安全性監控》專欄。

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


永續型運算 過濾不實環保
Dave Ohara

目錄
數據的必要性
測量能源使用情形
功率因數
在生產環境中測量
Microsoft 企業工程中心
總結
標榜環保、節能、高效率來行銷的產品與解決方案不可勝數。所有這些行銷手法在市場上所造成的混淆，使得環保商品真假難辨。即使評估過各種產品的規格，IT 專業人員仍然難以 (甚至無法)
判斷在環境因素有重大影響時，應該採用哪些設備。產品展示總是以能夠節約大量能源為主打，讓您以為投資報酬率 (ROI) 是升級的好理由。畢竟，節能表示能降低整體擁有成本 (TCO)。
各行各業流行將所有產品標示為環保並利用目前大眾對環保解決方案的興趣，使得「不實環保」一詞應時而生，用來形容過度吹噓環保效益的行為。那麼，節能的真相為何？不像是自家換裝一顆省電燈泡一樣單純，節能的真相無法一言以蔽之。
隨著永續型 IT 事業越來越引人注目，同時 IT 環保設備的市場逐漸擴大，許多組織及個人都迫不及待部署節約能源的膝上型電腦、桌上型電腦及伺服器，並使用虛擬化來減少能源耗用。但卻很少有組織實行能源稽核來確定這些採購行為究竟帶來多少效益。
以理想的情況來說，最好能在生產環境中主動進行測量，但是這麼做的成本很高。若您尚未準備好測量實際生產環境，您還是可以在作業流程的初期執行能源稽核，也就是在效能與評估實驗室中進行 (大部分的公司都設有某種實驗室或小組，負責在實際採購之前先測試和評估設備)。您可以在實驗室中將能源效益也加入測試條件中，然後將這些結果列入採購決定的考量中，而不是依賴製造商單方面提供的數值。因此進行測試時，建立自己的裝置耗電量資料庫。如此一來，您就可以忽略這些不實環保的口號，自行判斷何者真正有效。
當然，我必須提醒您，如果您希望了解在實際工作負荷下操作時的精確數據，就必須在生產環境中監測。您越早開始監測生產環境，對您的組織及營運就越有利。長遠看來，這項作業對於成功有關鍵性的影響。

數據的必要性
在理想情況下，應該執行獨立測試來評估硬體裝置在實際使用者工作量下的每瓦效能。但是業界在開發及部署這類測試方面，仍處於早期階段。而目前市面上的測試標準，例如 SPEC Power 基準測試，尚未成熟。這些能源測試一旦完備之後的表現如何，仍有待觀察。但是任何測試都一樣，製造商會從中學習如何修改產品來獲得最佳的測試結果。
老練的 IT 專家已經懂得質疑測試實驗室主導的測試結果。正如車廠一定是派遣它們最棒的車款進行道路試驗，IT 廠商也一定會提交最高效率的設備組態進行能源測試。
試想一下，使用虛擬化測試來比較一組過度佈建又完全沒有執行伺服器整併的伺服器，來展現虛擬化的效益。廠商故意不提節能計劃 (像是虛擬化) 可能造成反效果等這類問題。基本上，這意謂著能源效率降低成本，使得需求增加，此時反而提高能源使用量。每當您看到標榜全效節能的解決方案 (例如虛擬化)，就應該心存懷疑。您確實需要觀察各種產品搭配使用的情形，並留意使用一段時間後的漣漪作用。
那麼，您要如何為公司找到正確的方向？您會看到很多顧問都已經準備好提供收費的評估服務。但是這麼做有一些重大缺點。您真的希望將提高效率的專業工作交給組織外部的人員嗎？既然顧問想要拿到長期合約並讓客戶依賴他的服務，您還放心委託顧問嗎？
您可以將這項工作改變成一項多人參與的大型計劃，藉此擬定環保永續發展策略。請避免草率地從環境中隨處開始測量。想法也許沒錯，但作法有欠考慮，因為這種舉動太過貿然。您必須了解能源耗用的源頭，以及從何處著手最有效。

測量能源使用情形
您必須以新思維來看待有效運作這件事。舉例來說，當服務中斷時，IT 專業人員就知道硬體停止運作了。但若是從耗電量的角度來看，要如何得知硬體的運作不佳？可能無從得知，因為大多數的組織都缺乏建置能源效率基準所需的資料。
您要如何取得這些數據？有些人建議由專職的能源總管負責。但是這麼做需要某人能夠確定公司組織結構的方向，而且具備解決電源問題的技能。更簡單可行的方法是在效能實驗室的現有職能中加入能源測量工具。
市場上有一系列的能源測量裝置。可惜目前還沒有專為 IT 效能實驗室提供的理想裝置。退而求其次，您可以選擇 Watts Up Pro。這個 USB 裝置可提供 120V 的線上供電測量。另一項裝置是 Smart-Watt，此網路耗電量裝置包含 100-240 電壓和 15-30 安培系列。Smart-Watt 裝置也提供溫度和濕度感應器來測量環境係數。另外還有工業用電分析裝置，像是 Extech Appliance Tester 380801 和 Fluke 345 Power Clamp。您應該很容易可以找到像這類符合您的實驗室測試需求的裝置。

功率因數
如果您對電量測量不太熟悉，就必須先了解功率因數的概念。交流電系統的功率因數是定義為實功 (Real Power) 對視在功率 (Apparent Power) 之比，並以 0 到 1 之間的數字表示。實功 (瓦數) 是電路執行工作的能量。視在功率 (VA) 是電路上電流和電壓的乘積。
您可能不清楚這個概念的重要性。看一下 [圖 1]，照片中是一個 Smart Works 的能源監視系統，用來比較膝上型電腦、燈泡與電容器的能源效率。燈泡有 50 瓦的電量和 50 VA，功率因數為 1.0。純電容負載的電容器有 2 瓦的電量和 193 VA，功率因數為 0.01。膝上型電腦的用電量是 22 瓦，但讀數是 48 VA，因此功率因數為 .47。膝上型電腦的功率因數低是因為缺乏效率的供電設計，而且可能是為了降低製造成本的結果。
[圖 1] 膝上型電腦、燈泡及電容器的耗電量 (按一下以放大影像)
廠商對於能源效率的興致高昂，因此已經開始設法在預期條件下提升電源供應的效能。比較一下現有設備與新設備的功率因數，可能會發現只要選擇電源供應更有效率和功率因數更高的解決方案，也許就能節省一些電量。

在生產環境中測量
效能實驗室中的測量結果目的在於預測生產環境中的效能。但是在生產環境中測量耗電量的問題出在，測量所有裝置所需投入的成本。不過有一個辦法可以減少在生產環境中測量用電的成本，就是根據配電裝置 (Power Distribution Unit，PDU) 進行測量，然後彙總數個設備讀數。[圖 2] 顯示的能源讀數範例是從同個單位上含有多個相同設備的 PDU 測得。每一伺服器的平均耗電量可以透過計算得出，因此這種測量方式能提供生產環境的耗電量數據。
[圖 2] 根據配電裝置進行測量 (按一下以放大影像)
測量過每個設備後，應該將用電資料整合至您的設定管理資料庫中。如果這麼做太困難，您可以建立自己的資料庫，或者至少使用 Excel® 試算表來列出裝置與其用電量。收集到更多裝置的數據之後，您就可以預估其他裝置的用電量，進而建立完整的電容量計算。請記住，新的節能伺服器在閒置時會耗用在尖峰時段時一半以下的電量。如果您有老舊伺服器正在執行過時的解決方案，那麼這些舊伺服器即使在閒置時也會耗用大量的電力。從這些舊伺服器著手是重獲收回電容量最簡單的方法。
若要繼續進行節能的工作，下一步就是計算在資料中心內每一機架的用電。您也必須在改變環境時，確實了解您的電源和冷卻能力。經過一段時間後，您會開始根據電力需求而不只是所佔空間來審視您的設備。空間的概念很簡單 — 這是靜態和視覺上的概念。IT 專業人員可以輕鬆討論 1U、2U 及 4U 伺服器，但是一講到 200 瓦伺服器對 450 瓦伺服器，您會發現同樣的一批人就無法暢所欲言了。這是討論 IT 設備一種全新的語言，在今日的資料中心中顯而易見。許多組織擁有大量空間可容納更多設備，但是卻已經達到電容量上限。

Microsoft 企業工程中心
Microsoft 企業工程中心 (EEC) 最近為中心內的設施增加了電力測量功能。EEC (microsoft.com/windowsserver/evaluation/eec/default.mspx) 座落在華盛頓州雷德蒙的 Microsoft 公司園區中，是專門處理高複雜度運算環境的尖端科技試驗場。
中心裡包含價值四千萬美元以上的硬體及網路設備 (見 [圖 3])，EEC 足以重現最複雜的真實企業生產環境。這個團體與許多頂尖的網路、存放裝置及用戶端/伺服器解決方案提供者合作，創造出尖端技術與舊平台混合的環境。目標是為了確保每次測試都能準確地反映出客戶當前的環境。中心內正在開發的最新服務是報告解決方案的能源耗量，以便提供每瓦效能的基準。
[圖 3] EEC 實驗室中眾多機架的其中一排 (按一下以放大影像)
過去幾年來，EEC 見到許多資料中心操作員耗盡設備的電力和冷卻能力。尖端設備的功率密度往往比較高，對設施造成的壓力也更重。EEC 人員最先了解到升級電力和冷卻基礎結構所需的成本與時間。因此為了提高操作效率和節省成本，EEC 增添了測量每一裝置用電量的功能。
EEC 所用的部分工具及設備在本文編寫時尚未問世。由於這是全新的解決方案，EEC 將繼續開發更完備的技術，並與客戶、廠商及 Microsoft 開發小組共同合作。EEC 與客戶分享 EEC 開發的方法以取得初步回饋，讓客戶能夠建立自己的基準。
別以為測試結果很理所當然。EEC 分享了在 EEC 效能實驗室中使用能源監測功能時，所觀察到的一些有趣結果：
  1. 關閉裝置所減少的耗電量不見得有您預期的那麼多 (見 [圖 4])。在關於伺服器硬體的一個案例中，EEC 發現裝置在關機但插頭仍插上的情況下，實際上會耗用 100 瓦。這個結果讓人大感意外，EEC 反覆檢查設定很多次。最後，EEC 使用紅外線溫度計來測量插頭與插座的溫度，然後確認裝置的確在關機時耗用 100 瓦的電力。
  2. 軟體也可能對用電量產生巨大的影響。在完全相同的網路交換機上並使用一模一樣的硬體與 BIOS 組態，執行不同網路軟體會呈現出相差 21 % 的用電量。啟用比較多處理程序與功能的高階解決方案 (例如安全性與監視工具) 往往比低階解決方案耗用更多能源。
  3. 在虛擬化案例中，EEC 測量了用電量與 I/O 使用率及 CPU 使用率，以確定特定硬體的每瓦效能何時最高。EEC 發現如果只注重 CPU 使用率，將導致實體機器上載入太多虛擬機器，實際上反而降低整體的每瓦效能。
  4. 如您所料，密度較高的裝置會發生比較多電力和冷卻問題。在部署高密度系統時，應該要盡早諮詢您的電力和冷卻設施人員。如果您知道環境內的電力吃緊，那麼使用這些本身在生產環境中具有電源監視裝置的裝置，可能是不錯的選擇。
  5. 雙電源供應器比單一電源供應器耗用的電源高出許多。
  6. 表面上相同且組態設定一樣的硬體出現截然不同的用電量。差異之大，使得 EEC 人員不得不重複檢查硬體以確保兩者的設定真得一模一樣。
  7. 產品標示上的瓦額定功率並非實際的耗電量，而是電源供應器的額定容量。
  8. 為了獲得知識和比較資料，維護每個裝置與子元件的能源耗量測試及結果的資料庫很重要。
  9. 等量 RAM 的組態設定不同，所耗用的能源量也不同。較少的 DIMM 通常耗用的能源較少 — 例如 4 x 2GB DIMM 對 8 x 1GB DIMM。但有時候較少的 DIMM 也可能耗用更多能源。
[圖 4] 開機與關機的用電量比較 (按一下以放大影像)

總結
經由在效能實驗室中增加測量用電量的功能，您可以開始累積關於每一裝置用電量的資料庫，並輸入實際負載的精確數據。當您部署這些解決方案時，應該要以封閉迴路回饋來稽核結果，以確認效能實驗室測試結果的準確性。正如 EEC 在執行本身的測量測試時的意外發現，您可以注意一些很有趣的細節，藉此協助您過濾掉不實環保並發掘真相。
這套在效能實驗室中測量的方法將影響整個市場，讓業界開始辨別什麼才最節能。接著，製造商就必須提供針對他們的節能訴求更準確的參考資料。同樣地，IT 專業人員在評估採購條件時，也會開始討論每一裝置的瓦數。這些作法必須變成例行作業，尤其是那些購買大量伺服器的公司。不過，您現在就可以率先將能源視為寶貴的 IT 資源。
保持資料中心涼爽
資料中心冷卻能力對於降低能源耗量有潛在的強大威力。資料中心產生的熱量，以及為了冷卻硬體所用的能源，往往多到令人吃驚。但如果您想要成功管理冷卻系統、解決問題和開發更有效率的冷卻解決方案，就需要運用溫度監測解決方案。參考一下 Microsoft 資料中心使用的解決方案。
Microsoft Research 為資料中心建置一個溫度感應器網路，可提升溫度控制，也有助於評估各種冷卻增強功能。舉例來說，某個 Microsoft 資料中心評估走道末端風幕機來促進冷熱空氣分離。安裝風幕機之後，某些伺服器開始發出過熱警報。當然，作業工程師增加了冷卻系統的氣流來提供更多冷空氣。但讓人驚訝的是，有更多伺服器發出過熱警報。而且這些伺服器全都位於機架底部 — 當然，在高架地板系統中，機架底部通常是最涼爽的區域。
工程師利用感應器系統確認機架越高處越低溫，而機架底部則最高溫。他們很快發現熱空氣是從機架底部與地板之間的熱走道抽送 — 白努利定律的結果。藉由封閉機架底部並減緩氣流速度，工程師輕而易舉地解決了過熱問題。
這只不過是 Microsoft 企業工程中心在進行效能測試時收集和分析的資料。因此，EEC 最近通知 Microsoft Research 他們已經準備好進行部署測試。一天之內系統中就已經部署了 10 個機架，而且安裝作業只花了一小時就完成了。EEC 現在能夠研究並深入了解冷卻問題以及冷卻與硬體效能之間的關係。
當然，單靠監測本身並非解決方案。真正的收穫是能夠找出您可以修復的問題區域，進行變更，然後評估各種解決方案來確認它們是否能提供您想要的結果。畢竟，您可不希望當新的冷卻解決方案突然造成機架過熱時，卻只能一籌莫展。

Dave Ohara 擁有 26 年的技術經驗，目前與多家公司合作，共同提倡環保方案。


現場筆記 IMAP 拯救世界
R'ykandar Korra'ti

有時候，解決不重要的新問題的方法，也能夠解決重大的舊問題。下面就是一個例子。
去年冬天，我們網站管理員買了一部 MacBook。過去她只執行 Windows®，但是現在她不但執行 OS X，並且還在虛擬機器執行 Windows XP，以便同步處理 Windows Mobile® 裝置以及其他少許小型工作。
她需要從這兩個作業系統存取所有的郵件封存，但又不想在 Mac 端執行 Entourage (那勢必會過於忙碌)。其實，她是想執行 Mail.app，亦即 OS X 所包含的電子郵件用戶端。順帶一提，她把所有的東西都放在膝上型電腦的本機存放區當中，而且並未加以鏡像。而我的工作就是：把這件事情搞定。
要讓封存檔在每一個地方都能讀取，只有前面提過的一個小問題，因為包括 Exchange Server、Microsoft® Office Outlook® 和 Mail 在內的每一個產品，都是透過 IMAP4 溝通，而這也是我們的第一條規範。IMAP4 是一種傳訊通訊協定，負責處理精簡型用戶端在伺服器上的郵件儲存區。雖然它受使用者青睞的功能沒有 Exchange 多，但運作起來都沒問題 (請參閱 2006 年 3 月和 4 月號《TechNet Magazine》的＜IT 如何運作：IMAP4＞，網址為 technet.microsoft.com/magazine/cc161016)。
所以，只要稍微更改一些設定，讓 IMAP4 over SSL 上線，再將她所有的本機資料夾複製到伺服器上，然後再 Ping！這麼一來，她就可以存取所有用戶端上的郵件，並且隨時更新 Windows Mobile 裝置，問題就完全解決了。
但是，想出簡單的方法解決潛在的棘手問題，就像拿到新電鋸一樣，一下子就開始收集建築夾板，以迅雷不及掩耳的速度蓋好場景，準備好上演「羅密歐與茱莉葉」，完全不假思索。
我們的 ISP 麻雀雖小，卻五臟俱全，不但有 Windows、OS X、Mac OS、Linux，甚至還有一個寂寞的老 AmigaOS 系統在等著找尋同伴。很久以前，我們曾在 Amiga 上為 Usenet news 和 UUCP 郵件提供主機服務。它是以 RFC-733/AmigaUUCP 格式建立並收藏封存。我們也有 Microsoft Mail 封存 (.mmf 格式) 以及一些仿古式的 UNIX 郵件封存 (.mbox 格式)。但是這些封存檔根本派不上用場，只是坐在那裡嘲笑我們 — 雖然我們不時反覆思考這個問題，最後卻只能以尖叫掩面逃跑告終。
這個案例把我們帶到了第二條規範，也就是危險駭客座右銘傳說：千萬不要清除無法取代的東西。
我們先處理 Microsoft Mail 封存。雖然有段時間 Outlook 一直無法匯入 .mmf 檔案，但是隨著這幾年用戶端的升級，我們也為每一個舊版產品至少保留一份授權，誰知道哪天會用得著。就這樣，我們的授權存檔就形成一份 Microsoft Corporation 歷史表。需要 MS-DOS®？OS/2 1.31？Microsoft Mail？還是 Office 95 嗎？沒問題！您要英文版還是法文版呢？
雖然 Outlook 2000 已經匯入 .mmf，但是它的 IMAP 支援卻有點古怪，有時候還會無故刪除標頭資料。而且，它也不能跟 IMAP4 和 Exchange 伺服器同時交談。這實在令人傷腦筋，不過還不至於解決不了。您可以經由 Outlook 2000 匯入 .mmf 檔、升級到我們所保留的 Outlook 2003 授權，然後進行拖放動作幾個小時的時間：15 年之久的封存檔就出現在線上，要在哪裡查看都可以。.mbox 也一樣，您可以把一個跟 mbox 相容的 IMAP 伺服器丟到 Linux 電腦上，然後將 .mbox 格式的封存檔放在它的工作目錄下，接著再使用 Outlook IMAP 支援來連接並複製資料夾到您所選的實際執行伺服器。
另一方面，Amiga 封存要求必須撰寫一個小型的 C 程式碼套件，將 RFC-733 標頭轉換為 RFC-822 格式，揚棄舊式的 SysV 郵件分隔線，然後從它所在的可怕地方擷取「寄件人：」一行的資料。這就是讓問題擺太久的代價。但是完成之後，AmigaUUCP 格式就變成 .mbox 格式。接著 Outlook IMAP4 就把被丟在同一工作目錄下的郵件取出，這些郵件看起來就跟新的一樣。除此之外，它甚至還幫我們把附件都封裝妥當了。
現在我們可以在線上看到回溯到 1990 年的封存檔，格式完全統一，而且我們還在四處尋找其他封存檔 ... 反正我們做得到嘛。不賴吧？

R'ykandar Korra'ti 是一家小型消費合作網際網路服務提供者 (ISP) 的郵件管理員，和她的搭檔 Anna 住在美國的西雅圖附近。她過去曾推出 Microsoft 的郵件產品，她在不寫深奧難懂的曼陀林歌詞時，就寫技術文件。想簽約的經紀人可以透過電子郵件與她聯絡：darako@murkworks.net。


Windows 機密文件 建置在過去的基礎上
Raymond Chen

我的一位同事從佈滿灰塵的儲藏室中營救出一台 Alpha AXP 機器。啟動系統時，他發現這台電腦是執行 2000 年初發行的 64 位元版本的 Windows®。這怎麼可能？
我的辦公室剛好也有這款機器。這款機器在全盛時期來勢洶洶。它的體積就跟一台小冰箱差不多，而且發出的噪音就像真空吸塵器一樣大聲。其中包含了四顆 — 數數看，有四顆！ — Alpha AXP 處理器，分別以驚人的 400 MHz 執行。這台機器擁有 1 GB 的 RAM，還有 13 GB 的硬碟空間，分佈在十二個快速 SCSI 磁碟機上。這在現今也許微不足道，但在 1990 年代，這些 Alpha AXP 機器可說是目光焦點，有了它，每個人都想跟你作朋友。
1999 年，當 Compaq 宣布 Alpha AXP 不再支援 Windows 時，許多 Alpha AXP 系統突然留在 Microsoft 中無正事可做。不過其中有一部份的機器開始擔當起各式各樣的非公務工作。我使用我的 Alpha AXP 系統來建立整個 Windows 原始程式碼索引。想想看，要是程式設計人員在幾秒內就能識別某個函式的所有呼叫者，或是找到偵錯追蹤中出現的函式或對話方塊的原始程式碼，那有多方便呀！
但即使是執行建立 Windows 原始程式碼索引這樣簡單的工作，Alpha AXP 依舊很快面臨了 x86 級機器的威脅。這些機器除了更便宜快速，提供更多硬碟空間，而且記憶體更大。因此，我的電腦隨即就加入了被遺忘的行列。本來以為停止支援 Alpha AXP 等於是這些機器的末日，但此時出現一個契機，讓這些機器光榮復出，在新世代中呼吸最後幾口空氣。
64 位元的 Windows 計劃正如火如荼展開，而 Alpha AXP 是唯一符合計劃中的 64 位元處理器需求的實體機器。Intel Itanium 仍在開發階段而且只在模擬器中執行過，至於 AMD64 架構根本還沒發明。因此，64 位元的 Windows 最初是在 Alpha AXP 上開發。
當 Compaq 宣布 Alpha AXP 上將不再支援 Windows 時，先前用於 32 位元 Windows 2000 開發及測試的所有這些 Alpha AXP 機器另謀他途，開始秘密地當作 64 位元作業系統的測試機器，但此作業系統永遠不會以這種形式發行。Alpha AXP 只是一個概念證明的平台。
Alpha AXP 機器的表現恰如其份，為 64 位元的 Windows 小組提供真實的硬體來使用，讓小組不需要在 Itanium 模擬器的作業系統上執行 (想也知道速度有多慢)。當然，Alpha AXP 並非最終的目標硬體，但它的確幫了大忙。當實體 Itanium CPU 問世時，Alpha AXP 所填補的空缺已經消失，於是它們又再次退居到塵封的儲藏室中。
為了拍照，我在 Microsoft Archives 工作的朋友將我那台可靠的老舊 Alpha AXP 從塵封的儲藏室找出來，並與它促成的產品一同合照：64 位元版的 Microsoft Windows Server® 2003。而且沒錯，連灰塵都是當初留下來的。

Raymond Chen 的網站「The Old New Thing」以及同名著作 (Addison-Wesley，2007 年) 均探討 Windows 的歷史和 Win32 程式設計。他不想被鎖在佈滿灰塵的儲藏室裡。