September 2008 September 2008
ISA Server: ISA Server 2006 保全指南
很多公司都倚賴 ISA Server 2006 來保護他們的環境，卻鮮少採取重要的步驟保護 ISA Server 本身的安全。本文指導您如何使用「安全性設定精靈」和系統管理角色來限制 ISA Server 2006 受攻擊面，以及保護其實作安全。 Alan Maddison
ISA Server: 透過 ISA Server 2006 強化 TS 閘道安全性
Windows Server 2008 使用全新的 TS 閘道功能，讓使用者不需 VPN，就能夠在任何地方存取他們的桌上型電腦。一同來了解您要如何透過 ISA Server 2006 發行 TS 閘道，以及如何延伸 ISA Server 2006 發行案例來涵蓋用戶端健康強制。 Dr. Thomas W. Shinder 和 Yuri Diogenes
IIS 7.0: IIS 7.0 中的十大效能改進
最新版的 IIS 引進了模組化和可擴充的平台，並改善對常見部署和管理案例的支援，藉此達成可觀的效能改進。現在就來看看 IIS 7.0 中提供這些改進的十大區域。 Mike Volodarsky
行動性: 將企業營運應用程式行動化
現今許多行動專業人員都需要在外出時，從行動裝置存取辦公室內所用的企業營運應用程式 (CRM、ERP 等)。讓我們一起了解 Windows Mobile 和 Mobile Device Manager 如何讓您部署重大企業營運應用程式豐富的行動功能。 Matt Fontaine
安全性: 了解共用帳戶密碼管理
共用和特殊權限帳戶密碼是老生常談，但是卻有太多的公司無法適當管理這些共用密碼。因此製造了嚴重的安全性問題。一同來探索與共用和特殊權限帳戶相關的風險，並找出更恰當的方法來管理更安全的密碼。 Chris Stoneff
Columns
編輯的話: 回歸校園: | 讀者來信: 讀者有話直說: | 工具箱: 適合 IT 專家的新產品:
Exchange 佇列問題與解答: 校準磁碟分割，規劃 SCR 及其他: 在 2008 年 9 月號的《Exchange 佇列問題與解答》中，我們解答了關於計算您所需之通用類別目錄伺服器的數目，變更伺服器的站台成員資格以及其他問題。Henrik Walther | 公用程式焦點: Windows 記憶體診斷: 一同來了解這個免費的公用程式如何協助您判斷在執行 Windows 時出現的問題是否由記憶體錯誤所引起。Lance Whitney | Sharepoint 內幕: SharePoint 目錄整合: Pav Cherny 探討 SharePoint 中的內建目錄管理服務的限制，並向您說明如何以自訂解決方案來取代這個元件，讓您將 SharePoint 收件者資訊與其他目錄解決方案同步處理。Pav Cherny
Windows PowerShell: 字串理論: 儘管具備物件導向的本質，Windows PowerShell 同時也能夠剖析複雜的字串。Don Jones 示範要怎麼在 Windows PowerShell 中使用 Select-String 來辦到。Don Jones | 嗨，Scripting Guy！: 與您的烤麵包機保持連線: 探索如何使用離線式資料錄集 — 虛擬資料庫資料表 — 來解決與資料排序以及使用大型資料集有關的 VBScript 限制。Microsoft Scripting Guy | 桌面檔案: WDS 中的進階功能: 在 Wes Miller 第三篇探討 Windows 部署服務的文章中，他討論到可提升效能和延展性的功能、記錄功能和命令列自動化。Wes Miller
安全性監控: 密碼與信用卡 - 第三篇: 在本系列三篇的最後一篇，Jesper Johansson 探討軟體廠商、安全性套件和宣傳效果如何阻礙為可靠的安全性所做的努力，他並且警告我們，這些作法將如何導致技術安全性生態系統的崩潰。Jesper M. Johansson | 現場筆記: 內在創新: Romi Mahajan 解說他的「內在創新」理論，該理論強調人類創意和人力資本是提供比較優勢的重要關鍵。Romi Mahajan | Windows 機密文件: Windows 95 原形畢露: Raymond Chen 解說一個小小的診斷程式碼，如何意外拖累 Windows 95 組建的執行速度。Raymond Chen


ISA Server 2006 保全指南
Alan Maddison
綜覽：
  • 保全伺服器的最佳作法
  • 設定安全性設定精靈
  • 安全性設定精靈逐步解說
  • 指定系統管理角色

目錄
保護伺服器安全
設定安全性設定精靈
執行 SCW
系統管理角色
雖然有很多 IT 專家都倚賴 ISA Server 2006 (Internet Security and Acceleration Server 2006) 來保護他們的技術資產，卻鮮少採取額外的步驟保護 ISA Server 本身的安全。如果您
近來安裝了 ISA Server 2006，可能猶記在安裝完成之後馬上會提示您進行這個動作。可惜，我們許多 IT 專家很少花 (或有) 時間來執行這個重要的步驟，結果變成待辦清單上從未完成的事項。
在當今安全性多變的環境下，保護 ISA Server 的安全是不可少的。所幸，用來保護 ISA Server 安全的工具有大幅的改進。您在安全性強化精靈 (ISA Server 2004 以前的版本提供的) 中不用再面對這麼多挑戰。您反而可以仰賴充分定義的步驟和工具，例如隨 Windows Server® 2003 發行的「安全性設定精靈」(SCW)。
在本文中，我將扼要說明保護伺服器安全性的一般最佳作法。接下來，我將逐步探討 ISA Server 本身的強化策略，使用「安全性設定精靈」來縮小 ISA Server 的受攻擊面，並利用系統管理角色來限制對 ISA Server 的存取。

保護伺服器安全
無論伺服器是位於資料中心，或是您辦公室隔壁的機房，保護伺服器安全牽涉的要素和最佳作法相當多。身為系統管理員，您有責任了解這些最佳作法，並且以對您的環境來說切合實際的方式盡力履行這些需求。隨著近年來越來越強調安全性，我們當中有許多人也對構成這些需求核心的工作變得相當熟悉，所以我在此也不嘮叨，只會做簡短的介紹。
保護您的環境必須採取的第一個步驟，是確保您的伺服器在實體上是安全的。用白話說，就是您必須限制對伺服器的實體存取。在規模較小的環境中，這表示確定鎖好機房的門，而且只讓少數人可以進出機房。在較大型的環境中，這樣的基本需求不變，但執行方法需要更縝密。比方說，許多公司都採用電子監視。這可讓公司審查對伺服器位置的進出，甚至限制只能存取個別的機架或機殼，視工作職責的結構而定。
在處理 ISA Server 或 ISA 設定存放區伺服器遭竊或實體遭到入侵時，有一些特殊的要素需要考量。因為自遭竊的伺服器取得的資訊性質，有可能會侵害環境內所有的 ISA Server 和流量 (包括加密的流量)。
如果您懷疑某伺服器已遭入侵、遭竊，應立即移除受影響的伺服器 (如果仍在站內的話)，並遵循保全證據的標準程序。在採取這些必要步驟之後，必須開始進行變更所有機密資訊的程序 — 安裝在伺服器上的所有認證都應撤銷，而所有預先共用的金鑰和共用密碼都該修改。此外，如果您有設定存放區伺服器的複本，也請確定與受侵害的伺服器相關的資料都已移除。
伺服器一旦在實體上受到保護之後，下一步便是確保有一套結構化的方法來修補所有的軟體，包括虛擬層、OS 和應用程式。修補程式、升級和 Hotfix 都應該經過檢閱並定期套用。但別忘了在將這些更新套用到實際執行系統之前先行測試。修補程式如果到最後導致問題而危及應用程式或資料完整性，也無用處。
如果資料完整性受到危害，就得依賴備份。這把話題帶到保護基礎結構安全的另一個關鍵要素。如果您無法在需要的時候迅速且完整地還原資料，停機可能會對您的營運產生顯著的衝擊，因而增加受到入侵的成本。
另外兩個要考慮的要素分別是監視和稽核。監視您的應用程式和系統是任何良好安全性計畫不可或缺的一環。假如您不花時間檢閱記錄檔，尤其是安全性相關的記錄檔，也就無法在傷害造成之前找出入侵的舉動。
同樣地，稽核也是不可少的。對於許多公司來說，特別是大型環境，這通常已經形式化，甚至是法規要求。無論如何，在任何環境中定期檢閱用來保護資產的控制管道和方法學，好讓您的努力發揮效用，這點是很重要的。
最後，由於您是在 Windows Server® 2003 上執行 ISA Server 2006，因此檢閱《Windows Server 2003 安全性指南》並實作必要的建議作法也是勢在必行。您可以在 microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx 找到《Windows Server 2003 安全性指南》(英文)。
Microsoft 目前是建議實作「基準安全性原則」範本，但您不應該實作任何網際網路通訊協定安全性 (IPsec) 篩選器。

設定安全性設定精靈
那麼，您要怎麼使 ISA Server 本身更安全呢？保障 ISA 安全的主要工具是 SCW，這是用來縮小受攻擊面的工具。它會針對伺服器的服務、網路安全性、登錄和稽核原則等建立安全性原則，只對它所需的服務和功能設定系統。要特別注意的是，您應該只設定您打算使用的 ISA Server 服務。舉例來說，Web Proxy 服務預設是啟用的，但如果您不打算使用它，應該停用這項功能。因此，您必須特別注意 SCW 所顯示的設定選項。
Windows Server 2003 中預設並不會安裝 SCW，因此第一個步驟是使用 [新增或移除程式] 控制台中的 [新增/移除 Windows® 元件] 小程式，自行安裝它 (請注意，Windows Server 2008 預設會安裝 SCW)。[Windows 元件] 畫面一載入之後，請向下捲動，並勾選 SCW 的方塊。
安裝一完成，便可在 [系統管理工具] 下找到此應用程式。在開始使用精靈之前，您必須下載 ISA Server 2006 的更新 (可從 go.microsoft.com/fwlink/?LinkId=122532 取得)，來更新 SCW。這個更新檔會在 ISA Server 2006 Standard Edition、ISA Server 2006 Enterprise Edition 和 ISA Server Configuration Storage Server 新增角色。
下載更新之後，您必須執行套件，並從中將檔案解壓縮。將這些檔案解壓縮之後，將兩個 .xml 檔案 (isa.xml 和 isaloc.xml) 複製到 SCW kbs 資料夾 — 若為 Windows Server 的預設安裝，這將位於 c:\windows\security\msscw\kbs。
複製檔案時，系統會提示您以相同的名稱覆寫兩個現有的檔案。這兩個檔案是供 ISA Server 2004 之用，因此您應該在覆寫之前把它們備份起來。最後一步是將 isascwhlp.dll 檔案複製到 bin 資料夾，一般可以在 c:\windows\security\msscw\bin 找到。完成將 ISA 角色新增到 SCW 之後，就可以準備開始安裝了。
Microsoft 一般是建議只在完成 ISA Server 的設定之後才執行 SCW。如果您執行的是 Enterprise Edition，這包括設定所有的陣列及所有陣列成員。

執行 SCW
第一步是從 [系統管理工具] 啟動 SCW — 別忘了，您必須具備系統管理權限才能順利完成 SCW 程序。
[圖 1] 顯示精靈的第一個畫面。如果您詳讀這個畫面上的文字，特別是「此精靈會偵測到此伺服器所聆聽的輸入連接埠」的警告，就可以了解在開始這個程序之前先把 ISA Server 和陣列完全設定好的重要性。
[圖 1] 開始「安全性設定精靈」 (按一下以放大影像)
如果您尚未完整設定好您的環境，在完成 ISA 設定之後，很有可能還需要修改 SCW 的設定。如 [圖 2] 所示，下一個畫面會詢問您想要執行的動作。您應該選取 [建立新的安全性原則] 選項。
[圖 2] 建立新的安全性原則 (按一下以放大影像)
您接下來會收到指示選取伺服器作為該原則的基準。由於您是要建立新原則，因此預設選項是使用您正在執行 SCW 的電腦。不過，這個行為會根據您在前一個畫面選擇要執行的動作而改變。無論如何，在您想要用作為基準的伺服器上安裝 SCW，都是建議的最佳作法。如果目標伺服器上未安裝 SCW，將會缺少用來完成原則的資訊。因此，為了省掉麻煩，請從您想要用作為基準的伺服器上安裝和執行 SCW。
按下 [下一步] 時，SCW 即會開始分析您的 ISA Server。這項分析包括判斷伺服器上已安裝的角色、伺服器上可以安裝的角色、已安裝的服務，以及基本網路資訊。處理程序完成後，您就可以選取 [檢視設定資料庫] 來檢視資料庫。設定資料庫內含許多資訊，包括所有支援的伺服器角色、用戶端功能和連接埠等。
接著，SCW 會開始帶您逐步完成「以角色為基礎的服務設定」程序。按下 [下一步] 會帶您到下一個畫面，當中會提示您選取伺服器角色，如 [圖 3] 所示。SCW 執行的初始掃描相當可靠，因此您應該會發現它已經識別出正確的伺服器角色。不過，您務必再次確認，並移除任何不必要的角色。而且如果伺服器具備多重角色，請確定所有適當的角色皆已選取。
[圖 3] 指定伺服器角色 (按一下以放大影像)
如果您執行的是 ISA Server 2006 Enterprise Edition，有個重點要注意，那就是您必須考慮設定存放區伺服器。假如設定存放區伺服器是安裝在同時也是作為 ISA Server 的伺服器上 (順帶一提，這違反了建議的最佳作法，但常被忽略還是照做不誤)，您必須確定也選取了設定存放區伺服器角色。您不應該對實際上只有 ISA Server 2006 角色卻裝載兩個伺服器角色的伺服器使用基準線掃描。
接下來，精靈會提示您選擇伺服器的用戶端功能。換句話說，您必須指定伺服器所需的服務。譬如，幾乎所有伺服器都需要 DNS 用戶端，而如果伺服器是網域的成員，那麼它就需要網域成員功能。
完成這個動作之後，精靈會顯示 [系統管理和其他選項] 畫面。這是您指明使用服務或仰賴網路連線的應用程式、系統管理和作業系統選項的地方。在這裡任何未選取的服務都會被停用。但在您進行選擇並按下 [下一步] 之後，精靈會提供選項讓您選擇您要允許的任何其他服務。
您接下來是設定要如何處置未指定的服務。這可讓您定義在套用原則時，如果服務未包含在主資料庫中或安裝在基準伺服器時，該怎麼做。一般的最佳作法是，選擇停用未指定的服務，因為這樣可以限制任何無法預測的攻擊標的。不幸的是，若是您的伺服器彼此明顯不同，那麼這個選項可能會有負面的效果，如果您在未來新增任何應用程式或網路服務，也必須記得這個設定。
如 [圖 4] 所示，精靈的下一區段可讓您檢閱被 SCW 修改的服務。這個確認畫面會提供服務的目前狀態與套用原則之後的修改狀態兩者的比較檢視。
[圖 4] 檢閱和確認服務變更 (按一下以放大影像)
在確認服務要進行變更之後，您接下來繼續前進到 [網路安全性] 區段。在這裡，SCW 通常會讓您修改 Windows 防火牆和 IPsec 設定。但由於您是設定 ISA Server 2006，因此只能跳過這個區段，如 [圖 5] 所示。
[圖 5] 跳過 [網路安全性] 設定 (按一下以放大影像)
精靈接著會繼續前進到設定登錄設定，此處的重點在於網路驗證方法和安全性。這個區段中的第一個畫面包括伺服器訊息區 (SMB) 簽署。SMB 通訊協定是核心的 Microsoft 網路通訊協定，而且這些設定可容許簽署過的通訊，以便降低攔截式攻擊的可能性。
如 [圖 6] 所示，預設值為您的 ISA Server SMB 通訊提供了相當理想的安全性等級。但是您必須將簽署所有通訊所引起的衝擊列入考量。如果您沒有多餘的 CPU 週期，應該清除第二個選項。而且別忘了考量要套用這個原則的所有伺服器 — 如果您的伺服器擁有不同的工作負載，您必須以 CPU 使用率最高的伺服器作為是否要選取這個選項的指標。
[圖 6] 指定是否要要求簽署過的通訊 (按一下以放大影像)
下一組畫面是處理 ISA Server 應該採用的 LMCompatibility 層級。其中第一個畫面會顯示三個選項。除非您擁有舊版 Windows 用戶端 (例如 Windows 95 或 Windows 98)，或是您使用本機帳戶來進行存取控制，否則您應該保留 [網域帳戶] 的預設選項。
在第二個處理 LMCompatibility 層級的畫面上，提供關於網域控制站的資訊。如果您沒有任何 Windows NT® 4.0 網域，可讓預設選項 (Windows NT 4.0 Service Pack 6a 或之後版本的 OS) 保留選取狀態。在這個對話方塊上，您還應該選取 [跟所選取伺服器的時鐘同步的時鐘] 選項。選取 [下一步] 將帶出一些用於輸入 LAN Manager (LM) 通訊的額外設定選項，如 [圖 7] 所示。
[圖 7] 指出輸入驗證方法 (按一下以放大影像)
第三個與 LMCompatibility 層級相關的畫面會判斷是否需要 Windows NT LAN Manager (NTLM) 第 2 版，而且是否要儲存 LM 雜湊。若是您的環境支援這個設定的話，您應當確保這些選項都沒有選取，因為清除這兩個選項將可大幅提高安全性。您接著會看到 [登錄設定摘要]。檢閱每個項目，並確認原則設定是正確的。
接下來，精靈會帶您進入最後一個區段 — 稽核。您在這個區段所進行的任何設定有個重點要特別注意，那就是您無法將它們復原。但是既然稽核不會影響系統功能，您更不應該跳過這個區段。
[稽核成功的活動] 的預設選項並不會提供您登入失敗的事件記錄項目。然而，與登入失敗相關的資訊卻可提供關於入侵嘗試的重要資訊。因此，一般的最佳作法是選取 [稽核成功的和不成功的活動]。
您接著可以檢閱稽核設定，再按兩次 [下一步] 以儲存安全性原則。如 [圖 8] 所示，在這個畫面只需要輸入檔名，不過您也可以提供簡短的描述。此描述在由不同系統管理員分擔安全性責任的大型環境中蠻管用的。
[圖 8] 為您的安全性原則提供名稱和描述 (按一下以放大影像)
檔案一經儲存後，精靈就會提供您立即套用或稍後套用原則的選項。如果您選擇稍後套用原則，那麼整個程序就告完成。要是您發現您在原則設定中犯了任何錯誤，可以復原原則，但稽核設定除外。

系統管理角色
縮小 ISA Server 的受攻擊面是降低外部來源入侵可能性的重要步驟。不過，檢閱 ISA Server 內部的系統管理角色的指派，來限制可能來自內部來源的入侵也很重要。[圖 9] 和 [圖 10] 中顯示了系統管理角色和部分常見相關工作的清單。
[圖 9] 與 Standard Edition 相關的角色和工作
工作 | 監視稽核員 | 稽核員 | 系統完整權限管理員
檢視儀表板警示、連線、工作階段和服務 | 允許 | 允許 | 允許
認可警示 | 允許 | 允許 | 允許
檢視記錄資訊 | – | 允許 | 允許
建立警示定義 | – | – | 允許
建立報告 | – | 允許 | 允許
停止和啟動工作階段及服務 | – | 允許 | 允許
檢視防火牆原則 | – | 允許 | 允許
設定防火牆原則 | – | – | 允許
設定快取 | – | – | 允許
設定虛擬私人網路 (VPN) | – | – | 允許
[圖 10] 與 Enterprise Edition 相關的角色和工作
活動 | 陣列監視稽核員 | 陣列稽核員 | 陣列系統管理員
檢視儀表板警示、連線和工作階段 | 允許 | 允許 | 允許
認可和重設警示 | 允許 | 允許 | 允許
檢視記錄資訊 | – | 允許 | 允許
建立警示定義 | – | - | 允許
建立報告 | – | 允許 | 允許
停止和啟動工作階段及服務 | – | 允許 | 允許
檢視防火牆原則 | – | 允許 | 允許
設定防火牆原則 | – | – | 允許
設定快取 | – | – | 允許
設定虛擬私人網路 (VPN) | – | – | 允許
執行 NLB 清空/停止 | – | 允許 | 允許
檢視本機資訊 (在陣列成員的登錄中) | – | 允許 | 允許
變更本機資訊 (在陣列成員的登錄中) | – | – | –
如您所見，與 ISA Server 相關的系統管理工作非常分散。因此，這樣應該方便您將正確的角色指定給公司內的使用者。
除此之外，您還必須牢記角色指派的最佳方法是採納最低權限的概念。任何指定的使用者都應該只具備容他完成工作所需的最低權限。
有一點也很重要，那就是別忘了 ISA Server 2006 Standard Edition 上的本機 Administrators 群組成員具備的權限與 ISA Server 系統完整權限管理員一樣。至於 Enterprise Edition，在具有設定存放區伺服器角色的伺服器上的本機 Administrators 群組成員，則擁有 Enterprise 設定的完整控制權。這表示您必須審慎檢閱 Domain Admins 群組的成員資格 (假設您的 ISA Server 是網域成員)，以及任何其他也屬於 ISA Server 本幾 Administrators 群組一員的群組。

Alan Maddison 在 Brocade 的 Strategic Business Systems 部門擔任資深顧問一職，專攻 Microsoft 技術。


ISA Server
透過 ISA Server 2006 強化 TS 閘道安全性
Dr. Thomas W. Shinder 和 Yuri Diogenes
綜覽：
  • 透過 ISA Server 使用 TS 閘道的兩種案例
  • ISA Server 2006 設定
  • 測試和監視

目錄
超越周邊
第一種案例
設定 ISA Server 2006
測試和監視用戶端存取
從 ISA Server 監視
第二種案例
那用戶端呢？
結論
隨著 Exchange Server 2007 中的「Outlook 無所不在」大舉成功，Windows Server 2008 也緊跟著提供以安全且受到控制的方式隨處存取桌上型電腦的功能。
Windows Server® 2008 中全新的終端機伺服器閘道服務 (TS 閘道) 除了提供 Windows® 終端機伺服器服務的彈性，還外加了透過 HTTP 連線隨處連接到終端機伺服器的功能。這項服務使用 RDP (遠端桌面通訊協定) over HTTPS (SSL) 來加強安全性，並同時提供單一用戶端介面以利存取終端機服務資源。
這個全新的 TS 閘道服務為那些需要從遠端存取他們電腦的人提供了無比的好處：
  • 使用 RDP 連接到內部資源之前，完全不用建立虛擬私人網路 (VPN) 工作階段。
  • 使用網路存取保護 (NAP) 與 Windows Security Health Checks 來控制 RDP 連線以加強安全性。
  • 無須開啟 TCP 連接埠 3389 輸入，即可透過防火牆提供更安全的網頁發行。
您可以使用 Microsoft® Internet Security and Acceleration (ISA) Server 2006 來加強 TS 閘道的安全性，同時允許外部存取內部資源。您也可以使用 HTTPS 建立 SSL 對 SSL 橋接的案例，讓 ISA Server 2006 接收要求，並將它們傳送到內部 TS 閘道服務。在橋接要求時，ISA 防火牆會將 SSL 通訊解密，並執行應用程式層偵測。
如果 HTTP 通訊協定資料流通過偵測，就會將通訊重新加密，轉寄到終端機服務 Proxy。如果通訊協定資料流沒有通過偵測，則會捨棄連線。

超越周邊
Microsoft 在安全性上投入了相當的心力，而 Windows Server 2008 正是當前最安全、最強固的 Windows 版本。但是 Microsoft 公司也非常關心使用者會如何實作它的產品，並且希望使用者遵守最佳作法來保護他們的環境。最佳作法需要採取深度防禦的方法，在多個存取點或存取層提供保護。我們在此處討論的階層是跟原則、程序和覺察、周邊、內部網路和主機等相關。
當您允許外部使用者透過 ISA Server 存取內部資源時，必須了解其中牽涉的各項產品的界限。ISA Server 2006 和 TS 閘道會在周邊層提供安全性，但對於內部資源，您必須在必要時設立允許或拒絕存取的原則。網路原則與存取服務 (NPAS) 可讓您完成這項作業，在原則、程序和覺察層工作。存取內部資源 (磁碟機、剪貼簿、印表機等) 是由終端機服務資源授權原則定義而成，以內部網路層為主。
在本文中，我們首先將討論如何透過 ISA Server 2006 發行終端機服務閘道。接下來，我們會擴大 ISA Server 2006 發行案例，加入強制使用 NAP 來保護用戶端健康狀況這一項。藉由使用 NAP，我們可以建立用戶端健康原則，幫助我們在主機層控制存取。

