 TechNet Magazine May 2007

TechNet Magazine May 2007

通訊: 探索 Exchange 2007 行動訊息新功能

行動訊息改變了人們工作的方式，而這項改變也使得行動裝置的安全性益加重要。介紹 Exchange Server 2007 如何改善使用者體驗，並幫助您管理與日俱增的行動工作力。

Yee-Chen Tjie 通訊: 使用 Exchange Server 2007 促進法規遵循

保護企業資產並落實法規遵循的需求對 IT 部門而言是很沈重的負荷。來瞧瞧 Exchange Server 2007 的新功能如何協助您捍衛資料同時落實循規。

Alan Maddison 身分識別管理: 建立單步提供工作流程

正在尋找網路式供應系統嗎？瞧瞧如何使用 Microsoft Identity Lifecycle Manager 2007 中的 MIISWorkflow，打造出自動化單步使用者供應系統。

Aung Oo Windows 系統管理: 透過 Windows PowerShell 簡化群組原則的管理

Windows PowerShell 的目的是要讓您的工作加倍輕鬆。看看如何能直接從 Windows PowerShell 取用針對 Windows Scripting Host 語言所寫的 GPMC API，來大幅簡化您管理群組原則。

Thorbjörn Sjövold Windows 系統管理: 部署終端機服務指南

將組織的應用程式集中執行有說不盡的好處，起頭進行現在更是意想不到的簡單。要在 Windows Server 2003 上啟用終端機服務，並將終端機服務導入整個組織，看這裡就沒錯！

James D. Silliman 編輯的話: 安全性帶著走

Joshua Trupin 回信: 解答

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

Greg Steen SQL 問答集: 最佳作法分析程式、多核心處理器及更多

Edited by Nancy Michell 公用程式焦點: SharePoint 網站與範本的升級工具箱

Luis Câmara Manoel and Peter Skjøtt Larsen IT 產業: 精製商務計劃

Stephen Ibaraki The Cable Guy: Windows 中的 EAPHost

Joseph Davies Windows PowerShell: WMI 連線

Don Jones 嗨，Scripting Guy！: 百花怒放，對話方塊蹦蹦跳，春神來了。

The Microsoft Scripting Guys Exchange 問答集: OWA 逾時、Cmdlet 疑難排解及其他

KC Lemson and Nino Bilic 安全性監控: 網路存取保護

John Morello 桌面檔案: 重新認識 Windows 部署服務

Wes Miller 現場筆記: 保持敏銳

Joshua Hoffman Windows 機密文件: 判斷常用的項目

Raymond Chen


 通訊: 探索 Exchange 2007 行動訊息新功能
通訊 Yee-Chen Tjie

探索 Exchange 2007 行動訊息新功能

摘要:
  • 行動裝置組態
  • 強制原則
  • 進階訊息
  • 行動檔案存取

不過就是幾年前而已，人不在桌上型電腦旁卻想存取公司電子郵件並不常見，而且非常複雜。今天，人們不僅預期能夠從遠端存取電子郵件，就連
在當地的咖啡店裡使用行動訊息裝置的人也比比皆是。行動訊息已改變了人們工作的方式。它讓游牧員工在外出完成工作時變得更有效率。
但也因行動訊息技術近來的進步，使得行動裝置的安全性成了一項憂慮。各公司尋求更佳的辦法保護存在行動裝置上的商務機密資料。
Exchange Server 2003 以及一項稱為 Exchange ActiveSync® 的技術的推出，為 Windows Mobile® 裝置 (Pocket PC 電話或 Smartphone) 提供了使用 HTTPS 安全地連線到 Exchange Server 2003 的能力。然而，行動裝置仍然匱乏管理。隨著 Exchange Server 2003 Service Pack 2 (SP2) 和 Windows Mobile 5.0 上 Messaging and Security Feature Pack (MSFP) 的發行，設定一個通用原則影響所有連線到 Exchange 的 Windows Mobile 裝置也變得可行。這些原則允許強制 PIN 具有指定的長度，閒置逾時後要求輸入 PIN，以及在指定次數嘗試 PIN 失敗後清除裝置等。
Exchange Server 2003 SP2 也新增了使用 Exchange Mobile Admin Tool 進行遠端清除的功能，如 [圖 1] 所示。這項工具提供系統管理員針對遺失的 Windows Mobile 裝置發出清除命令的功能。當裝置下次連線至 Exchange 時，它會執行硬重設，清除裝置記憶體內的全部內容。
[圖 1] 用於清除裝置的 Exchange Mobile Admin Tool
[圖 1] 用於清除裝置的 Exchange Mobile Admin Tool
雖然這是行動裝置的管理和安全性一個好的開始，但是仍有許多安全性需求留待解決。Exchange Server 2007 有助於填補這些懸缺。

裝置的設定和強制
Exchange Server 2007 內預設會為所有的信箱使用者啟用 Exchange ActiveSync。假如您只希望為一小組的使用者啟用此項功能，請先停用針對所有使用者的這項功能。Exchange 管理主控台不會讓您停用使用者群組的 ActiveSync，可是使用 Exchange 管理命令介面的命令，像下面這個命令，很容易就辦得到：
Get-mailbox –server <servername> | Set-CASMailbox –ActiveSyncEnabled $false
這個命令會擷取 Exchange 2007 伺服器上的全部信箱，並將資訊輸送到 Set-CASMailbox 命令來停用所有現有信箱的 ActiveSync。
下一步涵蓋了為您的組織建構 Exchange 信箱 ActiveSync 原則。建構的原則數目將端視使用者各種不同的安全性設定檔而定。比方說，在電子郵件中收到機密財務資訊的財務分析專家可能比一般使用者需要更為嚴格的安全性裝置原則。
若要設定 ActiveSync 原則，請前往 Exchange 管理主控台瀏覽樹，並在 [組織組態] 容器下選取 [用戶端存取]。在 [執行] 窗格，選取 [新增 Exchange ActiveSync 信箱原則]。
在 [新增 Exchange ActiveSync 信箱原則] 對話方塊中，可針對控制是否允許將附件下載至裝置或允許非可預備裝置 (見 [圖 2]) 的設定建立彈性的原則。可預備裝置是能夠套用及強制指定原則的 Windows Mobile 裝置。非可預備裝置則是只能套用原則子集 (或全部不套用) 的裝置。
[圖 2] Exchange Server 2007 ActiveSync 信箱原則
[圖 2] Exchange Server 2007 ActiveSync 信箱原則
其他功能還包括讓您設定加密和密碼復原等設定。如果已開啟 [需要加密裝置] 選項，則該裝置儲存卡上的所有檔案都會加密起來。[啟用密碼復原] 選項可讓使用者透過 Outlook® Web Access 2007 擷取裝置 PIN。
在套用之前，請謹慎考慮裝置的密碼原則。冗長且複雜的 PIN 提供更高的安全性，但也可能使裝置較難使用。在安全性和使用性之間取得良好的平衡，是決定密碼強度和要求輸入 PIN 之前的逾時時間兩者的關鍵。開啟 [密碼到期] 和 [強制密碼歷程記錄] 選項也可以提高安全性，但是如果追蹤密碼和 PIN 變得太複雜的話可能會讓使用者有挫敗感。
Exchange Server 2007 ActiveSync 信箱原則有助於改進裝置安全性，但它的部份功能需要有 Windows Mobile 6.0 才能用，這在我們發表本文時才剛在裝置上推出。[圖 2] 中顯示的功能：[需要加密裝置]、[強制密碼歷程記錄]，以及 [密碼到期 (天數)] 等，全都需要使用新版本。不過，您還是可以利用全新的 Exchange Server 2007 彈性原則，來鎖定使用裝有 Windows Mobile 5.0 的裝置使用者。
原則一旦定義好之後，就可以將它們套用至使用者。在 Exchange 管理主控台中，前往 [收件者組態]，並選取 [信箱]。選擇要為之啟用 ActiveSync 原則的信箱使用者，並從 [執行] 窗格中選取 [屬性]。前往 [信箱功能] 索引標籤，再按兩下 [Exchange ActiveSync]。在 [Exchange ActiveSync 屬性] 方塊中，按一下 [瀏覽] 按鈕，並選取要套用至使用者的 ActiveSync 原則 (見 [圖 3])。您可以重複相同的步驟將不同的原則套用至不同的使用者，或者您可以使用下面的 Exchange 管理命令介面的命令將原則套用至使用者群組：
[圖 3] 套用 ActiveSync 信箱原則
[圖 3] 套用 ActiveSync 信箱原則
Set-CASMailbox –Activesyncmailpolicy
最後一步是訓練您的使用者和支援工程師。告訴您的使用者當他們連線到 Exchange Server 2007 時，他們的裝置上需要設定指定長度的 PIN (見 [圖 4])。讓他們認識套用在他們身上的安全性原則，而不致將這些變更視為日常工作的障礙。
[圖 4] ActiveSync 信箱原則需要 PIN
[圖 4] ActiveSync 信箱原則需要 PIN
您也要讓他們知道 Exchange Server 2007 中的一項新功能 — 使用 Outlook Web Access 2007 的自助遠端清除。如果使用者遺失裝置，他可以透過 Outlook Web Access 中的 [選項] 連結起始裝置的清除作業 — 而不需要連絡支援工程師 (見 [圖 5])。這在一般上班以外的時間遺失裝置時相當實用。
[圖 5] 透過 Outlook Web Access 管理裝置
[圖 5] 透過 Outlook Web Access 管理裝置
最後，向您的支援工程師示範如何遠端清除裝置。這個動作很輕鬆就可以完成，只要開啟 Exchange 管理主控台，瀏覽至 [收件者組態]，並選取 [信箱] 即可。從該處選擇要為之起始清除作業的使用者，並從 [執行] 窗格中選取 [管理行動裝置]。[圖 6] 中顯示 [管理行動裝置] 介面。請注意使用者可能有一台以上的 Windows Mobile 裝置連線到 Exchange 2007，因此在起始清除作業時要小心選取正確的裝置。
[圖 6] 從遠端清除使用者的裝置
[圖 6] 從遠端清除使用者的裝置

電子郵件處理和搜尋
Windows Mobile 6.0 可讓您以 HTML 格式讀取電子郵件，設定郵件答錄機通知 (見 [圖 7])，以及標示電子郵件訊息。在 Windows Mobile 6.0 裝置上標示電子郵件訊息，就跟在 Outlook 中標示電子郵件的處理方式一樣。您不用將電子郵件訊息標示為未讀取以便後續處理，您現在可以標示它們，並使用 Outlook 的進階功能在回到辦公桌後再進行處理。以 HTML 讀取電子郵件提供的優點不僅有益行動裝置使用者，對來回討論電子郵件的其他收件者來說也有好處。當使用 Windows Mobile 6.0 回覆電子郵件時，該電子郵件並不會轉換成基本文字，因此能改善其他同樣身為 Outlook 電子郵件收件者的使用觀感。
[圖 7] 郵件答錄機訊息
[圖 7] 郵件答錄機訊息
Windows Mobile 6.0 的行事曆功能已獲得大幅改進。您現在可以在行事曆項目內轉寄、回覆或全部回覆，也可以查看所有受邀者的接受狀態。
Windows Mobile 6.0 與 Exchange Server 2007 結合使用，提供了兩項與搜尋和 Mobile Document Access 相關的新功能。使用行動裝置的其中一項挑戰就是儲存容量有限。也因為如此，許多使用者只將電子郵件保留在裝置上一到三天的時間。使用者也經常選擇只從收件匣的一個資料夾抓取電子郵件訊息。這種極簡策略在您想要存取較舊的郵件，或是存取放在信箱不同資料夾的郵件時，可能會有問題。
透過 Windows Mobile 6.0，使用者可藉由 Exchange Server 2007 搜尋和檢索引擎，對整個信箱執行線上搜尋。電子郵件搜尋可根據關鍵字在多個資料夾中進行 (見 [圖 8])。接下來便可從搜尋的結果即時擷取電子郵件訊息。
[圖 8] 線上電子郵件搜尋
[圖 8] 線上電子郵件搜尋

Mobile Document Access
隨著一些像是 SharePoint® 等文件協作軟體的增長，以及對允許傳輸的最大電子郵件大小的限制，使得使用者在電子郵件附加的文件變少，取而代之的是傳送更多檔案共用和 SharePoint 網站的連結。除非您可以透過虛擬私人網路 (VPN) 連線到公司網路，否則經由行動裝置存取這些文件可說是不可能的任務。對於游牧工作者來說，這可能是項阻礙。
Windows Mobile 6.0 和 Exchange Server 2007 可讓使用者藉由 UNC 檔案共用和 SharePoint 網站 (可透過唯讀模式來存取) 的方式來存取他們的資料。Exchange Server 2007 可代表 Windows Mobile 裝置代理這些文件的要求 (見 [圖 9])。即使公司網路沒有 VPN 連線，使用者也不會受到限制只能存取附加到電子郵件訊息的文件，他們反而可以存取位在檔案共用或 SharePoint 網站的任何文件。
[圖 9] 經由 UNC 連結存取文件
[圖 9] 經由 UNC 連結存取文件
若要管理 Mobile Document Access，請前往 Exchange 管理主控台，並在瀏覽樹中的 [伺服器組態] 下選取 [用戶端存取]。然後前往 [ActiveSync] 索引標籤，選取 Microsoft-Server-ActiveSync 物件，再按一下 [執行] 窗格中的屬性。在 [遠端檔案伺服器] 索引標籤下，您可設定 SharePoint 網站和檔案伺服器主機名稱的允許清單和封鎖清單。
這個動作完成之後，回到 Exchange ActiveSync 信箱原則，並確定已選取 [Windows® 檔案共用和 Windows SharePoint Services] 的核取方塊 ([圖 10])。
[圖 10] 啟用文件存取
[圖 10] 啟用文件存取
您現在可以為所有 Windows Mobile 裝置使用者提供更方便的文件存取。

結論
在當今到處充斥著遠端工作者的世界中，Windows Mobile 裝置提供了強而有力的方法能隨時隨地存取資訊。行動裝置的安全性和管理已成為 IT 部門關注的一大議題。Exchange Server 2007 與 Windows Mobile 6.0 結合，減輕了為 Windows Mobile 裝置建立原則和鎖定原則目標的工作，這不但有助於舒緩問題，更為遠端工作者的新功能提供了基礎。
Windows Mobile 的資源
有許多資源可供您進一步了解 Exchange Server 2007 部署和 Windows Mobile Messaging。
  • Exchange Server TechCenter
  • 行動存取 Exchange 2007 的基礎
  • 管理 Exchange ActiveSync
  • Windows Mobile 虛擬實驗室
  • Windows Mobile 6 SDK

Yee-Chen Tjie 是 Microsoft 在美國新英格蘭地區的技術專家。他的工作主重行動性和統一通訊解決方案。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 通訊: 使用 Exchange Server 2007 促進法規遵循
通訊 Alan Maddison

使用 Exchange Server 2007 促進法規遵循
摘要:
  • 受管理的資料夾
  • 傳輸規則
  • 郵件分類
  • 日誌記錄

分析師估計，有高達 75 % 的企業文件是透過電子郵件建立及傳達的。無庸置疑的是，在您的組織中，很高比例的智慧財產需仰賴組織的訊息伺服器。因此維護訊息伺服器的系統管理員
肩負著重責大任，因為訊息伺服器存放許多公司的重要資料。不僅如此，有鑑於規範企業資料封存和保留方式的聯邦及地方法規數目不斷增加 (美國與其他國家皆然)，執行這項工作更加繁雜，亦顯重要。
保護企業資產和落實法規遵循的需求是很沈重的負荷。Microsoft 在設計 Exchange Server 2007 時進行了一些改變，同時加入一些新功能以期大幅提昇 Exchange 遵循法規的能力，並讓管理實務更加輕鬆。在本文中，我將著眼於 Exchange Server 2007 中有助於法規遵循的關鍵變革。

了解法規遵循
轉入正題 Exchange Server 2007 之前，我要先討論所要應對的需求。法規遵循需求通常可分為三大領域：資訊保留、存取控制和資料完整性。舉例來說，美國證券交易委員會法案 (SEC Rule 17A-4) 規定了特定證券交易所成員、經紀人和交易商的資料保留政策，並要求金融機構必須能夠擷取、編列索引、封存、搜尋及取出他們的電子郵件。一些知名的法規條文均已納入資料存取控制的規定，其中包括美國健康保險流通與責任法案 (Health Insurance Portability and Accountability Act，HIPAA)、美國金融服務法案 (Gramm-Leach-Bliley Act，GLB Act) 和加州資料隱私法案 (California Senate Bill 1386，SB 1386)。HIPAA 與 GLB Act 控管個人資料的安全性與機密性，而 SB 1386 則規定有關機密資料外洩的公開電腦安全性破壞事宜。
另外，資料完整性需求也納入其他重要的法條，例如美國沙賓法案 (Sarbanes-Oxley，SOX)、愛國者法案 (PATRIOT Act) 及巴賽爾資本協定 (Basel II)。但這些知名法案只是滄海一粟。據估計，全球執行相關法規的數量超過 35,000 條。由此可見，公司的確有必要控管保留資訊、控制資料存取及確保資料完整性等方面的風險。那麼身為系統管理員，您要如何管理此風險，該怎麼做才能符合所有這些法定義務？
第一步是先記錄法規遵循與保留原則。下一步則是實施和持續管理這些原則。透過使用受管理的資料夾、傳輸規則代理程式、郵件分類和日誌代理程式，Exchange Server 2007 可以協助您制訂這些原則。

受管理的資料夾
資料保留 (或記錄管理) 是法規遵循架構中很重要的一環。Exchange Server 2007 在允許系統管理員管理資料方面有長足的進步。Exchange Server 2007 中的資料管理是根據三項原則：移除過時郵件、保留所需郵件，以及使用者需負責分類自己的郵件。
大多數的 Exchange 系統管理員都熟悉套用至信箱的 Exchange Server 2003 信箱管理員原則。Exchange Server 2007 中的受管理的資料夾提供一種集中管理的方式，好讓系統管理員建立及部署新預設值，或是自訂無法移除、重新命名或刪除 (最常見的情況) 的資料夾。利用 SDK 也可以建立網站式的自助應用程式，讓使用者能夠選擇要新增到信箱的資料夾。
如 [圖 1] 所示，Exchange 管理主控台提供精靈式的機制來建立資料夾(這個功能在 Exchange 管理命令介面 New-ManagedFolder cmdlet 中也看得見)。
[圖 1] 使用 Exchange 管理主控台來建立新的資料夾
[圖 1] 使用 Exchange 管理主控台來建立新的資料夾
這將啟動如 [圖 2] 所示的精靈。建立資料夾的程序很簡單易懂；您只要輸入資料夾的名稱和描述，然後按下 [新增] 按鈕即可。當資料夾建立完成時，您會收到確認訊息。
[圖 2] 直覺式精靈可以簡化新建受管理的資料夾的程序
[圖 2] 直覺式精靈可以簡化新建受管理的資料夾的程序
若要妥善實施資料保留原則，您必須為使用者提供簡單的方法來排序及儲存郵件，確保資料的保存方式符合組織的需求。假設您需要為使用者部署三種自訂資料夾，好讓使用者識別保留三年、五年或七年的郵件。建立好受管理的資料夾後，下一步便是套用內容設定到各個資料夾。方法是使用 [受管理的內容設定] 精靈。
訊息系統管理員負責設定內容到期 (以天數為單位) 以及內容實際到期時應採取的動作。可以選擇的動作有五種：
  • 刪除並允許復原
  • 標記為超過保留限制
  • 移到受管理的自訂資料夾
  • 移到刪除的郵件資料夾
  • 永久刪除
進行這些設定時，您必須特別注意三個參數。第一個是郵件到期的值；因為此數值是以天數為單位，因此要將閏年考慮進去。即使只提早一天，企業管理階層 (更別說是法官) 也不會欣賞提早刪除內容的舉動。第二個參數是有效期限的開始時間。除非法務室另有規定，否則這通常是指郵件傳送到信箱的那一天。第三個參數是內容到期時要執行的動作。最佳作法往往是永久刪除該項目。內容設定可讓您透過將郵件傳送到 SMTP 位址的方式來記錄郵件日誌。
受管理的資料夾是根據受管理的資料夾信箱原則套用至信箱。Exchange 管理主控台提供另一個用來建立這些原則的精靈。這些原則可讓您選取及分組多個資料夾。如此一來，您就可以將數個資料夾連結到單一的原則。
通常您會在建立信箱的過程中套用受管理的資料夾信箱原則。不過您也可以使用 Exchange 管理命令介面的 Set-Mailbox cmdlet，將原則套用至現有的信箱。假設您要將名為 retention 的受管理的資料夾信箱原則套用到別名為 USER1 的電子郵件帳號。要這麼做，您會使用下列命令：
Set-Mailbox –Identity USER1
–ManagedFolderMailboxPolicy “retention”
受管理的資料夾和對應的內容設定將提供功能強大的機制來管理資料保留與法規遵循程序。它不僅能讓使用者排序相關的電子郵件和以集中管理的資料夾儲存資料，還能夠記錄這些項目的日誌，以便確保在出現探索要求或保留命令時，您可以輕鬆的遵循法院命令。

傳輸規則
Exchange Server 2007 中有兩個傳輸規則代理程式。不過就遵循法規而言，您其實只會對在 Hub Transport Server 上執行的代理程式感興趣。這個代理程式可協助您將原則式的法規遵循規則，套用到在 Exchange 組織中流通的郵件(另一方面，Edge Transport Server 規則代理程式則是協助您保護組織抵抗垃圾郵件與病毒的侵擾)。
系統管理員負責執行的某些常見循規需求包括：
  • 限制不同群組的寄件者與收件者之間的互動
  • 防止不適當的內容進入或離開公司
  • 過濾機密資訊
  • 追蹤或封存傳送到特定使用者及群組或從對方接收的郵件
  • 寄送之前先重新導向輸入和輸出郵件以進行檢查
  • 套用免責聲明
此代理程式之所以選擇 Hub Transport Server，是基於它在 Exchange 2007 拓樸中扮演的角色。Exchange 2007 中的拓樸有大規模的變動，因此 Exchange 現在更能與 Active Directory® 拓樸緊密整合。當郵件在組織內部流通時，會在某個時間點經由 Hub Transport Server 加以處理。這個 Hub Transport Server 將查詢 Active Directory 以取得現行的傳輸規則設定，然後將這些規則套用到它所處理的所有郵件。
透過 Active Directory 服務，在 Hub Transport Server 上設定的傳輸規則都會複製到所有其他 Hub Transport Server。您必須了解您的網站和拓樸對此複製行為的影響，然後據此判斷您能多快部署全組織規則。
您也必須記住，Hub Transport Server 會保留收件者快取以用於收件者和通訊群組清單查詢。重新整理間隔的預設值是四小時，這個設定將影響規則套用到郵件的時間。
Hub Transport Server 上的傳輸規則會評估所有會議要求、一般郵件、加密郵件以及在驗證使用者之間傳送的受權限保護的郵件。所以以匿名方式傳送的電子郵件訊息也會經過評估，無論其訊息類型、寄件者和收件者為何。
每個傳輸規則都包含下列元件：條件、例外及動作。條件是用來指定訊息識別程序中要使用哪些訊息屬性，例如標題、收件者或寄件者。當某個訊息符合特定規則的所有條件時，除非該訊息也符合已設定的例外，否則就會對該訊息套用動作。例外屬於選擇性項目。一旦設定，例外將會防止傳輸規則處理符合例外準則的訊息。每個傳輸規則都需要設定動作，以便指定處理訊息的方式。[圖 3] 列出可用的動作，這些動作的套用是根據 Hub Transport Server 上設定的傳輸規則來決定。
Figure 3 Hub Server 上可用於傳輸規則的動作 (Close Figure 3)

動作 | 動作名稱 | 描述
使用郵件記錄事件 | LogEvent | 將事件新增到本機電腦的應用程式記錄檔。
主旨前面加上字串 | PrependSubject | 在郵件主旨欄位的開頭加上字串。
套用郵件分類 | ApplyClassification | 對郵件套用郵件分類。
套用免責聲明文字 | ApplyDisclaimer | 在郵件中套用免責聲明。
將垃圾郵件信賴等級設定為數值 | SetScl | 設定郵件的垃圾郵件信賴等級 (SCL)。
設定包含值的標題 | SetHeader | 建立新的郵件標題欄位或修改現有的郵件標題欄位。
移除標題 | RemoveHeader | 從郵件移除指定的郵件標題欄位。
在 [收件者] 欄位地址中新增收件者 | AddToRecipient | 新增一或多位收件者到郵件的 [收件者] 通訊清單。原始收件者可以看到其他地址。
複製郵件到其他地址 | CopyTo | 新增一或多位收件者到郵件的 [副本] (Cc) 欄位。原始收件者可以看到原始地址。
傳送郵件的密件副本至其他地址 | BlindCopyTo | 新增一或多位郵件收件者到電子郵件訊息的 [密件副本] (Bcc) 通訊清單。
重新導向郵件到其他地址 | RedirectMessage | 重新導向郵件到系統管理員指定的一或多位收件者。郵件不會傳遞到原始的收件者，收件者或寄件者也不會收到通知。
傳送包含增強型狀態碼的退回郵件給寄件者 | RejectMessage | 刪除郵件並傳送未送達回條給寄件者。收件者不會收到郵件或通知。
無訊息地刪除郵件 | DeleteMessage | 刪除郵件。不會傳送通知給收件者或寄件者。
若要建立傳輸規則，您可以使用 Exchange 管理主控台和規則傳輸精靈，如 [圖 4] 所示。或者，您也可以使用 Exchange 管理命令介面來編寫建立規則的指令碼。
[圖 4] 啟動規則傳輸精靈以便在 Hub Transport Server 上設定傳輸規則
[圖 4] 啟動規則傳輸精靈以便在 Hub Transport Server 上設定傳輸規則
請注意，您也可以使用 SDK 來撰寫自訂傳輸代理程式，這些代理程式會在 Exchange 內部根據 SMTP 事件來處理訊息。不過心臟不強者切勿輕易嘗試。

郵件分類
新的郵件分類工具使用中繼資料來描述特定郵件的指定用途或對象。在用戶端，可以透過 Outlook® Web Access (OWA) 或 Outlook 2007 使用此中繼資料來顯示使用者可讀的分類說明。至於在伺服器端，傳輸規則代理程式可以根據郵件分類來處理郵件。
Exchange Server 2007 的預設郵件分類包括具有 A/C (法定代理人/用戶端) 權限、附件已移除、公司機密以及公司內部。不過，很多組織可能都希望建立自己的分類。您可以使用 Exchange 管理命令介面中的 new-MessageClassification cmdlet 來建立新的分類。例如，若您需要限制財務資料的存取，您可以建立稱為 Financial—Confidential 的郵件分類：
new-MessageClassification –Name finance –DisplayName “Financial—Confidential”
-RecipientDescription “This message contains confidential financial data.”
–SenderDescription “Restricts recipients of messages that contain confidential financial data”
請注意，雖然只有三個必要參數 (Name、DisplayName 和 SenderDescription)，但您應該至少再加入 RecipientDescription 以滿足基本的機能。[圖 5] 顯示此新增分類現已列示在 OWA 介面當中。
[圖 5] 郵件分類清單包括新建的 Financial—Confidential
[圖 5] 郵件分類清單包括新建的 Financial—Confidential
此命令並不使用地區參數，因此會套用至 Exchange 組織內的所有地區。如果您支援全域作業，那麼您可能要建立包含地區特性的自訂訊息分類。
此外，請記得要正確設定分類的權限。根據預設，所有建立的新郵件分類都設有指定給驗證使用者的讀取權限。不過，您應該要區隔郵件分類，好讓郵件分類只提供給適當角色的使用者存取。另外還需注意，每個分類都包含與其他郵件分類相關的優先順序。這個優先順序會指定描述的排序，並決定哪些分類會與轉寄或回覆的郵件建立關聯性。
當您建立必要的分類後，下一步便是建立使用分類傳輸規則(當然，這些郵件分類不見得要與動作相關，也可以純粹當做資訊參考之用)。如 [圖 6] 所示，在結合郵件分類與傳輸規則時有許多選項供您選用。我建立了一條傳輸規則，它會監視分類為 Financial 的郵件。遇到這樣標示的郵件，傳輸規則代理程式便會檢查收件者。如果其中有任何收件者不屬於財務部通訊群組的成員，此郵件就會被退回給寄件者並包含自訂的未傳遞訊息。
[圖 6] 針對分類為 Financial 的郵件建立傳輸規則
[圖 6] 針對分類為 Financial 的郵件建立傳輸規則
郵件分類也可以用來在組織中強制執行「道德管束」。例如，有時候必須限制特定人員與部門之間的通訊。此時就可以使用郵件分類來達到目的。

