 TechNet Magazine December 2007

TechNet Magazine December 2007

通訊: Exchange Server 2007 Service Pack 1 中 16 種新增功能

Exchange Server 2007 Service Pack 1 與傳統 Service Pack 不同，它提供的不單只是 Hotfix 和安全性更新而已，還有更多豐富的功能。下面就是 SP1 所提供的一些重要的新功能概觀。

Tony Smith 通訊: Exchange Server 2007 Service Pack 1 中的待命連續複寫

在 Service Pack 1 提供的功能當中，最棒的當屬待命連續複寫 (Standby Continuous Replication) 了。接下來我們要瞭解這個工具如何協助您改善執行時間、限制資料遺失，以及簡化電子郵件的維護與保存工作。

Scott Schnoll 通訊: 透過 Windows Server 2008 執行 Exchange

準備好在 Windows Server 2008 上執行 Exchange 了嗎？Microsoft Exchange 開發小組使用這種環境已經有一段時間，而 Paul Bowden 將與您分享一些他們的建議及心得，幫助您準備就緒。

Paul Bowden 通訊: 透過 Exchange Server 2007 部署整合通訊

將語音信箱、傳真功能和電子郵件訊息整合成單一信箱乍聽之下並非易事。但其實比您想像的簡單。本文可指引您在組織中部署整合通訊。

Jeff Goodwin 安全性: 基本電腦鑑識指南

瞭解簡單好用、價格便宜的方法來鑑識電腦，這些方法可以讓主流系統管理員用來進行基本調查工作。

Tom Cloward and Frank Simorjay 網路功能: Microsoft Security Intelligence Report

Microsoft 收集了許多關於電腦使用者面臨之安全性威脅的統計資料。粗略了解一下最近的趨勢、不同 Windows 版本的表現，世界上的哪些地區受到的衝擊最大，還有更多資訊。

Tim Rains 網路功能: 追蹤難以捉摸的網路問題

若有台機器無緣無故不跟其他機器通訊，這些秘訣可以幫助您快速診斷和修復問題。

Christopher Stoneff 編輯的話: 揭開對話的序幕

Joshua Hoffman 讀者來信: 讀者有話直說

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

Greg Steen SQL 問答集: 記憶體設定、效能設定、設定您的填滿因素及其他

Edited by Nancy Michell 公用程式焦點: Microsoft Security Assessment Tool

這個免費的公用程式和電子問卷調查，可以幫助中型企業識別和消除網路安全性風險。

Lance Whitney The Cable Guy: 網路原則伺服器

Windows Server 2008 中的網路原則伺服器 (NPS) 服務不但取代了 Windows Server 2003 中使用的網際網路驗證服務，並帶來了眾多的增強功能，從強制系統健康需求到改進的管理能力一應俱全。

Joseph Davies Windows PowerShell: 深入挖掘

Windows PowerShell 提供的許多功能經常受到忽略。但是透過一套有系統的方法來探索 Windows PowerShell 指令程式，您將挖掘出一些過去未曾注意到的強大功能。

Don Jones 嗨，Scripting Guy！: 重返 WinRM

是管家幹的嗎？東西放在儲藏室的燭臺旁邊嗎？本文不會揭開這些謎底。不過在久違了四週之後，Scripting Guy 又回頭來談 WinRM 二部曲的＜第二篇＞。

The Microsoft Scripting Guys 安全性監控: Windows 網域密碼原則

到目前為止，Windows 都堅持一個網域只接受一個密碼原則。不過，Windows Server 2008 可讓系統管理員實作多項密碼原則，針對不同類型的使用者量身訂做不同的原則。

Derek Melber 桌面檔案: 在虛擬世界中部署 Windows

考慮採用虛擬化嗎？沒有？不會吧，您應該好好考慮。一起來了解如何部署虛擬系統，有什麼要避免的，以及虛擬化實際的運作方式。

Wes Miller 現場筆記: 變幻莫測的未來

隨著私人生活中的技術與觀念逐漸融入專業生活中的技術與觀念，IT 也變得「消費化」。而對企業及私人生活造成深遠影響。

Romi Mahajan Windows 機密文件: 不必把搖桿當微波爐

了解一下 DirectInput 力回饋搖桿 (force feedback joystick) 介面指定週期性力道的方式 — 外加一些出乎意料的結果。

Raymond Chen


 通訊: Exchange Server 2007 Service Pack 1 中 16 種新增功能
通訊 Tony Smith

Exchange Server 2007 Service Pack 1 中 16 種新增功能
摘要:
  • 新的管理功能
  • 增強的伺服器角色
  • 改進的整合通訊

大多數的系統管理員都很熟悉針對伺服器和桌上型系統下載和套用 Service Pack 的程序。這些下載的 Service Pack 當然都有提供 Hotfix 和安全性更新，
可以幫助您保持系統的最新狀態，不過 Service Pack 有時候包括的還不只這些。即將推出的 Microsoft® Exchange Server 2007 Service Pack 1 就是一例，它包含了許多刺激好玩的新功能。
您所下載的 Service Pack (下載網址為 go.microsoft.com/fwlink/?LinkId=91472) 可以執行 Exchange Server 2007 的完整安裝 (內含所有的 SP1 更新)，也可以更新 Exchange Server 2007 的現有安裝。Exchange Server 2007 SP1 可以安裝在 Windows Server® 2003 SP1、SP2 和 R2 上，同時也與未來的 Windows Server 2008 版本相容。
Service Pack 1 提供的新增功能和增強功能之多，不是一篇簡短的概觀就能探討得完。我只能編列一份清單，說明一些值得注意的變更部分，作為您改善 Exchange 環境之用。如需詳細查看所有的變更，請參閱＜Exchange Server 2007 SP1 的新功能＞，網址是 technet.microsoft.com/bb676323.aspx。

Exchange 管理主控台的變更部分
Service Pack 1 賦予 Exchange 管理主控台 (見 [圖 1]) 一些實用的新功能。簡單的說，這個工具箱原本就提供一系列預設要隨著 Exchange Server 2007 安裝的診斷、疑難排解和修復工具，現在更加入了公用資料夾管理主控台、詳細資料範本編輯器，以及路由記錄檢視器。
Figure 1 Exchange Management Console with Service Pack 1
Figure 1 Exchange Management Console with Service Pack 1
您可以使用 Exchange 管理主控台、公用資料夾管理主控台、詳細資料範本編輯器以及佇列檢視器，從結果窗格和工作窗格匯出清單。清單可以匯出成文字 (以 Tab 分隔)、文字 (以逗號分隔)、Unicode 文字 (以 Tab 分隔) 和 Unicode 文字 (以逗號分隔)。現在除了能夠在 Exchange 管理主控台中篩選結果窗格之外，還可以在公用資料夾管理主控台、詳細資料範本編輯器以及佇列檢視器中篩選結果窗格。
然而最值得注意的是，Exchange 管理主控台包含了許多全新的管理介面 (例如我剛剛提到的公用資料夾管理主控台)，我將在文中一一討論這些介面。

IPv6 的支援
隨著 Windows Server 2008 支援的出現，網際網路通訊協定第 6 版 (IPv6) 的支援也應運而生。當然，前提是必須在 Windows Server 2008 上實際安裝 Exchange Server 2007，並且同時啟用 IPv4 和 IPv6 通訊協定堆疊。如果在安裝前停用 IPv4，Exchange 就不會支援 IPv6。
您可以採用 IPv4 或 IPv6 格式來輸入 IP 位址和範圍。但是只有一個伺服器角色可以收發使用 IPv6 位址的裝置、伺服器和用戶端資料。唯一例外的是 Unified Messaging server role。因為基於一些必要拓樸和語音元件的限制，Unified Messaging role 必須使用 IPv4。

POP3 和 IMAP4 管理 UI
Exchange 管理主控台新增了一個管理 UI，負責管理 POP3 和 IMAP4。您可以在這裡為 Client Access Server 設定所有的 POP3 和 IMAP4 設定，包括連接埠設定、驗證設定和連線設定。[圖 2] 所顯示的是 IMAP4 屬性設定對話方塊，POP3 也有相同的選項。
Figure 2 Exchange Management Console for POP3/IMAP4
Figure 2 Exchange Management Console for POP3/IMAP4

更健全的信箱管理
Exchange 管理主控台中的信箱管理功能，現在也支援為現有使用者帳戶建立大量信箱。同時，新的精靈也容許系統管理員授與或移除信箱的「完整存取」權利，並且容許您設定信箱的「傳送為」權限。

管理信箱資料的新功能
現在系統管理員可以透過匯入和匯出 .pst 檔案來管理信箱資料了。您也可以在 Exchange 管理命令介面分別使用 Import-Mailbox 和 Export-Mailbox Cmdlet 來進行這項工作。
郵件記錄管理 (Messaging Records Management，MRM) 可套用至 Exchange 伺服器 (含 Exchanage 標準版用戶端存取授權) 上的受管理預設資料夾 (請注意，受管理自訂資料夾的 MRM 仍必須具有 Exchange 企業版用戶端存取授權)。Set-Mailbox Cmdlet 用的新參數 RemoveManagedFolderAndPolicy，會從信箱裡移除任何 MRM 原則、從任何被視為 MRM 原則 (並且套用至信箱) 一部分的受管理資料夾中移除 MRM 屬性，並且將任何受管理的資料夾轉換成標準資料夾。
新的效能監視器計數器可讓您監視不同的線上重組資訊 — 也就是上次執行線上重組的時間、完成所花的時間，以及進行了哪些動作等。這些資訊可以幫助您將線上重組間隔最佳化。

確認遠端清除
Exchange Server 2007 已經容許系統管理員或帳戶使用者發出遠端清除命令，清除行動裝置上所有的使用者資料 — 這在裝置遺失或遭竊時是個相當有用的安全性功能。安裝 Service Pack 1 之後，只要裝置收到遠端清除的要求時，就會傳送一則確認訊息。如果是使用者發出要求 (透過 Outlook® Web Access 或稱 OWA)，他就會收到一封確認電子郵件。如果是系統管理員發出要求 (透過 Exchange 管理主控台)，則系統管理員和使用者都會收到一封確認電子郵件。

更穩固的 OWA 用戶端
網路架構的電子郵件用戶端內含許多增強功能，為行動工作者提供更完備的訊息功能。有了 SP1 之後，OWA 使用者就可以建立和編輯個人通訊群組清單，以及伺服器端規則。此外，使用者還可以使用「大型垃圾筒」和「復原刪除的郵件」功能。
UI 中也加入了移動和複製命令，容許使用者透過資料夾清單上的按右鍵功能表，來移動和複製資料夾。訊息資料夾和公用資料夾中個別的項目也可以透過在項目按一下滑鼠右鍵或按一下工具列上的圖示來進行移動和複製。
另外，OWA 使用者不需要使用 /public 虛擬目錄，就能夠完整存取公用資料夾 (而且不需要 Exchange 2003 後端伺服器來支援這項作業)。而且 OWA 也支援公用資料夾搜尋功能。
現在 S/MIME 功能容許使用者讀取和撰寫經過簽署和加密的電子郵件訊息 (見 [圖 3])。甚至還支援 CNG (Cryptography API:Next Generation)，並且與 Suite-B 相容。同時還可以自訂 OWA UI，以便順暢地整合自訂應用程式。
Figure 3 S/MIME message settings
Figure 3 S/MIME message settings

OWA Light 中的複合監視
Outlook Web Access Light (簡化版的 OWA) 過去是專門為了與所有 (幾乎是所有) 網頁伺服器搭配使用而設計。現在，它可以在使用者撰寫任何一種長項目 (例如郵件或行事曆項目) 時監視活動，以確保工作階段不會在使用者還在輸入時逾時 (而導致資料遺失)。此外，如果工作階段在郵件撰寫表單處於開啟狀態時因為閒置而逾時，郵件訊息還會自動儲存到 [草稿] 資料夾。

改善的 Direct Push 效能
Direct Push 是透過在行動裝置與 Exchange 2007 伺服器之間建立 HTTPS 連線的方式來運作。Exchange 2007 SP1 已經縮小 HTTPS 要求和回應標頭的大小，因而也減少了從行動裝置接收以及傳送至行動裝置的資料量。

公用資料夾管理
新的公用資料夾管理主控台 (見 [圖 4]) 容許系統管理員在 Exchange 管理主控台內，建立、設定和維護公用資料夾。位址清單、電子郵件地址原則、動態通訊群組以及通訊群組清單都可以感知公用資料夾。您在預覽位址清單、電子郵件地址原則、動態通訊群組和通訊群組收件者時，可以看到在群組成員資格條件中，含有啟用郵件功能的公用資料夾。
Figure 4 Public Folder Management Console
Figure 4 Public Folder Management Console
Exchange 2007 SP1 中的公用資料夾管理主控台，可讓您設定公用資料夾管理權限。做法是使用 Add-ExchangeAdministrator Cmdlet 或「新增 Exchange 系統管理員精靈」，將使用者新增至公用資料夾系統管理員角色，或是使用 Add-PublicFolderAdministratorPermission Cmdlet 授與或拒絕公用資料夾的特定權限。

增強郵件處理和路由
部署於 Active Directory® 樹系內的 Hub Transport Server，負責處理組織內部所有的郵件流量、套用傳輸規則、套用日誌規則，以及傳送郵件至收件者信箱。Hub Trasnaport Server 會將外寄至網際網路的郵件，轉送到周邊網路上的 Edge Transport Server。SP1 就包含了這些伺服器角色的增強功能。
Exchange Server 2007 內含一項系統資源監視功能，稱為流量回增 (Back Pressure)，它可以讓 Hub Transport Server 與 Edge Transport Server 對高資源使用量作出回應。有了 SP1 之後，可用磁碟空間的需求，已經從 4GB 大幅降低為 500MB 了。
由於　SP1 中的 Exchange 管理主控台提供更多的傳輸組態設定，因此現在您可以把 X.400 位址空間設定成授權網域 (現在也支援 X.400 長位址)。
Hub Transport Server 支援優先佇列，分類程式會判斷 Outlook 使用者指派給郵件的郵件優先順序，確保以高重要性傳送的郵件確實獲得優先處理，而且傳遞的速度也比指定為低重要性的郵件更快。
Exchange 2007 SP1 藉由在 Exchange 管理命令介面 Cmdlet 中加入 IsScopedConnector 參數，以及在 Exchange 管理主控台加入 [界定領域的傳送連接器 (Scoped Send Connector)] 核取方塊等方式，簡化單一 Active Directory 站台之傳送連接器的領域。在界定傳送連接器的領域時，只有與傳送連接器的來源伺服器位於同一個 Active Directory 站台的 Hub Transport Server，才會將該傳送連接器列入路由決策的考量當中。

Edge Transport Server 同步處理增強功能
在 Exchange Server 2007 SP1 中，您可以使用 Start-EdgeSynchronization Cmdlet，立即進行從 Active Directory 到 Active Directory 應用程式模式 (ADAM) 目錄服務的資料同步處理作業。由於它在 Exchange 2007 SP1 當中支援 Server 參數，因此您可以從遠端電腦執行 Cmdlet。
Test-EdgeSynchronization Cmdlet 是一種負責報告 Edge Transport Server 同步處理狀態的診斷 Cmdlet，它新增了一組參數集合，可讓您確認個別使用者的同步處理結果。

TransportConfig 物件複製
當在環境中部署一部以上的 Edge Transport Server 時，複製組態指令碼可以方便系統管理員套用一致的組態。SP1 中的複製組態資訊現在還加了 TransportConfig 物件，負責控制 Edge Transport server role 的伺服器端設定。伺服器部署、備份和還原程序的效率大幅提升，都要拜它所賜。

整合通訊的改進功能
整合通訊是 Exchange Server 2007 初版中令人驚喜的功能。Service Pack 1 是根據這項功能為基礎建置而成，另外再加入許多新增功能和增強功能。有的功能要求您在同一個 Active Directory 樹系內部署 Office Communications Server 2007，但也有許多功能並不需要 Office Communications Server。此處我無法一一探討整合通訊的不同之處，只能概略說明一些值得注意的新增功能。如果您想閱讀更多有關整合通訊的資訊，可參閱本期《TechNet Magazine》中的＜使用 Exchange Server 2007 部署整合通訊＞一文，以取得詳細資訊。
首先我將介紹一些需要 Office Communications Server 2007 的新功能。整合通訊現在支援讓媒體資料流周遊防火牆，也支援高逼真語音訊息。當您用語音訊息留言時，如果目的地是採用來電轉接，就會發出轉接通知。使用者不需要輸入 PIN，就可以從 Office Communicator 2007 存取 Outlook Voice Access。Office Communicator 2007 還把未接來電通知電子郵件訊息與語音信箱通知相加整合 (見 [圖 5])。另外還有更多功能。
Figure 5 Voicemail notification in Office Communicator
Figure 5 Voicemail notification in Office Communicator
整合通訊其中一項不需要 Office Communications Server 的增強功能，是支援 Secure Realtime Transport Protocol (SRTP)。Exchange Server 2007 初版提供兩種安全性模式：不安全模式和安全模式。安全模式只會將工作階段初始通訊協定 (Session Initiation Protocol，SIP) 流量加密，而不會將 RTP 流量加密。SP1 有三種模式： 不安全模式、SIP 安全模式以及安全模式。在 SIP 安全模式中，只有 SIP 流量會加密，RTP 流量則不會。而在安全模式中，SIP 流量和 RTP 流量都會加密。您也可以使用 Exchange 管理主控台，設定撥號方案的 Mutual Transport Layer Security (MTLS)。
其他變更部分還包括新的「啟用整合通訊精靈」(您可以用它來新增使用者的 SIP 或 E.164 位址)；使用 Exchange 管理主控台來設定撥號對應表的 URI 類型；以及使用 DiffServ 標示媒體流量的服務品質 (QoS) 支援，這些都是 SP1 的新功能。

更高的可用性
Service Pack 1 加入幾項新的功能，不但提升高可用性，也增強了現有的高可用性功能。全新和經過改善的功能擴大了案例規模，讓您達成 Exchange 2007 伺服器角色的資料和服務可用性。新的案例可讓組織將高可用性案例與站台復原案例分開，並在各個不同的區域內，部署專為組織量身訂做的組態。
簡單的說，Windows Server 2008 的支援，提供了多重子網路容錯移轉叢集，也提供了新仲裁模型的支援 (磁碟和檔案共用見證)。在叢集報告和監視功能方面也有相當實用的改進，包括其他專為主動監視連續複寫環境而設計的功能。另外，效能方面的改良，則包括減少內含儲存群組被動複本之磁碟上的 I/O 作業、加快記錄檔複製的速度，以及加快在節點之間移動叢集信箱伺服器的速度等。
最後，還有改善管理和設定用的新精靈 (見 [圖 6])，以及管理叢集信箱伺服器用的新 UI 控制項，其中包括新的 [叢集信箱伺服器] 索引標籤，以及叢集連續複寫 (Cluster Continuous Replication，CCR) 組態頁。
Figure 6 Manage Clustered Mailbox Server Wizard
Figure 6 Manage Clustered Mailbox Server Wizard

待命連續複寫
待命連續複寫 (Standby Continuous Replication，SCR) 採用本機連續複寫 (Local Continuous Replication，LCR) 所用的同一種記錄傳送和轉送技術，來提供附加的部署選項和組態。SCR 與 LCR 和 CCR 很類似，但還是具有自己獨特的特性。如需 SCR 的深入探討，請參閱本期《TechNet Magazine》中由 Scott Schnoll 所寫的＜Exchange Server 2007 中的待命連續複寫＞。

結論
Exchange Server 2007 Service Pack 1 很顯然不單只是提供 Hotfix 和安全性更新而已，它還提供許多新增和增強的功能，絕對讓您愛不釋手。只可惜本文沒有足夠的篇幅可以探討所有的新增功能和增強功能，但至少希望能夠提供您初步的了解。如需有關 Service Pack 1 中所有變更的完整資訊，還有下載、網路廣播和論壇等資訊，請造訪 Exchange Server TechCenter，網址是 http://technet.microsoft.com/zh-tw/exchange/default.aspx

Tony Smith 是 Exchange User Education 小組的首席技術文件作者，專精於整合通訊。在受雇於 Microsoft 之前，Tony 曾擔任網路工程師、Microsoft 廠商和 Microsoft 認證講師。他也為 Microsoft Learning 完成了幾項寫作專案，包括書籍和實驗室手冊。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 通訊: Exchange Server 2007 Service Pack 1 中的待命連續複寫
通訊 Scott Schnoll

Exchange Server 2007 Service Pack 1 中的待命連續複寫
摘要:
  • 設定待命連續複寫
  • 備援的重要性
  • SCR 如何縮短停機時間

Service Pack 1 提供數個 Exchange 2007 新增功能和增強功能。其中一項新功能 ─ 待命連續複寫 (SCR) ─ 就是專門為公司提供資料中心內部備援和站台復原能力而設計。正如其名，SCR 是針對
使用或促成使用待命復原伺服器的案例而設計。
如果您很熟悉 Exchange 2007 的量產發行版 (RTM)，就知道它也透過它的記錄傳送功能以及 Windows® 容錯移轉叢集，提供資料中心內部備援和站台復原能力。在 RTM 版當中，記錄傳送 (正式稱為連續複寫) 有兩種形式：本機連續複寫 (LCR) (如 [圖 1] 所示) 以及叢集連續複寫 (CCR) (如 [圖 2] 所示)。
Figure 1 Local continuous replication
Figure 1 Local continuous replication
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
Figure 2 CCR is log shipping to a second server in a Windows failover cluster
連續複寫容許系統管理員在線上啟用和維護每一個信箱資料庫的第二個複本，藉此提供資料的可用性和備援能力。這個資料庫複本是預防實際執行資料庫失敗、遺失或損毀的第一道防線。資料庫複本可在數分鐘內啟動，並成為實際執行的資料庫，省去了尋找備份磁帶來還原資料所浪費的時間。
SCR 把規模更進一步擴大，讓您達成貴公司資料和服務的可用性。新的案例可讓您將高可用性拓樸與站台復原拓樸分開，並且容許您在每一個區域部署專為貴公司量身訂做的設定。
雖然 Exchange 2007 RTM 版可以提供資料中心內部備援能力和站台復原能力，但是因為 LCR 和 CCR 只為每一個資料庫提供一份額外複本，所以您必須在復原能力和備援能力之間擇其一。以 CCR 所提供的資料和服務可用性功能為例。將主動和被動節點部署在同一個資料中心，雖然能夠提供資料中心內部服務與資料的可用性，但是卻不能提供站台復原能力 (因為這兩個節點是位於同一個實體站台)。將主動節點部署在一個資料中心，將被動節點部署在第二個資料中心，雖然能夠提供站台復原能力，卻不能提供資料中心內部可用性 (因為提供這些功能的被動節點是位於第二資料中心)。
但是當 Service Pack 1 附有 SCR 功能之後，在為每一個資料庫建立額外複本時，高可用性和站台復原能力兩者便互不相斥，而能同時達成這兩種能力。比方說，如 [圖 3] 所示，您可以結合 SCR 與 CCR，在主要資料中心本機複寫儲存群組 (使用 CCR 是為了達到高可用性)，以及在第二或備份資料中心從遠端複寫儲存群組 (使用 SCR 是為了達到站台復原能力)。第二資料中心含有待命叢集，您可以啟動該叢集，並且在站台復原案例快速準備一個替代叢集信箱伺服器。
Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter
Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter
[圖 3] 描述了部署兩個資料中心的企業，每一個資料中心各有自己的 Active Directory® 站台：里德蒙和昆西。里德蒙站台位於主要 (實際執行) 資料中心，而昆西站台位於第二 (備份) 資料中心。將 CCR 部署在里德蒙，是為了達成資料中心內部備援能力。而將 SCR 目標連同 Exchange 2007 所需要的基礎結構元素，在昆西的待命叢集上設定，是為了達成站台復原能力。這些額外的基礎結構元素可能是專用或非專用的資源，它們包括 Client Access 和 Hub Transport Server、Active Directory 和 DNS 伺服器以及網際網路存取。專用資源是專門支援資源所在資料中心的使用者。非專用資源則是支援本機資料中心的使用者以及其他地方的使用者。您必須以對貴公司最有利的原則為前提，決定資源為專用還是非專用。如需專用和非專用資源的相關資訊，請參閱 Exchange Server 2007 說明檔主題「站台復原組態」，網址是 technet.microsoft.com/bb201662.aspx。另外在使用新型的多數節點組合 (MNS) 仲裁時也要多加注意。在 Exchange Server 2007 中，CCR 採用的是 MNS 仲裁和檔案共用見證 (FSW)，而不是傳統的票選 (Voter) 節點，如 [圖 3] 所示。
在 [圖 4] 當中，CCR 外加 SCR 環境具有復原能力，它為伺服器 EXCLUS1 上控管的信箱和服務提供了好幾層的備援，因此可以保護信箱，防止它們發生大小規模的嚴重失敗。
Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other
Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other
另外，SCR 也嘉惠了中小型企業。以 [圖 4] 為例，一家公司可以部署兩部獨立的信箱伺服器 (EXMBX1 和 EXMBX2)，並且使用 SCR，把一部信箱伺服器的儲存群組，部分或全部複寫到另一部 Mailbox Server。
在這個範例當中，EXMBX1 和 EXMBX2 都是實際執行伺服器，並具有五個作用中的儲存群組。每一個儲存群組，都是另一個伺服器上相對應 SCR 目標的 SCR 來源。如果發生儲存失敗，或者發生其他事件，導致設定為 SCR 來源的作用中儲存群組無法使用，只要使用 Exchange 管理命令介面中一些的管理工作，很快就可以啟動 SCR 目標複本。有了 Microsoft® Office Outlook® 2007 以及 Exchange 2007 的資料庫可攜性和自動探索功能，即使因為遺失作用中儲存群組 (或是同一個情況下遺失多個作用中儲存群組) 而導致停機，停機時間頂多也只有幾分鐘而已。

SCR 來源和目標
跟 LCR 和 CCR 一樣，SCR 也採用主動和被動複本的儲存群組概念，但它分別稱之為 SCR 來源和目標。儘管如此，SCR 來源和目標都是儲存群組複本 (復原儲存群組無法用於 SCR)。
SCR 的起點 (SCR 來源) 是單一複本叢集或 CCR 環境中獨立信箱伺服器上，或叢集信箱伺服器上的任何一個儲存群組。請注意，SCR 來源可以是叢集信箱伺服器，但因為 SCR 本身不是叢集解決方案，所以不需要 Windows 叢集服務。SCR 的結束點 (SCR 目標) 可以是獨立的信箱伺服器，也可以是容錯移轉叢集當中的一個節點 (這個容錯移轉叢集有安裝 Mailbox role，但是在叢集當中沒有設定任何叢集信箱伺服器)。

來源和目標的關係
每一個 SCR 來源儲存群組都可以有無限量的 SCR 目標。舉個例說，來源的其中一個目標可能位於與來源同樣的資料中心，第二個目標則位於另一個資料中心。但是，Microsoft 建議每一個來源不要超過四個目標。如果您決定使用四個以上的目標，就必須接受 SCR 來源伺服器在記憶體、CPU 和磁碟資源方面可能受到的衝擊，並且根據這一點加以規劃。每一部 SCR 目標電腦都可以有多部來源伺服器。來源和目標電腦都必須執行 Service Pack 1 for Exchange 2007。作業系統必須是 Service Pack 1 for Exchange 2007 支援的作業系統 (例如，Windows Server® 2008 或 Windows Server 2003 SP2)。但是，無論您使用的是哪一個作業系統，SCR 都沒有跨作業系統支援，因此它要求 SCR 來源上的作業系統，必須與該來源所有 SCR 目標上的作業系統一樣。因此，如果 SCR 來源是執行 Windows Server 2003，那麼該來源所有的 SCR 目標，也都必須執行 Windows Server 2003。
SCR 是附隨在 Exchange 2007 標準版中。如果 SCC 或 CCR 環境中的叢集信箱伺服器用作為 SCR 來源，就必須採用 Exchange 2007 企業版。使用企業版時，每一個 SCR 目標最多可支援 50 個執行個體 (50 個複寫的儲存群組)；而使用標準版時，最多可支援 5 個執行個體。
SCR 目標也有它必須符合的需求。首先，無論來源和目標電腦是在相同或不同的 Active Directory 站台上，都必須位於同一個 Active Directory 網域。另外，來源及其所有目標上的資料庫和記錄檔路徑，都必須與以 SCR 複寫的每一個儲存群組相符。最後，如果節點或伺服器是設定為 SCR 目標，您就不能在 SCR 目標電腦上的任何儲存群組啟用 LCR，也不能把任何叢集信箱伺服器加入獨立的容錯移轉叢集當中。