第一種案例
我們的目標是要示範如何透過 ISA Server 2006 發行 TS 閘道。[圖 1] 概括了在連線期間的電腦和資料流程。本案例是在 TS 閘道本身實作網路原則伺服器 (NPS) 角色，不過，第二個案例會改用中央 NPS 伺服器。請遵循下面的順序，來了解 TS 閘道發行解決方案各元件間如何進行通訊：
[圖 1] 透過 ISA Server 2006 發行 TS 閘道 (按一下以放大影像)
  1. 由外部 RDP 使用者起始連線。首先，用戶端必須解析 TS 閘道的外部名稱 (在本例中是 tsg.contoso.com)。外部 DNS 會解析這個名稱，它會指向 ISA Server 的外部 IP 位址。
  2. 在 RDP 用戶端與 ISA Server 外部介面之間建立 SSL 通道。ISA Server 在使用發行到 tsg.contoso.com 的憑證的連接埠 TCP 443 上設有網頁發行規則。
  3. 評估規則並檢查流量確實受到允許之後，ISA Server 會傳送 DNS 查詢給內部 DNS 伺服器 (位於網域控制站上)，來解析網頁發行規則上指定的伺服器名稱。
  4. ISA Server 接著開啟連往 TS 閘道的 SSL 通道，並將驗證要求傳給它。
  5. 由 TS 閘道伺服器驗證使用者的認證，並確認該使用者有權建立連線。
  6. 在證實使用者有權建立連線之後，TS 閘道服務便在 TCP 連接埠 443 上接收要求，並透過 TCP 連接埠 3389 (預設值)，將 RDP 封包轉寄到內部應用程式 (例如 CRM 應用程式) 所在的終端機伺服器。
從這裡開始，RDP 用戶端透過 ISA Server 傳給 TS 閘道的任何封包，都會轉寄給內部終端機伺服器，反之亦然。
還有一點很重要，那就是 RDP over HTTPS 實際上不過是 RDP/RPC/HTTPS。RDP 用戶端會將 RDP 通訊封裝在 RPC 標頭中，這個標頭後來會與使用 SSL (或傳輸層安全性，TLS) 保護的 HTTP 標頭一起封裝起來。RPC over HTTPS 解決方案所需的所有元件都必須存在。這也是您一安裝 TS 閘道角色服務時，它自動安裝 RPC over HTTP Proxy 的原因。若要進一步了解這個通訊協定的運作方式，建議您詳讀＜透過 ISA Server 2006 測試 RPC over HTTP 第一篇：通訊協定、驗證和處理＞(英文)，您可以在 ISA Server 小組部落格上找到 (網址是 blogs.technet.com/isablog)。
要進行這項實作，必須安裝含終端機服務閘道的 Windows Server 2008，而這項功能所仰賴的是 RPC over HTTP Proxy。為了讓 RDP over RPC over HTTP Proxy 功能順利運作，您也必須安裝和執行 Internet Information Services (IIS) 7.0。另外，您還需要網路原則與存取服務，但是如果您要的話，可以設定 TS 閘道來使用 NPS 伺服器 (之前稱為 Internet Authentication Services (IAS))，以便集中處理終端機服務連線授權原則 (TS CAP) 的存放、管理和驗證作業。最後，您必須取得 TS 閘道伺服器的 SSL 憑證 (如果沒有的話)。這裡要特別強調的一點是，ISA Server 2006 必須信任發行該憑證的憑證授權單位 (CA)。因此，請務必將憑證匯入信任的根憑證授權單位存放區。
除非您所設定的 TS 閘道授權原則要求使用者必須是 Active Directory 安全性群組的成員，才能連接到 TS 閘道伺服器，否則 Active Directory® 網域服務一般是派不上用場。為了這項特別的設定，我們將在執行 Windows Server 2003 SP2 的電腦上使用 Active Directory。
當終端機服務閘道服務完裝完畢時，便會出現 [圖 2] 的畫面，列出您所安裝的元件。用戶端若要連接 TS 閘道，必須執行下列一項：Windows Vista®；Windows XP (含 SP2 和 RDP 6.0 或之後版本)；Windows Server 2008；Windows Server 2003 (含 SP1 或之後版本和 RDP 6.0 或之後版本)。如需關於 TS 閘道設定的詳細資訊，請參閱《Windows Server 2008 TS 閘道伺服器逐步設定指南》(英文)，網址是 go.microsoft.com/fwlink/?LinkId=122251。現在，讓我們來看看要如何設定 ISA Server 2006。
[圖 2] TS 閘道安裝摘要 (按一下以放大影像)

設定 ISA Server 2006
第一步是建立網頁接聽程式，來處理外部 RDP 用戶端所發出的要求。我們的網頁接聽程式有下列參數：
  • 驗證：基本
  • 驗證確認：Windows (Active Directory)
  • 連線：在連接埠 443 上啟用 SSL (HTTPS) 連線
  • 憑證：發到 tsg.contoso.com 的憑證
  • 網路：外部