日誌代理程式
在落實法律遵循這方面，日誌記錄是一項功能強大但困難度也高的武器。幸好，Exchange Server 2007 提供了更能靈活運用的日誌功能。Exchange Server 2007 現在可同時支援標準日誌 (在信箱資料庫層級) 和新的超值 (premium) 日誌 (按收件者)，後者可以啟用個別使用者與通訊群組的日誌功能。如此可大幅簡化遵循法規要求 (例如預留或法院發出的保留命令) 的作業程序。此外，您還可以加強控制日誌對儲存及效能的影響。
例如，其中一項最有彈性的新選項便是支援以動態通訊群組為基礎的日誌。假設您的組織一直需要預留某人的電子郵件訊息。也許原因是為了進行內部 HR 調查或法庭案件。藉由動態通訊群組，系統管理員可以將使用者新增到已經使用日誌記錄的現成群組，或從中移除使用者。這樣就能快速方便地準備特別的日誌記錄。
利用 Exchange 管理主控台和動態通訊群組精靈，您可以選擇使用者容器，以及根據特定 Active Directory 屬性值來篩選包含的信箱 (如 [圖 7] 所示)。選取其中一個自訂屬性 (如 [圖 7] 所示) 可讓系統管理員藉由新增或移除這個值來控制要加入日誌記錄的使用者。
[圖 7] 使用動態通訊群組精靈來設定日誌規則
[圖 7] 使用動態通訊群組精靈來設定日誌規則
如需 Exchange 2007 中日誌功能的深入剖析，請參閱 2006 年 12 月由 David Strome 撰寫的文章＜Exchange 2007 更強大的日誌功能＞。您可以在＜日誌概觀＞中找到其他關資訊。

Alan Maddison 服務於 MTI Technology Corporation，擔任 Microsoft 技術實踐的資深顧問。其專長在於 Active Directory、Exchange Server 和模擬技術。


 身分識別管理: 建立單步提供工作流程
身分識別管理 Aung Oo

建立單步提供工作流程
摘要:
  • 使用 MIISWorkflow
  • 實作與設定
  • 擴展 MIISWorkflow

如果您正在尋找可要求與核准帳戶的網路式介面，而且您的組織是採用 Microsoft Identity Lifecycle Manager 2007 (ILM 2007，前身為 Microsoft Identity Integration Server 2003)，
那麼 MIISWorkflow 應用程式將可提供簡單有效的解決方案。MIISWorkflow 是 MIIS 2003 Resource Tool Kit 2.0 的一部份，於 2004 年 12 月問世。雖然不算是適用於各種環境的全方位解決方案，但是您可以使用 MIISWorkflow 來著手建置符合組織需求的自訂應用程式。
透過整合 Web 應用程式，MIISWorkflow 為 ILM 2007 提供以核准為基礎的提供功能。這是一個工作流程導向的單步供應系統，它會接受來自使用者的要求，然後將要求路由傳送至核准者 (通常是主管) 並提供回應特定要求的決定所需的充分授權。根據核准者的決定，ILM 繼續使用 ILM 中定義的商務規則來處理已連線目錄內的使用者帳戶提供。
這個應用程式只能輔助一個單步工作流程；它無法建立複雜的工作流程功能，例如包含平行路徑的多重步驟的核准程序，或是使用圖形化介面的工作流程作業。如果您的組織不需要這些複雜的工作流程功能，那麼您就可以使用 MIIS Resource Tool Kit 提供的 MIISWorkflow 範例來實作解決方案。
在此我將著重探討某個虛構公司的人事部。一般而言，HR 系統是組織內部所有員工資訊的授權來源。不過，雖然這些系統通常握有正職員工的詳細資料，但是往往缺少臨時員工 (像是約聘人員及實習生) 的相關資訊。HR 系統中包含的資料可能無法追蹤使用者可以存取哪些系統 (包括使用者資訊)。我將示範如何針對組織內部的臨時員工建置簡單的追蹤系統。

以 MIISWorkflow 為基礎建置
組織該如何利用 MIISWorkflow 的功能？舉例來說，組織可以建立與現有的 HR 系統相互合作的應用程式。當雇用新員工時，員工的使用者資訊會新增到 HR 系統中。您可以將 ILM 流程設計為先傳送資訊到 MIISWorkflow 資料庫，接著利用工作流程應用程式將使用者資訊路由傳送至核准者，然後再讓 ILM 在已連線目錄中提供帳戶。
如果您的組織不使用 HR 系統來追蹤臨時員工，可以使用 MIISWorkflow 應用程式做為授權資料來源以管理企業目錄中的帳戶。由於工作流程應用程式可減少取得核准的書面行政作業，因此使用者不需要等待數天的時間才能存取目錄和應用程式中的帳戶。您也可以使用 MIISWorkflow 讓撤銷存取權立即生效，藉此加強組織安全性。
MIISWorkflow 也可以用作為稽核工具，它可以追蹤使用者能夠存取的系統數目、每個帳戶的要求和終止日期，以及每個帳戶的要求者與核准者。產生帳戶歷程記錄明細的功能讓組織更容易遵循沙賓法案 (Sarbanes-Oxley) 與 HIPAA 等法規。
MIISWorkflow 應用程式是在 IIS 上執行並使用 ILM 2007 的目錄整合與提供功能，來提供及取消提供已連線目錄中的帳戶。工作流程應用程式的元件包括 ASP.NET 網頁、SQL Server™ 資料庫、管理代理程式以及授權原則存放區的集合 (見 [圖 1])。此應用程式使用 SQL Server 做為資料存放區，利用 Active Directory® 進行驗證，並使用包含 Windows® 授權管理員 (一般稱為 AzMan) 的原則存放區進行授權。
[圖 1] MIISWorkflow 應用程式架構
[圖 1] MIISWorkflow 應用程式架構
利用 C# 和 ASP.NET 可以延伸和自訂此應用程式。MIISWorkflow 包含下列五個 .aspx 頁面：ContractorApproval、ContractorHistory、ContractorRequest、ContractorStatus 和 ContractorUpdate。這些頁面可讓系統管理員要求、更新、核准及追蹤系統中各個使用者帳戶的狀態。請注意，MIISWorkflow 應用程式預設是藉由 IIS 整合式 Windows 驗證來使用 Kerberos。
工作流程應用程式會根據核准者的動作來觸發 ILM，而 ILM 接著會使用定義的規則來提供或取消提供已連線目錄中的使用者帳戶。對要求採取動作之後，應用程式便會立即觸發 ILM，而要求不需要等到下一次 ILM 同步處理循環，便能在已連線目錄中提供或取消提供使用者帳戶。
工作流程應用程式需要 MIISWorkflow 資料庫來儲存使用者的帳戶資訊。這個資料庫與 ILM 儲存 Metaverse 資訊的資料庫不同，但也是在相同的 SQL Server 執行個體上設定。當授權使用者透過工作流程應用程式提出帳戶的要求時，MIISWorkflow 會儲存這項資訊。接著經由 ASP.NET 網頁呈現此資訊，此時核准者會存取這個網頁。MIISWorkflow 也會在資料庫中儲存動作的歷程記錄以及其他帳戶相關資訊。ILM 利用應用程式隨附的 SQL Server 管理代理程式，從 MIISWorkflow 資料庫匯入這些資訊，然後視需要提供或取消提供帳戶。
AzMan (MIISWorkflow 用來進行授權) 提供以角色為基礎的存取控制 (RBAC)，以便管理根據使用者被指定的角色來允許使用者在應用程式中執行的工作(請參閱 go.microsoft.com/fwlink/?LinkId=85825 以取得 RBAC 的詳細資訊)。當使用者在 Active Directory 中經過驗證，進而獲得存取許可時，工作流程應用程式會檢查在 AzMan 授權存放區中定義的角色，以便授權可讓使用者執行的作業。此應用程式有兩個預先定義的角色：約聘人員要求者和約聘人員核准者。屬於約聘人員要求者角色的使用者或群組只能透過應用程式提出要求，但屬於約聘人員核准者角色的使用者或群組則能夠建立要求以及核准或拒絕要求。
MIISWorkflow 應用程式授權原則儲存在 XML 檔案中。無論是 Windows 使用者與群組或應用程式群組都可以被指派至定義的角色。應用程式群組允許 LDAP 查詢根據屬性值對使用者的 Active Directory 或 Active Directory 應用程式模式 (ADAM) 帳戶物件執行執行階段查詢；舉例來說，使用者屬於 (department=‘marketing’) 這樣的群組，便會傳回 True。

應用程式逐步解說
應用程式系統管理員使用 AzMan 來控制應用程式的存取。根據您的組織使用應用程式的方式而定，您可以將約聘人員要求者角色授與所有網域使用者或只授與選定群組。而約聘人員核准者角色則只應該授與有權核准或拒絕要求的使用者及群組。這個角色通常是由特別指定的 HR 主管以及系統和群組系統管理員擔任。根據預設，MIISWorkflow 應用程式使用 IIS 整合式 Windows 驗證做為其驗證方法，因此此應用程式會透過使用者的 Windows 桌面登入認證來驗證使用者 — 這表示使用者不會再次收到認證的提示向應用程式進行驗證。
約聘人員要求者角色的使用者可以將瀏覽器指向應用程式中的約聘人員要求網頁，然後提供有關約聘人員的資訊以要求建立該約聘人員的帳戶。[圖 2] 顯示約聘人員要求網頁。
[圖 2] 新約聘人員要求網頁
[圖 2] 新約聘人員要求網頁
要求者角色的人員填入適當的約聘人員資訊，然後提交要求。此處有一個核准要求的連結和一個檢查頁面狀態的連結，但是要求者無法存取核准者頁面，除非他也屬於約聘人員核准者角色。要求者可以按一下 [約聘人員狀態 (Contractor Status)] 連結來檢視自己的要求，但是無法檢視其他人提交的要求狀態。
只有約聘人員核准者才能存取約聘人員核准網頁，在此他可以審查相關資訊，然後核准或拒絕要求。[圖 3] 顯示約聘人員核准網頁的介面。
[圖 3] 約聘人員核准網頁
[圖 3] 約聘人員核准網頁
約聘人員核准者可以檢視所有要求者提交的要求。任何一位約聘人員核准者都可以核准要求，而且只需要一個核准或拒絕動作便會將要求路由傳送至下一階段。一旦核准者採取動作之後，要求便會從約聘人員核准網頁中消失。這樣可以避免核准者執行多餘的作業。
為了檢視新要求以及根據組織需求來處理擱置中的要求，核准者必須定期存取約聘人員核准網頁，因為此應用程式並沒有通知機制來告知核准者是否有新的要求或待處理項目。當核准者從網頁核准或拒絕要求之後，應用程式隨即會觸發 ILM，接著便會根據核准者的動作在已連線目錄中供應或取消供應帳戶。
[圖 4] 約聘人員狀態網頁
[圖 4] 約聘人員狀態網頁
您可以從約聘人員狀態網頁追蹤擱置中要求的狀態與已完成要求的記錄 (見 [圖 4])。要求者可以從這個網頁執行數個動作。您可以檢視自己的要求，包括員工識別碼、名字、姓氏、部門、狀態以及上次修改日期等資訊。您也可以編輯現有的資訊，檢視歷程記錄，以及終止約聘人員的帳戶。您可以修改名字及姓氏和部門資訊，然後重新提交資訊以等待核准。最後，您可以從約聘人員歷程記錄網頁檢視針對要求採取的動作記錄，其中還包含每個動作的日期與時間 (見 [圖 5])。
[圖 5] 約聘人員歷程記錄網頁
[圖 5] 約聘人員歷程記錄網頁
MIISWorkflow 應用程式可讓要求者從約聘人員狀態網頁終止約聘人員帳戶，這樣會讓執行帳戶終止的作業更順暢。要求者只要按一下終止連結，即可立即停用或刪除已連線目錄中的約聘人員帳戶。從工作流程應用程式終止約聘人員帳戶這項功能的好處是，系統管理員不需要在每個目錄中搜尋約聘人員帳戶，並手動刪除帳戶。既然 MIISWorkflow 應用程式會立即觸發 ILM 並在已連線目錄中取消供應這些帳戶，就不會延遲刪除這些帳戶。

設定應用程式
MIISWorkflow 應用程式的設定牽涉到設定服務帳戶、設定應用程式的資料庫、設定 ILM 與工作流程應用程式一同運作、設定 IIS，以及設定原則存放區。此應用程式包含預先建置的指令碼和設定檔案，藉此簡化作業流程。
MIISWorkflow 應用程式隨附 T-SQL 查詢檔案，讓建立 MIISWorkflow 資料庫的過程變得更簡單。您可以在查詢解析程式中載入此查詢檔案，然後執行查詢以便自動建立資料庫。
IIS 的設定牽涉到建立新的 IIS 應用程式集區和虛擬目錄，接著設定驗證和存取控制以裝載 ASP.NET 網頁。應用程式也包含具有預先定義角色的 XML 檔案，可用來設定授權原則存放區。您可以將使用者及群組指派為現有的角色，並使用 AzMan MMC 來建立新角色。
最後一個步驟是在 ILM 中設定管理代理程式，以便從 MIISWorkflow 資料庫匯入資料到 ILM。方法是匯入 XML 檔案中的管理代理程式設定，然後複製 SQL Server 管理代理程式的預先建置延伸檔案。應用程式會提供此 XML 檔案與管理代理程式延伸檔案。有一個讀我檔案會逐步指示如何設定上述各個步驟。

擴展應用程式
MIISWorkflow 應用程式為開發與 MIIS 整合的簡單工作流程提供一個起點，而您可能需要透過一些自訂動作來擴展這個應用程式。除了變更網頁這類簡單的修改動作，還有其他很多方式可以擴展此應用程式。
您可以新增通知功能，好讓核准者收到擱置中要求的電子郵件訊息。如果在指定天數內沒有對要求採取任何動作，這項功能還可以傳送提醒訊息給核准者。如果您需要預設網頁以外更多的使用者相關資訊，您可以同時在約聘人員要求網頁和約聘人員更新網頁中新增欄位。您可以新增更多角色到應用程式，例如稽核者角色，這個角色讓使用者不僅能夠檢視自己提交的要求，也能檢視每個要求的歷程記錄。
至於更複雜的工作流程功能，例如多重步驟的工作流程以及使用圖形設計工具來設計工作流程的能力，則超出此應用程式的範圍。不過，您可以使用 Windows Workflow Foundation 來開發更健全且能應付複雜的工作流程功能的應用程式。
您可以在以下網址找到 MIIS Resource Tool Kit：go.microsoft.com/fwlink/?LinkId=85829。立即下載，您就可以開始建置自己的身分識別工作流程解決方案。

Aung Oo 是微軟顧問服務 (Microsoft Consulting Services，MCS) 的身分識別管理主題專家。早在第一版的 Microsoft Identity Management 推出以來，Aung 便開始為商界和政府客戶設計、開發和部署企業目錄與身分識別管理解決方案。


 Windows 系統管理: 透過 Windows PowerShell 簡化群組原則的管理
Windows 系統管理 Thorbjörn Sjövold

透過 Windows PowerShell 簡化群組原則的管理
摘要:
  • 什麼是 Windows PowerShell？
  • GPO 過去是怎麼管理的
  • 將指令碼遷移到 Windows PowerShell

Microsoft 群組原則技術並不是花個晚上就能弄懂，它稍微複雜，而且它必須採用 Active Directory，這項奇怪的新服務看起來跟當時標準的帳戶/資源網域完全是兩個樣。當今的群組原則
幾乎是各家擁有 Windows® 基礎結構的公司的管理骨幹。我可以預見 Microsoft 推出的這項最新管理技術 Windows PowerShell™ 也會有一樣的成就。事實上，Windows PowerShell 很有可能讓身為群組原則管理員的您的工作更加倍輕鬆。
在本文中，我將說明如何直接從 Windows PowerShell 取用針對 Windows Scripting Host 語言，如 VBScript (以及一般以 COM 為主的指令碼語言)，所撰寫的 Microsoft® 群組原則管理主控台 (GPMC) API，來簡化在您的環境中管理群組原則的方式。

編寫群組原則工作的指令碼
幾年前，當 Microsoft 發行 GPMC 時，群組原則管理員們手邊突然多了一堆有用的功能。尤其是以群組原則為主的 MMC 嵌入式管理單元，特別在與 Active Directory® 使用者和電腦相較之下，更是讓群組原則管理向前邁出了一大步。再者，還有嶄新的 API 讓系統管理員能使用以 COM 為主的語言 (如 VBScript) 來執行群組原則的管理工作，例如備份和還原群組原則物件 (GPO)，在網域間遷移 GPO，設定 GPO 上的安全性設定以及連結和報告等。
可惜的是，GPMC 並沒有提供在群組原則物件內編輯實際設定內容的功能。也就是說，可以在 GPO 容器上執行諸如讀取 GPO 版本、讀取修改日期、建立全新的 GPO、從不同的網域備份和還原/匯入 GPO 等作業，但是無法撰寫程式來新增或變更 GPO 的內容，例如新增重新導向的資料夾，或是新增軟體安裝等。大致上您是建立 GPO，並使用群組原則物件編輯器來手動設定所有設定，然後加以備份，並將之匯入到測試環境中。當一切經過確認都運作正常後，您就可以將它匯入實際環境內。儘管少了該功能，使用指令碼而不手動與 GPMC API 互動，仍為日常群組原則的管理工作省下了大量的時間、精力，並減少了出錯的情況。

下一級
Windows PowerShell 與像是 VBScript 的指令碼語言有何不同？對於新手來說，Windows PowerShell 是一種命令介面，至少就我們的目的而言是如此，您可以把它想成是命令列解譯器。雖然 VBScript 也可以從命令列執行，但是 VBScript 檔案並不能一行一行的執行。相反地，Windows PowerShell 可以馬上建立成一連串個別的命令。此外，Windows PowerShell 還有函數，運作的方式跟 VBScript 中的副程式很像，此函數可在 Windows PowerShell 命令提示即時建立。
更棒的是 Windows PowerShell 是以 Microsoft .NET Framework 為基礎建置而成，而 VBScript 則是仰賴舊式的 COM 技術。這表示現今所產生的大量 .NET 程式碼都可以直接從 Windows PowerShell 內部加以運用。
也就是說，透過 Windows PowerShell，您可一次同時獲得完整的指令碼支援和互動模式。我在此處提供的範例全都是命令列輸入，因此您可以照著打，不過如果您把它們放到 Windows PowerShell 指令碼檔案中來執行也照樣可行。

使用 Windows PowerShell 重建舊指令碼
一開始使用新技術就拋棄之前所有的心血是最下下策。從 GPMC API 存取 COM 物件有三種方法可以用，或基本上乾脆重複利用任何舊有的 VBScript。您可選擇下列三個當中一個選項：
  • 使用程式設計語言，如 C# 或 Manged C++，來建立 Windows PowerShell cmdlet。
  • 使用 Windows PowerShell 存取 MSScript.ocx 中的 ScriptControl 來包裝舊指令碼。
  • 將 COM 呼叫包裝在可重複使用的 Windows PowerShell 函數中，或直接呼叫 COM 物件。
我將把重點放在第三個選項，但先讓我們快速瀏覽一下所有選項。