比較 SCR 與 CCR 和 LCR
SCR (如 [圖 5] 所示) 是採用 LCR 和 CCR 所用的同一種記錄傳送和轉送技術，來提供新的部署選項和設定。採用 SCR 的儲存群組與 LCR 和 CCR 一樣，都不能有超過一個資料庫。同樣的，如果 Exchange 組織結構當中的公用資料夾資料庫不只一個，SCR 也不能用於公用資料夾資料庫。
Figure 5 SCR is log shipping to another server or a passive node in a failover cluster
Figure 5 SCR is log shipping to another server or a passive node in a failover cluster
兩者的主要差別在於，SCR 在每一個儲存群組支援多個目標，而 LCR 和 CCR 只支援一個目標 (被動複本)。另一個主要差異是，SCR 複本無法備份，這一點與 CCR 和 LCR 不同。使用 SCR 時，若是向 SCR 來源儲存群組取得支援的備份 (或者，若是使用 CCR 和 LCR，則是向 SCR 來源儲存群組的主動或被動複本取得備份)，則會更新 SCR 目標的資料庫標頭，而且會截斷記錄檔。
與 LCR 和 CCR 一樣，透過 SCR 的記錄傳送會連續進行，並且是使用提取模式。 當新的記錄檔一關閉，並且以下一代序列記錄檔案號碼命名時，在 SCR 目標電腦上執行的 Microsoft Exchange 複寫服務，就會從 SCR 來源電腦提取關閉的交易記錄檔，檢查並驗證它們，然後將它們移到它們在 SCR 目標電腦上的對應儲存群組記錄檔案資料夾。

轉送延遲時間
當記錄檔複製到 SCR 目標電腦之後，SCR 會採取一些動作，但 LCR 和 CCR 不會。SCR 不會立刻將記錄檔轉送到資料庫複本中，而是強制執行內建延遲功能，將 50 個記錄檔延遲 24 小時。除了這些內建延遲功能之外，SCR 也容許您另外指定其他時間延遲。在很多情況下，延遲轉送活動都能派上用場。舉個例說，如果作用中資料庫發生邏輯損毀，延遲便能防止 SCR 目標資料庫發生邏輯損毀。
由系統管理員控制的轉送延遲，是利用一個稱為 ReplayLagTime 的參數所設定，它負責指定 Exchange 複寫服務應該等待多久，才能轉送被複製到 SCR 目標電腦上的記錄檔。其格式是 Days.Hours:Minutes:Seconds，預設值是 24 小時。此值的設定上限是七天，下限是零秒，如果將此值設為零秒，就能有效刪除記錄轉送活動中任何超過預設 50 個記錄檔的延遲活動。
無論 ReplayLagTime 的值為何，除了 ReplayLagTime 之外，Exchange 還有一個內建限定 50 個記錄檔的延遲。Exchange 是使用較大的 ReplayLagTime 或 x 個記錄檔 (x=50)，來判斷何時轉送記錄檔。萬一使用連續複寫的 SCR 來源 (例如，CCR 環境中的叢集信箱伺服器) 遭遇容錯移轉，而必須以 Restore-StorageGroupCopy 指令程式讓其中一或多個儲存群組上線，為了避免在這些情況下重新植入儲存群組，於是多這麼一層安全保護 (所謂植入 (Seeding)，是指使用 Extensible Storage Engine (ESE) 串流備份 API，在 SCR 目標電腦上製作 SCR 來源資料庫的線上複本)。延遲 SCR 目標轉送活動的好處是，萬一 SCR 來源發生失真容錯移轉時，可以盡可能減少重新植入 SCR 複本的需要，因為一旦 SCR 來源遺失資料，此舉會及時將兩個複本放在一起。

截斷延遲時間
在 Exchange 2007 RTM 版中，連續複寫環境強制規定除非記錄檔已經備份，並且已轉送到資料庫複本中，否則不會將它們刪除。但在使用 SCR 時，這個規則已經過修改。只要 SCR 來源電腦上的記錄檔經過所有 SCR 目標電腦的檢查，SCR (介紹了多資料庫複本的概念) 便容許截斷這些記錄檔。SCR 來源伺服器不會等到所有的記錄都轉送到所有的 SCR 目標之後才截斷記錄，因為您可以用很高的記錄轉送延遲時間來設定 SCR 目標複本。
您也可以使用一個稱為 TruncationLagTime 的新參數，在記錄截斷另外加入延遲，這個參數會指定 Exchange 複寫服務要等待多久 (採用 Days.Hours:Minutes:Seconds 格式)，再截斷已複製到 SCR 目標電腦上、且轉送到資料庫複本中的記錄檔。只要記錄檔一經順利轉送到資料庫複本，就表示該時段開始了。此值的上限是七天，而下限是零秒 (不過零秒便能有效去除記錄截斷活動中的任何延遲動作)。
在 SCR 環境中，每三分鐘就會執行一個背景執行緒，以判定是否有記錄檔需要截斷。如果記錄檔產生順序是低於儲存群組的記錄檔檢查點，而且這個記錄檔早於 ReplayLagTime + TruncationLagTime，那麼 SCR 目標上就會有一個記錄檔被截斷。
在以 SCR 延伸的 LCR 或 CCR 環境中，如果符合下列四個條件，就會截斷 SCR 目標上的一個記錄檔：記錄檔已經備份、記錄檔產生順序低於儲存群組的記錄檔檢查點、儲存群組的被動複本容許記錄檔被截斷，而且所有 SCR 目標都已經檢查過這個記錄檔。

啟用和管理 SCR
SCR 是以 Exchange 管理命令介面中的 Enable-StorageGroupCopy 指令程式來啟用，這個指令程式在 SP1 中已經過更新並加入一些新參數。如前所述，ReplayLagTime 和 TruncationLagTime 可讓您控制 SCR 目標的一些行為。另一個參數 SeedingPostponed 則可用來跳過初次植入 SCR 目標的動作。在許多情況下，延遲植入都能派上用場。舉個例說，假設儲存群組中 SCR 所用的資料庫有 100GB，您應該不希望在尖峰執行時間時，讓所有 100GB 的資料都在網路上周遊。SeedingPostponed 參數可以讓您選擇立即啟用 SCR，稍後再執行植入工作。只要等您準備就緒，就可以使用 Update-StorageGroupCopy Cmdlet，手動植入 SCR 目標。
上面提及的參數都是選擇性參數，但是其中一個 Enable-StorageGroupCopy 參數，卻是 SCR 的必要參數：StandbyMachine。它會指定含有 SCR 目標的電腦的名稱。這個參數的值，是設為 SCR 所用的 msExchStandbyCopyMachines 屬性值一部分。msExchStandbyCopyMachines 屬性是一種多值的 Unicode 字串，它是在 Exchange 2007 SP1 引進 Exchange 組織結構時，加入到 Active Directory 結構描述中，這也是 SP1 需要更新 Active Directory 結構描述的原因之一。
StandbyMachine 參數是 SCR 的核心，SP1 當中有好幾個指令程式經過更新都是為了使用這個參數來啟用和管理 SCR 目標。[圖 6] 說明更新的 Cmdlet。
Figure 6 Cmdlets that use the StandbyMachine parameter (Close Figure 6)

Cmdlet | 描述
Disable-StorageGroupCopy | 停用儲存群組的 SCR 目標。
Get-StorageGroupCopyStatus | 決定 SCR 目標的目前健康狀態。
New-StorageGroup | 不必以 Enable-StorageGroupCopy 指令程式另外啟用 SCR，即可建立新的 SCR 儲存群組。
Restore-StorageGroupCopy | 停用 SCR，將 Mount-Database 作業當作復原程序的一部分，讓 SCR 目標資料庫進行裝載。
Resume-StorageGroupCopy | 目的是讓暫停 SCR 的儲存群組繼續進行連續複寫。
Suspend-StorageGroupCopy | 讓啟用 SCR 的儲存群組暫停連續複寫活動。
Update-StorageGroupCopy | 目的是植入或重新植入 SCR 目標儲存群組。

啟動 SCR 目標
SCR 提供一或多個最新資料複本，可以在原始資料遺失或無法使用時派上用場。採用 SCR 目標複本，將它重新作為實際執行資料庫的程序，舊稱為啟動。啟動是修復程序的一部分，它是以資料庫可攜性，或是其中一種安裝復原選項的形式存在 (/m:RecoverServer 是用於修復獨立伺服器，或者 /RecoverCMS 是用於修復叢集信箱伺服器)。

運用 SCR
接下來我們要看看一家虛構的公司，如何使用 SCR 和資料庫可攜性來復原信箱資料庫的失敗。當您發現實際執行資料庫損毀之後，系統管理員會使用資料庫可攜性來啟動 SCR 目標資料庫。
該公司部署了附隨 SP1 的 Exchange 2007，並且決定運用 SCR，在遠端信箱伺服器提供一份儲存群組的複本。來源和目標信箱伺服器都位於同一個 Active Directory 站台，並且都經過設定採用與 Active Directory 整合的 DNS 伺服器。Active Directory 複寫間隔是設定為 15 分鐘。

啟用 SCR 和接移復原
SCR 的設定方式，是針對含有單一資料庫 MBX1 的單一儲存群組 SG1 來複寫交易記錄檔。儲存群組檔案和資料庫檔案的路徑是 C:\SG1 和 C:\SG1\MBX1.EDB。在本例中，EXMBX1 是 SCR 來源，EXMBX2 是 SCR 目標。其設定如下所示：
Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
啟用 SCR 之後，SG1 所用的 SCR 的健康與狀態，是由 Get-StorageGroupCopyStatus 指令程式負責驗證：
Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2
為了節省 SCR 目標啟動程序的時間，EXMBX2 以儲存群組 SG1PORT 和資料庫 MBX1PORT 經過預先設定，作為資料庫可攜性作業的一部分。SG1PORT 和 MBX1PORT 則獨立於 SCR 目標的儲存群組和資料庫檔案之外。因此，SG1PORT 和 MBX1PORT 的路徑，是以與 SCR 目標路徑不衝突的暫時路徑加以設定。SG1PORT 和 MBX1PORT 將只作為資料庫可攜性物件使用；SG1PORT 的實際儲存群組和資料庫檔案則不需要。因此，系統管理員會卸載 MBX1PORT，並刪除儲存群組中所有的檔案。儲存群組和資料庫物件則留在 Active Directory 中，因為它們會在稍後進行復原程序時用到，以達到資料庫可攜性。

啟動和復原
根據應用程式事件記錄項目指出，SCR 來源資料庫實際上已經毀損。由於 SCR 是用於 SG1，因此決定手動啟動 SG1 的 SCR 目標資料庫，並且利用資料庫可攜性來還原資料庫可用性。要啟動 SCR 目標複本，就必須先以下面這個指令程式來卸載 SG1 中的 MBX1。
Dismount-Database EXMBX1\SG1\MBX1
接著再啟用 SCR 目標資料庫進行裝載，並且使原先在 MBX1 的信箱重新隸屬於 MBX1PORT。
在停用 SCR 以及啟用 SCR 目標資料庫進行裝載時，會執行 Restore-StorageGroupCopy Cmdlet。這項工作會將儲存群組的資料庫標示為可以裝載，並且提供因為在儲存群組中裝載資料庫而導致資料遺失的相關報告 (如果有的話)。同時它也會驗證所有由儲存群組主動複本所產生的記錄檔，的確是出現在被動複本的儲存群組檔案位置。如果有任何記錄檔遺漏，這個作業也會想辦法加以複製。下面這個指令程式的目的，是讓 SCR 目標資料庫進行裝載：
Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2
在本例中，您可以複製來自 SCR 來源儲存群組的記錄檔。如果這些檔案無法使用 (比方說，因為 SCR 來源電腦當機)，就必須將 Force 參數加到 Restore-StorageGroupCopy 工作中。否則 Restore-StorageGroupCopy 就會不斷地想辦法連接 SCR 來源，來複製任何遺漏的記錄檔，而且如果 SCR 來源無法使用，Restore-StorageGroupCopy 工作就會失敗，資料庫也就無法進行裝載。加入 Force 參數的用意，只是告訴 Restore-StorageGroupCopy 工作來源檔無法使用，並不會處理連線動作，而是直接讓 SCR 目標資料庫進行裝載。
Restore-StorageGroupCopy 命令完成之後，系統管理員必須驗證資料庫是否處於正常關機狀態。如果資料庫是處於不正常關機的狀態 (請參閱 technet.microsoft.com/aa996757.aspx)，就必須將它正常關機。如果儲存群組的記錄檔前置詞 (例如，E00 或 E01) 與 SCR 來源 (EXMBX1\SG1) 一樣，同時也與 SCR 目標 (SG1PORT) 上為了達成資料庫可攜性 (EXMBX2\SG1PORT) 所用的儲存群組相同，那麼就不需要以復原模式執行 Eseutil，而且最後的資料庫裝載作業，會在所有複寫的記錄檔全部轉送之後，將資料庫正常關機。如果資料庫不是處於正常關機狀態，則必須對該資料庫執行 Exchange Server 資料庫公用程式 (Eseutil) 復原模式 (Eseutil /r)。
一旦資料庫處於正常關機狀態，您就可以執行兩個命令，將 Active Directory 更新儲存群組檔案和資料庫檔案的新位置。這些命令會將 SG1PORT 和 MBX1 的路徑，從原始路徑改為接移儲存群組和資料庫的路徑 (SG1PORT 和 MBX1PORT)：
Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly
上述命令必須包含 –ConfigurationOnly 參數，因為這麼一來，就只會在 Active Directory 中更新這些物件的設定。任何資料或檔案都不會移動，也不必移動，因為 SCR 已將資料複寫到 EXMBX2 的 C:\SG1 了。
接下來就是設定資料庫 (MBX1PORT)，容許它本身在復原作業時被覆寫。這個動作可以藉由兩種方式完成，一是在 Exchange 管理主控台中，勾選資料庫物件屬性上 [此資料庫可被還原覆寫] 設定的核取方塊，一是使用 Exchange 管理命令介面中的下面這個命令：
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true
一旦設定資料庫容許本身被覆寫之後，下一步就是以下述命令裝載資料庫：
Mount-Database EXMBX2\SG1PORT\MBX1PORT
資料庫裝載之後，必須使位於 SCR 來源資料庫上的信箱 (SG1\MBX1) 重新隸屬，並指向 EXMBX2 上的 MBX1PORT。做法很簡單，只要執行 Get-Mailbox cmdlet，並且將輸出傳送至 Move-Mailbox 指令程式即可。在這個過程當中，絕不可將 Exchange 系統服務員和系統信箱包含在從 Get-Mailbox 指令程式傳送到 Move-Mailbox 指令程式的輸出中。因為那些信箱物件不需要重新隸屬，也不應該這麼做。下面這個命令的目的是重新隸屬所有的使用者信箱，並且排除系統信箱：
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}|Move-Mailbox-ConfigurationOnly -TargetDatabase EXMBX2\SG1PORT\MBX1PORT
這時候，用戶端就可以存取 MBX1PORT 了。但是，信箱從 EXMBX1\SG1\MBX1 移到 EXMBX2\SG1PORT\MBX1PORT 之後，使用者是否能夠實際存取他們的信箱，還得視 Active Directory 複寫延遲而定；也就是說，在環境中傳播更新可能要花點時間，而花多少時間則要根據目錄伺服器的數目而定。此外，用戶端存取的方法也有關係：當使用者用戶端存取伺服器所用的目錄伺服器更新路徑之後，執行 Outlook 2007 的郵件用戶端以及非 Outlook 的用戶端就有權存取使用者的信箱了。執行 Outlook 2003 及舊版 Outlook 的郵件用戶端，會要求使用者的桌面郵件服務設定檔更新伺服器的名稱。

最後步驟
當用戶端有權存取他們的信箱和信箱資料之後，接下來只要重新啟用 SCR 來建立備援即可。做法是從 EXMBX1 移除所有剩下的儲存群組和資料庫檔案。檔案被移除之後，可以將 EXMBX1\SG1\MBX1 的路徑移到暫時位置，而 EXMBX1 則成為 EXMBX2 的 SCR 目標。

Scott Schnoll 是 Microsoft Exchange Server 小組的首席技術文件作者，負責撰寫 Exchange Server 2007 方面的文章。在加入 Microsoft 之前，Scott 曾寫過《Exchange Server 2003 Distilled》(Addison-Wesley Professional，2004 年)，而且是《Exchange 2000 Server: The Complete Reference》(McGraw-Hill/OsborneMedia，2001 年) 的主要作者。


 通訊: 透過 Windows Server 2008 執行 Exchange
通訊 Paul Bowden

透過 Windows Server 2008 執行 Exchange
摘要:
  • 在 Windows Server 2008 上設定 Exchange
  • 設定秘訣與訣竅
  • 了解您的 Exchange 環境

我在 Microsoft 的 Exchange 開發小組負責安排小組的時間表、工作節奏和優先事項，這個角色在 Microsoft 叫做發行經理，相當於在其他公司的技術專案經理。在只要這個領域工作過的人
都知道，要準時推出良好的產品，需要的不光是知識、技能、努力，還要有團隊齊心齊力才辦得到。與這麼優秀的團隊合作，要贏得他們的信任可不是一蹴可幾，必須一分耕耘才有一分收穫。
要證明您的勇氣，其中一種方法就是在「狗食 (dogfood)」伺服器，也就是實際執行 Excahnge 搶鮮版的伺服器上執行自己的信箱。在這個多變的環境內，每兩三個禮拜就會升級成新版的 Exchange 組建，也因此讓我們得以在充滿真實人為互動的環境中測試軟體。我們甚至還在最新版的測試組建上執行自己的信箱。以下就是我個人的經驗談。

準備好迎接 "Longhorn"
2006 年底甫推出 Exchange Server 2007 時，有個新的作業系統正嶄露頭角 — Windows Server® (產品代碼是 "Longhorn")。正當我們開始為推出新版 Exchange 平台的第一個 Service Pack 訂定計畫時，很快也注意到 Exchange 與 Windows® 的時間表雷同，而且 "Longhorn" (現在稱為 Windows Server 2008) 必將聲勢不凡。我們當下就決定推出的 Exchange Server 2007 SP1 要同時針對 Windows Server 2003 和 Windows Server 2008。要在多重版本的 Windows 上支援企業應用程式，所需投入的協調和規劃心力實在龐大，像是 Exchange 與 IIS 合作密切，而且 Windows Server 2008 中包含了一個新版本 IIS 7.0。
猶記 2006 年 12 月底在實驗室裡初次安裝 Windows Server 2008 的情景，那天有兩件事情讓我印象深刻：第一是安裝速度飛快；第二是管理工具雖然不同於 Windows Server 2003，卻非常容易使用。
在我們的主實驗室中，安裝 Windows Server 2008 的時間約只要 Windows Server 2003 的三分之一。時間之所以縮短，其中一個因素是並未安裝選用元件，因為這並不是執行作業系統的必備項目，也不是預設設定。這對於縮小電腦的受攻擊面和盡可能保持簡化頗有幫助，畢竟不必要的雜亂是人人唯恐避之不及。這類安裝最典型的缺點是每次想新增其他元件時，都必須插入光碟。不過，Windows Server 2008 中所有的檔案都已經複製到 SxS 資料夾 (唸成 SxS，字字分開唸)，您只要使用伺服器管理員工具設定所需的元件，作業系統就會為您找出要複製的檔案。
裡說到這裡，不能不介紹一種叫伺服器核心的東西。這是 Windows Server 2008 裡的一種模式，可用來安裝最基本的作業系統。這種模式甚至連檔案總管都未安裝，因此一般是透過命令提示與伺服器主控台互動。這種模式非常適合基礎結構伺服器，例如網域控制站和 DNS 伺服器。不過，您在這裡不能執行任何一種類型的應用程式。Exchange 採用大量的 Managed 程式碼，而使它不能支援伺服器核心安裝。

設定 Exchange
我最愛在機器上拿實際的 Windows Server 2008 和 Exchange Server 2007 SP1 媒體從頭開始安裝，根本不必擔心下載其他東西或是否符合先決條件。為 Exchange 設定 Windows Server 2008 安裝最佳的方法是使用 ServerManagerCmd 工具。我精心製作了一個 XML 回應檔案，如 [圖 1] 所示，它只會安裝足夠的作業系統元件好讓 Exchange 在 Windows Server 2008 上安裝和執行。新的作業系統一經安裝，直接執行這個命令就可以設定系統說：
Figure 1 ServerManagerCmd answer file for Exchange (Close Figure 1)
<!-- ServerManagerCmd 回應檔案與 Windows Server 2008 相容        --> <!—使用：ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration Action="Install" xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE:安裝 PowerShell 1.0 功能 --> <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA:安裝 LDIFDE 和其他目錄工具，如 LDP 及 ADSIEdit --> <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX:安裝網頁伺服器角色與其他子元件 --> <Role Id="Web-Server"/> <RoleService Id="Web-Metabase"/> <RoleService Id="Web-Lgcy-Mgmt-Console"/> <RoleService Id="Web-Basic-Auth"/> <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS:針對 OWA、GZip 壓縮再加上「Outlook 無所不在」支援安裝三個驗證類型 --> <RoleService Id="Web-ISAPI-Ext"/> <RoleService Id="Web-Digest-Auth"/> <RoleService Id="Web-Dyn-Compression"/> <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE:安裝 Active Directory 輕量型目錄服務 (原先稱為 ADAM) --> <Role Id="ADLDS"/>

    <!-- UM:安裝 Windows Media Player 元件 --> <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
完成這個步驟並且也重新啟動系統後，您就擁有安裝 Exchange 角色 (例如 Mailbox、Client Access、Hub Transport、Edge Transport 和 Unified Messaging) 所需的一切。
另外一個有用的訣竅是使用 ServerManagerCmd 搭配 –query 參數，這樣就能完整列出所有的角色和服務，並顯示實際上設定的有哪些 (在 [圖 2] 中是以綠色文字表示)。
Figure 2 Enumerating Exchange roles and services
Figure 2 Enumerating Exchange roles and services
言歸正傳，我們在 2007 年的頭幾個月埋首實驗室，不斷摸索在 Windows Server 2008 獲得絕佳效能所需的變更。如果硬要說有什麼心得，就是可以在實驗室不斷地安裝軟體、進行壓力測試，直到你頭昏眼花。不過，品質好不好，取決於真實、即時的部署以及活生生的使用者。這也正是為什麼我們對產品進行「狗食」實驗的原因 — 在真實、日常、處理工作的使用情況下進行測試。2007 年 4 月發行的 Windows Server 2008 Beta 3 是個轉折點，是勇敢將它部署到生產環境中的時候了。
我坐在那邊望著作業小組成員在 Windows Server 2008 上部署第一組 Exchange 伺服器。Exchange 的安裝進行得很順暢，所有服務也都開始運作。現在的工作只剩下移動信箱，並確定它是否真的可以操作。我自願當實驗對象，我有一個 2GB 的信箱，經過 26 分鐘之後，便能在 Windows Server 2008 上使用 Exchange 成功傳送電子郵件！

心得
自從那次在 Windows Server 2008 進行初次安裝後，我們就不斷地進行微調，確定真的準備好上場。這一路上我們的確也碰到過必須作出重大部署決策的時候。
安裝 您可以使用 Exchange Server 2007 SP1 做為原始 Exchange Server 2007 安裝的升級 — 也就是我所謂的 Exchange 2007 RTM (量產發行版) — 或是在全新的電腦上直接使用 Exchange Server 2007 SP1 媒體安裝。這很重要，因為您不能將 Exchange Server 2007 RTM 安裝在執行 Windows Server 2008 的電腦上。
升級 雖然您可以將作業系統就地從 Windows Server 2003 SP2 升級到 Windows Server 2008，但必須先解除安裝某些元件，其中一個就是 Windows PowerShell™。這是 Exchange 管理的核心，即使是 Exchange 安裝也是以 Windows PowerShell 為基礎。因此，我們不支援在已經安裝 Exchange 時就地升級作業系統。對許多人來說，這一般是指您應該將 Windows Server 2008 安裝在全新的電腦上，然後安裝 Exchange Server 2007 SP1。
IPv6 Exchange 是為了利用 Windows Server 2008 中的幾項新功能而設計的。舉例來說，預設會安裝 IPv6，而兩部在新作業系統上執行的 Exchange 伺服器會自動使用 IPv6 來彼此通訊。Exchange 管理主控台中的介面也接受 IPv6 位址範圍。但有一點要注意：Exchange 仍要求 IPv4 位址需繫結到每個網路介面。
唯讀網域控制站 針對 Active Directory® 部署有項還算重大的變更，那就是唯讀網域控制站 (或通用類別目錄伺服器) 的概念。這可讓各公司部署只接受單向複寫且無法將變更往回複寫的 Active Directory 伺服器。這很適用於無法保證實體安全性的分公司或遠端辦公室的情形。可惜的是 Exchange Server 2007 SP1 無法利用唯讀網域控制站，而且需要存取可正常寫入磁碟分割的 Active Directory。

您的 Exchange 環境
Exchange 和 Windows Server 資源
  • Windows Server 2008 TechCenter
  • Exchange Server TechCenter
  • TechNet Evaluation Center
  • Windows Server 2008 虛擬實驗室

說到為您的部署選擇作業系統等級，您的彈性還蠻大的，可以選擇執行各種不同設定，如 [圖 3] 所示。
Figure 3 Exchange environment matrix (Close Figure 3)

Exchange 版本 | 伺服器作業系統 | 網域控制站
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
另一個考量點是混合版本部署。您絕對可以混合 Exchange 和 Windows 版本，彼此交互操作。比方說，您可以在 Windows Server 2008 上部署 Exchange Server 2007 SP1 作為 Client Access Server，讓它們存取 Windows Server 2003 信箱伺服器上的 Exchange Server 2007 RTM。
舊版的 Exchange 與 Windows Server 2008 Active Directory 有些微妙的差異需要特別注意。如果您裝有 Exchange Server 2003 SP2 及更新的版本，可以在環境中部署和使用 Windows Server 2008 網域控制站。然而，假若您還有部署 Exchange 2000，可能要延緩在那些 Exchange 伺服器所在的 Active Directory 站台內部署 Windows Server 20008 網域控制站，或是將 Directory Service Access (DSAccess) 設定寫死在程式中，這樣一來 Exchange 2000 就不會嘗試使用 Windows Server 2008 網域控制站。

感想
我們投入了相當大的心力讓 Exchange 2007 SP1 在 Windows Server 2003 和 Windows Server 2008 兩種平台上順利運作。在 Exchange 中，我們盡力提供部署彈性以及搭配運作更佳的案例。我認為，您會訝於在 Windows Server 2008 上部署 Exchange 的簡便與速度，也會注意到內部效能和延展性稍有增強，例如針對「Outlook 無所不在」用戶端提供的絕佳 Client Access Server 延展性。
Windows Server 2008 在傳訊的空間裡提供了創造未來革新的平台。您肯定不會失望。

Paul Bowden 是 Exchange Server 小組的部門經理 (Lead Program Manager)。他大部分的空閒時間都花在應他人要求重新確認自己的 PayPal。


 通訊: 透過 Exchange Server 2007 部署整合通訊