接下來是建立網頁發行規則。從 ISA Server 2006 的角度來看，RDP 用戶端會使用跟 Outlook® 無所不在一樣的通訊協定，因此請選擇 Exchange Server 2007 精靈。其步驟如下：
  1. 以滑鼠右鍵按一下 [防火牆原則]，選取 [新增]，然後按一下 [Exchange Web 用戶端存取發行規則]。
  2. 在 [歡迎使用新增網頁發行規則精靈] 頁上輸入規則名稱，然後按 [下一步]。
  3. 在 [選取規則動作] 頁選取 [允許] 選項，然後按 [下一步]。
  4. 在 [新增 Exchange 發行規則] 頁選取 Exchange 版本，在本例是 Exchange Server 2007。接著選取 [Outlook Anywhere (RPC/HTTP(s))]，然後按 [下一步] (注意：請勿選取 [在 Exchange Server for Outlook 2007 用戶端上發行其他資料夾] 選項)。
  5. 在 [發行類型] 頁選取 [發行單一網站或負載平衡器]，然後按 [下一步]。
  6. 在 [伺服器連線安全性] 頁選取 [使用 SSL 連線到發行的 Web 伺服器或伺服器陣列]，然後按 [下一步]。
  7. 在 [內部發行詳細資料] 頁的 [內部網站名稱] 方塊中，輸入 TS 閘道伺服器的名稱。接著選取 [使用要連線到發行伺服器的電腦名稱或 IP 位址] 核取方塊，然後在 [電腦名稱或 IP 位址] 方塊中輸入伺服器名稱。如果您不知道 TS 閘道伺服器的名稱，請按一下 [瀏覽] 以巡覽至它的位置。請注意，您在此頁上使用的名稱，必須與繫結到 TS 閘道網站的網站憑證上的一般名稱或主題名稱相符。
  8. 在 [公用名稱詳細資料] 頁上，從 [為右列接受要求] 下拉式清單選取 [這個網域名稱 (在下方鍵入)]，然後在 [公用名稱] 方塊中，輸入與針對此 URL 發行的憑證名稱相符的公用名稱 — 在本例是 tsg.contoso.com。接著按 [下一步]。
  9. 在 [選取網頁接聽程式] 頁上按一下下拉式清單，選取之前建立的網頁接聽程式，然後按 [下一步]。
  • 接下來，在 [授權委派] 頁選取 [沒有委派，但用戶端可以直接驗證]，再按 [下一步]。
  • 然後在 [使用者組] 頁上，確認已經選取預設選項 (所有使用者)，再先後按 [下一步] 和 [完成]，最後再套用它。
    • 如果您按兩下規則，然後前往 [路徑] 索引標籤，會看到我們只有一個路徑，那就是 /rpc/*。這是因為我們使用 Exchange Server 2007 Outlook 無所不在精靈的關係。

    測試和監視用戶端存取
    我們在前面說過，您必須有 RDP 6.0 或之後的版本，才能連線到 TS 閘道。若要設定 RDP 用戶端應用程式，請啟動它，然後在 [電腦] 欄位中輸入您要連接的終端機伺服器名稱。接著依序按一下 [選項] 按鈕、[進階] 索引標籤和 [設定]，然後輸入 TS 閘道伺服器的外部名稱，如 [圖 3] 所示。在本例當中，這是繫結到我們網頁發行規則接受連入要求所用之網頁接聽程式的憑證上的名稱。請注意，本例是使用 Windows NT® LAN Manager 驗證。完成之後，請按一下 [確定]，再按一下 [連線]。您會收到驗證提示。請輸入有權存取終端機伺服器的使用者的認證，然後再按一下 [確定]。
    [圖 3] 設定 RDP 用戶端 (按一下以放大影像)
    請注意 RDP 6.0 用戶端 (用於 Windows XP 和 Windows Server 2003) 會顯示 [圖 3] 的畫面。系統會提示您進行驗證兩次 — 第一次是針對 TS 閘道電腦進行驗證，第二次是針對您要存取的終端機伺服器進行驗證。這一點很重要，因為您可能會以為這是 ISA Server 設定所致，但實際上 ISA Server 完全不會處理驗證作業，因為網頁發行規則是套用到「所有使用者」，而這可以讓使用者透過 ISA 防火牆進行匿名連線。
    Windows Server 2008 隨附的 RDP 用戶端有個 [對遠端電腦使用我的 TS 閘道認證] 選項，如 [圖 4] 所示。只要選取這個選項之後，就不用輸入認證兩次，對於使用者來說相當方便。Windows Vista 在套用 SP1 之後，也會出現一個單一登入選項供您使用。
    [圖 4] Windows Server 2008 RDP 用戶端 (按一下以放大影像)
    您可以使用 [監視] 選項，透過 TS 閘道管理員來監視連線。當未經授權的使用者想要連線到伺服器時，TS 閘道服務也會提供詳細資料。在 [圖 5] 中，事件檢視器顯示出一位無權透過 TS 閘道連線的使用者所做的連線嘗試。
    [圖 5] 記錄到 TS 閘道服務的事件 (按一下以放大影像)
    這個事件會記錄 ISA Server 2006 的內部 IP 位址，因為網頁發行規則中已啟用 [要求看起來是來自 ISA Server 電腦]。如果您想要註冊原始的用戶端 IP 位址，必須變更 ISA Server 2006 網頁發行規則，然後在 [目標] 索引標籤上選取 [要求看起來是來自原始用戶端] 選項。

    從 ISA Server 監視
    使用 ISA Server 2006 Supportability Update 的新功能，可仔細觀察和了解內部網路的各個連線。[圖 6] 所示的是一個反白標示的連線，另外還在 [要求:]行顯示指出 RPC over HTTP Proxy URL 的 RPC_IN_DATA 指令動詞。
    [圖 6] 使用 Supportability update 的 ISA Server 2006 記錄 (按一下以放大影像)
    如果您繼續看一下記錄，應該可以看到另一個 RPC over HTTP 指令動詞 RPC_OUT_DATA。請特別注意使用的是哪些 HTTP 方法，此處是 RPC_IN_DATA 和 RPC_OUT_DATA (用於 RDP/HTTP)，因為如果您設定了 HTTP 篩選來封鎖這些方法的話，ISA Server 就會封鎖流量。如果您想要鎖住環境，可以設定 RDP/HTTP 網頁發行規則，只允許使用這兩種方法。如需有關發行常用的 HTTP 方法的詳細資訊，請閱讀＜ISA Server 2004 中的 HTTP 篩選＞(英文) 一文，網址是 technet.microsoft.com/library/cc302627。

    第二種案例
    在這個案例當中，TS 閘道將使用位於另一部伺服器上的 NPS 中央原則。我們將強制使用 NAP 原則，讓用戶端透過 TS 閘道從遠端進行連線。除了多加一個 NPS 伺服器之外，此處所用的元件與第一種案例完全一樣。不過，由於強制使用 NAP 的關係，用戶端上會使用更多元件，如 [圖 7] 所示。
    [圖 7] 第二種案例拓樸的主要元件 (按一下以放大影像)
    以下是個別元件的說明。Windows Vista 用戶端上的 System Health Agent (SHA)，是由負責監視和報告用戶端健康狀態的用戶端元件組成。雖然 Windows Vista 附有 Windows SHA，但是其他廠商也在積極建立自己的 SHA。
    用戶端上的 NAP 代理程式負責在用戶端嘗試存取網路時，建立與 NAP 強制伺服器的通訊。NAP 代理程式會將用戶端的健康狀態聲明 (SoH) 傳給該部伺服器。
    在 TS 閘道上，TS 資源授權原則 (TS RAP) 是讓您決定哪部電腦可用來接收連入 RDP 要求的元件。TS RAP 也會決定哪些使用者可以和特定的伺服器建立 RDP 連線。
    中央 NPS 負責的是控制用來協調內部電腦存取的條件、條件約束和設定。中央 NPS 上的 System Health Validators (SHV) 是負責評估用戶端所提交的 SoH 是否遵守系統管理員所設定的原則。
    現在讓我們把 TS 閘道改指向 NPS 中央伺服器，開啟 [TS 閘道管理員主控台]，在伺服器名稱上按一下右鍵，然後選取 [屬性] 選項。接著在伺服器的屬性視窗上按一下 [TS CAP 存放區] 索引標籤，選取 [中央 NPS 伺服器]。接下來是輸入 NPS 伺服器的名稱或 IP 位址，然後按 [新增] 按鈕。這時候會出現一個 [共用密碼] 視窗。請輸入密碼，再按一下 [確定]，然後再次按一下 [確定] 關閉視窗。您必須記住這個密碼，因為 NPS 伺服器上會用到。
    假設另一部伺服器已經安裝 NPS，則步驟如下：
    1. 開啟 [網路原則伺服器] 主控台，然後在左窗格按一下 [NPS (本機)]。
    2. 在右窗格按一下 [設定 NAP]。接著會出現 [選取與 NAP 搭配使用的網路連線方法] 頁面。
    3. 在 [網路連線方法] 下，從下拉式方塊選取 [終端機服務閘道 (TS 閘道)]，然後按 [下一步]。
    4. 在 [指定執行 TS 閘道的 NAP 強制伺服器] 頁按一下 [新增] 按鈕。
    5. 在 [新增 TS 閘道] 視窗中，輸入 TS 閘道伺服器的易記名稱和 IP 位址。接著在視窗下方輸入共用密碼，使用與 TS 閘道伺服器設定上同一個密碼。接著按一下 [確定]。
    6. 您可以在 [設定用戶端裝置重新導向及驗證方法] 頁，指定要重新導向哪些裝置，以及允許的驗證方法 (密碼或智慧卡)。基於本範例的目的，請保留預設選項，然後按 [下一步]。
    7. 在 [設定使用者群組與電腦群組] 頁上，新增允許建立連線的使用者群組。以本範例來說，請按一下 [使用者群組:(必要)] 下的 [新增使用者] 按鈕，然後選取 [Domain Admins]。按一下 [確定]，再按 [下一步]。
    8. 您會看到 [預設 NAP 健康原則] 頁已經選取預設的 SHV 了。另外也請注意這一頁的下半部，不合格電腦的存取已被拒絕。請保留預設值的選取狀態，然後按 [下一步]。
    9. 在 [正在完成 NAP 強制原則及 RADIUS 用戶端設定] 頁上，檢閱之前選取的選項。您也可以按一下 [設定詳細資料] 超連結，開啟一個 HTML 頁面，列出您的選項摘要。完成時，請按一下 [完成]。
    這個精靈會負責設定幾項重要原則 (連線要求原則、網路原則和健康原則) 的設定，因此明顯幫本案例減少許多設定 NAP 所需的工作。

    那用戶端呢？
    現在伺服器都已安裝設定妥當，至於用戶端該怎麼處理呢？
    若要利用 NAP 強制原則，用戶端必須是 Windows Server 2008 或 Windows Vista 才行。如果是 Windows XP，則必須安裝 SP3 (其中包含 NAP 用戶端)。
    除了作業系統的需求外，用戶端上還有一些相關的服務和設定需要啟用。當中包括下列項目：
    • 在用戶端上新增 TS 閘道伺服器名稱到 [信任的伺服器] 清單。
    • 啟動 NAP 代理程式服務，並將服務啟動類型設為 [自動]。
    • 啟用 TS 閘道隔離強制用戶端。
    為了簡化這套解決方案的部署，Microsoft 建立了終端機服務 NAP 用戶端設定命令 (Tsgqecclientconfig.cmd)，此命令可從 go.microsoft.com/fwlink/?LinkId=122267 下載取得。執行命令之後，用戶端就會設定成 TS 閘道的 NAP 強制用戶端。請注意，您必須具有較高的權限，才能執行這個命令。
    在本文當中，我們主要的目的不光是說明和解釋 Windows Server 2008 提供的全新 TS 閘道功能，示範如何安全地透過 ISA Server 2006 來發行它，也要讓您全然瞭解兩種產品的結合，可為貴公司提供哪些安全性優勢。
    以目前來說，隨處連線可說是成功企業的必備條件，但也必須確定這樣的連線能力並不會損及使用者的體驗，更重要的是，一定要以安全性為優先考量。

    Dr. Thomas W. Shinder 身兼 MCSE 和 ISA Server MVP，自 1996 年來先後擔任過技術培訓講師、作者和顧問，並撰寫過六本 ISA 防火牆方面的著述。他同時也是 ISAserver.org 的實踐先驅，這是網際網路上最大的 ISA 防火牆系統管理員和熱中者社群。

    Yuri Diogenes 身兼 MCSE+S、MCTS、MCITP、Security+、Network+ 和 CCNP，他是 Microsoft ISA Server/IAG 小組的支援工程師。Yuri 為 Microsoft TechNet Library 和 ISA Server 小組部落格撰文，他自 1993 起就投入 Microsoft 技術。加入 Microsoft 之前，他曾擔任 Microsoft 培訓講師、支援分析師和顧問。


IIS 7.0
IIS 7.0 中的十大效能改進
Mike Volodarsky
綜覽：
  • 盡量減少您的應用程式數量
  • 降低頻寬成本
  • 使用增強的快取功能

目錄
更精簡的網頁伺服器
建置在精簡的 OS 上
專門化的應用程式拓樸
改良過的應用程式支援
增加應用程式密度
透過壓縮減少頻寬
媒體位元率節流
輸出快取
將 ISAPI 程式碼轉換成 IIS 7.0 模組
伺服器擴充性
總結
當我與打算採納 IIS 7.0 的公司碰面時，它們必問的問題是，移轉到 IIS 7.0 到底能不能提升伺服器或應用程式的效能。答案
通常是肯定的，但是如果您剛將應用程式移轉到 IIS 7.0 卻沒看到什麼效能方面的提升，也別太驚訝。
要了解原因，您必須認識最新版本的本質。IIS 6.0 是一種工程設計版本，目標是要完成三件事：:更強固的安全性、更高的可靠性，以及更佳的效能。相反地，IIS 7.0 則是一種平台版本。它的目的是要將它前版以高品質為基底的網頁伺服器核心，轉換成一個可擴充的模組化平台，以支援主要的現代部署和管理案例。
許多架構上的變更和新功能，實際上對網頁伺服器的效能可能會有負面影響 — 譬如，當中一項重大的變更，是把嚴密最佳化的網頁伺服器程式碼路徑，分成不受網頁伺服器特別對待的獨立模組。不過，還是要感謝 IIS 小組努力不懈地完成許多效能工作，使得 IIS 7.0 的效能不但與前版並駕齊驅，並且在某些方面表現更加出色。根據我個人投入網頁伺服器核心和整合式管線的工作經驗，要達成這樣的成效不僅需要具備相當精巧的設計才能，也必須下功夫在實作產品上。
儘管如此，說到提供大幅的效能改進和降低伺服器伺服陣列效能相關成本，IIS 7.0 所具備的潛能要比過去任何其他 IIS 版本大得多。
除了一些環境是例外，單是移轉至 IIS 7.0 並不一定可以看到這些成效。例如，Microsoft.com 在 CPU 效率方面就提高了 10% (您可以在 Microsoft.com 小組部落格上找到完整的分析，網址是 go.microsoft.com/fwlink/?LinkId=122497)。您也可能在某些方面發現到明顯的改進，包括安全通訊端層 (SSL) 和 Windows® 驗證 (兩者現在都在核心內執行)，以及在多核心和多處理器的電腦上看到更佳的垂直延展性。
話雖如此，IIS 7.0 真正的威力並不是來自對現有功能不斷進行的效能改進，而是來自您必須主動使用的新功能。這些功能通常深植於平台的彈性和可擴充的特性裡面，也可在新效能功能中窺見。在本文中，我將向您說明透過移轉至 IIS 7.0，您可以開啟的十大效能改進來源。

更精簡的網頁伺服器
部署精簡式 IIS 7.0 伺服器的能力是汲取自伺服器的模組化架構。幾乎它所有的網頁伺服器功能，都是實作成可以個別新增或移除的模組化元件。因此，您可以把任何對應用程式作業來說不必要的伺服器功能移除掉，來達成顯著的成效，包括大幅縮小受攻擊面，更小規模的作業支配，以及改進的效能等。
完整的 IIS 7.0 網頁伺服器功能組內含 44 個模組，包括原生 IIS 模組和 ASP.NET 模組，後者為整合式管線提供服務。這些模組提供如驗證 (Windows 驗證和摘要式驗證模組)、應用程式架構支援 (FastCGI 模組)、應用程式服務 (工作階段狀態模組)、安全性 (要求篩選模組)，以及效能 (輸出快取模組) 等服務。而最精簡的網頁伺服器 (只需要提供靜態內容)，只要兩個模組就可以運作了！
不必要的模組所產生的額外負荷可能相當明顯 — 例如，在要求記錄和失敗要求追蹤模組的情況下。而在不需要這類模組的環境中把它們移除，可產生較高的總輸送量，以及更快速的回應，因而減少伺服器工作負載的距第一位元組時間 (TTFB) 和距最末位元組時間 (TTLB) 度量。
[圖 1] 顯示當以完整的功能組、針對工作負載的預設功能組，以及針對工作負載所需的最精簡功能組設定時，對 HTML 檔案 (靜態工作負載) 與 Hello World ASP.NET 網頁 (ASP.NET 工作負載) 進行的簡單輸送量測試所產生的結果。雖然大多數非基本功能在「完整」設定中都已停用，但在「最精簡」設定中把它們完全移除，對靜態工作負載和 ASP.NET 工作負載兩者，仍舊增加了可觀的輸送量。
[圖 1] 靜態工作負載和 ASP.NET 工作負載在三種不同設定與 100 個並行用戶端下的輸送率 (按一下以放大影像)
除此之外，您還可能看到記憶體支配方面的改進，以及更高的網站密度，特別是在使用大量工作者處理序的共用主機環境或情況下。在每個處理序中載入更少的 DLL，並消除在模組初始化和要求處理期間發生的記憶體配置，通常就可以看到這樣的成效。[圖 2] 顯示相同輸送量測試中的記憶體使用量 (IIS 工作者處理序的專用位元組)。雖然改進的情況在本例中比較不明顯，但提升的程度還是有達到預期，因為 ASP.NET AppDomain 的負荷遠比移除模組所省下的基準量要高許多。
[圖 2] 靜態和 ASP.NET 工作負載在三種不同設定與 100 個並行用戶端下的記憶體使用量 (專用位元組) (按一下以放大影像)
IIS 7.0 還讓您控制要在應用程式層級啟用哪些模組，以及透過模組先決條件，根據工作負載來控制模組使用情況。雖然這需要進階設定才行，但它可在多網站的環境中，或是對支援多個不同工作負載的應用程式，提供額外的好處。
注意：判斷您所需的功能可能不容易。您不但必須考量支援應用程式架構所需的最基本功能，還必須考慮到應用程式可能間接需要仰賴的任何其他功能。例如，您的應用程式可能需要依賴特定的驗證方法，或仰賴不同 IIS 功能所提供的驗證語意，在這種情況下，若移除這些功能，可能會對應用程式的安全性產生負面的影響。同樣地，您的應用程式也可能有賴一些模組以獲得操作或效能上的成效，在這種情況下，若把它們移除掉，可能會產生行為不當或效能損失。

建置在精簡的 OS 上
Windows Server® 2008 另外還提供了 OS 層級的元件化，讓您用來進一步縮減網頁伺服器的表面。Server Core 是 Windows Server 2008 作業系統最基本的安裝選項，而且內含一組最精簡的核心 OS 子系統。Server Core 對於精簡式 IIS 7.0 網頁伺服器來說，是個理想的環境。
但是在評估 Server Core 時，要注意一些可能會影響您應用程式的限制。Server Core 並不提供 Microsoft® .NET Framework 支援，也就是說既沒有 ASP.NET，也沒有用於 IIS 的 .NET 擴充性，更沒有 IIS Manager。此外，因為沒有 Microsoft Management Console (MMC)，執行本機管理工作得使用命令列工具才行。從效能的觀點看來，如果您已經適當利用 IIS 元件化的優點，執行 Server Core 與完整 Windows Server 實作比起來，在記憶體支配或應用程式工作負載的輸送量方面，可能不會看到有多大的懸殊。這是因為 IIS 和您的應用程式所執行的工作在兩種平台上是一樣的。不過，您倒是會在一個地方看到差異：那就是伺服器的整體支配，就磁碟空間和記憶體使用量兩方面都有不同。
[圖 3] 舉例說明了在完整 Windows Server 2008 設定與在 Server Core 上執行靜態工作負載測試後，支配方面的差異。雖然 IIS 支配在兩種情況下實際上是一模一樣，但 Server Core 的整體 OS 支配規模較小，因此能夠以明顯更少的記憶體來支援工作負載。較小的支配規模也許實際上可以讓您把應用程式工作負載部署在能力較低的硬體上，而把焦點放在應用程式的處理需要上，而不是作業環境上。不用說，這使得 Server Core 成為虛擬化環境的絕佳選擇。
[圖 3] 完整 Windows Server 2008 與 Server Core 在執行靜態工作負載測試之後的記憶體支配比較 (按一下以放大影像)

專門化應用程式拓樸
將應用程式工作負載最佳化時，可把工作負載分隔成不同的部分。比方說，與其在 30 部相同的網頁伺服器伺服陣列上執行應用程式，不如在 10 部網頁伺服器、5 部應用程式伺服器和 3 部執行快取和壓縮的 Proxy 伺服器上執行應用程式。
這樣的專門化之所以可行的原因有好幾個。第一，許多應用程式工作負載的效能主要是看不同的共用資源而定，例如應用程式的不同組件之間可能會爭用的記憶體。爭用這些資源可能會造成瓶頸，而使其他資源無法完整利用每部伺服器。將應用程式的各組件相區隔，可讓組件迅速存取在其他情況下被爭用的資源，而在同一組硬體資源上達成更高的效率。
第二，專門化可讓應用程式達到更廣大的快取位置，進而提升效能。這包括低層級的快取，例如虛擬記憶體轉譯對應緩衝區 (TLB)、檔案系統快取，以及其他作業系統和應用程式快取。另一個取得位置的來源是 CPU。透過把焦點放在特定的應用程式組件上，來減少平行發生的活動數量，應用程式可藉此減少內容切換的數量，並充分發揮 CPU 所執行的工作。
第三，專門化可針對工作負載提供最佳化，讓應用程式的每個組件更有效地運作。如果整個應用程式是在同一部伺服器上受到支援，許多這些最佳化都會因為應用程式不同組件的需要彼此衝突而無法達成。
發生這種情況其中一個常見的地方是 IIS 和 ASP.NET 執行緒處理設定，這個設定會嚴重影響並行處理，並間接影響許多應用程式的記憶體使用量、延遲和輸送量。IIS 靜態檔案工作負載相當不同步，而且需要高並行處理要求限制，但它只需要非常少數的可用執行緒便可成功。另一方面，許多 ASP.NET 功能既是同步也處於長期封鎖狀態，而且需要高執行緒計數，而其他功能仍舊需要較低的並行處理限制來緩和對記憶體的衝擊。您可以透過分隔靜態工作負載，並把要求處理管線各部分分成不同的處理序或伺服器，把每個個別工作負載的並行處理能力最佳化。
最後，專門化還可讓應用程式向外擴充分散的工作負載或彼此獨立的應用程式組件，而達成更高的整體擴充性。這可讓應用程式拓樸在最需要的地方提供更高的容量和重複性，而不是要求您在整個應用程式套用相同的樣板。這種模型下的專門化資源，可以是實體伺服器、虛擬伺服器，甚或是相同電腦上的應用程式集區。
在評估將應用程式拓樸專門化可能的優點時，不妨先從找出應用程式當中的處理或耗用大量資源的瓶頸開始著手。這些地方應該是進行專門化的首選，因為它們在隔離時進行專門化的可能性相當高，而且也因為它們需要有最大的範圍進行向外擴充。接下來則評估將它們隔離是否可讓其餘的應用程式更有效地利用資源。最後需要評估的是，將隔離的應用程式元件結合在一起所需的連接機制，會產生多少額外的負荷。

改良過的應用程式支援
IIS 7.0 還透過 FastCGI 提供了對應用程式架構的延伸支援，這是許多開放原始碼應用程式架構所支援的開放通訊協定，若沒有此通訊協定，這些架構可能無法支援與 IIS 進行穩定且高效能的原生整合。與 IIS 長久以來支援的 CGI (通用閘道介面) 通訊協定不同，FastCGI 在 Windows 平台上提供了更佳的效能。這都要歸功於 FastCGI 的可重複使用處理序架構，這種架構消除了依要求建立處理序的沉重負擔，而讓用戶端可以利用持續作用的連線。
如果您使用 CGI 或其他機制在 IIS 上支援應用程式架構，那麼移轉至 FastCGI 通訊協定也許可達成更佳的效能 (在某些情況下，還能達成穩定性)。
第一個利用這項支援的應用程式架構，是 PHP。事實上，IIS 小組已經與 Zend Technologies 直接合作，確定 IIS FastCGI 實作能與 PHP 順利搭配運作，並且能在 Windows 上提升 PHP 架構內的效能 (如需此專案的詳細資訊，請參閱我部落格上的文章，網址是 go.microsoft.com/fwlink/?LinkId=122509)。如果您混用各種網頁伺服器技術，包括在 IIS 上執行的 ASP 或 ASP.NET 應用程式，以及採用其他技術的 PHP 或其他 FastCGI 相容應用程式架構，也許可以在 IIS 7.0 平台上整合這些應用程式。
將 PHP 和其他應用程式架構移到 IIS 7.0 和 FastCGI，可讓您充分利用各種 IIS 7.0 功能，包括 ASP.NET 整合式管線。此舉提供了一個非常便利的選擇，即使不將它們轉換成 ASP.NET，也可以利用 ASP.NET 服務強化應用程式架構。而且這也讓使用不同架構的應用程式得以彼此協同作業。若想瞭解如何利用這種方式來強化現有應用程式的功能，以及在不變更任何程式碼下提升效能，請參閱我在《MSDN® Magazine》發表的＜使用整合式 ASP.NET 管線增強應用程式的功能＞一文 (網址是 msdn.microsoft.com/magazine/cc135973.aspx)。

增加應用程式密度
IIS 7.0 包括的許多增強功能，都是為了增加可在單一伺服器裝載的應用程式的密度而設計的。這些增強功能不過是 IIS 7.0 為了提升共用主機的品質而提供的許多功能的一部分，當中包括了經過改良的網站佈建，以及更佳的應用程式隔離。
以效能的觀點來看，改進的重點主要放在增加應用程式密度的兩個層面 — 增加可在 IIS 7.0 伺服器佈建的應用程式數量，以及增加在任一指定時間內可使用的應用程式數量。
要注意的是，IIS 7.0 比以往更能夠在每部伺服器上佈建大量的應用程式 — 在一些內部測試中，可在單一伺服器上佈建多達 100,000 個網站。這充分發揮了建立和設定大量網站和應用程式的能力。
注意：若要達成高速佈建，必須移轉到新的設定 API，舊版的設定 API 無法達成高速佈建。另外，並非所有 IIS 設定 API 都提供相同的效能特性，因此為了確保高效能，必須審慎選擇。若不確定，可採用直接運用新 IIS 設定物件的設定選項，包括 Microsoft.Web.Administration 命名空間、AppCmd.exe 命令列工具，以及從指令碼、.NET 或 C++ 程式碼存取的 IIS COM 設定物件。
可以佈建多少網站，以及可以使用多少網站兩者之間，在 IIS 架構上存在著相當重要的差別，此架構是使用持續的應用程式和工作者處理序來執行要求處理。在這種模型下，作用中應用程式會在伺服器上耗用較多的資源，但也因為快取而且不用初始化成本的緣故，因而提供持久的效能。
因為每個作用中應用程式都需要特定的記憶體量以及個別的工作者處理序 (如果採用建議的應用程式隔離模型的話)，所以作用中應用程式的數目主要要視應用程式記憶體支配而定。因此，只提供靜態內容的單一應用程式，它的工作者處理序可能只需要 3MB (而且甚至可以與其他靜態內容應用程式共用相同的工作者處理序)，反之有些動態應用程式即使使用量很低，還可能需要 100MB 或以上的 RAM。這在定義最大密度時，使得 IIS 工作者處理序本身的記憶體負荷與應用程式的使用量比起來，顯得微不足道。
在典型的共用主機情況下，使用所謂的 80/20 分配是很常見的，也就是 80% 的要求送往 20% 的網站。因此不管在任何時間，只會有一小部分百分比的網站處於作用狀態。為了允許有更多的作用中網站，IIS 7.0 提供了作用存留期管理。這可幫助您從非作用中應用程式取回記憶體，以便裝載更多作用中應用程式。
IIS 7.0 引進了一種全新的演算法，稱為動態閒置，它會根據伺服器上可用的記憶體，主動調整工作者處理序的閒置逾時。隨著記憶體越少，更能迅速移除閒置應用程式，從而允許裝載更多作用中應用程式。然而，如果有記憶體可用，逾時也會保持較長的時間，以提供更佳的效能並維持應用程式狀態。除了允許更多應用程式保持作用狀態外，動態閒置還有助於避免發生低記憶體的狀況，這種狀況會因濫用而導致嚴重的效能折損。
為了盡可能裝載最多的作用中應用程式，您也應該利用 64 位元作業系統，因為這可讓 OS 處理 4GB 以上的記憶體。除此之外，您還可以將 IIS 工作者處理序設定在 32 位元模式 (SysWoW64) 中執行，在這種模式中，它們本身會耗用較少的記憶體，而允許 OS 處理比在 32 位元環境中還多的記憶體。

透過壓縮減少頻寬
說頻寬成本是執行網際網路面向的資料中心最高的成本之一，一點也不為過。此外，傳遞要求的內容所需的頻寬，也是觀察應用程式回應能力的關鍵要素。
要減少傳遞應用程式回應所需的頻寬，最有效的方法之一，就是使用 HTTP 壓縮。這可大幅縮小回應的大小，並且在套用到可輕易壓縮的文字內容 (例如 HTML) 時，可減小 10 分之一的大小。最棒的是，實際上所有的桌上型瀏覽器都支援它，而桌上型硬體上的解壓縮成本，比起傳送更少資料所省下的延遲要來得低。而且由於壓縮是根據 HTTP 1.1 通訊協定中定義的內容編碼交涉進行的，因此對於不支援壓縮的用戶端來說啟用它很安全 — 這些用戶端只會接收到未壓縮版本的內容。
IIS 7.0 提供兩種由它前版所提供的壓縮功能：靜態壓縮和動態壓縮。靜態壓縮會預先壓縮靜態內容，並將它儲存到磁碟上，從而允許未來的要求在沒有額外的壓縮負荷下，直接提供已壓縮的內容。動態壓縮則會即時壓縮回應，因此可壓縮由應用程式所產生的回應。IIS 7.0 上的任何應用程式架構皆可利用動態壓縮 — 包括 ASP、ASP.NET 或 PHP。
儘管普遍存在一種迷思，動態壓縮通常沒有過於沉重的 CPU 負荷。事實上，動態壓縮在忙碌的伺服器上，常常花不到 5% 的總 CPU 使用率。您多少可以自由地部署動態壓縮，以盡量節省頻寬，將它用於任何應用程式工作負載。
您還可以設定壓縮強度，以達到所要的壓縮與 CPU 負荷比率，進一步將壓縮負荷最佳化。好處還不只如此，您也可以設定應用程式來啟用壓縮內容的快取，這可透過提供已經壓縮的內容來消除壓縮負荷對快取的衝擊。要注意的是，ASP.NET 和 IIS 輸出兩種快取都已經過選擇性功能的升級，為支援它的用戶端快取壓縮內容，以及處理需要未壓縮內容的用戶端所發出的要求。

媒體位元速率節流
隨著提供媒體內容的網站數量不斷增加，許多企業的頻寬成本也跟著暴漲。更糟的是，因為傳送給用戶端的媒體內容都沒有真正用到，而浪費了高百分比的媒體頻寬。為什麼會這樣呢？
想想看您上次看線上影片時，或在上網時看到影片，您有把整段影片看完嗎？瀏覽影片網站的使用者常常只看了部分影片就移往下一段影片或離開網頁。不過，利用漸進下載來提供影片的網頁伺服器，一般傳遞的資料遠比只播放幾秒鐘的時間所需的資料還多。而大部分的資料根本沒用到。
如果您的影片平均只得到 5 秒的觀賞時間，卻在這 5 秒內傳遞 (緩衝) 值 30 秒的視訊資料，您很有可能浪費了 80% 以上的頻寬呢！
一年前，為了幫採用 IIS 7.0 Beta 測試版的客戶解決這個問題，我寫了一個頻寬節流模組，這個模組會自動偵測視訊位元速率，並且確保伺服器以大致上相同的速率傳遞視訊給用戶端。IIS 媒體小組正是使用這個模組，稱為「位元速率節流模組」(見 [圖 4])，您可以從 iis.net 下載中心 (iis.net/downloads/?tabid=34&g=6&i=1640) 取得。您也可以在 Scott Guthrie 的部落格上瞭解相關資訊 (請造訪 go.microsoft.com/fwlink/?LinkId=122514)。
[圖 4] 位元速率節流將頻寬使用降至最低 (按一下以放大影像)
位元速率節流模組會自動偵測最受歡迎的視訊類型的編碼速率。您可以控制要預先傳送多少資料給用戶端，來消除最初的緩衝延遲 (快速開始)，也可以控制要使用多少百分比的編碼速率來傳遞內容。您還可以設定許多其他選項，例如最大頻寬和並行連線，以及撰寫程式來控制模組。

輸出快取
一般說來，快取是提升執行重複工作的應用程式效能最有效的方法。應用程式特有的效能改進通常都需要大費周章，並且耗盡應用程式的處理負荷，而快取反而可以消弭對相同內容的重複要求所產生的額外負荷。
在 IIS 7.0 之前，IIS 和 ASP.NET 都以 IIS 核心快取和 ASP.NET 輸出快取的形式，提供快取功能。IIS 核心快取所提供效能最大，但主要限於靜態內容。ASP.NET 輸出快取對於快取動態內容來說，是比較完整的解決方案，但是效能較緩慢，而且記憶體管理也比較沒有效率。IIS 7.0 中全新的輸出快取則彌補了 IIS 核心快取與 ASP.NET 輸出快取之間的差距。
IIS 7.0 輸出快取可快取任何應用程式的動態內容，包括 ASP、ASP.NET、PHP，以及任何其他 IIS 7.0 相容的應用程式架構。這項新功能是藉由對內容變化和到期提供基本支援，而對無法由 IIS 核心快取快取的內容實作快取。然而，它還是可以對符合限制條件的內容使用核心快取。
此外，IIS 7.0 輸出快取還針對不需要用到只在 ASP.NET 輸出快取中有提供的進階快取功能 (例如快取相依性或失效) 的 ASP.NET 內容，提供一種更高效能的 ASP.NET 輸出快取替代方案。
說到輸出快取，一般會碰到的挑戰是定義適當的內容到期、失效和變化原則，以便在有效回應快取的同時，維持必要的快取正確性和最新狀態。很多時候，您只要設定適當的快取規則就可以做到這點，不過有些情況需要更複雜的原則，要視執行階段資訊而定。為了處理這種情況，IIS 7.0 輸出快取提供了程式設計 API，可以確保必要的快取行為。如此一來，原本無法獲得快取加持的內容，也有可能從快取獲益了。此外，ASP.NET 整合式管線也可讓您將 ASP.NET 輸出快取用於非 ASP.NET 內容。
針對動態內容部署輸出快取可能需要一點技巧，也可能需要多層策略，以利用 IIS 7.0 平台上不同快取功能的效率和彈性。通常其步驟包括描述多個會影響回應的參數，以及定義到期和失效兩種策略來保持快取的最新狀態，接著再判斷哪一個快取將支援必要的語意。
複雜歸複雜，到最後總是值回票價。透過實作 IIS 7.0 輸出快取，可以把應用程式的整體輸送量提高多達好幾次方倍，而資料庫和商務層元件上的負載也會有相對的降幅。

將 ISAPI 程式碼轉換成 IIS 7.0 模組
IIS 7.0 引進了全新的伺服器 API，這是所有 IIS 7.0 模組的基礎。它取代了前版 IIS 中所使用的舊式 ISAPI 篩選器和 ISAPI 延伸模組 API。對於不需要支援舊版的新模組來說，全新的 API 不但更容易使用，有利於產生更可靠的伺服器端程式碼，而且功能還更加強大。
不過，IIS 7.0 也可以讓您透過相容性層支援現有的 ISAPI 篩選器和延伸模組，而這個相容性層是透過選擇性的 IIS 7.0 模組實作而成。這麼一來，現有的 ISAPI 元件不需經過重寫，就可以在 IIS 7.0 上運作了。
縱然使用現有的 ISAPI 投資可減輕 IIS 7.0 移轉的障礙，但您還是應該慎重考慮將舊版 ISAPI 程式碼移植到全新的 IIS 7.0 API。這樣不但可以消弭 ISAPI 相容性層的額外負荷，更能享受 ISAPI 元件所沒有的效能效益。根據 ISAPI 元件所執行的工作而定，這些效能效益可能相當可觀。譬如，IIS 7.0 模組 API 提供了對快取設定中繼資料和其他與網站、應用程式和 URL 相關任意資料的內建支援，明顯加速元件的內部作業。
除此之外，IIS 模組 API 還可讓模組以非同步的方式執行長期執行的作業，例如接收要求實體資料或傳送回應。以非同步的方式執行這些工作，可讓伺服器服務相當多的並行用戶端 (上萬)，而不致於因為要求執行緒的數量限制，只能服務好幾十個，或最多好幾百個用戶端。以非同步的方式處理，還可以免除處理對應用程式內其他要求和活動所產生的影響、減少記憶體使用量，以及提供更高的 CPU 使用率。
除了有影響效能的特定模式之外，原生 API 還提供開發人員更大的彈性來完成要求處理工作。這可讓您改良伺服器元件的設計，轉而達成大規模的效率。例如，過去有些篩選工作需要用到萬用字元 ISAPI 延伸模組和子要求延伸模組，但現在已經可以在原始要求期間於模組內執行，而且還可以針對回應啟用 IIS 核心快取。
如果要判斷出最佳設計以充分發揮移轉的效益，可能還需要建立一些原型和試驗。基於 ISAPI 與 IIS 7.0 模組 API 之間根本的架構差異，直接移植一途不一定是適當的選擇。還好 IIS 7.0 模組 API 使用起來也比 ISAPI 簡單，使得移轉作業沒有那麼困難。

伺服器擴充性
IIS 7.0 提供端對端的擴充能力，這必須對伺服器作業瞭如指掌，但它也大大增加提升應用程式特定效能的可能性。只要對伺服器架構和要求處理具備一些了解，您就能利用這項擴充能力，針對您的應用程式、工作負載和硬體需求量身訂做自訂效能解決方案。
這甚至包括以自訂實作來取代任何內建的 IIS 7.0 功能。當然，IIS 7.0 功能雖然經過多次的最佳化和效能測試，但是並沒有針對各種可能的用途而最佳化。因此，針對特定的工作負載建置最佳化，也許可以提升特定模組的效能。例如，您可以選擇重新實作目錄清單模組來快取記憶體中的目錄清單，而不是使用檔案系統 API 來列舉檔案。
另外，您也可以利用擴充性來建置新的效能功能。這類功能的現成範例包括輸出快取，壓縮模組和幾個其他內部快取。
若要判斷是否需要自訂效能功能，除了必須認識應用程式及其工作負載的效能特性外，還必須了解您需要解決的瓶頸。IIS 7.0 為效能分析提供了豐富的診斷支援，讓您需要的功能需求和可能的設計更加清楚。

總結
儘管 IIS 7.0 版本主要是功能上的更新，但它在模組化架構、設定性和新效能功能方面，也明顯提升不少效能。這些改進將為您舖路，幫您透過伺服器整併和更低的頻寬成本，省下可觀的業務成本，除此之外，它也提供了更完備的使用者體驗。
為了適當運用這些改進功能，對目前的應用程式平台進行徹底的分析，並且對 IIS 7.0 架構有相當程度的了解，往往是不可少的。若要進一步了解本文所述的 IIS 7.0 架構和功能，請造訪 iis.net。我在 mvolo.com 上將發表更多關於主動運用 IIS 7.0 來提升應用程式效能及降低作業成本的技巧的部落格文章。
Mike Volodarsky 是 Microsoft IIS 小組前任程式經理。過去五年來，他努力推動 ASP.NET 2.0 和 IIS 7.0 核心功能的設計與開發。現在，他使用 IIS 7.0 和 Windows Server 2008，建置用於高效能 Web 伺服陣列的進階網頁伺服器技術。Mike 是《IIS 7.0 Resource Kit》一書的主要作者，並積極為《MSDN Magazine》和他的 IIS 7.0 部落格 (mvolo.com) 撰文。


行動性
將企業營運應用程式行動化
Matt Fontaine
綜覽：
  • 行動 LOB 應用程式的商務需要
  • 利於 mLOB 開發與部署的強固平台
  • 無線安全性、管理和佈建

目錄
推動和管理遠端工作者
安全性和裝置管理
互通性
IT 和使用者產能
開發和散佈
結語
除了傳統的語音、訊息和產能功能之外，當今許多企業也希望行動專業人員能夠透過行動 LOB (mLOB) 應用程式，存取跟在
辦公室裡一樣的企業營運 (LOB) 系統。候選系統一般包括客戶關係管理 (CRM)、企業資源規劃 (ERP)、商務智慧 (BI)、財務，以及會計應用程式。擁有 mLOB 功能顯然能讓行動使用者存取和使用豐富的商務應用程式，並在外出時與資料進行即時互動，從而縮短銷售時間，改善客戶滿意度，以及提高業務產能。一些典型的商務案例包括：
  • 銷售小組可使用 Microsoft Dynamics™ CRM Mobile，隨處檢視和更新客戶資料。另一個 mLOB 應用程式可讓他們存取即時的報價和庫存資料。再者，銷售人員可使用專門裝置，在外收集銷售文件，包括填寫訂單到收集簽名等。事實上，甚至還有適用於 Windows Mobile® 裝置的銷售點應用程式，可用來掃描條碼及讀取信用卡，然後連線到後端 LOB 資料系統進行處理。
  • 使用 ERP 解決方案可排定外勤服務工作人員的時間表，根據人員的約定和位置來決定路線，而且可以使用具 GPS 功能的 Windows Mobile 裝置自動加以追蹤。外勤服務人員只需要收集當天的第一份工作，因為他們一完成一項工作，就會自動分派他們到下一個工作 (見 [圖 1])。
  • 對於製造業的公司，具無線頻率識別 (RFID) 掃描功能的 Windows Mobile 裝置，可在具有 RFID 功能的倉庫中管理庫存，以無線方式立即將資訊填入資料庫中。另外，還有針對危險的工作環境設計成本質安全耐用的 Windows Mobile 裝置，以便在需要的地方傳遞資料，同時達到重要的安全需求。
  • 當天必須在客戶會議、董事會議還有媒體活動之間趕場 — 可能遠離所在的辦公室 — 的行動主管，可以在剛好有需要的時候取得財務、開支報告或客戶資訊。
這些案例以及其他許多商務案例，都驅使尖端科技公司採納 mLOB 應用程式。本文將向您說明 Windows Mobile 和 Mobile Device Manager 如何搭配運作，從而讓 IT 專家有能力部署當今企業越來越需要的豐富行動功能。
[圖 1] 顯示完成外勤服務工作的 mLOB 應用程式

推動和管理遠端工作者
Windows Mobile 已證實是多元化產業當中推動遠端工作者的強大平台，因為它與現有以 Windows® 為基礎的 IT 資產搭配無間，它的行動訊息和整合通訊 (UC) 是由 Exchange Server 和 Office Communications Server 提供，而且使用者和 IT 專家等都很享受熟悉的 Windows 體驗，不需要什麼教育訓練就能開始使用及了解。
隨著 Mobile Device Manager 的發行，Windows Mobile 也變成商務環境中部署行動裝置更加吸引人的選擇。Mobile Device Manager 可讓行動裝置使用 Active Directory® 和群組原則，以無線的方式進行佈建、管理和保全，使得裝置仿如網路化的電腦或檔案共用一般。原則和軟體也可以自動發送到電話，而安全性、軟體和硬體原則更可以利用豐富的庫存報告功能，以高度細微控制的方式來管理。
這些改革背後的動力是認為行動裝置應該是 IT 系統的自然延伸，而不是存在它們自己中介軟體的泡泡裡。對於希望明顯超越 Windows Mobile 裝置上的訊息、通訊和基本產能的公司，使行動裝置成為網路上的第一等公民是它們的第一道課題。
那麼，若是貴公司也想要超越基本功能呢？讓我們看一下 Windows Mobile 和 Mobile Device Manager 的功能如何透過為 mLOB 應用程式提供絕佳的平台來達成這樣的使命。

安全性和裝置管理
這些功能提供了對關於客戶、財務、庫存等商務關鍵資訊隨時隨地存取的能力，讓 mLOB 應用程式顯得魅力四射，但也使得安全性更具挑戰。使用者可在各種不同的位置，透過公用網路從小型裝置輸入和存取資訊。
許多公司已經透過具有虛擬私人網路 (VPN) 連線的膝上型電腦，在內部網路上提供對 LOB 應用程式及其他共用資源和工具的行動存取。Mobile Device Manager 則利用 Mobile VPN，將這項功能延伸到 Windows Mobile 裝置 (見 [圖 2])。Mobile Device Manager 閘道伺服器允許在 Windows Mobile 用戶端與網路之間建立經過 IPsec 加密的通道，在公用連線 (例如網際網路或無線封包資料網路) 上安全存取公司防火牆背後的資訊。Windows Mobile 在這種環境下支援多種類型的加密。
[圖 2] 透過 Mobile Device Manager 的進階裝置管理、安全性和 Mobile VPN (按一下以放大影像)

互通性
裝置和儲存卡上的資料，可設定和強制加密原則。使用 mLOB 應用程式的工作者可能會下載機密資訊到他們的行動裝置，而這比其他網路裝置更容易弄丟。所幸，任何有啟用 Mobile VPN 的裝置，只要有資料連線，都可以執行遠端裝置清除 (見 [圖 3])。比方說，如果藥品銷售人員從公司的 CRM 系統下載客戶檔案到她的行動裝置，然後粗心地把裝置遺留在計程車裡面，就可能產生嚴重的後果。
[圖 3] 若行動裝置遺失或遭竊，可從遠端移除上面的資訊。(按一下以放大影像)
Mobile Device Manager 正是為了處理這類問題而設計的。事實上，Mobile Device Manager 可讓您管理幾乎各層面的 Windows Mobile 裝置功能和使用者原則，從停用特定硬體功能到控制要安裝哪些應用程式，到限制對特定網路資源的存取，無所不包。所有這些動作都可以從單一解決方案完成，而且可透過無線的方式進行。當使用者具備 mLOB 能力時，這些功能甚至變得更加重要。例如，藍芽網路可能會允許資料下載到未受控制的裝置，因此您應該會希望防堵使用者使用它。您可能只想讓特定的使用者能夠安裝行動會計軟體用戶端，這麼一來，就可以將它設定成自動上載和安裝到只有那些需要它的使用者了。
其他資源
  • Microsoft System Center Mobile Device Manager 2008 (
  • Microsoft System Center Mobile Device Manager 2008 簡介
  • Microsoft System Center Mobile Device Manager 2008：技術白皮書
  • Microsoft System Center Mobile Device Manager 2008 針對企業讀者的簡介
  • Windows Mobile Line of Business Solution Accelerator 2008
再者，Mobile Device Manager 不要求公司資料必須經過協力廠商 Network Operations Center (NOC)，因為 NOC 不過是另一個可能的可用性或安全性中斷點。基本上，Mobile Device Manager 可讓您全權控制幾乎任何規模的行動裝置部署 — 讓您更方便的部署、管理和保護 mLOB 功能。
網路整合則提供另一種優勢：所有高度細微的控制都是透過 Active Directory 和群組原則的形式完成，完全不需要從其他網路用戶端分開管理行動裝置。這不但可省下不少金錢與時間，最重要的是，還可讓您採用一致的安全性和存取原則。群組原則是控制行動存取 LOB 資料一個相當有效的方法。它可以輕易提供給需要存取的人，而對於那些不需要存取的人，則可一併或個別加以限制。
管理 mLOB 部署 (一般也包括行動裝置) 另外還有一大考量，那就是與現有基礎結構的互通性。有些行動裝置作業系統會以其他 IT 形式中斷連線，因此需要用到它們自己的語言、伺服器和工具，這一點與 Windows Mobile 不同。當您在行動裝置上提供複雜的應用程式和重要的資料存取時，這些因素就越來越重要了。
Windows Mobile 與 Mobile Device Manager 就提供這樣的互通性。Windows Mobile 也是一種 Windows OS，與 Windows 架構的 IT 資產搭配無間，像是 Microsoft® Exchange Server、Microsoft Forefront™、SQL Server®，以及 Microsoft Office Communications Server。這種內部家族的互通性，使得設計和建置先進 mLOB 功能更加容易。
舉例來說，提供應用程式間通訊的 Microsoft .NET Framework 技術 Windows Communication Foundation (WCF)，可利用服務導向架構 (SOA，將 Exchange Server 當作 mLOB 實作的訊息傳遞公用程式。全新的 Sync Framework 可讓偶爾連線的工作者保持在最新狀態，方便在使用 SQL Server Compact 3.5 的 Windows Mobile 裝置與 SQL Server 2008 上的公司資料之間同步處理資料。若沒有一套與這麼多現成網路資源搭配運作的行動基礎結構，要實作這些案例可能更加困難。

IT 和使用者產能
提高產能是 mLOB 部署的重要目標。但如果它的功能對工作者來說難以使用，對 IT 專家來說也難以管理的話，那麼它所耗費的成本，可能會超過它所帶來的好處，或者至少也會降低投資報酬率。開發 Windows Mobile 的目的，就是讓它與桌上型 Windows 的體驗盡可能相似，使它所提供的熟悉度，能夠為所有相關人員提高解決方案的價值。
就 IT 方面來說，使用 Mobile Device Manager 的 Windows Mobile 是為了將 Windows Mobile 裝置帶入網路主流而設計的。而它是透過使用熟悉的技術，尤其是 Active Directory 和 Windows Server® 來達成此目標。Mobile Device Manager 是 IT 管理解決方案 System Center 系列的一部分，受到世界各地許多 IT 專家的廣泛採用。熟悉 Windows 環境的 IT 專家不用學習全新的工具和作法，而是使用已知的 Microsoft Management Console 嵌入式管理單元。
使用者也一樣，以類似桌上型電腦的體驗使用 Windows Mobile，可幫助他們快速上手。他們不必學習新的應用程式，只要使用 Office Mobile 組合軟體 (包括 Office Mobile Outlook®) 即可完成工作。他們不用擔心裝置管理，因為裝置會集中管理。mLOB 應用程式可以設計成以使用者熟悉的桌上型版本的方式來運作，新工具的外觀和行為也可以建置得像典型的 Windows 軟體一樣。這樣的使用者熟悉性可減少支援電話並降低事件嚴重性 — 對 IT 專家而言也是一大福音。
Windows Mobile 和 Mobile Device Manager 平台的其他方面也可增強產能。除了快速重新連線的功能外，Mobile VPN 甚至可以跨網路提供完美和持續的連線能力，幫助使用者在他們需要的時候連線，從而減少服務台電話數量，因為這也是另一個打電話取得支援的常見原因。Windows Mobile 所支援的多重裝置表單係數，可讓公司標準化為少量的裝置，同時讓員工選擇合乎所需的裝置。裝置多元化也有利於各種提高產能的 mLOB 案例，像是以條碼為主的庫存管理，或是以具有 GPS 功能的裝置來決定路線。

開發和散佈
定義 LOB 應用程式的屬性 — 資料豐富性、效力和專門功能 — 在針對應用程式產能而設計的行動平台上更容易發揮威力。Windows Mobile 為行動工作者提供了類似桌上型電腦的體驗，使得 mLOB 應用程式開發、散佈和管理起來更加容易。
一開始，Windows Mobile 支援稱為 .NET Compact Framework 的 .NET 版本。由於 .NET Framework 是世界各地上百萬開發人員所採用的程式設計工具組，許多 IT 產業內部早已具備針對 Windows Mobile 自訂和建立 mLOB 應用程式的開發技能。如果他們不具備這些技能，也可以迅速在市面上找到。
Windows Mobile 也支援大量商用 mLOB 應用程式。Microsoft 是把 mLOB 解決方案，當作它的 Microsoft Dynamics 產品系列的一部分來提供，包括 Microsoft Dynamics CRM Mobile 和 Microsoft Dynamics AX Mobile Sales。另外，Microsoft Dynamics Mobile Development Tools 更提供開發人員將軟體延伸到行動環境的技術。Microsoft 已承諾要把其他 Microsoft Dynamics 解決方案行動化，另外還將提供 Microsoft Dynamics NAV 支援。而最主要的 LOB 解決方案，諸如 SAP、Siebel、PeopleSoft 和 SalesForce.com，也提供了與它們應用程式組合軟體相容的 Windows Mobile 版本。
在購買或開發 mLOB 應用程式之後，即可使用 Mobile Device Manager 和 Windows Server Update Services 3.0，以無線方式加以部署和管理。另外，也可以使用群組原則來設定哪些裝置接收應用程式，以及它們可以存取的功能。請注意，更新應用程式也可以用這麼簡單的方式進行。

結語
有越來越多的公司提供 mLOB 應用程式給員工和主管階層，為那些負責部署和維護 IT 系統的人員增添了新的考量點。Windows Mobile 和 Mobile Device Manager 是以具網路功能的行動裝置來實現遠景，為 mLOB 的開發和部署提供一個容易管理的平台。這樣的平台在充分發揮安全性和使用者產能的同時，也將 IT 部門的頭痛問題和基礎結構投資減至最低。加上 Mobile Device Manager 可將 mLOB 部署調整至大量使用者，因此降低了每位使用者的 mLOB 開發和部署成本，也提高了每位使用者的 ROI。這麼一來，就減輕了管理 Windows Mobile 與 Mobile Device Manager 的負擔，讓您有更多時間思考如何最能有效利用 mLOB 應用程式 — 而不是如何操作它們。

Matt Fontaine 是居住在華盛頓州西雅圖的作家兼顧問。他涉獵的行業相當廣泛，包括高效能運算、企業軟體、精算、商用房地產、工程、建設以及消費包裝產品。Matt 是常青州立大學 (The Evergreen State College) 的光榮校友。


安全性
了解共用帳戶密碼管理
Chris Stoneff
綜覽：
  • 共用與特殊權限帳戶密碼的風險
  • 儲存密碼的方式
  • 管理和保護共用密碼
  • 唯命是從

目錄
瞭解問題
越長越好
網域暴力
藉口、藉口，全是藉口
立規者的要求
自動化方法
深思熟慮
定期變更共用與特殊權限帳戶的密碼，例如，
內建的系統管理員或根帳戶、防火牆帳戶，甚或是處理帳戶，是系統管理員必須不斷應付的常見工作之一。就定義而言，內建系統管理員或根帳戶指的是每個 Windows® 版本、Linux 和 UNIX 上的帳戶，而且這些帳戶始終具備相同的安全性識別元 (SID) 或使用者識別碼 (UID)。防火牆帳戶則是指您建立用來加速緊急存取安全系統的其他那些帳戶。這些防火牆或系統管理員帳戶有時候會被未經授權的使用者，在發生問題時用來存取重要系統。最後，處理帳戶則是您用來執行服務、工作、COM+ 應用程式，以及內嵌項目 (例如指令碼和其他必須登入的二進位檔案) 的帳戶。
您目前可能是使用安裝指令碼或映像來部署系統。此外，您所有的工作站或伺服器可能都擁有相同的系統管理員帳戶名稱，以及同一個 8 字元密碼，而且可能從系統最初部署後都沒改過。所以，我才說「同一個」密碼，而不是「很多」密碼。
系統管理員可能為了採用最佳作法或達到循規的需求 (例如沙賓法案 (SOX)、付款卡業 (PCI)，或是美國健康保險流通與責任法案 (HIPAA)) 而不得不變更這些密碼。有時候是因為知道這些密碼的前任系統管理員或技術人員離職，系統管理員害怕發生密碼被公開的安全性缺口或無法處理信用卡而更改密碼。撇開這些因素不管，系統管理員非得變更這些密碼，純粹為了公司的安全性，以及公司必須保護的資料。

瞭解問題
當處理這些帳戶及其密碼時，必須先了解幾個要素：
  1. 密碼使用的時間越長，就越不安全。
  2. 原則是，越長的密碼越難破解。
  3. 電腦驗證的方式並不會因為它們隸屬於網域而有所改變。每個網域的核心在於工作群組。
「密碼使用的時間越長，就越不安全」其實是一種誤解。它真正的含意是，只要決心入侵電腦，時間夠長就能辦得到。如果有人問：「破解密碼需要花多久的時間？」，我通常會說答案不一定，並且提供一些線索，以便針對特定系統找出適切的答案：
  • 有多少人知道密碼？
  • 這些人全都還在公司工作嗎？
  • 如果知道帳戶密碼的一些人已經不在公司工作，他們是心平氣和地離職嗎？
  • 您拒絕從磁碟片、CD 或 DVD 磁碟機，或是網路開機嗎？
  • 電腦的使用者也是本機系統管理員嗎？
  • 您所有系統的特殊權限帳戶都是使用相同的密碼嗎？
從這份清單的前頭說起，我們可以假設秘密要是越多人知道，就越可能變得眾所皆知。我還記得曾在一家公司上班，公司內的系統管理員覺得把共用密碼設成相同的值，然後告訴 IT 人員還有實習生這個密碼，要比在需要的時候為他們輸入密碼要方便得多了。不用說，不消多久的時間，公司便開始發現電腦滿是各種未經核准的設定，而且一般的網路使用者也能登入這些帳戶。
如果所有這些知道密碼的人都還在這家公司工作，而且個個都是開心又負責的員工，那麼倒是可以稍微舒緩這類的存取風險。但是您永遠不知道何時會出現惡意的使用者需要對抗。如果當中有任何使用者是不滿離職，外頭就有個敵意份子，知道怎麼使用無法追蹤的帳戶入侵您的網路。
若是您不拒絕從硬碟以外的任何媒介開機，那麼也等於是允許使用者使用非授權的映像開機，例如 Windows PE 或各種 Linux 系統，這些系統可直接從電腦的檔案系統讀取並存取電腦受保護的儲存區 (我應該註明，許多安全性漏洞確實是來自內部。即便所有人員和實習生仍舊受雇於公司，還是沒法保證密碼和系統是安全的)。
我知道有很多人仍繼續登入前雇主的網路是因為他們可以，所以有何不可。這種不變更系統密碼的錯誤習慣雖然有點引人發噱，但一想到他們若心存惡意而可能造成的傷害，不免令人惶恐。
如果您讓使用者能夠從 DVD 或網路開機，那麼您可能無法稽核他們進行的動作。也就是說，Linux 開機磁碟或網路映像通常可以直接存取您的檔案系統。如果您的系統對特殊權限帳戶使用相同的使用者名稱和密碼的話，您的系統顯然是等著遭大殃。不過我們還是稍後再詳細討論吧。
密碼使用期限和長度跟用來破解密碼的方法息息相關。若您應付的是暴力破解方法，那麼您面臨的問題其實是時間。密碼越不常變更，就等於留更長的時間讓破解者取得密碼。
同樣地，更長的密碼因為含有更多字元變形，因此需要花更長的時間破解。所以說，務必要考量您的密碼長度是否少於 7 個字元，8 至 14 個字元，還是包含 15 個或以上的字元。另外，若是密碼少於 15 個字元，而且您使用的是 Windows 的話，您是根據系統設定還是透過群組原則來停用 LAN Manager (LM) 雜湊？
密碼的長度究竟有什麼影響？就 Windows 來說，答案很簡單。姑且不談 Microsoft 雜湊程序的歷史，Microsoft 針對密碼實作兩種雜湊類型，也就是 LM 雜湊和 Message Digest 4 雜湊 (MD4)。Microsoft 預設是使用 LM 雜湊，而且除非您明確關閉這些雜湊的儲存選項，否則針對所有長達 14 個字元的密碼都會儲存值。這些密碼會分成兩個 7 字元的值 — 第一個值用於前 7 個字元，第二個值用於後 7 個字元，如 [圖 1] 所示。
[圖 1] 範例雜湊表
帳戶名稱 | RID | LM 雜湊 | NT 雜湊 | 密碼 | 備註
Administrator | 500 | aad3b435b51404ee:aad3b435b51404ee | 31d6cfe0d16ae931:b73c59d7e0c089c0 | 空白密碼 | LM 雜湊與 20 個字元的密碼 LM 雜湊一模一樣。
Administrator | 500 | 0182bd0bd4444bf8:aad3b435b51404ee | 328727b81ca05805:a68ef26acb252039 | 7 個字元密碼 = 1234567 | 表示前 7 個字元的前半部與 8 字元密碼相同。
Administrator | 500 | 0182bd0bd4444bf8:36077a718ccdf409 | 0182bd0bd4444bf8:36077a718ccdf409 | 8 個字元密碼 = 12345678 | 表示前 7 個字元的前半部與 8 字元密碼相同，但後半部不同。
Administrator | 500 | aad3b435b51404ee:aad3b435b51404ee | b79d07c2ecb3d565:033ece663f5a0b2e | 20 個字元密碼 = 9876543210 9876543210 | LM 雜湊與空白密碼一樣，因為超過 14 個字元的密碼無法建立 LM 雜湊。
Fred | 1221 | e52cac67419a9a:224a3b108f3fa6cb6d | 8846f7eaee8fb117:ad06bdd830b7586c | 一樣 | 在這三個範例中，有看到 LM 與 NT 雜湊其實是一樣的嗎？這表示所有這些帳戶的密碼全都一樣。Microsoft 永遠不會改變雜湊演算法。
Monday | 1385 | e52cac67419a9a:224a3b108f3fa6cb6d | 8846f7eaee8fb117:ad06bdd830b7586c | 一樣
SvcAcctX | 1314 | e52cac67419a9a:224a3b108f3fa6cb6d | 8846f7eaee8fb117:ad06bdd830b7586c | 一樣
因此，如果您的密碼長度只有 7 個字元，便會包含在單一 LM 雜湊中。Microsoft 好幾年來都建議您，密碼至少要使用 8 個字元。原因是，這樣一來，第 8 個字元就會強制將密碼分成兩個 LM 雜湊值。
不過有一點要注意的是，LM 雜湊其實眾所皆知，而且很容易避開。目前的解決方案採用它們的唯一目的，是要幫助維持與下層系統的回溯相容性，例如 Windows NT® 4.0。
時至今日，您應該使用至少 15 個字元的密碼 (通關密語比較貼切)，最好是更長，因為根據定義，它們將不會產生 LM 雜湊。如果在您的環境中強制使用 15 個字元的密碼不可行，您應該停用在映像建立程序 (利用本機原則) 和 Active Directory® 群組原則兩者中儲存 LM 雜湊。
此原則可在 [電腦設定]\[Windows 設定]\[安全性設定]\[本機原則]\[安全性選項] 中找到。只要將 [網路安全性: 下次密碼變更時不儲存 LAN Manager 雜湊數值] 原則設為 [啟用] 即可。
重要的是，要記住儘管良好的原則會規定使用大小寫字母，以及數值或特殊字元，但更完善的原則也當規定使用 15 個字元或以上的密碼長度。

越長越好
目前有個用來入侵電腦方法，叫做 Rainbow Tables，它便是利用 LM 雜湊作為弱點。但是較長的密碼可消弭 Rainbow Tables 的成效。
我很驚訝的是，很多負責安全性的系統管理員竟然對 Rainbow Tables 一知半解 (或一無所知)。要建立 Rainbow Tables 來處理不同的演算法，方法有很多。但這些其實只是從 0-14 個字元預先計算所有 LM 雜湊的清單。
對於 Rainbow Tables，要注意的是，攻擊者必須先取得 LM 雜湊。這也把重點帶到了之前的疑問，那就是系統要如何開機 (CD 或 DVD)，或是您的使用者是否是本機系統管理員。最後，這些 LM 雜湊在幾秒的時間內，使用像是 pwdump 的免費工具，就擷取得到。藉著使用 Rainbow Tables，接著會搜尋雜湊來判斷密碼。
為了滿足我自己的好奇心，我在系統的內建系統管理員帳戶上設定了一個密碼。它有 14 個字元，而且包含各種大小寫字母，還有特殊字元和數字。我接著使用從網際網路上免費下載的 Rainbow Tables，結果我竟然能夠擷取系統上所有帳戶的密碼雜湊，並在不到兩分鐘的時間內判斷出系統管理員的密碼。
我必須承認，看到第一個 LM 雜湊被破解，接著第二個雜湊被破解，的確蠻酷的，只要再把它們湊在一起就可以得到您的密碼。在這裡要重述我的重點，那就是，假如我使用之前討論的原則停用 LM 雜湊的話，即使不能完全封鎖此一特定的攻擊標的，至少也能強加限制。

網域暴力
身處網域當中並不能解決問題。網域當中的電腦仍舊以相同的方式進行驗證。而且，我之前說過，每個網域的核心在於工作群組。這句話雖然簡單，卻不一定容易明瞭。我就曾對這個主題進行過多次討論，而且常常發現自己需要提醒系統管理員存取電腦的必備條件 — 就是使用者名稱和密碼。之後，我還得說明 Windows 如何在工作群組內運作。
如果您嘗試存取某系統，就必須提供使用者名稱和密碼給遠端系統。透過整合式驗證的運用，Windows 會試著為您進行這項作業。這表示，如果您存取其他 Windows 系統，Windows 將會使用您目前登入的使用者名稱和密碼。所以，若是您嘗試存取其他 Windows 系統，而遠端系統也擁有相同的使用者名稱和密碼的話，系統永遠不會提示您輸入使用者名稱和密碼。
這也稱為傳遞驗證，整個程序在工作群組和網域間一樣可行。最糟的情況不過是系統要求您輸入使用者名稱和密碼，也就是說您必須重新輸入您的登入資訊。
現在即使您將工作站或伺服器加入網域，而 Active Directory 變成您的中央帳戶存放庫，這些系統上所有的本機安全性帳戶管理員 (SAM) 或本機帳戶存放區也不會就這樣神奇地消失。看起來發生在這些本機 SAM 身上的，就是它們不受管理也不受保護，而這正是問題的根源。您上次變更系統上的內建系統管理員或根帳戶是什麼時候？不妨下載任一種報告公用程式，顯示所有帳戶的密碼使用期限，並看看結果是否能通過稽核。
如果您還不清楚我的用意，隨便找一台網域工作站，然後以具備系統管理權限的網域帳戶登入。開啟系統上的電腦管理，再建立一個稱為 ToldYouSo 的本機使用者。給帳戶設個密碼，然後把它加入到您系統的本機 Administrators 群組。在第二部網域系統上重複這個程序。
現在，從其中一部系統中，以本機 ToldYouSo 帳戶的身分登入，然後前往 \\systemName\c$ 嘗試存取第二台機器。您將能夠存取系統管理共用，而且系統甚至不會提示您輸入密碼！我希望您不會被這個例子嚇到，如果嚇到您，請從中學得教訓，並容我再次重述：即使您的系統隸屬於網域，也改變不了所有這些系統仍舊是以工作群組的方式運作的事實。
重點是，假如您的共用和特殊權限帳戶所使用的密碼鮮少變更，您的共用和特殊權限帳戶就有風險。只要時間夠，就足以入侵您的網路。

藉口、藉口，全是藉口
當我跟系統管理員，甚或是 CIO 對談時，常常聽到不肯變更這些帳戶密碼的幾個主要理由是：
  • 我們有上千部系統，沒有時間或人力來變更這些帳戶。
  • 我們沒有所需的預算。
  • 我們已經完全停用系統管理員帳戶。
  • 我們從沒被入侵過，所以我們真的不認為這有什麼問題。
  • 稽核人員沒有發現。
雖然我可以體諒前兩個理由，但這都不算藉口。一想到藉故不處理這個問題的公司，可能存有我的私人資訊，我就不寒而慄。
雖說並非網路內的每一部系統都會存放機密資訊，但這些電腦的使用者確實有可能存取機密資訊，例如您的身分證號碼、醫療記錄或財務資料等。身為系統的系統管理員，使用者可以安裝按鍵記錄程式和螢幕擷取公用程式，阻止套用群組原則，將填充碼引入各種子系統來擷取和傳輸資料等等。當使用者在個別的電腦進行這些作業時，因為他也稱為 Administrator 而使得要捕獲這名惡意使用者難上加難。
您知道停用 Windows 中的內建系統管理員帳戶並不能阻止您以該帳戶的身分登入嗎？試試這個動作：以安全模式重新啟動您的系統，然後以內建系統管理員帳戶的身分登入。您多半可以使用從原始映像發給帳戶的密碼順利登入。如需有關此行為的詳細資訊，請參閱 Microsoft® 知識庫文章＜如何在停用系統管理員帳戶之後存取電腦＞(support.microsoft.com/kb/814777)。

立規者的要求
應付 SOX、PCI、HIPAA 和其他法規，可能會讓您一個頭兩個大。瞭解它們的需求可能要費點功夫，畢竟它們既廣泛，定義又不清楚。一般而言，所有這些法規的要求大致可總結如下：
首先，您必須確定有誰可隨時存取所有特殊權限帳戶和資訊，並提供方法證明。這在各種案例下都屬於良好行為 — 特殊權限帳戶是具備權限在任何系統上進行任何動作的帳戶。這是內建系統管理員，也是防火牆帳戶。這些是替您工作的整組支援工程師和每名系統管理員可能都知道的帳戶。
當您選擇實作一套解決方案來管理這些共用帳戶密碼時，您等於是為內建系統管理員建立一份目前不存在的稽核記錄。您得到的會是變動不定的密碼。既然解決方案已自動化，所以您不會浪費好幾個星期的生產力來變更這些密碼。最後，由於解決方案提供稽核功能，貴公司將更輕鬆通過稽核。

自動化方法
處理這類帳戶最有效的方法，是定期變更帳戶，不讓兩個帳戶共用相同的密碼。若共用密碼，一個系統遭到入侵表示其他系統也跟著遭殃。換句話說，不應該有共同的本機或網域帳戶。
當您使用可管理和隨機安排密碼的自動化解決方案時，請避免只做稽核者所要求的最低限度工作。比方說，如果使用 8 個字元的密碼，與使用 15 或 20，甚或 127 個字元的密碼比起來，所花的精力一樣，何必只使用 8 個字元的密碼呢 (見 [圖 2])？
[圖 2] 使用自動化建立超長的密碼 (按一下以放大影像)
另外，可考慮每天隨機安排特殊權限帳戶，如 [圖 3] 所示。如果每個月或每兩個月，甚或每天都可以這麼做，實在沒有理由每隔 90 天才做一次。畢竟，如果程序已自動化，您應該不用多費力氣。加上如果您定期這麼做的話，也可強制使用者從工具的稽核擷取介面復原密碼，提供過去不存在的稽核記錄 (如果您目前是把寫下的密碼放在信封裡面，然後鎖在某人辦公室角落的保險箱裡面，您就無法像使用密碼管理解決方案一樣保留這些密碼的稽核記錄)。
[圖 3] 每天隨機安排特殊權限帳戶 (按一下以放大影像)
最後，確定密碼在復原時，在復原後的一段固定時間內可以而且也會重新隨機安排。我指的不是您建立的排程隨機安排工作，我說的是建立只在幾個小時內有效，而不是幾個月內有效的單次用密碼。再次強調，這個方法會強迫使用者從工具的稽核擷取介面復原密碼，進而提供稽核記錄。

深思熟慮
共用帳戶密碼管理的問題務必要解決。也就是說，您應該建立一種能夠可靠且定期變更密碼的方法。這套解決方案必須能夠調整，而且富有彈性。它也必須提供安全的密碼存取，而且它必須稽核工具所採取的每項動作，以及工具的使用者所採取的每項動作。此外，所產生的密碼在每部系統上必須是唯一的，如此才能避免因共用帳戶資訊而遭到入侵。
許多廠商致力於解決此問題已有多年的時間，還有更多新廠商才剛剛踏入這個領域。購買之前，務必花點功夫研究並試用所有的新工具，以確保您採用的解決方案確實合乎您的環境。

Chris Stoneff 在 Lieberman Software (liebsoft.com) 擔任產品經理，這是一家安全性和系統管理軟體的開發商。他的幹勁來自於不只要知道事情的運作方式，還要了解背後的原因。


過去幾個禮拜，我有幸獲得參與一門進修課程的機會，內容主要在講述怎麼做才稱得上一位稱職的 IT 專家。隨著夏天接近尾聲，我也興起了返校進修的念頭，這當然是件好事，但不可否認的，也同樣帶給我一些震撼。
話說 Microsoft 的雜誌小組 (負責發行《MSDN Magazine》和《TechNet Magazine》的小組) 正忙著檢驗和加強我們的程序。不過最後我們還是決定，要在 2008 年的此時，丟開剩下的文書版面和彩色鉛筆標記，全心迎向數位時代 (我知道 — 我們的確很有改革的野心！)，不過說正經的，也該是時候讓我們體驗一下那些大型軟體公司一直宣傳推銷的高效率了。
在適應新數位工作流程的過程當中，我們很快就發現自己受限於追蹤文章狀態的工具。雖然現在早已是數位時代了，不過這個數位時代是架構在某種好用的古早技術上 (我們很希望能夠藉由這種技術永遠消滅世界)，然後在每一個版面頂端加印一些小型彩色方塊加以潤飾。這就是高科技？不會吧！於是我開始著手建立一個概念驗證的替代方案，而 SharePoint 是我認為的絕佳首選。
不過，我想快速帶過，直接和您們之中的 SharePoint 系統管理員分享自己的新發現。我不是存心要洩 SharePoint 的氣 (如果有，也是指平台的力量和彈性)，但是，要在 SharePoint 建立自訂工作流程解決方案還真不容易 (幸好我們有全新的《SharePoint 內幕》專欄可助您一臂之力)。雖然如此，在退隱數年之後再度披掛上陣，對我來說是一種強而有力的召喚 — 該是再度走入教室的時候了。
我們有許多很棒的資源可以幫助您回頭研究基本理論，或者繼續探索新知：這些資源廣泛涵蓋了 TechNet 全新《How Do I?》系列的視訊 (technet.microsoft.com/cc138021)、我們在雜誌 (.com/video) 上發表的影片，以及 TechNet Edge (edge.technet.com) 等等。不過，我想《TechNet Magazine》本身的「基本」報導也該拓展了。不是我老王賣瓜，我們在提供幫助您認識最後愛不釋手 (希望如此) 的深度技術題材方面的確很拿手。畢竟，偶而回頭探討基本原理，也不會讓我們吃什麼虧。所以，好好享受您剩下的夏天，因為不久之後，我們全都要返校進修了。—Joshua Hoffman

感謝下列 Microsoft 技術專家： Nathan Bigman、Nino Bilic、Mai-lan Tomsen Bukovec、Eric Charran、Trina Gorman、Gershon Levitz、Thomas Marquardt、Mandy Maxwell、Michael Murgolo、Sanjeev Nair、Michelle Rutzer、Jez Sadler、Jim Truher 以及 Shimon Yannay。


讀者來信 讀者有話直說

SharePoint Capacity Planning Tool
我們公司不到 600 名員工，而且許多人也不太積極使用他們的電腦或我們的內部網路，但是一提到企業通訊與共同作業，卻有志一同的發出強烈抗議。我覺得 Windows® SharePoint® Services (WSS) 3.0 非常適合我們的工作環境，但是經理只給了一部伺服器的預算。
我努力想要使用 SharePoint Capacity Planning Tool，但它就是不模擬單伺服器模型。您知道單伺服器有沒有什麼模擬選項呢？
—Allen M.
我想單伺服器並沒有模擬選項，但是要調整規模，一定要考慮所有使用者的行為。我會使用一顆四核心 CPU，從 8GB 的 RAM 開始著手。基本上，一部中型伺服器應該就夠用了。
Joel Oleson 曾經編譯過許多調整規模參考文章，而這幾篇是他發表在部落格上供人閱讀的部分 (網址是 blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx)，也許可以配合貴公司的需求，更進一步幫助您做出最佳決策。
—Pav Cherny，專欄作家
Sharepoint 內幕

Microsoft Bob
我知道《Windows 機密文件》專欄的＜空間佔用回顧＞ (2008 年 7 月 technet.microsoft.com/magazine/cc565089) 的目的，是要揭露 Microsoft® Bob 程式藏身在 Windows XP 磁碟中，但它對於我家小朋友熱愛並且用來學習基本電腦文書處理的程式，卻是一項無情的攻擊。Bob 從我們第一部家用電腦 (安裝了 Window 95 的 NEC 電腦) 就開始伴隨我們。我的每一個孩子在成長過程中，都跟 Bob 玩在一起，並且一用就長達數小時。
在那篇專欄中，Bob 被貶為拙劣的科技產品，但其實它是一個很棒的軟體，只是被錯放到不適合的市場.. . 也就是成人市場。它很適合兒童使用，如果它是朝著這個方向推出的話，一定會獲得不同的評價，甚至有不同的命運。誰知道呢，如果它一開始就是以兒童程式的名義推出，說不定連我的孫子都會愛不釋手呢。
—Jim S.

告別印刷
拜讀了您在 2008 年 7 月份《編輯的話》所寫的＜告別印刷＞(網址是 technet.microsoft.com/magazine/cc595615)，我覺得很有意思。在我看來，有關資訊科技的專家著述印刷本，很快就會被數位媒體取代。不過根據您的說法，在接受問卷調查的讀者當中，有九成的受訪者偏愛印刷版。這項問卷真的具有代表性嗎？亦或回答問卷的人，都是您藉由印刷媒體找到的讀者呢？這群讀者應該不包括年輕族群在內吧。年輕一代已經沒有人訂閱像您所訂閱的報紙或雜誌了，他們所有的資訊都是從線上取得，而且從未聽過您的問卷調查。
印刷文字的讀者，無法從浮動文字啟動視訊或網路廣播；無法在印刷的網際網路連結上按一下滑鼠，開啟首頁、新聞群組或部落格；也無法按一下滑鼠來下載印刷文字所提及的增益集或工具。
說到底：印刷書籍是根本是一種吃虧的和解。讀者很快就會明白，印刷書籍只能提供 DVD 的部分好處，但他只要把 DVD 的所有內容全部複製到筆記型電腦上，就可以隨時隨地存取這些內容了。
—Ulrich S.
非常謝謝您的寶貴意見！關於您針對 90% 的讀者表示偏好印刷版所提出的問題，這份問卷是敝刊年度編輯研究的一部分，調查對象是我們的印刷版訂戶和網路版讀者 (人數大約各半)，而且問卷結果是以電子方式而非印刷方式發表。這道問題是發佈給表示自己兩種版本 (印刷版和線上版) 都看的讀者，而其中有 90% 表示比較喜歡印刷版。
當然我完全同意您提到有關線上出版內容的優點 (多媒體、全球化和可按式連結等)，不過我仍然覺得閱讀印刷版上面的文章，可以提供更迷人的體驗。我覺得內容更讓我自在，更能與我緊密連結，而且不少人也有同感。正因為每一種媒體都有它自己的優點，所以我們才會持續發表兩種版本的《TechNet Magazine》。再次感謝！
—Joshua Hoffman，總編輯


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

監視您的伺服器
Mastering SQL Server 2005 Reporting Services Infrastructure Design
sybex.com
基礎結構越複雜，我們系統管理員所面對的資訊量就越龐大 — 其中大部分的資訊都記錄在檔案或資料庫中。但想要有效運用這些資訊，您需要一個分析引擎及工具，以有意義的形式來表示分析所得的資料。Microsoft® SQL Server® 2005 Reporting Services 正是其中一項好用的工具。此工具可協助您將所有這類資訊集結成彙總內容，並以容易閱讀的方式呈現。此外，這個工具還能夠自動或根據您的需求傳送這些資訊到不同的位置，讓您的商務使用者更有效率地快速取得所需資料，以做出更佳的商業決策。
若要規劃、部署和管理完善的 Reporting Services 基礎架構 (或任何新的伺服器基礎結構)，以便滿足公司需求，並伴隨公司成長一同擴展，您需要充分的準備、專業的知識技能，以及一點克服困難的勇氣。如果您想部署 Reporting Services 執行個體，Joseph L. Jorden 的著作《Mastering SQL Server 2005 Reporting Services Infrastructure Design》(Sybex，2007 年) 能幫助您了解這項工具，並指引您進行成功操作的關鍵步驟。
值得讚許的是，這本書先提醒讀者一些常被忽略的系統實作環節，接著再詳述 Reporting Services 部署細節。這些基本環節包括確知實作系統的原因、其商業用途的需求，以及定義如何管理使用者期望。書中有一個章節專門探討報告系統中的管理變更所使用的策略。這個章節介紹各種方法來變更管理，並針對變更管理要求表單提供範本與準則。我不是在吹捧官僚體制，但若能建立適當的制度，將可提高環境的穩定性。
討論過 Reporting Services 的商業層面之後，這本書開始深入剖析部署作業，介紹安裝、調整、自動化和設定等基本知識。文中還提供如何與 Microsoft Windows® SharePoint® Services (WSS) 整合的秘訣。您可以將這本入門書當作是一份部署檢查清單，讓您剔除作業過程中的絆腳石。
SQL Server 2005 Reporting Services 有一個很酷的新功能，就是特定報告功能。這個功能可讓使用者即時建立報告。書中說明了如何啟用這項功能和設定報表產生器工具。接著話題一轉，這本書開始描述如何建立報告訂閱，好讓您產生報告，並透過電子郵件、檔案共用或整合式 SharePoint 傳送，根據排程來散發您的報告。
所有系統在使用一段時間後都需要維護，因此下一章就是探討一些基本工作，例如備份執行個體、管理報告內容，以及藉助可用記錄檔來疑難排解問題。書中還有一個關於安全性的章節也不錯，內容是討論適用於部署的驗證與授權選項。
有關擴充 Reporting Services 的章節內容，以及有關經由 Microsoft .NET Framework 架構的應用程式來存取和處理報告的章節，應該會讓程式設計師受益匪淺。報表定義語言 (RDL) 是 Reporting Services 其中一個基礎概念，因此這本書特別花了一個章節的篇幅來介紹一些您可以使用的關鍵項目、RDL 檔案結構，以及建立與部署這些檔案的基礎。
本書結尾提供幾項秘訣和訣竅來進行 Reporting Services 部署的效能微調。您會看到關於測量效能、修改組態檔和使用效能主控台等方面的資訊。另外，本書的附錄也介紹了如何整合 Reporting Services 與 SharePoint，值得一讀。如果您想在自己的環境中執行 SQL Server 2005 Reporting Services，不妨讀一下這本書，它一定能幫您快速上手。

價格： $49.99 美元 (直接售價)。

稽核您的環境
Alloy Discovery Professional Edition
alloy-software.com
為了執行工作、疑難排解問題，以及確保系統的最新狀態且遵守安全性與軟體原則，能夠在您的責任範圍內快速擷取特定系統的資訊是很重要的。此外，如果這些資訊可以使用方便商務使用者檢閱的格式，而且用來評估基礎架構也一目了然的話，將提供相當的優勢 (不用說，管理起來也會更賞心悅目)。如果這樣還不能說服您，快速的資訊存取也能協助您辨別哪些軟體的使用者是誰，以確保使用者是經過合法授權。有一個具備這些功能的清查與稽核工具您可能會感興趣，就是 Alloy Software 推出的 Alloy Discovery Professional Edition。
這個應用程式的安裝簡單，您可以很快在 LAN 上開始稽核群組或特定範圍的電腦。UI 會以井然有序的檢視畫面來分組您的電腦，與 Internet Explorer® 非常類似，當您設定好可稽核的電腦群組後，只要按一下按鍵就可輕鬆執行群組稽核。收集到的資訊很廣泛，從硬體、軟體及裝置到印表機、共用，甚至是事件，應有盡有。您也可以檢視資產標籤、序號、執行時間統計資料、環境變數、網路設定和本機使用者帳戶。基本上，您需要知道一切有關環境的資訊，都可以在您自己的座位上收集到 (不過為了您的個人健康，建議您還是要時常起來走動一下)。
除了在需要時稽核電腦，您也可以排程稽核。針對位於直接 LAN 以外的電腦，還有無法使用足夠權限從遠端連線來執行稽核工作的電腦，Alloy Discovery 提供以代理程式為基礎的方法來稽核目標電腦。這種稽核類型可以透過指令碼編寫，然後加以排程，以便定期執行或經由代理程式執行，接著從代理程式傳送電子郵件到您主要的 Alloy Discovery 存放庫。另一個選項是將代理程式放在快閃磁碟上，然後帶到其他電腦上以啟動稽核。稽核完畢後，視主要存放庫使用的方法而定，您可以自動或手動同步處理這些資訊。
您也可以在稽核結果上套用 Alloy Discovery 提供的篩選器來分析整體存貨狀況。譬如說，您可以查看有多少台電腦需要升級記憶體來支援應用程式，或是環境中有哪些電腦正在執行 Windows® XP Professional 與 Windows Vista® Business Edition。
收集到資料之後，您就可以建立報告。此應用程式可以將報告發佈成 HTML 網頁，讓您詳細檢視。而且您可以設定排程工作來持續產生這些報告，這個選項特別適用於網路操作中心。此外，您可以將所有稽核資訊匯出成 XML、CSV 或 Microsoft Excel®，譬如作為稽核人員的證明文件。

價格： 基本產品 $795 (直接售價) 美元，每一節點額外收取 $3 美元。﻿
使用 Alloy Discovery 監視您的環境 (按一下以放大影像)

管理您的密碼
錯誤密碼計數
cygnusproductions.com
在今日密切連結的世界中，密碼成了生活的一部份 (至少在所有東西都採用生物特徵機制，或人類創造出世界大同的烏托邦之前是如此，不過這兩種情況短期內都不可能發生)。如果您像我一樣，那麼您可能也有不同類型的密碼用於不同類型的環境，而且透過不同的媒體上變換這些密碼。
除了一般常見的用途之外，還有系統管理員帳戶、服務帳戶及各種網域帳戶所使用的各種系統密碼。當然，這些形形色色的密碼也搭配相關聯的各種使用者名稱，數都數不清。那麼您要怎麼做，最能夠安全又輕鬆地記錄所有這些密碼？
有一個方法是使用密碼儲存機制，將所有資料鎖在強式加密的檔案中，而 Password Corral 正是執行這項工作的理想解決方案。這個自 2001 年即上市的應用程式既簡單又好用，而且還經過強式加密，它會利用 Diamond2 或 Blowfish 加密將所有您的密碼加密成單一檔案。通過時間的試煉及測試，此應用程式的現行版本與未來版本仍舊提供支援並持續開發中。
安裝此程式後，您要建立新的使用者，並選擇要將密碼檔案放置在系統 (或網路磁碟) 的何處，然後就可以開始使用您的新密碼檔案。當然，如果您打算將所有帳戶的各種密碼機密資訊保存在單一的 Password Corral 檔案中，您的 Password Corral 密碼必須牢不可破，而且經常變更。這是您真正需要記住並保護的密碼，因此一定要小心處理。
當您通過驗證之後，Password Corral 會提供與 Internet Explorer 非常類似的 UI，它的左邊是階層式的資料夾結構，右邊則是詳細資料窗格。您可以在樹狀目錄式的資料夾結構中整理您的密碼。每個密碼都可以加入描述、使用者名稱、密碼、參考 URL、參考電子郵件地址，以及與帳戶相關的註解。此外，您可以告知應用程式各個帳戶所要套用的密碼原則，指定期限週期的天數，以及特定密碼到期前的剩餘天數。
其中一個檢視選項包含依過期密碼篩選的功能，好讓您查看哪些帳戶在下次使用時需要重設密碼。另一個很棒的功能是程式可以替您產生密碼，省去您為每個帳戶構思強式密碼的麻煩。您也可以自訂這個密碼產生器，根據您想要的長度、複雜度和字元組合來進行設定。
還有一個功能也不錯：當您輸入所有密碼之後，您可以按照剛才輸入資料的任意欄位來輕鬆搜尋密碼，如果您要尋找位於資料夾結構底層且較少使用的帳戶，這就能派上用場。您也可以設定應用程式的逾時，如此一來，若您忘記關閉 Password Corral，應用程式將自動鎖定以保護您的機密資訊。根據預設，應用程式也會在結束時自動清除剪貼簿，以免您在使用密碼後，讓複製的密碼保留在緩衝區中。
如果您需要經常存取密碼，可以使用應用程式的系統匣圖示選項，您只要在上面按兩下就能啟動應用程式。若您想要使用 Password Corral 並將帳戶儲存在別處，那麼此應用程式也可讓您從檔案匯入，您就不必重複輸入這些資料。願意的話，您甚至可以匯出和列印密碼 — 只要記得在工作結束後把紙吞掉就行了！總而言之，這是非常實用的免費工具。

價格： 免費。
使用 Password Corral 記錄所有密碼(按一下以放大影像)

稽核檔案使用情況
File System Auditor
scriptlogic.com
在共用檔案系統上維護稽核記錄可以省下您許多麻煩事。然而更重要的是，這麼做也是為了遵守某些資訊保留政策標準。若要了解何人在何時做了何事，您可能想要參考一下 ScriptLogic 推出的 File System Auditor。此應用程式是一個集中式管理系統，可在近乎即時的效率下稽核目標系統上的檔案使用情況，並將這些資訊儲存在 SQL Server 資料庫中，以便建立使用情況報告。
File System Auditor 支援 Microsoft SQL Server Desktop Engine (MSDE)、SQL Server 2000 和所有版本的 SQL Server 2005 (包括免費的 SQL Server 2005 Express)。受監視的系統分別都需要安裝代理程式，此代理程式是用來監視檔案使用情況，並回報 SQL Server。完成安裝之後，您使用資料庫精靈來建立資料庫儲存機制，在此會記錄所有稽核資訊。
身為系統管理員，您現在可能擔心使用率較高的系統上的頻寬和繁雜度問題，但是此應用程式據稱是使用智慧型稽核系統，將不同動作結合成單一的稽核項目。就頻寬而言，File System Auditor 在第一次存取檔案時只使用 100 個位元組的資料，之後每次存取都使用 10 到 20 個左右的位元組。
您可能納悶，為何不直接使用原生的 Windows 稽核來執行這項工作，但是專用監視應用程式的集中式管理、事件聯合和報告功能比較有彈性，也比較好用。此外，將所有資訊集中在 SQL 資料庫中更方便從其他系統參考這些資訊。
設定資料庫之後，利用「代理程式設定主控台 (Agent Configuration Console)」在目標伺服器上安裝代理程式。您可以輸入伺服器名稱，也可以使用 Active Directory® 瀏覽到該伺服器。File System Auditor 也支援叢集檔案伺服器，因此您可以輸入叢集執行個體的名稱。接下來您安裝代理程式服務 (如果帳戶具有遠端存取，方法是按一下按鈕)，選取代理程式要用來連線到 File System Auditor 資料庫 Windows 或 SQL Server 帳戶。
針對每部伺服器，您都可以設定三種類型的監視排除項目：「路徑篩選 (Path Filter)」、「處理程序排除篩選 (Process Exclusion Filter)」和「使用者排除篩選 (User Exclusion Filter)」。「路徑篩選 (Path Filter)」可讓您選取路徑，然後選擇要包含或排除特定資料夾及檔案事件 — 例如權限變更、建立與刪除，這個動作可以針對所有檔案或特定類型的檔案。「處理程序排除 (Process Exclusion)」和「使用者排除 (User Exclusion)」可讓您針對與目標伺服器上特定處理程序相關的檔案與資料夾事件執行同樣的動作，但不支援檔案類型篩選。
完成設定並開始收集稽核事件之後，您接著啟動「報告設定主控台 (Report Configuration Console)」來運用這些稽核資料。若要設定報告，您可以在資料上設定一些篩選條件，包括使用者、特定檔案或資料夾事件、路徑、伺服器、處理程序和日期範圍。另外，您可以接著排程報告，讓應用程式透過 SMTP 伺服器以電子郵件傳送發佈的報告。最後，若要即時檢視系統上的檔案情況，您可以啟動 File System Auditor 的「即時檢視器 (Real Time Viewer)」來查看原始事件的發展，就像「監視」記錄檔一樣。

價格： 程式與單一伺服器授權的直接售價約為 $800 美元起。
使用 File System Auditor 稽核檔案使用情況 (按一下以放大影像)

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


公用程式焦點 Windows 記憶體診斷
Lance Whitney

程式碼下載： Utility2008_09.exe (640 KB)

目錄
取得 Windows 記憶體診斷
測試記憶體
您支援的某一台電腦出問題了 — 凍結、當機、出現藍色螢幕。是某部分的硬體故障嗎？還是哪個新安裝的應用程式產生問題？或者是記憶體出錯？要確認問題根源的其中一個方法就是使用免費的 Microsoft® Windows® 記憶體診斷公用程式。這個工具會在電腦的 RAM 上執行各種測試，藉此確認模組上是否有什麼問題。

取得 Windows 記憶體診斷
若要使用 Windows 記憶體診斷，請從下列網址下載並執行程式的單一檔案 mtinst.exe：oca.microsoft.com/en/windiag.asp。請注意，您不一定要安裝 Windows 記憶體診斷。此工具提供兩個選項，如螢幕擷取畫面所示：
[圖 1] 建立可開機媒體的 Windows 記憶體診斷選項 (按一下以放大影像)
  • 建立開機磁片，可讓您透過程式來建立開機磁片。
  • 將 CD 映像儲存到磁碟，可讓您將程式的 ISO 映像儲存到硬碟。然後您可以將映像燒錄成 CD，並使用 CD 建立軟體讓它變成可開機光碟。建置可開機媒體之後，重新啟動電腦，然後從磁片或 CD 啟動診斷作業。
測試記憶體
在程式載入時，它會立即開始掃描您的 RAM。Windows 記憶體診斷工具會以標準模式啟動，其中包含 6 種不同的連續記憶體測試，每種測試都使用獨特的演算法來掃描不同類型的錯誤。個別測試執行時，螢幕會顯示該測試，列出測試進度以及正在掃描的記憶體位址範圍。完成這 6 種測試後，此工具會使用相同測試執行另一次循環，並不斷地執行循環直到您結束軟體。不過一般說來，一次循環應該足以看出記憶體是否出錯。
若要執行更徹底的測試，您可以切換成延伸模式，這會執行 11 種個別的記憶體測試。此外還有只執行 2 個測試的基本模式，不過為了保險起見，最好還是使用標準和延伸模式。若要執行整組延伸測試，建議您在夜間執行 Windows 記憶體診斷。
每個測試完成後，工具都會顯示成功或失敗訊息。失敗訊息會加上失敗的詳細資料，而且通常表示某個 RAM 模組有問題。視您的電腦環境而定，診斷作業可能可以將記憶體問題的範圍縮小到特定模組。
此時，功能表會顯示依照記憶體模組檢視錯誤的選項。這個選項能幫助您確認出現故障而應該替換的特定模組。
在 [進階] 選項畫面中，您可以切換基本、標準和延伸模式。在此您也可以關閉掃描過程中的處理器快取，這樣會強迫工具直接從 RAM 存取資料，藉此執行更測底的測試。系統資訊命令列出每個插槽上安裝的 RAM 容量與類型。
Windows 記憶體診斷支援 x86 架構平台，包括 Intel Pentium 與 Celeron 處理器和 AMD K6、Athlon 以及 Duron CPU。不過，此工具最多只能處理 4GB 的 RAM，超過此範圍便無法掃描。
在 Windows Vista® 的系統管理工具和 Windows Vista 安裝媒體的 [修復] 選項中，您會看到安裝了這個診斷工具的某個版本。不過，Windows Vista 版本並不提供這麼多視覺化回應或選項。因此您應該確保手邊有這個獨立版本的診斷工具，以便在下次電腦出問題時派上用場。
Lance Whitney 身兼 IT 顧問、培訓講師和技術文件作家。他投入許多時間改良 Windows 工作站與伺服器。記者出身的 Lance 在 15 年前一頭栽進了 IT 產業。


SharePoint 內幕 SharePoint 目錄整合
Pav Cherny

程式碼下載： SharePoint2008_09.exe (2,775 KB)

目錄
SharePoint 目錄管理服務
自訂目錄管理服務
SharePoint 與 ILM
結論
Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 以目錄管理服務的形式提供了目錄同步處理功能，這項服務可在 Active Directory 中針對 SharePoint 資源佈建啟用郵件功能的連絡人和群組物件。針對
SharePoint® 資源佈建這類的收件者物件，可讓使用者在傳送文件和其他資訊時，直接從 Microsoft® Outlook® 通訊錄選取 SharePoint 文件庫、清單和群組。
SharePoint 收件者物件也提供了一種管道，讓您在 Exchange Server 組織中控制郵件傳輸和格式轉換。除此之外，您還可以在 Active Directory® 中設定郵件傳遞限制，藉此預防未經驗證的寄件者 (例如濫發垃圾郵件者) 提交郵件到 SharePoint 文件庫。
不過，SharePoint 目錄管理的功能有限，而且在撰寫本文之時，是以 Exchange Server 2003 為基本郵件系統。就目前而言，如果您是使用 Exchange Server 2007 或是協力廠商郵件系統，您必須以自訂解決方案來延伸或取代內建目錄管理功能，才能達到所要的互通性等級。
在本專欄中，我將簡短評估一下 SharePoint 目錄管理功能，隨後探討克服目前限制的方法。我的前題是，內建目錄管理服務只能滿足最基本的使用者需求，內含各種郵件系統和目錄平台的環境需要有更多的彈性和功能。藉著以自訂解決方案取代內建元件，您便能夠同步處理 SharePoint 收件者資訊與任何提供 API 或匯入功能的目錄解決方案。
為了證明這點，我會向您說明如何以 Exchange Server 2007 相容的方式來同步處理 SharePoint 收件者資訊。您同樣可以使用自訂解決方案，將收件者資訊與 IBM Lotus Notes 或其他系統同步處理。
您也能夠根據 Metadirectory 服務 (例如內含在 Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) 中的 Identity Information Server) 將目錄佈建程序集中化。更具體的說，我會向您說明如何將 SharePoint 與 ILM 2007 相整合，以協調 SharePoint 文件庫的目錄物件的佈建作業。您可以在本專欄隨附的資料 (可從 Technetmagaine.com 中的「程式碼下載 (Code Downloads)」區段取得) 中找到建置此解決方案的工具、原始程式碼和逐步指示。

SharePoint 目錄管理服務
與 Exchange Server 不同 (幾乎所有設定和收件者資訊都是使用 Active Directory)，SharePoint 仰賴的是設定和內容資料庫。SharePoint 因此必須將啟用郵件功能的文件庫、清單和群組的收件者資訊，從資料庫傳播到目錄。畢竟，郵件用戶端會預期在通訊錄中找到收件者資訊，而通訊錄一般是從目錄物件產生。
針對此目的，SharePoint 包含了一個現成的目錄管理服務，它是電子郵件整合 Web 服務 (SharepointEmailWS.asmx) 的一部分，您可以在 SharePoint 3.0 管理中心的 [作業] 頁面上的 [內送電子郵件] 設定下進行設定。[圖 1] 圖解內建目錄管理服務的運作方式。
[圖 1] SharePoint 目錄管理服務架構 (按一下以放大影像)
當您啟用 Web 伺服陣列以進行目錄管理，然後為文件庫、清單或群組指定電子郵件地址以接收郵件時 (例如利用 EmailSettings.aspx)，您等於是以隱含的方式呼叫電子郵件整合 Web 服務在 Active Directory 中佈建相對應的收件者物件。首先，SharePoint 會將電子郵件地址資訊儲存在內容資料庫中。接下來，SharePoint 會使用 Web 應用程式集區帳戶的身分，代表您將佈建要求傳送到電子郵件整合 Web 服務。如果佈建要求失敗，您最後會在內容資料庫中得到電子郵件地址資訊，但在 Active Directory 卻不會有相對應的收件者物件。
其他資源
  • SharePoint 產品和技術網站
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services 開發人員中心
  • Microsoft SharePoint 產品和技術小組部落格
佈建要求失敗的原因有好幾種。最常見的原因是缺乏 IIS Metabase 存取權限。因為 SharepointEmailWS.asmx 是為了作為應用程式集區帳戶的 Web 服務而設計的，所以此 Web 服務會檢查 IIS Metabase 確定呼叫者是否是應用程式集區帳戶，若不是則拒絕存取，無論您的 SharePoint 網站和 Active Directory 權限的等級為何。
不過，SharepointEmailWS.asmx 會在呼叫者的身分下執行這項存取檢查，因此呼叫應用程式集區帳戶必須要存取 Metabase 才能確認它自己的存取權限。這會強迫您授與應用程式集區帳戶提高權限，以便順利存取。
不用說，網頁伺服器上的提高權限向來是安全性顧慮的源頭。要控制對 ASP.NET Web 服務的存取有更好的方法。況且，SharePoint 也預期在管理中心網站中找到目錄管理服務，但是這個網站在為了縮小受攻擊面而鎖定的 Web 伺服陣列中並不永久可用。因此，如果您想要在您的 SharePoint 生產環境中使用內建目錄管理服務，就必須接受比較脆弱的安全性設定。
另外，也因為內建目錄管理服務是以緊密結合的用戶端/伺服器架構為基礎，而存在了額外的限制。Microsoft.SharePoint.dll 是直接使用 System.DirectoryServices.dll，因此您無法實作您自己的邏輯來自訂佈建程序。舉例來說，內建目錄管理服務實作並不會寫入所有收件者屬性來支援 Exchange Server 2007，而且也沒有任何選項可自訂屬性產生規則。
無法實作您自己的邏輯也暗示了您無法自訂佈建程序進行一些動作，例如實作自訂核准。SharePoint 支援群組的核准程序，但是這項功能是以管理中心網站為基礎。只有 SharePoint 伺服陣列系統管理員能夠核准擱置中的要求，但 SharePoint 系統管理員並不一定是負責核准 Active Directory 佈建程序的人。
或許更為重要的是，對於啟用郵件功能的文件庫和清單來說，並沒有所謂的核准程序。假若您啟用目錄管理，您基本上是把在 Active Directory 中建立啟用郵件功能的連絡人和群組的權限，授與您 Web 伺服陣列當中的所有網站系統管理員。要根據組織單位 (OU) 來建構收件者管理也是不可能的，因為每個 Web 伺服陣列的所有收件者物件都是放在相同的 OU 中。
您無法將收件者物件移到其他 OU 中，因為目錄管理服務會預期在 SharePoint OU 中找到收件者物件，而且您必須在 Active Directory 中授與 SharePoint 管理中心應用程式集區帳戶系統管理權限。另外，要在 SharePoint 與 Active Directory 之間實作雙向同步處理也是不可能的。而變更 Active Directory 中的物件屬性並不能將變更傳播回 SharePoint 環境中。

自訂目錄管理服務
現在證實內建目錄管理服務有留空間以發展出更大的彈性後，讓我們來討論一些其他替代方案。好消息是，SharePoint 可讓您實作自己的目錄管理服務。您只需要在 SharePoint 3.0 管理中心的 [作業] 頁面的 [內送電子郵件] 設定下，將 Web 服務當作遠端目錄管理服務註冊就大功告成了。
如需部署和註冊自訂 Web 服務的詳細逐步指示，請參閱隨附資料中的「Directory Integration Based on a Custom Directory Management Service.xps」工作表。另外，我的自訂 Web 服務也說明了如何在沒有指令程式或 Exchange 管理工具的情況下，在 Active Directory 中佈建 Exchange Server 2007 相容的收件者物件。相對應的原始程式碼位於 EmailIntegrationService 資料夾中。[圖 2] 圖解說明了解決方案的架構。
[圖 2] 自訂目錄管理服務架構 (按一下以放大影像)
如 SharePoint SDK 中所述，自訂 Web 服務的介面必須遵守目錄管理服務介面。如果您在 MSDN® 網站 (msdn.microsoft.com) 上搜尋「SharepointEmailWS」，就可以找到所有必要的詳細資料。您也可以查看隨附資料中 EmailIntegrationService\App_Code 資料夾內的 Service.cs 檔案。這個檔案會實作必要的 Web 服務介面，而佈建 Active Directory 物件的實際程式碼則位於 SPRecipient.cs 中。例如，SPRecipient.cs 中的 UpdateRecipientAttributes 函數會產生必要的 Exchange Server 2007 屬性。如果您想要開發自己的自訂目錄管理服務，就必須取代 SPRecipient.cs 這個程式碼檔案。
自訂目錄管理服務是克服提高權限需求，以及將 SharePoint 與協力廠商目錄或郵件系統相整合的好工具。您不必檢查 IIS Metabase 來限制 Web 服務對應用程式集區帳戶的存取。相反地，您可以在 Web 服務的 web.config 檔案中新增 <authorization> 區段 (請參閱隨附資料中的範例)。
不過，還是有幾個問題，因為您不能控制 SharePoint 是否以及何時會呼叫您的目錄管理服務。除此之外，當您刪除啟用郵件功能的文件庫或清單時，SharePoint 也不會呼叫目錄管理服務，而使得無效的收件者物件繼續留在 Active Directory 中。無論您是使用內建目錄管理服務還是自訂解決方案，您都無法保證 Active Directory 中的收件者資訊會與 SharePoint 資源保持一致。

SharePoint 與 ILM
為了達成可靠的目錄整合，您應該考慮部署專業目錄管理套件，例如 ILM。這個系統仰賴的是以提取為主的目錄同步處理模型。管理代理程式會從它們連接的來源提取資訊，將資訊匯入通用的 Metadirectory，然後從 Metadirectory 匯出資訊到它們連接的系統中。來源系統一般不會將它們的資訊推入 Metadirectory 中。透過提取資訊，您可以確保與每個同步處理周期保持一致。
另外一個好處是，ILM 包含了幾個支援 Active Directory、Lotus Notes 和各種其他現成系統的管理代理程式。您只需要為 SharePoint 實作一個自訂管理代理程式，就能將 SharePoint 資訊與您環境中其他受到支援的平台同步處理。
您必須實作邏輯從 SharePoint 擷取所要的資訊，將資訊儲存到匯入檔案，然後將匯入的資訊傳輸到 Metadirectory。但是將資訊從 Metadriectory 匯出到 Active Directory 或其他目錄平台時，並不需要實作邏輯。[圖 3] 圖解說明了如何使用 ILM 從 SharePoint 實作同步處理到 Active Directory。要從其他方向佈建目錄物件的 SharePoint 資源來進行同步處理也是可行的，不過這可能沒有必要或是次要的。
[圖 3] 以 Identity Lifecycle Manager 為主的目錄整合 (按一下以放大影像)
Alex Tcherniakhovski 所著的＜連接 ILM 2007 與 SharePoint Service 清單＞(英文) 一文是開發 SharePoint 管理代理程式一個不錯的出發點，網址是 blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx。Alex 說明了如何建置 ILM 架構的目錄管理解決方案，仰賴提交給文件庫以 InfoPath® 為主的佈建要求。Alex 的管理代理程式從文件庫擷取所有核准的要求，然後建立相對應的 Metadirectory 物件，之後再匯出到連接的目錄中。
但是在預設的情況下，當您啟用清單或群組的郵件功能時，SharePoint 並不會產生以 InfoPath 為主的佈建要求。您可以透過自訂目錄管理服務來完成這個動作，但是您之後會碰到先前提到的一致性問題，因為 SharePoint 無論如何都不會呼叫目錄管理服務。有基於此，我建議您的管理代理程式直接從您網站集合中的清單和群組擷取所要的 SharePoint 收件者資訊。如果您需要核准程序，隨後可在管理代理程式中針對新資源產生以 InfoPath 為主的佈建要求，後續再處理所有核准的要求。
要擷取 SharePoint 資訊，您有幾個選擇。您可以直接從內容資料庫讀取資訊，使用 SharePoint 物件模型，或是利用 SharePoint Web 服務。
我不建議直接存取內容資料庫，因為未來版本中的資料庫結構可能會有所變化，而可能打斷您的目錄管理解決方案。
在您的管理代理程式中直接使用 SharePoint 物件模型也一樣麻煩，因為物件模型會要求您在本機執行程式碼，而在您環境內每個 SharePoint 伺服陣列中的網頁伺服器上安裝 ILM，可能會使目錄管理基礎結構複雜化。
您可能會想要使用 SharePoint Web 服務，但是這會製造另一個難題，因為您要的資訊透過 SharePoint Web 服務並不容易存取，例如 SharePoing 群組的電子郵件地址資訊，或內送電子郵件伺服器顯示位址。
到最後，似乎實作自訂 SharePoint Web 服務，使用 SharePoint 物件模型來擷取所要的資訊，以 XML 文件的形式把它傳回呼叫者才是上策。現在您可以將 ILM 部署集中化，並透過自訂 SharePoint Web 服務個別的執行個體，整合任何數目的伺服陣列和網站集合，如 [圖 3] 所示。
另外還有一點值得一提的是，進行 ILM 為主的目錄整合，還是需要自訂目錄管理服務。這項自訂服務並不需要執行任何工作，因為 ILM 會佈建目錄物件，但是您必須提供自訂服務，如此一來，您才能在 SharePoint 3.0 管理中心啟用目錄管理。否則的話，您一開始就無法指定電子郵件地址給群組。[圖 4] 說明所得的解決方案架構。
[圖 4] 以 Web 服務為基礎的 SharePoint 目錄整合 (按一下以放大影像)
您可以把隨附資料中的自訂目錄管理服務變成虛擬服務，方法是在 web.config 檔案中設定 OpMode 參數 (<add key="OpMode" value="dummy"/>)。在這種設定中，自訂服務不會執行任何工作，始終都會傳回 SUCCESS 來回應佈建呼叫。
此外，自訂服務會公開一個 ResolveUsers 方法，SharePoint 管理代理程式可以呼叫這個方法將以 NetBIOS 為主的使用者帳戶名稱解析成辨別名稱，這是佈建群組時的必要步驟 (SharePoint 會把群組成員資格資訊傳回成以 NetBIOS 為主的使用者帳戶名稱清單，但是 Active Directory 預期的則是辨別名稱)。這樣就大功告成了！如需如何部署所得的解決方案的詳細資訊，請參閱隨附資料中的「Configuring Directory Integration based on ILM 2007.xps」。
WSS 3.0 和 MOSS 2007 都包含了目錄管理服務，可將 SharePoint 與 Exchange Server 2003 整合進行以郵件為主的跨平台協作。
不過，還是有幾項限制。使用者必須以自訂解決方案取代內建目錄管理服務。您也可以使用專業目錄管理解決方案，像是 ILM，將 SharePoint 整合到目錄管理基礎結構。這提供了最高度的彈性，而且有助於透過以提取為基礎的同步處理模型確保資訊的一致性。

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


Windows PowerShell 字串理論
Don Jones

目錄
真實案例
複雜的比對
真是個字串連連的世界
當我在像是 Tech•Ed 或 TechMentor 等研討會發表演說時，我總是習慣提出宣言 — 幫助使用者記住例如 Windows PowerShell 等重點的通則宣告。我最近的宣言是「如果您在 Windows PowerShell 中剖析字串，肯定是搞錯了」。
這是我就 Windows PowerShell™ 是物件導向殼層的觀點提出來的。如果您把服務清單傾印到文字檔，然後剖析該文字檔來查看啟動了哪些服務，或諸如此類的事，那也未免太辛苦了。這在以文字為基礎的 OS (如 UNIX) 中是個有效的方法，但 Windows PowerShell (還有 Windows® 本身) 可讓您以更有效的方式來使用物件。
影片
觀看 Don Jones 示範如何使用 Windows PowerShell 來剖析複雜的字串。

即便是您自己的指令碼都應該產生物件而不是格式化文字，如此一來，就可以利用殼層的各種格式化、篩選、匯出和其他命令，從您的指令碼來操作輸出 (在我 2008 年 7 月號的《Windows PowerShell》專欄中，您可以進一步了解將物件自訂成指令碼輸出的概念)。
最近在佛羅里達州奧蘭多舉辦的 TechMentor 中，我有一名學生提醒我幾乎所有規則，特別是通則，都有例外。「那麼要在 IIS 記錄檔中搜尋呢？這種情況下，不是只能剖析文字嗎？」
呃，沒錯。好在像 Windows PowerShell 這麼適合使用物件，說到剖析文字字串，它也絕非等閒之輩。經您這麼一說，IIS 記錄檔、防火牆記錄檔和其他文字型的記錄檔都是絕佳的範例。

真實案例
我實際上曾為一家我服務的公司剖析過一組防火牆記錄檔。有名員工被抓到瀏覽一些不當的網站，為了進行後續調查，人事部需要一份他曾造訪過的完整網站清單。要調出一天的記錄檔就已經有點難了，HR 的同仁竟然想回溯好幾週的記錄 — 這樣的工作我一點也不想手動進行。
該公司的動態主機設定通訊協定 (DHCP) 伺服器指出，該名員工的電腦好幾個月以來一直都是使用相同的 IP 位址 (基於本例的目的，讓我們假設是 192.168.17.54)。這其實並不罕見，尤其這是一部桌上型電腦，而且很少關機。既然防火牆記錄檔有保留來源 IP 位址的記錄，我知道 Windows PowerShell 可以幫上忙。
秘密在於常常受到忽視的 Select-String 命令。另外，您也必須具備規則運算式的實務經驗 (我在 2007 年 11 月號的《Windows PowerShell》中曾討論過)。
Select-String 命令可以接受檔案路徑，充滿著文字檔、規則運算式或是簡單字串可供尋找。它接著會輸出每個記錄檔中與規則運算式或簡單的字串相符的每一行。為了開始工作，我想取得包含該名員工之桌上型電腦 IP 位址的每一行。每個記錄檔行都包含一個日期和一個時間戳記，這也正是人事部的同仁想要的。
以下就是這個命令：
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
–simpleMatch 參數指出我提供的模式不過是一個簡單的字串，並非規則運算式。[圖 1] 顯示一些也可傳送到檔案的輸出。要特別注意的是，輸出同時包含了找到相符項目的檔名和行號，如果您事後想要回頭找更多資訊的話，這將非常管用。
本月指令程式：Start-Sleep
這個指令程式可以滿足您在一天漫長的工作後所想要的 — 小盹一會兒。Start-Sleep 提供片刻休息 — 當然是指 Windows PowerShell 指令碼啦。
指令碼中需要片刻暫停是很正常的。比方說，假設您需要啟動服務，等幾秒的時間好讓它啟動和運行，然後執行一些仰賴該服務的其他工作。Start-Sleep 正是這種行為所需的，譬如，執行 Start-Sleep 10 會使殼層暫停 10 秒的時間。如果您需要更準確的控制，比如說，您可執行 Start-Sleep -milli 100 來暫停 100 毫秒的時間。Start-Sleep 會在指定的時間內完全中止殼層，包括指令碼、管線和任何一切在內。現在要是有人寫我期待已久的那個 Start-Nap 指令程式的話就太好了。
[圖 1] Select-String 命令的輸出 (按一下以放大影像)

複雜的比對
在我提供 HR 同仁他們想要的東西後，他們卻發現那其實不是他們要的。我的報告包含了對眾多 IP 位址的造訪，例如 207.68.172.246 (也就是 MSN® 網站)。調查人員的下一個請求是把我的報告精簡成只對特定 IP 位址的造訪，也就是他們識別出屬於前述的其中一個網站。在本專欄中，我將不會公開調查中出現的真正 IP 位址。針對此範例，我會改用 207.68.172.246 (雖然 MSN 網站一般不被認為是不當的網站)。
這項請求可能比較困難一點。在我處理的記錄檔中，來源和目標 IP 位址都是彼此相鄰，並且由一個逗號分隔。所以我只要把搜尋字串改成「192.168.17.54,207.68.172.246」，然後重複搜尋就行了。
然而，在比較複雜的記錄檔裡面，兩個 IP 位址之間可能存有變數，因此簡單的字串比對是行不通的。在這種情況下，您就得訴諸規則運算式，它也可以用在比較簡單的記錄格式中，這也正是我要在此處示範的。
在規則運算式中，句點字元是代表任何單一字元的萬用字元。而我可以使用子運算式 (.)* 來搜尋兩個 IP 位址之間的任何字元。不過，為了逸出出現在 IP 位址本身的文字句點，有必要使用反斜線。
所得的命令是：
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
因為我這次是使用規則運算式，所以我移除了 –simpleMatch 參數。所得到的輸出結果只會顯示從特定員工的電腦對被視為不當之特定網站的造訪。輸出也包括了調查人員想要的日期和時間戳記資訊。[圖 2] 顯示在執行這類命令時可能會得到的部分輸出。
[圖 2] 縮小範圍的搜尋結果，只顯示對特定網站的造訪 (按一下以放大影像)
但是我可以更進一步把輸出代入 Format-Table，並利用它的功能來顯示計算欄。我可以讓表格包含記錄檔的檔名和找到相符項目的行號，我甚至還可以顯示相符行本身。不過，我可以讓殼層以空白字串來取代規則運算式相符項目，而只顯示該行其餘的部分 — 在我的例子中即日期和時間戳記。這是進階技巧，但它更進一步示範了 Windows PowerShell 如何操作字串資料，並產生高度自訂的輸出，全都在單一命令列中完成：
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
[圖 3] 顯示我的最終結果可能的樣子。
[圖 3] Select-String 命令的格式化輸出 (按一下以放大影像)

真是個字串連連的世界
我宣布 Windows PowerShell 的物件導向本質是它最大的優勢，話說得有點太快。但是，儘管如此，還是有不能用物件的時候。
Windows PowerShell 可能活在物件導向的世界，所幸，Windows PowerShell 小組覺察到您的世界常常在格式化的字串裡包含外部資料，因此他們加進了 Select-String 命令。有了 Select-String 加上對規則運算式的熟悉度，您可以使用 Windows PowerShell 來編寫單行的命令剖析最複雜的字串。

Don Jones 是《Windows PowerShell:TFM》的作者之一，也著有其他十幾本 IT 書籍。請透過他的部落格與他連絡，網址是 www.concentratedtech.com。


嗨，Scripting Guy！ 與您的烤麵包機保持連線
Microsoft Scripting Guy

程式碼下載： HeyScriptingGuy2008_09.exe (150 KB)

如果要用幾個字總括描述我們所處的現代世界，下面四個字可以說相當貼切：保持連線。拜手機問世之賜，您再也不必待在家中苦候別人的電話，因為他們隨時隨地都能聯絡到您 (是呀，真方便哪)。而要感謝無線運算，您就算不在辦公室，也可以隨時辦公事，因為您可以在家裡、在海灘，或是在您想得到的任何地方工作。
真人真事：Scripting Editor 的爸媽最近去了一趟露營之旅，可是卻無法連上營地的無線網路，只好被迫將就度日 (就像偉大的探險家 Lewis 和 Clark 一樣)，幸好衛星電視還能用，真是謝天謝地！
不僅如此，GPS 裝置還可以讓您精確知道您所在的位置 (不出幾英呎的差距)，有的裝置甚至可以讓別人精確知道您所在的位置 (所謂「跑得了一時，藏不了一世」這句古語，用來形容現今的情況，真是再貼切不過了)。如果撰寫這篇專欄的 Scripting Guy 想要的話，還可以設定在每次支票過戶時讓支票帳戶打電話通知他；同樣的，也可以設定讓他的車每月以電子郵件寄送進度報告給他。不只如此，烤麵包機還可以在他外出渡假時，提供蹓狗和澆花的服務。
好啦，最後那項服務也許太誇張了 — 未來可難說了。不過如果想要的話，Scripting Guy 可以購買一部能夠連接網際網路的烤麵包機，然後在回家的路上打電話給烤麵包機，請烤麵包機準備好熱騰騰的吐司等他進門。是不是真的會有人想要在進門時看到熱騰騰的吐司，我們不知道啦，不過，想要的話…
當然嘍，如果每個人都要保持連線的話，那麼當那些從不追逐流行的 Scripting Guy 主張多多斷線時，不必太過驚訝。難道這表示 Scripting Guy 建議您丟掉手機或膝上型電腦嗎？當然不；就算 Scripting Guy 比手機或膝上型電腦還聰明，他們也不會這麼說。他們是建議您在指令碼集合中加上離線式資料錄集。不過，如果您要丟掉手機或膝上型電腦，我們也不會阻止您的啦。
注意根據 Harris Interactive 所做的調查，43% 的美國人曾在度假時，使用膝上型電腦來查看並傳送與工作有關的電子郵件。而超過 50% 的美國人在度假時，會用手機查看電子郵件和/或語音郵件。這還不包括 40% 已經超過一年沒放假的美國人在內。
不用說也知道，一定有很多人非常樂意在指令碼集合中加入離線式資料錄集，但問題是：他們根本不知道什麼是離線式資料錄集。好吧，為了讓您熟悉這個概念，我就簡單介紹一下。離線式資料錄集可以說是一個資料庫資料表，但它並沒有連到真正的資料庫，而是由指令碼建立，只存在於記憶體中，指令碼一結束，它就跟著消失。換句話說，離線式資料錄集是一個虛構的資料結構，只存在幾分鐘就跟著資料一起消失了。嘩！聽起來真的很好用耶，Scripting Guy。多謝了！
好啦，我們承認啦，離線式資料錄集聽起來沒那麼吸引人，而且也真的不吸引人，不過有時候真的相當實用。經驗老道的 VBScript 編寫人員很清楚，VBScript 的資料排序功能並非世界無敵 (除非您認為沒有一個資料排序功能稱得上世界無敵)。同樣的，VBScript 處理大量資料的功能也很有限，它不能處理 Dictionary 物件 (它會限制您使用最多具有兩個屬性的項目) 或陣列 (主要限於單屬性資料清單)，嗯 … 就這兩個。
但是離線式資料錄集可以解決這兩個問題 (還有其他問題)。您需要排列資料，尤其是排列多屬性資料嗎？沒問題，就像我們說的，離線式資料錄集是虛擬的資料庫資料表，沒有什麼比排列資料庫資料表更容易的事了 (好吧，如果您還想雞蛋裡挑骨頭的話，那麼不排列資料庫資料表，當然是比排列資料庫資料表容易啦)。要不然，您需要追蹤一大組多屬性的項目嗎？沒問題，我們不是說過離線式資料錄集是虛擬的資料庫資料表嗎？您需要以某種方式篩選那些資訊，或者在那些資料中搜尋某個特定值嗎？啊，要是有辦法可以使用虛擬資料庫資料表就好了 …
說得好，也許該是示範給您看的時候了 (如果我們知道該示範什麼就好了)。好，假設 [圖 1] 是我們從 MLB.com 網站搜尋到的棒球統計資料，它們是儲存在以 Tab 鍵分隔各值的 C:\Scripts\Test.txt 中。
[圖 1] 儲存在以 Tab 鍵分隔各值的檔案中的統計資料
球員 | 全壘打數 | RBI | 平均值
D Pedroia | 4 | 28 | .276
K Kouzmanoff | 8 | 25 | .269
J Francouer | 7 | 35 | .254
C Guzman | 5 | 20 | .299
F Sanchez | 2 | 25 | .238
I Suzuki | 3 | 15 | .287
J Hamilton | 17 | 67 | .329
I Kinsler | 7 | 35 | .309
M Ramirez | 12 | 39 | .295
A Gonzalez | 17 | 55 | .299
看起來很不錯。不過，如果我們要的是用全壘打數排列的球員清單呢？離線式資料錄集能夠幫我們做到這樣的事嗎？答案馬上就揭曉；請見 [圖 2]。看到一大堆程式碼了嗎？不過別擔心，等一下就知道它們其實沒這麼恐怖。
[圖 2] 離線式資料錄集
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
我們先定義四個常數：
  • ForReading。這個變數是用來開啟文字檔，以及從文字檔讀取。
  • adVarChar。這是標準的 ADO 常數，用來建立使用 Variant 資料型別的欄位。
  • MaxCharacters。這是標準的 ADO 常數，用來指出 [變數] 欄位能容納的字元數上限 (此處是 255)。
  • adDouble。最後一個 ADO 常數，用來建立使用 double (數值) 資料型別的欄位。
定義常數之後，就會看到下面這個程式碼區塊：
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
這是我們真正設定離線式資料錄集的指令碼部分。首先我們必須建立一個 ADOR.Recordset 物件的執行個體；不用說，此舉會建立一個虛擬資料庫資料表 (也就是離線式資料錄集)。
接著再使用這行程式碼 (以及 Append 方法)，在資料錄集加入一個新欄位：
DataList.Fields.Append "Player", adVarChar, MaxCharacters
您瞧，一點都不複雜：只不過呼叫 Append 方法，還有三個參數而已：
  • 欄位的名稱 (球員)。
  • 欄位的資料型別 (adVarChar)。
  • 欄位所能儲存的字元數上限 (MaxCharacters)。
加上 [球員] 欄位之後，可以再加上第二個欄位：[全壘打數]，其資料型別是數值 (adDouble)。完成這個工作之後，接下來就是呼叫 Open 方法，宣告離線式資料錄集已經開啟，並且可以用於商業用途了。
接著再建立 Scripting.FileSystemObject 物件的執行個體，然後開啟檔案 C:\Scripts\Test.txt。這個部分的指令碼其實與離線式資料錄集無關；只不過因為我們需要從文字檔擷取資料，才會加入這個部分。文字檔的第一行包含標頭資訊：
Player     Home Runs     RBI        Average
離線式資料錄集並不需要這項資訊，所以開啟檔案之後的第一件事，就是呼叫 SkipLine 方法，跳過第一行：
objFile.SkipLine
移到真正資料的第一行之後，接下來就是設定 Do Until 迴圈，這個迴圈是設計成逐行讀取剩下的部分。每當我們讀取檔案的一行時，就會把該值儲存在一個名叫 strLine 的變數中，然後用 Split 函數將這一行轉換成數值陣列 (每遇到一個定位點，就會斷開那一行)：
arrStats = Split(strStats, vbTab)
沒錯，我們只是簡單帶過，但是我們假設大部分看這篇文章的人，應該都知道如何從文字檔擷取資訊。長話短說，第一次執行迴圈時，陣列 arrStats 包含 [圖 3] 所示的項目。
[圖 3] 陣列的內容
項目號碼 | 項目名稱
0 | D Pedroia
1 | 4
2 | 28
3 | .276
現在我們已經準備好來點樂子了：
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
我們要在離線式資料錄集加上 1 號球員 (D Pedroia) 的相關資訊。要在資料錄集加上一筆記錄，必須先呼叫 AddNew 方法，以建立一筆新的空記錄供我們使用。接著再使用程式碼的下兩行，將這些值指派給兩個資料錄集欄位 ([球員] 和 [全壘打數])，再呼叫 Update 方法，正式將該筆記錄寫到資料錄集當中。最後再回到迴圈開頭，針對文字檔中的下一行 (球員) 重複執行這道程序。看到沒？也許還是有一大堆程式碼，不過現在看起來整齊清爽多了。
那麼，當所有球員都加入離線式資料錄集之後會怎麼樣呢？等我們關閉文字檔之後，再來執行這個程式碼區塊：
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
我們在第 1 行使用 MoveFirst 方法，將游標定位在離線式資料錄集的開端；如果不這麼做，可能只會顯示離線式資料錄集的一部分資料。接著就是設定 Do Until 迴圈，這個迴圈會持續執行，直到用完資料為止 (也就是到達離線式資料錄集的檔案結尾為止 — 屬性為 True)。
在迴圈裡面，我們只要回應 [球員] 和 [全壘打數] 欄位的值 (請注意，用來指出特定欄位的語法有點奇特：DataList.Fields.Item("Player")。最後再呼叫 MoveNext 方法，進入資料錄集的下一筆記錄就行了。
不說也知道，相當簡單吧。等該做的都做了之後，就會得到下面這個結果：
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
您瞧，很不錯吧！好啦，仔細想想，其實也沒那麼棒啦。就算我們取得球員姓名和全壘打總數，還是沒有把全壘打總數排好順序。真是的，離線式資料錄集怎麼沒幫我們排好資料順序啊？
其實原因是：我們根本沒告訴資料錄集我們想要依照哪一個欄位來排序。不過這很容易改正：只要修改指令碼，先加入排序資訊，接著再呼叫 MoveFirst 方法就行了。換句話說，讓那一段程式碼看起來像這樣：
DataList.Sort = "HomeRuns"
DataList.MoveFirst
很清楚，沒什麼花招，只不過是把 [全壘打數] 欄位指派給 Sort 屬性罷了。讓我們看看執行程式碼的結果：
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
好多了。不過，還有一個問題：通常全壘打總數是以遞增順序列示，全壘打數最多的球員排在第一個。有沒有什麼辦法可以用遞增順序排列離線式資料錄集呢？
當然有，只要加上好用的 DESC 參數就行了，請看下面：
DataList.Sort = "HomeRuns DESC"
那 DESC 參數能幫我們做什麼呢？說得好：
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
順帶一提，您可以依照多個屬性排序；只要指派每一個屬性給排列順序就行了。舉個例說，假設您想要先依照全壘打數，再依照 RBI 排序。沒問題，下面這個命令就可以幫您做到：
DataList.Sort = "HomeRuns DESC, RBI DESC"
您不妨試試看，親身體驗一下。雖然沒有度假時查看電子郵件那麼好玩，不過也不會差太多啦。
注意請記住，還沒加到資料錄集的欄位，不可以用來排列順序。這是什麼意思呢？這意思是，您在加入像 RBI 這樣的屬性到 Sort 陳述式之前，必須在指令碼的適當位置中加入下列幾行：
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
如果要查看結果，也必須修改 Wscript.Echo 陳述式：
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
讓我們看看，離線式資料錄集還能做什麼？喔，有了：假設我們擷取所有球員的所有資訊，然後依照打擊率來排序 (除了別的意思之外，這表示我們必須修改原始指令碼，建立名叫 [RBI] 和 [打擊率] 的欄位)。結果如下所示：
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
很好，但萬一我們只是要安打數 .300 或 .300 以上的球員名單呢？我們該如何做到只顯示符合某特定條件的球員呢？這個嘛，其中一個方法就是在資料錄集指定篩選器：
DataList.Filter = "BattingAverage >= .300"
資料錄集篩選器的功能相當於資料庫查詢：它提供一個機制，規定只傳回離線式資料錄集所有記錄的其中一部分。在這個案例中，我們只要規定篩選器只保留 [打擊率] 欄位值大於等於 .300 的記錄，其他全部去掉就行了。您猜結果如何？篩選器的表現完全符合我們的要求：
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
要是我們家小朋友也能這麼聽話就好了。
對了，您可以在一個篩選器內使用多項條件。比方說，下面這個命令就規定只傳回 [打擊率] 欄位值大於等於 .300，而 [全壘打數] 欄位值大於 10 的記錄：
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
相較之下，這個篩選器則是規定只傳回 [打擊率] 欄位值大於等於 .300，或 [全壘打] 欄位值大於 10 的記錄：
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
試試看，您就會明白哪裡不一樣。哎呀，我在鬼扯什麼：您也可以試試下面這個篩選器，就當作好玩吧：
DataList.Filter = "Player LIKE 'I*'"
結果顯示，您也可以在篩選器裡使用萬用字元。方法是使用 LIKE 運算子 (而不是等號)，然後再使用星號，就像您在執行一個像 dir C:\Scripts\*.txt 的 MS-DOS® 命令時一樣。在前面的範例中，我們會得出一份姓名以 I 開頭的球員名單；那是因為我們所用的語法是：「請列出一份 [球員] 欄位值以 I 開頭，後面是什麼都無所謂的所有記錄」。不妨試 — 好啦，您想也知道我要說什麼了。
對了，您也沒有陷入像 0.309 這種打擊率的陷阱 (通常表示打擊率的數字都會省略前面的 0，例如 .309)。不過無所謂，您可以只用 FormatNumber 函數，以您要的任何古老方法設定打擊率的格式：
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
顯示這個數字時，只要在 Wscript.Echo 陳述式中加入這個函數即可 (或者，也可以把輸出指派給一個變數，再將該變數置於您的 Echo 陳述式中)：
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
好玩吧？
不過，看來這個月已經沒時間了。簡單說就是 — 抱歉，電話響了。
不管怎樣，我們想提的是 — 喔，太好了，連手機也響了。我們剛剛收到一封從烤麵包機傳來的電子郵件。重要事項：熱騰騰的吐司已經準備好了，要奶油還是果醬呢？好啦，我們該走了，不過下個月還會再見！
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
這個每月一次的挑戰不僅測試您的解謎功力，更要測試您的指令碼技巧。

2008 年 9 月：指令碼搜尋
下面是一個簡單 (也許沒那麼簡單啦) 的字詞搜尋。請從清單中找出所有的 VBScript 函數和陳述式。但有個地方要注意：其餘的字母會拼出一個隱藏字詞，而那個字詞剛好就是 — 您猜猜看 — 一個 Windows PowerShell™ 指令程式！
字詞清單：Abs、Array、Atn、CCur、CLng、CInt、DateValue、Day、Dim、Else、Exp、Fix、InStr、IsEmpty、IsObject、Join、Len、Log、Loop、LTrim、Mid、Month、MsgBox、Now、Oct、Replace、Set、Sin、Space、Split、Sqr、StrComp、String、Timer、TimeValue、WeekdayName。

答案是：
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：2008 年 9 月：指令碼搜尋

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


桌面檔案 WDS 中的進階功能
Wes Miller

目錄
命令列管理
映像存放區
多點傳送
WDS 記錄
其他問題
總結
我在前兩期專欄中，都在探索 Windows 部署服務 (WDS)。我開始先回顧 Microsoft 推出的以開機前執行環境 (PXE) 為基礎的部署工具的歷史，隨後概述 WDS。這個月，我將深入探討一些進階主題 —
WDSUtil (適用於 WDS 的強大命令列公用程式)、WDS 映像存放區、WDS 記錄，以及針對 Windows Server® 2008 使用 WDS 中的多點傳送功能。
當遠端安裝服務 (RIS) 隨 Windows® 2000 和 Windows Server 2003 發行時，它的功能一直不如許多人嚮往般地豐富。尤其是以下三個區域：
  • 效能 (更容易擴充的部署)
  • 記錄/稽核
  • 命令列自動化
隨著本月專欄逐一介紹 WDS 的初次發行，特別是 Windows Server 2008 中的 WDS，您就不難發現這些領域都有了顯著的改進。

命令列管理
我在上個月曾提到 WDS 提供了大幅改良過的管理主控台。但對於大多數企業來說，更重要的是，WDS 提供了有利於管理工作的全新命令列公用程式，WDSUtil.exe (見 [圖 1])。WDSUtil 是隨 Windows Server 2003 (SP1+WDS 或 SP2) 上的 WDS 選用元件，以及隨 Windows Server 2008 上的 WDS 角色一同安裝。
[圖 1] 使用 WDSUtil 將架構探索選項設為 yes (按一下以放大影像)
WDSUtil 是威力極強的公用程式，但卻很複雜。事實上，您經由 Microsoft® Management Console (MMC) 進行的任何動作，透過 WDSUtil 都可以辦得到。廢話不多說，不妨舉個最佳實例，這剛好也是診斷問題的最佳辦法，執行看看：
wdsutil /get-server /show:config
結果幾乎跟您在整個 WDS MMC 中看到的一模一樣 — 然而 WDSUtil 以容易細讀的格式將它輸出，讓您隨後輸出成文字檔。
資訊不夠？改試下列的命令，這麼做甚至會傳回更多內容：
wdsutil /get-server /show:all /detailed
而且您可以停止和重新啟動 WDS 伺服器，只要執行：
wdsutil /stop-server
wdsutil /start-server
您可以在 go.microsoft.com/fwlink/?LinkId=112194 找到 WDSUtil 的命令參考資料。您高興的話，還可以在 go.microsoft.com/fwlink/?LinkId=89381 下載這份參考資料的 .chm 版本 (隨附所有 WDS 2008 文件)。
要使用 RIS 透過命令列來確定特定 MAC 位址或 GUID 是否與 Active Directory 中的電腦帳戶物件 (MAO) 相關聯並非易事 — 除非您是 Active Directory® 服務介面的高手。而透過 WDSUtil，您可以根據任一者來進行查詢。
GUID 可能很容易令人混淆，因為您可以將它們當作二進位字串，也可以當作 GUID 字串來輸入，而當中唯一的差別是位元組的順序，以及有無連字號。您可以使用下列幾行程式碼輸入包含或不含連字號的 MAC 位址：
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
您可以使用這個命令透過二進位字串來取得裝置資訊：
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
或者，您可以使用這個命令透過 GUID 來取得裝置資訊：
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
您有很多電腦可能可以執行 64 位元版本的 Windows，但不幸的是，有些電腦無法正確報告它們的架構。您可以讓 WDS 嘗試判斷某系統是否具備 x64 能力，方法是執行一個 net-boot 小程式，這個程式是作為 WDS 的一部分而提供的。如 [圖 1] 所示，您可以使用下列命令進行這個動作：
wdsutil /set-server /architecturediscovery:yes
事實上，WDSUtil /set-server 命令可讓您設定大量的伺服器設定。要看它有何威力，可執行這段命令：
wdsutil /set-server /?
如果您已將 Windows Server 2003 WDS 伺服器升級至 Windows Server 2008，就可以將任何 RIPrep 映像轉換成 Windows Imaging Format (WIM) 映像，只要執行：
WDSUtil /convert-RIPrepImage
雖然 WDSUtil 可以轉換 RIPrep 映像，但無法轉換其餘任何 RISetup 映像 (傳統 RIS/舊版 WDS 指令碼式安裝)。
WDSUtil 的威力在於它能夠自動化重複性工作。[圖 2] 中的命令可讓您大致了解 WDSUtil 的功能。無論您是部署新 WDS 伺服器，新增或修改多個伺服器上的映像，管理多點傳送基礎結構，還是指定要用於特定開機用戶端的網路開機程式，WDSUtil 所提供的一些超強功能都是在 RIS 中前所未見的。
[圖 2] WDSUtil 命令
命令 | 描述
/add | 新增裝置、映像或映像群組。
/approve-AutoAddDevices | 核准擱置中的自動新增裝置，並允許您為它們設定組態資訊。
/convert-RiprepImage | 將舊版 RIPrep 映像轉換成 WIM 映像。
/copy-Image | 在映像存放區內複製映像。
/delete-AutoAddDevices | 刪除所有或特定的擱置中自動新增裝置。
/disable | 停用 WDS 伺服器或傳輸伺服器。
/disconnect-Client | 中斷用戶端與多點傳送傳輸或命名空間的連線。
/enable | 啟用 WDS 伺服器或傳輸伺服器。
/export-Image | 跟 ImageX 中的 /export 一樣，這會將現有的映像從映像存放區匯出成 WIM 映像。
/get | 取得裝置、映像、映像群組、WDS 伺服器或傳輸伺服器的內容和屬性。
/initialize-Server | 設定 WDS 伺服器以供第一次安裝後使用。
/new | 建立擷取或探索映像、多點傳送傳輸和命名空間。
/progress | 顯示當執行指定命令時的進度。
/reject-AutoAddDevices | 拒絕所有或特定的擱置中自動新增裝置。
/remove | 移除映像、映像群組、多點傳送傳輸和命名空間。
/replace-Image | 以新映像取代 (覆寫) 映像。
/set | 設定裝置、映像、映像群組、WDS 伺服器或傳輸伺服器的內容和屬性。
/start | 啟動 WDS 伺服器或傳輸伺服器。
/stop | 停止 WDS 伺服器或傳輸伺服器。
/uninitialize-Server | 還原在伺服器初始化期間對伺服器所作的變更 (將它還原為未設定狀態)。
/update-ServerFiles | 從伺服器的 System32\RemInst 目錄以最新版本更新伺服器 REMINST 共用中的檔案。
/verbose | 顯示執行指定命令時的詳細輸出。

映像存放區
上個月我曾提到 WDS 遺棄了 RIS 用在磁碟上更有效儲存檔案的儲存單一版本 (SIS)。而現在，所有原生模式 (WIM) 映像 (無論 OS 為何)，全都存放在 WDS 映像存放區中。我在之前專欄中提過，當磁碟區映像有相關檔案時，單一執行個體功能可在 .wim 檔案中為您省下不少空間。而 WDS 映像存放區也具備相同的作用。事實上，它正是使用 WIM 功能來存放映像的。
若要使用映像存放區，您必須至少擁有一個映像群組，WDS 初始化一般會提示您建立映像群組。您也可以在新增安裝映像時建立新的映像群組，而該映像會加入該映像群組中 (見 [圖 3])。
[圖 3] 建立新的映像群組 (按一下以放大影像)
那麼，映像存放區到底是什麼呢？看一下您的 RemoteInstall 目錄下，在 Images 目錄中會看到每個您建立的映像群組都有目錄。如 [圖 4] 所示，針對您匯入到映像群組的安裝映像都有一個 .wim 檔案，另外還有一個 .rwm 檔案 (資源 WIM)。
[圖 4] 映像群組的內容 (按一下以放大影像)
仔細看一下 [圖 4] 中的檔案。這個映像群組包括了：
  • install.wim (Windows Server 2008, Standard Edition)
  • install-(2).wim (Windows Server 2008, Enterprise Edition)
  • install-(3).wim (Windows Server 2008, Datacenter Edition)
  • install-(4).wim (Windows Server 2008, Standard Edition (Server Core)
  • install-(5).wim (Windows Server 2008, Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008, Datacenter Edition (Server Core)
現在比較這些檔案與 MMC 的檔案大小 (如 [圖 5] 所示)。[圖 4] 中每個 .wim 檔案的大小都是 Res.rwm 檔案大小的一小部分。為什麼呢？是這樣的，為了節省空間，顯示的 .wim 檔案不過是實際檔案剩餘的一小部分。它們包含用以還原 .wim 檔案的中繼資料，但並不實際包括檔案資源。映像群組裡面所有的檔案資源都存放在該映像群組的 .rwm 檔案中。
[圖 5] 顯示在伺服器管理員中的映像 (按一下以放大影像)
若要編輯映像存放區中的安裝映像，您可以匯出該映像，進行編輯，然後取代該映像 (或是重新將它匯入)，或者您也可以與映像互動，方法是從 MMC 停用適當的安裝映像，然後透過掛接和修改 .wim 檔案來進行編輯。
RIS 一直有映像複寫方面的問題。當您透過網路複製 SIS 處理過的檔案時，SIS 會因為它是 NTFS 屬性的關係而消失。這表示，若是您有 40GB 的 RISetup 和 RIPrep 映像，然後您將它們複寫到另一部伺服器，即便 SIS Groveler 將它們的大小縮減至 5GB 那麼小，您仍舊是在網路上複寫 40GB 的資料。而 WDS 映像存放區則不是這麼一回事。事實上，藉著映像存放區的架構，您可以將它儲存在分散式檔案系統 (DFS) 伺服器上，然後使用 DFS 複寫 (DFS-R) 在不同的網站間進行複寫。
而這方面的特性因情況而異，要看 WDS 的版本而定。對於 Windows Server 2003，請參閱說明文件中的第七章＜使用映像＞(英文)，這份說明文件可從 go.microsoft.com/fwlink/?LinkId=81031 下載。對於 Windows Server 2008，請參閱＜使用 DFS 儲存和複寫映像＞(英文)，網址是 go.microsoft.com/fwlink/?LinkId=121960。由於資源全都是儲存在 .rwm 檔案中，因此即使當您在伺服器間複製映像群組，跨越網路的資料量仍舊跟傳輸整個 .wim 檔案的一小部分一樣 (或是在舊版 RIS SIS 架構中)。
那麼您何時應該建立新的映像群組，何時又該使用舊的映像群組呢？原則大致上跟 .wim 檔案沒什麼兩樣。雖然您可以將 Windows XP Professional SP3 的映像放入主要是由 Windows Server 2008 映像所組成的映像群組中，但是這其實並不怎麼合理，因為您省不了多少空間。至於 .wim，您一般至少都應該針對下列情況擁有一個映像群組：
  • 每個特定的 Windows 版本 — 此處的版本包括 SKU (Windows XP Professional) 和 Service Pack 修訂 (SP3)。
  • Windows Server 2003 及早期版本：每個當地語系化版本 (非多語言使用者介面)。Windows Vista® 之前的當地語系化組建的二進位碼截然不同，因此就單一執行個體來說，它們在儲存 .wim 檔案中的情況並不佳。
  • 每個版本的每個 Service Pack。雖然您可能可以將 Windows Server 2008 和 Windows Vista SP1 映像存放在一起，也請考慮這麼做是否符合貴組織所需的功能。
映像存放區比它之前的 SIS 更節省空間 — 同時在磁碟上和網路上，而且通常不用多費什麼力氣就能順利運作。

RIS 最大的缺點之一是缺乏延展性。而多點傳送部署可以矯正這個缺點。人們常常認為多點傳送是「較快速」的部署，但它其實跟速度沒什麼關係 — 而是在於「廣度」。您可以透過 RIS 部署多部系統，事實上，RIS 可以同時處理大約 75 部系統的部署工作。
但是遠在達到這個極限之前，效能早已受到波及，而且每個安裝作業所花的時間也越來越長。更糟的是，安裝的數目增加，發生失敗的可能性也跟著提高。同時，多項安裝也會因伺服器訊息區 (SMB) 網路流量充斥而使網路飽和 (因此在部署期間，員工可能無法取得重要的網路資源，例如 Microsoft Exchange Server)。
多點傳送的重點在於擴充您的部署數量。無論您是部署四部伺服器或是含有 100 個系統的會議中心，多點傳送都能讓您在短時間內，以及在不使網路飽和的情況下完成部署作業。雖然您可以使用多點傳送部署到單一系統，但擴充的功效其實要等到有多部系統接聽傳輸時才比較顯著。
若要使用多點傳送，您必須擁有支援多點傳送的路由器。一般來說，這表示應該啟用網際網路群組管理通訊協定 (IGMP) 窺探。您還必須裝有 Windows PE 2.1 (Windows Server 2008 RTM 或 Windows Vista SP1)，因為隨 Windows Vista RTM 一起發行的版本 (2.0) 並無法接收多點傳送傳輸。
若是您在相同的網路上擁有多部 WDS (或其他多點傳送) 伺服器，您也應該確實指定自訂 IP 位址範圍。這透過 WDS MMC 很容易就可以變更，只要在伺服器上按滑鼠右鍵，按一下 [屬性]，再按 [網路設定] 索引標籤就行了。
在執行多點傳送廣播時，多點傳送伺服器可以調整成最慢的用戶端可以接收的速度，也可以將速度調整在較高的層級，然後捨棄速度不及的用戶端。為求穩定性，WDS 會以接收傳輸最慢的用戶端速度來執行。
如果您發現傳輸效能比您預期的低，可執行 wdsutil /Get-MulticastTransmission/Show-clients。這將顯示拖延傳輸的主用戶端。您接著可中斷與該用戶端的連線，它隨後會還原為使用 SMB 而不是多點傳送。如需可自動中斷與慢速用戶端連線的範例指令碼，請前往 go.microsoft.com/fwlink/?LinkId=121961。
若要建立多點傳送傳輸，您可以在安裝映像上按右鍵，然後選取 [建立多點傳送傳輸]，或是在 WDS 主控台中以滑鼠右鍵按一下 [多點傳送傳輸]，再選取 [建立多點傳送傳輸]。您在建立多點傳送傳輸的同時，也可以建立自動傳送或排程傳送。如果您有好幾個用戶端會定期上線，而且全都需要一模一樣的映像，那麼自動傳送就蠻管用的，因為新用戶端會自動加入當初針對第一個要求安裝映像的用戶端所起始的現行傳輸。而排程傳送則可讓您設定群組大小，在達到此大小時開始進行傳輸。
您也可以將傳輸設定在指定的時間開始。一旦用戶端開始利用多點傳送傳輸，您便可以按一下映像名稱來檢視它們。在右窗格中，您會看到連線到傳輸的用戶端的特定資訊。
一般來說，您的使用者會從 WDS 安裝用戶端使用多點傳送。不過，Windows Server 2008 Windows 自動安裝套件 (WAIK) 內有發行一個名為 WDSMCast 的命令列公用程式，可讓您從 WDS 透過多點傳送傳輸來要求 .wim 檔案。傳輸 .wim 檔案時必須傳輸整個檔案，然後套用到用戶端 — 因此您應該要確保有足夠的磁碟空間存放和套用映像。下個月，我將探討如何將 WDSMCast 整合至您自己自訂的部署程序中。

WDS 記錄
WDS 能夠執行相當可觀的記錄和追蹤作業，不過為了節省空間，這些功能預設是停用的。事件記錄有兩種類型 — 當用戶端寫入 Windows 事件記錄檔時，以及針對其他 WDS 層面寫入追蹤記錄檔時。
然而，在 Windows Server 2008 中，WDS 預設的確會執行為數不少的記錄作業。這些記錄檔可從 [系統管理工具] | [事件檢視器] 下取得。您可以在事件檢視器中的 [應用程式及服務記錄檔] | [Microsoft] | [Windows] | [Deployment-Services-Diagnostics] 下看到 WDS 記錄檔。為了方便起見，這些記錄檔跟您在 MMC 中查看 WDS 角色時看到的記錄檔是一樣的 (見 [圖 6])。
[圖 6] 在伺服器管理員中檢視 WDS 事件 (按一下以放大影像)
您可以使用下列引數執行 WDSUtil 來啟動 WDS 用戶端記錄 ([圖 6]中顯示的事件記錄檔)：
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
您也可以在 WDS 好幾個不同的子元件上啟用追蹤記錄。若要設定追蹤，請在登錄機碼下適當設定 DWORD 登錄值，如 [圖 7] 所示。追蹤記錄檔全都是存放在 \Windows\tracing 下。您接下來需要重新啟動適當的元件，以便開始記錄。
[圖 7] 設定追蹤記錄
WDS 元件 | 登錄機碼 | 登錄值 | 記錄檔名稱
伺服器 | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
多點傳送 | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
管理元件 | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
WDS 也有效能計數器 (在 go.microsoft.com/fwlink/?LinkId=121962 有說明)，您可以在發生系統效能問題時進行監視 (或是事前進行系統效能分析)。如前所述，如果您遇到問題時，可以使用 WDSUtil 的 /detailed、/verbose 或 /progress 參數取得更詳盡的資訊。
若是 WDS 用戶端在連接或與 WDS 伺服器互動時發生問題，Microsoft Network Monitor (Netmon) 則是偵錯這些問題的絕佳工具。您可在 go.microsoft.com/fwlink/?LinkId=121491 下載取得網路監視器。

其他問題
我有看到幾個值得一提的問題。第一個問題是記憶體 — 別忘了 WDS 的核心是以 Windows PE 2.x 為基礎。這也就是說 WDS 用戶端需要至少 384MB 的 RAM — 就現實的角度來看，您應該確保擁有 512MB 以達最佳效能。也別忘了 Windows PE 2.x 無法在非進階組態與電源介面 (ACPI) 系統上開機 — 這並不一定是指舊式硬體。就曾有報告指出相當新型的系統不支援 ACPI。
請注意這些系統也不支援 Windows Vista 或 Windows Server 2008。對於不支援 ACPI 的系統，您必須保有 Windows Server 2003 或舊版 WDS 或 RIS 伺服器，供預備接移到它的該些用戶端使用，或是透過非 PXE 的機制來安裝 Windows。
最後請牢記，如果您想要從伺服器啟動 Windows PE 1.x，您也需要使用 Windows Server 2003 或舊版 WDS 或 RIS 伺服器，因為 Windows Server 2008 中的 WDS 無法啟動 Windows PE 1.x 映像 (RAMDisk 或 PXE)。

總結
到目前為止，我深入探討了 WDS 的歷史、基礎，以及進階主題。下個月，我將討論一些自訂 WDS 案例 — 特別是您要如何與 WDS 互動，以及如何修改它來執行您要它進行的工作，這往往不用現有 WDS/安裝經驗就可以辦到。

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


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

目錄
超載的更新技術
不一致的安全性訊息
全都是勾選符號在作怪
召集令
在前幾期的《TechNet Magazine》中，我討論到安全性專家與 IT 產業常會混淆消費者，而且實際上阻礙了有效的安全性運作。在本系列專欄的前兩期中，我所討論的問題主要是一些解決方案會提供誤導資訊，使登入工作流程超載，
還有教導錯誤的行為等等。到目前為止，我已經提供很多不同的範例來說明 IT 產業表面上很熱中提倡消費者安全性，但實際上反而使得情況無謂地惡化。在這第三篇也是最後一篇專欄中，我將說明某些供消費者使用的重大技術，如何違背消費者對這些解決方案的期望。接著我會提出我的召集令作為總結。

超載的更新技術
在電子世界中保障安全性的主要原則之一 — 事實上也是不可動搖的必要條件，就是確保所有軟體都處於最新狀態。幾乎今日所有軟體提供者都提供某種形式的半自動化機制，以保持至少一部份軟體處於最新狀態。不過事情並非這麼簡單。
首先，您使用的軟體越多，需要更新的軟體也越多。而您從越多廠商取得軟體，所要應付的更新機制就越多樣化。這是造成混淆的因素。
比方說，如果您不更動預設值，Internet Explorer® 會自我更新。但 Internet Explorer 其實只是其他技術的容器。在 2008 年的 CanSecWest 大會上，Shane Macaulay 結合 Java 與 Adobe Flash 的安全性弱點來入侵 Mac，藉此示範這麼做可能產生的衝擊 (詳細的資料不太齊全，因為我在撰寫本專欄的同時，這些安全性缺陷尚未公開)。然而，我的重點在於，雖然這些技術都不屬於內建元件，但由於網際網路上的廣泛應用，因此在大部分的電腦中都可以找到這兩種技術。這些技術更新不易 — 它們都包含自動更新機制，不過這些機制啟動的頻率卻很低。
再說，大多數的使用者根本不曉得這些技術存在，更不知道它們也需要更新。通常這些技術是從電腦上的 OEM 映像提供，而消費者往往無法分辨它與作業系統有什麼不同。對使用者而言，只要 Windows® Update 說沒有更新檔，那就表示沒有更新檔。
第二個問題是更新機制常常過度複雜。缺乏全面自動化模式的更新機制不太可能被廣泛使用，因為一般使用者都不知道要執行更新工具。此外，在大部分的情況下，使用者必須是系統管理員才能安裝更新。最糟糕的情況就是，使用者必須是系統管理員，才能收到可用更新的通知。
最後，有越來越多的廠商開始使用軟體更新技術來部署使用者並未安裝且完全無關的軟體 — 工具列等諸如此類。軟體更新技術從原本專為部署軟體更新內容的技術，轉變為散發額外軟體的途徑。
Microsoft® Windows Update 服務 (如 [圖 1] 所示) 與 Apple Software Update (如 [圖 2] 所示) 就是兩個顯而易見的例子。除了更新原有軟體，Apple 與 Microsoft 都選擇使用其更新機制來部署使用者原先並未安裝的新軟體。
[圖 1] 使用 Windows Update 部署 Silverlight (按一下以放大影像)
[圖 2] 使用 Apple Software Update 散發 Safari (按一下以放大影像)
以 Apple 的情況來說，即使您只安裝了 QuickTime，更新軟體程式還提供了 iTunes 與 Safari。有趣的是，這兩個軟體都已經預設選取。
至於 Windows Update，最近利用更新服務來部署的新軟體是 Silverlight™。Microsoft 一直使用此技術來散發新軟體。但是值得稱許的是，Microsoft 至少並未在預設情況下選取安裝新軟體的選項。
這種經由更新機制來散發新軟體的方法，會為使用者帶來兩個問題。首先，很多使用者的電腦都會安裝比原先還多的軟體。您也知道，任何種類的軟體都有錯誤，而當中有些錯誤會導致潛在的安全性漏洞。其中某些安全性漏洞終究會被當作攻擊的手段。因此，有些使用者會因為自己不需要甚或是不使用的軟體 (透過軟體更新機制安裝在電腦上) 而遭到攻擊。
另一個副作用就是，使用者可能會對軟體更新機制的價值產生誤解。如果使用者發現軟體更新機制被用來部署新軟體而非更新內容，他們可能會覺得更新機制很麻煩，並不再使用更新機制。想像一下，使用者如果遭到攻擊，而且攻擊的漏洞是透過軟體更新機制安裝但從未使用的程式，使用者會做何感想。
比起使用者不再信賴原本應該保障使用者安全的技術，還有一些事情對於技術生態系統的健全與安全危害更大。一旦使用者失去信賴感，便會開始排斥這些技術，最終棄用這些技術。如果保障安全性的關鍵技術 (更新技術就是關鍵技術) 被打入冷宮，那麼整個技術生態系統都會遭受威脅。正是為了保護此生態系統，Microsoft 甚至願意散發安全性更新給眾所皆知執行盜版軟體的電腦。
相較之下，我真心推崇 Mozilla Firefox 更新介面簡潔且用途明確的設計，如 [圖 3] 所示。我當然希望 Mozilla 能夠繼續抵抗誘惑，不要透過自身的軟體更新工具來散發額外的軟體。
[圖 3] Firefox 的軟體更新介面是業界最簡潔的設計之一 (按一下以放大影像)

不一致的安全性訊息
要是 IT 產業能夠為消費者一起提供標準的訊息，那就太好了。雖然 IT 產業基本上是相互競爭，但是消費者需要知道安全性的意義何在。遺憾的是，如果業界不斷傳遞矛盾的訊息，消費者只會無所適從。坦白說，如果公司本身能維持一致的訊息，我也能勉強接受。
雖然 IT 產業大概永遠無法搞定這樣的標準訊息，但至少必須確保訊息的一致性和可信度。既然讓客戶繼續信賴安全性技術這麼重要，IT 產業全體都必須更加努力。
同樣地，我們也需要反問今日什麼才能提供真正的價值。舉例來說，我不認為現今的防毒軟體像業界所宣稱的那麼有效或重要。就以我七歲的兒子使用的電腦和我放在廚房的電腦為例，這兩台電腦都安裝了防毒軟體，但是打從安裝以來的三年內，從未提出任何警報。當然，我的意思不是要拋棄防毒軟體 — 就目前而言，防毒軟體仍然是技術生態系統中的核心元件。不用說，如果我們一下就移除所有防毒軟體，攻擊者一定會很快利用這個情勢，而我們會發現中毒的案例越來越多。
重點是，業界必須思考安全性產品中哪些是真正符合使用者需求的功能，這些功能的效用如何，還有公司要如何與消費者溝通這些需求及價值。顯然，今日的使用者收到太多矛盾、誇張，且通常為不實的安全性訊息。

全都是勾選符號在作怪
舉例來說，安全性軟體產業都是以套件為主。現在的安全性軟體的散發方式幾乎都包含了似乎無關的功能套件。而且實際上沒有任何資訊可指出其中哪些功能真正符合使用者需求。
這種現象可能是為了比賽加入更多勾選符號所造成的。雖然勾選單提供了不錯的參考方式來比較產品，但也可能導致不必要、不受歡迎，甚至不合常理的功能越來越多。[圖 4] 到 [圖 7] 顯示不同安全性軟體廠商提供的四種勾選單。我們可以放心假設包含 17 個勾選項目的產品一定優於只有 10 個勾選項目的產品嗎？
我認為這些數字頗值得玩味。在 [圖 4] 中，產品因為是新版本而加了一個勾選符號。而 [圖 5] 加了勾選符號是因為公司聲稱此產品能「遏止惡毒的網站攻擊」。[圖 6] 中的產品多加一分，因為它能「線上保護兒童」。當然，沒有人會希望產品不保障兒童的安全性。不過，贏家以創意取勝，因為它在安全性套件中還加入了清除登錄和硬碟重組等功能。清除登錄的功能幾乎沒有必要，而硬碟重組功能根本已經內建在 OS 中。事實上，以 [圖 7] 所顯示的 17 個勾選項目來說，Windows OS 已經涵蓋其中 15 個勾選項目的解決方案。
[圖 4] 這個暢銷產品只有 10 個勾選項目 (按一下以放大影像)
[圖 5] 這個產品包含 11 個勾選項目，一定比較好 (按一下以放大影像)
[圖 6] 等一下，這個產品有 12 個勾選項目 (按一下以放大影像)
[圖 7] 這個包含 17 個勾選項目的產品一定是最棒的解決方案，不是嗎？(按一下以放大影像)
我們所面對的是一種惱人的趨勢。這些產品不僅重複提供作業系統已經包含的功能 (卻在行銷文宣上隻字未提)，而且還自吹自擂。舉例來說，世界上沒有任何安全性軟體可以真正抵抗任何攻擊來源 — 它們只能防範於未然。也沒有任何產品能夠確實避免您成為攻擊者的目標。
問題是，軟體安全性產業的工作主要在於讓使用者不受其他廠商建立的產品所造成的安全性弱點危害。但是那些廠商不斷改良以保護自己的客戶，因此安全性軟體產業發現自己的商業模型受到威脅。不過，當新的安全性風險浮現時，安全性軟體產業的用處的確很大，但是這些廠商必須協助客戶管理風險，而非只是針對已經沒有危險的威脅提供防護。

召集令
如果說我希望讀者可以從這三篇系列專欄中記取一件事的話，那就是身在業界的我們必須對使用者與客戶坦誠以待。我們必須說明風險以及使用者如何因應這些風險。最後我們還需要開始提供使用者自我保護的工具。
所有這些「解決方案」最讓我憂心的地方是，長遠來看，它們最終很可能會減損安全性。如果使用者，甚至是 IT 主管，真的相信這些產品會解決實際的安全性風險，尤其是這些產品不實聲稱可以解決的風險，我們很可能喪失教導人們如何真正保護自己的良機。
就以密碼驗證系統為例。如果使用者相信密碼型驗證系統的無用附加元件 (我在第一篇系列專欄中討論過) 真的會保障他們的安全性，使用者可能會更加鬆懈，而使用更不牢靠的密碼。我在這個系列文章中所強調的最糟情況是，安全性技術實際上會強迫使用者採用比較脆弱的安全性環境，若非實作該新技術，使用者原本的安全性防護反而還比較有效。也就是說，當惡意使用者找出辦法來擊敗這些系統時 (通常不太困難)，我們的處境會比現在更糟。這可能會導致嚴重的信任問題，使人們拋棄真正有價值的解決方案。
我們必須立即行動，保護我們的產業賴以生存的技術生態系統。當然，創新技術值得鼓勵，但是我們也必須非常小心，以免只為了創新而創新，反倒阻礙了真正的風險分析。不然的話，我們空有安全性劇場 (security theater)，而此安全性劇場最終也會在我們眼前崩塌。
我所討論的另一個例子也是一樣。就以無意義的安全性視覺指標為例，它對於使用者毫無益處，製造安全性的假象，讓線上服務提供者以實際上會導致使用者間接傷害的最佳化來敷衍了事。另一方面，為使用者提供正確資訊的淨成本可能只要幾千美元，最多也不過數萬元。要求廠商花一點小錢來保障客戶與業務的安全性難道太過份嗎？
其中牽涉的層面很廣。首先，我們必須矯正使用者無法自己做決定，因此要避免讓使用者做決定這樣的觀念。使用者並不是無法教導為自己做決定。畢竟，這些使用者已經做出許多決定，例如決定購買電腦、使用您的網站，或是購買您的產品或服務。就像人們需要學習安全駕駛，他們也必須學會安全地使用電腦。今日的攻擊者會鎖定個別使用者，我們不能依賴安全性技術來做決定。相反地，安全性技術應該是支援決策的系統，適時提供正確資訊，好讓使用者做出明智的決定。
市面上某些很糟糕的使用者介面正是出自安全性解決方案，因為這些應用程式的設計若非讓使用者無法作任何決策，不然就是一股腦將所有可用資料 (非常不友善地) 推給使用者。這兩種方法都有不良影響。前者會提高使用者風險，因為他無法仰賴安全性技術來做出適當的選擇。而且萬一安全性技術被認為會妨礙使用者的商務目標，這項技術很快就會棄而不用了。而第二種方法的問題在於，沒有使用者想要看到 IP 位址、處理序識別碼和其他難以理解的資料。使用者只想知道電腦會如何處理他們的密碼與信用卡。畢竟，這才是安全性的重點所在。

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


現場筆記 內在創新
Romi Mahajan

知名的管理大師暨商業策略大師 Gary Hamel 在他著作《管理大未來》(The Future of Management) 一書當中，主張長期比較優勢是起源於創新文化的建立，而創新文化本身則是管理技術進化下的產品。儘管業界本身經歷過無數次的創新與改造，大多數的公司仍然沉浸在階層管理文化的迷思中。這種現象會阻礙正統創新文化的興起，因為它無法在人力資本及人類創意上獲得可觀的成果。
這種階層是創新的詛咒；而人類創意得以自由發揮時，才是長期創新比較優勢的主要後盾。當人類創意受到束縛時，則有八成以上的人無法全心投入他們的工作。Hamel 認為這不只是商業的失敗，更是道德的淪喪。
這套理論對於鼓勵業界揚棄過於繁複的階層而言，應該是一項強而有力的號召。其論點基本上是出自一種反官僚的思維，也就是決策權不應該掌握在疏離的管理人員和富有的高階主管手上。
Hamel 認為管理部門 (而非 IT) 才是創新的來源。畢竟，IT 可能會被商品化，商品化的 IT 如何提供比較優勢呢？如果 IT 不是創新的來源，而且如果產能、執行時間、可靠性、新應用程式快速上手，以及單一登入 (及類似作法) 都無法提供比較優勢的話，那麼我們到底在擔心什麼呢？
您願不願意深入瞭解貴公司及 IT 組織的內在，看看 (只是假設) Hamel 的論點是否行得通呢？您怎麼能確定 IT 不是被當成商品看待呢？
我把 Hamel 的精華概念作為創新的中心理念加以融入，利用這些概念幫助 IT 組織保護它們的未來，進而發展出一套理論，稱為「內在創新」。將人類創意和人力資本兩者發揮極致，是提供比較優勢的關鍵，大公司必須把創新當作公司運作的根本。組織必須重視的是眾人共同體，而不是官僚體制。最重要的一點是，管理部門也常常阻礙真正的創新 — 除非管理部門逐步成長，推動真正的創新。
讓我們看看 IT 組織吧。IT 工作人員多半聰明、專注且渴望創造影響力。但是他們常常必須在資源不足的情況下完成重責大任，所以大部分的時間多半用來進行主要工作，而無法關照到創新這部分。
而我的「內在創新」概念，則是將 Hamel 的理論應用在 IT 領域。其主要理念是：
  • 只要具備 IT 工作人員渾然天成的創意，那麼確保 IT 管理模式善用這項潛能，對我們是最有利的作法。
  • 創新是出自思考 – 嘗試 – 錯誤 – 修正的條理及挑剔程序，而這也是 IT 本身固有的程序。
  • 只要敞開心胸，深深擁抱眾人共同體，就會產生技術解決方案。而 IT 可以在此擔任引導的角色，從它本身開始做起！
  • 在 IT 業界，人是比較優勢的唯一來源。
  • IT 管理部門必須從強調專案和預算，逐漸改走強調創新管理的酷眩新路線。
  • IT 不應該只專注在控制成本，而是要創造豐厚的成果。
您是否已準備好信奉這個理論了嗎？我們是否能應用「內在創新」的概念，並且證明 IT 組織就是適合這項偉大實驗的標的呢？管理階層是否都準備好放棄權力，改而擁抱自己的眾人共同體呢？管理部門是否也準備好放棄自己的權力，擁抱我們的集體才華呢？

Romi Mahajan 是 Ascentium Corporation 的行銷長。他在加入 Ascentium 之前，曾在 Microsoft 工作七年以上，最後擔任的職務是技術聽眾與平台行銷總監。Romi 在技術、政治、經濟及社會等多方領域都曾廣泛發表過文章。


Windows 機密文件 Windows 95 原形畢露
Raymond Chen

雖然 Windows® 95 的 32 位元程式可以使用您的 32 位編譯器，16 位元程式可以使用您的 16 位元編譯器，但是 Windows 95 本身需要的是一種特殊的編譯器 ─ 一種懂得 32 位元和 16 位元世界，而且可以彌補兩者差距的編譯器。Windows 95 還需要一個懂得如何連接兩種類型程式碼的自訂連結器，以及 VxDs 的自訂連結器 (Windows 95 的驅動程式格式)。
Windows 95 小組在語言和工具部門的協助下，推出這些特殊用途的編譯器及連結器。我相信語言部門一定覺得這個要求很奇怪：「您要我們編寫一個執行 X、Y 和 Z 的編譯器，而這個編譯器終其一生只要編譯兩個 DLL？」沒錯。不過這可是兩個相當重要的 DLL 喔！
即使這項要求明顯怪誕，語言和工具部門仍然努力完成，讓高度專業的編譯器和連結器成為 Windows 95 組建程序的一部分。當然，這個編譯器並不是馬上成形，Windows 小組是根據初版，以實作最佳化和修正錯誤的方式定期更新。
有一天，Windows 95 組建的速度不知為何慢得出奇。平常只要幾秒鐘就能夠連結的檔案，竟然花了數分鐘。雖然檔案還是順利產生，但大夥兒已經等到天荒地老了。而且，這種現象還不只發生在一部開發人員的機器上，而是整個小組的機器上。難道是我們的程式碼在連結器中突然遇到病態案例嗎？莫非是碰到連結器錯誤？
經過偵錯之後，終於找出問題所在。最新版的連結器含有一個語言部門忘記移除就交給 Windows 小組的診斷程式碼。這個診斷程式碼將其輸出記錄在某個編譯器小組成員電腦上的一個檔案，而那部電腦剛好在關機狀態 (這讓我想起 Leslie Lamport，他把分散式系統描述成因為一部您根本沒聽過的電腦當掉，就完全不能視事的系統，他也因為說了這段話而聞名遐邇)。
那版連結器已經逍遙的執行了好幾個禮拜。每當有人在建置 Windows 95 的時候連結 VxD，就會更新那部開發人員電腦上的那個檔案。只要那部電腦是在開機狀態，並且連上網路，就不會引起任何注意。但是一旦關機時，所有的動作就會變得像老牛拉車一樣。
問題找出之後，編譯器部門人員馬上就給 Windows 小組一個修補程式，從連結器移除那個診斷程式碼。
不同的人講述這個故事，都有不同的妙語作結。如果是由我講述，我的妙語是：「後來那位編譯器開發人員轉到 Windows 小組，最後變成我的老板」。我經常把這個故事當作一種溫和的揶揄重複講述，樂此不疲。
但如果講述人換成我的老板，他的妙語就很與眾不同了：「其實那個診斷程式碼根本不是我寫的，寫的人是我一位同事，他最後決定不在他的電腦，而是在我的電腦填滿診斷資訊！」

Raymond Chen 的網站「The Old New Thing」以及同名著作均探討 Windows 的歷史和 Win32 程式設計。他的 DNA 佈滿了無作用程式碼。