建立 Windows PowerShell Cmdlet
Microsoft 在 Windows PowerShell 中包含了大量 cmdlet，可讓您複製檔案，格式化輸出，擷取日期和時間等等，不過您也可以建立自己的 cmdlet。整個過程在 msdn2.microsoft.com/ms714598.aspx 中有完整的示範。步驟總結如下：
  • 以 .NET 程式設計語言 (如 C#) 建立類別庫 DLL。
  • 建立新類別，並繼承自基底類別 cmdlet。
  • 設定決定名稱、用途、輸入參數等的屬性，並加入您的程式碼。
因為 Windows PowerShell 是建置在 .NET Framework 上，所以以參數傳回或傳遞的型別，諸如字串、物件等，在程式碼中與在 Windows PowerShell 中是一模一樣，不需要特殊的型別轉換。
此一解決方案的真正威力在於，您有完整的程式設計語言可任您擺佈。

使用 MSScript.ocx 中的 ScriptControl 物件包裝舊指令碼
很顯然地，您需要 VBScript 引擎來執行 VBScript 檔案。比較不明顯的是，此引擎是 COM 物件，而既然您可以從 Windows PowerShell 使用 COM 物件，也就可以叫用 VBScript 引擎。整個程式碼看起來如下：
$scriptControl = New-Object -ComObject ScriptControl
$scriptControl.Language = ‘VBScript’
$scriptControl.AddCode(
    ‘Function ShowMessage(messageToDisplay)
    MsgBox messageToDisplay
    End Function’)
$scriptControl.ExecuteStatement(‘ShowMessage
    “Hello World”’)
假如您在 Windows PowerShell 命令列介面 (CLI) 中輸入這段程式碼，便會呼叫 VBScript 函數 ShowMessage 並以參數執行，結果是顯示內含 Hello World 文字的訊息方塊。
你們當中有些人可能會想「太棒了！從 Windows PowerShell 使用 COM 我已經很熟，不用繼續讀下去，可以開始使用舊 GPMC 指令碼的集合來填滿 ScriptControl 物件。」不好意思，事情沒這麼簡單。隨著指令碼越來越大，這套方法很快就會變得非常複雜且難以偵錯。

包裝 COM 物件
因此最佳的選項是第三個選項：將 COM 呼叫包裝在可重複使用的 Windows PowerShell 函數中，這可讓您取用 GPMC API 中的 COM 物件。下行說明如何直接在 Windows PowerShell 中建立 .NET 物件。在本例中，可用來取得檔案大小的是 FileInfo 物件：
$netObject = New-Object System.IO.FileInfo(
“C:\boot.ini”) # Create an instance of FileInfo
               # representing c:\boot.ini
請注意 # 在 Windows PowerShell 中是用於內嵌註解。使用這個新具現化的 FileInfo 物件，只要鍵入下列程式碼，即可輕鬆取得 boot.ini 的大小：
$netObject.Length # Display the size in bytes of the
                  # file in the command line interface
等等，我們不是應該談談 COM 物件和 VBScript 轉換嗎？沒錯，但先看看下面的命令：
$comFileSystemObject = New-Object –ComObject Scripting.FileSystemObject
您會注意到語法基本上跟我之前從 .NET Framework 用來建立原生物件的一樣，只有兩點不同。第一點是我新增了 –ComObject 參數，將 Windows PowerShell 指向 COM 架構，而不是 .NET 架構。第二點，我使用的是 COM ProgID，而不是 .NET 建構函式，在本例中，即 Scripting.FileSystemObject。ProgID 的名稱就跟您過去一直使用的一樣。對等的 VBScript 程式碼是：
Set comFileSystemObject = CreateObject(
    “Scripting.FileSystemObject”)
若要使用 VBScript 取得檔案大小，將上列一行與下列程式碼一併加入檔案中：
Set comFileObject = comFileSystemObject.GetFile(
    “C:\Boot.ini”)
WScript.Echo comFileObject.Size
然後使用 Cscript.exe (舉例來說) 來執行它。在 Windows PowerShell 中，您的作法應該如下 (如果您想的話，可直接從 Windows PowerShell 命令列進行)：
$comFileObject = $comFileSystemObject.GetFile(
    “C:\boot.ini”)
$comFileObject.Size
當然啦，要轉換一段可讀取檔案大小的 VBScript，我可以使用 Windows PowerShell cmdlet 來管理磁碟中的物件，但是我想要向您示範從 Windows PowerShell 存取 COM 有多麼簡單。不過要注意的是，我告訴 Windows PowerShell 建立一個 COM 物件，在此處實際建立的物件 $comFileSystemObject，是一個包裝 COM 物件並公開其介面的 .NET 物件。然而這不在本文的討論範圍內，所以無關緊要。

Windows PowerShell 實際示範
看過了如何從 Windows PowerShell 存取 COM 之後，讓我們把焦點轉到群組原則上。此處的範例將顯示較短的程式碼片段，讓您大致了解如何從 Windows PowerShell 使用 GPMC API，不過您可以在與本文相關的程式碼下載中找到一組完整的 Windows PwoerShell 函數來管理群組原則，網址是 technetmagazine.com/code07.aspx。[圖 1] 列出下載中內含的函數。
Figure 1 下載中的自訂函數 (Close Figure 1)

函數名稱 | 描述
BackupAllGpos | 備份網域中所有的 GPO
BackupGpo | 備份單一 GPO
RestoreAllGpos | 從備份將所有 GPO 還原至網域
RestoreGpo | 從備份還原單一 GPO
GetAllBackedUpGpos | 從指定路徑擷取最新版本的 GPO 備份
CopyGpo | 將一個 GPO 中的設定複製到另一個 GPO
CreateGpo | 新建一個空白 GPO
DeleteGpo | 刪除 GPO
FindDisabledGpos | 傳回所有已同時停用使用者和電腦雙方的 GPO
FindUnlinkedGpos | 傳回所有不含連結的 GPO
CreateReportForGpo | 為網域內單一 GPO 建立 XML 報告
CreateReportForAllGpos | 為網域內每個 GPO 建立個別的 XML 報告
GetGpoByNameOrID | 依顯示名稱或 GPO ID 尋找 GPO
GetBackupByNameOrId | 依顯示名稱或 GPO ID 尋找 GPO 備份
GetAllGposInDomain | 傳回網域中所有的 GPO
在閱讀本節的同時，您可隨時啟動 Windows PowerShell 命令列鍵入命令。不過要記住，有些命令需依存於前一個命令。換句話說，有些最初建立的物件會在稍後派上用場，所以請留在相同的 Windows PowerShell 工作階段中。如果您關閉工作階段，就必須重新開始，重新鍵入所有的命令。
那就讓我們使用 Windows PowerShell 新建一個 GPO。Microsoft 的群組原則小組在 GPMC 內附上許多可讓您完整運用的 VBScript 範例，以提高效率。它們位於 %ProgramFiles%\GPMC\Scripts 目錄中，在此目錄中您也可以找到一個稱為 gpmc.chm 的檔案，內含 GPMC API 說明文件。讓我們來看看 CreateGPO.wsf 指令碼，並詳細分析看它是如何運作的。
您會在靠近頂端的地方看到此行：
Dim GPM
Set GPM = CreateObject(“GPMgmt.GPM”)
這基本上是所有群組原則管理工作階段或指令碼的起點，因為它會具現化 GPMgmt.GPM 類別，允許存取大多數的 GPMC 功能。讓我們直接改從 Windows PowerShell 進行這個動作：
$gpm = New-Object -ComObject GPMgmt.GPM
完成群組原則管理的起點後，下一步是決定要怎麼運用它。通常您是查詢說明文件來尋找這類的資訊，但是 Windows PowerShell 有個真的很酷的功能。如果您鍵入下行，會獲得如 [圖 2] 中所示的輸出：
[圖 2] Get-Member 輸出
[圖 2] Get-Member 輸出
$gpm | gm
如果您問我，我個人是覺得蠻酷的啦。注意一下 Get-Member (或 gm) cmdlet 如何讓您直接從命令列查看物件支援的屬性和方法。當然是跟閱讀說明文件不一樣啦，不過在您忘了確切的參數數目、確切的名稱等等時候，倒是能方便您使用已經熟悉的物件。有個需要注意重點的是，當您查詢 GPMC 說明文件節點清單時，看起來像是 GPM 物件和所有其他類別都是以 I 字母開頭，這是因為 COM 內部運作方式之故，跟我們此處無關；這主要是為了撰寫原生 COM 程式碼的 C++ 程式設計師而設計，表明介面與實作該介面的類別之間的差異。還有在使用 GPMC API 時也要注意，您需要的物件只有一個是依這種方式建立，亦即 GPMgmt.GPM，而所有其他物件都是使用以此 GPM 物件為開頭的方法建立的。
現在讓我們繼續建立新 GPO 的作業。
[圖 3] 圖解建立 GPO 有多麼簡單。請注意，我省略了一些程式碼，包括錯誤處理 (例如，如果您不能建立 GPO 的話會發生什麼事)，而且我也限定了網域名稱，不過您應該可以了解大致的概念。
Figure 3 建立 GPO (Close Figure 3)
$gpmConstants = $gpm.GetConstants()
# This is the GPMC way to retrieve all
# constants
$gpmDomain =$gpm.GetDomain(“Mydomain.local”, “”, $gpmConstants.UseAnyDC)
# Connects to the domain where the GPO should
# be created, replace Mydomain.local with the
# name of the domain to connect to.
$gpmNewGpo = $gpmDomain.CreateGPO()
# Create the GPO
$gpmNewGpo.DisplayName = “My New Windows PowerShell GPO”
# Set the name of the GPO
現在知道怎麼建立 GPO 後，讓我們改開啟一個現有的 GPO。您仍有網域的參考 $gpmDomain，所以鍵入下列內容：
$gpmExistingGpo = $gpmDomain.GetGPO(
  “{31B2F340-016D-11D2-945F-00C04FB984F9}”)
# Open an existing GPO based on its GUID,
# in this case the Default Domain Policy.
$gpmExistingGpo.DisplayName
# Show the display name of the GPO, it
# should say Default Domain Policy
$gpmExistingGpo.GenerateReportToFile($gpmConstants.ReportHTML, “.\DefaultDomainPolicyReport.html”
這會提供預設網域原則內各項設定的完整 HTML 報告，但是您顯然可以使用任何一種方法和屬性，像是 ModificationTime 會告訴您 GPO 上次修改的時間，以確定 GPO 內的任一設定是在何時發生變更。
這相當實用，您很有可能遇過這樣的情形：電話響個不停，一堆使用者抱怨他們的電腦怪怪的。您懷疑這跟 GPO 設定被變更、新增或刪除有關，但是您完全不知道要查看哪個 GPO。這時 Windows PowerShell 就派上用場了！假如您在 Windows PowerShell 命令列中輸入如 [圖 4] 所示的指令碼，會得到所有在過去 24 個小時內有所變更的 GPO。
Figure 4 探索已修改的 GPO (Close Figure 4)
$gpmSearchCriteria = $gpm.CreateSearchCriteria()
# We want all GPOs so no search criteria will be specified
$gpmAllGpos = $gpmDomain.SearchGPOs($gpmSearchCriteria)
# Find all GPOs in the domain
foreach ($gpmGpo in $gpmAllGpos)
{
if ($gpmGpo.ModificationTime -ge (get-date).AddDays(-1)) {$gpmGpo.DisplayName}
# Check if the GPO has been modified less than 24 hours from now
}
注意 –ge 運算子是指大於或等於。如果您習慣其他指令碼或程式設計語言中的 < 和 > 運算子的話，這看起來可能有點怪。但該些運算子是用於重新導向，比如將輸出重新導向至檔案，因此在 Windows PowerShell 中不能當做比較運算子來使用。

結論
[圖 5] 中的程式碼列出將其中一個 GPO 的設定複製到另一個 GPO 的完整指令碼。您現在對於要如何將此項新技術與群組原則搭配使用，還有如何重複利用 COM 物件或取用 COM 物件的 VBScript 程式碼，應該有點概念了。
Figure 5 將一個 GPO 中的設定複製到另一個 GPO (Close Figure 5)
###########################################################################
# Function  : CopyGpo
# Description: Copies the settings in a GPO to another GPO
# Parameters : $sourceGpo     - The GPO name or GPO ID of the GPO to copy
#           : $sourceDomain   - The dns name, such as microsoft.com, of the domain where the original GPO is located
#           : $targetGpo      - The GPO name of the GPO to add
#           : $targetDomain   - The dns name, such as microsoft.com, of the domain where the copy should be put
#           : $migrationTable - The path to an optional Migration table to use when copying the GPO
# Returns   : N/A
# Dependencies: Uses GetGpoByNameOrID, found in article download
###########################################################################
function CopyGpo(
 [string] $sourceGpo=$(throw ‘$sourceGpo is required’),
 [string] $sourceDomain=$(throw ‘$sourceDomain is required’),
 [string] $targetGpo=$(throw ‘$targetGpo is required’),
 [string] $targetDomain=$(throw ‘$targetDomain is required’),
 [string] $migrationTable=$(“”),
 [switch] $copyAcl)
{

 $gpm = New-Object -ComObject GPMgmt.GPM # Create the GPMC Main object
 $gpmConstants = $gpm.GetConstants() # Load the GPMC constants
 $gpmSourceDomain = $gpm.GetDomain($sourceDomain, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC
 $gpmSourceGpo = GetGpoByNameOrID $sourceGpo $gpmSourceDomain
 # Handle situations where no or multiple GPOs was found
 switch ($gpmSourceGpo.Count)
 {
   {$_ -eq 0} {throw ‘No GPO named $gpoName found’; return}
   {$_ -gt 1} {throw ‘More than one GPO named $gpoName found’; return}
 }
 if ($migrationTable)
 {
   $gpmMigrationTable = $gpm.GetMigrationTable($migrationTable)
 }

 $gpmTargetDomain = $gpm.GetDomain($targetDomain, “”, $gpmConstants.UseAnyDC) # Connect to the domain passed
                                                                              # using any DC

 $copyFlags = 0
 if ($copyAcl)
 {
   $copyFlags = Constants.ProcessSecurity
 }
 $gpmResult = $gpmSourceGpo.CopyTo($copyFlags, $gpmTargetDomain, $targetGpo)
 [void] $gpmResult.OverallStatus

}
就像群組原則一樣，Windows PowerShell 將成為任何 Windows 管理環境中渾然天成的一部分。不過還是有上百萬行的 VBScript 需要遷移或維護，希望這份教學課程有所幫助。
要加強您的群組原則管理，以及您過去使用 VBScript 的其他領域，有許多來源您可以利用，包括下載當中的 Windows PowerShell 函數，以及 Technet 網站上的 VBScript 與 Windows PowerShell 轉換指南，這本指南提供一些提示教您如何在 Windows PowerShell 內執行與 VBScript 對等的常見工作。您可以在 microsoft.com/technet/scriptcenter/topics/winpsh/convert 找到此指南。
另外，GPMC API 也有完整的記錄，您可以從群組原則網站下載相關資訊，網址是 microsoft.com/grouppolicy。
最後也很重要的一點是，如果您還沒安裝 Windows PowerShell，還在等什麼？趕快從 microsoft.com/powershell 下載，祝您玩得愉快。

Thorbjörn Sjövold 是 Special Operations Software (www.specopssoft.com) 的 CTO 和創辦者，這是一家以群組原則為主的系統管理和安全性延伸模組產品的供應商。您可透過電子郵件與他連絡：thorbjorn.sjovold@specopssoft.com。


 Windows 系統管理: 部署終端機服務指南
Windows 系統管理 James D. Silliman

部署終端機服務指南
摘要:
  • 以幾個簡單的步驟部署終端機服務
  • 最佳化您 TS 環境中的 Office
  • 使用 TS 有效管理使用者

回顧 1998 年，當時 Microsoft 發行了 Windows NT 4.0 終端機服務版本，代號 "Hydra"。Microsoft 從 Citrix Systems 取得授權，推出第一個精簡型用戶端/
伺服器產品。對於系統管理員來說，"Hydra" 是一種截然不同的部署。隨著時光流逝，終端機服務有了很大的轉變。它完全整合至核心，並且可透過內建的安裝精靈輕鬆設定，完全不需要額外的 CD 或網際網路下載。除了安裝極為簡便，還有許多理由可以解釋為什麼要在組織內部署終端機服務。最立竿見影的優點是讓所有的應用程式在中央伺服器上執行，這樣一來，就不需要操心用戶端架構和硬體。使用者只需要遠端桌面通訊協定 (RDP) 用戶端，就能連線到中央伺服器。所幸目前的架構大多提供 RDP 用戶端。
在本文中，我將向您說明如何啟用現有 Windows Server® 2003 安裝上的終端機服務，如何套用終端機服務群組原則，以及如何使用「自訂安裝精靈」來自動化 Microsoft® Outlook® 設定檔設定。完成所有步驟後，您將擁有一部部署完整的終端機伺服器可以提供應用程式給您的使用者。

入門
設定終端機您需要採取的第一個步驟是開啟內建的「設定您的伺服器精靈」，它位於 Windows Server 2003 系統管理工具內。選取 [終端機伺服器]，然後按一下 [下一步]，直到精靈完成為止。安裝程式會警告您它必須自動重開機以初始化變更。重開機之後，伺服器將處於 [終端機伺服器] 模式。
順帶一提，請先確定您手邊已經有終端機服務用戶端存取授權 (CAL)，再著手進行，否則即使部署成功也無人能夠連線。現在將執行終端機服務的方塊加入 Active Directory® 網域，並以具備 Domain Admin 權限的帳戶登入。假如您不在網域上，就很難繼續，因為您將無法強制群組原則。針對本文，您安裝終端機服務的伺服器叫做 TS01。
接下來從 [系統管理工具] 啟動 [Active Directory 使用者及電腦]，並在您要放置終端機伺服器的地方新建一個組織單位 (OU)。為了簡單起見，讓我們為 OU 取個非常原創的名稱，Terminal Servers。找出您的終端機伺服器 TS01，並將它移到新的 Terminal Servers OU 中。
接下來，從 microsoft.com/windowsserver2003/gpmc 下載並安裝群組原則管理主控台 (GPMC)。這個管理公用程式可讓您設定新群組原則、為它指派權限，然後編輯原則，以便讓您針對要連線的任何使用者開啟或關閉適用的原則設定。GPMC 是終端機服務部署不可或缺的工具，因為它有內建的「模型」精靈，可立即反映出哪些原則套用到使用者，而哪些沒有。
從 [系統管理工具] 啟動 GPMC，然後在 [群組原則管理] 視窗的左邊找出您新的 [Terminal Servers OU]。以滑鼠右鍵按一下 OU，選取 [在這裡建立及連結 GPO]，如 [圖 1] 所示，然後為它取個實用的名稱，像是 Terminal Server Policy #1。
[圖 1] 建立及連結新 GPO
[圖 1] 建立及連結新 GPO
您會注意到 Authenticated Users 群組神奇地出現在 GPMC 視窗左邊的 [安全性篩選] 方塊中。這個群組預設會新增到所有群組原則物件 (GPO) 中。按一下該群組，再按 [移除] 按鈕。您要改在 Active Directory 樹狀結構中設定 Terminal Services 群組，以便在使用者登入 TS01 時可以將之套用至 GPO。讓我們把 Terminal Services 群組叫做 BottleWashers。從 [系統管理工具] 使用 [Active Directory 使用者及電腦] 直接把它們加入 Active Directory 結構中。您也需要將 BottleWashers 加入 TS01 及您安裝的任何其他終端機伺服器上的 Remote Desktop Users 群組。
確定您現在位於 [領域] 索引標籤上。按一下 [安全性篩選] 方塊中的 [新增] 按鈕，然後將 BottleWashers 新增為群組。BottleWashers 將自動獲得 Terminal Server Policy # 1 的 [讀取] 和 [套用] 群組原則權限。這兩種權限是預設的群組原則權限，並且是將任何原則套用至物件的必要權限。
接下來，也將伺服器 TS01 加入 [安全性篩選] 方塊。對於此操作，還有另外一個步驟。首先按一下 [新增]，然後在 [物件類型] 下，確定您在 [電腦] 索引標籤中加上核取標記，否則 GPMC 將無法在 Active Directory 中找出 TS01。最後的結果看起來應該像 [圖 2] 所示。
[圖 2] 在安全性篩選下新增 TS01
[圖 2] 在安全性篩選下新增 TS01
同樣地，透過新增至 [安全性篩選] 方塊，正確的原則權限將自動套用至 TS01。現在按一下右手邊 GPMC 畫面上方的 [委派] 索引標籤，然後尋找 [Domain Admins]，這預設也會在任何新的原則上列出。按一下畫面右下角的 [進階] 按鈕。
您現在檢視的是群組原則物件的 [安全性設定]。請確定將焦點放在 [Domain Admins] 上，然後尋找下方的 [套用群組原則] 設定。在右手邊，按一下 [拒絕] 選項。按下 [確定] 後，您將收到一則標準的警告訊息，這在您每次設定 [拒絕] 權限時都會出現。此步驟可防止新的 TS 原則被套用到 Domain Admins，我們可不希望這樣。
記得我建議您準備好 Microsoft CAL 嗎？您需要檢閱授權文件並確定要購買哪個終端機服務 CAL。終端機伺服器有兩種 CAL：使用者和裝置。您可以在 microsoft.com/windowsserver2003/howtobuy/licensing/ts2003.mspx 取得有關授權的詳細資訊。
基本上，每一使用者授權可讓一名使用者只取用一份終端機伺服器授權，而不受到使用者連線裝置 (PC) 數目的限制。
如果您網域中還沒有終端機伺服器授權伺服器，請找出可接掌此角色的成員伺服器。雖然支援把 TS01 當作授權伺服器，但最好不要這麼做，因為若您稍後加入更多終端機伺服器到組織中，將無法在基礎結構內建置容錯。在您提出的授權伺服器上進入 [控制台]。開啟 [新增/移除程式] | [Window 元件] | [終端機伺服器授權]，然後遵循提示來啟用授權伺服器。這個步驟完成後，按一下 [開始] | [執行]，然後輸入：
tscc.msc
這會帶出 [終端機伺服器設定]\[伺服器設定] 樹狀目錄。在此處按一下 [伺服器設定] | [授權]，並選取 [每一使用者] 或 [每一裝置]。預設值是 [每一裝置]。如果您的網域中已經有終端機伺服器授權伺服器，則 Terminal Server Policy #1 內會有個設定指出擔任 [授權伺服器] 角色的伺服器。完成此工作之後，再次前往 [開始] | [執行]，然後鍵入：
licmgr.exe
現在您必須啟動 CAL，使用者才能連線。您可以方便地透過電話或網路進行此動作。使用者之後應該能夠連線到您的終端機伺服器，但是不會有任何強制的原則，所以讓我們開始設定幾項重要的原則。Microsoft 建議的一些原則位在知識庫文件＜如何將 Windows Server 2003 或 Windows 2000 終端機伺服器工作階段鎖定＞中。

啟用原則
請記住這個大原則，對每個原則的作用缺乏認識時千萬不要貿然開始啟用，否則可能會導致一些未預期的結果。比較妥當的方法是先從幾個基本的原則著手，並在實驗室環境下行大規模的測試。
您第一個可能會想要強制的原則是回送原則。若要啟用它，請啟動 GPMC，找出 Terminal Server Policy #1 的位置，以滑鼠右鍵按一下它，然後選取 [編輯]。前往 [電腦設定] | [系統管理範本] | [系統] | [群組原則]，然後啟用 [使用者群組原則回送處理模式] 設定。啟用此原則之後，要設定它的 [模式] 值，可以是 [取代] 或 [合併]。為了在終端機服務中獲得最佳結果，請選取 [取代]。
另一個您應該啟用的終端機伺服器設定是 [將 Administrators 安全性群組加入漫遊使用者設定檔]，位於 [電腦設定]\[系統管理範本]\[系統]\[使用者設定檔]。此設定可確保身為系統管理員的您永遠對使用者設定檔資料夾具備完整控制權。這個設定要及早設定，因為如果在使用者第一次登入後資料夾就已經建好的話，將不會套用此設定。
[圖 3] 啟用 [加入 Administrators 安全性群組] 值
[圖 3] 啟用 [加入 Administrators 安全性群組] 值
您可以在 [電腦設定]\[系統管理範本]\[Windows 元件]\[終端機服務] 中找到各種原則。請考慮啟用這些原則：
  • 限制終端機服務的使用者只能使用一個遠端工作階段
  • 設定 TS 漫遊設定檔路徑
  • TS 使用者主目錄
不過要注意的是，限制終端機服務使用者只能使用一個遠端工作階段將無法防止使用者登入一次以上，跟您預期的不同。相反地，當使用者嘗試啟動第二個終端機服務工作階段時，他會直接管第一個登入的工作階段。
漫遊設定檔是適當終端機伺服器作業的必要元素。預設情況下，當使用者登入終端機伺服器時，終端機伺服器 C: 磁碟機上會建立一個本機設定檔，即使您將 C:磁碟機隱藏起來不讓使用者看到也一樣。漫遊設定檔的預設行為是，在使用者登出時將本機設定檔與網路上的漫遊設定檔共用同步化。您可以設定群組原則在使用者登出時清除這個本機設定檔。
上述的後兩個終端機服務原則，[設定 TS 漫遊設定檔路徑] 及 [TS 使用者主目錄]，都與漫遊設定檔相關。這些設定通常是限定在 Active Directory 使用者的 [終端機服務設定檔路徑] 方塊中。經由群組原則來設定終端機服務路徑是比較簡單且較佳的方式。對於 [Active Directory 使用者及電腦] 的終端機服務設定檔路徑，如果您設定新使用者或複製現有的使用者，就必須每次手動加入 TS 伺服器設定檔路徑資訊 — 相當麻煩。將這些路徑設定到網路共用，並使用 GPO 為您設定是比較妥當得多的方法。

資料夾重新導向
現在讓我們來看一下另一個非常重要的終端機服務元件：資料夾重新導向，它會防止過長的登入和登出來最佳化 TS 體驗。您可以重新導向的資料夾是 [應用程式資料]、[桌面]、[我的文件] 和 [開始功能表]。這四個資料夾必須存在網路共用上，而且它們需要有特定的存取控制清單 (ACL)。不妨參考一下知識庫文件＜如何動態建立安全性增強重新導向的資料夾藉由使用在 Windows 2000 及 Windows Server 2003 中的資料夾重新導向＞，取得有關此主題的詳細資訊。
資料夾重新導向的優點是不必在每次使用者登入或登出時複製整個使用者設定檔。終端機服務會辨識存在網路上的這些資料夾，並且基本上只是提供指向它們的指標。
建議您使用漫遊設定檔和資料夾重新導向來探索分散式檔案系統 (DFS)，以簡化網路共用的維護作業。因為篇幅的限制，我在本文將不討論 DFS，不過您可以在 DFS 資源中心 (英文) 進一步探索它。
您可在 [使用者設定]\[Windows 設定]\[資料夾重新導向] 找到 [資料夾重新導向] 設定 (見 [圖 4])。[資料夾重新導向] 資料夾值非常明白易懂。您應該移除每個資料夾重新導向設定中標示為 [將使用者獨占權利授與] 的核取標記，否則系統管理員將無法存取該些資料夾。
[圖 4] 資料夾重新導向設定位置
[圖 4] 資料夾重新導向設定位置

安裝 Microsoft Office
現在設好幾項基本的原則後，讓我們準備好安裝 Microsoft Office 2003，或 2007 Microsoft Office System。Microsoft Office 已針對終端機服務經過最佳化，因此在安裝期間要變更的不多。Office 組合產品內的高頻寬項目預設會關閉。到目前為止，您需要下載和安裝群組原則系統管理範本檔案 (ADM 檔案)，以便控制 Office 組合產品內的原則。
您所需的 ADM 檔案是位於 microsoft.com/office/orkarchive/2003ddl.htm。針對本文的目的，您只需要下載兩個檔案：Office 範本檔 (ORKSP2AT.exe)，以及自訂安裝精靈。不過，第二個檔案只有在您部署的是 Office 2003 的時候才需要。2007 Office System 並不使用此精靈，您只需要按一下 [開始] | [執行]，然後鍵入 Setup /a，它就會自動啟動。
在解壓縮第一個檔案 ORKSP2AT.exe 後，會看到許多檔案。office11.adm 和 outlk11.adm 檔案是您要注意的檔案 (見 [圖 5])。
[圖 5] Office 範本檔
[圖 5] Office 範本檔
啟動 Windows 檔案總管，並將這兩個檔案複製到 %systemroot%\inf。回去再次啟動 GPMC 主控台。在 [群組原則物件] 下找出 Terminal Server Policy #1 的位置，以滑鼠右鍵按一下它，然後選取 [編輯]。現在前往定義原則內的 [電腦設定]\[系統管理範本]。在 [系統管理範本] 上按一下滑鼠右鍵，然後選取 [新增/移除範本]，如 [圖 6] 所示。
[圖 6] 將系統管理範本加入 GPO
[圖 6] 將系統管理範本加入 GPO
您現在會看到這兩個檔案已可供您使用，請一次新增一個檔案。這些範本檔會出現在 [使用者設定]\[系統管理範本]\[Microsoft Office 2003] 以及 [使用者設定]\[系統管理範本]\[Microsoft Office Outlook 2003] 中。您可以瀏覽這些範本設定，並隨意啟用或停用它們。
我在這裡不會詳討許多設定，但是有兩個您可能要移除的設定是 [Office 小幫手] 和 [Outlook 自動封存]。請注意有些設定，像是 [Exchange 快取模式] 和 [垃圾郵件篩選]，在終端機服務中預設都會停用，因此沒有必要停用這些原則。
您可以在＜在終端機服務停用的 Outlook 功能＞(英文) 中找到更詳細的資訊。要停用 [Office 小幫手] 很簡單，只要在群組原則選取 [使用者設定]\[系統管理範本]\[Microsoft Office 2003]\[小幫手]\[選項] 即可。
在終端機服務的環境中，您不會想要一直提示使用者採取某些動作。關於提示一個特別擾人的範例是 Outlook 的 [郵件自動封存] 設定。如果在群組原則內忽略此設定，使用者就會在特定的時間間隔內收到自動封存的提示。停用此設定可把它徹底從使用者的 Outlook [偏好設定] 功能表移掉。當然啦，您可能會想要自動封存，所以可以在 [使用者設定]\[系統管理範本]\[Microsoft Office Outlook 2003]\[工具] | [選項]\[自動封存] 的原則內微調此設定。
確保終端機服務部署成功要採取的下個步驟是設定 Outlook PRF 檔案，讓使用者不會收到提示要手動設定他們的 Outlook 設定。這項工作看似困難，其實不然。只需要安裝 OrkTools 並使用「自訂安裝精靈」建立 PRF 檔案，告訴 Outlook 安裝精靈如何反應就行了。2007 Office System 裡有個機制可廢棄這個程序，不過如果您想要的話，還是可以在 Office 使用 PRF 檔案。
讓我們使用 CIW 來設定 Outlook PRF 檔案。您實際上不會執行整個 CIW 常式，只會執行需要匯出修改過的 PRF 檔案的部分。這只有幾個步驟。
首先，啟動並解壓縮您稍早下載的第二個檔案 (即「自訂安裝精靈」)。在從 [開始] | [程式集] | [Microsoft Office 2003 Resource Kit] 啟動精靈後，系統將詢問您 Office 2003 MSI 檔案的位置。 插入 Office 2003 光碟，並指明 MSI 檔案的名稱和路徑。
現在直接跳到 CIW 中的第 17 頁 (共 24 頁)，以便跳過 CIW 其餘的部分，直接建立 PRF 檔案。在步驟 17，選取 [新增設定檔]，並為它取個像是 Outlook 的名稱，然後按一下 [下一步]。接著會出現一個畫面，允許您選取 Exchange Server (如 [圖 7] 中所示)。鍵入 Exchange Server 的名稱，再按一下 [下一步] 繼續。
[圖 7] 設定 Exchange Server 連線
[圖 7] 設定 Exchange Server 連線
將 Outlook 通訊錄加入您正在建立的通訊錄是個不錯的主意。這麼做可讓使用者在撰寫新郵件時選擇他們的連絡人。光這個步驟就可以在未來省下您許多時間。您也可以在此處選取 [新增] 按鈕來設定其他自訂功能。現在按一下 [下一步]，接下來就只剩匯出 PRF 檔案。
這裡您需要建立一個批次檔，將它放入網域控制站 (而不是 TS01) 上的 Netlogon 共用。批次檔將啟動您所需的任何對應，並設定好 PRF 檔案以進行部署。我寫了 WMI 指令碼，為您省點事。不過，這些指令碼只適合當作參考，您必須插入與您的情況相關的資訊。如果您要的話，可以使用另一個指令碼處理器，如 KiXTart。
批次檔 (logon.bat) 應該包含這幾行：
REM Logon.bat
@echo off
wscript %0\..\clean.vbs
wscript %0\..\outlook.vbs
Clean.vbs 檔案會移除第一次執行的登錄機碼，讓 Outlook 處理 PRF 檔案：
' Clean.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
    sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\
    Outlook\Setup"
sValueName = "First-Run"
oRegistry.DeleteValue HKEY_CURRENT_USER, sKeyPath, _
    sValueName
Outlook.vbs 會在登錄中為每個終端機伺服器使用者新增適當的 Outlook 安裝機碼。您需要在 SValue= 設定中提供您自己的路徑，而且別忘了將您實際自訂的 PRF 檔案加入實際的網路目錄中：
sValue = \\Serv01\PRF\Outlook.prf
變更此路徑，並在當中放入您的 Outlook.prf 檔案：
' Outlook.vbs
Const HKEY_CURRENT_USER = &H80000001
sComputer = "."
Set oRegistry=GetObject("winmgmts:\\" & _
  sComputer & "\root\default:StdRegProv")
sKeyPath = "Software\Microsoft\Office\11.0\Outlook\
    Setup"
oRegistry.CreateKey HKEY_CURRENT_USER, sKeyPath
sValue = "\\Serv01\PRF\Outlook.prf"
sValueName = "ImportPRF"
oRegistry.SetStringValue HKEY_CURRENT_USER, _
    sKeyPath, sValueName, sValue
部署作業的下一個待辦項目是在 TS01 上安裝 Office 2003 或 2007 Microsoft Office System。如前所述，Microsoft Office 已針對終端機服務環境經過最佳化。所以完全不再需要建立自訂轉換。您可以關閉預先選定的功能以外的 Office 功能，但這並非強制動作。相反地，您也可以開啟這些功能，不過此舉可能會有不利的頻寬反應。記得在部署到實際狀況之前，先測試您在實驗室環境中啟用的任何功能。
在安裝任一版的 Microsoft Office 之前，需要讓 TS01 進入適當的使用者模式。可選擇的動作有兩種：[安裝] 和 [執行]。您應該在執行任何軟體安裝之前處於 [安裝] 模式。若要讓 TS01 進入 [安裝] 模式，請在命令提示鍵入下面內容：
C:>change user /install
安裝完成後，鍵入下面內容讓 TS01 回到 [執行] 模式：
C:>change user /execute
如果您是在 TS01 上執行 Setup.exe 或 Install.exe，便會自動啟動 [安裝] 模式。Microsoft 所有產品皆有這些啟動檔案。然而，有些應用程式並不使用這些模式，所以為了安全起見，可使用 [變更] 命令。若是忘了您處於何種模式怎麼辦？只要執行下面的命令就可以知道：
C:>change user /query
您都撐到這裡了，表示應該沒什麼問題。您現在可以到 Windows 用戶端工作站，按一下 [開始] | [執行]，然後鍵入此命令：
mstsc
如果您使用的是 Windows 2000，可下載 Microsoft Terminal Services Client (Mstsc) 公用程式。
現在應該會出現 [遠端桌面連線] 畫面。直接鍵入終端機伺服器名稱或 IP 位址來進行連線。[選項] 按鈕下方有許多可用的選項，如是否要連接本機磁碟機或印表機，或變更視訊解析度。您也可以將 TS01 寫死在 [選項] 區域，然後將 RDF 設定檔存到桌面。在預設情況下，RDP 設定檔是叫做 Default.RDP。

系統管理工作
假如您希望在 TS01 上執行一些系統管理工作，最好是使用下面這個命令，因為它會模擬各種動作，就跟您親自坐在主控台前一樣。
Mstsc /console
如果您同時管理著許多不同的終端機伺服器，可能會想要使用位於系統管理工具內的遠端桌面公用程式，因為您可以用它將所有遠端終端機伺服器加入單一樹狀目錄格式中。
您應該要知道的最後一個命令是 Tsadmin，這可讓您查看連線到您終端機伺服器的有哪些使用者，以及使用者開啟了哪些 Windows 處理序。它還能讓您陰影複製使用者，這對系統管理員是一大福音。不過要注意，假如您是從工作站啟動 TSadmin，就無法陰影複製使用者，只看得到連線。您必須直接登入 TS01 才能陰影複製使用者，傳送訊息給他們，或是將他們登出。

結論
您現在對終端機服務應該有詳實的了解，所以自己部署終端機伺服器將是輕而易舉。還有許多主題可供您進一步探索，包括群組原則設定和 DES，但只要您記得基本原理，例如設定 GPO 時不要走極端，還有在發給使用者前大規模地進行測試等，就已經有非常好的開始。

James D. Silliman是 MCSE，擔任 DirectApps, Inc. 的資深系統工程師，擅長終端機伺服器部署。DirectApps 是一家設計 .NET 解決方案架構並提供主機代管和 ASP 服務的公司。您可以透過電子郵件與他聯絡：bhynes@microsoft.com。


 編輯的話: 安全性帶著走
編輯的話
安全性帶著走
Joshua Trupin

現在到處都可以是 工作場所。過去十年來，「行動辦公室」的概念開始風行。不用再綁在辦公桌前工作。行動技術讓您在外出、在家裡、在火車上，甚至在車內等紅燈 (不過要小心) 時都能具備產能。這真是完美的世界呀！但如果您是 IT 專家，可能正面臨著最大的挑戰：保障可順手帶著走的裝置安全性和管理這些裝置。
在 1980 年代，安全性是指在發現新病毒時做出反應，告知使用者把磁片放到塑膠套裡，彼此分開放(我可沒唬人，我在前一家服務的公司這麼做時，沒有一台機器感染病毒)。如果真有個惡意的程式最後感染了機器，也是因為有人帶著受感染的磁片到隔壁座位用電腦才散播出去的。有時候對 IT 專家來說，趁別人外出用餐時偷偷移掉他們的 5.25" 磁碟還比較輕鬆。運氣好的人還剩 10MB 硬碟可以存放資料。
在 1990 年代，要找出感染自己的機器的使用者就變得比較困難一點，因為他們開始透過網路感染病毒。跟前十年不一樣，光是以慢動作特效的功夫特技，把磁片從某人的手上踢掉，已經不能保護機器。
如今我們得全面掌控來保障企業的安全、散發群組原則，以及設定防火牆、隔離和瓶頸。接下來呢？企業自己開始四處跑！個個出辦公室大門，您能怎麼辦？
保障辦公室內的資產不過是當今 IT 現象中的部分挑戰。各組織並不如想像中的強固，而且讓員工帶著連到您的網路的行動裝置和膝上型電腦四處跑可說是自找麻煩。我們本月份的頭版文章將討論如何保障行動裝置的安全，好讓疲憊如您的系統管理員可以高枕入眠。
當然，本期還有更多精采內容。我們將探討管理 Exchange Server 以遵循法規、網路存取保護、部署終端機服務、Windows PowerShell、SQL Server 等，涵蓋的內容多到需要整整一頁才說得完 (從目錄來看，實際上是兩頁)。
您在公司遇過最獨特的安全性狀況是什麼？來趟《TechNet Magazine》部落格 (blogs.technet.com/tnmag)，一起參與討論。編輯們正等著您！—Joshua Trupin

感謝下列 Microsoft 技術專家：Alex Balcanquall、Tad Brockway、Anah Cameron、Jeroen de Borst、Michael Higashi、Ryan Hurst、Paul Limont、Sherman Lovell、Michael Murgolo、Shivakumar Seetharaman、John Speare、David Strome 和 Jim Truher。

Joshua Trupin


 回信: 解答
回信
解答

製作映像
在《Getting Started with Windows® PE》(2006 年 9 月) 一文中，Wes Miller 曾提到 mkimg.cmd。但是在我裝有 Windows Automated Installation Kit (WAIK) 和 Business Desktop Deployment Solution Accelerator (BDD) 2007 的 Windows Vista™ 系統上找不到這個命令檔。我有目前發佈的 mkimg_pe2004.cmd 和 mkimg_pe2005.cmd。可是它們呼叫的 bldini.cmd 檔案，好像也不存在。我在哪裡可以找到這些檔案？
—Jim A。

該文實際上是在 Windows Vista 發行之前發表的，而且只針對適用於 Windows XP 和 Windows Server® 2003 的 Windows PE 版本 (稱為 Windows PE 1.6)。我們於 2006 年 11 月所發表的續篇討論過 Windows PE 2.0，這是適用於 Windows Vista 的版本。您可以在我們的網站上找到該篇文章。
您可以利用 WAIK 中的工具來建置和自訂 Windows PE 2.0 映像，在此特別註明，"mkimg" 命令已被 "peimg" 取代。您可以在 WAIK 線上說明文件中找到建置 Windows PE 2.0 映像的逐步指南。

安全性迷思
針對《Deconstructing Common Security Myths》(2006 年 5/6 月) 提到使用長密碼而非複雜密碼的建議，您覺得在需要時擷取這些密碼的最佳辦法為何？不過長密碼對個人的記憶來說可能是項大挑戰。我也聽過有人建議每個要求存取的系統都使用不同密碼，不過這可能會產生類似的存放和擷取問題。
— Ian R。

我們請教好友兼投稿人 Steve Riley，很快獲得答覆：
記憶回溯性 (沒錯，這個詞是我發明的啦) 是個有趣的觀點。我覺得要記住當做通關密語的句子，比記住由任意字元組成的複雜密碼要來得容易。加上如果您採用對應方法的話，就可以記住一大堆通關密語。比方說，假設您的 Hotmail® 的通關密語是「My dog and I got the mail」。這很容易記得，因為密碼與目標 (電子郵件網站) 之間有關聯 (取得郵件)。採用對應方法的話，您可以使用「My dog and I went shopping」作為 eBay 的通關密語，使用「My dog and I went to work」作為辦公室網域帳戶的通關密語，甚至使用「My dog and I admired some art」作為您所鍾愛的，嗯，圖片網站的通關密語。
通關密語的來源幾乎是無限的。我認識有個人只使用《巨蟒》電影內的引言。還有人只使用含五個字的密碼，當中每個字都以鍵盤上連續的字母為開頭 (「Queen willie eats rancid turnips」—QWERT)。只要一點點創意，通關密語就能協助消除絕大多數與密碼相關的問題，同時鞏固個人身份證明的密語。

《Deconstructing Common Security Myths》是一篇好文章，正好證明我對這些書呆子的想法沒錯。但若是軟體允許在獨立程式裡面產生及使用獨特的字元集 (我不是指 Webdings® 裡面的字元，而是以前從未看過的)，不就可以加深複雜度？因為沒有人擁有所有完整的獨特字元組合，只有使用者自己知道產生及使用了哪些字元。萬一我把 USB 隨身碟搞丟了，我倒寧可重建由這類字元構成的短句，也不想輸入整篇古文觀止。
—H.D。

您的想法很有趣，可是我們不確定您要怎麼記得獨特又從來沒見過的字元。除非您正好是那位曾叫做「Prince」的藝人。

Sysprep
在《Techniques for Simplifying Desktop Image Creation》(2006 年 5/6 月) 一文中，Shelly Bird 提到當建置 Sysprep 資料夾時，「處理序開始會先在含基本硬體的舊版系統上建置主映像...」，這句話是什麼意思？ 我現在正在查 BDD，但還是找不到任何關於部署單一映像的建議內容。要怎麼樣才能取得這項資訊？
— Jon S。

在您所說的文件中，作者指的是建立可當作映像擷取並重新部署到其他電腦的標準化參考組態。換句話說，您在整個環境中最簡單的硬體 (作為最基本的共同標準) 上安裝 Windows，接著以基本規格 (您希望部署到整個組織的任何修改) 來設定它，同時安裝您想要包括的任何應用程式，然後準備好使用 Sysprep 工具進行部署 (這會移除任何與硬體相關的資訊，允許映像重新部署到新硬體)。
《Computer Images System Feature Team Guide》提供有關此程序的最佳指南，它是 BDD 的一部分。BDD 的電腦影像系統元件包含一項可下載的工具，可幫助您自訂和準備映像。如需詳細資訊，請參閱 microsoft.com/technet/desktopdeployment/bdd/standard/ComImgFea.mspx。

轉換驗證
我工作時使用 SQL Server™ 2005，要如何把驗證從 Windows 驗證變更為 SQL Server 驗證 (以 sa 登入)？
— Sara J。

《SQL Server 線上叢書》中的相關主題應該可以幫助您解決問題：msdn2.microsoft.com/ms188670.aspx。不過，強烈建議您繼續使用 Windows 驗證，因為使用 sa 有隱含的安全性風險 (尤其是在沒有密碼的情況下)。有鑑於此，我們的程式碼範例中已不再使用 sa/nopass。

熱情力挺
我是《TechNet Magazine》每個月的忠實讀者。我死忠的程度嚴重到無論是上班、回家，隨時隨地都會帶幾份拷貝放到背包裡或車上。我希望可以把整份雜誌放到 Tablet PC 或 Pocket PC Phone 上。我也期待雜誌推出可以放在 MP3 隨身聽上的語音內容版本。總而言之，這份雜誌實在太棒了。我愛死它了！我把它當作聖經一樣，到處向同事宣傳。
— Erasmo M。

您想要聽語音內容嗎？沒問題！我們每個月都有提供《TechNet Magazine》Podcast。只要前往《TechNet Magazine》網站 (www.technetmagazine .com)，然後按一下左邊的 Podcast 連結就可以了。希望您聽到我們的聲音！

Jigsaw 海報
你們 2006 年 3/4 月份中的 Active Directory® Jigsaw 元件的海報，是我目前看過示範 Active Directory 如何在 Windows Server 2003 內運作的圖形表示裡面最棒的。我負責的專案是將我們公司遍佈全球的組織架構放入 Windows 2000 和 Active Directory，要是早看到這張海報，我們的工作可就輕鬆許多了。即便現在，我們的企業系統管理員對於海報上涵蓋的元件仍有歧異，如果能夠獲得這張海報的資訊，長期下來將能提升他們的團結與共識。這張海報有提供下載嗎？
— Mike C。

我們收到索取這張海報的要求之多真的是不可勝數。看起來有許多人都有跟您一樣的疑問。我們已經提供下載此海報，網址為 go.microsoft.com/fwlink/?LinkID= 80428，不過別試著用 Letter 大小的紙張列印，因為它太大了。

設定 Outlook 電子郵件簽名檔
我在公司是擔任系統管理員一職，目前正在撰寫指令碼，以便標準化網域內所有使用者的 Outlook® 簽名檔。我一直都是用貴專欄《Setting Up Outlook E-Mail Signatures》(2006 年 10 月) 中的範例程式碼。可是我有個小問題：當我試著使用下列程式碼自訂和設定簽名檔的字型色彩時，字型色彩還是保持黑色：
objSelection.Font.Color = wdRed
我可以變更字型和字型大小，但就是不能變更字型色彩。
— Edison P。

我們問了 Scripting Guys 這是怎麼一回事 (我們有個特別的緊急電話可直接接通他們)，答案是：
我們確定變更字型色彩需要使用 wdColor 列舉。試著這麼做：
  • 定義指令碼中的這個常數：
wdColorRed = 255
  • 使用此程式碼指定色彩：
objSelection.Font.Color = wdColorRed
這樣應該就可以了。

取得 Windows PE
我們公司簽有 Microsoft® Select 授權合約，請問我應該要連絡哪位以便取得在公司內部使用的第五版的 Windows PE？我們特別想要利用從 USB 快閃磁碟機開機的功能。
— Thom S。

Windows PE 是作為「軟體保證」的權益而提供。您可以判斷您的授權方案是否包含此項權益，只要查看權益比較表即可。如果包含此權益，可透過貴公司的 Microsoft 大量授權服務帳戶下載取得 Windows PE (您可以登入 https://licensing.microsoft.com)。如果您需要協助來存取這個網站的話，建議您聯絡貴公司的授權專員，或是您的 Microsoft 授權代表。


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

分析 HTTP 流量
HttpWatch Professional Edition
httpwatch.com

HTTP 是瀏覽器用來進行網站通訊的基礎，它是一項非常好用的第 7 層通訊協定。此外，隨著 Web 服務的出現，許多 Windows® Form 應用程式都使用 HTTP 來下載程式更新和連至主機以進行驗證。要在 HTTP 上找到問題、進行效能微調，或檢查應用程式間通訊的安全性可能很困難，但 HttpWatch Professional Edition 能協助您排解網路至瀏覽器的問題。
HttpWatch 顯示 Web 要求背後的詳細資訊
HttpWatch 顯示 Web 要求背後的詳細資訊
HttpWatch Professional 與 Internet Explorer® 6.0 和 Internet Explorer 7 相整合，可以顯示在瀏覽器底部，也可以顯示成瀏覽器旁邊的獨立工具。只要按一下 HttpWatch 的 [Record (記錄)] 按鈕，HttpWatch 便會開始擷取和記錄流量，並顯示 Web 要求底下的所有詳細資訊。您可以檢視原始 HTTP 資料流、網頁要求發生的重新導向、與要求相關聯的查詢字串關鍵值組、HTTP 方法、HTTP 壓縮資訊，以及區塊編碼資訊。除此之外，HttpWatch 還會顯示與要求相關的 Cookie 的詳細資訊，並提供路徑、網域、到期日及 Cookie 值。由於此應用程式
會以 Internet Explorer 的外掛程式的形式執行，因此您也可以檢視加密 HTTPS 要求的所有詳細資訊。
您可以使用 HttpWatch 來探究要求的網路階層效能資料，因為它會顯示以豪秒計的回應時間、DNS 查詢、TCP 連線、IP 位址資訊、連接埠，以及從瀏覽器接收和傳送到瀏覽器的位元組。您覺得自己對每個要求的情況瞭若指掌嗎？單一 HTML 網頁的每個要求牽涉的範圍之廣，常讓人感到意外。幸好，HttpWatch 提供的選項可讓您根據 Content-type、反應碼、URL、標頭或特定的內容字串來篩選顯示結果。透過這種方式可讓您區隔查詢範圍，同時快速鎖定所需的特定詳細資訊。
商品網站推薦使用此工具來排解客戶的疑難雜症。此應用程式可儲存要求資訊，因此客戶可以將有問題的要求的相關資訊傳送給您。如此就能協助進行疑難排解。只要按幾下滑鼠按鍵，就可以透過電子郵件來傳送專利 HWL 檔案。收到來自客戶方面的這類檔案時，您可以使用安裝套件隨附的獨立記錄檔檢視器來檢視此檔案。您也可以將要求資料匯出成 CSV 和 XML 格式，以便在其他應用程式中使用這些資料。
HttpWatch 具有公開的自動化 API，可讓您記錄測試過程中的 HTTP 階層資訊，以協助您找到效能瓶頸。此套件會安裝三個使用 API 的範例 — 其中一個是透過 Interop 程式庫使用 C 語言，另外兩個則是透過 COM 架構使用 JavaScript 及 Ruby 語言。如果您是使用 Ruby 與 Watir 進行測試，請參考商品網站上的教學課程來了解如何將 HttpWatch 整合到您的測試平台中。
售價：單一使用者授權為 $249 美元。

書評
微軟解決方案框架精要 (Microsoft Solutions Framework Essentials)
microsoft.com/mspress

為了交付成功的技術解決方案，公司必須建立有效的作業程序和明確的溝通管道。Michael S. V. Turner 的著作《微軟解決方案框架精要 (Microsoft Solutions Framework Essentials)》(Microsoft Press，2006 年) 介紹 Microsoft® Solutions Framework (MSF) 4.0 版的概要，並教導您如何使用這些基礎來開發及實作測試程序與通訊實務。
Turner 在本書一開始就提出精闢的建議，告訴您在套用 MSF 指導方針和實行原則時，先不要放棄現行的作業程序和組織結構。他反而是建議將一部份的 MSF 實作到您的產品或專案開發作業中，然後再評估這麼做的成果。完成評估後，如果效果很好，再選擇其他適合專案的 MSF 部分，然後將其引入標準的專案週期中。如此一來，您不但可以在環境中套用 MSF，同時也能減少變動所產生的非預期問題。
本書適合各種程度的讀者 (無論是否為技術出身)，只要是與交付技術解決方案相關的領域均可。＜建立 MSF 團隊＞一章說明技術人員與非技術人員要如何相互合作來交付成功的解決方案。不過文中也提醒讀者，這可能是實作 MSF 時最困難的環節之一，因為相關的責任歸屬會不時改變。
這項結構變革的中心概念在於成立一個推動團隊，而團隊成員在平等的基礎上提出各自的觀點，增加整體流程的優勢(當然，這不表示就不需要指定負責制訂決策者)。如前所述，MSF 推動團隊成員分成七個小組：產品管理、計畫管理、架構、開發、測試、使用者經驗以及發行/運作，各具有其組成重點和責任。針對包含較大群組的組織，本書也提供一些建議，指導您如何擴大推動團隊的概念來支援較大的團隊及群組。
任何專案都存有風險，但書中豐富的重組秘訣將可協助您和您的團隊有效因應風險。將專案風險減至最低很重要，細分成六個步驟的風險管理程序可成功達到這個目標：識別、分析與排定優先順序、計畫與排程、追蹤與報告、變更管制以及從過去經驗中吸取教訓。此外，您必須持續評估整個專案週期中的風險。本節所描述的重點能夠確實降低失敗的機率。
文中詳盡地介紹了解決方案交付的基礎，包括展望、規劃、建置、穩定化及部署解決方案的歷程，以及定義每個推動小組在各個階段負責的任務。新引入的 MSF 治理模型 (MSF Governance Model) 可讓您更詳細地檢視解決方案交付生命週期的各個歷程：展望、規劃、建置、穩定化、部署和最終的治理 (也就是指導解決方案交付)。
雖然您可能認為您在組織中的角色並不需要用到本書所討論工具與作業程序，但是閱讀本書可讓您重新檢視目前的作業程序 — 無論您是負責營運、開發或專案管理。即使您的工作與軟體開發無關，Turner 所涵蓋的主題也可以當做是提昇組織效率和改進溝通管道的開端。
售價：$44.99 美元。

編輯檔案
UltraEdit
ultraedit.com

每位認真的 IT 專業人員的工具箱中都需要一個功能強大的編輯器。IDM Computer Solutions 的 UltraEdit 是我認為不可或缺的其中一個編輯器。它可支援其他優質文字編輯器提供的所有標準性能及功能，包括 ASCII 字元插入、巨集、使用規則運算式並取代、外部應用程式啟動、UTF 支援以及快速處理龐大的文字檔案。不過 UltraEdit 還有一些不尋常的功能，因此特別珍貴。
針對基本的編碼工作，它提供 100,000 字的整合式多語系拼字檢查、自動完成，以及用於 C# 等標準語言的程式碼語法反白顯示功能。您可以設定在指定欄位中以強制換行的方式自動換行，這個功能特別適用於格式化每行不得超過特定長度的文字型電子郵件。在這種情況下，只需要點幾下滑鼠按鍵，就可以透過 UltraEdit 來傳送電子郵件。此應用程式是與 Windows 檔案總管相互整合，因此開啟檔案進行編輯的步驟非常簡單，只要按滑鼠右鍵再按左鍵即可。
UltraEdit 中的程式碼語法反白顯示
UltraEdit 不止能處理文字檔。它還能處理二進位檔案，並提供標準十六進位檢視來查看十六進位值、行參考以及可能的 ASCII 值。在十六進位編輯模式中，您可以剪下、複製和貼上值，也能進行標準的搜尋並取代作業。UltraEdit 包含同時支援 FTP 與 SFTP 連線的整合式 FTP 用戶端。此外，您還可以開啟標準安全殼層 (SSH) 或 TELNET 連線。
針對網路開發人員，此應用程式包含整合式 HTML 驗證工具，可用來檢查網頁。UltraEdit 也有用來處理文字型資料庫檔案與分隔記錄檔的欄位模式；這個模式可讓您輕鬆轉換、加總和編輯資料，藉此簡化編輯作業。UltraEdit 甚至還能將檔案集合分組成一個專案或工作區，好讓您按一下就能開啟一群相關檔案。總而言之，UltraEdit 提供一堆可讓您的 IT 生涯更輕鬆有效率的功能。
售價：單一使用者授權的直接售價為 $49.95 美元。

管理行動組態
Net-Switch
net-switch.com

這個問題很常見。您會帶著膝上型電腦在不同的場所中移動 (例如，從資料中心牢籠移動到 QA 環境)。您發現自己得要不斷重新指定膝上型電腦的靜態 IP 位址與預設印表機。如果您覺得這種情境很熟悉，那麼您可能該試試看 Net-Switch。這個方便的公用程式可讓您設定及儲存多個網路設定，每個網路設定都有自己的預設印表機指定，因此您不需要每次在不同環境中移動時背誦或手動輸入這些數字。
Net-Switch 處理膝上型電腦設定
這個應用程式非常簡單好用。只要命名組態，挑選網路介面卡，指定靜態 IP 與其相關遮罩、閘道及 DNS 伺服器 (或選取 DHCP)，設定預設印表機，就大功告成了。只需花一點小錢就能免掉您日常的麻煩。
售價：直接售價 $19.95 美元。

寫信至工具箱
如果您希望在本專欄中介紹偏愛的工具或公用程式，請與作者連絡，來信請寄 tntools@microsoft.com。

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


 SQL 問答集: 最佳作法分析程式、多核心處理器及更多
SQL 問答集
最佳作法分析程式、多核心處理器及更多
由 Nancy Michell 編輯

問：對於結構描述限定資料表/檢視使用方面的一些最佳作法分析程式規則，我有一些問題。根據 BPA 說明文件，這項規則並不會檢查暫時資料表上的結構描述是否合格。BPA 報告旗標會參考在預存程序內建立的暫時資料表。它們應該要加以限定嗎？如果要，是使用哪個結構描述？我以為暫時資料表應該跟其他資料表一樣，限定為其擁有者。
答：BPA 對結構描述限定資料表和檢視參考的建議，事實上在 SQL Server™ 2005 上並不適用，因為分隔使用者結構描述已修正了要求在 SQL Server 早期版本上採用此作法的問題。之所以需要限定結構描述是為了要讓 SQL Server 2000 中具有不同預設結構描述的不同使用者重複使用查詢計劃。查詢計劃不需要合格即可使用 dbo 物件，但是 SQL Server 必須先檢查物件的預設結構描述，以防止重複使用查詢計劃。由於使用者結構描述的分隔可讓不同的使用者共用預設結構描述，並在一般的情況下，讓所有資料庫使用者存取其預設結構描述內的物件，因此通常是讓使用者間共用和重複使用含不完整資料表和檢視名稱的臨機操作計劃。預存程序內的不完整資料表和檢視名稱完全不會遇到這個問題，進而使此作法無立足之地。SQL Server 2005 中 BPA 不會包括此類的規則，因為它沒有 T-SQL 剖析器。它反而會檢查不當的組態和安全性設定。

問：我在使用 SQL Server 2005 SP1 時遇到奇怪的狀況。要是刪除資料表上的記錄，同時又在相同的資料表執行插入作業，這時插入的項目便會被鎖定，要等到刪除交易受到認可之後才解除。有什麼方法可以找出封鎖的來源？
答：有的。您可以執行 [圖 1] 中的 Dynamic Management Views (DMV) 指令碼找出鎖定和封鎖者。
Figure 1 尋找封鎖和鎖定 (Close Figure 1)
-- script to show blocking and locks
SELECT
  t1.request_session_id AS spid,
  t1.resource_type AS type,
  t1.resource_database_id AS dbid,
  (case resource_type
   WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id)
   WHEN ‘DATABASE’ THEN ‘ ‘
   ELSE (SELECT object_name(object_id)
      FROM sys.partitions
      WHERE hobt_id=resource_associated_entity_id)
  END) AS objname,
  t1.resource_description AS description,
  t1.request_mode AS mode,
  t1.request_status AS status,
   t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address
GO

問：除了超執行緒和雙核心技術之外，晶片廠商開始推出含多核心 (四顆、八顆，還有更多) 的處理器。我正在考慮添購一部含多核心處理器的全新伺服器，來支援 SQL Server 2005 Standard Edition 的部署，而我只是好奇，如果使用四核心處理器，就只能用單一實體 CPU (因為 Standard Edition 限用四顆 CPU) 嗎？
答：基於授權和 CPU 版本支援兩個目的，SQL Server 只會考慮實體插槽/CPU 的數目，而不管處理器上有多少核心。因此，比如 SQL Server 2005 Standard Edition 支援多達 4 顆 CPU，就表示不管每顆 CPU 裡有多少核心，它都是支援 4 個實體 CPU 插槽 (如果您有 4 顆實體 CPU，各自有 4 顆核心，則您的 Standard Edition 部署將有 16 顆邏輯 CPU 可以用)。再者，雖然您有 16 顆核心/邏輯 CPU，授權也只要求您支付 4 顆實體 CPU 而不是全部 16 顆核心的費用。如需 SQL Server 和多核心的詳細資訊，請參閱 microsoft.com/sql/howtobuy/multicore.mspx。

問：我即將添購一些全新的資料庫伺服器。我們公司應該考慮 64 位元，還是繼續使用經過測試的 32 位元版本呢？
答：視情況而定。這是目前相當常見的問題，因為廠商陸續將硬體從 x86 轉換成 x64。您應該先去了解資料庫伺服器上的記憶體壓力為何？如果 SQL Server 執行個體在硬體的壽命期間 (一般是三年) 會取用的 RAM 低於 3GB，再假設其他伺服器 (網域、控制站、DNS 伺服器、應用程式伺服器、Web 伺服器、郵件伺服器) 也將以此為參考標準的話，那麼 32 位元 x86 就蠻合理的。假如 SQL Server 執行個體會取用超過 16GB，或者是每部伺服器 (或叢集) 會有多重執行個體的話，就應該認真考慮移用 64 位元技術。要是有八個以上的處理器，建議的標準是 IA64。不過，隨著 x64 四核心和八核心 CPU 開始量產，就成本方面，可能會有很大的爭議決定選擇 x64 而不是 IA64。
當移向 x64 (或 IA64) 時，初期成本評估可能不含在開發、測試和效能環境內部署相同架構的成本。不過您也應該考慮是否要在硬體的生命週期內部份採用舊技術。18 個月後，要自外取得純 x86 硬體零件幾乎是不可能的。如果您現在採納這類的解決方案，在未來一兩年再升級，成本將很高昂，因為到時將是淘汰並替換的情況。現在就改用 64 位元硬體將在未來幾年給予您更多的選擇。
所以添購新硬體、核心應用程式發行週期的開始，或者是從 SQL Server 2000 升級至 SQL Server 2005 時，都是晉升到 64 位元的好時機。

問：我啟用了兩部伺服器間的記錄傳送。在週末時，主伺服器上發生了硬體問題，而中止了記錄傳送。我回去監看記錄傳送時，注意到儘管有幾個小時的停機 LS_backup_dbname 還是照常執行。
而在次要伺服器上，複製工作似乎運作順利，可是還原工作似乎略過一些檔案，最後是一次又一次的失敗。它可以執行，但是會略過每個檔案，然後就失敗了。所以我自上次還原的時間到現在已經有 849 分鐘。我在過去應付類似情況的措施是乾脆重新起始傳送組態 — 也就是將它關閉後再度開啟，結果變成我拿全新的備份還原到次要伺服器，重新開始記錄傳送。有什麼比較妥當的方法處理這種情況嗎？
答：您看到的大概是遺漏備份檔案的結果。如您所知，記錄傳送的備份、複製和還原工作是分開獨立執行。複製位置當中的舊備份檔也會根據您指定的排程移除。如果還原工作有一段時間沒有執行，它可能是超過了該時間間隔，於是產生遺漏備份檔案的結果。記錄傳送的還原工作的邏輯是，試著從因不同操作情況導致之不同類型的失敗中復原。基本上，它會在遇到錯誤時掃描各個檔案，並試著找出正確的備份檔案。如果找不到正確的備份檔，我在猜會不會是必要檔案已經被移除，或可能是您重新設定了記錄傳送的備份部份？
其中一個解決辦法是手動還原，一直還原到其他備份工作不小心建立的那個交易記錄備份檔。直接將它們複製到記錄傳送複製位置會有個問題，那就是記錄傳送所識別的命名慣例。不過一旦您手動還原到該點之後，正常的還原作業應該就可以接續下去。

問：我需要知道如何使用 T-SQL 來找出總實體記憶體和可用實體記憶體的大小。有沒有比較簡單的方法可以取得此項資訊？
答：只要執行 [圖 2] 中的查詢，就可以獲得您要找的資料。
Figure 2 取得記憶體 (Close Figure 2)
With VASummary(Size,Reserved,Free) AS
(SELECT
  Size = VaDump.Size,
  Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 0 ELSE 1 END),
  Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
  WHEN 0 THEN 1 ELSE 0 END)
FROM
(
  SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes))
    AS Size,
    region_allocation_base_address AS Base
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address <> 0x0
  GROUP BY region_allocation_base_address
  UNION
  SELECT CONVERT(VARBINARY, region_size_in_bytes),
    region_allocation_base_address
  FROM sys.dm_os_virtual_address_dump
  WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size)

SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024
    AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0

問：我想要將 sa (系統管理員) 密碼存到檔案中，以對稱金鑰加密該檔案，使得從應用程式建立資料庫更簡單一些。可以這麼做嗎？
答：首先，您真的不應該從應用程式使用 sa。再者，您應該使用 Windows 驗證，而不是 SQL Server 驗證。
如果您需要執行高權限的活動，應該進行下列動作：定義執行該動作所需的最低權限，定義內含該些權限的資料庫角色，指派使用者到該角色，以 EXECUTE AS 子句建立預存程序來執行該些功能。如需 Execute As 子句的說明，請造訪 msdn2.microsoft.com/ms188354.aspx。
當然啦，不管所提的帳戶是否是 sa 帳戶，要記住 Windows 驗證不一定是永遠可用的選擇，比較基本的問題是：您要如何安全地儲存 SQL Server 登入帳戶的密碼，讓需要使用該密碼的應用程式可以存取它，而未授權的使用者或應用程式不能存取呢？
將密碼加密，朝的方向沒錯，但只是將問題從保護密碼移轉到保護加密金鑰罷了。
假設這是 Microsoft® .NET Framework 應用程式，可看一下 Enterprise Library (網址是 msdn2.microsoft.com/aa480453.aspx)，以及 MSDN® 典範與實例 (patterns & practices) 部分的建議 (網址是 msdn.microsoft.com/practices)。Enterprise Library 包含了幾個對您有用的應用程式區塊，包括組態區塊、密碼編譯區塊以及資料存取區塊，這些都可以幫助您 (至少) 安全地儲存密碼，不過更重要的是，它們可幫助您管理整體的資料存取。
如果 Enterprise Library 不能用 (可能您不使用 .NET Framework)，那麼應該熟息 CryptoAPI：msdn2.microsoft.com/aa380255.aspx。您在這裡可找到附隨 OS 散發的核心密碼編譯功能，能讓您將加密金鑰繫結到使用者主體或機器，進而簡化金鑰管理 (這在您加密密碼後會是個議題)。

問：我想要將 SQL Server 2000 雙節點叢集伺服器 (主動/主動 — 在 64 位元硬體上) 從 A 網域移到相同樹系內的 B 網域。SQL Server 資料庫是位於 SAN 中。Active Directory® 架構需要有一個空根網域，含兩個子網域 (A 網域和 B 網域)。B 網域將會是放置所有基礎結構元件的網域。它是 Windows Server® 2003 企業環境，另含執行 Windows 2000 的網域控制站。
有沒有可能將 SQL Server 叢集伺服器的網域成員資格從 A 網域變更到 B 網域呢？
答：對於新手，可參考＜如何變更網域為 SQL Server 2000 容錯移轉叢集＞和＜如何將叢集伺服器從一個網域移到另一個網域＞。相同的程序也適用於多例項的叢集。唯一的差別在於您必須在適當的時候對每個例項重複各步驟。因為牽涉的複雜度，所以向來不建議您變更叢集的網域，但是也不是沒有先例。其他唯一的辦法是在開始時進行，並排重建新例項，然後遷移資料。
每個專案都不一樣，而且用來執行實際網域層級變更的工具也包羅萬象 (包括安全性考量、帳戶遷移、SID 對應等等)。通常整個程序最困難的部分在此，而不是實際進行變更本身。

感謝下列 Microsoft IT 專家提供其技術專業知識：Sunil Agarwal、Laurent Banon、Steve Bloom、Chad Boyd、Matt Burr、Shaun Cox、Cindy Gross、Bobby Gulati、Matt Hollingsworth、Arnost Kobylka、Mikhail Shir、Fernando Pessoa Sousa、Stephen Strong，以及 Ramu Veeraraghavan。


 公用程式焦點: SharePoint 網站與範本的升級工具箱