通訊 Jeff Goodwin

透過 Exchange Server 2007 部署整合通訊
摘要:
  • 電話語音基本知識
  • 整合通訊設計考量
  • 遷移使用者

您終於下定決心，要在環境中部署 Exchange Server 2007 整合通訊，也安裝了 Unified Messaging server role，並將它與現有的 PBX 相互整合，現在您和其他 10 名員工都可使用存放在 Exchange 內的語音信箱、電子郵件及傳真訊息。過去，您
曾將這視為一大成就。但是要如何部署，才能在不影響業務的情況下，讓橫跨多個站台的數千名訂閱者也能享用相同功能呢？
希望您能在本文中找到答案。我撰寫這篇文章的用意，是為了協助您瞭解如何在環境中部署整合通訊，並釐清與這類部署作業相關的電話語音概念。如果您在 Exchange Server 2007 整合通訊的安裝、設定及各項功能方面有需要協助，請參閱本文最後的「整合通訊資源」資訊看板。此外，Microsoft 已將一些公司視為「整合通訊專家」協助客戶諮詢、設計和部署 Exchange Server 2007 整合通訊。如需有關安裝、設定或部署方面的協助，請與資訊看板上所列的這些專家連絡。

入門
Exchange 對整合通訊技術並不陌生，許多組織都曾提供與 Exchange 搭配使用的整合通訊產品。不過，這是 Exchange 破天荒由自身提供支援的整合通訊版本。自問世以來，許多客戶都將 Exchange Server 2007 整合通訊部署到組織內部的小組中。然而基於種種原因，這些客戶不見得會為所有使用者部署整合通訊。問題之一在於，很多 Exchange 系統管理員不太瞭解實作整合通訊服務所必備的電話語音概念及技術，因此難以在企業中設計和部署這些解決方案。
正如任何部署專案一樣，分段式的方法往往能獲得最大功效。規劃架構、測試解決方案、試驗使用者社群、教育訓練以及將使用者遷移至新系統，上述五個階段涵蓋了整合通訊專案所需考量的所有面向。在規劃專案的過程中，務必要讓組織內部的 IT 與電信小組一同參與。
使用者在語音信箱平台上慣用的許多功能必須照樣提供，如果做不到，也必須設計替代的解決方案，以減輕實作新系統時對使用者社群造成的影響。您的電信小組必須在這個關鍵領域提供協助，不僅如此，在部署的過程中，電信小組也需要向 IT 小組學習如何管理、疑難排解和支援新的語音信箱平台。

電話語音基本知識
您將發現，如果您瞭解整合通訊的相關基本架構、呼叫流程和技術的話，會更容易規劃部署。[圖 1] 顯示整合通訊解決方案與現有的企業電話語音系統整合的範例。現在就讓我們進一步討論一些您在這類部署中可能遇到的最基本概念與技術。
Figure 1 A PBX-to-Unified Messaging solution
Figure 1 A PBX-to-Unified Messaging solution
專用交換機 (PBX) 是企業內部使用的私用電話網路。在這種系統上，每位使用者通常都有一台與 PBX 相連接的有線電話，透過撥打分機號碼 (一般為四或五個數字) 可以與其他內部使用者通話，也可以撥打外線電話。
如果企業客戶有許多不同位置的 PBX，有時他們會決定透過 PBX 供應商專門的網路技術將這些系統串連起來。如此一來，網路 PBX 上的所有使用者只要撥打分機號碼就可以互相通話。
整合通訊需要結合兩個異質系統：Exchange 訊息系統與實體的電話語音系統。Unified Messaging Server 和電話語音架構之間的通訊是利用工作階段初始通訊協定 (SIP) 來完成。有些 PBX 技術可以直接透過 SIP 與 Unified Messaging Server 通訊，而有些則需要利用 SIP 閘道。在 [圖 1] 中，PBX 經由 T1 線路連線到 SIP 閘道。當呼叫轉送到整合通訊時，PBX 會傳送資訊 (呼叫方電話號碼、被呼叫方電話號碼和某種理由代碼類型) 到 SIP 閘道，好讓 Unified Messaging Server 知道要呼叫誰。
有些 PBX 可以透過 IP 網路來網路化。電話網路能夠透過 IP 網路將呼叫重新導向到集中處理的語音信箱解決方案。例如，在 [圖 2] 中，您會看到蘇黎世連回倫敦的網路。
Figure 2 A more complex Unified Messaging deployment
Figure 2 A more complex Unified Messaging deployment

呼叫流程
整合通訊資源
  • 整合通訊專家名冊
  • Exchange Unified Messaging TechCenter
  • 支援的 SIP 閘道
  • 電話語音顧問
  • PBX 組態筆記

假設有一個外部呼叫者向整合通訊用戶電話提出呼叫。此時，整合通訊用戶不在辦公室，因此無人接聽電話。您可以參考 [圖 1] 中的訊息路徑。
PBX 將呼叫傳送至 SIP 閘道，而 SIP 閘道會在 TCP 上經由 SIP 與 Unified Messaging Server 交涉此呼叫。伺服器收到來自 SIP 閘道的整合資料，且 SIP 閘道會告知伺服器呼叫對象是誰。Unified Messaging Server 接著播放用戶的問候語，並讓外部呼叫者留言。這段留言訊息隨後被傳遞到整合通訊用戶的 Exchange 信箱。
上述的呼叫流程已經過大幅簡化。重點是，當留言訊息被記錄時，Unified Messaging Server 會透過 SMTP 將此訊息轉送到 Hub Transport Server 以便傳遞至 Mailbox Server。
身為整合通訊用戶，使用者現在可以經由電話 (使用 Outlook® 語音存取) 或電腦 (使用 Outlook 2007 或 Outlook Web Access) 存取自己的 Exchange 信箱。不過用戶也可以藉由名為「在電話上播放」的功能，利用 Outlook 2007 或 Outlook Web Access 透過電話存取訊息，這個功能可讓用戶的整合通訊以指定的電話來播放選取的訊息，而不用透過電腦存取訊息。使用此方法時，Unified Messaging Server 會同時與 Client Access Server 還有 Mailbox Server 兩者互動。知道這點很重要，因為如果您將 Unified Messaging Server 部署在沒有本機 Client Access Server 的遠端辦公室中，Unified Messaging Server 就必須周遊 WAN 以連絡 Client Access Server，而這項作業可能會造成效能不彰。

系統設計
客戶可以採用兩種核心 Exchange 架構設計：集中式或非集中式。一般來說，整合通訊架構會遵循您的 Exchange 架構，也就是說，只要您部署 Mailbox Server，就也會部署 Unified Messaging Server。當然，凡事都有例外。
設計整合通訊架構時，您需要設想五個基本層面。
  • 伺服器放置地點
  • Unified Messaging Server 數量
  • SIP 閘道
  • 信箱儲存體
  • 整合通訊站台組態
也別忽略了業務持續性。一般來說，與 Exchange 相關的嚴重損壞修復計劃可用來確定整合通訊的相關項目。
部署方案範例可協助您瞭解 Unified Messaging Server role。[圖 2] 清楚地顯示大型企業部署 Exchange Server 2007 與整合通訊的情況。
在這個比較複雜的部署設計中，西雅圖與倫敦是主要的資料中心。位於這些地點的 Unified Messaging Server 為各自的使用者社群提供服務，因為 Mailbox Server 和 Hub Transport Server 都是本機性質的。這兩個站台都有 IP PBX 可提供本機 Unified Messaging Server 的呼叫涵蓋範圍以進行自動答錄服務。
中型站台設於紐約與格拉斯哥。位於這些地點的 Unified Messaging Server 為各自的使用者社群提供服務，因為 Mailbox Server 和 Hub Transport Server 都是本機性質的。正如主要資料中心一樣，這兩個站台也都有 IP PBX 可提供本機 Unified Messaging Server 的呼叫涵蓋範圍以進行自動答錄服務。
小型站台沒有本機的 Mailbox Server 或 Hub Transport Server，但可以從主要資料中心提供整合通訊功能。奧斯丁設有 NEC PBX，可使用類比連線連接到本機 SIP 閘道。對本機使用者的呼叫會轉送到 SIP 閘道，SIP 閘道接著與西雅圖的 Unified Messaging Server 交涉，以便在整合通訊上提供自動答錄服務。
蘇黎世站台裝有 Avaya 通訊管理員，已透過 IP 網路與倫敦站台的 Avaya 通訊管理員網路化。對本機使用者的呼叫會在 Avaya 通訊管理員網路上轉送，而 Avaya 通訊管理員也會與倫敦的 Unified Messaging Server 交涉，以便在整合通訊上提供自動答錄服務。
在此範例中，西雅圖站台將 Exchange Mailbox Server 與 Unified Messaging Server 部署在同一個實體位置。在處理單一站台架構時，所有伺服器 (Mailbox、Unified Messaging、Client Access 等等) 和 PBX 設備都會包含在相同的站台中。為具有多個站台的企業設計比較複雜。這種複雜性看來似乎很沈重，但只要正確理解整合通訊的某些基本原則，就會比較容易控制。
如 [圖 2] 所示，如果站台包含 Mailbox Server，最好也在此設置 Unified Messaging Server。西雅圖、倫敦、紐約和格拉斯哥都符合此設計原則。奧斯丁或蘇黎世沒有本機的 Mailbox Server，不過藉由 IP 網路，仍然可為這些站台提供整合通訊服務。奧斯訂設有本機類比 PBX。在這種情況下，就必須使用 SIP 閘道來提供與西雅圖的 Unified Messaging Server 之間的 IP 網路連線機制。蘇黎世設有本機 IP PBX，可透過網路連回倫敦 PBX。因此，對蘇黎世使用者的呼叫將周遊電話網路並傳回倫敦 PBX 及 Unified Messaging Server。
由於對蘇黎世用戶的呼叫是在網路上周遊，並且由位於倫敦的集中式整合通訊系統處理，因此如果網路發生中斷現象，對於所有蘇黎世用戶的呼叫就會無人應答，直到網路修復為止。如果必須在發生網路中斷事件時確保網路存留能力，Unified Messaging Server 可以設置在蘇黎世。發生網路中斷事件時，Unified Messaging Server 會繼續回應呼叫，並在網路修復時傳送這些呼叫。
在設計符合您的環境的架構時，伺服器放置地點可能是您要考量的首要因素。[圖 3] 中的流程圖可輔助您決定適當的伺服器放置地點。
Figure 3 Determining server placement
Figure 3 Determining server placement

評估伺服器需求
下一個要考慮的層面是您需要多少 Unified Messaging Server 來支援使用者社群。這個問題的答案實際上取決於多項因素，而且這些因素都跟站台情況有關。
整合通訊的延展性是由伺服器可支援的同時呼叫 (在電話語音世界中的被呼叫連接埠) 數量多寡來決定。每個進入系統的呼叫都需要 Unified Messaging Server 指定網路、CPU、記憶體和磁碟資源。藉由增加這些資源，可讓 Unified Messaging Server 支援更多同時呼叫。由於這些資源總有限制，因此在資源超載之前，Unified Messaging Server 只能處理一定數量的同時呼叫。
您可以利用 Erlang 流量分析計算來確定您需要多少連接埠來支援用戶數，在此我就不細述。有一個比較簡單的方法可以確定所需的連接埠數量，就是直接詢問電話語音管理員在現有的語音信箱系統上，總共用了多少語音信箱連接埠。根據實際經驗，傳統語音信箱系統的連接埠需求與整合語音信箱系統的需求很相近。
通常我會建議在單一伺服器上不要實作超過 60 個連接埠。這與軟硬體限制無關。而是因為包含 60 個連接埠的單一伺服器大約可支援 5,000 位使用者。如果這部單一伺服器發生中斷現象，就會讓單一伺服器的失敗連累整個 (龐大的) 用戶群。
實作 Unified Messaging Server 時，您可能會考慮在架構中設計 N+1 備援。[圖 4] 顯示完全多餘的伺服器與 SIP 閘道設計。利用這項設計，當 Unified Messaging Server 1 發生中斷事件時，來自 SIP 閘道 1 的呼叫會自動與 Unified Messaging Server 2 交涉呼叫。您也可以採用程式設計的方式讓 PBX 在 SIP 閘道上平均分散呼叫負載量。例如，進入系統的第一個呼叫可以路由至 SIP 閘道 1，而下一個進入系統的呼叫可以路由至 SIP 閘道 2。在閘道上交替處理呼叫有助於在 Unified Messaging Server 上平均分散呼叫和負載共用。
Figure 4 Distributing calls between servers for redundancy
Figure 4 Distributing calls between servers for redundancy
Exchange Server 2007 整合通訊解決方案目前支援兩個 SIP 閘道提供者：AudioCodes 與 Dialogic。如果您的設計需要 SIP 閘道，請確認您購買的 SIP 閘道有支援設計所需的工作階段 (連接埠) 數量。譬如說，如果您的設計需要 32 個連接埠，您就需要使用至少可支援這麼多工作階段的閘道。
若您不確定您的 PBX 能否與整合通訊搭配使用，或是不曉得該使用哪種閘道，請參閱「整合通訊資源」資訊看板。資訊看板所列的連結可引導您連到 Microsoft 的特定指引，以及一份整合通訊專家名冊，這些專家會協助評估您的特定組織需求。就我個人的經驗而言，很少有無法與 SIP 閘道及 Exchange 整合通訊搭配使用的 PBX，而且有些 PBX 本身就可以在 TCP 上使用 SIP 與 Unified Messaging Server 通訊。
Exchange 整合通訊支援三種音訊轉碼器來儲存語音信箱訊息：G.711 PCM Linear、GSM 06.10 及 Windows Media®Audio (WMA)。每個 PCM Linear WAV 檔案的每秒音訊約佔 16 KB。WMA 是整合通訊的預設音訊轉碼器，WMA 會將每秒音訊壓縮為 1.1 千位元 (KB)，且包含 7 KB 的標頭。GSM 06.10 會將每秒音訊壓縮為 1.6 KB，但是其標頭小於 WMA 編碼。
WMA 與 GSM 06.10 編碼都提供可接受的語音訊息音質。根據使用 WMA 或 GSM 轉碼器的實際經驗，視組織依賴語音信箱的程度而定，您可以假設信箱儲存大小會增加 10% 到 20%。
在決定環境要採用哪種音訊轉碼器時，請牢記您的使用者可能使用的行動裝置和其他作業系統。有關這個主題的問題，大多涉及使用者可否在自己的 Windows Mobile® 裝置上聽取語音信箱。其他作業系統也需要列入考量：也許您已經大規模部署了可能無法播放 WMA 檔案的 Linux 電腦。無論情況如何，要了解這類因素會提高服務中心資源需求，而需要考慮訓練支援工程師。

組態和測試
無論是集中式或非集中式整合通訊架構，在組織中部署整合通訊之前，必須先衡量許多語音信箱需求。「整合通訊檢查清單」資訊看板中提供了專案小組必須討論的詳細主題清單。在考慮實作整合通訊時，應該收集各個站台的所有主題資訊。請記住，IT 小組與電信小組雙方必須一起合作來考量這些主題。
設計系統並完成組態後，應該執行系統測試以檢驗設計。在多站台設計中，我建議至少要測試兩個不同的站台，以證明概念和確認設計機能無誤。
您應根據組態需求擬定功能測試計劃，並完成測試。功能測試計劃應該包含用戶存取方法 (電話、Outlook 2007 和 Outlook Web Access)、系統管理方法以及硬體和網路中斷事件。
當測試完成，而且大家都認可整合通訊將複製舊語音信箱系統的功能，或已經設計替代解決方案來支援無法複製的組態或功能後，就應該挑選使用者試驗小組來測試系統。有了試驗小組，即可示範在環境中，讓用戶從舊語音信箱系統遷移到 (或者以電話語音述語來說，切換到) 整合通訊所需的步驟。一般而言，必須採取這些步驟來切換用戶：
  1. 從現有語音信箱系統停用用戶。
  2. 經由 Exchange 管理主控台，在整合通訊的 Active Directory 中啟用用戶。
  3. 將電話的涵蓋範圍路徑變更為整合通訊試驗號碼。
從現有的語音信箱系統停用用戶很重要，以避免訊息傳送到舊信箱。
在試驗階段中，您應該收集用戶對於系統功能提出的任何問題。記錄這些詳細資訊可讓您在教育訓練階段處理常見問題。
教育訓練對於成功切換影響重大。您的使用者習慣以特定的使用者介面從電話存取語音信箱。比方說，有些語音信箱系統會要求使用者按下 5 來聽取留言訊息。Exchange 整合通訊則要求使用者按下 1 或說出「voicemail」(或使用 Outlook 2007 或 Outlook Web Access 來播放語音訊息)。您的整合通訊用戶的訓練課程應該包含電話語音使用者介面導覽、Outlook 語音存取導覽以及 Outlook/Outlook Web Access 導覽。
藉由 Exchange 2007 整合通訊，命令的聲控功能已內建在 Outlook 語音存取中。有些使用者會對新的系統功能感到新奇，而這份新鮮感可能有助於推展從某個使用者介面移轉到另一個使用者介面。
Exchange 整合通訊能夠在使用者啟用時，發送自訂的電子郵件文字訊息給每位使用者。這些自訂訊息可用來提供實用的網站連結到常見問題集 (FAQ)、用戶說明文件、服務中心電話號碼等等。其中也可以包含如何存取語音信箱系統和用戶的唯一密碼等相關資訊。在啟用使用者時，這是其中一項可供利用的最強大功能。

遷移使用者
整合通訊檢查清單
下面各節會定義整合通訊系統的一些基本要素，並提出在部署和設定 Exchange Server 2007 整合通訊時需要準備好的問題答案。請使用這些內容來當做擬定部署計劃的檢查清單。
撥號對應表 整合通訊撥號對應表會以邏輯方式對應到 PBX 和相關聯的分機。有些需要預先考量的撥號對應表環節包括：
  • 分機號碼有幾位數？
  • 整合通訊系統的試驗號碼為何？
  • 使用者需要什麼來撥打外線電話？
  • 您的訊息要使用哪種音訊轉碼器？
  • 公司總機的分機號碼為何？
群組搜尋與試驗號碼 群組搜尋是指被設定為以特定順序接收呼叫的一組電話分機。試驗號碼則是存取群組搜尋所撥打的主要分機。您的設計中需要使用相同的群組搜尋成員分機號碼做為語音信箱連接埠號碼。
信箱原則 語音信箱信箱原則與 Exchange 信箱原則沒什麼不同。您可能會想討論的某些原則如下：
  • 語音郵件要保留幾天再刪除？
  • 語音信箱密碼需要重設的頻率為何？
  • 語音信箱備份原則為何？
  • 可接受的最小密碼長度為何？
  • 鎖定信箱之前，最多可嘗試登入幾次？
自動語音應答 (AA) 自動語音應答會接聽未指定用戶的來電。這項功能可提供資訊並引導呼叫者到組織內部的位置。Exchange 整合通訊針對 AA 提供 DTMF 與語音功能。應考量的因素包括：
  • 是否針對日間、夜間和假日提供不同的 AA 提示語？(提示語必須記錄並錄製)。
  • 從 AA 功能表可以撥號的對象？
  • 使用 AA 時，是否提供語音導覽功能？
  • 使用 AA 時是否需要多語服務？
一般或夜間信箱： 有些組織提供一般或夜間語音信箱好讓呼叫者留下一般傳遞訊息。如果您的公司提供這樣的信箱，就必須針對整合通訊建立和啟用 Exchange 信箱。
訊息等待指示： 訊息等待指示 (Message Waiting Indication，MWI) 是指電話上的燈號以提醒您信箱中有尚未聽取的語音訊息。在部署中是否需要話機包含訊息等待指示？
多重分機支援： 許多組織的員工都有多支電話。讓這些用戶啟用整合通訊時，您必須在當下建立他們所有分機號碼的關聯性。開始之前，請先列出擁有多重分機的員工清單。
互動式語音回應支援： 某些傳統語音信箱系統支援互動式語音回應 (Interactive Voice Response，IVR) 應用程式，但整合通訊無法複製這項功能。確認要取代的系統中是否有這類應用程式。這些應用程式可以保留在現有系統中，也可以使用替代的 IVR 應用程式來取代。
語音信箱網路功能： 語音信箱網路功能提供從某個系統傳送訊息到另一個異質系統的機制。舉例來說，在大型企業中，CEO 可能想要發送語音訊息到整個組織，或者您可能需要宣布消防演習等綜合資訊。藉由語音信箱網路，CEO 可以錄製語音訊息一次，然後傳送給公司內的每位員工，無論這些員工使用哪種語音信箱系統。目前，Exchange 整合通訊無法與其他傳統語音信箱系統建立網路。
傳真支援： 有些傳統語音信箱平台支援傳入傳真，可讓您使用單一電話號碼來收到語音和傳真功能。Exchange Server 2007 整合通訊支援傳入傳真，也可用來取代該功能。這是單向功能；系統並不支援傳出傳真功能。如果需要此功能，您必須參考可支援的協力廠商產品。

如何將系統完整移轉到執行環境有許多不同觀點。主要的兩個方法論分別是漸進式移轉和閃電切換 (flash-cut)。無論選用哪種方法，請訓練服務中心人員應答您從試驗小組記錄的常見問題。此外，請務必示範如何啟用使用者、如何確認使用者已啟用，以及如何變更密碼。
將使用者從舊的語音信箱系統移轉到整合通訊很簡單，但是您還是必須注意一項重大問題：語音信箱網路功能。正如可讓您傳送、轉寄和回覆其他電子郵件使用者及系統的電子郵件系統一樣，語音信箱也可讓您傳送、轉寄和回覆其他語音信箱使用者及系統。
試想一下 Alice 與 Brian 目前都採用舊的語音信箱系統。Brian 移轉至整合通訊，且想要發送訊息給採用舊語音信箱系統的 Alice。由於這兩位使用者位於不同的系統上，因此彼此之間無法再傳送、轉寄或回覆語音信箱訊息；不幸的是，此處形成了語音信箱孤島。
解決傳統語音信箱系統此一問題的方法是，使用某種網路通訊協定轉換器，以便建立異質系統之間的網路。然而，目前還沒有網路通訊協定轉換器能夠建立異質系統與 Exchange Server 2007 整合通訊之間的網路。雖然這點對您的組織來說可能無關緊要，但是選擇以小型群組遷移使用者時就必須考量到這個問題。
我個人偏好執行全站台的所有使用者閃電切換。閃電切換是從某個系統徹底轉換到另一個系統。通常是在週末執行；使用者星期五下班回家，星期一上班就發現全新的語音信箱系統。有些系統管理員認為閃電切換只適用於小型企業客戶或遠端站台。我不同意這種說法。我曾經在包含 7,000 位使用者之多的單一位置進行閃電切換 ，而不到 1% 的員工需要打電話給支援工程師尋求支援。如果專案中的其他階段都已經過完善規劃與執行，那麼切換成完整的生產系統應該沒什麼困難。
不過，將多個站台切換至完整執行環境時，請考慮一次切換一個小型遠端站台，之後再切換最大的站台。回顧從小型站台學到得經驗，然後對專案計劃進行必要的變更。
一般而言，在即時切換系統之前，應該先完成所有使用者教育訓練並啟用所有使用者進行整合通訊。以下提供逐步的方法來準備閃電切換語音信箱系統。
第一件要做的事情就是檢查整合通訊系統是否已完整安裝、設定和測試。
以小組的形式進行教育訓練。向加入訓練的使用者說明信箱會在系統上線之前先啟用，並鼓勵使用者登入信箱，然後變更密碼和錄製問候語來初始化他們的信箱。完成教育訓練後，立即啟用這些使用者，好讓他們能在切換之前先初始化信箱。
最後，在所有訓練完成後，選擇一個週末來停用所有使用者的舊語音信箱系統功能，並將電話轉送到 Exchange 整合通訊。如此一來，組織中的使用者就可以在星期一早晨立即使用您的系統。

進行切換
無論您要支援單一站台或是大型的多站台組織，本文中的資訊應該都能派上用場。多站台組織在設計上可能比較複雜，但是無論您有 50 位或 5,000 位使用者，基本需求都大同小異。
我一再強調，IT 與電信小組雙方必須緊密合作來部署整合通訊解決方案。從我的經驗來看，雖然有許多事情可能會使整合通訊專案出差錯，但是 IT 與電信小組的不合與缺乏關於解決方案的共識直接預言了失敗。技術統合並不是那麼困難，但是可能需要兼具 IT 與電信知識的組織外部人員來協助凝聚小組或計劃成功的專案部署。

Jeff Goodwin 是 VIA 小組的資深技術人員，精通 Exchange 與整合通訊設計和部署。您可以透過電子郵件地址與他聯絡：jgoodwin@theviagroup.com.


 安全性: 基本電腦鑑識指南
安全性 Tom Cloward and Frank Simorjay

基本電腦鑑識指南
摘要:
  • Windows 基本電腦鑑識指南
  • 惡意程式碼移除工具之入門套件
  • 使用 Windows PE 建立調查套件
  • 保存資訊供鑑識分析

心懷不軌的人利用電腦進行非法活動的方法不勝枚舉，舉凡攻擊電腦、洩漏交易秘密、釋放新病毒、使用網路釣魚郵件來偷竊私人資訊等都是。而新的攻擊方法
和技巧也時有所聞，但是利用電腦來調查這類活動的方法就比較少見了。
雖然有些調查工作必須仰賴經過專業訓練的專家，使用昂貴的工具和複雜的技術，但是基本的調查和分析工作，只要採用簡單好用且價格便宜的方法就可以了。本文將著重介紹方便主流系統管理員 (就是您) 存取的各種電腦鑑識技術。
討論過程則藉由兩個免費下載的解決方案加速器協助完成，下載網址如下：《Windows 基本電腦調查指南》(go.microsoft.com/fwlink/?LinkId=80344) 和惡意程式碼移除工具之入門套件 (go.microsoft.com/fwlink/?LinkId=93103)。本文將告訴您如何結合這兩個解決方案，共同建置開機用的 Windows® PE 環境，讓您有效展開調查，並將發現結果保存起來作為報告及分析之用。請注意，此處所討論的方法，不能用來調查經過加密或屬於 RAID 磁碟區一部分的硬碟。而且萬一硬碟已經損毀，則必須事先執行其他步驟來還原它的狀態。
雖然我們的解決方案可以提出一套方便您從 Windows 電腦收集證據的方法，但它只是基本、臨機操作的方法而已。如果要更有效的執行此處所述的工作，可以採用市面上販售的幾種較複雜的解決方案。
另外還要注意的一點是，此處所討論的技術既不是保證有效的解決方案，也沒有經過國際電腦鑑識人員協會的認證。所以在調查之前，最好先考量一下硬碟上的證據是否可能成為法律訴訟的一部分。如果有這個可能，最好能夠安排專業認證的電腦鑑識人員來進行調查。另外您也必須考量是否要根據任何可能的法律訴訟種類，將調查工作直接移交給執法人員。其他相關資訊，請參閱《Windows 基本電腦調查指南》。

關於解決方案加速器
《Windows 基本電腦調查指南》探討的是進行內部電腦調查所用的程序和工具。它概略敘述了電腦調查模型的四個階段：評估、獲取、分析和報告。這是一套實用的模型，可幫助 IT 專家在進行調查的同時，保存重要的發現。
本指南還將探討在哪些情況下需要執法人員的介入 — 在這種情況下作決定時，應該請法律顧問參與。您可以找到如何管理與電腦有關的犯罪、如何聯絡適當的執法機關，以及能夠協助調查工作的 Windows Sysinternals 工具和其他 Windows 工具等相關資訊。
本文參考的另一個解決方案快速器 ─ 惡意程式碼移除工具之入門套件，則提供相關的指導方針，告訴我們如何建置和使用開機用的 Windows PE CD-ROM，來移除電腦上的惡意程式碼。本指南提出一份威脅清單及部分防護之道，協助降低它們對公司可能產生的衝擊，同時也強調開發事件因應計劃的重要性，一旦發現可疑的惡意程式碼時，即可派上用場。惡意程式碼移除工具之入門套件還包括一套 4 階段的方法，幫助 IT 專家判斷所牽涉的惡意程式碼本質、遏制它們擴散、儘可能將它們移除、驗證它們已經移除，並且在必要時繼續下一步驟。