公用程式焦點
SharePoint 網站與範本的升級工具箱
Luis Câmara Manoel and Peter Skjøtt Larsen
下載本文程式碼: Upgrade Toolkit for Windows SharePoint Services Sites and Templates (699KB)

隨著 Windows SharePoint Services (WSS) 3.0 的到來，許多系統管理員正面臨將現有的 WSS 2.0 網站及資料升級至新的 WSS 3.0 環境的任務。雖然 WSS 3.0 本身提供的大量工具已足以遷移網站資料並
升級網站結構，不過升級自訂網站的結構或網站範本可能還是需要額外的工作。
然而，升級自訂網站的結構或網站範本可能還是需要額外的工作。還好，Microsoft® Solution Accelerator 小組已發行 Windows® SharePoint® Services 網站與範本的升級工具箱，當中提供了此一作法相關的指引和工具 (請參閱「WSS 資源」資訊看板)。本專欄會將重點放在升級自訂網站至 WSS 3.0 環境時可能遇到的挑戰及解決方案。不過請先參閱「WSS 詞彙」資訊看板，以了解一些常見用語的定義。

升級程序
為什麼應該升級？WSS 3.0 有許多吸引網站擁有人升級的新功能：
  • 資源回收筒，可讓使用者取回不小心刪除的文件。
  • 資料夾項目層級安全性，可讓網站系統管理員控制具有資料夾存取權的人員或群組。
  • 發送電子郵件至清單，可讓清單 (例如 SharePoint 網站上的部落格文章清單) 透過電子郵件來接收內容。
  • [網站動作] 按鈕，可讓使用者輕鬆建立網站和網頁、編輯網頁和管理網站設定。
  • 階層連結，可為使用者提供立即的導覽內容。
  • 行動裝置檢視，可讓行動使用者利用便利的離線同步處理功能。
  • RSS 摘要，可讓啟用 RSS 的程式 (例如，Internet Explorer 7.0 及 Outlook® 2007) 從清單擷取資訊。
  • 文件庫中的版本處理，可在編輯文件之前先檢查文件的次要版本處理及控制。
由於網站和範本升級程序需要在實際將伺服器升級至 WSS 3.0 的前後採取特定的步驟 (見 [圖 1])，因此妥善定義網站與範本升級需求在整個 WSS 3.0 升級策略中是很重要的步驟。網站擁有人和伺服器管理員應該一同決定要初始化及升級哪些網站和範本到 WSS 3.0 環境。一旦選取這些自訂網站後，就可以開始執行升級工作。
[圖 1] WSS 網站和網站範本升級工作流程
[圖 1] WSS 網站和網站範本升級工作流程

識別自訂的網站範本
如何判別網站是否已自訂化？WSS 3.0 提供的升級前掃描工具可產生整個伺服陣列的網站範本變更情況報告。開始進行遷移之前，您應該先執行這個工具，以便選取需要特別處理的網站範本。
這個工具會提供 XML 格式的報告，如 [圖 2] 所示。unghostedPage 項目表示網站已經過自訂。
Figure 2 針對網站範本變更內容的升級前掃描工具 (Close Figure 2)
<?xml version=”1.0” encoding=”utf-8”?>
<summary>
  <sites>
    <site url=”http://mscc-shr-v3-01” storage=”172767226”>
      <webs>
        <web url=”http://mscc-shr-v3-01/Board of Directors-Basic”>
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/default.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/EditForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/Upload.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Board Information/
                Forms/WebFldr.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/AllItems.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/DispForm.aspx” />
          <unghostedPage url=”http://mscc-shr-v3-01/Board of Directors-Basic/Company Finance and
                Business Planning/Forms/EditForm.aspx” />

自訂網站定義
您想要升級的自訂 WSS 2.0 網站可能大半是從標準 WSS 網站定義所建立的範本建置而成的。不過有些自訂網站範本也有可能是以自訂網站定義為基礎建置的。如果您組織內的開發人員自行建立自訂的網站定義，或是您購買根據自訂網站定義所建置的協力廠商應用程式或範本，就可能屬於這種情況。本專欄只針對標準網站定義案例進行討論。如需自訂網站範本案例的詳細資訊，請參閱「WSS 資源」資訊看板。
當您查明 .stp 檔案和網站的確是從標準網站定義建置的之後，表示 WSS 3.0 中有升級網站定義，您接下來就可以安裝和初始化您的網站。
若要升級特定 WSS 2.0 網站範本，首先您必須在 WSS 2.0 伺服器上安裝範本 (見 [圖 1] 中的第 1 階段)。接著，您必須根據每個已安裝的範本來建立網站。
為了簡化安裝多個 .stp 檔案、初始化多個網站，以及在完成升級程序後清除伺服器上的暫存檔案這整個流程，解決方案加速器提供了一組運用 Stsadm.exe 命令的指令碼 (詳細資訊請參閱「解決方案指令碼」資訊看板)。Stsadm.exe 是一個提供完整 WSS 作業集的命令列應用程式，可用來管理 SharePoint 伺服器與網站。解決方案指令碼任您以批次處理的方式來安裝和初始化這些工作或循序執行這些任務，藉此自動化這套程序。如果需要安裝的 .stps 以及需要初始化的網站有很多，這將節省可觀的時間。
解決方案指令碼
安裝及網站建立程序會使用兩個執行 Stsadm.exe 的指令碼：
  • MigInstStp.cmd 使用 Stsadm.exe addtemplate 作業來安裝網站範本。這項作業包含 _SOURCEFILELOCATION、_SOURCEFILENAME 與 _FILETITLE 等參數。
  • MigMakeSite_1.cmd 會建立新網站，並且執行 Stsadm.exe createweb 作業。這項作業包含 _SERVERURL、_SITENAME、_SITETEMPLATENAME 與 _SITETITLE 等參數。
請在本機 WSS 2.0 伺服器上使用對已儲存網站範本 (.stp) 檔案的位置具備存取權的身分，來執行這些指令碼。若要執行這些指令碼，您必須是該伺服器上本機 Administrators 群組的成員，或是具有網站建立權限之 WSS Administrators 群組的成員。《Windows SharePoint Services 網站和範本的升級工具箱》指南內詳盡解說了如何充分利用這些指令碼。在安裝 .stps 並初始化網站之後，您就可以開始繼續進行伺服器升級。《升級至 Windows SharePoint Services 3.0》詳細說明了 WSS 3.0 升級方法 (請參閱「WSS 資源」資訊看板中所列的連結)。

WSS 詞彙
Windows SharePoint Services 使用自己獨特的詞彙。以下簡短列出常用詞彙的名詞解釋。
網站定義：這是定義特定網站類型的一組檔案。網站定義包含 .xml、.aspx、.ascx 和主版頁面檔案，以及儲存在前端網頁伺服器上特殊資料夾中的清單範本檔案和內容檔案。WSS 提供一套標準的全新網站定義，其中包括小組網站、空白網站與文件工作區。一開始，只有儲存在網站範本庫中的網站範本，可從新 SharePoint 網站的 [選取範本] 清單中取得。
網站範本：網站範本定義著如何初始化 SharePoint 網站。若要新建 SharePoint 網站，您必須選取要當做網站基礎的網站範本。例如，您可以根據標準「空白網站」範本建立名為「Board of Directors」的新網站。接著您可以將清單、組件庫、網頁組件和其他自訂內容新增到初始化的網站。若要讓其他網站也可以使用這些自訂內容，您可以將此網站儲存成以「空白網站」網站定義為基礎的範本，並命名為「Board of Directors」。WSS 會將自訂網站範本儲存為 .stp (網站範本) 檔案，放入網站範本庫，然後顯示於新 SharePoint 網站網頁的 [選取範本] 清單中，以方便之後的使用者根據此範本建立新網站。網站範本包含一系列的網站設定檔案，包括 .xml、.aspx、影像，以及其他將會壓縮成單一 .stp 檔案的檔案(.Stp 檔案的作用類似 .cab 檔案)。其中最重要的檔案是 Manifest.xml，它包含重要的資訊，例如網站結構和導覽、清單和組件庫、網頁組件位置、自訂清單定義，還有關於自訂網站範本基礎的網站定義。
應用程式範本：這些是 Windows SharePoint Services 網站範本，專為滿足特定商務處理流程或任務的需求而開發。他們是由 Microsoft 發行，可供 WSS 客戶免費下載。
自訂網站：這是使用者介面經過修改的 SharePoint 網站。
主版頁面：這是用來儲存預設版面配置資訊 (例如，橫幅、導覽控制項和其他功能表) 的區域，以便維持整體網站介面的一致性。
映像網頁：這些網頁的內容不儲存在 WSS 內容資料庫中，而是從網站定義檔案讀取。映像網頁並未經過自訂化。
非映像網頁：這些是已從網站定義檔案修改過的網頁，其內容儲存在 WSS 內容資料庫中。

伺服器升級之後 — 網站檢查
現在您已經到達升級工作流程的第 2 階段 (回頭參考 [圖 1])。您在此網站和範本升級階段將採取下列步驟：
  1. 開啟並檢查升級的網站。
  2. 套用預設的主版頁面。
  3. 修正新網站的功能和版面配置問題。
  4. 將已修正的網站儲存為新的 WSS 3.0 網站範本。
  5. 在伺服器上重新部署新的 WSS 3.0 網站範本。
  6. 從重新部署的網站範本建立網站。
  7. 開啟新網站並檢查其功能是否正常。
  8. 初始化清除程序。

重新設回網站定義
第一次開啟升級後的網站時，您會看到新網站仍然與 WSS 2.0 網站非常近似。若要讓網站外觀更接近 WSS 3.0 網站，您必須先重新設回新 WSS 3.0 網站的網站定義。只要網頁組件已經存放在網站定義網頁的網頁組件區域，執行這個動作將可修正大部分的版面配置問題，而且也不會喪失對網頁組件所做的變更。這個動作也會將預設的主版頁面套用到您所有的網站頁面。
主版頁面名副其實就是指儲存預設版面配置資訊 (例如，橫幅、導覽控制項和其他功能表) 的區域，以便維持一致的外觀。如此一來，只要在主版頁面變更設計，您的變更內容就會傳播至整個網站。藉由套用主版頁面，已升級的網站便會啟用所有 WSS 3.0 自有的功能。
雖然網站現在已經具備原始 WSS 3.0 網站的大致外觀與功能，但您可能還會發現一些問題區域，例如討論區、自訂網頁組件、超連結及主題。

修正問題
已升級和已自訂的網站範本可能會發生一些問題。此處提出一些常見問題和解決這些問題的一些簡單建議。
WSS 2.0 預設樣式表仍然套用至網站： 移除 SharePoint Designer 中舊的樣式表。
網頁組件遺失或位置錯誤： 使用 SharePoint Designer 移動或插入網頁組件。
網頁組件無法正常運作： 移除與 WSS 3.0 不相容的網頁組件，並連絡網頁組件開發人員以詢問是否有針對 WSS 3.0 環境建置的相對應網頁組件。
自訂清單和組件庫的外觀有問題： 儲存現有資料，然後重新建立自訂清單或組件庫，並匯入儲存的資料。
無法使用已啟用的 WSS 3.0 功能： 小組共同作業功能可能必須在 [網站功能] 下明確加以啟動。
超連結無法發揮作用： 硬式編碼的超連結可能需要手動更新。
主題被改變： 套用適當的 WSS 主題。

成功在即
整個流程即將接近尾聲，而問題也都獲得解決，現在該是執行網站最終確認的時候了。您應該將修正的網站儲存為 WSS 3.0 網站範本，執行新的 .stp 安裝和網站初始化 (您也可以在此使用便利的指令碼)，最後再開啟網站來確認所有問題均已解決，這些升級的網站和 .stps 現在已經準備好進一步發佈到您的工作環境中。

升級替代方案
使用本文所述的自動化工具與程序來升級範本有時候不一定是最理想的做法。如果您使用高度自訂化的協力廠商範本，自行升級範本可能非常困難，因此最好等待範本推出新版本。但是在其他情況下，在 WSS 3.0 上建立全新範本，並實作舊範本的功能可能是最佳選擇。

應用程式範本
WSS 2.0 與 WSS 3.0 有一組 Microsoft 開發的應用程式範本。新的 WSS 3.0 組合內含一些 WSS 2.0 應用程式範本的升級版本。如果您習慣使用這些範本，您可以將升級的 WSS 3.0 版本上載到 WSS 3.0 環境中。
如果您使用的是尚未升級為 WSS 3.0 的 WSS 2.0 應用程式範本，那麼解決方案加速器可提供您一組經過升級以用於 WSSS 3.0 環境的 WSS 2.0 應用程式範本。

結論
您會發現 Windows SharePoint Services 網站和範本的升級工具箱對於幫助您在 3.0 環境中保留 2.0 範本、網站和自訂內容非常實用。如需取得這個主題的詳細資訊和工具箱，請造訪「WSS 資源」資訊看板指示的網站。
在此特別感謝 Betty Houser 對本專欄與解決方案加速器的寶貴貢獻。
WSS 資源
  • 升級前掃描工具
  • Windows SharePoint Services 網站和範本的升級工具箱
  • 升級至 Windows SharePoint Services 3.0 版 (Windows SharePoint Services 3.0 技術庫)
  • 部署升級定義檔案和新網站定義

Luis Câmara Manoel 是 Microsoft Solution Accelerator 小組的程式經理，他已在 Microsoft 工作一年。Luis 過去曾在 Novell Inc 與 Volera (位於美國猶太州的普洛佛) 擔任專案及程式經理。您可以透過電子郵件與 Luis 連絡：luiscam@microsoft.com。
Peter Skjøtt Larsen 是 Microsoft Solution Accelerator 小組的產品經理，在 Microsoft 從事開發與行銷工作已逾四年。他之前曾為金融業、工程業和電信業開發用戶端與伺服器軟體。您可以透過電子郵件與 Peter 連絡：petela@microsoft.com。


 IT 產業: 精製商務計劃
IT 產業
精製商務計劃
Stephen Ibaraki

沒有充分的理由，就別貿然進行 IT 採購或投資，相信這對許多讀者來說已經不是什麼新聞。只為了擁有最新的運算創新而購買的的思維已經過時，不受拘束、不按牌理出牌的技術曾一度被認為是駕馭市場
和提高市場佔有率之道。然而，隨著網路公司泡沫化，這個概念已隨風而逝，也導致 IT 預算的裁減。當前的主流觀念是 IT 專案對企業必須要有真正的價值報酬才行。
預算緊縮之際，要怎麼提出正當的理由進行 IT 投資？答案就在於將商業個案與全面化統一技術解決方案作一個結合。這會撞擊出怎樣的火花呢？創造商業個案的重要元素為何？您要如何採用商務計劃模型提出充分理由施行 IT 專案？在商業個案內整合適當的技術解決方案時，應該朝什麼方向？我會提供您一些構想，讓您規劃出自己的個案。

打造成功企業
一個成功的企業或組織必須為員工、客戶、合作夥伴、供應商和業主等利害關係人創造出可量化的價值。此一價值必須清楚地定義與衡量，並不斷地修正以求改進。
在聯繫日益密切的世界裡，企業必須使內外網絡能進行有效率的協作，進而即時充分發揮互動關係。試問，服務、問題解答、產品推出，有誰願意枯等？因通訊中斷而發生專案延遲或停滯，又有誰樂見？隨著網際網路時代的到來，全球化益加白熱化，競爭可能遠在天邊，近在眼前。因此，企業必須在這個競爭激烈的環境內創造出自己的特色。組織要如何超群出眾呢？
不僅如此，企業還必須具備靈活的身段，持續觀察內外環境的變動，並能從一連串抉擇當中敏捷地選擇正確的道路並付諸實踐。透過這樣的行動，企業便能利用自己的優點，並改正自己的缺點，駕馭新商機。這些商機能迎來新市場、新客戶、新產品和新服務。企業也必須評估並減緩各種威脅，包括競爭力。把重點放在產能和效率的提升，並同時管理營運成本和風險，便能克服這些挑戰。
靈活度必須靠技術投資來培育，如此便能更快上市、立即反應客戶的需要、對競爭威脅防患未然、提高產能、改進效率，以及降低營運成本和風險。
截至目前，我討論了企業成功背後的驅動力，以及 IT 必須如何支援和配合這些驅動力。事實上，如果不朝這麼方向走，IT 就會成為與生產力毫無關係的經常開支，而無存在的理由！採商務計劃一途，將促成商業個案，確保企業成功。而企業的成功也是 IT 的成功。

打造商務計劃
將 IT 投資與日增的商業價值相關聯是很重要的 — 區別、降低成本、市場導向、協作和革新。商務計劃可滿足這項需要。
[圖 1] 概括了 IT 商務計劃的基本要素。您計劃的目標為何？任務和遠景陳述描述著企業目前的定位，以及未來的目標。確定您清楚地解釋 IT 專案如何支援這個整體目標。您需要詳述 IT 投資與企業目標之間的關聯，尤其是 IT 目標如何支持企業的策略方向 — 兩者必須契合。
Figure 1 商務計劃要素 (Close Figure 1)

要素 | 描述
目的 | 簡述投資與企業目標的關聯。
遠景 | 企業成果，以及 IT 將如何支持此目標。
任務 | 目前的業務，以及 IT 要如何強化此企業任務。
商機 | 鎖定的市場，以及商業價值。
商業模型 | IT 為獲取商機提供的產品和服務。
目標市場 | 要服務的客戶 (或潛在客戶)。
與 IT 整合 | 將產品和服務與技術資源配合
競爭性分析 | 競爭者清單，以及其優缺點。
SWOT 分析 | 優點、缺點、機會、威脅。
資源分析 | 現存的基礎結構，以及所需的資源預估。
IT 成功的衡量標準 | 可衡量的計劃層面。
財務評估 | 投資報酬的預計時間表。
在商機方面的陳述應該說明 IT 如何提供或支援新商機，以及它的報酬價值。具體的商業模型為何？企業提供什麼產品和服務以贏取收益？潛在的市場有多大，以及在 IT 上的改進可達成多少佔有率？IT 如何擴展這個商業模型？您應該解釋 IT 投資將如何在所述的商業模型內改善工作流程和商務程序 — 改善營運、降低成本、提高效率、實現協作、有效溝通、排程和傳訊。所有這些都可以降低成本或提高產能。別忘了將企業營運當中可透過 IT 達成的改革特別提出來。
您另外也應該談談目標市場。仔細思考您的 IT 計劃如何能促使企業提高現有目標市場或新市場的滲透力。討論會使用什麼樣的系統來提供產品和服務，以及 IT 支援如何能使服務更臻完善並傳達到目標市場。
這應該直接瞄準探討企業產品和服務如何與 IT 技術整合。哪些具體的產品和服務是整合和統一技術平台上的關鍵？IT 如何支援產品或服務？這如何與企業目標結合？這是您提議 IT 如何能改進服務管理、專案交付，以及內外關係的起點。IT 可促進企業變革 — 改進預期的服務等級、提供有效的監督、判定孰輕孰重、遵循法規、隱私權和安全性。您的商務計劃應該指出所有這些重點。
您的競爭力分析涵蓋企業競爭的全貌。您的競爭對象是誰？他們有什麼優缺點？指出您的競爭者如何採用技術，以及他們如何改進市場定位。IT 是否提供您的企業優於對手的競爭優勢？解釋 IT 如何改善您的企業靈活度、促進成長、加速進入新市場、支援新客戶、加強對現有客戶的服務等等。技術如何為您的企業提供區別和優勢？IT 如何提高競爭者進入的阻礙？
SWOT 分析會對與您的企業相關的優點、缺點、商機和威脅進行具體檢討。企業有什麼外部機會和威脅？IT 如何改善企業的內部優點，以善用外部的新機會？IT 將如何克服內部缺點和定位公司，並藉此創造新商機？如何透過 IT 投資減輕或舒緩外部威脅？
務必考量 IT 投資在實作之前、之後，以及實作期間的資源需求，其中包括人員、硬體和基礎結構。您能利用的現有知識或基礎結構為何，以及您需要為之編列多少預算？新的教育訓練和配備回本時間要多久？如果新投資能為具體商務計劃帶來額外的優點，也記得加以註明。
若要確知商務計劃是否達到您的預期，應該事先列出成功的衡量標準。計劃可以衡量的層面有哪些？您衡量成功的頻率為何，以及未有效支援目標的話要如何應對？如果遇到非預期的破壞力，有什麼備案？
商務計劃若缺少財務評估就不完整。整體擁有成本為何，以及要如何在新商機裡證明該項成本的用處？還有這些機會的價值何在？在何處以及用什麼方法實現投資報酬以達到企業成功？投資報酬的預計時間表為何？IT 如何透過營收與利潤的成長以及成本降低，來改進企業的財務目標？

邁向未來
您的計劃並不能保證真的能成功。但是花功夫構思和開發商務計劃，可讓您掌控未來。您將一一考量到所有可能的問題，進而修訂計劃或簡述防範措施。您對相關的成本和優點，包括如果不進行的話所付出的代價，也會有清楚的概念。最後一題，若少了衡量的標準，是無法確知您是成功還是慘敗。這些衡量標準在向主管展示您的計劃對企業發紅利之將特別有用。
如果想要交換關於 IT 產業的意見，建議前往 IT Managers Connection，網址是 blogs.technet.com/cdnitmanagers。Microsoft 網站上也有許多商務計劃的相關資源。Small Business Center 提供了關於撰寫商務計劃的教學課程，網址是 microsoft.com/smallbusiness/resources/startups/business_plans_ entities/how_to_write_a_business_plan.mspx，還有除了 2007 Microsoft Office System 上提供的範本之外，Office Online (office .microsoft.com/en-us/templates) 上也有許多商務計劃範本。

Stephen Ibaraki 是獲獎肯定的商業科技系教授，也是擁有超過 35 年商業和 IT 經驗的老手。他目前擔任國際網路專家協會 (Network Professional Association，NPA) 的副主席。若要連絡 Stephen，請前往 www.StephenIbaraki.com。


 The Cable Guy: Windows 中的 EAPHost
The Cable Guy
Windows 中的 EAPHost
Joseph Davies
此專欄中的 Windows Server "Longhorn" 測試版相關資訊有可能變更。

存取用戶端連上受保護的網路時，必須使用交涉的驗證方法，向驗證伺服器驗明正身。舉例來說，存取用戶端和驗證伺服器可能同意使用特定的密碼驗證通訊協定，例如 Microsoft Challenge Handshake 驗證
通訊協定第 2 版 (MS-CHAP v2)。不過，當存取用戶端和驗證伺服器使用內建及硬式編碼的驗證方法時，就很難加入新的通訊協定。
可延伸驗證通訊協定 (EAP) 是一種結構型架構，為常用的受保護網路存取技術 (例如以 IEEE 802.1X 為主的無線網路) 以及點對點通訊協定 (又稱 PPP，例如撥接和 VPN) 的驗證方法提供擴充性。EAP 並不同於 MS-CHAP v2 這種驗證方法，而是存取用戶端和驗證伺服器上的一種架構，允許網路廠商開發並輕易安裝新的驗證方法，也就是所謂的 EAP 方法。如需有關 EAP 的詳細背景資訊，請參閱 Microsoft EAP 網頁，網址是 microsoft.com/eap。
雖然 Microsoft® Windows® 自 Windows 2000 以來就一直支援 EAP，但是 Windows XP 和 Windows Server® 2003 中的 EAP 架構在 EAP 方法和請求者 (亦即可在特定類型的連結層上使用 EAP 的軟體元件) 方面卻有著擴充性的限制。Windows Vista™ 以及 Windows Server 日後版本 (代號 "Longhorn") 中的 EAPHost 架構解決了這些限制，讓協力網路廠商能夠更輕鬆地針對新請求者和 EAP 方法擴充 Windows。

Windows Server 2003 和 Windows XP 中的 EAP 支援
Windows Server 2003 和 Windows XP 將 EAP 用於以 802.1X 進行驗證的無線或有線連線，以及以 PPP 為主的連線，例如撥號或以 VPN 為主的遠端存取或站台間連線。換句話說，這些作業系統包含了遵守 RFC 2284 的 EAP 實作，也包含了 IEEE 802.1X 及 PPP 請求者 (Supplicant)。[圖 1] 顯示了 Windows XP 和 Windows Server 2003 的 EAP 及請求者架構。不過，要注意的是 Windows XP Service Pack2 (SP2) 與 Windows Server 2003 SP1 中的 EAP 實作並不支援 RFC 3748 (EAP 目前的網際網路標準) 及其他 EAP RFC。
[圖 1] Windows XP 及 Windows Server 2003 的 EAP 和請求者架構
[圖 1] Windows XP 及 Windows Server 2003 的 EAP 和請求者架構
EAP API 提供了在 Windows XP 和 Windows Server 2003 中擴充驗證的途徑。雖然協力廠商可開發和安裝新 EAP 方法，但內建 PPP 及 802.1X 請求者並無法使用所有已安裝的 EAP 方法。比方說，廠商可建立一套新的指紋掃描 EAP 驗證方法，但該方法可能無法用於無線連線。
由於內建請求者有限制，有些協力廠商軟體和硬體廠商便自行開發請求者，而這些請求者通常會取代及停用內建請求者和整個 EAP 架構。然而這種替代方案卻帶來了一些問題。首先，取代內建請求者和 EAP 架構會造成開發上的支出，而導致延遲。此外，假使企業客戶不自行開發請求者，便需要負擔授權以及安裝協力廠商產品的每基座成本。

EAPHost 的功能
EAPHost 提供以下新功能：
支援其他 EAP 方法： EAPHost 支援安裝及使用 EAP 登錄 (位於 www.iana.org/assignments/eap-numbers) 上所列各項 EAP 方法，以及其他常見的驗證方法，像是由 Cisco Systems, Inc. 所開發和提供的 Lightweight EAP (LEAP)。
網路探索： EAPHost 支援網路探索，如 RFC 4284 中所定義。
遵循 RFC 3748： EAPHost 遵守 EAP State Machine，並解決了 RFC 3748 中指定的許多安全性弱點。過去，請求者必須實作自己的狀態機器。此外，EAPHost 也支援如「擴充的 EAP 類型」(包括廠商特定 EAP 方法) 的功能。
EAP 方法並存： EAPHost 允許同一個 EAP 方法的多項實作同時存在。例如，您可以安裝並選擇 Microsoft 版本的受保護的 EAP (PEAP) 以及 Cisco Systems, Inc. 版本的 PEAP。
模組化請求者架構： EAPHost 支援一種模組化請求者架構，不需要像在舊版中得取代整個 EAP 實作，即可輕易地新增請求者。
對於 EAP 方法廠商，EAPHost 支援已針對 Windows XP 和 Windows Server 2003 開發的 EAP 方法，也支援一種比較簡單的方法針對 Windows Vista 和 Windows Server "Longhorn" 開發新 EAP 方法。EAPHost 同時還提供比較清楚的 EAP 類型分類，供內建 IEEE 802.1X 請求者使用。
對於請求者廠商，EAPHost 可支援其他新連結層的請求者。由於 EAPHost 已與網路存取保護 (NAP) 整合，因此新請求者並不需要感知 NAP。若要加入 NAP，新請求者只需要登錄一個連線識別元，以及一個回呼函數來通知請求者重新驗證便可。有關 NAP 的詳細資訊，請參閱本期《Technet Magzine》中 John Morello 的《安全性監控》專欄，以及 NAP 網頁，網址是 microsoft.com/nap。如需有關如何開發 EAP 方法或 EAPHost 的請求者的詳細資訊，請參閱＜可延伸驗證通訊協定主機＞，網址是 msdn2.microsoft.com/aa364249.aspx。

EAPHost 和 EAP 基礎結構架構
EAPHost 架構是由 EAPHost 的 EAP 基礎結構架構、EAP 對等 (驗證用戶端) 上的 EAPHost 架構，以及驗證伺服器上的 EAPHost 架構所組成。[圖 2] 顯示執行 Windows Vista 或 Windows Server "Longhorn" 的電腦上 EAPHost 的 EAP 基礎結構架構。在這些作業系統上，EAP 對等具有一個請求者層 (例如 802.1X 的內建請求者)、用於 EAP 對等的全新 EAPHost 架構 (方便請求者和 EAP 方法的通訊和管理)，以及一個 EAP 方法層來執行驗證。
[圖 2] EAPHost 的 EAP 基礎結構架構
[圖 2] EAPHost 的 EAP 基礎結構架構
Windows Server "Longhorn" 的驗證伺服器具有網路原則伺服器 (NPS)、用於驗證伺服器的全新 EAPHost 架構，以及一個 EAP 方法層。NPS 過去在 Windows Server 2003 中稱為網際網路驗證服務 (IAS)，它是一種遠端驗證撥入使用者服務 (RADIUS) 伺服器和 Proxy，也是 NAP 的原則伺服器。
EAP 對等上的請求者是使用一種像是 PPP 或 802.1X 的連結層技術，來收發 EAP 對等與傳遞驗證者 (一種網路存取伺服器，如無線存取點或遠端存取伺服器) 連結之間的 EAP 訊息。傳遞驗證者及驗證伺服器上的 NPS 是使用 RADIUS 來收發傳遞驗證者與 NPS 以 IP 為主的網路之間的 EAP 訊息。
在 EAP 對等與驗證伺服器交涉好使用特定的 EAP 方法後，邏輯通訊便由 EAP 對等與驗證伺服器上交涉的方法之間傳送的 EAP 訊息組成。
[圖 3] 顯示在執行 Windows Vista 或 Windows Server "Longhorn" 的 EAP 對等上的 EAPHost 架構。此架構包含請求者、EAPHost 元件、EAP 方法管理元件，以及 NAP 元件。
[圖 3] EAP 對等上的 EAPHost 架構
[圖 3] EAP 對等上的 EAPHost 架構
Windows Vista 和 Windows Server "Longhorn" 包括 802.1X 請求者，用於以 802.1X 為主的無線和有線連線。對於撥號或以 VPN 為主的遠端存取或站台間連線，則會調查 PPP 請求者是否有針對這兩種作業系統進一步發行更新。您也可以新增其他由協力廠商所開發的請求者。EAPHost API 允許請求者使用 EAP 進行連線。如需詳細資訊，請參閱 msdn2.microsoft.com/aa364249.aspx 上的文件。
EAPHost 元件包括 EAP Client State Machine/Protocol Validator，這會維護 EAP 對等狀態機器 (見 RFC 3748) 並驗證 EAP 訊息。另外也包括了 EAP Method Manager，這會管理不同的 EAP 方法 (不管它們與 EAPHost 相容與否)，並且有助於將 EAP 方法提供給請求者和服務使用。最後還有 EAP Library Manager，這可使 EAP 方法庫的載入和卸載作業更順當。
EAP 方法元件包括：
內建 EAP 方法。 其中包括 PEAP、EAP-傳輸層安全性 (TLS)，以及 EAP-MS-CHAP-V2。
兩個主 API。 這些裝載著非 EAPHost 相容的 EAP 方法 (舊版 EAP API)，以及與協力廠商 EAPHost 相容的 EAP 方法 (EAPHost Method API)。
舊版轉譯程式方法。 這會轉譯寫入舊版 EAP API 與 EAPHost Method API 之間非 EAPHost 相容的 EAP 方法。
EAP Method Proxy Manager . 這裝載了協力廠商 EAP 方法，無論它們是否與 EAPHost 相容。
EAP Method API 是用於與 EAPHost 相容之 EAP 方法的全新 API。EAP 方法會將 EAP Method API 中定義的 API 匯出。EAPHost 會載入 EAP 方法並呼叫匯出的 API 函數。
NAP 元件包括下列項目：
EAP NAP EC Messenger . 此元件可加速 EAPHost NAP 強制用戶端 (EC) 及 EAPHost 其他元件之間 NAP 相關資料的通訊，例如健康和事件的狀態。
EAPHost NAP EC . 這會與其他 NAP 元件互動，在 802.1X 驗證的連線不符合 NAP 系統健康需求時，提供健康驗證並強制限制存取。
NAP 代理程式。 這會維護用戶端目前的健康狀態，並加速已安裝 NAP EC 及 System Heath Agents (SHA) 層之間的通訊。每個 SHA 都是針對一或多項系統健康需求加以定義。
如 [圖 3] 所示，協力廠商可開發新請求者及與 EAPHost 相容的新 EAP 方法。您也可以使用現有針對 Windows Server 2003 或 Windows XP 開發的 EAP 方法。
[圖 4] 顯示執行 Windows Server "Longhorn" 和 NPS 之驗證伺服器上的 EAPHost 架構。此架構與支援 EAP 方法的 EAP 對等的架構是一樣的。驗證伺服器並沒有請求者，反而是具有 NPS，此 NPS 是利用 EAPHost API 來使用及設定 EAP 方法。在 EAP 元件當中，維護 EAP 驗證伺服器狀態機器與驗證傳入 EAP 訊息的工作是由 EAP Server State Machine/Protocol Validator 負責。
[圖 4] 驗證伺服器上的 EAPHost 架構
[圖 4] 驗證伺服器上的 EAPHost 架構
驗證伺服器上的 EAPHost 允許協力廠商軟體廠商開發和安裝與 EAPHost 相容的新 EAP 方法，並支援已針對 Windows XP 和 Windows Server 2003 開發的 EAP 方法。
針對 EAP 對等和驗證伺服器，EAPHost 還提供 EAPHost UI Proxy API (未顯示於 [圖 3] 及 [圖 4] 中)，與 EAPHost 相容的方法可用它來顯示需要使用者互動的對話方塊。EAPHost UI Proxy API 允許協力廠商加入他們自己的對話方塊，以獲得更順暢的使用者體驗。

結論
Windows Server "Longhonr" 和 Windows Vista 中的 EAPHost 更新了 Windows 內的 EAP 實作，以達最新的網際網路標準，並提供一套全新的模組化架構，以便透過 EAP 驗證方法和請求者來擴充 Windows。網路廠商不需要取代整個 Windows EAP 實作，便可透過開發寫入 EAPHost API 的新請求者，以及寫入 EAPHost Method API 的新驗證方法，來擴充 Windows 中現有的使用者體驗。EAPHost 同樣還支援針對 Windows Server 2003 及 Windows XP 開發的 EAP 方法。
適用於 Windows XP 的 EAPHost
Microsoft 預計針對 Windows XP SP2 發行一項更新，當中包含 EAPHost 架構、對 RFC 3748 的支援，以及用於有線 802.1X 連線且以 EAPHost 為主的請求者。有了此更新後，針對 Windows Vista 開發的 EAPHost 請求者也能用在 Windows XP SP2 上。有關這項更新的最新資訊，請參閱 NAP 產品小組的部落格，網址是 blogs.technet.com/nap。

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


 Windows PowerShell: WMI 連線
Windows PowerShell
WMI 連線
Don Jones

在 VBScript 的國度裡，我最信賴的其中一項技術是 Windows Management Instrumentation，或稱 WMI。有趣的是，Windows PowerShell 與 WMI 的關係相當深厚，不單就技術觀點而言，Windows PowerShell 的架構設計師 Jeffrey Snover，也曾是創造
Wmic.exe 的要角之一。Wmic.exe 是 Windows Server® 2003 時代用來與 WMI 搭配使用的命令列工具。它在許多方面是 Windows PowerShell™ 的前驅，因為它們的運作方式有點類似 (如需 WMIC 的詳細資訊，請參閱 John Kelbley 在 2006 年 7 月期《TechNet Magazine》內發表的文章，網址為 microsoft.com/technet/technetmag/issues/2006/09/WMIData)。
跟此命令介面的其餘功能一樣，Windows PowerShell 也是以相同一致、物件為基礎的方式提供 WMI 支援。這使得 WMI 學習和使用起來比早期的技術 (如 VBScript) 還要簡單許多 — 特別是在臨機操作的情況下。

WMI 入門
如果您讀過指令碼書籍和文章，幾乎處處都會提到 WMI。然而，真正使用 WMI 時又很容易陷入困境，因為您會忘了它實際上是怎麼建置的 — 知道它的建置方式對於了解它在 Windows PowerShell 中如何運作尤為重要。
WMI 主要是一個類別組織化的系統，這些類別代表 Windows® 作業系統及其他 Windows 軟硬體產品的管理資訊。類別其實不過是某些特定軟體或硬體元件擁有的屬性和功能的抽象描述。比方說，邏輯磁碟類別描述的類別可能包含序號、固定儲存容量、可用的容量等等。另一方面，描述 Windows 服務的類別可能會指出該服務具有名稱，可以被啟動和停止，並說明它目前的狀態等等。
在 WMI 中，類別代表 WMI 可以管理的所有內容。假如 WMI 沒有某元件的類別，就無法管理該元件。Microsoft 在 msdn2.microsoft.com/aa394554.aspx 記錄核心 Windows WMI 類別，其他產品 — 例如網際網路資訊服務、SQL Server™ — 則是個別記載其 WMI 類別。
因為類別很多，WMI 於是將它們組織成命名空間階層。例如，包含核心 Windows OS 類別的命名空間稱為 root\cimv2，而 Microsoft IIS 6.0 則是將其類別存放在 root\MicrosoftIISv2 中。為了方便，root\cimv2 命名空間即是 WMI 預設的命名空間，這是由 Windows PowerShell 共用的設定，以便與這些核心類別搭配使用。
「例項」是類別實際發生的次數。舉例來說，若您的電腦有兩個邏輯磁碟，您就會有兩個 Win32_LogicalDisk 類別的例項。如果電腦上有 50 個服務正在執行，WMI 會看到 50 個 Win32_Service 類別的例項。使用 WMI 基本上等於是要求 WMI 給您一或多個例項，然後檢查該些例項的屬性以找出您所需的管理資訊，或執行這些例項的方法以進行管理變更，例如啟動或停止服務。
WMI 是採用主從式架構。Windows 自 Windows 2000 以後的每個版本都內建有 WMI (後續版本擴增了可用的類別數)，這表示您有現成的 WMI 用戶端和 WMI 伺服器可用。使用 WMI 時，實際上是傳送要求給任何您感興趣的電腦上執行的 WMI 服務。該 WMI 服務會擷取您指定的 WMI 例項，並將它們傳回給您使用。這也正是 Windows PowerShell 派上用場的時候，它會簡化要求例項，取回例項，以及使用例項的程序。

取得 WMI 物件
WMI 類別例項廣義來說是指物件，因此可以解釋在 Windows PowerShell 中擷取該些例項的方法是 Get-WMIObject cmdlet。此 cmdlet 的別名 gwmi 很好記，我會在大多數的範例中用到它。最簡單的用法是，直接指定您要擷取的 WMI 類別名稱，然後就悠哉等著看結果 (見 [圖 1])。執行 gwmi win32_service 時，Windows PowerShell 連線到我的本機電腦上的 WMI 服務 (因為我沒有指定其他電腦)，並連線到 root\cimv2 命名空間 (因為我沒有指定其他命名空間)。Windows PowerShell 擷取指定類別的所有例項，另外因為我沒有告訴它要對這些例項採取什麼動作，因此 Windows PowerShell 將它們轉換成文字表示。換言之，Windows PowerShell 取得這些物件並產生了一些我 (身為人類) 看得懂的文字。
[圖 1] 執行 gwmi win32_service 時，Windows PowerShell 以可讀的文字格式傳回指定類別的所有例項
[圖 1] 執行 gwmi win32_service 時，Windows PowerShell 以可讀的文字格式傳回指定類別的所有例項
具體地說，Windows PowerShell 是藉著讀取和顯示選定類別屬性的名稱和值，將 WMI 物件轉換成文字。對於 Win32_Service 類別，它會選取一組六個的屬性。
Windows PowerShell 實際上可透過這種方式將任何物件轉換成文字。它選擇顯示的屬性絕大部分是根據 Windows PowerShell 安裝資料夾中的一組 .format.pslxml 檔案定義而成。這些格式定義檔案已經過 Microsoft 數位簽署，因此建議您不要變更這些檔案，不過您可提供自己的格式化檔案 (我在將來的專欄中會更深入討論此主題)。
gwmi cmdlet 可幫助您探索電腦以找出可用的類別。比如，執行 gwmi –namespace "root\cimv2" –list 可提供該命名空間當中完整的類別清單。不過要記住，您電腦上的類別只有在電腦是由您管理時才相關，如果您管理的是遠端電腦，那麼應該了解該系統上可用的類別。若要這麼做，您可以使用 gwmi 的 –computer 參數連線到遠端電腦。比如，gwmi –namespace "root\cimv2" –list –computer ServerA 會列出名為 ServerA 之遠端電腦上 \root\cinv2 命名空間內的所有類別。