Windows PE CD-ROM
執行這類調查有兩個先決條件：Windows PE CD-ROM 和外部存放裝置，例如 USB 快閃磁碟。
您可能看過不少電視節目，知道警員應該將犯罪現場保持現狀。同樣的道理，您也應該將您在調查的資料保留在硬碟上。只不過我們所建置的 Windows PE 開機光碟片在執行工具時，並不會修改硬碟資料，這一點跟惡意程式碼移除工具之入門套件不同。
利用 Windows PE 光碟片開機之後，會進入一個受限的 Windows 環境。當您建立這張開機光碟時，可以加入針對特殊目的事先設定的工具 (例如，惡意程式碼移除工具之入門套件中的工具)。請注意，電腦至少要具備 512MB 的 RAM 才行 — 這是 Windows PE 的需求。
建立 Windows PE CD-ROM 的程序相當直接了當，相關細節請參閱＜惡意程式碼移除工具之入門套件＞。建立這張開機光碟片之前，必須先安裝 Windows 自動化安裝套件 (AIK)、Sysinternals Suite (可在 microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx 取得)，將 Sysinternals 工具放在惡意程式碼移除工具之入門套件第二項工作所述的工具清單中，然後再安裝其他惡意程式碼掃描工具和公用程式。有關建立光碟片的詳細指示，請使用＜惡意程式碼移除工具之入門套件＞文件中所述的步驟。

USB 外接磁碟
這個程序不會更改您要調查的磁碟機，因此您還要另外準備一個 USB 隨身碟或其他種類的外接硬碟，以便儲存所產生的輸出檔案 (建議使用 USB 隨身碟，因為 Windows PE 可以自動掛接 USB 裝置)。您也可以使用外部硬碟機來存放原始硬碟機的影像。正因為有這些需求和選擇的關係，您必須事先進行規劃，將調查所需的總磁碟空間列入考量。
您想要確定套件在調查開始時是空的，因此必須把儲存調查檔案所用的外部磁碟機當中，所有之前的資料完全移除。這個動作只要利用磁碟清除公用程式覆寫整個可寫入磁碟機表面，就可以輕鬆辦到。必要時，可以再將外部磁碟格式化，並且標示作為調查之用。此舉是為了確保裝置不含任何可能污染您在調查期間所收集之證據的檔案。
另外最好也能加入監管鏈表，這麼一來就有一份官方記錄，記載整個調查期間由誰負責處理電腦了。《Windows 基本電腦調查指南》附有監管鏈表範例供您參考。完成包裝套件後 (此套件包含必要了的 Windows PE 開機光碟片、外部存放裝置和監管鏈表)，就可以著手進行調查工作了。

進行調查
現在您已經準備就緒，可以著手展開調查了。首先，請使用 Windows PE 光碟片啟動可疑的系統，確定電腦的開機順序是將 CD-ROM 光碟機視為主要開機裝置。當畫面出現提示時，請按下任何按鍵，完成從 CD-ROM 開機的程序。這時候，您就有權存取您安裝在光碟片上的工具了。
我們將在測試機器上使用套件，示範從電腦 (我們將它稱為 Testbox1) 收集資訊的程序。Testbox1 上所指派的光碟機是 X:\，而提供給惡意程式碼移除工具之入門套件工具的預設位置是 X:\tools。若要存取套件內的工具，只要輸入：cd \tools 即可。
您可以利用幾種工具，識別掛接在電腦上的目標磁碟機。而位於 Sysinternals 工具目錄的 Bginfo.exe 正可提供這項資訊，並將它放在桌面上的背景視窗內，以方便您參考。磁碟機管理員也可以識別電腦上所有的磁碟機，包括目標硬碟機和外部 USB 裝置。[圖 1] 所顯示的是 Testbox1 的磁碟資訊。開機磁碟機是 X:\，目標硬碟機是 C:\，而我們的外部 USB 磁碟機是 F:\。
Figure 1 Viewing disk information with Drive Manager
Figure 1 Viewing disk information with Drive Manager

找出惡意程式碼
在開始調查之前，必須先執行防惡意程式碼工具，以確保調查工作不受到病毒或其他惡意程式碼的染指。必要時，還可以把防惡意程式碼工具所產生的報告作為證據。要是不檢查電腦是否含有惡意程式碼，不僅危及調查，也會降低鑑識人員調查準確性的可信度。我們建議您以唯讀或報告模式，執行它所提供的防惡意程式碼工具。
＜惡意程式碼移除工具之入門套件＞討論了幾項建議工具，其中包括惡意軟體移除工具和 McAfee AVERT Stinger。執行惡意軟體移除工具時，務必加入 /N 命令列選項，表示工具只報告惡意程式碼，而不會移除它。
x:\tools\windows-KB890830-v1.29.exe /N
得出的報告檔案將置於 %windir%\debug\mrt.log 中。
同樣的，在執行 McAfee AVERT Stinger 時，請將喜好設定改為 [僅產生報告 (Report only)]，如 [圖 2] 所示，這樣它只會掃描電腦，但不會對硬碟做任何變更。另外，掃描完成時，一定要從工具儲存報告。
Figure 2 Use Report only mode in McAfee AVERT Stinger
Figure 2 Use Report only mode in McAfee AVERT Stinger

儲存重要檔案
如果在調查之前未將整個磁碟備份，至少應該備份重要的使用者檔案。必要時，也可以將設定資訊作為日後複閱之用。開始時，請先收集登錄檔和設定，其中包含電腦的用途，以及系統所安裝的軟體等所有相關資訊。
為了儲存 Testbox1 的登錄 Hive，我們首先在卸除式 F:\ 磁碟機上建立一個資料夾，然後在開始進行調查時，以下列命令記錄日期和時間：
f:Mkdir f:\evidence_files Date /t >> f:\evidence_files\Evidence_start.txt Time /t >> f:\evidence_files\Evidence_start.txt
接下來我們再以 xcopy 命令儲存登錄 Hive，複製整個設定目錄及其內容。您感興趣的登錄檔就位於 %windows%\system32\config 下。在本例當中，我們要執行的命令如下：
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
這個命令會複製 config 資料夾中所有的設定資訊。Textbox1 的 config 資料夾大約含有 95MB 的資訊。
接下來就是使用者資料了，硬碟的任何地方都有可能存有使用者資料。不過在本例當中，我們只複製 c:\HR 這個目錄的資料。為了確保資料完整收集，我們以下面這個 xcopy 命令來複製目錄及其子目錄中所有的資料：
Mkdir f:\evidence_files\HR_Evidence Mkdir f:\evidence_files\documents_and_settings Mkdir f:\evidence_files\users xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
接下來是個人資料夾資訊。同樣的，我們想從這些目錄及其子目錄複製所有的資料。我們使用下列命令來進行這個動作：
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
這個範例收集了大約 500MB 的資料，必要的話我們現在就可以進行分析。如您所見，您所收集的資料量有可能相當龐大 — 如果碰到音訊檔、視訊和相片的話，就更不在話下了。儘管如此，還是要盡可能保存原始資料，因為調查工作需要的不只是實際收集的證據，還要保證這項資訊在收集的過程中未經更改。因此在理想的情況下，最好能夠為調查工作製作一個完整的磁碟影像，但是這個動作可能會因大小的限制而難以辦到。現在您應該知道，為什麼一定要事先研究調查工作需要多少存放空間了吧。

收集其他資訊
系統檔案也是收集證據的有力幫手，但是要尋找這類資料可能需要花點時間搜索目標電腦，因為這些檔案不見得會放在同一個地方。雖然如此，有些類型的檔案還是值得一找，因為它們的確可以提供有用的內容。比方說，交換檔案含有記憶體存取了哪些檔案的相關資訊。另外，交換檔案甚至還提供詳細的使用活動。同樣的，網頁瀏覽器資料和 Cookie 也會提供瀏覽行為和模式的相關資訊。
尋找這項資料可能需要進行一些偵查工作，特別是當使用者變更設定，把資料儲存到預設位置以外的地方時更是如此。不過您可以利用幾種 Sysinternals 工具，幫助您尋找重要的檔案。[圖 3] 一共列了五個有用的應用程式，並且說明這些應用程式如何協助您進行調查。
Figure 3 Tools to locate files and data of interest (Close Figure 3)

應用程式 | 描述
AccessChk | 依您所指定的使用者或群組，來顯示檔案、登錄機碼和 Windows 服務的存取。
AccessEnum | 顯示誰有權存取電腦上的哪些目錄、檔案和登錄機碼。您可以使用這個應用程式，尋找權限套用不當的地方。
Du | 依目錄顯示磁碟使用情形。
PsInfo | 顯示電腦的相關資訊。
Strings | 搜尋以二進位映像表示的 ANSI 和 UNICODE 字串。

Tom Cloward身兼 CCE、CISSP，在 Microsoft 擔任專案經理，主要工作是提供適用於 IT 專家的安全性和循規解決方案加速器。他在軟體和 IT 產業已有 15 年以上的工作經驗，熱衷於 IT 安全性、鑑識與法規遵循。
Frank Simorjay身兼 CISSP、CET，同時也是 Microsoft Solution Accelerator ─ 安全性和法規遵循小組的技術專案經理暨安全性主題專家，專為 Microsoft 的客戶設計安全性解決方案。他的最新作品是惡意程式碼移除工具之入門套件 (Malware Removal Starter Kit)，此套件可在 Microsoft TechNet 網站上取得。


 網路功能: Microsoft Security Intelligence Report
網路功能 Tim Rains

Microsoft Security Intelligence Report
摘要:
  • 揭露軟體漏洞、入侵和惡意程式碼的趨勢
  • 不同 Windows 版本的威脅衝擊
  • 全世界感染最嚴重與最輕微的地區

從上億個網際網路連線的系統，加上從一些全世界最繁忙的線上服務所得到的資料，讓 Microsoft 得以獨到的觀點剖析當今網際網路使用者所面臨的安全性威脅。
Microsoft 每年都會透過 Security Intelligence Report (SIR) 分享兩次這項資訊。此報告的貢獻者包括 Microsoft® Malware Protection Center (MMPC)、Microsoft 安全性回應中心 (Microsoft Security Response Center，MSRC)、高可信度電腦運算 (Trustworthy Computing，TwC) 小組，以及許多其他產品小組。SIR 提供揭漏軟體漏洞、惡意軟體和可能不受歡迎的軟體 (例如間諜軟體和廣告軟體) 近來趨勢的深入檢討。此份報告另外還包括不同版本的 Windows 作業系統在遍佈威脅的大環境中的表現，以及世界上哪些地區受到惡意程式碼和其他入侵軟體的影響最深。最新一期的報告把重點放在於 2007 年上半年觀察到的發展趨勢，也另闢一節來探討軟體漏洞入侵。如果電腦安全性是您的責任或是您關心的議題，閱讀 SIR 將大有裨益，因為它是為了幫助您了解網際網路相關威脅而設計的。
最近的 SIR 顯示出安全性研究人員在各家的軟體中發現到越來越多的漏洞。事實上，光是 2007 年上半年就揭發了超過 3,400 個新的軟體漏洞！ 這個數字固然驚人，但被揭發的作業系統漏洞的整體百分比卻在下滑當中。
這代表什麼意思呢？其中一個可能性就是安全性研究人員把重點多放在應用程式上，因為作業系統安全性一直在改進中。再者，由於新應用程式的數量遠超過新作業系統的數量，應用程式的激增有可能是這些近來揭露的漏洞趨勢背後的推手。
在 2006 年間，Microsoft 產品中有 29.3% 已知的漏洞有可公開取得的入侵程式碼，而在 2007 年 8 月 1 日，只有 20.9% 已知的漏洞有可公開取得的入侵程式碼。雖然漏洞的數目持續增加，入侵程式碼的比率卻保持相當穩定，甚至還出現微小的降幅。新推出的產品比較難找到入侵程式碼。我們進行了一項產品對產品的比較，當中指出較新版本的產品所面臨的風險比在市場上推出較久的產品版本還低。平均而言，入侵性會隨產品壽命降低，表示對於絕大多數的產品來說，較新版本比較不容易入侵。這在 Windows 和 Microsoft Office System 產品最為明顯。兩者較新的版本 (Windows Server® 2003、Windows Vista®、Office 2003 和 2007 Office System) 都在產品的壽命期間顯示出漏洞數目有明顯的降低。
SIR 提供惡意軟體 (亦稱為惡意程式碼) 發展趨勢的重要洞悉資訊。這些趨勢指出目前攻擊使用者所採納的策略。看看一些主要來源所提供的資料，包括 Microsoft Exchange Hosted Services (EHS)、Windows Live® OneCare 和 Windows Live OneCare 安全掃描器、Windows 惡意軟體移除工具 (Malicious Software Removal Tool，MSRT)，以及 Windows Defender，讓我們得以從幾個不同的有利位置一探威脅的全貌。
社交工程在惡意程式碼的散發扮演著日益重要的角色。這類的攻擊經常能成功引誘使用者採取一些可能會減損安全性機制有效性的行動。來自 EHS 的資料指出，在 2006 年上半年，傳統的電子郵件蠕蟲構成了歷史上來自電子郵件最嚴重的威脅，有 95% 的電子郵件偵測到惡意程式碼。自 2006 年的下半年開始，這個數字下降至 49%，並且直到 2007 年的上半年都保持不變 (見 [圖 1])。網路釣魚垃圾郵件和包含惡意 IFrame 攻擊的電子郵件則佔了 2006 年下半年偵測到的電子郵件惡意程式碼的 27%，並且在 2007 年的上半年上升至 37%。電子郵件內夾帶的特洛伊木馬下載程式在 2006 年下半年達到 20% 的高峰，並在 2007 年上半年降至 7%。
Figure 1 Composition of infected e-mail in the first half of 2007
Figure 1 Composition of infected e-mail in the first half of 2007
自 Windows Live OneCare 和 Windows Live OneCare 安全掃描器 (safety.live.com) 的測距儀收集到的資料指出，病毒、後門程式、密碼偷竊程式和資料竊取特洛伊木馬程式的感染率在 2007 年上半年攀升。
MSRT 的設計是為了幫助從客戶電腦識別和移除常見的惡意程式碼。它主要是透過 Windows Update (WU)、Microsoft Update (MU) 和自動更新作為重大更新發行。在過去兩年以來，MSRT 在全世界 2050 萬台電腦上移除了 5030 萬的感染原。MSRT 到目前處決的總數已超過 7 億 4 千萬，這包括了 2007 年上半年的 1 億 9 千萬次處決。
MSRT 是 Microsoft 及其客戶絕佳的資料來源。MSRT 在 Windows Vista 和 Windows XP SP2 系統上所觀察到的感染率與舊版 Windows 作業系統相比起來低很多，如 [圖 2] 所示。MSRT 從執行 Windows Vista 的電腦清除的惡意程式碼比執行 Windows XP SP2 的電腦還少 60%，而比執行 Windows XP 但未安裝任何 Service Pack 的電腦還少 91.5%。有趣的是，每部電腦的消毒數目經過一段時間以來都保持穩定狀態，每部受感染的電腦平均約有 2.2 的消毒率。
Figure 2 OS versions cleaned by the MSRT in the first half of 2007
Figure 2 OS versions cleaned by the MSRT in the first half of 2007
一般來說，MSRT 在開發中國家發現到的惡意程式碼比例比在已開發國家發現的高。例如，歐洲感染最嚴重的國家是阿爾巴尼亞和土耳其，而感染最不嚴重的是義大利和芬蘭。而在亞太地區，感染最嚴重的是蒙古和泰國，而感染最不嚴重的是紐西蘭和日本。美國受感染的比例比大部分的美洲國家和地區都低，而它的感染率跟全球的平均值大約相同。MSRT 在 2007 年上半年平均是每 216 部電腦清理 1 部。
Windows Defender 是在 Windows Vista、Windows XP 和 Windows Server 2003 上執行。整體來說，在 2007 年上半年偵測到了 5070 萬個可能不受歡迎的軟體，在執行 Windows Vista 的電腦上偵測到的比在執行 Windows XP SP2 的電腦上偵測到的少 2.8 倍。同樣地，在執行 Windows Vista 的電腦上偵測到的可能不受歡迎的軟體數量是在執行 Windows Server 2003 的電腦上發現到的一半。
您到現在可能會好奇，這些統計數字是很有趣，但它們要如何幫助您更妥善地保護您自己和您的環境呢？在最近的 SIR 中，每個主要分節的前面都會有該章節重點的摘要，以及一組「策略、緩和之道和因應對策 (Strategy, Mitigations, and Countermeasures)」。您可以使用這些清單快速了解這份報告中每個章節的重大發現。
另外，您還可以使用 SIR 中提供的資料、洞悉資訊和指引，針對威脅善變的環境評估及改善您目前的安全性狀況。完整的報告還會根據重大的發現提供策略、緩和之道與因應對策，您可從 microsoft.com/sir 下載。

Tim Rains 在 Microsoft Malware Protection Center (MMPC) 擔任產品經理。他負責管理 Microsoft Security Intelligence Report (SIR) 的製作。SIR 的作者包括 Jeff Jones (Microsoft 高可信度電腦運算小組主任)、Jeff Williams (MMPC 的主任)、Mike Reavey (Microsoft 安全性回應中心的小組經理)，以及 Ziv Mador (MMPC 的資深專案經理兼回應協調員)。


 網路功能: 追蹤難以捉摸的網路問題
網路功能 Christopher Stoneff

追蹤難以捉摸的網路問題
摘要:
  • 網路問題的常見起因
  • 忽略最明顯的因素
  • 當疑難排解工具沒用時
  • 為什麼需要設定連線限制

這種情況您可能見過很多次 — 您的機器無法跟其他機器通訊，是什麼原因您完全沒有頭緒。您的管理系統位於路由網路的其中一段，透過路由器的方式 (例如 Microsoft Internet
Security and Acceleration (ISA) Server 或其他硬體裝置) 與其他網路區段連線。當您嘗試管理 10、20 或甚至 100 部系統時，不會遇到什麼問題。但是當您嘗試管理 500 部系統時，除了電腦已經開啟連線的機器以外，它無法在網路上進行通訊。您無法與任何其他系統通訊，連不上網際網路，但是網路上 (包括您區段上) 的電腦都沒有發生這個情況。您要先從哪裡著手找出問題呢？

診斷問題
這種情況最常見的判斷是管理軟體有問題。許多主動式管理工具都會連線到您的系統並進行管理，但是有時候您嘗試追蹤的問題可能是這些工具本身所引起的。這是因為主動式管理工具可能會假借促進管理之名，產生上千個連線連到您的裝置。Windows® 預設會讓這些連線保持開啟狀態達兩分鐘的時間，即使連線閒置也一樣，除非工具、應用程式或服務讓它們存留更久的時間。換句話說，即使您的管理系統在兩分鐘內未與任何機器交談，還是可能有超過 1,000 個開啟中的連線 (您可以在命令提示執行 NETSTAT 來查看開啟中的連線。NETSTAT 命令會向您顯示系統所有開啟中、擱置中和關閉中的連線，並提供它們的狀態。狀態訊息的說明可在 RFC 793 中找到，網址是 tools.ietf.org/html/rfc793)。
若要排除故障的管理軟體，您可以建立一個批次檔來建立與遠端系統的連線。如果在執行批次檔時還是遇到相同的問題，您就知道管理軟體和它的執行緒是清白的。下面是所需批次檔的內容範例：
Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...
如果剛剛提到的管理程式剛好會實作自己的網路和驗證堆疊，它有可能正是罪魁禍首，但是在沒有代理程式的解決方案中 (這些管理套件絕大多數都是這種情況)，工具便會使用作業系統的網路和驗證堆疊來執行網路作業。使用批次檔來啟動一樣多的網路連線而不導致失敗，便可證明問題並非出自於程式使用作業系統的網路和驗證堆疊，因為批次檔也同樣使用它們。

越幫越忙的記錄檔和錯誤訊息
您可能已經注意到隨著連線開始失敗，您也跟著收到錯誤的失敗資訊：錯誤 53 — 找不到網路路徑，錯誤 64 — 網路名稱已刪除，以及錯誤 1203 — 網路提供者都不接受指定的網路路徑。所有這些錯誤通常可能表示是名稱解析的問題，但是所有其他機器在解析名稱和連線到相同系統時並沒有任何問題。若要確認您的電腦設定沒有錯，只要執行 ipconfig 來確認您的設定是否正確。
接下來，由於問題似乎是跟您的管理系統有關，因此您應該查看事件記錄檔。搜尋應用程式記錄檔沒什麼斬獲，但是在系統記錄檔中您發現到事件來源 TCP/IP 發出一個警告事件 4226，指出已達最大連線數目 (見 [圖 1])。
Figure 1 TCP connection limit has been reached
Figure 1 TCP connection limit has been reached
在 Microsoft® 知識庫徹底搜尋連線限制方面的資訊，可以找到有對未完成的連線施加的連線限制，但對已完成連線並沒有任何限制。您可以在 HKLM\System\CurrentControlSet\Services\TCPIP 底下調整下列登錄項目來控制上述因素：TcpNumConnections 是用來 TCP 可以同時開啟的最大連線數目 (預設為 10)。TCPTimedWaitDelay 則會設定連線在關閉時保持 TIME_WAIT 狀態的時間。預設一半的時間是 120 秒，也就是說連線基本上是使用 4 分鐘的時間。最後，MaxFreeTcbs 也在最大連線數目扮演著舉足輕重的角色。如果 TCP 控制區塊全都在使用中，即使 TCPTimedWaitDelay 尚未到期，TCP 還是應該釋放列為 TIME_WAIT 狀態的連線，以建立更多連線。TCPTimedWaitDelay 的值範圍是 30-300 秒 (0x1E – 0x12C)。
根據您的情況而定，變更這些登錄內容可能可以在整體效能上看到微幅的改進。另外一個您可以嘗試的步驟是修補 TCPIP.sys 檔案來移除這些限制，但這只能提升 P2P 應用程式的效能。

網路擷取
在試過其他解決連線問題的方法都不成功後，對相關機器進行網路擷取看似蠻有希望的。在我執行 Microsoft 網路監視器 (Netmon) 後，它產生的擷取所顯示的結果跟我在管理工具和測試指令碼中看到的一模一樣：剛開始一切運作正常，後來就失常了，連一個錯誤訊息都沒有。
[圖 2]顯示執行 Netmon 的結果，指出前 n 個系統間的通訊成功。請注意，我是取得 RPC 要求的認可。您想看到的結果是 — 成功的雙向通訊。
Figure 2 Successful communication in Netmon
Figure 2 Successful communication in Netmon
您現在需要查看一下從管理系統和看似出現錯誤 53/1203 的遠端系統所得的擷取。如您所預期，沒什麼好看的，因為機器之間並沒有通訊。在 [圖 3] 中的網路擷取，管理系統已解析 IP 位址，並嘗試透過連接埠 445 (Microsoft SMB 連接埠) 連線到系統，但是沒有收到任何回應。
Figure 3 Attempts to connect to the system over port 445 yield no response
Figure 3 Attempts to connect to the system over port 445 yield no response
當您擁有的執行緒超過機器目前可以連線的數目時，所收到的錯誤不一定都是一樣的。在某些情況下，您可能會從來源系統看到錯誤 53，指出您已收到名稱解析，但是怎麼樣就是找不到 IP 位址。這表示 DNS 提供了一個您無法連線的位址。您也可能收到錯誤 1203，指出沒有任何機器回應您所要求的名稱或 IP 位址。錯誤 1203 在這種情況下表示您無法使用 DNS。如果您執行 nslookup，也會碰到這種情況。
此時您肯定是信心大挫，但還有其他選項可以考慮。由於問題以下面的方式自我呈現，因此絕大多數的人甚至不會想到要查看連線基礎結構：您的機器是唯一不能連線到網路其餘部分的電腦，而事件記錄檔指出您的機器已達允許連線的最大數目，因此問題看起來不像是架構上的問題。
雖然您的管理解決方案並不會同時起始上千個連線，但是一直存留的傳輸和連線逾時，可能表示在任一時刻擁有的開啟中連線比您想像中得多。因此，您也必須檢查那些連接到您的網路其餘部分的系統。
且聽我一一分曉，我之前說過，隨著網路流量通過您的網路，它也會通過交換機、路由器，甚或是防火牆。通過當中任何一點時 (通常是路由器或防火牆)，您可能會碰到入侵偵測系統。受管理的交換機和路由器也可能採用流量篩選。無論是您或其他對這些裝置有控制權的使用者，都需要檢查記錄檔以尋找錯誤或警告。通訊問題很可能就出於這些系統內。
由於您是從內部系統連線到其他內部系統，所以可能發現並未產生任何警示，因為裝置上並沒有設定警示功能，或是因為問題根本不算是入侵或阻絕服務 (DoS) 攻擊。同樣地，您應該從記錄檔著手。舉 ISA Server 為例，這些記錄檔可在 ISA Server 管理主控台中找到，位置是 [陣列]\[<陣列名稱>]\[監視]\[記錄]。
如果封鎖您的是原則，您可以 (就 ISA Server 的例子而言) 尋找下列結果碼，當中的來源 IP 是您的管理電腦：
  • 0xc0040037FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000dFWX_E_POLICY_RULES_DENIED
  • 0xc0040017FWX_E_TXP_SYN_PACKET_DROPPED
如果找到這類的結果，表示您已找出連線問題的根源。