遠端 WMI
在 1.0 版的 Windows PowerShell 中，gwmi 可算是唯一直接支援遠端管理的 cmdlet。這主要是因為遠端控制已內建至基礎 WMI 架構。而且因為 Windows PowerShell 僅利用該現有架構，所以受限於該架構的安全性功能。以下為範例：
C:\> gwmi -namespace “root\cimv2” -computer
mediaserver -list
Get-WmiObject : Access is denied. (Exception
from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:5
+ gwmi <<<< -namespace “root\cimv2” -computer
mediaserver -list
PS C:\>
在此例中，我試著連線到一台我沒有存取權限的遠端電腦 — 叫做 MediaServer。身為系統管理員，我應該有權使用此電腦的 WMI 服務，但可能我的本機工作站的憑證權限不足。比方說，我可能登入了另一個不受信任的網域，或者我可能是以低權限的帳戶登入。幸虧 gwmi 支援 –credential 參數，可讓我為 WMI 連線指定另外一組使用者憑證。您在下面會看到一個非常簡單的範例：
gwmi win32_service –credential mydomain\administrator –computer mediaserver
我的憑證 — 具體來說是我的使用者名稱 — 是以 DOMAIN\Username 的格式提供。
請注意這裡沒有地方可以輸入密碼 — Windows PowerShell 會另外提示。Windows PowerShell 是故意不在命令列上提供輸入密碼的管道，因為這麼做便可讓您將密碼寫死到指令碼檔案中，這無疑會提高安全性風險。不過，還有另外一種方法可以使用這個 –credential 參數，就是事先建立一個叫做 PSCredential 的憑證物件。關鍵是 Get-Credential cmdlet：
$cred = get-credential mydomain\administrator
當我執行此命令時，還是會收到要對應密碼的提示。不過這一次，建立的憑證物件是存放在 $cred 變數中。如果查看 $cred 的內容，會看到名稱而不是密碼：
PS C:\> $cred

UserName
--------
mydomain\adminstrator
我接著就可以任意重複使用該憑證物件，多少次都可以：
gwmi win32_service –credential $cred –computer mediaserver
透過預先定義一個可重複使用的憑證物件，簡化了 WMI 連線至遠端電腦的重複作業。可惜無用武之地，因為 Get-WMIObject cmdlet 目前並不像 VBScript 一樣支援指定驗證等級 (亦稱為模擬)。請參閱 msdn2.microsoft.com/aa389290.aspx 以取得詳細資訊。

自動探索
我最喜歡 Windows PowerShell 的一點是它不會使事情過於無趣。我向您說明過 Windows PowerShell 針對我查詢的 Win32_Service 類別只挑選一組屬性。但命令介面仍可存取所有屬性，甚至可以告訴您這是什麼屬性。如果想這麼做，只要將物件輸送到 Get-Member cmdlet (或是它的別名 gm) 即可，如 [圖 2] 所示。
[圖 2] 將物件輸送到 Get-Member cmdlet 會告訴您可存取哪些方法和屬性
[圖 2] 將物件輸送到 Get-Member cmdlet 會告訴您可存取哪些方法和屬性
除了屬性外，命令介面還會列出可用的方法，這表示不需要說明文件也可以了解類別的作用。我可以看到類別自己提供變更例項設定、暫停服務、停止服務等方法。
要利用這些方法，或顯示其他屬性，最簡單的方法通常是將例項放入變數中：
$server = gwmi win32_operatingsystem
$server.reboot()
這個範例將擷取 Win32_OperatingSystem 類別唯一可用的例項 (此類別在每台電腦只有一個例項)，並將它儲存到 $server 變數中。之後便會使用 $server 變數來存取例項的 Reboot 方法，以重新啟動電腦。使用這個方法時要小心！

高階查詢語言
如果您在 VBScript 或其他技術下用過 WMI，可能已經習慣使用以 WQL (WMI 查詢語言) 寫成的查詢來擷取 WMI 類別例項。它的語法類似 SQL，因此更容易擷取特定例項 (例如特定服務) 而不是擷取指定類別的所有例項。幸運的是，gwmi 也可讓您指定查詢，如下所示：
gwmi –query “select * from win32_service where name=’alerter’”
gwmi 這樣的語法 (這是在 Windows PowerShell 正式發行之前新增的) 非常實用，而且非常方便您遷移針對其他用途開發的複雜 WMI 查詢。另外，Windows PowerShell 向來都會在傳回豐富物件時，一同傳回這些物件本身的屬性和方法，讓您徹底運用 WMI 的管理威力。

與 WMI 一同邁進
WMI 會繼續針對未來的 Windows 版本進行開發，新添類別和功能，而且還會持續加入 Microsoft 新產品中。雖然大多數 Microsoft 產品都還沒發行專門以 Windows PowerShell 為基礎建置的版本，但是其 WMI 連線能力儼然是使現今的 Windows PowerShell 這麼實用最大的優點之一。
我所介紹的 WMI 只不過是皮毛而已，不過，仍希望這足以激發您探索 Windows PowerShell 的興趣，並自行研究其他可用的功能。

Don Jones 是 SAPIEN Technologies 的專案與服務總監，也是《Windows PowerShell:TFM》(SAPIEN Press) 的作者之一。請透過 Don 的網站與他連絡：www.ScriptingAnswers.com。


 嗨，Scripting Guy！: 百花怒放，對話方塊蹦蹦跳，春神來了。
嗨，Scripting Guy！
百花怒放，對話方塊蹦蹦跳，春神來了。
Microsoft Scripting Guys

啊，春天終於降臨了。 我們也是心神俱爽。熬過一個降雨量破紀錄，夾雜著冰暴、雪暴和風暴的寒冬 — 有場暴風把大樹吹倒在其中一名 Scripting Guy 的後院，只差幾吋就砸到房子，嚇得 Scripting Dog 躲到沙發後面 — 春天終於來了！讓我們在夏天較暖和的太平洋西北雨來到之前，好好享受一點點清涼的雨水。
望著窗外的小雨時，我們想到這種天氣正適合來點小小的指令碼探險，討論一下 HTML 應用程式 (HTA)。說到探險，我們可是認真的。在這裡將不多作介紹，我們假設您已經知道什麼是 HTA，以及如何建立它。如果您還不知道，應該看看 指令碼中心上的 HTA Developers Center。您特別應該閱讀 HTAs for Beginners 部份中的兩篇文章。讀完後，就可以趕上我們的進度，回到這來。
在本專欄中，我們將向您說明如何建立對話方塊。除此之外，還會示範如何在主要 HTA 和對話方塊之間來回傳遞資訊。沒錯，春天裡的新鮮空氣真的讓我們野心勃勃，不是嗎？趁現在多多享受吧。
您可能已經知道，對話方塊有兩種：強制回應和非強制回應。差別在於當開啟強制回應對話方塊時，要等到關閉開啟的對話方塊後，才能從該對話方塊回到主視窗。當您開啟非強制回應對話方塊時，則可在視窗間來回移動。然而，假如您關閉主視窗的話，非強制回應對話方塊也會跟著關閉起來。
建立強制回應對話方塊的方法跟建立非強制回應對話方塊沒什麼兩樣。唯一不同的是建立強制回應對話方塊時，是呼叫 ShowModalDialog 函數，而建立非強制回應對話方塊時，則是呼叫 ShowModelessDialog 函數。這兩種函數都接受相同的參數。讓我們開始先看看一個簡單的 HTA，它會開啟一個強制回應對話方塊 (見 [圖 1])。
Figure 1 簡單的初學對話方塊 (Close Figure 1)
<html>
<head>
<title>Modal Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”MainModal”>
</head>

<script language=”VBScript”>
Sub ShowDialog
 intReturn = _
    ShowModalDialog(“modaldialog.hta”)
 textbox.Value = intReturn
End Sub
</script>

<body>
<button onclick=”ShowDialog”>
 Show Dialog Box</button> <p>
<input type=”text” name=”textbox”>
</body>
</html>
我們在這裡建立了一個標題為 Modal Example 的 HTA。在 HTA 的 <body> 區域，我們新增了兩個元件：一個標示為 Show Dialog Box 的按鈕，以及一個名為 textbox 的文字方塊，兩個都可以在 [圖 2] 中看到。按下按鈕後，ShowDialog 副程式便會執行。
[圖 2] 實際的 HTA 強制回應對話方塊
[圖 2] 實際的 HTA 強制回應對話方塊
ShowDialog 副程式很簡單，我們呼叫 ShowModalDialog 函數，將要顯示為強制回應對話方塊的 HTA 檔案名稱當作參數來傳遞，在本例中即 modaldialog.hta (我們假設 modaldialog.hta 與此 HTA 是位在同一個資料夾中。如果不是，您必須在此處包含完整的檔案路徑)。
我們也從 ShowModalDialog 擷取一個傳回值 (intReturn)，並將此值顯示在文字方塊中。您等一下會看到我們是如何取得此傳回值的。要注意的一個重點是，對 ShowModalDialog 的呼叫要等到關閉強制回應對話方塊後，才會傳回。這表示傳回值要等到對話方塊關閉之後才會指派給文字方塊。
讓我們看一下 modaldialog.hta，也就是呼叫 HTA 所開啟的對話方塊 (見 [圖 3])。在這個 HTA 中，我們建立了兩個元件：一個名為 listbox 的清單方塊，和一個標示為 OK 的按鈕，如 [圖 4] 所示。我們已新增四個項目到清單方塊中，分別標示為 Option 1、Option 2，依此類推，並且也指派了相對應的值 (從 1 到 4) 給這些項目。按下 OK 按鈕後，CloseWindows 副程式便會執行。
Figure 3 modaldialog.hta (Close Figure 3)
<html>
<head>
<title>Modal Dialog Box</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModalDialog”>
</head>

<script language=”VBScript”>
Sub CloseWindow
  window.returnValue = listbox.Value
  window.Close
End Sub
</script>

<body>
<select size=”3” name=”listbox”>
 <option value=”1”>Option 1</option>
 <option value=”2”>Option 2</option>
 <option value=”3”>Option 3</option>
 <option value=”4”>Option 4</option>
</select>
<p>
<input type=”button” id=”idBtn” value=”OK” onclick=”CloseWindow”>
</body>
</html>
[圖 4] 代表強制回應對話方塊的 HTA
[圖 4] 代表強制回應對話方塊的 HTA
CloseWindowsg 副程式很簡單，我們所做的第一件事是讀取選定清單方塊中的項目值，並將該值指派給 window.returnValue 屬性。舉例來說，如果使用者選擇 Option 2，則會指派 2 的值給 window.returnValue。我們接著呼叫 window.Close 方法來關閉對話方塊。
控制權此時返回到主 HTA。還記得對 ShowModalDialog 的呼叫：
intReturn = _
  ShowModalDialog(“modaldialog.hta”)
指派給 intReturn 的傳回值正是我們在對話方塊 HTA 中指派給 window.returnValue 的值。因此要是在對話方塊選擇 Option 2，也就是指派 2 的值給 window.returnValue，則 intReturn 將等於 2，下列一行程式碼向文字方塊顯示該值：
textbox.Value = intReturn
看過了如何從對話方塊取得值之後，讓我們來瞧瞧如何將值傳給對話方塊。這一次我們將使用非強制回應對話方塊 (見 [圖 5])，但請記住，強制回應和非強制回應的運作方式一樣，因此同一程序也可以用於強制回應對話方塊。
Figure 5 轉成非強制回應 (Close Figure 5)
<html>
<head>
<title>Modeless Example</title>
<HTA:APPLICATION
  APPLICATIONNAME=”ModelessMain”>
</head>

<script language=”VBScript”>
Sub ShowDialog
  intReturn = _
    window.ShowModelessDialog _
    (“modelessdialog.hta”, _
    lstServers.Value, _
    “dialogHeight:400px;dialogWidth:300px”)
End Sub
</script>

<body>
<select size=”1” name=”lstServers”>
 <option value=”server1”>Server1</option>
 <option value=”server2”>Server2</option>
 <option value=”server3”>Server3</option>
 <option value=”server4”>Server4</option>
</select>
<p>
<input type=”button” value=”Retrieve Processes” onclick=”ShowDialog”>
</body>
</html>
[圖 7] 傳遞給非強制回應對話方塊的資料
[圖 7] 傳遞給非強制回應對話方塊的資料
這次我們建立了一個名為 lstServers 的下拉式清單方塊 (您可以分辨出這是下拉清單，因為大小等於 1)。另外還有一個標示為 Retrieve Processes 的按鈕。按下按鈕後，ShowDialog 副程式便會執行。ShowDialog 副程式只有一行，也就是對 window.ShowModelessDialog 函數的呼叫，如下所示：
intReturn = _
  window.ShowModelessDialog _
  (“modelessdialog.hta”, _
  lstServers.Value, _
  “dialogHeight:400px;dialogWidth:300px”)
我們傳給這個函數的第一個參數是要在對話方塊中執行的 HTA 名稱，在本例中即 modelessdialog.hta。第二個參數是清單方塊的 Value 屬性。請記住，Value 屬性包含清單方塊中選定選項的值。因此如果使用者從清單方塊中選取 Server2，則 Value 將是 server2。這個參數是我們將資訊傳遞給對話方塊的媒介 (如果您想要傳遞多個值，可在此參數中將它們當作陣列或集合來傳遞)。
等會兒就會看到對話方塊如何擷取此參數中的值。不過先注意我們要放入第三個參數：
“dialogHeight:400px;dialogWidth:300px”
這個參數包含一個字串，指定我們要對話方塊具有的高度和寬度。在本例中，指定了 400 像素的高度 (400px) 和 300 像素的寬度。跟在強制回應的範例中看到的一樣，我們可以把這個參數留空，而對話方塊將顯示成電腦的預設大小。
現在讓我們看一下 modelessdialog.hta (在 [圖 6] 中)，看看對話方塊如何讀取傳遞給它的值。
Figure 6 modelessdialog.hta (Close Figure 6)
<html>
<head>
<title>Modeless Dialog</title>
<HTA:APPLICATION
  APPLICATIONNAME=”Processes”>
</head>

<script language=”VBScript”>
Sub window_onLoad
  strComputer = window.dialogArguments
  Set objWMIService = GetObject(“winmgmts:” _
    & “{impersonationLevel=impersonate}!\\” _
    & strComputer & “\root\cimv2”)
  Set colProcesses = objWMIService.ExecQuery   _
    (“Select * from Win32_Process”)

  strHTML = “<h1>” & strComputer & “</h1><p>”
  For Each objProcess in colProcesses
    strHTML = strHTML & objProcess.Name & _
       “<br>”
  Next

  DataArea.InnerHTML = strHTML
End Sub
</script>

<body>
<span id=”DataArea”></span>
</body>
</html>
在此 HTA 中，我們唯一指定的元件是一個跨距，包含對話方塊整個區域。在指令碼區段中，我們定義了一個 window_onLoad 副程式。這個副程式將在 HTA 一開啟 (在本例中，是在對 ShowModelessDialog 呼叫時) 後馬上執行。看一下此副程式中的第一行：
strComputer = window.dialogArguments
我們把屬性 window.dialogArguments 的內容指派給變數 strComputer。您覺得這個屬性裡面是什麼？看吧，您也從冬眠甦醒，迎接春天的到來囉。沒錯，正是在對 ShowModelessDialog 的呼叫的第二個參數中傳遞的值。假如在主視窗中選取 Server2，strComputer 現在就會包含值 server2。
副程式其餘的部分不外是從 strComputer 擷取所有的處理序，並將它們顯示在跨距區域中。您可以在 [圖 7] 中看到此項作業的結果。
您現在有整個夏天可以玩 HTA 對話方塊了，高興吧！當然啦，除非您剛好住在南半球等著過冬，又像我們一樣在這邊碰到那麼多次停電的話，可能就開心不太起來了。

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


 Exchange 問答集: OWA 逾時、Cmdlet 疑難排解及其他
Exchange 問答集
OWA 逾時、Cmdlet 疑難排解及其他
KC Lemson and Nino Bilic

問：我們最近剛從 Exchange Server 2003 遷移到 Exchange Server 2007，收到了一些抱怨，因為受限的使用者在登入 OWA 2007 時選取 [這是私人電腦] 選項後，發生 Outlook® Web Access (OWA) 逾時。有什麼適當的 Exchange 管理命令介面命令可以用來驗證私人電腦的逾時嗎？
答：讓我們倒帶一下，首先，我會解釋為什麼有私人電腦和公用電腦兩種不同的選項 (見 [圖 1])，並說明這些選項的行為有何不同。這些選項的目的是要提供使用者一種管道來告知 Exchange 需要哪種層級的安全性 — 比方說在機場的公共資訊站登入 OWA，或是使用家用電腦登入。Exchange 系統管理員可選擇以不同的方式對待這些工作階段類型。舉例而言，系統管理員可使已驗證的工作階段在公用機器上比在私人電腦上更快逾時，前者可能是幾分鐘內，而後者最長可達三天。系統管理員也可以根據使用者的選項分別設定其他設定。例如，系統管理員可將 SharePoint® 文件庫和 Windows® 檔案共用設定成只允許私人登入才能存取。這當然還是得靠使用者指定正確的選項。假如系統管理員不信任使用者可以做出正確的決定，他們可以為每個選項設定相同的逾時值和其他設定選項。
[圖 1] 公用和私人電腦工作階段類型允許有不同的逾時設定和其他設定選項
[圖 1] 公用和私人電腦工作階段類型允許有不同的逾時設定和其他設定選項
所提到的選項是自 Exchange 2003 延續而來，也就是 OWA 首度採用表單型驗證的產品 (源由：表單型驗證的首次實作，部分是由一名傑出的程式經理設計的。我不透漏她的身分，但是我可以告訴您她之後為《Technet Magazine》編寫雙月刊專欄，因而名利雙收)。
此設定實際上是存放在登錄中，但既然 Windows PowerShell™ 有個介面可以更新登錄，您可以使用 Exchange 管理命令介面來進行此設定。下面的範例在使用者於登入期間選擇私人電腦選項時，將逾時設為 1440 分鐘，即一天：
set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout
-value 1440 -type dword
既然設定是在登錄中，您當然可以使用 regedit 自行更新機碼，若這麼做請選擇：
#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>
不管是哪種方法，都需要重新啟動 IIS，以確保 OWA 採用新設定。您應該可以透過選取 [開始] | [執行]，然後執行 iisreset /noforce 進行此動作。

問：我們鼓勵辦公室裡每個使用完整 MAPI Outlook 用戶端的人，都將所有不迫切需要的項目封存到個人資料夾 (.pst) 檔案。但是使用者之後從家裡登入 Outlook Web Access 時並無法使用封存的項目。要如何透過 OWA 介面使這些 .pst 檔案可用呢？
答：很抱歉，OWA 並不支援存取 .pst 檔案。OWA 是從無到有建置成線上專用的用戶端。我們下了很多功夫來確保不會在本機電腦上留下任何個人資料 — 這包括像是首先在 Exchange 2003 推出的安全登出機制，以及 Exchange 2007 中的 WebReady 文件檢視等功能，以確保附件的快取副本不會留在硬碟上。因此從 OWA 存取 .pst 檔案與我們期望它成為容易部署的線上專用用戶端的目標背道而馳。
所以我們想要討論的是 .pst 一般用途的有趣案例。我們去年秋天碰到了一個客戶，他的使用者擁有約 200MB 的信箱配額，而且幾乎每名使用者都有至少一個 .pst 檔案。因為這家公司有項原則：以最不費力的方式清除和取代使用者機器，所以要求所有使用者將他們的 .pst 檔案存放在網路共用上。該網路共用則是由中央系統備份。
首先，從網路共用存取 .pst 檔案有已知的問題。就跟 OWA 最初是設計成專供線上使用一樣，.pst 檔案當初主要是要存放在本機位置上。不管您的網路有多棒，都會發生延遲和其他問題，而遠端存放資料 (同時還要供使用者存取) 可能問題連連。
其次，這家公司因為不希望將所有資料都放在 Exchange 裡 — 因為這樣就得負責備份所有該些資料 — 因此信箱配額有點小 (我們承認我們的公司信箱約有 2GB 是很奢侈的享受)。不過，讓使用者使用 .pst 檔案將資料存放在備份起來的網路共用，系統管理員並沒有因此省下麻煩。事實上，反而可能還因各種因素而產生更多工作，例如：多重 .pst 檔案無法儲存單一例項；與 .pst 檔案問題相關的支援工程師成本 (像是忘記密碼和一般的網路消失；在病毒攻擊後難以清除 .pst 檔案中的訊息；在發生法律案件時難以探索 .pst 檔案中的訊息；維護不同備份系統的負荷等等。
所以我們力勸您考慮組態決策所產生的所有成本。您可能會發現所有的成本加總起來後，另外一種組態可能還比較適當。

問：我使用 Exchange 管理命令介面的命令時有問題，它就是不能正常運作。是哪裡出問題？
答：我們沒辦法回答這個問題，不過我們可以告訴您若要獲得最佳的協助 — 無論從何處獲得 — 您都應該使用 Windows PowerShell 中一個叫做 start-transcript 的內建 cmdlet 來記錄您所嘗試的命令及所得的結果。這樣可方便您之後將確切的詳細資料貼入電子郵件訊息、部落格張貼或論壇的問題中。
開啟 Exchange 管理命令介面工作階段，然後鍵入 start-transcript，如 [圖 2] 中所示。Exchange 管理命令介面會自動開始將未來所有的命令記錄到文字檔中，如 [圖 3] 中所示 (別擔心，應用程式會告訴您文字檔的位置)。若要停止記錄，只需要鍵入 stop-transcript 即可。
[圖 2] 使用 start-transcript cmdlet 來記錄您使用的命令及其結果
[圖 2] 使用 start-transcript cmdlet 來記錄您使用的命令及其結果
[圖 3] Windows PowerShell 將您使用的命令存成副本，並存放在 .txt 檔案中
[圖 3] Windows PowerShell 將您使用的命令存成副本，並存放在 .txt 檔案中
擁有一份完整的清單記下您使用過的命令及所傳回的結果，對任何疑難排解您的問題的人都有極大的幫助。但是在將記錄分享給您不認識或信任的人之前，請確定先檢查看看有沒有傳回任何機密或敏感的資料。

問：我看到 Exchange 2007 安裝程式在根網域中建立了一個新的組織單位 (OU)，叫做 Microsoft Exchange 安全性群組，當中有五個新的 Exchange 2007 安全性群組。我們可以將這些群組移到不同的 OU 嗎？那要是移到不同的網域呢？
答：此問題所指的是在 Active Directory 準備階段的期間，於根網域中建立的五個萬用安全性群組 (USG)。這些群組分別為：
  • Exchange Organization Administrators
  • Exchange Recipient Administrators
  • Exchange View-Only Administrators
  • Exchange Servers
  • ExchangeLegacyInterop
在 Exchange 2000 和 Exchange 2003 的時代，移動預設安全性群組 (Exchange Domain Servers 和 Exchange Enterprise Servers) 的能力有限。比較恰當的說法是，您要移動它們可以，但是過程中會破壞一些項目 (有關此問題的詳細資料，請參考 support.microsoft.com/kb/260914)。所以這實在相當有限。
而在 Exchange 2007 中，情況就不太一樣了。您可移動預設的五個群組，將它們移到相同網域內不同的 OU，或是一併移到不同的網域。
萬一「弄丟」了這五個群組，而且不知道將它們移到哪裡去了 — 忘了是哪個 OU 或網域 — 您永遠可以檢查下列容器中另一個 WellKnownObjects 屬性的值：
CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com
隨著群組被四處移動，它們的位置也會在此屬性上跟著更新，讓您永遠有辦法找出群組所在。不賴吧！

問：我在網域中找到一個叫做「Exchange Install Domain Servers」的通用安全性群組，這是做什麼用的？
答：您顯然是很注意您的 Active Directory®。沒錯，每個裝有 Exchnage 2007 伺服器的網域中都會有一個稱為 Exchange Install Domain Servers 的群組。這個群組是建立在 Microsoft Exchange System Objects (MESO) OU 中。如果您仔細查看這個群組，會看到它被當成根網域的 Exchange Servers 群組 (這是萬用安全性群組) 的成員。
簡單地說，如果您是在其中一個子網域中執行 Exchange 2007 安裝程式的話，Exchange Install Domain Servers 這個群組可用來應付可能冗長的 Active Directory 複寫週期。舉例來說，假設您有一個稱為 Root 的根網域，一個稱為 Child 的子網域，以及一個 Child 的子網域，稱為 Grandchild。(我們知道，這樣的命名法太高明了！您想您猜得出我們的密碼是什麼嗎？)
若要開始在此組織中設定 Exchange 2007，您首先必須延伸架構，並準備您的根網域。這會建立我們在上個答案中所討論的五個原始 USG。
接下來，假設您需要在 Grandchild 網域中執行安裝程式。為了能夠在本機網域中啟動 Exchange 2007 服務，安裝程式放了一個 Exchange 2007 機器的電腦帳戶到根網域的 Exchange Servers 群組中。但是由於您現在位於 Grandchild 網域中，Exchange Servers 群組的成員資格可能需要花點時間進行複寫。
Exchange Servers 是一個萬用群組，而其成員資格會複寫整個樹系。因為複寫可能發生延遲，所以 Grandchild 網域中的安裝程式有可能無法啟動服務，原因是權限並未在安裝程式完成之時複寫完畢。這也是為什麼在網域中設定第一部 Exchange 2007 伺服器時，它會在本機網域中建立 Exchange Install Domain Servers 群組的原因了。
在安裝過程中，Exchange 電腦帳戶將成為該群組的成員。即使 Exchange Servers 群組的成員資格還未從根網域複寫，此群組的成員資格也會提供足夠的權限，以便在安裝程式結束時啟動服務。請注意本機網域複寫通常比網域間的複寫還快。

問：Exchange 2007 說明文件告訴我在針對 Exchange 2007 延伸架構之前，應該以 /PrepareLegacyExchangePermissions 參數執行安裝程式，為什麼？(還有這個參數的名稱沒事取這麼長做什麼？)
答：我們很高興聽到您在執行安裝程式之前閱讀說明文件。您覺得寫得如何呢？
名字這麼長的 /PrepareLegacyExchangePermissions (簡稱 /pl) 這個參數，是要賦予 Exchange 2000 和 Exchange 2003 收件者更新服務 (RUS) 權限以寫入 Exchange Information 和 Personal Information 屬性集。在 Exchange 2007 架構延伸的過程中，有幾個屬性 (例如 Proxy Addresses) 會從 Active Directory Public Information 屬性集移入 Exchange Information 屬性集。在預設情況下，Exchange 2000 和 Exchange 2003 RUS 並沒有寫入 Exchange Information 屬性集的權限。而在實際情況下，這表示若您先執行 Exchange 2007 架構延伸，就會中斷 Exchange 2000 和 Exchange 2003 RUS，因為它們將無法為任何新收件者加上戳記！(如果您想要進一步了解這些屬性集，請前往我們的部落格，網址是 msexchangeteam.com)。
因此，在為 Exchange 2007 擴充架構之前先執行 /pl 參數是很重要的。您另外還應該確定將這項變更複寫至所有包含 Exchange 2000 或 Exchange 2003 收件者的網域 (以便這些網域存有 RUS)。如果在稍後新增網域至樹系中，而您需要在當中放入 Exchange 2000 或 Exchange 2003 RUS 的話，也應該在這些網域中執行 /pl 參數。
針對該點，當您第一次執行 /pl 參數時，若以具備 Enterprise Admin 權限的帳戶來執行參數，您的日子可能會快活許多。之後根網域的安裝程式會識別出哪些網域上面需要執行 /pl，它會在所有這些網域上執行 /pl 參數。如果您不是使用 Enterprise Admin 帳戶，就需要個別針對各個網域使用 Domain Admin 來執行 /pl 參數。好在 Exchange 2007 說明文件中有指出所有的權限需求。
最後，您問到這個參數的名稱沒事取這麼長做什麼，試試很快地念 /PrepareLegacyExchangePermissions 三次。
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
我們有想過把這改成 /Prepare-LegacyExchangePermissionsWOWThisIsaReallyLongname，但是我們還是決定使用較短也較好記的 /PrepareLegacyExchangePermissions。
好啦，開玩笑的啦。不過您還是可以使用長度短得多的 /pl。這是實話 — 我們發誓！

KC Lemson 是 Exchange Server 小組的使用者體驗經理 (User Experience Manager)。她的閒暇時間都花在等候電子郵件，告訴她應該把小孩的大學基金投資在哪裡。
Nino Bilic 是 Exchange Server 的技術組長，總想著平常每天可以打多少場《最後一戰》。


 安全性監控: 網路存取保護
安全性監控
網路存取保護
John Morello
此專欄中的 Windows Server "Longhorn" 測試版相關資訊有可能變更。

當今的企業組織，無論規模大小，都面臨著一項巨大的安全性威脅，也就是周邊網路背後的惡意裝置。無論組織為防杜來自網際網路的外部威脅把自己包得密不通風，安全性還是可能會因為善意的員工不經意接觸
蠕蟲或特洛伊木馬程式所傳輸的惡意程式碼而危險重重。這種情況在中小型組織的 IT 環境中更是尤為如此，這些員工可能拿筆電作個人和商業用途，而且網路存取控制技術通常過於昂貴和複雜而沒有部署。也正因如此，這些組織往往為停機付出慘痛的代價，因此對抗這些威脅可說是至關重要。
Microsoft 推出的網路存取保護 (NAP) 技術方便各種規模的組織在加入網路時主動檢查電腦的健康狀況，並確保整個連線過程中保持良好狀態。NAP 為組織提供富彈性、以原則為主的架構，防止員工、廠商和訪客有意或無意地將不合格的電腦帶入他們的網路，起到保護組織的目的。NAP 是根據四大基本要件建置而成：原則驗證、隔離、矯正和保持合格性。

NAP 概觀
NAP 提供的第一項核心服務是原則驗證。原則驗證是一項過程，NAP 會藉著一組由系統管理員定義的規則評估系統，藉此替系統的健康狀態分級。
IT 系統管理員會指定一組原則元素，在電腦嘗試連上網路時供 NAP 比較之用。符合原則元素的電腦被視為健康，而那些沒有通過一或多項檢查 (由系統管理員指定) 的電腦則被視為不健康。這些原則可以檢查一些像是防毒和防間諜軟體是否存在、主機防火牆是否為作用中，以及電腦是否遺漏任何安全性更新等。此外，由於 NAP 建置上是可擴充的，因此獨立軟體廠商可以針對 NAP 建立自己的外掛程式，以便進行應用程式特定的檢查。
NAP 提供的另外一個核心服務是網路連線限制。視系統管理員定義的原則而定，NAP 可將機器設成不同的網路連線狀態。舉例來說，假如機器因遺漏重大安全性更新而被視為不健康，NAP 就可以將該部機器放入隔離網路，使該機器與環境的其他部分隔離，直到恢復健康狀態為止。少了 NAP，不健康的用戶端就能熬無阻礙地存取組織的網路。機器要是錯過更新而有漏洞，此時要是惡意程式碼趁虛而入，就能大肆感染其他的網路。[圖 1] 讓您對該架構有基本的了解。
[圖 1] NAP 的一般架構
[圖 1] NAP 的一般架構
不過，光是制連線，仍不能算是處理不健康機器的有效方法 (畢竟，您的使用者還得工作)。因此 NAP 另外還提供了矯正服務，讓不健康且受到隔離的機器能夠在不需要系統管理員介入的情況下，修正它們的健康問題。在上例中，限制的網路只允許不健康的電腦存取安裝遺漏更新所需的特定網路資源，例如公司的 Windows Server® Update Services (WSUS) 電腦。換句話說，在設有 NAP 的情況下，不健康的機器僅限存取可使它恢復健康的網路資源，除非痊癒，否則這台機器無法將流量傳送給網路其餘的部分。
NAP 最後一大要件是保持合格，這會在電腦連線到網路的整段期間，而不只是初次連線時，強制這些健康原則。從本文的例子中，想想電腦自行更新並痊癒後 (因而獲得無限制的網路存取權) 會發生什麼事。假如該電腦稍後因為一些情況 (比方說 Windows 防火牆停用) 而不再合格，NAP 便會自動重隔離該機器。NAP 也允許系統管理員設定自動矯正，也就是不合格狀態在不需要其他使用者介入的情況下便會自動修正，即使是在完成初次網路連線後過了很久一段時間亦然。
NAP 可採用幾項不同的技術來控制網路存取。如果組織採用管理式網路交換器，可使用 802.1X 在網路硬體層提供以連接埠為基礎的存取控制。NAP 亦可使用 IPsec 強制的功能，以便透過 IPsec 關聯建立安全網路，並在實體網路上分層處理。透過 IPsec 強制，NAP 能藉著動態建立並移除 IPsec 引擎所使用的認證，來控制對安全區域的存取。最後，NAP 可提供 DHCP 強制。在本例中，DHCP 伺服器可為不健康的用戶端提供限制集區的 IP 租約。這些租約會使用不同的 DNS 尾碼和 IP 路由，來控制受限用戶端能夠存取哪些資源。
NAP 伺服器元件採下一版 Windows Server (代號 "Longhorn") 建置而成，特別是它已內建至全新的網路原則伺服器 (NPS)，這是網際網路驗證服務經過大幅增強的後繼版本。對於利用 802.1X 強制的組織來說，網路硬體必須支援 802.1X 驗證和動態 VLAN 功能 (「NAP 資源」資訊看板中的 NAP 合作夥伴網站提供更多關於特定硬體廠商的詳細資料)。對於 DHCP 強制，則需要有啟用 NAP 的 DHCP 服務，例如 Windows Server "Longhorn" 當中提供的 DHCP 服務。在用戶端上，NAP 支援已內建至 Windows Vista™。NAP 支援也可作為 Windows® XP 的附加元件取得，當中隨附了一個新的 802.1X 請求者，可啟用 Windows XP 上的 802.1X 強制。
此外，NAP 不但已整合至 Windows 資訊安全中心，也已整合至協力廠商健康狀態代理程式，以報告健康資訊。因此，NAP 得以根據透過資訊安全中心公開的資料來訂定原則驗證決策。
NAP 這套企業級原則管理解決方案功能相當強大，光是一篇文章不足以介紹所有功能和部署策略。礙於篇幅，本文將著重於中小型組織的部署，這些組織中的 IT 員工所要處理的工作相當繁多，而且簡化 NAP 部署將快速提高部署所需的投資報酬率。不過，其中許多經驗分享和綜合指導方針同樣適用其他的組織和 NAP 設計，不受規模和種類限制。在此一強調，本文的逐步解說範例並非步驟式的安裝指南，而重點概述如何成功部署以 DHCP 為主的 NAP。如需更詳盡的安裝指南，請參閱「NAP 資源」資訊看板的連結。

Contoso 的問題集
為方便讀者更深入了解 NAP 如何解決中小型組織的獨特需要，我們以 Contoso, Inc. 為例。Contoso 是一家虛構的中型公司，在三處主要辦公室有 250 部電腦。它的行動員工比例很高，而且有許多使用者從遠端客戶地點透過電信或連線連回主辦公室。因此，約有一半的電腦是膝上型電腦和 Tablet PC。就跟許多組織一樣，Contoso 也隨著工作人力的行動化而面臨著與日俱增的安全性挑戰。有些配有可攜式電腦的使用者從客戶網站或家庭辦公室染上惡意程式碼，並將受感染的電腦連至 Contoso 內部網路。
Contoso 也為了使這些遠端電腦保持最新狀態而費盡心思。使用者往往在客戶地點工作了很長一段時間才回到 Contoso 辦公室。在這種情況下，他們的機器經常好幾個月未進行安全性更新，因此提高了 Contoso 的網路上其他機器的整體風險。Contoso 需要一套解決方案，確保連上其網路的所有機器 (無論是遠端或本機連線) 都受到保護而且健康狀況無虞。
NAP 要如何協助 Contoso 達到此目標呢？回想一下 NAP 的主要要件。透過原則驗證，NAP 可以檢查所有連線到 Contoso 網路的機器的健康狀態。原則驗證能判斷機器是否有符合時宜的防毒簽名檔，以及是否已安裝全部的安全性更新。只要 NAP 原則驗證常式判定機器不健康，NAP 便可限制這種主機的網路連線，以便確保離站使用且染上惡意程式碼的機器不會把問題散播到網路的其他部分。NAP 會限制不健康電腦的連線能力，規定讓它只能存取由 Contoso 的 IT 系統管理員所定義的矯正資源。比如，不健康電腦可存取 Contoso WSUS 伺服器和裝載防毒簽名檔的伺服器。最後，NAP 可確保在機器恢復正常後，仍然持續保持健康狀態。在這個例子中，如果電子通勤族經由 VPN 使用不健康的主機，而且使用者關閉主機防火牆的話，NAP 便會自動矯正該問題。防火牆一停用，NAP 基礎結構會馬上將電腦隔離，重新啟用防火牆，重新評估機器的健康，並且在判定它是健康的之後，再將該機器挪回無限制的網路上。NAP 的四大要件直接滿足了 Contoso 動態及行動運算環境的重要安全性需求。

NAP 設計
對於許多中小型組織來說，NAP 的 DHCP 強制是在實作上是快速簡單的選擇。這是因為 DHCP 強制不需要進行額外的網路變更，DHCP 和 NPS 背後也不需要額外的服務。雖然 IPsec 和 802.1X 強制選項比較有彈性，但它們需要對網路進行額外的變更，並且需要部署新服務。對於複雜度較低的環境而言，使用 DHCP 的成本較低，也不需要經常操作，同時又能兼顧 NAP 的各大優點。
Contoso 的環境採用執行 Windows Server "Longhorn" 的電腦作為 NAP 部署核心。由於 NAP 需要有 Windows Server "Longhorn" NPS，因此無法在舊版的 Windows Server 上進行部署。NAP 的 DHCP 強制也需要有 Windows Server "Longhorn" DHCP 伺服器。為了整併服務，Contoso 可同時將 NPS 和 DHCP 部署在同一台伺服器，它們可相安無事地並存。因此，Contoso 的基本 NAP 伺服器基礎結構相當簡單：一部同時執行原則和強制元件的 Windows Server "Longhorn" 電腦。
在用戶端上，Contoso 執行 Windows Vista 的電腦已具備支援 NAP 所需的功能。執行 Windows Vista 的機器上唯一得變更的用戶端設定就只有啟用 NAP 功能，這可透過群組原則來完成。Contoso 中執行 Windows XP 的電腦則必須另外安裝 NAP 用戶端套件。執行 Windows XP 且已加入網域的電腦，預設會停用 Windows 資訊安全中心功能。假如 NAP 原則使用資訊安全中心的狀態資訊，評估電腦的健康狀況，就必須執行資訊安全中心好讓 NAP 正常運作。因此，對於執行 Windows XP 的 Contoso 電腦，系統管理員必須利用群組原則來開啟資訊安全中心。除了上述變更，並不需要其他任何動作，即可讓用戶端支援 NAP。

Contoso NAP 部署
在 Contoso 進行稍早討論的必要群組原則變更後，部署 NAP 的下一步便是安裝 Windows Server "Longhorn"。Windows Server "Longhorn" 的所有版本都包括必要的 NAP 元件，因此 Contoso 可以使用最符合需求的版本。一旦完成安裝後，IT 系統管理員將使用「伺服器管理員」工具將角色新增至機器。Contoso 所使用的 DHCP 強制需要 Network Access Services 及 DHCP Server 這兩個角色。新增角色精靈將協助系統管理員處理各項依存性，以及加入伺服器所需的其他任何功能。新增角色之後，Contoso 就可以開始設定 NAP。
Contoso 的系統管理員將使用「伺服器管理員」工具存取 Microsoft Management Console (MMC) DHCP 嵌入式管理單元，並加入一個新領域。設定 Windows Server "Longhorn" DHCP 伺服器將會取代其服務的 IP 區段上的所有現有 DHCP 服務。建好領域並根據 Contoso 的網路填入正確選項之後，就必須啟用其上的 NAP。這是在領域屬性的 [網路存取保護] 索引標籤完成 (見 [圖 2])。
[圖 2] 啟用 NAP
[圖 2] 啟用 NAP
NAP 會在相同領域內限制或無限制的網路存取間切換機器，方法是使用全新的 NAP 使用者類別領域選項。這一組特殊的領域選項 (包括 DNS 伺服器、預設 DNS 尾碼等) 是在提供租約給不健康的用戶端時使用。譬如，提供給健康用戶端的預設 DNS 是含 "contoso.com" 尾碼，而提供給不健康用戶端的則會有 "restricted.contoso.com" 的尾碼，如 [圖 3] 所示。DHCP 領域選項一旦設定好之後，就可設定網路原則伺服器並建立規則。
[圖 3] 限制存取
[圖 3] 限制存取
NPS 原則是由四大元件構成。System Health Validators (SHV) 定義要執行哪些檢查來評估電腦的健康狀態。Remediation Servers Groups 則包含允許不健康機器存取的系統清單 (比如 WSUS)，以恢復健康。而 System Health Validator Template 元件是用來定義實際的健康狀態。比方說，Contoso 可以把通過 Windows Security SHV 的機器視為「合格」機器，但該用戶端不一定要通過防毒廠商另外提供的 SHV 檢查。最後，這些元件都會整合至網路原則組合中，此組合包含了根據其健康狀態來判斷要怎麼處置機器的邏輯。
System Health Validators 是 NAP 代理程式檢查並將狀態報告給 NPS 的項目清單。預設的 NAP 部署中含有 Windows SHV，這會連到 Windows 資訊安全中心，並允許 NAP 檢查所有透過資源安全中心報告的安全性元件的狀態。安全性元件包括有防火牆、防毒、自動更新和反間諜元件。
前文提到 NAP 的可擴充設計，並允許協力廠商建立自己的 SHV，以提供個別元件更詳盡的檢查 (詳細資訊請參閱 microsoft.com/windowsserver2003/partners/nappartners.mspx)。例如，Windows Security SHV 允許 NAP 檢查防毒程式是否已啟用並處於最新狀態。不過，關於 Windows Security SHV 並無法更詳盡地執行有關防毒程式的檢查，諸如掃描機器的頻率，或其他應用程式特定選項等。但防毒軟體廠商可建立與自家應用程式連結更深的 SHV，並開放比預設 Windows SHV 更多的應用程式特定檢查。此 SHV 可與 Windows SHV 和任何其他可能存在的 SHV 共同搭配使用，單一 NAP 部署可同時使用許多 SHV (見 [圖 4])。
[圖 4] Windows Security SHV
[圖 4] Windows Security SHV
Remediation Server Groups 是用來指定不健康機器能夠存取哪些資源。這些群組通常包括一些像是 WSUS 或 Systems Management Server (SMS) 伺服器，還有防毒更新伺服器等資源。重要的是，除了包括伺服器本身之外，還得包括用戶端尋找它們所用的名稱解析伺服器。因為 Contoso 的用戶端都是經由群組原則設定成使用稱為 wsus.contoso.com 的伺服器進行自動更新，所以 Remediation Servers Group 不僅必須包括 WSUS 伺服器的 IP 位址，也必須將用戶端用來將完整網域名稱 (FQDN) 轉換成數字式 IP 位址的 DNS 伺服器涵蓋進來。若不允許存取這些名稱解析資源 (視用戶端的設定，可能是 DNS 和 WINS 兩者)，用戶端將無法解析矯正資源的 IP 位址，也就無法存取它們。[圖 5] 顯示此範例的 DNS 和 IP 設定。
[圖 5] DNS 名稱和 IP 位址
[圖 5] DNS 名稱和 IP 位址
System Health Validator Templates 是用來定義健康電腦的構成要素。Validator Templates 會取得 SHV 檢查結果，並根據機器是否通過一或多項檢查，來指出它的健康與否 (見 [圖 6])。
[圖 6] 合格性檢查
[圖 6] 合格性檢查
在 Contoso 環境中 (就跟許多中小型部署一樣)，只定義了兩種狀態。健康的電腦是通過所有 SHV 檢查的電腦，而不合格機器則是未通過一或多項檢查的機器。組織在必要時可選擇實作更複雜的邏輯 (例如，根據角色、部門、地理位置等為使用者建立不同的合格標準)，但須注意，此舉可能會使辨別問題和疑難排解更加困難而且費時。
所有這些元件都是透過網路原則結合在一起。網路原則是由系統管理員定義，並且會指示 NPS 如何根據其健康狀態來對待電腦。系統會從上而下評估這些原則 (如 NPS UI 所示)，並在比對到原則規則時立即停止作業。
再次強調，簡單是 Contoso 網路的目標，所有只需要幾個原則。第一個是 Compliant-FullAccess 原則。此原則會指出通過所有 SHV 檢查的機器將獲得無限制的網路存取權。換句話說，當機器的健康狀態經過評估，通過所有檢查後，NPS 即會指示 DHCP 伺服器以「標準」領域選項提供該機器 IP 租約。這個 Compliant-FullAccess 原則一般應該列在處理順序的最前面，因為大部分的機器都應該通過合格性檢查。先列出此原則可減少 NPS 上的處理負載和時間。
下一個使用的原則是 Noncompliant-Restricted。在 Contoso 環境中，未通過一或多項 SHV 檢查 (因此符合「不合格系統健康狀態檢查範本 (Noncompliant System Health Validation Template)」) 的任何機器都會對應到此原則。當符合此原則時，NPS 便會指示 DHCP 伺服器以特殊的 NAP「限制」領域選項提供用戶端 IP 租約。這使得不合格電腦只能存取在 Contoso 的 Remediation Servers Group 中定義的資源。
使用的第三個原則是回溯相容性。還記得 Windows XP 及之後版本的作業系統預設都提供 NAP 支援 (不過獨立軟體廠商也可針對舊版 Windows 及非 Windows 作業系統開發 NAP 用戶端)？假如 Contoso 仍在生產環境中使用 Windows 2000，那麼可建立一項規則 (在我們的例子中即 Downlevel-Full-Access)，授與非 NAP 感知的機器一般網路存取權 (假設是 DHCP 伺服器的預設領域選項)。此原則應該最後再評估，而且只有在下層機器需要網路存取時才需要建立和啟用 (見 [圖 7])。
[圖 7] 下層機器的存取設定
[圖 7] 下層機器的存取設定
若是 Contoso 的某些資源位在不具備或永遠無法提供 NAP 功能的網路上 (如印表機或其他硬體) 怎麼辦？此外，要是 Contoso 的機器具備 NAP 功能，但暫時或永遠不希望接受原則檢查的話呢？豁免這些機器一個簡單的方法就是藉由 MAC 位址來完成。若要提供管道讓這些機器略過 NAP 檢查，Contoso 系統管理員可建立一條新原則 (Exempt by MAC)，來授與完整網路存取權。此原則使用一項條件陳述式：撥號站台 ID 的 RADIUS 用戶端屬性會比對需要略過 NAP 的裝置的 MAC 位址。當有機器符合此原則陳述式時，NPS 就會指示 DHCP 以「標準」領域選項提供租約。此原則應列在評估順序的最前面，以縮短整體的處理時間，並減輕 NPS 上的負載。符合此原則的機器並不需要任何 SHV 評估，因此就沒有必要在 NPS 上挪出檢查它們的週期 (見 [圖 8])。
[圖 8] 忽略特定機器
[圖 8] 忽略特定機器
結合使用這些原則將有助於確保 Contoso 的 NPS 迅速且準確地評估連線至網路的機器。這些原則還能在必要時為下層電腦和裝置提供豁免，或在具備 NAP 功能的裝置暫時需要略過評估時提供豁免。

結論
NAP 包含了一組廣泛的技術，尤其是在比較複雜的案例下，需要有通盤的計劃和測試。本文重點是放在比較單純的案例，NAP 網站上有各種規模部署的詳盡指南。該網站還包括 802.1X 和 IPsec 強制技術的規劃協助，這對企業來說往往比 DHCP 強制更適合。
NAP 提供了一個有效且可擴充的平台，可用來評估連線到網路的電腦的健康狀態。對於中小型組織來說，實作與管理成本均低的 DHCP 強制可以提供許多優點。NAP 是 Windows Server "Longhorn" 的主要優點，並且可幫助您的組織改進安全性和合格性。
NAP 資源
  • 網路存取保護
  • 在測試實驗室中針對網路存取保護設定動態主機設定通訊協定強制
  • 網路存取保護合作夥伴
  • 《網路存取保護簡介》白皮書網路廣播

John Morello 已在 Microsoft 服務六年，擔任過各種職責。身為資深的顧問的他曾為美國財星前百大 (Fortune 100) 企業、民間企業和國防部門設計安全解決方案。他目前擔任 Windows Server 小組的資深專案經理，負責開發隨處存取技術。


 桌面檔案: 重新認識 Windows 部署服務
桌面檔案
重新認識 Windows 部署服務
Wes Miller

在最近幾次的專欄中，我已經討論過有關 Windows Vista 和下一版 Windows Server (代碼 "Longhorn") 的部署技術。變化是軟體業界不變的真理，所以我要介紹一些有關 Windows 部署服務 (WDS) 的更新資訊，此 WDS 將會隨附在
Windows Server® "Longhorn" 中。另外，我也收集了過去幾個月來從讀者以及從我參與的討論中所提出的問題，我會撥出一部份的專欄內容來探討幾個關於 ImageX、WDS 和 Windows® PE 的問題。

新功能和增強功能
在 WDS 的原始構想中，本來是打算讓以附加元件的形式隨附在 Windows Server 2003 中的功能要與之後隨 Windows Server "Longhorn" 發行的功能版本幾乎一樣。但是，Windows Server "Longhorn" 的 WDS 開發小組孜孜不倦地開發了三大新功能，而即將問世的伺服器平台將會獨享這三項 WDS 功能。
這些新功能分別為多點傳送部署、增強型 TFTP 下載效能以及適用於 x64 系統的可延伸韌體介面 (EFI) 網路開機支援。這些功能對於 WDS 使用者與系統管理員有極大的助益，我們現在就來逐一剖析這些新功能。不過在此強調，Windows Server 2003 未來所有的 WDS 版本都不會排入這些新功能。

多點傳送
早在我加入 Windows 小組之前，多點傳送早已經是遠端安裝服務 (RIS) 的熱門話題，也是最常要求的功能，甚至是一般的 Windows 部署也有這方面的需求。 曾經使用過協力廠商部署技術的客戶都深知多點傳送部署的能耐。在 Microsoft 中，有些特定專案的部署技術 (尤其是 Automated Deployment Services [ADS]) 曾經實作多點傳送，但從來不曾為 OEM 與企業部署提供此功能。每當我與 OEM 或企業客戶討論部署議題時，多點傳送依舊是最常被要求的功能。
多點傳送的主要優點在於它可讓多部電腦同時接收通訊。也就是說，傳送者 (此處為 WDS 伺服器) 只傳送一次要通訊的資訊。每個用戶端接著都必須從頭到尾接聽整個通訊，才能接收此通訊。由於所有用戶端都特地同時接聽單一的網路位址，因此可收到雙倍效益：網路不會因多個用戶端執行相同工作而壅塞，因而能提高部署速度；而且每個用戶端都接聽單一資料流，因而可降低網路飽和度。
長久以來，多點傳送本身的基礎結構一直是它的缺點。想像一下很多人小時候玩過的「聽電話」遊戲。您大概還記得玩法：
  1. 對旁邊的人說一句話。
  2. 排在第二位的這個人聽到這句話。
  3. 第二個人向第三個人重複同一句話。
  4. 就這樣不斷輪流直到每個人都玩過。
那麼，多點傳送本身的問題在於，為了讓四個人完整地聽到您說的句子，這些人必須同時在同一個房間且聽到您說的話。如果這時第五個人走進房裡，除非他知道要立即豎起耳朵，否則您必須向他重述整個句子。
多點傳送的運作方式大同小異。您透過網路傳送一個二進位映像 (通常是以磁區為主的磁碟映像)。如果需要接收此映像的用戶端並未在映像一開始廣播時立即準備接聽，那麼所有這些用戶端通常必須在佇列中等候。更麻煩的是，如果用戶端基於網路或效能問題而遺失太多資料，他們只能選擇完全退出通訊佇列 (因為無法確定是否接收到完整的磁碟映像)，或者減緩整個群組的速度來配合發生問題的用戶端的需求。同時部署幾百個系統時，如果想要設計多點傳送系統，就必須花很多功夫來確保所有用戶端都同時啟動，還得確定單一用戶端的速度問題不會影響其他用戶端。
WDS 小組將情況完全改觀，WDS 小組開發的新多點傳送引擎採用以檔案為基礎的 Windows Imaging Format (WIM) 基礎結構，可提供某些獨一無二的功能。大多數協力廠商多點傳送軟體也可以執行相同的分段式多點傳送部署案例，但是 WDS 的多點傳送解決方案提供您更多優勢。
首先，用戶端電腦可以在傳輸過程中隨時加入。多點傳送廣播是包含檔案資料流的「循環配置資源」廣播，它會持續廣播直到滿足每部用戶端電腦的需求為止。因此，用戶端何時上線就不會構成問題。他們會接聽 WDS 伺服器，當伺服器完成映像檔廣播時，又會從頭開始。如果用戶端錯失某個檔案，只要繼續接聽直到檔案再次出現即可 (您可以想成是旋轉木馬)。
其次，這個通訊協定是全新的，它具備阻塞控制與流量控制，也就是說，它可以在生產網路上順利運作，而不會干擾現有的網路通訊。讓很多網路系統管理員擔心的是，原本是為了增加通訊效率而啟用此通訊協定，但卻造成很多流量湧入網路的反效果，而這也是某些多點傳送解決方案的實際案例。
第三，此解決方案的設計是獨立於 WDS 和 Active Directory®。這表示您不需要有 Active Directory 或作用中的 WDS 實作才能利用這個解決方案。ImageX 多點傳送可以獨立執行，因此適用於更多方案。多點傳送用戶端是一種命令列應用程式，可以在 Windows Server "Longhorn" (與其相關的 Windows PE 版本)、Windows Vista™、Windows XP Service Pack 2 (SP2) 或最近發行的 Windows Server 2003 SP2 中執行。
WDS MMC 與 WDSUtil 應用程式中包含新的管理工作以便安裝及設定多點傳送。WDS 用戶端的使用者介面也做了一些改變，以指出正在使用多點傳送。
WDS 管理工具可讓系統管理員監視到用戶端的即時傳輸進度 (包括移除傳輸中的用戶端)。此管理工具也提供完整的記錄和報告功能，這表示系統管理員現在有辦法記錄安裝日誌 — RIS 完全缺乏這項能力。
適用於 Windows Server "Longhorn" 的 WDS 中的多點傳送可說是最近我聽過最振奮人心的消息之一。很高興 WDS 小組終於能夠滿足經常詢問這項功能的客戶要求，而且相信 OEM 和企業客戶都能順利部署此解決方案。

增強型 TFTP 下載效能
簡單式檔案傳輸通訊協定 (TFTP) 是 Pre-boot eXecution Environment (PXE) 的主要元件，而 PXE 本身則是 RIS 和眼前的 WDS 的骨幹。TFTP 雀屏中選的原因並非考量到其網路效率或穩定性，主要是因為這個通訊協定特別小 (沒有狀態、非安全且以 UDP 為基礎)，因此它可以封裝在開機 ROM 中，而系統需要此開機 ROM 才能從網路進行 PXE 開機。
針對 Windows Server "Longhorn" 的 TFTP Daemon (TFTPD) 經過徹底重新編寫後能大幅改進 TFTP 下載時間 (由於這項重大增強功能，現在所有 WDS 部署都是以從 RAM 映像執行的 Windows PE 開機為基礎)。對於希望改善在 Windows Server 2003 上從 RIS 或 WDS 下載 Windows PE 之效能的客戶而言，這是一個好消息。
隨著個人電腦產業逐漸從普遍的 BIOS (今日 x86 個人電腦的骨幹) 轉移成 EFI，Microsoft 已經備妥 WDS 來搭配使用 EFI (而非 BIOS) 開機的新興 x64 伺服器系統。其內含功能可讓 x64 用戶端系統從 WDS 伺服器執行 PXE 開機。

問題
既然手邊有了 WDS 更新資訊，我打算在本專欄的後半部回答一些來自電子郵件或從最近的線上討論內容看到的問題，相信我的讀者也同樣會對這些問題感到興趣。

問：可以在非 DHCP 環境中使用 WDS 嗎？我的網路不允許使用 DHCP 或 PXE 流量。.
答：您可以在非 DHCP 環境中使用 WDS，但是此解決方案將無法擴充，因為您必須為想要支援的每個安裝建立唯一 CD 媒體 (各自包含唯一的 IP 位址)。使用 DVD 媒體進行安裝是比較明智的做法。如果您只能在沒有 DHCP 的情況下透過 WDS 進行安裝，請執行下列步驟：
  1. 以靜態定義的伺服器建立一個 WDS Discover 映像 (這會指向您將從該處安裝的特定 WDS 伺服器)。
  2. 允許 DHCP 流量進入此目的地 WDS 伺服器上的連接埠 4011。即使並非使用 DHCP，您還是必須允許此動作，因為 WDS 用戶端是透過這種方式與伺服器信號交換。
  3. 使用靜態 IP 位址而非 DHCP 來建立唯一的 Windows PE 媒體。
請注意，這個解決方案很費事，因為用戶端媒體必須是唯一的，以免發生 IP 位址衝突，而且您必須指向網路上的特定 WDS 伺服器。PXE (本身以 DHCP 做為基礎) 是 WDS 的骨幹，由此可知為何 WDS 在環境允許 DHCP 的情況下運作較順暢。

問：我希望從 PXE 伺服器而非 WDS 進行 Windows PE 2.0 的 PXE 開機。要怎麼做呢？
答：support.microsoft.com/kb/926172 上的知識庫文件針對如何從非 WDS PXE 伺服器執行 Windows PE 2.0 提供一些指引，但是請注意，Microsoft 對此的支援有限。

問：什麼是 BDD？Windows Automated Installation Kit (WAIK) 是其中一部份嗎？
答：BDD (全名是 Business Desktop Deployment Solution Accelerator) 是一個指導架構，教導您透過可管理及可重現的方式來使用 Windows 部署工具 (例如 WAIK)。WAIK 不是直接隸屬於 BDD，但是 BDD 可以為您集合所有尚未安裝的必要工具 (包括 WAIK) 以進行安裝。因此從技術上來說，BDD 不包含 WAIK，但是它的確需要 WAIK 才能運作。如需有關 BDD 的詳細資訊，請造訪 microsoft.com/desktopdeployment。

問：從哪裡可以取得適用於我 Windows Server 2003 系統的 WDS？
答：WDS 隨附在 WDS 目錄的 WAIK 下載中 (請參閱 go.microsoft.com/fwlink/?LinkId=85377)。

問：如何將 Windows PE 2.0 設定為以靜態 IP 位址開機，並支援 DNS 設定？
答：若要設定靜態 IP，請使用 [圖 1] 中的 unattend.xml 範例，然後將它放到 CD、USB 快閃磁碟或其他可開機媒體，以便能夠選取它。如果您也希望具備 DNS 支援，還需要執行下列命令：
Figure 1 [圖 1] unattend.xml (Close Figure 1)
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
 <settings pass="windowsPE">
  <component
   name="Microsoft-Windows-TCPIP"
   processorArchitecture="x86"
   publicKeyToken="31bf3856ad364e35"
   language="neutral"
   versionScope="nonSxS"
   xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Interfaces>
    <Interface wcm:action="add">
     <Ipv4Settings>
      <DhcpEnabled>false</DhcpEnabled>
     </Ipv4Settings>
     <UnicastIpAddresses>
      <IpAddress wcm:action="add" wcm:keyValue="1">
       192.168.0.1</IpAddress>
     </UnicastIpAddresses>
     <Identifier>Local Area Connection</Identifier>
    </Interface>
   </Interfaces>
  </component>
 </settings>
<cpi:offlineImage
 cpi:source="wim:c:/simtest/winpe.wim#Microsoft Windows Vista PE (X86)"
 xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

net start "DNS Client"
netsh interface ipv4 add dnsserver "Local Area Connection" 192.168.2.10 index=1

問：可以從光纖通道控制器啟動 Windows PE 嗎？
答：可以，只要此光纖通道 HBA 支援透過 Int13 登錄開機磁碟區，如此它便可以在 BIOS 中顯示為 Windows PE 的可開機磁碟區。您也必須新增光纖通道控制器的驅動程式，就像處理其他現成可用的存放控制器驅動程式一樣。

問：Windows PE 2.0 一律是從 RAMDisk 開機。我有一些系統的 RAM 不夠，無法使用這種方式啟動。我可以不使用 RAMDisk 來啟動 Windows PE 2.0 嗎？
答：可以的。RAM 低於 256MB 的系統尤其需要進行 Windows PE 的非 RAMDisk 實作才能開機。有一篇正在撰寫中的 Microsoft 支援文章將會描述其做法。在此提出幾個重要的警告：您無法像使用 RAMDisk 時一樣交換媒體，而且這種方式的開機速度比以 RAMDisk 為基礎的 Windows PE 2.0 版本要慢很多。

問：我已經嘗試從 DVD 以外的媒體啟動 Windows PE 2004 和 Windows PE 2005 (1.5 或 1.6)，並複製 DVD 的映像 (或其他資料)。我並非從 DVD 開機，只是複製其中的資料，可是卻行不通。我在完整安裝的 Windows 底下可以讀取 DVD，但是在 Windows PE 底下會收到錯誤訊息，指出磁碟區已損毀或無法讀取。有解決方法嗎？
答：有的。在預設情況下，Windows PE 1.x 不支援 UDF 格式化的媒體。根據定義，DVD 會格式化為 ISO 橋接支援 (ISO 與 UDF 的雙重格式) 或單純是 UDF。您必須新增 UDF 驅動程式到您的 Windows PE 安裝才能運作。電腦上已經存有驅動程式，只不過尚未安裝。若要安裝，請執行下列步驟：
  1. 在記事本中開啟位於 I386 (如果是 Windows PE 的硬碟安裝，則位於 MiniNT) 目錄中的 txtsetup.sif 檔案。
  2. 找到稱為 [CdRomDrivers.Load] 的區段，然後尋找包含名為 cdfs.sys 的驅動程式的那一行。在該行底下新增 udfs = udfs.sys 一行。輸入結果應該類似如下：
[CdRomDrivers.Load]
cdfs = cdfs.sys
udfs = udfs.sys
3. 找到稱為 [CdRomDrivers] 的區段，然後尋找包含 cdfs 的那一行。在該行底下新增 udfs = "Universal Disk File System" 一行。輸入結果應該類似如下：
[CdRomDrivers]
cdfs = "CD-ROM File System"
udfs = "Universal Disk File System"
4. 儲存並關閉 txtsetup.sif，然後視需要重新建立 Windows PE 映像。您現在應該能夠從 Windows PE 讀取 UDF 格式化的 DVD 媒體了。

問：我有一些執行 Windows XP 的舊系統不支援 ACPI。我可以在這些系統上使用 Windows PE 2.0，以便遷移至 Windows Vista 或者重新安裝 Windows XP 嗎？
答：不行。Windows PE 2.0 只支援與 Advanced Configuration and Power Interface (ACPI) 相容的系統，因此無法在您的系統上啟動。若您需要在這些系統上使用 Windows PE，請使用 Windows PE 1.6 或更舊版本。

問：我在 Visual Studio® 2005 上撰寫自己的應用程式，而且想要在 Windows PE (1.x 或 2.0) 上執行。可以順利執行嗎？
答：要視您撰寫應用程式的方式而定。若您是使用 Unmanaged C++，那麼就沒問題，您的應用程式應該可以執行。若您是使用任何一種 Managed 程式碼語言 (例如 C# 或 J#)，或撰寫任何 Managed C++ 程式碼，那麼就無法執行。因為 Microsoft® .NET Framework (所有版本) 不適用於 Windows PE，因此將無法執行 Managed 程式碼。

問：我想要自己撰寫可以在 Windows PE 2.0 上使用的應用程式，但需要一點幫助。我最好從何處找起？
答：建議您先閱讀《Windows PE 開發人員指南》白皮書。

問：我從 CD 啟動 Windows PE 2.0 好幾次，但是磁碟機代號 (RAMDisk) 一直顯示 X。我要如何分辨實際開機的是哪個磁碟機代號呢？
答：當您檢視登錄時，下列機碼應該會反應出一開始啟動 Windows PE 的實際磁碟機代號：
HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition
如果您發現因為在 Windows PE 中使用協力廠商殼層的關係，登錄中並未填入此機碼，那麼以下命令會將它更新為正確值：
start /w wpeinit UpdateBootInfo

問：可以使用 ImageX 和 WIM 檔案來備份我的系統嗎？
答：理論上可以，但不建議這麼做。ImageX 不會像真正的備份工具一樣，備份已鎖定或開啟中的檔案。建議您繼續使用真正的備份公用程式，以便保護開啟中和鎖定的檔案。

問：如果我擷取未壓縮的 WIM 檔案，其部署速度會比相同的已壓縮磁碟區影像快嗎？
答：不會明顯較快。壓縮會讓擷取時間比較久。但是無論使用哪種壓縮類型 (無、XPress 或 LZX)，將映像套用到目標系統的時間並不會明顯較久。建議您根據自己實際的映像大小需求和預備擷取的時間長度來決定壓縮選項。

問：如果我要對磁碟套用 WIM 映像，需要重新分割及格式化磁碟嗎？
答：是的，您需要這麼做。為了執行清楚的系統映像，首先您必須使用 Diskpart 工具來清理磁碟區 (或刪除並重新建立目的地資料分割)。或者，您也可以在套用前完全格式化磁碟區。
此外，您必須記得 Windows Vista 之前的 Windows 版本使用不同的開機磁區 — 因此若您使用 Windows PE 2.0 來部署 Windows Server 2003 或更舊版本，就必須先在 Windows PE 中執行下列命令，以便將開機磁區設為可以啟動 Windows Server 2003 及更舊版本的開機磁區，然後再開始進行 Windows 安裝或套用其 WIM。
bootsect /nt52 sys C: /force

結論
希望您會覺得以上的 WDS 更新和這些問題解答實用又有趣。很感謝讀者提出的問題，只要專欄長度允許，我都將竭誠回答這些問題。歡迎繼續提問，來信請寄至我的簡介中的電子郵件位址。
Windows Vista 硬體評量
Baldwin Ng

好消息！您的主管終於回應您一個月前提出的建議。顯然他已經認真考慮過您提議全組織逐步導入 Windows Vista 的計劃，並且開始了解管理單一作業系統的優點，以及能省下的成本。但是，他還不太確定替換所有 PC 以進行 Windows Vista 安裝是否符合經濟效益。對於哪些 PC 可以立即遷移到 Windows Vista，還有哪些 PC 只需要小規模的升級 (例如，增加系統記憶體和硬碟空間) 就能遷移，他想要參考具體的詳細資料。而且週末前就要答案。那您要從何處開始著手呢？若您的組織沒有任何精密的資產或網路管理工具，要如何在幾天內獲得解答呢？更糟的是，交接者並未留下現有網路資產的充分資訊。
Microsoft 剛剛發行的「Windows Vista 硬體評量」是一個解決方案加速器，可協助您判斷組織部署 Windows Vista 的就緒程度 (請參閱 microsoft.com/technet/wvha)。這個工具會快速評估網路上的 PC，以大多數中型的組織來說，只要幾小時就能產生有關硬體及裝置相容性的詳細就緒程度報告，而且完全不需要在網路中的電腦上安裝任何軟體代理程式。
「Windows Vista 硬體評量」是根據先前為 Microsoft Assessment and Deployment Solution (ADS) 開發的超強清查彙總與報告技術建置而成，它會透過三個步驟來建立一組就緒程度報告：

1. 硬體清查
藉由使用 Windows Management Instrumentation (WMI)、Active Directory® 和其他 Windows 網路通訊協定 (例如 NetServerEnum)，這個工具會探索網域上的電腦和工作群組電腦。完成清查後，所有系統資源及裝置資訊都會儲存在 SQL Server™ 2005 Express 資料庫中。這個工具的目前版本支援對多達 5,000 部機器進行網路探索。未來版本將可望擴充至更大型的網路。

2. 相容性分析
此工具利用 Windows 團隊的最新裝置及 BIOS 資料庫來分析各個 PC 對於安裝 Windows Vista 的硬體及裝置相容性的就緒程度。此外還會透過定期更新的 Web 服務來取得驅動程式資訊，因此您每次執行這個工具時都能獲得最新資訊。

3. 就緒程度報告
最後一個步驟是自動產生一組就緒程度報告，報告形式採用 Microsoft Word 文件和 Excel® 試算表。這些報告可提供就緒程度狀態以及每部 PC 的升級建議。
「Windows Vista 硬體評量」能彌補包括 Business Desktop Deployment 2007 和《Windows Vista 安全性指南》等其他 Windows Vista 解決方案加速器的不足之處。如需詳細資訊，請參閱解決方案加速器首頁。

Baldwin Ng 是 Microsoft Solution Accelerators 小組的產品經理，擅長建立自動化工具來協助客戶與顧問快速有效地採用 Microsoft 軟體。您可透過電子郵件與他連絡：Baldwin.Ng@microsoft.com。

Wes Miller 於美國德州奧斯丁的 Pluck 公司 (www.pluck.com) 擔任開發經理。他之前任職於同樣位於奧斯丁的 Winternals Software，並且曾在 Microsoft 擔任 Windows 的專案經理與產品經理。您可以透過電子郵件與 Wes 連絡：technet@getwired.com。Wes 特別感謝 Scott Dicken (Microsoft 的 Windows 部署服務的專案經理) 提供 WDS 新功能內容方面的協助。


 現場筆記: 保持敏銳
現場筆記
保持敏銳
Joshua Hoffman

喔，外勤呀！ 我一清二楚。大約兩年前在接下目前的職位 (擔任這份優良出版物的技術編輯) 之前，我算是這個領域當中活躍的 IT 專家。我花了五年的時間從事微軟顧問服務 (Microsoft Consulting Services)，也花了數年的時間服務於美國財星前一百大 (Fortune 100) 各家公司的 IT 部門。然後我受到現在這個苦活兒的誘惑。我不是在抱怨 — 我們這裡有一群很優秀的人，而且我有機會認識、跟諸位讀者合作！而且要是我不用在星期一早上搭 6 點的飛機去工作的話，也無所謂。
但是我這份新工作有個缺點。許多 IT 專家都宣稱在我們這一行學習新玩意 (以及隨時了解最新動態) 最佳之道是親自下海操作。實際、實機操作的應用程式是強大的教育性工具，但隨著職業的晉升，職責的變動，可能一下子發現自己變成沒有系統或基礎結構可以管理的 IT 專家。而且物換星移的速度相當快。自從我接掌這份新職務，Windows® 就有了新版本，內有全新的部署架構、新的安全性基礎結構、新的網路堆疊，以及一些其他功能。對了，Office 也推出新版本。Exchange Server 也是，SQL Server™ 也是，還有 Microsoft® Operations Manager 也是。另外，還有一些新工具：Windows PowerShell™、MMC 3.0、Windows Automated Installation Kit 等。希望我沒漏掉其他的。
看來短短兩年的時間，很多事都變了。所以說，如果學習的最佳之道是動手去做，而您的工作將不再包含「做」的部分的話，怎麼可能跟得上腳步呢？
嗯，我當然希望這本雜誌能有所幫助，因為它幫了我。我們有許多優秀的作者真的對他們的專業很在行，而且讓我獲益良多。可是還是那句老話，有時候您真的得實機操作。我通常是從 Virtual PC (或 Virtual Server) 開始，兩者皆可從 Microsoft 網站免費下載 (您可以在我們網站上的下載專區找到連結。透過虛擬化技術，我很快就可以直接在膝上型電腦上建置自己的 Active Directory®，或是自訂 Windows Vista™ 的部署，完全不需要其他硬體。在我想要了解某些東西是怎麼運作的時候，親身經歷過整個流程的確有差。
Virtual PC 唯一的麻煩是您實際上必須建置虛擬環境 (安裝 OS、適當設定一切等等)，如果這是您想學的，那很好，但要是您只是想要探索某產品特定的功能呢？比方說，若是您想要了解 Exchange Server 2007 中全新的相容功能呢？重頭安裝和設定 Windows Server®、Active Directory 和 Exchange Server 似乎是相當繁重的工作。不妨進來 TechNet 虛擬實驗室。敝人覺得虛擬實驗室是長久以來的其中一項最佳訓練資源。虛擬實驗室小組已經幫您完成了艱難的部分 — 他們擁有超過 180 台預先安裝、預先設定好的虛擬機器，涵蓋了 20 種以上不同的產品組合。每項組合都附有一套訓練練習，可帶您逐一了解常見的工作和新功能。而最棒的部分是整個過程是在瀏覽器的環境中執行 (裝載在 Microsoft 管理的伺服器上)，因此您不需要用到自己的硬體資源。
的確，如果您已不在最前線，要隨時了解最新動態是越來越不容易，但還是辦得到！我已指出了一些我最喜愛的資源，還有就跟我的好友 Edward Dake 幾個月前在本專欄中所說的一樣，我們擁有的最佳資源其實是彼此。您永遠可以向他人尋求幫助。

Joshua Hoffman 是《TechNet Magazine》的技術與徵稿編輯。


 Windows 機密文件: 判斷常用的項目
Windows 機密文件
判斷常用的項目
Raymond Chen

按一下 [開始] 按鈕，接著會顯示 [開始] 功能表，左邊列出一份程式清單。這份程式清單是如何挑選出來的呢？一開始我們是根據一項通則，即近來最常執行的程式應該顯示在 [開始] 功能表的首頁。以此原則做為前提，我們很快就發現有必要做些微調。
基本規則是每次啟動一個程式，它就得一分。反過來說，不啟動某程式的時間越長，它失掉的分數就越多。[開始] 功能表會顯示得分最多的程式。很簡單，對吧？不過這不是選擇演算法令人困惑的地方。套用基本規則後要進行的微調，才是最令人不解之處。
在開始進行微調之前，有幾件事從基本規則不容易看出。您可以注意到規則講的是啟動程式，而不是捷徑。有些程式會安裝多個捷徑，而使用哪個捷徑來啟動程式都沒有差別。如果它們全都指向同一個可執行檔，那麼該程式就會將不同捷徑所得的分數全部加總。
[開始] 功能表
這表示只要是從檔案總管執行，即使沒有使用 [開始] 功能表來執行，程式也可得分。假使您手動執行程式，比方說開啟資料夾然後按兩下可執行檔，那麼該程式仍然可以得分，而且最終會被升級到 [開始] 功能表的首頁。
現在只要程式獲得足夠的積分而能夠顯示在 [開始] 功能表的首頁，Windows® 就必須決定要顯示哪個捷徑 (如果有超過一個捷徑指向該程式的話)。不用多說，當然會選最常用的捷徑。
微調的工作之一，就是從清單篩選特定的程式。舉例來說，您固定到 [開始] 功能表的程式就不會顯示，因為沒有必要顯示兩個代表同一個程式的圖示。畢竟，將程式固定到 [開始] 功能表示的原因是您常常執行它。
另一個微調的步驟則會篩選出干擾的程式。許多程式都是因為它們是常見協助程式 (像是記事本或 Wordpad) 的捷徑而顯示出來，例如顯示讀我檔案的捷徑。這些捷徑需要被過濾，才不會成為程式 (例如記事本) 的代表。順帶一提，程式也可以將自己登記成不適合包含在 [開始] 功能表首頁，方法是在其應用程式註冊中建立 NoStartPage 值。
基本規則同樣也不會將啟動一次、然後一直執行的程式列入考量。根據該項規則狹義的解釋，此程式會在您啟動它時獲得一分，然後在經過一段時候後失去該得分 (在這種情況下，「經常使用」的定義根本不包括「使用個不停」)，所以我們加了另一條規則：程式連續不間斷的執行一天，就得一分。這足以讓程式繼續競爭分數，而且又不至於把實際啟動的程式完全比下去。畢竟，假如您一直執行這個程式，根本也不需要經常啟動它。
Windows Vista™ 中新增了其他幾條微調規則。例如，現在對於從來不曾自 [開始] 功能表執行的程式來說，若要從候選的捷徑挑選的話，會比較偏好選擇不含命令列參數的捷徑。而您最近一次執行的程式無論得分為何，永遠都會出現在清單上。

Raymond Chen 的網站 The Old New Thing 以及同名著作 (Addison-Wesley，2007 年) 均探討 Windows 的歷史和 Win32 程式設計。他非常重視您的來電，並會以接到的順序回電。