實作解決方案
識別出問題後，解決辦法也許很簡單，但是部門原則可能會使它難以實作。在進行任何變更之前，確定您有適當的權限進行這個動作，因為您不一定可以在防火牆、路由器和/或入侵偵測系統上建立安全性設定的排除原則。
同樣舉 ISA Server 為例，下列步驟說明如何增加特定主機或網路中所有機器的最大連線數目 (如 [圖 4] 所示)。開啟 ISA Server 管理主控台，並巡覽至 [陣列]\[<陣列名稱>]\[設定]\[一般]\[設定洪水安全防護功能設定]。
Figure 4 Increase the maximum number of connections for one host or all machines using ISA Server
Figure 4 Increase the maximum number of connections for one host or all machines using ISA Server
兩個值得注意的設定是 [每一 IP 位址的同時 TCP 連線數上限]，以及 [每分鐘，每一 IP 位址的 TCP 連線要求數上限]。[每一 IP 位址的同時 TCP 連線數上限] 一般所設的值就足以應付沒有發生任何主動管理的情況，表示沒有任何電腦可以快速地主動連線至上千部其他機器。在 ISA Server 中，同時 TCP 連線數上限的預設限制是 160。每分鐘，每一 IP 位址的 TCP 連線要求數上限是為了限制網路掃描的毀損和可見度而設計的。預設限制是每分鐘每一 IP 有 600 個連線要求。
前面曾提到，如果沒有其他項目嘗試保存連線，則即使連線不在使用中，Windows 會也讓連線存留一段為時兩分鐘的預設時間。這表示即使您已經成功管理一部電腦，而且不再需要與它通訊，連線還是會保持作用狀態。這個開啟的連線也會計入您分配的連線總數。重複這個程序超過 160 次而不移除任何連線的話，您就會發現到所有嘗試的連線都會遭到您的路由器拒絕。即使您的管理程式主動刪除工作階段，Windows 還是可能把連線保持在 time_wait 的狀態，等候目標機器同意中斷工作階段的連線。
開始對嫌疑最大的兇手進行調整：每一 IP 位址的同時 TCP 連線數上限。您應該設定這個值，這樣一來您的管理機器就能夠建立所需的全部連線來管理您的系統，而不會遭到存取拒絕。按一下設定旁邊的 [編輯] 按鈕，並變更各值。
下一個提示 (見 [圖 5]) 有個 [限制] 方塊，代表預設限制，適用於所有用戶端。[自訂限制] 會套用到洪水安全防護功能對話方塊的 [IP 例外狀況] 索引標籤上定義的所有機器、網路等。如果您希望允許每部機器建立更多連線，那麼請變更 [限制] 的值。若只要設定管理機器的例外狀況，請調整 [自訂限制]，然後將您的機器新增至 [IP 例外狀況] 索引標籤。一般來說，只允許您自己的機器的例外狀況是比較妥當的做法。
Figure 5 Default connection limit and custom connection limit
Figure 5 Default connection limit and custom connection limit
如果您希望使用自訂限制，只針對特定系統修改此值，那麼請變更 [自訂限制] 欄位中的值，然後按一下 [確定]。接著將您的機器新增至洪水安全防護功能對話方塊上的 [IP 例外狀況] 索引標籤。若要將單部電腦新增至例外狀況清單，請在 [IP 例外狀況] 上按一下 [新增] 以叫出 [電腦組] 對話方塊。按一下 [新增] 來新建一個網路組，以包含您的系統 (如果包含這些機器的網路組不存在的話)。選取這個網路組，再按一下 [新增] 以加入 [內部網路] 網路組，然後按一下 [關閉]。再次選取 [內部網路] 網路組，並按一下 [編輯]。這將開啟 [內部網路] 的內容 (見 [圖 6])。按一下此對話方塊上的 [新增] 來顯示子功能表，您可以從中選擇新增電腦、位址範圍或子網路；請選擇電腦。輸入用來識別項目的名稱、機器的 IP 位址，以及描述，讓稍後查看這個項目的使用者不會覺得有必要移除您的系統 (見 [圖 7])。按一下 [確定] 以新增您的系統，再按一次以新增例外狀況。做了這些變更之後，您必須套用設定。
Figure 6 Internal networks properties settings
Figure 6 Internal networks properties settings
Figure 7 Enter computer name, IP address, and description to ensure your system is not removed
Figure 7 Enter computer name, IP address, and description to ensure your system is not removed
再試一次您的主動式管理工具，您應該會發現效能改善許多，而且連線並未失敗 — 至少不會因為網路流量造成失敗。結果原來問題並不是出在軟體所啟始的連線數目，而是因為對那些連線缺乏妥善規劃而導致服務中斷。

心得
在 IT 業中最頭痛的問題之一，就是遇到和解決真的很難以捉摸的問題。這些問題不是使用者製造的，不是伺服器小組引起的，也不是支援工程師了解的，而不幸的是，您可能得靠自己解決這些問題。有很多工具可以幫助您進行疑難排解、隔離和解決問題，但有時光靠工具是不夠的。工具有時候甚至會誤導您，這時您得要機靈點，別被工具騙了。
下次要是發現自己無緣無故沒法在網路的幾部機器上建立連線，不妨試試本文描述的步驟。遵循這些步驟、仔細查看您的管理軟體，還有適當設定可允許的連線，您很有可能就可以順利解決問題。

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


 編輯的話: 揭開對話的序幕
編輯的話
揭開對話的序幕
Joshua Hoffman

我們發現，過去所有發生過的重大事件 幾乎都以對話作為開端。
「我總覺得這世界不是平的。要不要一起找出真相呢？」
「為什麼不送個人到月球上去看看呢？」
「能跟你聊聊我對這些新電腦的點子嗎？」
「喝杯咖啡碰個面怎麼樣？」
(最後那句話也許不代表什麼大不了的事啦...我就是喜歡喝咖啡嘛！不過，一起喝杯咖啡的話，說不定會撞擊出什麼火花也很難講呢！)
不管怎麼樣，對話是重大事件之母這個想法，從本月份我身邊的兩件事看起來似乎是沒錯。第一件是目前在部落格、在走廊，甚至在本期《TechNet Magazine》中實際進行的對話 (請參閱 Romi Mahajan《現場筆記》專欄的第 91 頁)。話題是關於 IT 的消費化。內容強調我們不只在工作上才是 IT 專家，其實我們在日常生活所做的事情 (不管是擔任慈善事業義工、唱卡拉 OK，還是玩 Xbox)，或多或少都會對我們的工作、我們在專業上的決策產生一點影響。即將於拉斯維加斯召開的 Windows Connections 會議中，Romi 跟我還有幾位特別嘉賓決定在一場名為「The Fungible Future (可買賣的未來)」的專題討論會繼續進行這場對話。希望各位也能親臨現場加入我們，或者到 WeWantToKnow.net 網站一瞧。也非常歡迎各位前往我們的部落格加入對話，網址是 blogs.technet.com/tnmag，您的意見是我們前進的動力！
至於第二件事，就是進行這場對話所採用的科技。在本月的《TechNet Magazine》期刊中，我們要探討 Exchange Server 幫助您保持連線的主要加強功能。無論您是在走廊的那一端還是在世界的那一端，我們都歡迎您參加。我們將告訴您 Exchange Server 2007 SP1 必須改善哪些地方；待命連續複寫 (Standby Continuous Replication) 如何大幅強化您的嚴重損壞修復計畫；Windows Server 2008 如何增強 Exchange 平台；以及整合通訊如何讓您的對話顯得更加有力。另外，《TechNet Magazine》印刷本還將附上兩位特約編輯 Astrid McClean 和 Martin McClean 提供的最新人氣系列海報，這就當作本月份的特殊奬勵吧。您可能看過他們榮獲奬項的 Active Directory Jigsaw 的海報，或是過去在這裡刊登過的 Windows Server 2008 的海報，而本月份他們專攻的主題是 Exchange。讓我們一起揭開對話的序幕吧！ —Joshua Hoffman

感謝下列 Microsoft 技術專家： Ed Banti、Anah Cameron、Chun Yong Chua、Cliff Didcock、Jeremy Kelly、Michael Murgolo、Jon Orton、Jeff Ressler、Kevin Sullivan、Jim Truher、Scot Vidican 和 Michael Wilson。

Joshua Hoffman


 讀者來信: 讀者有話直說
讀者來信
讀者有話直說

PageDefrag 公用程式
我試著執行您在 2007 年 9 月份介紹的 SysInternals PageDefrag 公用程式。但是，這個公用程式無法在 Windows Vista® x64 底下執行，而且出現錯誤：「請確定您是系統管理員。載入 PageDefrag 驅動程式時發生錯誤」。
—Alex D.

目前 Windows Vista 不支援 PageDefrag 公用程式。它只適用於 Windows NT® 4.0、Windows® 2000、Windows XP 及 Windows Server® 2003。很抱歉在九月份的文章中並未清楚載明這點。

備份排程器
我讀了 2007 年 9 月份的文章《Windows Vista 備份技術指南》，覺得很有趣，但是有一些疑問。文章中的 [圖 2] 有顯示出下次備份的日期和時間。如果備份工具本身沒有排程器，這是怎麼辦到的？
既然磁碟區變更是決定要備份對象的基礎，萬一發生磁碟重組時該怎麼辦？這是否會造成大量的資料需要備份，因為區塊已經移動或變更？此外，在還原過程中，如果區塊還原到原本的位置，磁碟重組會對此造成什麼影響？
—Bruce G.

我們找了原文作者 (Christine Fok) 討論，她的回覆如下：
[圖 2] 顯示下次檔案及資料夾備份的日期和時間，但只是最近的「Complete PC 備份」的時間。您可以排程檔案/資料夾層級備份，但是正如您所說，「Complete PC 備份」本身不包含排程器。
您說的沒錯，在兩次「Complete PC 備份」之間執行磁碟重組會使得第二次的備份大小變大。至於您對磁碟重組之後還原的想法也正確。Complete PC 是在檔案系統底下的磁碟區層級運作。它會將每個區塊還原成與備份時一模一樣的狀態，並放在磁碟上的相同位置，無論在備份後是否執行磁碟重組都一樣。因此，您可能需要在還原完成後再執行一次磁碟區重組。

BGInfo 工具
拜讀 2007 年 8 月份的《公用程式焦點》專欄讓我獲得許多樂趣。SysInternals 提供的 BGInfo 工具收集關鍵 CPU 與網路資訊的功能的確很棒。我很喜歡閱讀有關研發新產品、公用程式程式或應用程式的故事。請問 Cogswell 先生是否為 Microsoft 研發其他軟體產品？
—Daryl B.

很高興您覺得 BGInfo 公用程式很實用！Bryce Cogswell 編撰了一些好用的公用程式，而且大多是與 Mark Russinovich 合作開發成為 Sysinternals 的產品。好消息是，Microsoft 已於 2006 年併購 Sysinternals，而且 Cogswell 先生與 Russinovich 博士目前都服務於本公司。您可以在以下的 Sysinternals 網站上找到他們所有的公用程式： microsoft.com/technet/sysinternals。

RPC 和防火牆
2007 年 7 月份的＜RPC 錯誤的疑難排解＞一文很實用，但是有一點遺漏了：Windows 防火牆也可能引起 RPC 錯誤。如果將 Windows 防火牆設定為允許 PING 要求，但不允許來路不明的訊息，那麼想要從遠端管理機器的嘗試便會失敗。如果您從 Windows Resource Kit 執行 RPCPING.exe，便會傳回 1722 的錯誤 (RPC 伺服器無法使用)。
在這種情況下，防火牆正在履行它的本分：阻止外來者存取特定系統。但是當系統管理員嘗試管理企業網路上的電腦時，也會落入被阻擋的範疇。
—Aaron M.

感謝您指出另一個可能造成 RPC 問題的來源。我們希望該文所介紹的工具能協助疑難排解這些問題。

Windows XP 授權
2007 年 10 月份的《現場筆記》專欄提到可以用 $5.00 美元的低價購買 Windows XP 授權。 我們是一家非營利出版社，想要知道如何能取得這些授權。能否透過電話或郵件購得？我有電子郵件信箱，但是沒有網站。
—Ernest B.

您可以寄電子郵件到 communitymar@techsoup.org 或來電 800-659-3579 x350 與 MAR 系統管理夥伴 TechSoup 聯絡。您也可以寫信到以下地址：Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107。


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

監視器網路系統
ActiveXperts Network Monitor
activexperts.com
身為系統管理員，當情況有異時就要立即警覺，別等到使用者像受驚的土撥鼠從辦公座位一一探頭時才發現不對勁。服務監視是主動式管理基礎結構一項重要的工具。ActiveXperts Network Monitor 是一套強大的解決方案，包含多種跨越 LAN/WAN 和 Windows ®、Novell 和 *NIX 伺服器的檢查，確保您在使用者通知您之前就發現問題。
ActiveXperts Network Monitor 是一種 Windows 應用程式，在您指派作為監控站使用的電腦上執行成服務，這部電腦的基本作業系統可以是 Windows 2000、Windows Server® 2003、Windows XP 或 Windows Vista®。它安裝之後，畫面會出現一個快速設定精靈，引導您設定電子郵件通知、SMS 通知，以及預設的掃描頻率或失敗閾值。您也可以加入一組範例檢查，作為設定中的範例。這些範例可以大大幫助您突破區塊執行，它會提供基本方針，指導您如何配合環境的需求，設定不同的應用程式功能。
這個應用程式一共分為三個獨立元件：網路監視引擎 (Network Monitor Engine) 是一種 Windows 服務，負責持續監視工作；網路監視管理員 (Network Monitor Manager) 是一種 Windows 應用程式，可讓您看到目前的監視器活動、檢視工作結果，以及更改設定。網路介面 (Web interface) 則提供您唯讀存取工作和工作結果。
網路監視引擎除了執行監視檢查之外，也負責處理通知、觸發結果的動作，以及應用程式的記錄。監視引擎是多執行緒作業，可以配合環境調整。這項服務不需要委託端點代理程式執行監視檢查，不過這也表示您必須提供管理憑證，才能監視遠端 Windows 伺服器或工作站。幸好您可以指定多組憑證，跨越不同的網域和安全性內容進行監視，而不必單單仰賴一個全能帳戶幫助您執行監視解決方案。
網路監視管理員最佔用時間，它可以讓您控制所有細微的功能和設定。您可以把監視工作組織成一個樹狀資料夾結構，幫助您在大型環境中更快速的尋找和識別項目，以及篩選目前的 UI 檢視，快速查看一組監視工作。
增加新的監視檢查很簡單。光是網路監視器就有大約 40 種的內建檢查，包括 IP 和通訊協定檢查 (例如 ICMP、LDAP、 SMTP 和 HTTP)、Windows 檢查 (例如 CPU、處理序、記憶體和終端機伺服器檢查)、ODBC 連線、Oracle TnsPing、OLEDB 查詢式資料庫檢查、Novell 成員資格檢查以及 *NIX RSH 檢查。另外您還可以使用網路上的 SensaTronics 環境監視器來監視環境細項 (例如溫度、濕度和溼潤度)。
這個應用程式支援自訂 VBScript 和遠端 Shell 指令碼，可讓您調整監視工作。此外，它還包含一組 VBScript 範本讓您監視像是防毒軟體、Microsoft® ISA Server 和 XML 查詢等各種服務，所以在建立自訂監視工作時，不必從頭做起。
您可以設定每一項工作的檢查頻率和失敗閾值，並且根據自己的需求，安排在指定的日期和時間針對那些案例進行檢查，比方說，驗證其他執行中處理序 (例如，記錄保存工作或 IIS 應用程式集區重設) 的結果。您也可以指定在檢查失敗或復原時所要執行的執行檔、指令碼和批次工作，以及安排重新啟動指定的服務。最後，再由網路介面提供 XSL 轉譯檢視來查看 XML 結果資料。您可以輕易調整樣式表來建立自訂您的網路維運中心 (Network Operations Center，NOC) 或行動裝置的檢視，而且由於資料是以 XML 撰寫，也很方便擷取，再把它用在另一個應用程式或彙總系統。

價格： 五部伺服器授權的直接售價為 $395 美元起。
ActiveXperts Network Monitor includes sample checks to get you started
ActiveXperts Network Monitor includes sample checks to get you started

書評
Windows Vista Resource Kit
microsoft.com/mspress/books/9536.aspx
有鑑於越來越多的公司將 Windows Vista 用戶端整合到基礎結構中，因此 IT 專家必須加速研究適合新作業系統所用的工具。新發行的《Windows Vista Resource Kit》(Microsoft Press®，2007 年) 涵蓋了許多實作企業 Windows Vista 用戶端所需的資訊和工具 — 從安裝和大量啟動作業的自動化、到桌面管理與維護、到使用 IPv6 網路和遠端協助等一應俱全。本書除了 1,568 頁內文之外，還內附一片支援 DVD，其中包括超過 100 個管理和部署用的指令碼、一組偵錯工具、Solution Accelerator for Business Desktop Deployment (BDD) 以及其他有用的東西。
本書以 Windows Vista 新功能的概觀開頭，全書特別著重安全性的加強，例如使用者帳戶控制 (UAC)、BitLocker 磁碟機加密以及資料執行保護 (DEP)。同時也討論強化服務 (Service Hardening) 及核心補充程式保護的概念。接著就說明 Windows 的部署，並探索您手邊眾多的程序自動化工具。比方說，本書會探討 Windows PE 2.0 預先安裝和復原環境的設定，並且深入研究 BDD 2007，提供規劃和部署企業 Windows Vista 的指導方針。此外，還提供建立和設定磁碟影像的最佳作法，並且討論如何使用「Windows 輕鬆傳輸」和「使用者狀態遷移工具」，來移轉使用者資料。
接著本書再詳細說明如何透過群組原則來管理桌面環境，並深入探討全新 XML 架構管理範本檔案 (ADMX)。另外，還涵蓋磁碟與檔案系統的管理，以及嶄新的 Windows Vista ReadyBoost 和 BitLocker 增強功能。它會解說舊版、陰影複製和磁碟配額的運作方式，甚至探討在工作群組、網域以及臨機操作無線環境中部署和管理「Windows 會議空間」的方式。
本書＜桌面維護＞一節將討論工作、Windows 錯誤報告、效能監視和 Windows Eventing。文中也探討如何讓支援工程師利用遠端協助，另外還有軟體更新、幕後智慧型傳送服務 (BITS) 和 Windows Update 以及稽核工具。
＜網路＞一節則詳細說明 Windows 防火牆的運作方式，以及新的網路堆疊增強功能。另外它也使用遠端桌面和 VPN 連線來設定遠端使用者和網路，調查其效能。
書中最後則是詳細說明從開機到網路、驅動程式錯誤、到裝置等各種問題的疑難排解。當然文中偶而也會出現一些不太好懂的行銷術語，不過並不會佔據太多版面，也絕不是寫錯字。總之，這是一本內容豐富、深入探討 Windows Vista、其工具及作業系統管理的書。

價格： 直接售價 $59.99 美元。

分析 HTTP 流量
Charles Web Debugging Proxy
xk72.com/charles
想想應用程式之間，以及工作站、伺服器和網際網路之間大量的 HTTP 通訊，準備一個好的 HTTP 流量分析器，對系統管理員而言絕對是一個有力的生力軍。它可以幫助您識別 Proxy 問題、安全性疑慮、連線錯誤、設定問題，以及應用程式之間的通訊問題。有個工具我還蠻喜歡的是 Karl von Randow 的 Java 應用程式，它就是 Charles Web Debugging Proxy。
這個應用程式與其他偵錯 Proxy 一樣，會將本身設為類似「攔截式攻擊」的角色，坐陣在端點應用程式之間，攔截並解譯它所看到的資料流。正因為這樣的設定，您才能夠檢視純文字解密形式的加密 HTTPS 流量。UI 把記錄的工作階段組織成井然有序的檢視畫面，提供您從網頁、影像、指令碼和樣式表的基本要求，到大小、延遲和時機的核心細節等豐富資訊。您也會看到每一個要求所收送的 Cookie，以及它們所含的內容；甚至可以選擇一起封鎖 Cookie。
您可以利用 Charles Web Debugging Proxy 排解要求快取問題的疑難，方法是驗證「304 未修改」回應的前次修改日期，或者選擇在它們行經該應用程式時，從相關的要求和回應移除快取相關標頭，藉此停用快取。事實上，您可以使用該應用程式的重寫設定來定義一組規則，在要求和回應通過該應用程式時，重寫部分 HTTP 標頭或內文。甚至可以使用該應用程式的 DNS 詐騙設定，覆寫主機的 IP 位址，讓您測試可能未在 DNS 登錄的項目要求。它非常適合用來測試新的網頁伺服器 (其中一個例子)，確保它在正式使用之前，確實有妥善接聽並回應主機標頭。
您也可以使用這個工具，對 AJAX 要求和回應進行偵錯，並且查看回應中的原始 XML 資料。在 UI 當中，您甚至可以看到內文中的原始要求和回應資料，幫助您找出所有不太對勁的標頭。
這個工具可以提供兩個很棒的資料配置，讓您洞悉資料交易的內容：摘要表格和圖表表格。摘要表格可讓您快速掃描要求/回應資料、顯示標頭大小、內文大小、回應時間、回應碼、MIME 類型以及資源。而圖表表格則提供圖形式的生命週期時間表，依序顯示要求/回應資料所發生的地方，以及執行交易所花的時間。
您可以把記錄工作階段儲存起來，稍後再重新播放及分析。這項記錄可以幫助您抓住導致零星通訊錯誤的詭異要求/回應資料流；有它在手，就可以重現這個資料流。您甚至可以將 HTTP 追蹤檔匯入到新的工作階段，以及將目前的工作階段匯出成 CSV 或 HTTP 追蹤格式。
如果您要以較低的寬頻模擬要求 (例如，找出要求能用在 56k 的數據機線路，卻不能用在公司網路的原因)，這個應用程式會提供節流功能，讓您從常用的一組預設值中選擇，或者以下列四個節流重點為根據，定義一組新的預設值：頻寬、使用比例、來回延遲時間以及最大傳輸單位。您也可以設定偵錯 Proxy，作為反向 Proxy 或連接埠轉寄站，有效將本端連接埠連結到遠端端點 (和連接埠)，將所有傳送到該連接埠的流量，重新導向至遠端位址。

價格： 單一使用者授權的直接售價為 $50 美元起。
Charles Web Debugging Proxy analyzes HTTP traffic
Charles Web Debugging Proxy analyzes HTTP traffic

清除不必要的檔案
Wise Disk Cleaner 2
wisecleaner.com
硬碟就像一個家，時間久了就會累積一些東西，一些沒必要留著的東西，因此最好三不五時就仔細清理一番。您可以採用幾種標準方法，以內建的 Windows 工具 (例如系統工具、清理磁碟以及搜尋功能) 來清理硬碟。但有時候不妨也採用一下快速好用的公用程式，尤其是免費的公用程式。其中一個例子就是 Wise Disk Cleaner 2，它可以在硬碟當中搜尋專惹麻煩的檔案，並且將它們從系統中安全移除。
這工具吸引我的一點，就是能夠列出所有它在 UI 找到的檔案，方便您找出所有可能的問題。另一個不錯的功能，則是方便您另外加入您要檢查和移除的檔案模式。Wise Disk Cleaner 也會根據您的需要，清除暫存網際網路檔案，而您也可以選擇保留 Cookie，以免遺失可能儲存在裡面的站台喜好設定。另外，您也可以移除 Windows Update 解除安裝檔案，以及清除 Windows Update 原始檔案、最近檔案清單，以及 Windows 和使用者暫時資料夾。您甚至可以自動執行這個應用程式，將喜好設定設為永久刪除這些項目，或者只是將它們移到資源回收桶。應用程式會記錄它的活動，稍後供您檢閱 — 以免費工具來說，這點還不賴。

價格： 免費。
Wise Disk Cleaner 2 finds files that you can safely delete
Wise Disk Cleaner 2 finds files that you can safely delete

管理網路裝置
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
如果您的基礎結構中有任何採用簡易網路管理通訊協定 (SNMP) 的網路裝置、應用程式或系統，iReasoning Networks MIB Browser 可讓您載入一組管理資訊庫 (MIB) 檔案，並且透過一個很像 Windows 檔案總管中的檢視來瀏覽階層式結構。您會在這裡看到選定物件的詳細資訊，包括物件識別碼 (OID)、語法、讀寫權和描述。
您可以輕鬆發出 SNMP 要求，透過 UI 從網路裝置擷取資料。您只要輸入裝置的 IP 位址，選取 MIB 物件，然後按一下 [執行] 即可。必要時，也可以設定連接埠、SNMP 要求版本，以及讀寫社群字串。修改代理程式只有簡單兩個字可以形容 (假設您的裝置容許您更改的話)，只要選取 OID、資料類型和值，然後按一下 [確定] 就可以了。此外，還有一種內建的陷阱傳送器和陷阱接收器公用程式，可讓您發出陷阱，並且觀察陷阱活動 (您可以在這裡套用篩選器，讓這些裝置更容易看得見)。
iReasoning Networks MIB Browser Personal Edition 是免費工具，不過它不支援 SNMPv3，而且最多只能同時載入五個 MIB。至於 Professional Edition (每份授權直接售價 $269 美元) 則含有其他功能，並且支援 SNMPv3、網路探索以及裝置比較。

價格： 免費。
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen Greg Steen 是一位技術專家，熱衷於探索新工具和新方法，讓 IT 專家的操作和開發工作更加輕鬆。


 SQL 問答集: 記憶體設定、效能設定、設定您的填滿因素及其他
SQL 問答集
記憶體設定、效能設定、設定您的填滿因素及其他
Edited by Nancy Michell

設定記憶體
提示：更簡單的設定工作
您知道現在可以將 PerfMon 與 SQL Server 2005 Profiler 搭配使用嗎？
或許您已注意到 SQL Server 機器上的效能監視器 CPU 使用率遽增、耗用過度的記憶體，或是整體效能緩慢，還在猜想是什麼原因造成這些效能異常。在 SQL Server 2005 之前，得使用 Profiler 擷取追蹤，然後在 Enterprise Manager 中查看系統程序 (sysprocess)，最後才能擷取到效能監視器的記錄檔 — 不用說，要這麼做還得引發 PerfMon。使用所有這些工具進行所有這些工作之後，還是得手動重新調解工具之間的事件，找出效能折損的肇因。也就是說，您可能得一個接著一個吃力地找遍每個記錄檔。這可是一點也不好玩，不過您想要找出效能問題的元兇，就得這麼做。
使用 SQL Server 2005，您還是需要擷取追蹤，然後分析 PerfMon 記錄檔，但是 Profiler 現在可讓您附加記錄檔。您可以捲動查看 T-SQL 陳述式，Profiler 會自動以圖形的方式向您顯示發生什麼事。如果按一下 Profiler 中的效能監視器使用者介面，就可以跳到與該時間戳記相關的陳述式。這在您的 SQL Server 環境中進行疑難排解時，可省下不少時間。
讓我們來看看如何附加 PerfMon 記錄檔到 Profiler：
  1. 啟動效能監視器，然後開始從資料庫伺服器擷取資訊。
  2. 在 [效能記錄及警示] 下建立一個新的計數器記錄檔，然後為您的新記錄檔輸入名稱。
  3. 新增計數器，例如 % Processor Time。您可能也會想要將記錄設定為手動開始，或是使用 [排程] 索引標籤在排定的時間開始。
  4. 按一下 [確定]，如果您是選擇手動選項，確定您自己要開始記錄。
  5. 透過 Profiler 在 SQL Server 上設定追蹤。您可以按一下 [檔案] 功能表上的 [新增追蹤] 來進行。確定在追蹤中包含 StartTime 和 EndTime，然後為追蹤命名，並設定將它存回檔案。最後，您必須砲轟一下伺服器以模擬一些交易活動，然後停止擷取效能監視器和 Profiler 兩邊的資料。
  6. 在 Profiler 中，從 [檔案] 功能表中選取 [匯入效能資料]。接下來，選擇您存放 PerfMon 記錄檔的位置，然後選取 [檔案] | [開啟舊檔] | [追蹤]。最後，選擇您存放 Profiler 追蹤的位置。
完成後，您會發現要找出哪些特定的 SQL 陳述式對處理時間有什麼影響有多麼簡單呀。

問：我試著找出最適合我的 SQL Server™ 電腦的記憶體設定。我之前的系統管理員把 SQL Server 2000 雙節點叢集上每台含有 12GB RAM 的機器的 Boot.ini 設成：Yes /PAE NO /3GB (為 SQL Server 設定 No AWE)。有 12GB 的 RAM 可用，我應該移除 Boot.ini 中的 /3GB 參數，開啟 AWE，然後給 SQL Server 大約 12GB 當中的 10GB 嗎？執行 SQL Server 的機器上沒有其他任何程式，所以沒有其他應用程式需要記憶體。
答：沒錯，您應該開啟 Address Windowing Extensions (AWE)，然後預先配置 SQL Server RAM 的上限 — 對於有 12GB 可用 RAM 的 SQL Server 電腦來說，10GB 似乎蠻恰當的 (請注意，預先配置只適用於 SQL Server 2000。自 SQL Server 2005 開始，使用 AWE 已經不再是靜態，而且可以隨即變更)。對於是否要同時使用 /3GB 和 /PAE 參數，或只使用必要的 /PAE，一直以來都是議論紛紛。雖然您其實只需要設定 /PAE 以及啟用 AWE，我還是建議您同時使用兩個參數；不過還有幾項因素需要考慮。
簡單的說，要不要使用 /3GB 參數取決於您的特殊情況需求。您記憶體的 MemToLeave 部分 (也就是必須位於虛擬位址空間的前 2GB 或 3GB) 不夠用嗎？ 如果真的啟用該參數，您的作業系統會很缺記憶體嗎？(請參閱 support.microsoft.com/kb/316739 以取得詳細資訊)。如果您是在叢集上工作，那麼可以只在其中一個節點上設定 /3GB。這樣一來，如果您測試 /3GB 有問題，很快就可以將執行個體容錯移轉至其他節點。請記住，如果您的 RAM 超過 16GB，就不支援 /3GB 參數。
使用 /3GB 時，您等於是增加 50% 的虛擬位址空間 (VAS)，因此不只是資料快取連對 VAS 造成記憶體壓力的應用程式也可大大受益。所幸，64 位元伺服器，包括 IA64 和 x64，都免除了這個容易誤解的因素。如果機器是專門用於 SQL Server，那麼就不用顧慮 OS 的記憶體不足的問題。為 OS 保留 2GB 也有點過火，如果這部伺服器是專門用於 SQL Server，而且只執行最低數目的標準 OS 服務，您會發現到伺服器上大約還有 1.3GB 的可用記憶體，還不如讓 SQL Server 使用那多出來的 1GB。開始先指派 10GB，使用 PerfMon 來監視可用的記憶體一段時間，看看有多少記憶體閒置沒用，然後再做適當的調整。請記住，如果您在 SQL Server 2000 上過度認可，可能會碰到交換的情況，因為 AWE 不像在 SQL Server 2005 上的動態性那麼高。決定是否使用 /3GB 參數的關鍵在於您的特定環境中進行測試的結果。

複寫的執行個體名稱
問：我現在可以在 SQL Server 2005 複寫中使用伺服器的 IP 位址來指明要複寫哪個執行個體嗎？ 根據《HOW TO：在不受信任網域或網際網路中執行 SQL Server 的電腦之間設定複寫》(support.microsoft.com/kb/321822/zh-tw) 一文，在 SQL Server 2000 中這麼做會產生錯誤，但我不確定現在還有沒有這個問題。
答：當指定伺服器執行個體以加入複寫時，您必須提供 SQL Server 登錄的執行個體名稱。舉例來說，在命令列上指定 Publisher 或 Subscriber 參數給複寫預存程序或給複寫代理程式連接設定時，您必須使用 SQL Server 執行個體名稱。如果 SQL Server 執行個體的網路名稱與登錄的執行個體名稱不符，代理程式進行的複寫連線就會失敗。
若是執行個體的網路名稱和 SQL Server 執行個體名稱不符，可考慮將 SQL Server 執行個體名稱加入為有效的網路名稱。設定替代網路名稱的其中一種方法是將它加入本機 Hosts 檔案。本機 Hosts 檔案預設是位於 WINDOWS\system32\drivers\etc 或 WINNT\system32\drivers\etc。例如，若電腦名稱為 comp1，電腦的 IP 位址為 10.193.17.129，而執行個體名稱為 inst1/instname，即可加入下列項目到 Hosts 檔案中：
10.193.17.129 inst1

SQL Server Integration Services
問：我正在為 SQL Server 2005 (64 位元 Enterprise Edition，有兩部伺服器) 安裝主動/主動叢集，而我總共會有四個 SQL Server 2005 執行個體。所有執行個體都需要安裝 SQL Server Integration Services (SSIS)。您能解說一下叢集 SSIS，還有它對維護計劃的影響嗎？
答：您雖然可以叢集 SSIS 服務，但並沒有必要這麼做，而且可能會遇到許多問題，包括缺乏委派支援 (請參閱 msdn2.microsoft.com/aa337083)，而且它不允許多執行個體 — 您一次只能在一個節點上執行一個執行個體。
過去必須安裝 SSIS — 不是要執行，只是單純安裝 — 是為了讓「維護計劃精靈」能夠執行。不過，這在 SQL Server 2005 SP1 已大改作風。若未執行 SSIS，可由 SQL Server 代理程式執行維護計劃。
您可以考慮讓 SSIS 以獨立服務的方式執行，然後編輯 MsDtsSrvr.ini.xml 來指向所有執行中的執行個體，而不用叢集 SSIS。這可讓您從任何節點管理套件，並提供絕大多數客戶所尋求的高可用性，而不必擔心叢集服務所造成的相關問題。
如需有關維護計劃建立失敗的詳細資訊，請務必參閱知識庫文件，網址是 http://support.microsoft.com/kb/909036。

反常的執行時間
問：我在 SQL Server 2005 SP1 電腦上進行負載測試時，SQL Server Profiler 記錄到許多負值的預存程序 (SP) 執行時間，而且有時候 SP 執行時間與結束時間減去開始時間所得的結果也不符。
答：有很多因素都可能影響 SP 執行時間和 SQL Server Profiler 中效能時間的報告。請記住，SQL Server 2005 是使用毫秒來計算執行時間，如果您所採用的技術會改變測量單位的話，得到的報告會不一致，還有執行時間也會不合理。
例如，如果您使用其他電源配置、CPU 步驟執行 (CPU Stepping)，或是 AMD Cool 'n Quiet 技術，表示您會改變 CPU 頻率，這與 SQL Server Profile 在計算執行時間時預期的值就會不符。
support.microsoft.com/kb/931279 上的知識庫文件說明了徵狀、各種起因，以及一些對策。
提示：檢查您的填滿因素
假設您有個杯子裝滿了水，然後您試著在那個杯子中倒入更多的水。結果會發生什麼事呢？水會溢出來。
SQL Server 的情形也是一樣。當新增資料行到已滿的索引頁時，SQL Server 會將大約一半的資料列移到新的頁面以挪出空間給新的資料列用。這就是所謂的頁面分割。頁面分割會挪出空間放置新記錄，但是它們不僅耗時，而且非常耗用資源。它們也可能導致分散情形，而對 I/O 作業造成負面的影響。那麼要如何加以防範呢？
若要避免這種情形，您必須主動地判斷填滿因素值。當建立或重建索引時，填滿因素值會判定要填滿資料的每個分葉層級頁面上的空間百分比，並保留剩餘的空間以因應日後成長。例如，設定 60 的填滿因素值表示每個分葉層級頁面有 40% 會留空，以隨資料新增至基礎資料表時供索引擴增之用。
預設的填滿因素值固定是 0，對於絕大多數的情況來說沒什麼問題。基本上，設為 0 的填滿因素表示分葉層級幾乎是填到滿，但會保留一些空間容納至少多一個索引資料列 (請注意 0 跟 100 的填滿因素類似)。
您可以在 CREATE INDEX 或 ALTER INDEX 陳述式針對個別的索引設定填滿因素，或者您可以直接在伺服器層級設定此值，讓任何新建的索引都使用預設值。
下面的範例是在伺服器層級將填滿因素值設為 70%，表示您有 30% 的可用空間供日後擴增之用。想當然爾，您在將它實作到生產環境之前，必須審慎測試這個選項。
USE Master; GO SP_Configure 'show advanced options',1; GO SP_Configure 'Fill Factor', 70; GO – 您必須重新啟動 SQL Server 引擎，這項變更才會生效。
要是您想要在個別的索引層級設定填滿因素呢？假設您正在建置下列資料表，而且您希望在名為 Col_A 的資料行上建立唯一索引，並且具有 70 的填滿因素值。整個命令看起來應該像這樣 (請注意，範例程式檔案中的程式設計人員註解雖是英文，但是本文提供翻譯以便解說)：
--建立項目資料表 USE Item_DB; GO CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200)); GO;

--在項目資料表的資料行 Col_A 上建立唯一索引，並包含填滿因素值 70; CREATE UNIQUE INDEX AK_Index ON Item (Col_A) WITH (FillFactor = 70); GO
您要怎麼識別每個索引的填滿因素呢？您可以查詢 sys.Indexes 來取得資料庫中所有索引的填滿因素值，像這樣：
USE Item_DB; GO SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL; GO


 公用程式焦點: Microsoft Security Assessment Tool
公用程式焦點
Microsoft Security Assessment Tool
Lance Whitney
下載本文程式碼: Microsoft Security Assessment Tool 3.0 (只有英文版) (10547.2KB)

尋找 網路安全性問題並不容易，而且曠日費時。您可以利用工具幫助您識別和消除安全性風險，其中一個工具就是 Microsoft® Security Assessment Tool (MSAT)，這個免費的公用程式會提供電子問卷調查，要求您說明您的安全性環境。MSAT 是針對擁有 50 到 500 部電腦的中型企業所設計，它提出 172 道問題，並將問題分門別類，然後分析您的情況，並且提出改善的建議方案。
MSAT 一開始先針對您的商業模型提出一組查詢問題，再利用這些問題建立商業風險概況 (BRP)，與業界其他公司比較，評估您的安全性風險。問卷調查通常花兩個小時完成，您可以隨時停止和繼續進行。下面是範例問題的分類：
基本資訊 貴公司有多少部用戶端和伺服器？
基礎結構安全性 您的員工是在遠端工作嗎？外包人員會存取您的網路嗎？
應用程式安全性 貴公司開發應用程式嗎？它會儲存您應用程式所處理的機密資料嗎？
營運安全性 貴公司的公司網路連接外部網路嗎？貴公司接收外部廠商提供的資料嗎？
人員安全性 貴公司將電腦維護工作外包出去嗎？您容許員工下載公司機密資料到他們的工作站嗎？
環境 貴公司有多少位員工？您的 IT 部門員工流動率高嗎？
接下來 MSAT 會產生一份評估，這份評估是使用一種稱為深度防禦指數 (DiDI) 的測量方式，著重您手邊的安全性程序。下面是使用相同分類的一般問題：貴公司在每一個地方都安裝防火牆嗎？您在您的 Microsoft Office 應用程式使用自訂巨集嗎？您的使用者在他們的工作站上具有管理權限嗎？您有設立原則將補充程式和更新部署到電腦上嗎？
MSAT 提供下列三份報告來回應您的答案。摘要報告是以長條圖顯示結果。 BRP 分數高表示風險高，DiDI 分數高則表示安全性高。雖然，根據 MSAT 表示，低 BRP 與高 DiDI 似乎代表結果較為樂觀，但您還是要檢查個別的區域。因此，「完整報告」會針對每一個區域，指出您是否符合最佳作法、是否需要改進，或者是否嚴重缺乏安全性 (見 [圖 1])。
Figure 1 The complete report
Figure 1 The complete report
最後，「比較報告」會要求您以匿名方式，將結果上傳到安全的 MSAT 網站，讓您比較您與其他公司的結果。
您可以從 Microsoft 資訊安全指導中心網站 (網址為 securityguidance.com) 或從 TechNet Magazine 網站 (網址為 technetmagazine.com/code07.aspx) 下載此工具。

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


 The Cable Guy: 網路原則伺服器
The Cable Guy
網路原則伺服器
Joseph Davies
本專欄是根據 Windows Server 2008 的搶鮮版所撰寫。本文包含的所有資訊均有可能變更。

Windows Server 2008 中的網路原則伺服器 (NPS) 服務取代了 Windows Server 2003 中的網際網路驗證服務 (IAS)，NPS 允許執行 Windows Server 2008 的電腦用作為遠端驗證撥入使用者服務 (RADIUS) 伺服器和 Proxy。RADIUS 是 RFC 2865 與 2866 中指定的
網際網路工程任務推動小組 (IETF) 通訊協定，它為網路存取裝置 (例如無線存取點) 提供集中化驗證、授權和帳戶管理 (AAA)。RADIUS 伺服器會對網路存取裝置執行 AAA，RADIUS Proxy 則會在 RADIUS 用戶端 (網路存取裝置) 與 RADIUS 伺服器之間轉送 RADIUS 訊息。
NPS 包括了許多增強功能，能夠更有效率地部署經過驗證的網路存取作業，並提供擴充性以使用協力廠商元件，以及支援最新的網路技術和平台。[圖 1] 中顯示了全新的 NPS 嵌入式管理單元。
Figure 1 The new NPS snap-in
Figure 1 The new NPS snap-in

網路原則伺服器功能
在本專欄中，我將探討舊版 Windows® 未包含的 NPS 功能。一開始我將說明網路存取保護 (NAP) 如何協助為您的網路強制健康需求，接下來將介紹管理、設定、IPv6 支援，以及其他項目。我還將解釋全新 NPS 嵌入式管理單元的各項功能。
網路存取保護 NAP 是 Windows Server® 2008 引入的一組新技術，可幫助您強制遵守電腦健康需求，以便以更周全的方式保護內部網路。比如說，您的健康原則可以如此指定：所有連線到您的網路的用戶端都必須安裝和啟用防火牆，也必須安裝最新的作業系統更新。透過 NAP，您可以建立自訂的原則，在允許網路存取或通訊之前先確認電腦的健康情況，自動更新電腦以確保它們一直符合規範，並將不合格的電腦侷限在有限的網路上，直到它們合格為止。如需詳細資訊，請參閱 microsoft.com/nap。
在 NAP 部署的情況下，NPS 伺服器是 NAP 健康原則伺服器，它會代表 NAP 強制端點，例如健康情況登錄授權單位 (HRA)、802.1X 存取點、虛擬私人網路 (VPN) 伺服器和動態主機設定通訊協定 (DHCP) 伺服器 — 評估 NAP 用戶端的健康情況。NPS 伺服器也會決定是否該授與用戶端完整或限制的內部網路存取權。網路原則、健康原則和 NAP 設定決定了 NPS 的健康情況評估行為。
EAPHost 和 EAP 原則支援 NPS 支援 EAPHost，這是可延伸驗證通訊協定 (EAP) 驗證方法的新架構。這套新架構可讓 EAP 方法廠商同時在用戶端與 NPS 伺服器上，輕鬆地開發和安裝用於 802.1X 的新 EAP 方法或點對點通訊協定 (PPP) 式的驗證。
EAPHost 支援安裝及使用 EAP 登錄 (位於 www.iana.org/assignments/eap-numbers) 上列出的所有 EAP 方法，以及其他常見的驗證方法，例如 Cisco Systems Lightweight EAP (LEAP)。EAPHost 允許同一個 EAP 方法的多項實作共存。例如，您可以安裝並選擇 Microsoft 版本的受保護的 EAP (PEAP) 與 Cisco Systems 兩種版本。
對於 EAP 方法廠商，EAPHost 支援已針對 Windows XP 和 Windows Server 2003 開發的 EAP 方法，也支援一種較簡單的方法來針對 Windows Vista® 和 Windows Server 2008 開發新 EAP 方法。安裝後，您可以在網路原則中為特定的網路存取案例設定必要的 EAP 方法。NPS 的網路原則就跟 IAS 的遠端存取原則一樣。
如需有關 EAPHost 架構的詳細資訊，請參閱 technetmagazine.com/issues/2007/05/CableGuy。
以 XML 儲存的設定 IAS 將其設定資訊儲存在 Jet 資料庫中。NPS 現在則將設定資訊存成 XML 格式，更方便匯出其中一部 NPS 伺服器的設定，然後再匯入到另一部 NPS 伺服器。匯出和匯入設定檔案是以容錯設定將多部 NPS 伺服器的設定同步化的方法之一。您可以使用 netst nps export 命令匯出 NPS 設定，然後使用 netsh nps import 命令匯入它。
遵守通用工程準則 NPS 已經過更新以便支援在必須符合 Microsoft® Common Engineering Criteria (CEC) 的環境中進行部署。如需詳細資訊，請參閱 microsoft.com/windowsserversystem/cer/allcriteria.mspx。
強大的 NPS 延伸 DLL NPS 服務可透過延伸和授權 DLL 加以擴充。與 IAS 相反，這些協力廠商元件是封裝在 NPS 的沙箱中，如此一來它們遇到的任何問題就不致影響 NPS 服務的操作或執行。
IPv6 支援 NPS 支援 IPv6 以及在原生或通道 IPv6 環境中部署。您可以為 RADIUS 用戶端或遠端 RADIUS 伺服器設定 IPv6 位址，如此 NPS 服務便能透過 IPv6 通訊以進行 Active Directory® 網域服務帳戶驗證和授權作業。
IAS 與 NPS 比較
如果您對 Windows Server 2003 的 IAS 嵌入式管理單元不陌生，您一定樂見下列對 NPS 嵌入式管理單元所作的變更：
  • 遠端存取原則已變成網路原則，並且已從 [原則] 節點下移除。
  • [RADIUS 用戶端] 節點已從 [RADIUS 用戶端和伺服器] 節點下移除。
  • [連線要求處理] 節點已經淘汰，[連線要求原則] 節點已從 [原則] 節點下移除，而 [遠端 RADIUS 伺服器群組] 節點已從 [RADIUS 用戶端和伺服器] 下移除。
  • 遠端存取原則條件和設定檔設定已在網路原則內容的 [概觀]、[條件]、[限制] 和 [設定] 索引標籤下重新排列。
  • 連線要求原則條件和設定檔設定已在連線要求原則內容的 [概觀]、[條件] 和 [設定] 索引標籤下重新排列。
  • [遠端存取記錄] 資料夾已重新命名為 [帳戶處理 (Accounting)] 節點，而且不再具有 [本機檔案] 或 [SQL ServerTM] 節點。

自動產生強式 RADIUS 共用密碼 RADIUS 共用密碼是用來驗證 RADIUS 訊息是由設有相同共用密碼的 RADIUS 用戶端、伺服器或 Proxy 送出的。共用密碼也可用來加密一些機密的 RADIUS 屬性，例如密碼和加密金鑰。強式 RADIUS 共用密碼是一長串隨機字母、數字和標點符號 (超過 22 個字元)。
透過 NPS 嵌入式管理單元，您可以在新增或編輯 RADIUS 用戶端時自動產生強式 RADIUS 共用密碼。您可以將這個強式共用密碼複製到文字編輯器 (例如記事本)，以便使用相同的共用密碼設定網路存取裝置或 NAP 強制端點。
與伺服器管理員整合 您可以透過「初始設定工作」和「伺服器管理員」工具來安裝 NPS。無論是使用哪種工具，您都是使用「網路原則與存取服務」角色來安裝 NPS。若要開始，請在「初始設定工作」工具的 [自訂此伺服器] 下，按一下 [新增角色] 選項。在「伺服器管理員」工具中，開啟 [角色摘要]，並按一下 [新增角色]。
NPS 安裝之後，您可以在伺服器管理員的主控台樹狀目錄中，按一下 [角色] 節點底下的 [網路原則與存取服務]，藉此檢查 NPS 服務的狀態，以及查看在過去 24 個小時內遇到的錯誤事件。當在主控台中展開 [網路原則與存取服務] 節點時，便可以使用 NPS 嵌入式管理單元來設定 NPS。
增強 Netsh 支援 Windows Server 2003 在 netsh aaaa 內容中有一組有限的命令可以用來設定 IAS。而在 Windows Server 2008 中，全新的 netsh nps 內容則具有廣泛的命令組，可在命令列或透過指令碼來設定 NPS。您現在可以使用 netsh nps 命令來設定 RADIUS 用戶端和遠端 RADIUS 伺服器、網路原則、記錄，以及針對 NAP，設定健康原則、系統健康狀態驗證和補救伺服器群組。包含 netsh nps 內容中各種命令的指令碼，提供您另一種方法以容錯設定同步處理多部 NPS 伺服器的設定。
用於網路原則隔離的來源標記 您可以針對特定類型的網路存取伺服器或 NAP 強制端點 (例如 DHCP 伺服器或 HRA) 來設定網路原則，此類伺服器或強制端點之後會變成一種來源標記，將網路原則加以分類。Windows Server 2008 存取伺服器和 NAP 強制端點會在 RADIUS 訊息中包含此來源標記。當收到要求存取的 RADIUS 訊息時，NPS 服務會嘗試尋找與傳入訊息具有相同來源標記的相符網路原則。如果找不到相符原則，NPS 就會嘗試尋找與那些未指定任何來源標記相符的網路原則。
在網路原則和傳入 RADIUS 訊息中使用來源標記可將不同類型的網路原則彼此分隔。例如，DHCP 的網路原則便不會用於 VPN 連線。
與 Cisco 網路存取控制整合 NPS 支援各種功能，以利整合至使用 Cisco 硬體和網路存取控制 (NAC) 的環境。這些功能包括支援主機認證授權通訊協定 (HCAP) 和 HCAP 條件、原則到期條件，以及網路原則中的擴充狀態網路存取保護設定。
全新的網路原則條件 NPS 中的網路原則有些新條件主要是用於指定電腦群組、使用者群組、允許的 EAP 類型，以及用戶端和存取伺服器 IPv6 位址。對於 HCAP 支援，NPS 具有用於位置群組和使用者群組的新條件。而對於 NAP 支援，NPS 則具有用於身分識別類型、健康原則、具備 NAP 功能的電腦、作業系統和原則到期的新原則條件。
NPS 嵌入式管理單元 全新的 NPS 嵌入式管理單元已經過大幅增強，可讓您更輕鬆地建立和管理 RADIUS 用戶端和遠端 RADIUS 伺服器、適用於常見網路存取案例的網路原則、適用於 NAP 案例的健康原則和 NAP 設定，以及記錄設定等。
在 [RADIUS 用戶端和伺服器] 節點中，您可以設定 RADIUS 用戶端 (網路存取伺服器、NAP 強制端點或是當 NPS 作為 RADIUS 伺服器使用時的其他 RADIUS Proxy) 和遠端 RADIUS 伺服器群組 (當 NPS 作為 RADIUS Proxy 時的其他 RADIUS 伺服器)。
在 [原則] 節點中，您可以設定連線要求原則 (NPS 服務是否將作為 RADIUS 伺服器或 Proxy 使用)、網路原則 (當 NPS 服務作為 RADIUS 伺服器使用時的授權和連線設定及限制)，以及健康原則 (適用於 NAP 用戶端的系統健康狀態遵循規範)。當您在詳細資料窗格中選取連線要求原則或網路原則時，NAP 嵌入式管理單元會顯示該原則的條件與設定。[圖 2] 顯示了這樣的範例。
Figure 2 The NPS snap-in enhanced display
Figure 2 The NPS snap-in enhanced display
在 [網路存取保護] 節點中，[系統健康狀態驗證] 節點可讓您設定 NAP 健康需求。[補救伺服器群組] 節點可讓您設定限制 NAP 用戶端可存取 VPN 和 DHCP NAP 強制方法的一組伺服器。最後，在 [帳戶處理] 節點中，您可以設定 NPS 要如何儲存帳戶處理資訊。
NPS 嵌入式管理單元包括了大量的精靈集，可自動化 RADIUS 用戶端和 NAP 強制方法所需的原則、撥號或 VPN 連線，以及 802.1X 驗證的無線和有線連線的初始設定作業。對於 NAP 強制方法，NAP 精靈會自動設定所有連線要求原則、網路原則和健康原則。
這些新精靈在您按下 NPS 嵌入式管理單元內的 NPS 節點時就可以使用。若要設定 NAP 強制方法的原則和設定，請在 [標準設定] 下拉式方塊中選取 [網路存取保護]，再按一下 [設定 NAP]。若要設定 VPN 或撥號網路存取的原則和設定，請在 [標準設定] 下拉式方塊中選取 [撥號或 VPN 連線的 RADIUS 伺服器]，再按一下 [設定 VPN 或撥號]。若要設定 802.1X 驗證有線或無線存取的原則及設定，請在 [標準設定] 下拉式方塊中選取 [802.1X 無線或有線連線的 RADIUS 伺服器]，再按一下 [設定 802.1X]。
這些精靈都會針對您選定的案例指引您完成最常見的設定項目。NAP 強制方法的精靈尤其管用：用於 VPN 強制的 NAP 精靈會建立一個連線要求原則、三個網路原則 (用於合格的 NAP 用戶端、不合格的 NAP 用戶端，以及不具 NAP 功能的用戶端)，以及兩個健康原則 (用於合格和不合格的 NAP 用戶端)。
全新的 NAP 精靈和用來建立 RADIUS 用戶端、遠端 RADIUS 伺服器群組、連線要求原則和網路原則的其他精靈，都能在各式各樣的網路存取案例中簡化設定 NPS 的作業。

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


 Windows PowerShell: 深入挖掘
Windows PowerShell
深入挖掘
Don Jones

Windows PowerShell 滿載各種功能，卻經常受到許多系統管理員的忽略。但只要您深入挖掘，必定會發現一些令人驚喜的功能。事實上，我就常常從自以為了解透徹的指令程式身上挖到一些新功能。
我在自己教授的 Windows PowerShellTM 課堂中，建議系統管理員製作一份每日一指令程式的月曆 (就像您可能會買的每日一字月曆一樣)，然後每天早上 (我讓他們週末休息) 花幾分鐘的時間熟悉一個指令程式的完整功能。Windows PowerShell 大約有 130 個指令程式，也就是說，如果您嚴守這個時間表的話，大概六個月內就可以摸熟 Windows PowerShell。那時候您就準備好可以使用所有的 Exchange Server 2007指令程式了。
我想在本月份的專欄中提供一些範例，告訴您只要多花幾分鐘的時間深入探索各種指令程式功能，您可能會發掘到哪些寶藏，以及可能達到什麼樣的成效。

交出更漂亮的 HTML 報告
ConvertTo-HTML 是一個未受充分利用的指令程式。聰明的它，可以接受輸入物件集合 (服務、處理序、Windows® Management Instrumentation (WMI) 物件等等)，並且將它們轉換成 HTML 表。接著您只要把這個 HTML 傳送到 Out-File，就會得出一個適合張貼在內部網路網頁伺服器的 HTML 網頁了。舉個例說，您可以安排每天早上執行下面這一行：
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML | Out-File C:\ServiceAlert.html
這個命令會針對應該自動啟動但卻沒有執行的服務，建立一份 HTML 報告 (如 [圖 1] 所示)。
Figure 1 An HTML report of services that aren't running
Figure 1 An HTML report of services that aren't running
當然啦，您一定希望做出好看一點的報告。還好，ConvertTo-HTML指令程式所產生的 HTML 相當簡潔，也就是說，它不會在它所建立的 HTML 程式碼中內嵌任何格式。根據 HTML 的規則指出，HTML 內最好不要加置任何格式 (能不加就不加)，格式應該放置在外部階層式樣式表 (CSS)，並且將 CSS 連結到 HTML，而您可以使用 ConvertTo-HTML 建立該連結。
CSS 會連結至 HTML 的 <HEAD> 區段。您只要稍微看看 ConvertTo-HTML 的說明，就會發現語法當中包含了一些您以前可能沒注意到的參數：
ConvertTo-Html [[-property] <Object[]>] [-inputObject <psobject>] [-body <string[]>] [-head <string[]>] [-title <string>] [<CommonParameters>]
–head 參數可讓您額外指定要插入指令碼 <HEAD> 區段的 HTML 程式碼。我只要稍微修改一行指令，就可以讓它連結到含有我想套用到 HTML 表的格式的現有 CSS 檔案：
Gwmi Win32_Service | Where { $_.StartMode –eq "Auto" –and $_.State –ne "Running" } | ConvertTo-HTML -title "Services" -head "<link rel='stylesheet' href='styles.css' type='text/ css' />" | Out-File C:\ServiceAlert.html
我利用 –head 參數，把連結插入到跟輸出 HTML 檔案位於同一個資料夾的 CSS 檔案中。另外我也使用 –title 參數來設定網頁的標題。結果就如 [圖 2] 所示。我所用的 Style.CSS 檔案文字看起就像這樣：
Figure 2 An HTML report that is formatted with a CSS file
Figure 2 An HTML report that is formatted with a CSS file
body { background-color:#EEEEEE; } body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt } th { font-weight:bold; background-color:#CCCCCC; } td { background-color:white; }

更方便篩選
本月指令程式
本月份我要探討一組指令程式： Start-Transcript 和 Stop-Transcript。這兩個指令程式的功能都是控制 Windows PowerShell 文字記錄 — 也就是說，將顯示在主控台視窗的一切，寫到您所指定的文字檔中。做法很簡單，只要執行 Start-Transcript，然後給它一個檔名就成了。接著再執行 Stop-Transcript 結束記錄，並且關閉檔案。這個動作會提供一個絕佳管道，讓命令列從使用臨機操作命令介面進入正式指令碼 — 一旦讓個別的命令列待在命令介面裡面乖乖辦事之後，接下來只要從您所建立的文字記錄檔複製和貼上它們就行了。當然您也可以將文字記錄編輯成實際的指令碼。MVP Jeffery Hicks 同志甚至還寫了一個指令碼來剖析文字記錄，並且把它們轉換成 Windows PowerShell PS1 檔案。您可以在 blog.sapien.com/current/2006/11/28/powershell-transcripts.html 找到這個指令碼。

接下來讓我們看看 Get-WMIObject指令程式。如 Windows PowerShell 內建說明所示，您可以從它的語法看出它還有未經利用的功能：
Get-WmiObject [-class] <string> [[-property] <string[]>] [-namespace <string>] [-computerName <string[]>] [-filter <string>] [-credential <PSCredential>] [<CommonParameters>]
Windows PowerShell 新手最常犯的一個錯誤，就是發出像這樣的 WMI 命令：
Gwmi Win32_NTLogEvent –comp Server2
這個命令會從 Server2 擷取事件記錄項目，而且是所有的事件記錄項目。這項工作勢必讓 Server2 花上一段時間來進行處理和傳輸，而 Windows PowerShell 也得耗上好一陣子來使用這麼一個大型集合。
所以囉，還是請 Server2 尋找和傳送您真正關心的事件比較妥當。您可以利用 WMI 查詢語言 (WQL) 查詢幫您辦妥這件事。也許有些人覺得這種查詢語法很難，其實使用 Windows PowerShell 時，只需要以 –filter 參數指定 WQL 查詢的篩選部分就行了：
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
這個動作會從所有的記錄檔中，擷取所有事件識別碼為 1024 的事件。請注意篩選條件是以 = 作為比較運算子，而不是 Windows PowerShell –eq 運算子。因為您是將篩選器傳遞到遠端電腦的 WMI 服務進行處理，所以必須採用 WMI 語法，而不是 Windows PowerShell 語法來撰寫條件。
在其他像 Get-ChildItem 的指令程式上其實有一個 –filter 參數，這是在 Dir 和 Ls 等別名背後的指令程式。在大多數的情況下，–filter 參數會將您的篩選器條件直接傳到基礎技術，這就是我所謂的來源篩選，這麼做通常會比透過 Where-Object指令程式執行所有的物件，最後篩選出您不想要的物件還要快許多。

受到忽略的指令程式
這種一天學習一個指令程式的方法，無疑可以幫助您更加了解您自以為熟知的指令程式。但是採用每日一指令程式的月曆，另一個原因是為了避免完全忽略您可能怎麼也發掘不到的指令程式。我最喜歡的其中一個指令程式，也是許多人都沒用到的 Resolve-Path。如果您輸入一個萬用字元路徑，這個指令程式會傳回一組符合該路徑的檔案和資料夾名稱。它跟 Get-ChildItem指令程式很類似 (也就是您所熟悉的 Dir 或 Ls 別名)，但它不會傳回整個檔案和資料夾物件，而只傳回字串，這些字串可以傳送到其他的指令程式供進一步篩選或處理之用。用法非常簡單：
Resolve-Path C:\P*
這個簡單的一行會傳回像是 C:\Program Files、C:\Processes.txt 等路徑。[圖 3] 就是兩個這樣的指令程式範例。
Figure 3 Using the handy, though overlooked, Resolve-Path指令程式
Figure 3 Using the handy, though overlooked, Resolve-Path指令程式

從頭開始
當您準備好開始一天體驗一個指令程式時，請執行 Get-Command 的別名 Gcm。這時候畫面會出現一份 Windows PowerShell 認識的指令程式清單，包括您透過嵌入式管理單元加入的指令程式，例如 Exchange Server 2007 管理命令介面、PowerShell Community Extensions 等等。只要從清單中挑選一個 (我第一個挑的是 Add-Content)，然後閱讀它的說明，就可以開始了：
Help Add-Content –full
您需要閱讀完整的說明 (而不是較為簡單的預設說明)，完整的說明含有每個參數用途的完整描述，指令程式的一些使用範例，還有其他詳細的資訊。花點時間體驗一下指令程式吧(您可以使用虛擬機器，而不必動用到實際執行環境)。我建議您每天挪出 10 分鐘的時間 — 而且都在同一個時間，讓自己養成習慣。要不了多久，您對 Windows PowerShell 所提供的所有功能就會有深入的了解。

Don Jones 是 SAPIEN Technologies 的指令碼語言大師，也是《Windows PowerShell:TFM》(SAPIEN Press，2007 年) 一書的作者之一。您可以透過下列網站與他聯絡：www.ScriptingAnswers.com.


 嗨，Scripting Guy！: 重返 WinRM
嗨，Scripting Guy！
重返 WinRM
The Microsoft Scripting Guys

當 Scripting Guy 剛開始撰寫二部曲的 Windows® 遠端管理 (WinRM) 系列專欄時，立刻就浮現一個重大問題：安全性。畢竟，我們 Scripting Guy 都很瞭解伴隨《哈利波特》最後一集上市而來的種種問題：預購書在首賣日之前不小心提早出貨上架 (這樣會造成問題嗎？當然不會，出版社已經要求讀者等到正式發行日再開始閱讀)。
不僅如此，這本書的內容和結局早在書籍發行前就洩漏了 (如果您還沒讀過這本書，它的情節是這樣的：原來哈利波特居然是個巫師！)同樣地，網路上很快就出現全文的掃描版本，甚至在作者 J. K. 羅琳尚未動筆寫這些內容之前就出現了。總歸一句話，真可說是安全崩盤，而 Scripting Guy 決心不讓這種事發生在他們身上。畢竟，如果有人執意要洩漏《哈利波特》的結局，想像一下，在他們指染 Scripting Guy 的 WinRM 二部曲結局之前，還有好長的路要走。
幸好，Scripting Guy 終能緊守他們的所有秘密，呃，只有一個秘密啦。不過主要的原因是 Scripting Guy 一直到截稿時 (其實是截稿後) 才真正撰寫這篇二部曲的下半部。但是別搞錯，撰寫此專欄的 Scripting Guy 八月份在放大假，而且他可不像大部分的 Microsoft 員工，他放假時是連電腦都不看一眼，更別說使用電腦了。
好啦，其實：他即使沒放假時也很少看電腦，更別說用電腦了。不過這已經離題，暫且不談。
無論如何，我們知道過去四週以來，很多讀者都茶不思飯不想，緊張著 WinRM 傳奇的結局如何。還好，這些輾轉難眠的漫漫長夜終於結束了。今天，Scripting Guy 的 WinRM 二部曲精彩大結局終於揭露了。嗯，基本上就如 [圖 1] 所示。
Figure 1 The denouement (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

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

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

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

Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement Wscript.Echo "Name:" & objElement.ChildNodes(0).ChildNodes(0).NodeValue Wscript.Echo "Display Name:" &  objElement.ChildNodes(1).ChildNodes(0).NodeValue Wscript.Echo Loop
是！我們知道：出人意表的情節轉折也讓我們頸後的寒毛直豎。objElement.ChildNodes(0).ChildNodes(0).NodeValue！誰料得到呢？當然，這有一部份要歸功於我們的嚴密保全，即使 Scripting Guy 自己都不清楚二部曲會如何收尾。不過現在終於真相大白。
在進一步講解之前，我們先迅速溫習一下整個二部曲的內容，以免有人居然沒讀＜第一篇＞(網址是：technetmagazine.com/issues/2007/11/HeyScriptingGuy)。在＜第一篇＞中，我們介紹了 Windows Server® 2003 R2、Windows Vista® 和 Windows Server 2008 中的新技術 WinRM，讓您更容易在網際網路上管理電腦 (甚至是透過防火牆)。雖然 Windows Management Instrumentation (WMI) 原本就具備遠端管理電腦的能力；但 WMI 是依賴分散式 COM (DCOM) 做為遠端管理技術。這倒也還好，只不過很多防火牆預設會封鎖 DCOM 流量。沒錯，您是可以開放適當的連接埠並允許 DCOM 流量，但許多網路管理員都不願意這麼做；他們主要是考慮到一旦開放大門給 DCOM，同時也會讓各種惡意程式有機可趁。
因此 WinRM 這個「Microsoft 的 WS-Management 通訊協定實作，它是以 SOAP 為主且與防火牆互動良好的標準通訊協定，可讓不同廠商的硬體與作業系統交互操作」。說得天花亂墜，其實就是說您現在可以使用像 HTTP 和 HTTPS 一樣的標準網際網路通訊協定來執行遠端管理。
正如上個月的專欄所述，WinRM 可簡化連線到遠端電腦和從中擷取 WMI 資訊的作業。這是否表示 WinRM 是一項完美無缺的技術？其實不盡然。就像我們說過的，當 WinRM 傳送資料回到呼叫指令碼，這些資料將會以 XML 格式傳回。毫無疑問，XML 的剖析和使用可能有點棘手，尤其是對在這方面沒什麼經驗的系統管理員來說。有鑑於此，WinRM 隨附 XSL 轉換，可將傳回的資料轉換成更容易讀懂的格式。
太棒了，但言下之意，您的輸出看起來永遠會像這樣：
Win32_Service AcceptPause = false AcceptStop = true Caption = User Profile Service CheckPoint = 0 CreationClassName = Win32_Service
這也許沒那麼糟，只不過您的輸出固定都會寫入命令視窗；在預設情況下，您無法立即將資料儲存到文字檔、將這些資料寫入資料庫或 Microsoft® Excel® 試算表，除了在螢幕上顯示資訊之外，幾乎沒辦法對資料做任何處理。這樣可不妙。
不僅如此，如果您選擇只傳回 WMI 類別的特定屬性數目 (您可能會這麼做以減少網路流量)，問題會更加惡化。在只處理幾個類別屬性的情況下 — 相對於處理所有類別屬性 — 您會得到類似下面的輸出：
XmlFragment DisplayName = Windows Event Log Name = EventLog

XmlFragment DisplayName = COM+ Event System Name = EventSystem
蠻有趣的，但不是所我們見過最美的資訊呈現方式 (尤其是遍佈報告中的標題 XmlFragment)。
那您該拿它怎麼辦？撰寫自訂程式碼來剖析和格式化這些 XML 資料？聽起來不像是系統管理指令碼作者會做的事。不對嗎？

如果您要把事情作好，就自己動手作
事實證明，處理 WinRM 傳回的原始 XML 資料並不像表面看來那麼令人卻步。本月我們將示範一個簡單的方法來剖析和格式化 XML 資料。我們將使用的方法並不是處理 XML 的唯一方法，但是沒關係；我們的主要目的只是在於證明您不需要依賴 XSLT 轉換。一旦掌握基本概念，您就可以海闊天空地運用 WinRM 資料。
不過有個小問題：礙於專欄的篇幅限制，我們將省略您在 [圖 1] 看到的大部分指令碼。但這應該不構成什麼問題，因為上個月專欄中已經詳細說明了前三分之二的指令碼。在此我們把重點放在指令碼的最後三分之一部分，也就是我們實際處理傳回資料的部分。
如您所見，WinRM 史記的下半部將從我們建立 WSMan.Automation 物件的執行個體，查詢遠端電腦 (在此為 atl-fs-01.fabrikam.com)，並收到有關在該電腦上執行的所有服務的資訊談起。此時，我們來到在指令碼中設定 Do Until 迴圈以讀取和處理傳回 XML 資料的那一行；這個迴圈會不斷執行，直到沒有可讀取和處理的資料 (如果表現得好像我們很有學問的話，也就是這個迴圈會繼續執行，直到 XML 檔案的 AtEndOfStream 屬性為 True 為止)。
我們所說的正是這一行程式碼，而本月的故事就要從這一行談起：
Do Until objResponse.AtEndOfStream
在迴圈中，我們首先要使用 ReadItem 方法來讀取傳回 XML 資料的第一個區段 (由於我們使用的是 WinRM，而且正在擷取服務資訊，因此第一個區段會包含針對集合中的第一個服務所傳回的所有資料)。以名為 strXML 的變數儲存這些資料 (仍是使用 XML 格式) 之後，我們接著建立 Microsoft.XMLDom 物件的執行個體。事實上，我們會得到一份可處理的空白 XML 文件：
Set objXMLDoc = _ CreateObject("Microsoft.XMLDom")
當空白文件準備好時，我們將 Async 屬性值設為 False，然後呼叫 loadXML 方法。
接著我們會 — 您剛才說什麼？為何將 Async 屬性值設為 False？還有為什麼要呼叫 loadXML 方法？好問題；我們自己怎麼沒想到！
簡單來說，Async 屬性指出指令碼是否允許非同步下載 XML 資訊。如果此屬性為 True，便會開始下載，而且即使下載尚未完成，控制項還是會立即傳回指令碼。這聽起來還不錯。但不幸的是，您的指令碼接著會以為已經獲得所有必要資訊而繼續執行。如果指令碼實際上尚未收到所需的全部資訊，麻煩就大了。因此我們將 Async 屬性設為 False。
請注意：當然，您可以撰寫程式碼來定期監視下載狀態，藉此避免指令碼提早貿然行動。這的確行得通，但是直接將 Async 屬性值設為 False 要簡單多了。因為只要這麼做，指令碼便會在下載完成前保持封鎖；換句話說，一旦開始下載，指令碼就會耐心等候下載完成，然後再進行其他動作。
至於 loadXML 方法，它的功用正如其名：將格式正確的 XML 文件 (或文件片段) 載入我們的空白文件中。我們只需要呼叫 loadXML 方法，並傳遞變數 strXML 以當做唯一的方法參數就行了：
objXMLDoc.loadXML(strXML)
結果呢？我們現在已經將 WinRM 資料轉換成虛擬 XML 文件。也就是說，我們可以開始使用標準 XML 方法來剖析這份虛擬文件。
為此，接下來我們必須使用以下這行程式碼來建立 XML 檔案中的根項目的物件參考：
Set objElement = objXMLDoc.documentElement
我們現在已經準備好找點樂子 (當然，前提是您覺得剖析 XML 檔案是種樂趣，而我們 Scripting Guy 全都覺得這很好玩)。
您可能還記得，我們的 WMI 查詢語言 (WQL) 查詢 (或者以 WinRM 述語來說，我們的 Filter) 如下所示：
strFilter = "Select Name, DisplayName " & _ "From Win32_Service Where State = 'Running'"
您可以看到，我們已經從 Win32_Service 類別要求兩個屬性：Name 和 DisplayName (也加入 Where 子句，將傳回資料限制為正在執行的服務。不過現在先擱在一旁不管)。我們要求兩個屬性，這點很重要嗎？要求的順序有關係嗎？也許是，我們哪會知道這些？
好吧，您說得沒錯。或許，身為本文作者，我們的確應該知道如何回答這些問題。沒關係，其實我們知道這兩個問題的答案都是肯定的。我們在 WQL 查詢中要求兩個屬性，這點很重要嗎？是的，畢竟，這些是唯一會回傳給我們的屬性 (相對於執行 Select * From 查詢，這個查詢將傳回單一類別的所有屬性值)。
那麼，這兩個屬性的順序也很重要囉？一點也沒錯。我們指定屬性名稱的順序也就是屬性值傳回的順序。之所以重要是因為每個屬性值都將以根項目的子節點 (或區段) 的方式傳回。第一個傳回的子節點是哪個屬性值？這個問題太簡單了。在這個範例中，第一個子節點是 Name 屬性，因為這是列在 WQL 查詢中的第一個屬性。第二個傳回的子節點是哪個屬性？答對了 — 就是 DisplayName 屬性，因為這是查詢中列出的第二個項目。
等一下。您是自己想到的嗎？還是有人先洩漏本專欄內容給您？嗯 ...
無論如何，這樣比較容易回應 Name 屬性值。我們只需要參考 ChildNodes (項目 0) 集合中第一個項目 (項目 0) 的 NodeValue，如下所示：
Wscript.Echo "Name:" & _ objElement.ChildNodes(0).ChildNodes(0).NodeValue
那麼我們如何參考 DisplayName 屬性值？在本例中，我們會參考第二個 ChildNodes (項目 1) 集合中第一個項目的 NodeValue：
Wscript.Echo "Display Name:" & _ objElement.ChildNodes(1).ChildNodes(0).NodeValue
萬一我們的 WQL 查詢中有第三個屬性 (譬如說 Status)，該怎麼辦？此時，我們只要參考第三個 ChildNodes (項目 2) 集合中第一個項目的 NodeValue：
Wscript.Echo "Status:" & _ objElement.ChildNodes(2).ChildNodes(0).NodeValue
基本流程就會一直重複，直到最後一個屬性為止。
那麼，我們的指令碼輸出現在看起來如何？如下所示：
Display Name:Windows Event Log Name:EventLog

Display Name:COM+ Event System Name:EventSystem
不過，它看起來與預設的 WinRM 輸出並沒有太大不同 (雖然我們的確已經去除了愚蠢的 XmlFragment 標題)。差別在於：藉由處理個別屬性值，我們不再侷限於預設格式 (請注意，我們使用標籤 Display Name 而非 DisplayName)，也不再受限於只能在命令視窗顯示資訊。
您是否偏好將這些資料寫入 Excel 試算表？易如反掌。首先，將下列程式碼區塊 (它會建立和設定新的 Excel 試算表) 緊接著插入到 WinRM 指令碼中呼叫 Enumerate 方法的那行程式碼之後：
Set objExcel = _ CreateObject("Excel.Application") objExcel.Visible = True Set objWorkbook = objExcel.Workbooks.Add() Set objWorksheet = objWorkbook.Worksheets(1)

i = 2 objWorksheet.Cells(1,1) = "Name" objWorksheet.Cells(1,2) = "Display Name"
接著，將原本的 Do Until 迴圈替換成這個程式碼，如 [圖 2] 所示。試試結果如何吧。
Figure 2 New Do Until loop (Close Figure 2)
Do Until objResponse.AtEndOfStream strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom") objXMLDoc.async=False objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue i = i + 1 Loop

WinRM，第三篇？
本月及上個月專欄應該足以讓您開始使用 WinRM。希望如此；WinRM 是一項有趣的新技術，絕對能簡化遠端管理電腦的程序 (同時確保安全性)。當然，每個人心裡一定會想：這是否表示 WinRM 傳奇將有第三篇？
抱歉，我們不能透露任何消息。並非基於安全性考量，而是由於 Scripting Guy 一向採取的計劃與決策模式，使得我們不曉得還會不會撰寫其他 WinRM 內容。老話一句，敬請密切期待！
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
Doctor Scripto 發生了一點兒小意外。他把一片指令碼到處亂放 (不像守規矩的指令碼作者會把它放好)，然後不小心被它絆倒，讓指令碼片段到處散落。他千辛萬苦地終於找回所有變數、關鍵字、符號等等，然後依照字母順序排好，但現在他得要將它們組合起來以便復原完整的指令碼。這會花上一些時間，但是他希望能在下個月的《TechNet Magazine》出版前得到解答。在此同時，不妨親自試一試，看您能否將隨機分散的指令碼片段恢復成完整的指令碼。祝您好運！
提示：好吧，讓我幫您一把。最終的指令碼將刪除本機電腦上早於指定日期之前的所有檔案。

Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：Clumsy Doctor Scripto，2007 年 12 月
沒錯，Dr. Scripto 設法將他的指令碼復原。以下是重新組合好能用的指令碼，這段指令碼將刪除本機電腦上早於指定日期之前的所有檔案：
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

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


 安全性監控: Windows 網域密碼原則
安全性監控
Windows 網域密碼原則
Derek Melber

如果您是 Windows 網域的系統管理員，想必對網域使用者帳戶中密碼原則的相關限制不陌生。然而，隨著 Windows Server 2008 的推出，有些限制也將跟著消失。讓我們來看看這個新作業系統如何解決這個問題 — 無力實作多項密碼原則。
無論您執行目前哪一種版本的 Windows® 網域 (Windows NT®、Windows 2000 Active Directory® 或 Windows Server® 2003 Active Directory)，都受限於 一個網域只能有一個密碼原則的規定。實際上，受到侷限的不僅是密碼原則，而是 [帳戶原則] 底下更廣泛的設定範圍。[圖 1] 顯示了這些原則和設定。
Figure 1 Account policies (Close Figure 1)

密碼原則
強制密碼歷程記錄
密碼最長使用期限
密碼最短使用期限
最小密碼長度
密碼必須符合複雜度需求
使用可還原的加密來存放密碼
帳戶鎖定原則
帳戶鎖定期間
帳戶鎖定閾值
重設帳戶鎖定計數器的時間
Kerberos 原則
強制使用者登入限制
服務票證最長存留期
使用者票證最長存留期
使用者票證更新最長存留期
電腦時鐘同步處理的最大容錯性
這些原則設定預設會套用到與網域相關聯的所有網域和使用者帳戶。這是因為群組原則往下繼承到 Active Directory 結構的方式之故。如果要更進一步認識這些原則對網域和本機使用者帳戶所產生的影響，不能不知道這些原則在哪裡設定，以及群組原則的繼承關係如何影響所有不同的使用者帳戶 (請注意，Kerberos 原則設定只會套用到網域使用者帳戶，因為只有網域使用者帳戶會使用 Kerberos 進行驗證。本機使用者帳戶是以 NTLMv2、NTLM 或 LM 進行驗證)。

設定帳戶原則
在 Active Directory 內，群組原則會建立和控制整個網域的帳戶原則。這個動作是在您初次安裝 Active Directory 網域時，以預設的群組原則物件 (GPO) 連結 Active Directory 中的網域節點而達成。這個 GPO 稱為預設網域原則，它在帳戶原則的所有三個區段中皆具有預設設定。[圖 2] 顯示 Windows Server 2003 網域上密碼原則項目初始設定的完整清單。
Figure 2 Default password policies for Windows Server 2003 domain
Figure 2 Default password policies for Windows Server 2003 domain
這個 GPO 中的設定會控制所有網域使用者帳戶以及每部網域電腦的帳戶原則。請記住，所有的網域電腦 (包括桌上型電腦和伺服器) 都有一個本機安全性帳戶管理員 (SAM)。而這個預設 GPO 設定所控制的也正是這個 SAM。不用多說，本機 SAM 也包含各個電腦的本機使用者帳戶。
預設網域原則中的設定，是透過 GPO 的正常繼承關係 (往下繼承到 Active Directory 結構)，影響所有的網域電腦。由於這個 GPO 是連結到網域節點，因此網域當中所有的電腦帳戶都將受它左右。

您無法對目前密碼原則進行的動作
Active Directory (在 Windows Server 2003 中) 目前的實作一直都對密碼控制存有許多誤解，儘管經過多年嚴格的測試，而且也沒有證據證明這些誤解有其道理，這種情形依然沒有改善。原則顯然是 (或者應該是) 完全照設計的方式來運作。
話雖如此，許多系統管理員還是相信有可能對同一網域內的使用者採行多項密碼原則。他們認為您可以建立一個 GPO，把它連結到組織單位 (OU)。這個構想是將使用者帳戶移到 OU，讓 GPO 得以左右物件。然後將 GPO 內的密碼長度上限設為 14 個字元，修改帳戶原則以建立更安全的密碼原則。但是基於種種原因，這樣的設定還是無法提供預期的結果。首先，密碼原則設定是以電腦為基礎，而不是以使用者為基礎的原則。只要是以這種概念為主的設定，就無法影響使用者帳戶。其次，要修改網域使用者帳戶的帳戶原則設定，唯一的方法就是在連結到網域的 GPO 內進行。連結到 OU 且設定成要更改帳戶原則設定的 GPO，會修改位於 OU 裡面或是位於連結 OU 之子 OU 裡面的電腦的本機 SAM。
第二個誤解是，在根網域 (Active Directory 樹系的初始網域) 內建立的帳戶原則設定，會往下流向或繼承到樹系中的子網域。這也是錯誤的觀念，根本無法使設定發揮作用。連結到網域和單一網域內各個 OU 的 GPO，並不會影響到其他網域的物件，即使 GPO 所連結的網域是根網域也一樣。要讓 GPO 設定橫跨到不同網域中的物件，唯一的方法就是將 GPO 連結到 Active Directory 站台。

密碼的未來
我們剛剛看到，目前的 Windows 版本是以簡單且直接的方式來處理使用者帳戶密碼。其中包括所有網域帳戶共用一組密碼規則，以及透過連結到 Active Directory 中網域節點的群組原則物件來管理帳戶原則。但是這種方式會隨著 Windows Server 2008 的到來而被掃地出門。
Windows Server 2008 及它所附隨的 Active Directory 基礎結構，是採取不同的方法。過去帳戶原則是置於 GPO 當中，所有的網域使用者帳戶只能設定一個原則，而現在設定則被移入 Active Directory 更深層的部分。另外，帳戶原則也不再以電腦帳戶為基礎，現在您就可以鎖定個別使用者和使用者群組，來控制他們的密碼限制。這對 Windows 系統管理員來說可是全新的概念，畢竟我們長久以來一直都是採用電腦帳戶的帳戶原則。

Windows Server 2008 內的帳戶原則
Windows Server 2008 並不是使用預設網域原則來建立帳戶原則。事實上，您根本不會用到 GPO 來建立網域使用者帳戶的帳戶原則。Windows Server 2008 會將您導往 Active Directory 資料庫裡面進行修改。說得更具體一點，您是使用類似 ADSIEdit 的工具來修改 Active Directory 物件及其相關屬性。
這項改變的原因是，群組原則並不是為了在相同網域內使用多個密碼而設計的。Windows Server 2008 在每個網域實作多個密碼的功能雖然簡潔了當，但是使用起來並不方便。但是只要假以時日，設定這些設定值的介面一定會越來越好用。不過現在您只能乖乖戴上防止 Active Directory 資料庫入侵的安全帽，在系統內採用這項改變吧。
如果您比較喜歡採取不同的方式，也不一定要使用 ADSIEdit 來修改帳戶原則設定。只要可以接通 Active Directory 資料庫，使用 LDAP 編輯工具，或甚至是撰寫指令碼都可以。在 Windows Server 2008 中實作密碼原則所採取的方式，與過去截然不同。使用新功能時，您必須考慮哪些使用者和群組要接受哪些密碼設定。
您不但得考慮密碼長度，也要考慮伴隨密碼原則設定而來的其他限制，包括最短和最長使用期限，以及歷程記錄等等。其他考量事項還包括如何控制使用者鎖定原則設定和 Kerberos 設定。目前的帳戶原則設定與那些在 Windows Server 2008 中 Active Directory 資料庫內設定的帳戶原則設定，是一對一的關係。不過要特別注意的是，既然原則設定現在是 Active Directory 物件和屬性，它們的名稱也跟以前不一樣。
要實作新密碼設定，必須在 [密碼設定] 容器下，建立名為 msDS-PasswordSettings 的密碼設定物件 (PSO)，它的 LDAP 路徑是 "cn=Password Settings,cn=System,dc=domainname,dc=com"。請注意，您工作所在網域的網域功能層級必須設定為 Windows Server 2008。在這個新物件下，您要填寫幾項屬性的資訊，如 [圖 3] 所示。
Figure 3 Password attributes in Active Directory (Close Figure 3)

Active Directory 屬性名稱 | 屬性描述
msDS-PasswordSettingsPrecedence | 建立當使用者身為多個採用不同密碼原則之群組的成員時，取得優先權的條件。
msDS-PasswordReversibleEncryptionEnabled | 切換是否啟用可還原加密。
msDS-PasswordHistoryLength | 決定有多少中途密碼必須是唯一密碼才能重複使用。
msDS-PasswordComplexityEnabled | 建立密碼所需的字元數目和類型。
msDS-MinimumPasswordLength | 建立密碼的最小長度。
msDS-MinimumPasswordAge | 決定使用者必須使用密碼多久的時間才能加以變更。
msDS-MaximumPasswordAge | 決定使用者可以使用密碼多久的時間才會要求他變更。
msDS-LockoutThreshold | 決定允許密碼嘗試失敗多少次之後再鎖定使用者帳戶。
msDS-LockoutObservationWindow | 決定密碼計數器錯誤多少次之後再重設。
msDS-LockoutDuration | 決定在密碼嘗試失敗太多次之後要鎖定帳戶多久。
如您所見，與帳戶原則設定相關的所有群組原則設定都會複製成屬性。請注意，另外還有一個優先順序設定，這在相同網域內實作多個密碼是不可少的，因為發生衝突是在所難免，所以需要有解決它們的機制。

鎖定帳戶原則設定
對於您所建立的每個物件，都必須填寫所有屬性，以塑造每一個使用者的帳戶原則。您可以使用 msDS-PSOAppliesTo 這個新屬性，來決定哪些物件將接受原則設定組。這是讓您將特定設定導向特定使用者的最佳屬性。這個屬性底下的清單可以是使用者或群組，但是就跟建立存取控制清單一樣，最好採用群組而不是使用者。群組比較穩定、明顯，而且處理起來通常要容易許多。

起身鼓掌
這麼多年來我們一直希望能夠在相同的 Active Directory 網域內使用多個密碼，現在終於美夢成真了。整個網域裡面的每個使用者，將不再受限於相同的密碼安全性層級。比方說，一般使用者可以使用 8 個字元的密碼，而 IT 專家 (可能具備系統管理員權限) 則是更複雜的 14 字元密碼。
進入 Active Directory 資料庫建立或修改帳戶原則設定是需要一點時間習慣，不過幸好新設定所採用的方式與您所熟悉的方式相仿。開始使用 Windows Server 2008 之後，別忘了探索這些新設定，因為它們一定是您要面對的前幾項設定。

Derek Melber是一名獨立的顧問暨培訓講師，身兼 MCSE、CISM、MVP。他教授和宣導 Microsoft 技術，主重 Active Directory、群組原則、安全性和桌面管理。Derek 著有幾本 IT 書籍，包括《Microsoft Windows Group Policy Guide》(Microsoft Press，2005 年)。您可以透過電子郵件與他聯絡：derekm@braincore.net.


 桌面檔案: 在虛擬世界中部署 Windows
桌面檔案
在虛擬世界中部署 Windows
Wes Miller

虛擬運算技術比比皆是，如果您還沒利用到它，應該開始採用。虛擬化可降低硬體依存性，它基本上會建立自己的硬體抽象層，可讓您在主機系統之間移動一或多個虛擬系統 (例如 Windows Server 或 Windows 用戶端作業系統)。
不用說，虛擬化與模擬是有差別的，虛擬化並不會模仿虛擬系統的處理器，它只是以虛擬系統可以存取的方式來表示主機系統的資源。也就是說，主機系統對虛擬系統來說是通用的。一般來說，您可以在不同 OEM 所建造的系統間移動虛擬系統，主機的硬體通常無關緊要，但有些地方要特別注意。比方說，如果您將虛擬系統從含有某 CPU 廠商 (例如 AMD) 處理器的硬體移到含有另一個廠商 (例如 Intel) 處理器的硬體，可能會出問題 (要看您採用的虛擬化技術而定)。這是因為虛擬運算技術只會在主機和虛擬系統間來回傳遞資訊，它並不會模擬虛擬系統的特定 CPU (譬如，在舊版 PowerPC 型 Macintosh 上執行的 Microsoft® Virtual PC 就可以這麼做)。
不過，虛擬化倒是會對虛擬系統模擬重要的硬體元件。這大多限於網路、視訊 (一般是不含進階模擬 GPU 且相當有限的裝置) 和大型存放區。這些組合全都是藉著向虛擬系統呈現一或多種軟體模擬的裝置來運作。如果您閱讀我的專欄已經有一段時間，就會注意到這跟 Windows® PE 所因應的是同一份裝置清單。在虛擬化中，這份裝置清單與您讓 Windows 真正辦事所需的裝置類型一樣。除此之外，所有虛擬化技術也都必須模擬 BIOS。雖然它們也可以模擬可延伸韌體介面 (EFI)，但是在當今 EFI 作業系統有限的情況下，還是少用為妙，這樣的模擬就足以讓虛擬系統開機。BIOS 和每個裝置都會在軟體中模擬實際的裝置，然後將該裝置呈現給虛擬系統。這表示，它們也像實際裝置一樣需要驅動程式 (並不一定是 Windows 提供的驅動程式)。這個概念很重要，理當謹記在心。
雖然有些虛擬化技術也可以讓 USB (或 USB 2.0) 裝置與其互動，但對於這些技術的細節我在此將不多做著墨。除了那些 USB 裝置需裝有驅動程式 (印表機、USB 無線 NIC 等等) 或特定DirectX® 支援 (大多數虛擬化技術中通常沒有) 之外，您應該不用多做什麼，就可以讓它們順利運作。有一點別忘了，要支援 USB 或其他非模擬的裝置，當然是要看您所採用的虛擬化技術而定。在嘗試將您所採用的虛擬化產品與新裝置搭配使用之前，應確實了解它的限制 (正如我所謂的工欲善其事，必先利其器)。
目前 Windows 上有兩大虛擬化技術廠商：Microsoft 和 VMware (vmware.com)，還有一些後起之秀如 Parallels (parallels.com)。
現在，您對虛擬化已經有了初步的了解，接著我將在專欄的其餘的部份討論如何進行設定、如何避開最常見的陷阱，以及如何在您環境中眾多的機器間進行部署。

虛擬部署
部署虛擬系統跟部署實體系統沒什麼太大差別，但是您等一下就會看到，做出區別其實不無道理。
在早期的 Windows NT® 時代，您得透過安裝程式來部署。沒錯，是可以用指令碼來進行，但還是得跑完整個程序。安裝程式一完成，就將該映像複製到多台系統上，這種方法在概念上是蠻便利的，但實際上並不受到支援。
最後，Microsoft 終於決定應該支援磁碟複製或是「複製」的 Windows NT 系統。所以，目前在部署實體系統時可採行的方法，同樣也適用於部署虛擬系統，那就是：Winnt32 (也就是 Windows Vista® 和 Windows Server® 2008 上為 setup.exe)；Windows PE (1.x 或 2.x，視您正在部署的用戶端而定，如我之前的專欄中所說明的一樣)；遠端安裝服務 (RIS) 或 Windows 部署服務 (WDS)；或是 Sysprep (隨 Windows NT 4.0 推出用於部署的系統準備工具)，以及您最喜愛的磁碟複製技術 (例如 ImageX)。
當然啦，您只需要在第一次部署特定 OS 時才需要這麼做。之後，只要複製就可以了。但是採用我剛剛提到的這些磁碟複製方法有個問題。

使用 Sysprep
Microsoft 不支援磁碟複製的最初決定主要是由 Windows NT 安全性識別項 (SID) 提出的。所幸，Sysprep 提供一個解決辦法。不過先來看看它要解決的問題。如 support.microsoft.com/kb/314828 中所述，SID 是由 SID 結構修訂編號 (通常是全域唯一識別碼，或稱 GUID) 組成，用來識別個別的 Windows 電腦。此一識別碼接著會被用作為所有本機帳戶識別碼的根項。本機帳戶有其各自的唯一識別碼，稱為相關識別元 (RID)。RID 包括了帳戶識別碼，與 SID 結尾串聯。因此兩者的組合遂成了本機帳戶的識別碼。
讓我們來看看為什麼使用系統管理員 SID S-1-5-21-191058668-193157475-1542849698-500 會有問題。此處的 S-1-5 是一個描述項，用來定義這是一個 SID (SID 的文字表示中一定會有 S)，而 1 和 5 則分別表示 Windows NT SID 修訂編號和授權識別碼值 (在此為 Windows Security)。其餘的部分則是真正的 SID，包括 500，代表這是已知的 SID — Windows 系統管理員帳戶。所有 Windows 安裝上預設建立的系統管理員帳戶 (而且無法加以刪除) 都有個以 500 為結尾的 SID。安裝之後新增到 Windows 的本機使用者帳戶則從 1000 開始重覆。
Windows Sysinternals (在我討論 PSTools 的專欄中曾提到，網址是 technetmagazine.com/issues/2007/03/DesktopFiles) 所提供的 PSGetSID，可讓您列舉系統上指定使用者的 SID 或系統的 SID。請參閱 [圖 1]，其中的 PSGetSID 輸出顯示我的虛擬系統的 SID 以及我的使用者帳戶 1003 的 SID。
Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003
Figure 1 Output of PSGetSID for a virtual system's SID and the SID of user account 1003
由於本機帳戶 RID 是以這個 SID 為基礎，因此當您以磁碟複製系統或直接複製虛擬機器映像時，會發生什麼問題應該顯而易見。因為不變更 SID (這是 Sysprep 的主要工作但不是唯一的工作)，您最後得到的是重要元件的副本，這是讓 Windows 系統之所以獨一無二的元件。如果系統 A 和系統 B 具有相同的系統管理員 SID，那麼各系統上的使用者就可以合法地將自己識別為相同的使用者。當向系統 A 驗證時，系統 B 的所有本機帳戶也可以這麼做，反之亦然。更糟的是，這些系統在呈現給 Active Directory® 時也將具有相同的 SID。因此，如果您允許系統 A 向網域資源驗證，但不允許系統 B 這麼做，便會發生衝突。若將 B 設為拒絕，實際上也會拒絕 A。
因此，使用 Sysprep 在系統上重新產生 SID 是很重要的 — 尤其是在虛擬系統的案例下，因為系統映像很容易就可以傳播。您也不該使用協力廠商 SID 變更工具 — 只能使用 Sysprep。Sysprep 是經過 Microsoft 的設計、測試且受到它的支援，可用來準備系統進行複製 (即使是虛擬系統)。請參閱 [圖 2] 看一下在變更系統上的 SID 之前，Sysprep 的模樣。如果您的下一步是要準備系統以進行複製，請確定永遠不要選取 [不重新產生安全性識別元] 選項。
Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication
Figure 2 "Don't regenerate security identifiers" should be unchecked when preparing for duplication
除了將 SID 更新成新的識別碼之外，Sysprep 還會修改任何它所知的私人資料存放區，來反映 SID 和電腦名稱，或變更它們的加密以採用新 SID。當中的例子包括排定的工作資料存放區，以及 IIS Metabase 裡面的值 (若有安裝 IIS 的話)。
Sysprep 也會強制刪除系統上的每個 NIC，連帶清除該 NIC 的網路設定資料。因為網路設定在登錄中是掛在 NIC 上，而且與該 NIC 的關係依據的是 NIC 的硬體識別碼 (這在虛擬移向虛擬系統以外的情況下常常可能拆散)，所以 Sysprep 也將這個過去被遺棄的資料一併清理掉。
Sysprep 還會清理系統上所有 Active Directory 成員資格的資訊。換句話說，強迫將系統從網域中移除是它的職責之一。這可確保剛收到新 SID 的系統可安全地加入網域。有些 SID 變更公用程式讓您不必將電腦從網域中移除，即可變更它的 SID，但這既不可靠也不安全。如果您真的有必要在屬於網域成員的機器上執行 Sysprep，可以在執行 Sysprep 前將它從網域移除，或是執行 Sysprep 並讓它為您料理這檔事。
還有相關的一點要注意的是，如果您將任何網域控制站 (DC) 虛擬化，則必須複製尚未升級為 DC 且未加入網域而只是獨立伺服器的系統。Windows Server 2003 Small Business Server Edition 則是例外，在此版本中，您無法安全地磁碟複製 DC。若要安全地建立新 DC，您應該為已經準備好加入網域且已升級為 DC 的伺服器建立磁碟映像。Sysprep (除了在 SBS 的特例下，也就是單一樹系/單一伺服器的情況下) 並不知道要怎麼在 DC 上安全地變更 SID。
最後，除了變更 SID 並將電腦從網域移除之外，Sysprep 還會變更電腦名稱。
在製作 (甚或只是複製) 虛擬系統的映像時，說您得執行所有上述的工作看起來可能很吃重。可是這些都是必要的動作 — 尤其是當您在包含其他實體或虛擬系統的網路上、網域中使用這些系統，或是在網路上與它們自己任何其他副本共同使用時。
如果您在複製虛擬系統時不使用 Sysprep，十之八九會碰到幾個明顯的問題 (Active Directory 或其他網路衝突)，而且有好些問題可能是您始料未及的。例如，您的虛擬映像將非常容易受到駭客攻擊，因為只要攻擊一個就可以獲得其他幾個的存取權。

驅動程式和硬體抽象層
我之前說過，內含在虛擬映像中的虛擬裝置可能沒有 Windows 的「內建」驅動程式。在部署 (或是當使用 Sysprep 部署磁碟映像) 時，確定您手邊有裝置的驅動程式，因為將虛擬映像從一個存放匯流排驅動程式移到另一個存放匯流排驅動程式就跟使用實體的硬體一樣，很容易發生可怕的 0x0000007B 驅動程式錯誤。NIC 的情況也是如此，雖然大多數的虛擬化產品都尋求提供相當通用的虛擬裝置，您可能還是有需要為它安裝額外的驅動程式。
您也不能忽視那個討厭的硬體抽象層 (HAL)。在理想的情況下，您應建立虛擬機器來支援 Advanced Configuration and Power Interface (ACPI) 多處理器 (請參閱 intel.com/technology/iapc/acpi)，如果您的虛擬技術有支援的話。在 HAL 間轉換通常不受到支援 (請參閱 support.microsoft.com/kb/309283 以取得詳細資訊)。然而，有些虛擬化技術— 或者，更重要的是，許多移轉技術 — 都承諾它們可以安全地將非 ACPI 的 Windows 安裝移到 ACPI 安裝，或反之亦然。但事實並非如此，而且若您果真遇到問題，Microsoft 也不支援由此產生的 Windows 安裝。我剛剛提到的支援網頁上所討論的限制也適用於虛擬化的系統。請參閱 [圖 3] 的例子，參考 HAL 在我其中一台虛擬機器上的裝置管理員中看起來的樣子 — 在本例中是使用 ACPI 單一處理器 HAL 執行。請勿與單一處理器相混淆，這個處理器可與其多處理器家族相互交換。
Figure 3 HAL in Device Manager on a virtual machine
Figure 3 HAL in Device Manager on a virtual machine

其他變更
變您所能變並接受您所不能變
當考慮將實體移轉到虛擬時 (反之亦然)，您必須記住可變與不可變的事項。您可以變更 Windows 安裝的下列各方面：
  • HAL (但只能從單一處理器變更為多處理器，或反之亦然，只要它們以相同的電源設定為基礎便可)。
  • 大型存放控制器 (這並不容易 — 但大多數的實體移轉至虛擬的解決方案都已經自行嘗試這麼做)。要注意的是，大部分的廠商都提供 IDE 和 SCSI 存放解決方案。部署時請做出明智的選擇，因為移轉的作業並不輕鬆。一般來說，選擇 SCSI 會產生比較可靠的裝置 (這是就大部分廠商 SCSI 裝置模擬實作的情況而言)。
  • 網路控制卡 (雖然在虛擬移轉至虛擬的案例下，這在同一家廠商的技術內通常並無不同)。
您無法變更 Windows 安裝的下列各方面：
  • HAL (除了前文所述使用相同的電源設定時)。您不應假設進行此動作的移轉解決方案會產生穩定或可靠的 Windows 安裝 (而且更重要的是，它並不會受到 Microsoft 支援)。

除了變更 SID 和電腦名稱，您還必須變更某些與您所使用的虛擬運算技術相關的值。您尤其必須變更 MAC 位址 (網路裝置的唯一識別碼)。此外，許多虛擬應用程式也都有自己的唯一識別碼。絕大多數都是將這些存放在自己的電腦設定檔案中，因此您應該要知道如何操控這些項目 (以及維持它們的有效性)。請注意，許多支援 Pre-Boot Execution Environment (PXE) 的虛擬化產品會根據自己的唯一識別碼來輸入 SMBIOS UUID — 這更凸顯了如果您將它加入網域時必須變更這項行為 (或是讓支援的虛擬化軟體為您進行變更)；否則可能無法管理 WDS 或 RIS 用戶端系統 (如果 GUID 發生衝突的話)。我用過的大部分虛擬化解決方案在發生 MAC 位址重複的情況下，可能會造成嚴重的網路問題；因此如果您不只是要移動虛擬機器而已，變更 MAC 位址 (如果虛擬化軟體沒有為您變更的話) 是很重要的。
在準備要部署的虛擬系統時，其他必須注意的元件就是連結的磁碟或快照集。根據您的虛擬化解決方案而定，這些元件也可能稱為差異磁碟或其他不同的名稱。但要是您執行 Sysprep 來準備系統，並且有搭配虛擬系統的快照集 (或其他可還原的狀態) 時，為了讓映像在複製時保持安全和可靠，必須摧毀它們。在採用快照集或其他「復原磁碟變更」技術方法的情況下，還原快照集可能是指回歸到有一個以上的系統 (都來自原始虛擬機器) 現在彼此相衝突的情況 (或甚至是與原始來源系統衝突，如果它也被還原的話)。所以任何快照集或差異磁碟關聯上應該要先執行 Sysprep。

最佳化
大部分虛擬化技術都包含虛擬機器新增功能或工具，可協助改進從主機與虛擬系統互動的效能和經驗。在各種效能增強中，通常包括最佳化滑鼠和鍵盤輸入的工作，此外也包括改進的複製和貼上 (或其他主機對虛擬系統) 互動。部署前，請在您的虛擬系統中安裝這些工具的最新版本。
您還必須確保用戶端記憶體已針對虛擬作業系統經過最佳化的設定，並且與其將要部署的主機一致。您最不想碰到的情況是將一個要使用主機系統 1GB RAM 的 Windows XP 映像部署到實際上沒有那麼多 RAM 的主機系統。
另外也要記住當今大多數虛擬技術的限制 — 重要的是讓您的使用者知道如何與附加到虛擬系統的周邊設備互動，以及哪些應用程式可以在虛擬作業系統上運作，哪些不可以 (例如，大部分虛擬作業系統不支援 DirectX9 或 10，或是支援舊版的能力有限)。使用者可能不曉得那是什麼意思或它如何表現出來 (有些應用程式無法妥善處理處理這類失敗)。

主機的考量事項
要注意的是，關於執行虛擬化技術的主機電腦，無論當下執行的是完整的作業系統或是直接在硬體上執行的 Type 1 Hypervisor，通常都沒有什麼好擔心的。大多數虛擬化技術的設計會確定虛擬作業系統對主機一無所知 (或是不需要知道太多)。不過請確保您知道哪些主機正在使用中，以免從一部主機移往另一部主機的虛擬系統發生問題。也確定您曉得虛擬化廠商的產品在特定平台上的限制。因為您雖然可能可以在平台間移動，還是可能在過程中遺失或獲得主機 OS Type 2 Hypervisor (虛擬化應用程式) 的某些功能。

其他部署機制
相關 Sysprep 連結
下列文件可提供您許多使用 Sysprep 的協助：
  • 使用 Sysprep 設計映像式安裝
  • 如何使用 Sysprep 工具將成功的 Windows XP 部署作業自動化
  • 如何使用系統準備工具 (Sysprep.exe) 執行磁碟複製
  • 在不同電腦上使用系統準備工具

使用 Sysprep 或磁碟複製 (或直接執行 Sysprep 然後複製虛擬機器) 是部署虛擬系統明顯的選擇，但還有其他方法。事實上，無論您是使用映像處理或安裝程式，使用 Windows PE 搭配虛擬化可能比搭配實體機器還要簡單，因為您處理的是 ISO 檔案，而不是實體 CD。要注意的是，有些虛擬化技術不太能處理 DVD 媒體，所以請確實向您的虛擬化廠商洽詢支援事宜。您可以使用 winnt32 或 setup.exe (在 Windows Vista 或 Windows Server 2008 的情況下)，但是並沒有什麼特別的好處。如果您使用其他 Microsoft 部署技術，像是 Automated Deployment Services，您的虛擬化技術會支援 PXE 展開以網路為基礎的部署，就跟使用 RIS 或 WDS 一樣。

移轉
最後，除了實際移轉整部電腦外，別忘了使用者狀態移轉工具 (USMT)。USMT 可讓您將使用者的設定從實體用戶端輕鬆移動到新的虛擬系統上。因此，若是您的使用者想要將舊資料和設定移轉到新的虛擬機器上，舉例來說，您可以輕鬆取得 Windows XP 的檔案和設定，將這些檔案和設定儲存到 UNC，然後再發送到新的虛擬機器。

Wes Miller 現居德州的奧斯丁。他之前任職於同樣位在奧斯丁的 Winternals Software，並且曾在 Microsoft 擔任 Windows 的專案經理與產品經理。您可以透過電子郵件與 Wes 聯絡：technet@getwired.com。


 現場筆記: 變幻莫測的未來
現場筆記
變幻莫測的未來
Romi Mahajan

哲學家 暨經濟學家馬克斯曾在手記中寫道「一切堅實事物終將煙消雲散 (all that is solid melts into air) 」。當時在 19 世紀的中歐，各種社會分野都因為工業化與資本主義而起了變化。這一段強而有力的見解，闡述了區隔與分野並非永恆不變的真理，這在許多形式和情境中都獲得印證，技術領域也不例外 — 在這個世界中，只有變化才是永恆的真理。
在此發展迅速的產業中，沒有什麼比消費導向技術的興起更能說明變化之快速 (以及我們為了應付此變化而面臨的挑戰)。事實上，IT 已經變得「消費化」，而且變化的主要跡象分散在私人生活的各個領域，並對工作與生活兩方面都造成巨大影響。這個現象以下列幾種面貌顯現：
  1. Web 2.0 世界是關於讀/寫網際網路；寫入網際網路可說是作者同時扮演消費者的角色。
  2. 消費者應用程式與技術儼然形成商業的「光環」效應。
  3. 網際網路的核心配置因為 IT 消費化的現象而經歷規劃與考驗。
  4. 諸如支援工程師等 IT 結構必須根據家用與商用技術之間模糊的分界來進行規劃、應付與學習。
  5. 決策者本身也是消費者和專業人士。
  6. 個人「最愛」的技術幾乎都是消費者產品，而非商用產品。
這個趨勢的意涵深遠，而各種分類是可互換的，從很多例子都可以看得出來。我在科技公司上班的朋友說，他們公司的所有服務電話中有高達 8% 的來電是關於 iTune 更新。Cisco 白皮書《Exabyte 時代》(The Exabyte Era) 開宗明義就點出兩個重點 — 資料流視訊不會拖垮網際網路，而且 YouTube 只是個開始。據 NDP Group 報告指出，Apple Corporation 光在 2007 年 3 月間幾乎是達到零售膝上型電腦 10% 的市場佔有率 — 這都要拜 iPod 的光環效應所賜。Microsoft 大量投資遊戲、音樂、數位相機和視訊裝載等領域。而且今日的公司乾脆在《第二人生》(Second Life) 遊戲上開會。
此外，科技品牌已經昇華並廣泛使用，成為永垂不朽的表徵。人們「Google」各種人事物，談論著 iPod，窩在「myspace」，還有玩「Xbox®」。人們與科技之間建立情感交流，而這份感情寄託的影響所及從辦公室、家庭、再回到辦公室，然後移情到創造這些裝置、應用程式、網站及社群的公司。當我們形成觀感時 — 好的、壞的或不好不壞的 — 這些觀感會同時存在於我們的私人與工作形體中。
因此，與私人相關的事物變得更複雜。如果公司打算與時漸進迎接這些挑戰來調整訊息、表達親密性和關懷客戶，就必須進行底層的文化變遷。之前，當角色專門化尚淺時，通用訊息是行銷的中流砥柱。但是近年來情況丕變，「焦點」訊息開始風行，如雷射般精準的定位對照工作職稱、目標群區隔、公司規模和特別技術等分類。但是其中遺漏了一個事實，就是的確一切堅實的都煙消雲散了，而且訴諸大眾的私人/消費者具象，而就這是建立關聯以及引領趨勢的方法，而且是唯一的方法。
變幻莫測意味著互換性以及缺乏硬性的類別分際。換言之，我們不應該在消費者與商用技術的定義之間築起高牆。IT 消費化時代已經來臨，而未來的確是變幻莫測的。

Romi Mahajan 在 Microsoft 擔任技術聽眾與平台行銷 (Technical Audience and Platform Marketing) 小組的行銷總監。Romi 在政治、環保、技術及社會等多方領域都曾廣泛發表過文章。


 Windows 機密文件: 不必把搖桿當微波爐
Windows 機密文件
不必把搖桿當微波爐
Raymond Chen

我最近在看 我同事 Audio Fool 所寫的部落格，讓我想起了多年前曾經犯下的一個錯誤，至今仍讓我惴惴不安。當初 DirectInput® 力回饋搖桿介面當紅時，許多搖桿廠商受邀到 Microsoft 位於華盛頓州列德蒙 (Redmond) 市的辦公室，共同商討即將推出新介面的相關細節，並且提出自己的意見作為回饋 (別誤會，這不是雙關語)。
在那些會議當中討論了許多議題，但最令我難忘的還是大家針對週期性力道 (periodic force) 該以時段表示還是頻率表示無法達成共識。其中在場的一家廠商說什麼也不肯罷休，因為他們公司已經寫好驅動程式，指定以頻率表示週期性力道，而他不想更改。拜託！開會目的就是要商討新介面的相關細節，怎麼可能因為哪一家廠商不想更改自己的驅動程式，而屈就他們拍板定案呢？
但是這家廠商實在鬧得太厲害了，最後大家只好棄械妥協，同意以頻率而非時段來指定週期性力道的速率。反正，不管選擇哪一個都差不多嘛。每秒振動 10 次的頻率力道，不就是十分之一秒的時段力道嗎？時段和頻率只不過是一體兩面罷了。
事實真是如此嗎？時段是以毫秒表示，動態範圍是 1 毫秒到 50 天左右。50 天的時段對人類來說好像沒什麼，而 1 毫秒的時段更是快到根本不被視為週期性現象 (與其說是週期，不如說是音調吧)。
另一方面，頻率是以赫茲表示，動態範圍是每秒 1 赫茲到 40 億個週期。這麼一來，以搖桿播放音樂會不會太牽強了點？萬一所產生的力道剛好落到微波爐頻率帶，那會出現什麼局面呢？
問題在於，以這種不切實際的表示法來表示力道，一旦達到頻率範圍的高點，就必須付出代價。很不巧，模擬飛行剛好就是時段較長的週期性力道。雖然我不懂這背後的物理學，不過我聽說這麼一來飛行員會發現，控制桿的週期性力道慢了數分鐘。一般說來，飛機會傾向以非常慢速的垂直正弦波飛行，而飛行員必須採取行動來抵制這個傾向，才能保持水平飛行。如果力道的速率是以時段表示，模擬飛行方案就能夠指定一個時段 120,000 毫秒。但如果以頻率表示，就是 0.0083 赫茲，這就遠慢於驅動程式介面所能表示的最慢頻率 (亦即 1 赫茲)。因此，模擬飛行所能要求的最慢力道，就是每秒重複一次的力道，而這對於模擬飛行所要模仿的實際效果來說仍然很快。
即使過了這麼多年，我還是擺脫不了它帶給我的不安，於是就在最近，我決定去查看有關力回饋的文件記錄。出乎我意料之外，DIPERIODIC 結構竟然是以時段而不是頻率來表示週期性力道 (為了使測量精確，它採用百萬分之一秒作為單位，換句話說，現在不管是播放音樂還是駕駛飛機都沒問題了)。到底是後來修正了這個錯誤？還是我老人痴呆，把以前的事都記反了？不管怎樣，我再也不必擔心我犯的這個錯誤了 (如果真的有發生的話)。

Raymond Chen的網站「The Old New Thing」以及同名著作 (Addison-Wesley，2007 年) 均探討 Windows 的歷史和 Win32 程式設計。這顏色跟你真速配。