 TechNet Magazine July 2007

TechNet Magazine July 2007

通訊: Exchange Server 2007 的資料保護和嚴重損壞修復

Exchange Server 2007 包含一系列支援高可用性及嚴重損壞修復的選項。探究 Exchange 提供的替代方案，並為組織規劃理想的修復解決方案。

Lee Benjamin 通訊: 使用 Windows Mobile 6 提高安全性

智慧型手機和 PDA 雖然提供從辦公室外面存取網路的功能，但它們也可能造成網路的新安全性風險。以下是 Windows Mobile 6 與 Exchange Server 如何可以幫助保護貴公司的行動裝置和基礎結構的指南。

Matt Fontaine 通訊: 公用資料夾的強大替代方案

MOSS 2007 針對共用資料提供比 Exchange 公用資料夾更強大的解決方案，提供增強的功能和更簡易的管理。看看您可以如何使用 SharePoint 來共用行事曆、連絡人和文件。

Alan Maddison 通訊: 使用智慧卡登入 Outlook Web Access

安全性鏈結中最脆弱的一環，就是容易被破解的密碼。學習如何透過雙重關卡智慧卡驗證的實作，為您的行動使用者改善電子郵件安全性。

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Windows 系統管理: Windows Vista 的 ActiveX Installer 服務

您要如何保護電腦不受惡意 ActiveX 控制項的侵害，而又不會限制應用程式的相容性？我們將帶您導覽 Windows Vista 中的 ActiveX Installer Service (AxIS)，以了解其如何使用新方法管理 ActiveX 控制項來解決此問題。

Rob Campbell and Joel Yoker 編輯的話: 第六階層

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

Greg Steen SQL 問題與解答: 深入探索叢集、意外當機、SA 帳戶等

Edited by Nancy Michell 公用程式焦點: SMSMap

Jeff Tondt IT 如何運作: RPC 錯誤的疑難排解

Zubair Alexander The Cable Guy: 經過 VPN 連線的 IPv6 流量

Joseph Davies Windows PowerShell: 重新探討管線

Don Jones 嗨，Scripting Guy！: 指令碼世界和現實生活一樣，外觀很重要

The Microsoft Scripting Guys Exchange 佇列問題與解答: 邊緣和集線器傳輸角色、虛擬機器等

KC Lemson and Nino Bilic 安全性監控: 管理 ACL 的工具

Jesper M. Johansson 桌面檔案: Microsoft Desktop Optimization Pack

Wes Miller Windows 機密文件: 安全模式的修復能力

Raymond Chen


 通訊: Exchange Server 2007 的資料保護和嚴重損壞修復
通訊 Lee Benjamin

Exchange Server 2007 的資料保護和嚴重損壞修復
摘要:
  • 基本備份及還原
  • 資料的持續性
  • 複寫技術
  • 替代解決方案

Microsoft Exchange Server 的設計兼顧備份功能。組織需要備份其郵件訊息資料，也必須能夠還原該資訊才行。為了滿足這些需求，Microsoft 建置了一系列的資料保護選項，從基本的
備份和還原，到作業的持續性，到真正的業務持續性解決方案，以提供最高階的可用性和嚴重損壞修復功能。本文將探討這些選項，並幫助您決定如何為組織實作最佳 Exchange 復原解決方案。

第一層：基本備份及還原
您可以選擇在資料庫離線時備份 Exchange 檔案，也可以在資料庫執行時進行備份。事實上，後者是一般建議的 Exchange 備份方式。但 Exchange 不止是一組檔案而已。它是一個含有大型資料庫檔案和交易記錄檔的資訊儲存庫。傳送至 Exchange 的訊息會立即記錄在交易日誌檔中，當系統有一些空檔時 (通常只是晚幾毫秒而已)，訊息就會複製到資料庫本身。Exchange 讓資訊能夠儘快儲存到磁碟上，因而可提供非常高度的復原能力。還原 Exchange 的基礎，正是這兩組資訊的可用性。萬一系統故障，需結合先前的備份以及自備份時間點以後的所有交易，才能使 Exchange 還原到最新資訊。請注意，必要時，Exchange 會在還原的資料庫中自動重新執行那些交易。
備份程式存取 Exchange 資料庫資訊的方式，是透過可延伸儲存引擎 (Extensible Storage Engine，ESE) 備份 API 或較新的 VSS 解決方案，我會在稍後討論這些解決方案。每當起始 ESE 備份時，Exchange 會暫停其資料庫的所有寫入作業。同時，ESE 會暫時將資料庫設定為唯讀模式，使它可以在完整備份中進行複製，它也會利用暫時資料庫來保存備份期間進行的新交易。當備份完成時，ESE 會使資料庫回到其正常讀寫模式，並套用累積在其暫時資料庫中的交易。備份也會在成功備份程序結束時清除舊的交易記錄檔。
此備份程序的方式很直接，即時是半夜登入的使用者也無法察覺到備份的進行，ESE 可能要花費很長的時間才能完成，尤其是因為 Exchange 資料庫大小有可能從少數 GB 到可管理的 30、50、甚至到 100GB -- 所以使用標準技術幾乎無法一夜之間完成備份。若要瞭解使用 NTBackup.exe 可用的選項，請參閱 [圖 1]。
圖 1 使用 NTBackup 公用程式
圖 1 使用 NTBackup 公用程式

Exchange 的最佳作法
如果您希望從一般硬體和系統故障中快速復原，應該每晚都執行完整的 Exchange 備份。每當 Exchange 伺服器使用本機磁碟時，若要改進效能和復原能力，請務必使用個別的 RAID 陣列來儲存 Exchange 資料庫和 Exchange 交易記錄檔。如此一來，萬一 RAID 陣列控制器故障，或陣列當中有不止一個磁碟故障而造成其餘磁碟無法重構等量資料時，您才依然可以進行復原。如果您失去交易記錄檔，其他磁碟機上仍然有最新的 Exchange 資料庫，讓您可以使用新的交易記錄檔繼續正常作業。如果您失去資料庫磁碟機，則復原策略是回復到前一夜的 Exchange 資料庫完整備份，然後套用當天的交易記錄檔來更新。
請務必限制 Exchange 資料庫的大小，使每一個資料庫可以在合理的時間內完成備份，以及更重要的 -- 才能在合理的時間內還原資料。大部分組織應該將資料庫大小維持在 30 到 50GB 之間。當資料庫超過此大小時，最好將它分割成數個資料庫，以便使還原工作容易一點。

備份及還原的持續性
資料庫和交易記錄檔的存放位置很重要，不只是為了備份效能，同時也是為了復原速度。現在，所有伺服器均支援各種層級的磁碟機備援，稱為 RAID。基本上，RAID 容許磁碟機故障而不會使系統當機，不過系統效能會變慢，直到磁碟更換及重建為止。屆時，陣列控制器必須從剩餘磁碟中快速地重新建構資料，以回應每一個磁碟存取要求。如需信箱伺服器儲存架構的詳細資訊，請參閱 Microsoft IT Showcase 文件使 Exchange Server 2007 邁向 64 位元。
Exchange 的核心功能就是它的單一執行個體資料庫設計。這表示在 Exchange 資料庫內，只會儲存特定訊息的單一複本及單一附件 (如果有的話)。如果訊息傳送至相同資訊儲存庫的多位收件者，只會建立物件的其他指標 (訊息、附件)，但不會複製物件。這不只是傳遞效率的大利多，也可以為 Exchange 節省磁碟和磁帶的空間。
雖然 Exchange 在回復整個資料庫方面很厲害，但是若要還原個別信箱、資料夾或訊息，就需要先回復整個磁帶。使用者當然想要有更細微的還原功能，但是，在磁帶上的單一執行個體卻很難做到。因此，備份供應商便以積木層備份 (Brick-Level Backup) 來回應此需求 (我並不建議這麼做)。在使用核准的 ESE 備份 API 完成 Exchange 資料庫的完整備份之後，備份產品會將每一個信箱加入備份磁帶中。由於備份 API 並未提供從個別信箱提取資料的管道，所以這會使用 MAPI。結果是，備份磁帶會變得很冗長，因為您需要不斷複製所有的訊息和附件。
Microsoft 有提供一些增強功能，可局部解決此問題。例如，當使用者刪除項目之後，系統管理的垃圾桶 (或廢紙箱) 會保留項目一段時間，以防萬一又需要用到它們。此外，不再需要保留一個閒置伺服器作為 Exchange 復原樹系 (Recovery Forest)；復原儲存群組 (Recovery Storage Groups) 可以讓系統管理員局部裝載從磁帶還原的資料庫，以便在信箱層級進行資料的複製或合併。

熟能生巧
許多組織得到這樣的教訓：不論他們決定何種備份及修復層級，備份媒體和修復程序都必須定期測試才行。有太多系統管理員只有在嚴重損壞之後，才瞭解到他們的備份技術和還原程序是否真的有用。測試的最佳時機是在建置及設定全新伺服器之後的隔天，因為那時候它已成為 Exchange 組織作業的一部分，但只有少數使用者在使用。這個時候，您應該執行 Exchange 完整備份、磁帶機定期備份及擷取系統狀態，包括系統磁碟上的重要資料和 IIS Metabase (亦即儲存 Exchange 路由設定的位置)。然後冷靜地重新製作新伺服器的格式並重來一遍，然後在過程中更新您一開始建置伺服器時所做的筆記。您應該可以從系統狀態還原設定，但也有足夠的文件可手動重新實作系統設定。
您花在此「消防演習」的時間，將可大幅減少未來的復原時間。請定期重複此程序。當您在從事這項活動時，請計算從存放磁帶的遠端地點帶回磁帶花費了多少時間。對於那些歷經過漫長等待之煎熬的人，通常會開始嚴肅地思考磁碟到磁碟備份對於其備份及還原策略的重要性，即使繼續維持遠端地點磁帶儲存備份機制以提供嚴重損壞修復的支援。

磁帶備份的困擾
從磁帶還原需要花費太多時間。Exchange 對組織如此重要，使用者和管理階層都預期服務不會中斷。當嚴重問題發生時，大部分的組織都會慌張。因為沒有人可以接受需要花費八個小時才能從磁帶還原 75GB 的資料庫，而且那甚至還不包括從儲存磁帶的遠端地點取得和重新安裝作業系統所要花費的時間。
不僅如此，從磁帶擷取正確資料庫也是一項挑戰。從 Exchange 發行至今已經 10 年了，磁碟儲存和廣域網路的成本已大幅下降。因此，許多組織可以負擔得起更快的備份及還原方法。這些組織可以利用科技，來提升其 Exchange 基礎結構的作業持續性以及嚴重損壞的修復功能。

第二層：作業持續性
作業持續性是一組程序和技術，主要是要使復原作業儘快完成，使意外停機的時間縮至最短。作業持續性在磁帶式本機復原方面，改良了復原時間目的 (Recovery Time Objective，RTO) 以及復原點目的 (Recovery Point Objective，RPO)。可能的話，它會盡力縮減磁帶回站的時間。請看一下 [圖 2]，將作業持續性與備份及還原和 DR 做個比較。
圖 2 復原持續性
圖 2 復原持續性
本圖表說明復原和可用性的範圍，從左下方的慢速但較便宜範圍，到右上方的快速但更昂貴的範圍，在作業持續性與嚴重損壞修復解決方案之間則故意有一個模糊地帶。
此圖讓您了解這些方法的成本、復原時間和可用性之間的取捨和平衡。在本文中，我故意明顯的區分本機持續程序和嚴重損壞修復。DR 一律視為遠端，以從遠端地點取得資料為主要目的。距離會帶來更多的挑戰，通常費用也更為昂貴，但 DR 正是與發生災難事件之後的業務持續性息息相關。稍後我會更詳細討論這一點。

一些歷史背景
當 Exchange 變成基礎結構的較重要部分，以及儲存在其資料庫中的資訊越來越多時，顯然備份及還原時間需要縮減才行。在與 Microsoft 合作時，有些大型組織所提出的方法，是復原部分作業的好處。亦即，如果組織可接收及傳送新的電子郵件給外界，那麼看起來似乎什麼事也沒發生。畢竟，形象很重要。
為了實作 Exchange 的這種類似「以撥號連接備援」的還原方式，這些企業會設置新的空白資料庫來取代損壞的資料庫。然後，Exchange 和 Active Directory® 會建立具有適當權限的新信箱，讓使用者能夠傳送及接收郵件。擷取備份磁帶及復原資料之後，可以由系統管理員裝載。然後 Exchange 系統管理員會將還原的信箱合併到撥號信箱。信箱可依需要排列優先順序。雖然有所改進，但這是一個耗時而複雜的程序，它原本使用 EXMERGE，後來改為復原儲存群組。不過值得注意的是，在撥號復原之後要再進行完整資料還原時，會是一項艱巨而複雜的工作 (尤其是 Exchange 2007 最多可以有 50 個儲存群組)。如果您考慮要實作撥號復原，請確保所耗費的大量資源是值得的。

磁碟區陰影複製服務
為了利用較便宜的磁碟及消除實際執行之 Exchange 伺服器的處理器負荷，Microsoft® Windows Server® 2003 和 Exchange 開發了新的備份 API。所建立的磁碟區陰影複製服務 (Volume Shadow Copy Service，VSS) 是為了產生一致的時間點資料複本。這些快照集是 Exchange 資料的快速唯讀複本，其中只會持續包括已變更的資料。複本通常會指向另一個有磁碟空間可用的伺服器或是存放區域網路 (Storage Area Network，SAN)。其中可以保留多個快照集，並備份到磁帶上。因此，實際執行的 Exchange 伺服器不再受到備份軟體和磁帶複製負荷的效能影響。
使用 VSS for Exchange 資料保護有一些好處。第一，可從 Exchange 除去磁帶備份作業的效能負荷。雖然還是會備份到磁帶，但它可以使用 Exchange 資料的複本，而不影響使用者效能。第二，可更頻繁地擷取快照集，一個晚上不止一次。而且您可以在第二個伺服器或其他本機儲存裝置上，保留多個快照集。
市場上有許多協力廠商產品利用 VSS 快照集功能。有些只是減少備份及還原 Exchange 資料庫的時間，有些則增加功能，例如比原始 Exchange 更細微的復原功能，使您可以向下還原到信箱層級。雖然沒有人喜歡這種積木式備份，但是大家都希望能夠還原特定資料夾，甚至還原特定郵件訊息。

複寫技術
軟體調解式 Exchange 容錯移轉，是某些複寫供應商提供的一個選項。它會使待命的 Exchange 伺服器上線，然後告訴 Active Directory 所有使用者信箱都已移動。有兩種方式可達成此目的，兩者都需要對 Exchange 和 Windows 環境做一些自訂作業。一種方式是要對 DNS 施展一點技巧，使待命伺服器接管失敗伺服器的名稱和 IP 位址。此方式的優點是可以減少用戶端工作站的影響，因為 Outlook® 會認為它仍然使用相同的伺服器。
第二種方式是使用保有資料庫複本且執行 Exchange 的待命伺服器，但不裝載任何東西。當發生失敗時，待命伺服器會通知 Active Directory 所有使用者信箱都已移動。然後會執行指令碼或發佈群組原則，以告訴用戶端他們要使用不同的郵件伺服器。Outlook 2007 可以感知 Active Directory，這使得此程序更簡單，因為它會自動完成對應配置。

使用 MSCS 的本機叢集
可用性較高的是 Microsoft Cluster Services (MSCS)；Exchange 為叢集感知式應用程式。叢集會在兩部或以上的電腦之間共用資訊，因此萬一其中一部故障，其他電腦可以接管。現在，大部分 Exchange 叢集為兩個或四個節點，不過最多可使用八個節點。有一個節點一定會指定為被動，其中會執行 Windows Server 且已安裝 Exchange Server，但沒有作用中的信箱。在 Exchange 2003 中，可以有雙節點主動/主動叢集，但由於效能負荷的緣故，現在並不鼓勵使用這樣的叢集，所以在 Exchange 2007 中也不支援。
就像 Exchange 2003 叢集配置一樣，包含被動節點的 Exchange 2007 叢集仍然可以使用單一共用儲存陣列。雖然叢集的儲存陣列一般會有多重備援功能來因應各種類型的失敗，但它們仍然只提供一份資料複本，這是此配置的弱點。這就是為什麼這些叢集稱為單一複本叢集 (SCC)，以便與 Exchange 2007 的多重複本叢集 (MCC) 提供的下一個資料保護境界做區分。當我們探討嚴重損壞修復時，會進一步討論 MCC。

本機持續複寫
本機持續複寫 (Local Continuous Replication，LCR) 是 Exchange 2007 的新功能，這項改良可以在相同伺服器內保留 Exchange 資料庫和交易記錄檔的第二個複本。這使得將 Exchange 資料庫放在一個 RAID 陣列上，然後將交易記錄檔放在另一個陣列上的最佳作法，又多了一層備援作用：LCR 可讓您在儲存資料庫主要複本的陣列上儲存記錄檔的第二個複本，然後在儲存記錄檔的主要複本的陣列上儲存資料庫的第二個複本 (請參閱 [圖 3])。如果 RAID 控制器或陣列失效，在另一個陣列上仍然擁有資料庫和交易記錄檔。如此一來，您可以繼續作業 (儘管會有所不安，而且效能會稍微減低) 直到您能夠重建失效陣列為止。
圖 3 設定 LCR
圖 3 設定 LCR
LCR 是本機作業持續性解決方案，而不是備份解決方案，因此，您仍然需要完整備份策略。LCR 還帶來一項效能衝擊，因為伺服器現在會產生資料庫和交易記錄檔的兩個複本。此外，在 Exchange 2007 實作中，LCR 有一些限制，所以只適合小型組織，這是因為 LCR 只支援一個儲存群組一個資料庫，一個組織一個公用資料夾資料庫。
使用 LCR 復原的容錯移轉並非瞬間完成，而是需要 IT 專家執行指令碼，才能使 Exchange 回復運作。此程序需要執行 Exchange 管理命令介面指令，這些指令是在 Exchange 管理主控台之外執行的。
Exchange Server 2003 Enterprise Edition 讓組織可以執行最多 20 個 Exchange 資料庫 (四個儲存群組，每一個最多有五個資料庫)，Exchange 2007 Enterprise Edition 則容許多達 50 個儲存群組，每一個有它自己的資料庫。交易記錄檔也從 Exchange 2003 的 5MB 檔案減少為 Exchange 2007 的 1MB 檔案。這兩項變更的設計均支援 LCR，而且還有叢集持續性複寫 (CCR) 功能，此功能會在稍後介紹。
中小型組織可以使用 LCR，為其 Exchange 作業提供更好的資料保護。LCR 容易實作，但仍需要手動介入。LCR 為相同伺服器/本機磁碟解決方案，它只是改進作業持續性的第一步。雖然它可以因應 RAID 陣列和 RAID 控制器的失敗，但多個磁碟同時損毀或 RAID 控制器失敗的情況畢竟很罕見。大部分時間，失敗的狀況會涉及整個伺服器的停擺，於是我們進入 Exchange 保護機制的下一步。

協力廠商本機「無主機」複寫
為加強 Exchange 的復原功能，協力廠商開發出利用「無主機」複寫的產品，使用 Exchange 記錄檔在另一部機器上保留一份 Exchange 資料庫的待命複本。在這種情況下，資料保護或保存解決方案會對另一部電腦執行 Exchange 的 ESE 完整備份，然後等到 Exchange 一關閉交易記錄檔，就立刻提取它們。那些交易會插入其 Exchange 資料庫複本中，以永遠保持最新狀態。就像我所說過的，這些記錄檔很小 (Exchange 2003 為 5MB，Exchange 2007 為 1MB)，因此完成完整備份之後，要將這些記錄檔複製到「無主機」伺服器中，幾乎不會造成 Exchange 伺服器的任何負荷。

第三層：嚴重損壞修復及高可用性
嚴重損壞修復是指萬一主要資料中心無法使用時，回復運作及執行的功能。Exchange 需要有效的嚴重損壞修復機制，因為電子郵件和行事曆功能，已是當下組織最重要的運作方式。
有些公司認為他們儲存在遠端的傳統磁帶備份，是一種嚴重損壞修復形式，但如果唯一的資料中心因火災或水災而遭到破壞，那麼就算有一卡車的磁帶也於事無補。嚴重損壞修復不止是要將資料移到另一個位置，還需要相對的復原技術和程序，使應用程式得以盡快回復運作和執行。為了發揮具體的效果，嚴重損壞修復有賴於以一段距離隔開主要和次要系統。兩地之間相隔多遠，視您要克服的嚴重損壞規模而定。如果您擔心火災，或許園區另一棟建築就夠遠了。不過，如果是火車或飛機基礎結構嚴重損壞，則可能影響半徑一公里以外的範圍。許多嚴重損壞是區域性的：水災、暴風雪、地震，甚至電力中斷。通訊管道也有可能發生問題，從挖掘工程切斷與 ISP 的連結，到拒絕服務的攻擊，甚至是一般以商業為目標的 Internet DoS 攻擊，無所不包。
實際上，如果組織已經在不止一地設置 IT 人員，其中一個地點就可能符合遠端作業持續性的條件，可以成為您要防禦之嚴重損壞的備援機制。使用您自己的設備和人員，其成本遠低於與嚴重損壞修復提供者簽訂合約或租用新場地的空間。
最後，嚴重損壞修復也與觀感有關：讓客戶對您的營運不中斷產生更大的信心。大家都知道，當城市或地區遭遇天然災害時，如果公司在幾天到一星期內沒有回復運作，客戶和供應商可能會作最壞的打算；許多公司可能因此而倒閉。對客戶而言，您的作業必須看起來正在復原當中，以保證業務能夠連續不中斷。關於及時的復原，客戶會有不同的想法：他們對於金融服務公司運轉中斷比對於辦公室傢俱供應商運轉中斷更沒有耐心，這點是可以理解的。

嚴重損壞修復需求
在嚴重損壞之後要使 Exchange 能夠復原，需要將其資料複製到第二個地點，及使用已備妥的複寫技術來提供資料給一個執行中、隨時可接手的 Exchange 伺服器，然後通知 Outlook 用戶端其信箱已經移動。
Exchange 應用程式的複寫是一項繁重的負擔，尤其是若要透過遠距離。作為一個真正的交易式資料庫，每一次寫入的順序都非常重要。Exchange 用於在伺服器之間傳達所有交易和系統資訊的傳輸通訊協定是 SMTP，眾所周知，它是一個非常耗費頻寬的通訊協定，這真是雪上加霜。不僅如此，使用 Exchange 叢集時，系統之間必須每 500 毫秒維持一次活動訊號。如果第二個節點未接收到該活動訊息，它就會觸發容錯移轉作業。
要應付這些挑戰是如此複雜，這就是為什麼 Microsoft 到現在才以 Exchange 2007 切入這個領域。在 Microsoft 加入此領域之前，許多協力廠商開發的解決方案，會使用主機型或陣列型複寫來複製 Exchange 資料。
廠商們知道他們可以在不同位置分散節點來擴充叢集；這稱為延伸叢集。現在，實作延伸叢集最常見的方式，是透過通用協力廠商資料複寫產品或特別搭配來延伸 Exchange 節點的產品。您可以使用 MSCS 來達成此目的，但透過 WAN 的子網路需求是一個難題。叢集作業和供應可靠的高頻寬連線給遠端資料中心的複雜性，使得嚴重損壞修復系統的建置、維護和定期測試，需要涉及更高的成本和人力需求，這點是可以理解的。

叢集持續複寫
Microsoft 是以 Exchange 2007 的叢集持續複寫功能來延伸叢集支援。CCR 延伸了 LCR 維護兩份 Exchange 資料庫和交易記錄檔複本的功能，以在兩個叢集節點上實現相同的想法。嚴重損壞修復意味著主要和次要系統在地理上分隔兩地，而 Microsoft 多重複本叢集 (MCC) 要等到 Windows Server 2008 (以前的代號是 "Longhorn") 才能跨越長距離，實現延伸叢集的可能性。
讓 MCC 節點有不同資料複本的技術，叫作多數節點組合 (Majority Node Set，MNS)，這是指兩個以上的節點為決定由哪一方保存資料即時複本的投票程序。當發生失敗時，剩餘節點便握有新投票權，以決定由誰接管，成為新的主要處理/資料伺服器。支援此民主性的技術是 CCR，它會確保每一個節點都有最新的資料庫。使用 CCR 的 Exchange 2007 叢集僅限於兩個節點。
在大規模的環境中，Exchange 伺服器通常會在伺服器本身設定本機系統磁碟，然後利用 SCSI、光纖或 iSCSI 磁碟陣列，透過 SAN 連接到 Exchange 資料庫。使用 MCC/MNS 叢集時，有一個有趣的問題，即高階 Exchange 儲存裝置是否會倒退發展，成對每一個節點都使用本機 RAID 陣列。如果 MNS 叢集的目的是要讓每一個節點有個別儲存裝置，則將每一個節點指向提供共同儲存裝置的 SAN 是否仍然合理？
比較中庸的 MCC/MNS 叢集案例，是讓主要節點的儲存裝置設定在 SAN，而讓第二個叢集節點使用本機磁碟或低成本 iSCSI SAN。第二個節點可能與主要資料中心距離遙遠，位在一個沒有 SAN 基礎結構的地點。
不論這股潮流將走向何方，使用 MNS 和 CCR 的 MCC 都使備援能力和可用性更上一層樓，因為有多部電腦可容錯移轉，且資料會複製到不同的儲存元件上。不過，在 Windows Server 2008 問世之前，這仍然只侷限在單一資料中心內。Windows Server 2008 原生將支援延伸叢集，讓 MNS 叢集節點的地理位置能夠相隔無限遙遠，只要節點之間的網路延遲可靠地保持在小於 500 毫秒即可。在這之前 (及以後)，協力廠商的叢集技術將持續以 Microsoft MNS 和 CCR 為基礎，提供延伸叢集所需的地理分隔，而成為有效的嚴重損壞修復解決方案。
叢集作業屬於嚴重損壞修復的高階技術，CCR 則適當定位為 Exchange 的高可用性功能。雖然此組合涉及成本和人員的負荷，但對於想要操作同質性 Microsoft 環境的客戶而言，的確是一個絕佳的解決方案。

協力廠商遠端作業持續性
當 Microsoft 解決方案和協力廠商延伸模組的復原產品問世之後，絕對會成為最高階的產品。在數秒鐘內自動容錯移轉 -- 這已經是最高的境界。然而並非每一家公司都需要此層級的可用性和業務持續性，也不是每一家公司都能負擔得起 (需要投資數十萬美金)。對於許多公司而言，可以在幾分鐘內可靠地完全還原 Exchange 的解決方案，就足以提供他們所需的作業持續性。
例如，Mimosa Systems, Inc. 可以將單一資料中心內的作業持續性，延伸成為遠端持續性。在遠端位置，Mimosa DR 會保留一份 Exchange 資料，並以主要 Exchange 伺服器的交易記錄檔保持最新狀態，又隨時準備好提供此即時複本給待命的 Exchange 伺服器。遠端 Exchange 伺服器僅使用標準伺服器硬體，就像單一資料中心實作一樣，您可以讓它隨時待命、做好接手的準備，以因應嚴重損壞事件。萬一遭逢嚴重損壞，遠端地點的操作員會起始並執行容錯移轉，包括裝載待命中的資料庫檔案、重新對應信箱，以及 Outlook 設定檔。不過請注意，這些協力廠商解決方案必須支援知識庫文章 Microsoft 對於會修改或擷取 Exchange 資料庫內容之協力廠商產品的支援原則所定義的範圍。

總結
Exchange 的資料保護機制涉及技術和程序的組合範圍，這些可根據成本和功能分成三個階層。當您開始思考對 Exchange 資料保護的需求時，您應該考慮共同關係人能夠容忍多少停機時間。效能越高、速度越快的復原解決方案，其成本也會越高，所需的高階選購配備，至少得花費數十萬美元。有比較負擔得起的解決方案，雖然有效，但無法達到最高的可用性。您的選擇應該反映組織的真正需求。
Exchange 2007 的 Service Pack 1
目前在 Beta 測試階段的 Exchange 2007 Service Pack 1 (SP1) 預定將包含系統管理員作夢寐以求的一些功能，包括 OWA 的增強功能、主控台的其他 GUI 功能等。
規劃復原解決方案的系統管理員特別感興趣的，應該是 Exchange 2007 SP1 還會包括第三個可用性解決方案，來與 LCR 和 CCR 互補：次要持續性複寫 (SCR)。這是一種折衷方案，Microsoft 希望這可以提供更大的復原能力，但無須涉及「高可用性」的複雜度。
SCR 將容許 Exchange 資料庫和交易記錄檔，複寫到不同於您信箱一般所在的 Exchange 伺服器上。SCR 目標可為本機或遠端，也可以是待命的 Exchange 伺服器或叢集。不過，SCR 並不需要叢集在任一位置，且它與 CCR 不同之處在於其目標是待命環境，且容錯移轉為手動程序。請注意，您仍然需要透過連線取得首次 (極大) 的複本，本質上為完整備份。您可能偶爾就需要執行如此的大規模複寫作業，因此必須知道它對網路會有什麼影響，就像 CCR 和協力廠商的解決方案一樣。我預期市場上將會大量採用 SCR 和 CCR，以及提供類似和更多功能的附加產品。

Lee Benjamin 經營的公司名為 ExchangeGuy Consulting Services，他的工作包括直接面對客戶並為 Microsoft Partners 提供建議。Lee 是全球最大 Exchange 使用者群組 ExchangeServerBoston 的主席，也是 BostonUserGroups 的董事。Lee 也是 Exchange 的 MVP、Microsoft 合格培訓講師，而且經常在擔任產業會議中的講者。
© 2007 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.


 通訊: 使用 Windows Mobile 6 提高安全性
通訊 Matt Fontaine

使用 Windows Mobile 6 提高安全性
摘要:
  • 裝置安全性
  • Exchange Server 安全性
  • 網路安全性

行動裝置提高全球工作者的生產力，即使他們
不在辦公室，也可以存取公司資訊並保持連線。生產力提高可不是蓋的：因為只要隨時隨地開啟行動裝置就可以開始工作。
但在另一方面，IT 專家們卻要面對維持虛擬辦公室之安全性及穩定性的挑戰。從他們的觀點來看，每一個行動裝置都是一個潛在的網路安全性漏洞，以及資料可能因而遭竊的不利條件。為行動裝置建置一個更安全的部署環境雖然重要，但也必須顧及使用者的體驗，在兩者之間取得平衡。
Microsoft® Windows Mobile® 6 與含有 Messaging and Security Feature Pack (MSFP) 的舊版 Windows Mobile 5.0 均包含許多功能，可幫助您以最容易且對使用者最便利的方式來保護公司基礎結構。使用 Microsoft Exchange Server 做為傳訊平台，即可進一步增加可用的安全性選項。在本文中，我會示範如何使用 Windows Mobile、Exchange Server 以及一些網路安全性最佳作法，做為保護貴公司之行動裝置的基礎。

行動通訊架構
在規劃或升級行動裝置部署環境時，要考量三層因素：裝置、訊息伺服器和網路 (請參閱 [圖 1])。在裝置層級，主要的挑戰包括如何只允許已授權者存取裝置，以及如何防止裝置上出現未經授權的應用程式。Windows Mobile 會透過 PIN 驗證及密碼保護功能、裝置逾時鎖定，以及以本機模式或遠端模式清除或消除裝置記憶體的能力，來防止未經授權者存取裝置 (例如萬一裝置遺失或遭竊)。支援通訊通道和卸除式儲存裝置的資料加密。防止未經授權的應用程式 (例如病毒或間諜軟體) 安裝或存取裝置的重要組件，也是很重要的防護功能。另外還有管理角色定義、應用程式存取層、程式碼簽署設定、安全性設定以及安全性憑證等，共同實現裝置層級的保護。
圖 1 各行動通訊層
圖 1 各行動通訊層
下一個安全層是訊息伺服器，例如含 Service Pack 2 (SP2) 的 Exchange Server 2003 或 Exchange Server 2007。本層同時包括訊息安全性 (訊息在裝置間能夠安全來回傳輸所憑藉的技術)，以及訊息伺服器與行動裝置之間透過 Exchange ActiveSync® 的互動。使用 Windows Mobile 裝置並不需要 Exchange Server，但是使用 Exchange 可提供成本、擴充性、效能和管理上的優勢。
理想的裝置層級和訊息伺服器安全性作法是關鍵，但保護網路層也很重要。藉著依據最佳作法並實作強大的安全性通訊協定來設定公司網路，即使有一個或多個行動裝置遭遇安全性問題時，也可以防止網路受損。

裝置安全性原則
對抗安全性破壞的第一道防線，是 Windows Mobile 的裝置本身。Windows Mobile 作業系統提供大量的裝置層級安全防護服務，其中包括：支援驗證、儲存卡加密、虛擬私人網路 (VPN)、Wi-Fi 加密，以及安全通訊端層 (Secure Sockets Layer，SSL) 服務。裝置層級安全性涉及管理誰可以存取裝置及其資料、控制可在裝置上執行的應用程式，以及建立資料在裝置上來回傳輸的方式。一般而言，系統管理員在含有 MSFP 的 Windows Mobile 5.0 及 Windows Mobile 6 上，可以彈性地設定及強制執行各種安全性原則。
使用者存取是透過 PIN 或密碼驗證加以管理。裝置可以設定為在一段閒置時間後或在關閉後自動鎖定，使用者需要將裝置重新解除鎖定才能使用 (請參閱 [圖 2])。使用者存取控制的細節是由安全性原則設定，這可根據系統管理員的安全性角色來加以變更。
圖 2 設定密碼原則
圖 2 設定密碼原則
安全性原則會定義行動裝置的全域安全性層級 (請參閲 [圖 3])。誰可以設定及變更這些安全性原則，將由安全性角色來決定。通常保留給行動操作員的「主管 (Manager)」角色，會有安全性原則設定的完整控制權。Exchange 會使用「Enterprise 角色」來管理 Exchange 系統管理員所設定的某些裝置原則。您也許可以自訂貴公司的安全性原則，這要視您與裝置提供者的合約而定。
Figure 3 行動裝置的安全性原則 (Close Figure 3)

原則 行動裝置
阻止未經授權者存取裝置

含有 MSFP 的 Windows Mobile 5.0

指定使用者一定要在裝置上進行驗證，以解除鎖定裝置，或允許使用者在桌上型電腦上輸入 PIN。
預設角色：Manager、Enterprise。

Windows Mobile 6

允許或拒絕使用者變更卸除式儲存媒體之行動加密設定的權限。
預設角色：Manager、Enterprise。
指定當裝置連線時，如果裝置鎖定正在作用中，使用者是否必須在裝置上進行驗證。預設角色：Manager、Enterprise。
可以在萬一裝置遭竊或遺失時保護機密資料

含有 MSFP 的 Windows Mobile 5.0

指定使用者一定要在裝置上進行驗證，以解除鎖定裝置，或允許使用者在桌上型電腦上輸入 PIN。
預設角色：Manager、Enterprise。

含有 MSFP 的 Windows Mobile 5.0 和 Windows Mobile 6

指定是否必須在裝置上設定密碼。設定本機和遠端裝置清除設定。
預設角色：Manager、Enterprise。
Windows Mobile 所使用的可自訂驗證方法是由本機驗證外掛程式 (Local Authentication Plug-In，LAP) 控制，這些外掛程式會與本機驗證子系統 (Local Authentication Subsystem，LASS) 互動。此技術可讓 Exchange Server 在細微層級上控制裝置設定 (例如，強制設定密碼長度和強度需求，或啟用簡易 PIN 驗證)。
Windows Mobile 6 有一組擴充的 LAP 函數，是使用 Exchange Server 2007 所設定。您可以啟用 PIN 模式辨識 (例如，拒絕使用簡單模式如 "1111" 或 "1234")，設定密碼或 PIN 到期日，允許使用者根據特定條件要求 PIN 重設，或保存 PIN/密碼歷程記錄，以防止要求使用者建立新密碼時，使用者重複使用舊的 PIN 或密碼。

保護裝置上的資料
萬一輸入不正確 PIN 或密碼的次數超過系統管理員所設定的限制，本機裝置清除功能就會硬重設 (Hard Reset) 裝置，如此將消除其記憶體 (包括使用者驗證認證在內)。此限制是設定為 Exchange Server 安全性原則的一部分。每兩次不正確輸入之後，裝置便會提示使用者輸入一個結構式索引鍵字串，才能繼續進行 (請參閱 [圖 4])。這可防止裝置因為不小心的隨機按鍵而遭意外清除。使用 Windows Mobile 6 和 Exchange Server 2007 時，也可以從遠端清除儲存卡。
圖 4 強制設定 PIN 和密碼用法
圖 4 強制設定 PIN 和密碼用法
如果有人將充滿公司機密資料的 2GB 儲存卡遺忘在計程車上，則鎖定裝置的做法不太好。還好，您也可以使用 Windows Mobile 6 來處理此問題。它可以將儲存卡資料加密，因此，只有寫至儲存卡的裝置可以讀取它。和 Windows Mobile 6 的其他許多加強安全性功能一樣，Exchange Server 2007 也可以透過網路提供此安全性功能。對於使用者而言，儲存卡的加密過程為透明化。Exchange Server 2007 可讓系統管理員選擇使用者是否可以變更其儲存卡的加密設定。
應用程式是否可以在 Windows Mobile 裝置上執行，會根據三種權限層級而定：特權 (Privileged)、正常 (Normal) 和封鎖 (Blocked)。特權層級的應用程式 (由特權憑證存放區中的憑證簽署) 可以寫入登錄和系統檔案，也可以安裝憑證。和桌上型 PC 或伺服器一樣，可以改變作業系統環境的應用程式越多，該環境遭到破壞的機會就越大。減少具有特權存取權的應用程式數目通常是較好的做法。大部分應用程式只需要在正常層級執行 (由 Unpriv 憑證存放區中之憑證所簽署的應用程式，或使用者同意執行之未簽署的應用程式)，它們可以執行但不能存取系統檔案。封鎖層級應用程式是指 -- 因為不正確簽署或使用者動作而遭到封鎖，無法執行。
裝置可以有一層或兩層安全性存取設定。使用一層存取設定時，未簽署的應用程式是以特權存取權來執行，或遭到封鎖而無法執行。如果原則檢查成功，或使用者允許應用程式執行，則兩層存取設定會在正常層級執行未簽署的應用程式。視裝置設定而定，可提示使用者是否執行未簽署的應用程式。
數位憑證 (個人、裝置和應用程式驗證最常使用的其中一種形式) 是裝置、伺服器和網路層級上 Windows Mobile 安全性的重要部分。Windows Mobile 作業系統會在裝置上的不同憑證存放區中儲存數種類型的憑證。在應用程式方面，憑證將決定哪些應用程式可以安裝和執行。若要使應用程式能夠在 Windows Mobile 的裝置上執行而不提示使用者，就必須以憑證簽署該應用程式，證明 Microsoft Mobile2Mobile 程式接受它。應用程式的權限層級，會根據相關聯的憑證來授與。
在網路驗證方面，每一個行動裝置都隨附由憑證授權單位 (CA) 所發出之一些受信任的商業根憑證，如 [圖 5] 所示。訊息伺服器 (例如 Exchange Server) 會在建立與裝置的 SSL 連線之前，先驗證該裝置的根憑證。如果貴公司使用自訂憑證，您可以在所購買且 Windows Mobile 的裝置上安裝它們，否則您可能必須建立新憑證。我會在本文的＜網路安全性＞一節中進一步加以討論。
圖 5 管理數位憑證
圖 5 管理數位憑證
ActiveSync 和 Internet Explorer® Mobile 可以使用 SSL 來幫助保護裝置與公司 Web 伺服器之間的資料傳輸。不論連線是否存在，要同步處理 Microsoft Exchange 資料、設定裝置或下載應用程式時，都會受到保護。SSL 會以 128 位元 RC4 或 3DES 密碼來加密通訊管道，使組織外的對象無法讀取資料。在透過網際網路存取伺服器時，Windows Mobile 也支援 VPN，它會使用封包加密來提供類似專用線路的安全性。

Exchange Server 安全性
雖然 Windows Mobile 的裝置不需要 Exchange Server 即可運作，但這兩個系統已設計為可密切合作，並且可提供健全的端對端行動傳訊及生產力解決方案。從含有 MSFP 的 Windows Mobile 5.0 版開始，ActiveSync 就已加強為可透過遠端模式管理 Windows Mobile 裝置的設定。其中提供簡單而強大的功能，可以在大部分 Windows Mobile 裝置上傳播並強制執行全域安全性設定。
ActiveSync 會在 IIS 上執行，IIS 是 Microsoft Windows Server 2003 的應用程式/Web 伺服器元件。IIS 提供內建安全性，可幫助保護 ActiveSync 本身避免遭到來自網路的攻擊。由於 Microsoft Office Outlook® Web Access (OWA) 也是以 IIS 為基礎，因此，您可以同時對 ActiveSync 和 OWA 使用相同的安全性憑證。
若使用 ActiveSync 來傳播 Enterprise 原則，下次當裝置與 Exchange Server 進行同步處理時，該原則就會傳遞到裝置上。使用者必須接受這些變更，否則不得連線到伺服器。大部分的網路都需要與各式各樣的裝置互動，包括無法接受複雜安全性原則的舊硬體。必要的話，您可以從安全性原則需求中豁免特定裝置 (例如舊硬體)，使它們可以繼續連線。
Exchange Server 2003 SP2 和 Exchange Server 2007 具有稍微不同的安全性原則控制功能。Exchange Server 2003 SP2 可用來指定最小密碼長度 4 到 18 個字元，密碼需要同時有數字和字母，並設定裝置鎖定之前允許的閒置時間長度。這一版的 Exchange Server 也可以指定安全性設定傳遞到裝置的頻率，以及允許前述之舊裝置的豁免。
在 Exchange Server 2007 版本中，ActiveSync 行動裝置管理功能已加強為包含所有 Exchange Server 2003 SP2 的功能以及下列各項：
  • 允許或禁止簡單密碼 (例如 "1234" 或 "1111")
  • 啟用或停用附件下載
  • 需要儲存卡加密
  • 設定附件大小的上限
  • 使用者可透過 OWA 來復原裝置密碼
  • 啟用通用命名慣例 (Universal Naming Convention，UNC) 和 Microsoft Windows SharePoint® Services (WSS) 檔案的存取權
利用 Exchange Server 2007，IT 專家們可彈性地為每一位使用者或裝置量身訂做原則、管理使用者群組的原則，以及從安全性原則中豁免特定使用者。

遠端清除
除了先前詳述的本機裝置清除功能之外，您還可以使用 Exchange Server 2003 SP2、Exchange Server 2007 或 OWA，從遠端清除 Windows Mobile 的裝置。遠端清除會在同步處理時進行，即使您未使用 ActiveSync 安全性原則，也可以執行遠端清除。遠端清除硬重設 (Hard Reset) 作業將無法從裝置上停止。資料、設定和安全性金鑰會以重複的零覆寫，因此並非核心作業系統的資料，將會很難修復。

網路安全性
對行動安全性而言，網路安全性就和裝置及訊息伺服器元件一樣重要。它也是行動基礎結構的一部分，而且明顯受您的控制。即使有一個或多個行動裝置發生安全性的問題，根據最佳作法設定貴公司的網路並實作正確的安全性通訊協定，就有助於防止網路受損。
Windows Mobile 適用於各種網路類型。使用標準網際網路安全性通訊協定及防火牆，您可以設計符合您的效能、穩定性和安全性需求的解決方案。
當訊息伺服器保留在公司網路內時，它們可受到邊緣防火牆保護，此防火牆扮演網際網路與公司伺服器之間的緩衝區。Microsoft Internet Security and Acceleration (ISA) Server 2004 或 ISA Server 2006，兩者都有專門為此用途設計的功能，它們會檢查所有的傳入封包，在傳遞至 Exchange 伺服器之前判斷其身分，然後透過網際網路將輸出資訊傳回到用戶端。
設定 ISA Server 時，您需要啟用 SSL 加密及指定連接埠 443 做為 SSL Web 接聽埠，來接收 Exchange Server 流量。這樣可以將它限制為單一連接埠，使其曝露於網際網路的機率降至最低。而且，在透過 ActiveSync 連線之前，所有用戶端都應該要建立 SSL 連結。
ISA Server 可以預先驗證 Web 應用程式 (如 OWA) 的使用者，幫助防止未驗證的使用者呼叫應用程式伺服器。ISA Server 2006 藉由扮演 Windows Mobile 之裝置的 SSL 終止點，來改進 ISA Server 2004 的 SSL 橋接模型。這樣可讓 Windows Mobile 的裝置不必建立直接連線就可以在 Exchange 伺服器上驗證身分，而不必依賴 ISA Server 2006 來回傳遞流量。而且，由於 ISA Server 2006 的建議位置是周邊網路內，這樣還可以使公用網際網路和 Exchange Server 前端系統之間多一層安全性。

驗證
有兩種基本驗證方式可供選擇：基本和憑證型。基本型是指 Windows Mobile 用戶端與 Exchange 前端伺服器之間，已啟用標準名稱和密碼的 SSL 型連線。它仍然需要憑證，因為在驗證之前，Exchange Server 會在裝置上尋找符合的根憑證。Windows Mobile 和 IIS 可讓您使用與 SSL 相關聯、選擇性眾多的加密法。
憑證型驗證是含有 MSFP 的 Windows Mobile 5.0 與 Windows Mobile 6 都提供的驗證方式，其中會使用傳輸層安全性 (Transport Layer Security，TLS) 而非 SSL 基本驗證。除了根憑證之外，TLS 還需要每一位使用者都具有含公開金鑰和私密金鑰的憑證。因為 TLS 會使用加密金鑰 (最多 2,048 位元) 而非密碼，所以此通訊協定可提供更強大的驗證。
有了 Windows Mobile 6，若要使用 Desktop Enroll 來註冊使用者憑證，就需要將裝置銜接到桌上型電腦上 (桌上型電腦必須位於與憑證註冊伺服器相同的網域中)。使用者會使用密碼、智慧卡或其他方法來驗證註冊，然後將裝置連線到桌上型 PC。接著使用者就可以透過桌上型電腦存取憑證系統，再由桌上型電腦將憑證安裝在行動裝置上。Desktop Enroll 有各種不同的 Windows Mobile 安全性用途，包括憑證的更新，以及 ActiveSync 驗證憑證、SSL/TLS 驗證憑證、802.1x Wi-Fi 憑證或 S/MIME 數位簽章憑證的發佈。
安全性通訊協定 (例如 SSL) 會保護傳輸中的訊息資料，但當訊息資料到達 Windows Mobile 裝置或 Exchange 伺服器之後，並不會將它們加密。S/MIME 是熟悉的 MIME 電子郵件標準的安全形式，它支援數位簽署及 (或) 加密的電子郵件。這比 SSL 傳輸層加密提供多一層保護。

結論
構成安全之基礎結構的解決方案涉及許多層面，每一個層面都值得我們注意。Windows Mobile、Exchange Server 和 Microsoft 網路安全性產品 (如 ISA Server) 可以密切地合作，以減輕行動基礎結構的管理負荷。這有助於減輕 IT 部門的一些壓力，以便將焦點從行動裝置所產生的安全性挑戰，轉移到它們所帶來的生產力優勢。

特別感謝 Kathy Esser、Katharine Holdsworth、Sarah Norton 及 Chip Vollers 對於本文章所提供的協助。

Matt Fontaine 是 BuzzBee Company 的技術文件作家。


 通訊: 公用資料夾的強大替代方案
通訊 Alan Maddison

公用資料夾的強大替代方案
摘要:
  • 共用行事曆和連絡人
  • 與部落格和 Wiki 通訊
  • 共用及管理文件

公用資料夾從 Microsoft Exchange 第一版開始就存在，其原始目標是要為共用文件、通訊群組清單保存及自訂應用程式開發提供一個基本平台。然而，幾乎從一開始，
系統管理員就苦於管理及使用這個已經變成許多 Exchange 環境日益複雜的一部分。雖然 Exchange Server 2007 在公用資料夾的管理上已提供一些重大改進，但難題還是存在。公用資料夾不提供現今企業所需要的健全共同作業和文件管理平台。
Microsoft 已表明 Exchange Server 2007 可能是支援公用資料夾之產品的最後版本。它們仍可獲得完整支援，且在 Exchange Server 2007 推出之後，也將繼續擁有長達 10 年的完整支援，因此，這只是檢驗替代方案的理想時機。
幸好，Microsoft 在推出的 Microsoft® Office SharePoint® Server (MOSS) 2007 中提供了吸引人的選項。MOSS 2007 可提供 IT 系統管理員和企業需要的平台，來取代及超越公用資料夾所提供的功能。在本文中，我會示範 MOSS 如何帶來健全而強大的架構，提供比 Exchange 公用資料夾更多的功能。尤其，我會把重點放在如何使用 SharePoint 進行與公用資料夾一樣的用途，例如共用行事曆、連絡人及文件共用方面。
請記住，您仍然需要公用資料夾，直到您至少更新用戶端為止。從 Outlook 97 到 Outlook 2003，Microsoft Outlook® 用戶端需要公用資料夾有幾個原因，包括離線通訊錄、公司表單檔案庫，以及查閱空閒/忙碌狀態。一旦您升級到 Outlook 2007 和 Exchange Server 2007 之後，只要一切準備就緖，您就可以完全不必使用公用資料夾。

SharePoint 行事曆
共用行事曆是公用資料夾的一般用途，SharePoint 可讓您很容易地以 SharePoint 行事曆取代公用資料夾行事曆。雖然 SharePoint 網站的預設安裝包含行事曆，但您可能需要建立多個行事曆，才能滿足公司的需求。為了示範，我會帶您逐步了解如何建立人力資源小組的共用行事曆。第一步是選取 [檢視所有網站內容] -- 這通常顯示在 SharePoint 網站的左上角 (請參閱 [圖 1])。
圖 1 建立新網站內容
圖 1 建立新網站內容
選取 [檢視所有網站內容] 之後，按一下 [建立] 按鈕 (它也顯示在 [圖 1])。當 [建立] 頁面載入之後，您將會看到預設內容類型選項 (如 [圖 2] 所示)。若要建立行事曆，您必須在 [追蹤] 欄中選取 [行事曆]。然後，您必須填寫名稱和描述欄位，並選擇是否要在 [快速連結] 區段中包含行事曆。
圖 2 [建立] 頁面會顯示許多預設選項
圖 2 [建立] 頁面會顯示許多預設選項
此時，會建立行事曆。使用者可以選擇要透過 SharePoint 網站或直接從 Outlook 檢視共用行事曆。若選擇後者，使用者只需要使用 Web 瀏覽器連接到行事曆，然後開啟 [動作] 功能表並選取 [連線至 Outlook] 選項即可。
第一次連線時，Outlook 會顯示安全性警告；這是要提醒使用者只能連線到已知且受信任的來源。選取 [是] 之後，行事曆將連線至 Outlook。[圖 3] 顯示預設檢視，它會並排顯示 SharePoint 行事曆及 Outlook 行事曆。
圖 3 SharePoint 行事曆及 Outlook 行事曆的 並排顯示畫面
圖 3 SharePoint 行事曆及 Outlook 行事曆的 並排顯示畫面
當行事曆連線至 Outlook 之後，就可以進行雙向同步處理。任何透過 Outlook 輸入的事件都會與 SharePoint 同步處理，而檢視該行事曆的所有使用者將會看到更新的項目。此外，如果您已在 SharePoint 內啟用 SMTP 支援，則可直接用電子郵件將事件傳送到行事曆，SharePoint 就會新增那些項目。

SharePoint 連絡人
許多公司都會使用依賴公用資料夾的共用連絡人功能。同樣地，SharePoint 有提供更健全的替代方案，以便建立及管理連絡人清單。延續同一範例，現在我會告訴您如何為範例人力資源部門建立共用連絡人清單。
同樣地，選取 [檢視所有網站內容] 並按一下 [建立] 按鈕。現在，請選取 [通訊] 欄中的 [連絡人] 連結。您就會看到一個畫面，讓您在其中提供 [名稱]、[描述] 和 [快速連結] 設定的資訊 (請參閱 [圖 4])。填妥此資訊之後，只要按一下 [建立] 按鈕，即可建立新的連絡人清單。
圖 4 填寫 [名稱]、[描述] 及 [快速連結] 設定
圖 4 填寫 [名稱]、[描述] 及 [快速連結] 設定

使用者通訊
您也可以使用 SharePoint 來建立討論區 (亦稱為討論清單)。就像行事曆和連絡人一樣，建立程序非常直截了當 -- 選取 [檢視所有網站內容]，按一下 [建立] 按鈕，並選取 [通訊] 欄中的 [討論區] 連結。如先前您所做過的，請針對 [名稱]、[描述] 和 [快速連結] 設定填寫適當的資訊，然後按一下 [建立] 按鈕。[圖 5] 顯示含有一些範例貼文的討論區。
圖 5 含有一些貼文的範例討論區
圖 5 含有一些貼文的範例討論區
除了討論區之外，現在 SharePoint Server 還支援兩種非常受歡迎的通訊工具 -- 部落格和 Wiki。公用資料夾所沒有的部落格和 Wiki 是 SharePoint Server 2007 的新功能，這些工具為此功能集提供新奇而有用的共同作業功能。
部落格提供互動式論壇，讓部落客可以將看法和想法張貼到網站上分享給大家。一般而言，這些貼文會分類，讓讀者更容易找到感興趣的貼文。同時，讀者也可以對部落客的意見提出回應。例如，公司可以由主管的成員設立部落格。這會是一個與員工溝通的強大工具，而且它可以提供管道讓職員分享想法，使所有層級的通訊順暢。
用 SharePoint 建立部落格很容易。第一步是選取 [檢視所有網站內容]，按一下 [建立] 按鈕，並按一下 [網頁] 欄下方的 [網站與工作區]。這會帶您到 [新 SharePoint 網站] 頁面，您必須在該處提供網站的 [標題]、[名稱] 和 [URL]。然後，您要選擇網站的範本 -- 在此案例中，請挑選 [部落格] 範本。最後三個設定選項是關於權限、導覽和網站目錄清單。完成所有必要選項之後，按 [建立] 按鈕。這會在最上層網站內實際建立子網站，子網站內含有提供部落格功能的文件庫和清單。當程序完成之後，將會帶您到新的部落格。
Wiki 是另一個很棒的工具，是為了進行更多共同撰寫而設計的。使用者可以在網站上新增、移除及編輯內容，以及連結許多網頁。建立 Wiki 的最簡單方式是選取 [檢視所有網站內容]，按一下 [建立] 連結，然後選取 [Wiki 頁面庫]，它會列在 [文件庫 (Libraries)] 欄中。在填寫好必要的 [名稱]、[描述] 和 [導覽] 設定欄位之後，按 [建立] 按鈕即完成。如需在 SharePoint 使用 Wiki 的詳細資訊，請參閱 TechNet Magazine 於 2007 年 1 月發表的在工作時使用 Wiki。

SharePoint 文件庫
公用資料夾實際上已變成文件存放庫，這個中央位置讓使用者可以輕易地存取及共用文件。過去幾年來，Exchange 系統管理員發現，這是使公用資料夾造成不便的主要用法之一。這不僅造成 Exchange I/O 負荷因為公用資料夾資料庫而增加，而且對於 Exchange 基礎結構的複寫也有負面的影響。SharePoint 文件庫提供絕佳替代方案，擺脫 Exchange 及其資源的需求。
SharePoint 文件庫是在 SharePoint 網站內的一個位置，可讓您儲存及管理檔案。文件庫有數種類型，包括圖片、Wiki 頁面、論壇和文件。在考慮取代公用資料夾時，文件庫是最適當的選擇。文件庫支援在 SharePoint 網站內儲存、管理、甚至建立文件。
許多不同類型的檔案可以儲存在文件庫中，但某些檔案類型 (例如可執行檔和指令碼) 基於安全理由，預設為受到限制。不過，這些限制可透過 SharePoint 管理中心網站的 [作業] 區段加以設定。
MOSS 的預設安裝包括可自訂的文件庫。大部分公司會希望建立多個文件庫，來支援公司內的不同業務單位。使用 SharePoint 提供的工具即可輕易達成此目的。例如，若要部署人力資源的文件庫，請選取 [檢視所有網站內容]，按一下 [建立] 連結，然後選擇 [文件庫 (Document Library)]，它會列在 [文件庫 (Libraries)] 欄中。然後您會看到一些您需要設定的項目 -- 提供文件庫的名稱和描述，指定是否要在 [快速連結] 區段中包含文件庫，選擇是否應啟用版本控制，並為直接在文件庫中建立的新文件選取預設格式。
請特別留意 [文件版本歷程記錄] 選項。其預設選擇為 [已停用]。不過，版本控制可能適合許多環境並且很有用。除了儲存文件的歷程複本之外，此功能還會追蹤何時進行變更及由誰變更，也提供檢視及還原舊版的功能。
[圖 6] 顯示已上載之某些文件的新建文件庫。建立文件庫之後，您可以開放這些存放庫給 Microsoft Outlook 和 Windows® 檔案總管使用。Outlook 可讓您使文件庫內容離線，並提供唯讀複本給無法存取網路的使用者。透過 Windows 檔案總管存取時，可利用 [網路上的芳鄰] 的便利性。輸入文件庫的 URL 之後，您就可以為使用者提供存取權。在大型環境中，您會考慮使用 [群組原則] 來部署這些 [網路上的芳鄰]。
圖 6 包含已上載之某些文件的文件庫
圖 6 包含已上載之某些文件的文件庫

進階功能
SharePoint 提供的功能集明顯超越公用資料夾所提供的功能。除了提供您可從公用資料夾獲得的一般功能之外，SharePoint Server 還提供更強大的功能來擴充這些一般用途的功能。這些增強功能包括：
  • 版本歷程記錄
  • 核准控制
  • 取出程序
  • 工作流程控制
  • 文件保留原則
  • 稽核
  • RSS
諸如此類的功能對於企業內容管理平台而言非常重要，SharePoint 提供讓系統管理員可以輕鬆使用的健全架構。此增強功能可針對許多 SharePoint 功能啟用，包括行事曆、工作、討論區和文件庫。
若要設定此功能，請選取 [設定] 功能表，然後選擇設定選項 (例如 [文件庫設定] 選項)，如 [圖 7] 所示。然後您會看到 [設定] 頁面，您可以在此處檢視所有設定和可用的自訂選項。例如，在 [一般設定] 欄底下的 [版本控制] 設定連結可讓您設定版本歷程記錄。
圖 7 選取設定選項以設定增強功能
圖 7 選取設定選項以設定增強功能
如前所述，此功能提供文件變更的記錄，包括由誰變更及何時進行變更，必要時還可讓使用者檢視及還原舊版。也可以控制 SharePoint 儲存的版本數。達到此限制之後，項目會遭到刪除而不會傳送至 SharePoint 資源回收筒。
[版本控制] 區段也可以讓您設定所需的 [內容核准] 及 [取出] 需求。啟用 [內容核准] 之後，任何提交的項目必須經過核准才可以提供給其他使用者使用。未經核准的項目會保持擱置中狀態。[取出] 程序提供內容控制，方法是禁止多個使用者同時處理某一個檔案。
工作流程是 SharePoint 提供的另一個有用功能，公用資料夾不提供此功能。基本上，工作流程是一種結構式的商業流程，可幫助簡化貴公司的作業。在 SharePoint 內實作的工作流程是一連串預先定義的工作，可透過指定程序使文件的處理自動化。此程序可以反覆執行，且在進行下一個步驟之前，需要先完成前面的步驟，但是此程序也可以是平行的，好讓給定的工作及時完成。SharePoint 包含的預設工作流程如下：
  • 核准
  • 收集意見
  • 收集簽章
  • 處理核准
資訊管理原則是用來強制依循規範與商業需求。原則包含與文件的管理及控制相關的一組規則。SharePoint Server 支援自訂規則，但包含一些好用的預設規則，其中包括：
  • 稽核
  • 到期
  • 標籤
  • 條碼
稽核會根據您在網站設定內定義的一組動作，提供記錄事件的功能。您可以追蹤像開啟文件、下載或檢視項目或其內容、編輯文件、取出或存回文件、移動或複製項目，以及刪除或還原項目之類的動作。
內容到期可讓您刪除內容，以依循公司的資料保留原則。資料到期可發生於特定日期，或發生於特定事件 (例如建立文件) 發生之後的一段固定期間。
列印時會使用標籤，它會在列印時加上文字。實際上，此原則有許多用途。例如，您可以要求人力資源部之共用文件庫的所有文件，都包含一項保密聲明，以依循法務部門的規範。
條碼為線上文件和列印的文件提供正式追蹤方法。SharePoint 將為每一份文件建立唯一識別碼，於是使用者可以將條碼的影像插入其文件中。
SharePoint 提供的另一項重要增強功能是它與 RSS 摘要的整合。行事曆、連絡人、文件庫和討論區全部都會提供使用者可以訂閱的 RSS 摘要。使用者可以接收自動化更新項目來幫助追蹤其例行職責，而唯一需要的就是 RSS 讀取程式，例如 Outlook 2007。

結論
Microsoft Office SharePoint Server 2007 提供企業級功能，並提供比 Exchange 公用資料夾更強大的替代方案。健全的管理架構可讓您輕鬆實作解決方案，來共用行事曆、連絡人和文件。您也可以建立各種通訊管道，包括討論區、部落格和 Wiki。

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


 通訊: 使用智慧卡登入 Outlook Web Access
通訊 Victor Akinnagbe and Ted Dressel and Jason Opdycke

使用智慧卡登入 Outlook Web Access
摘要:
  • 雙重關卡驗證
  • Kerberos 限制委派
  • ISA Server 和 Exchange 的組態

行動員工為 IT 組織帶來更特殊的安全性挑戰。遠端使用者需要針對類似電子郵件等資料和服務，進行安全的存取。但不幸的是，在現實中，
安全性鏈結最脆弱的環節，涉及在存取貴組織內部資源的遠端電腦上，有容易破解的密碼、惡意程式 (例如按鍵記錄程式)，以及病毒。
在這種行動環境下增加安全性的方式之一，是移除其中最脆弱的一環：密碼 (不過允許無密碼驗證即存取帳戶的方式確實有些令人困擾)。要解決密碼相關問題的主要技巧，是採用名為雙重關卡驗證的方法 (或者有時候為多重關卡驗證)。雙重關卡驗證並非仰賴「密碼」這個單一方法來存取，而是採取其他驗證方法，包括使用者名稱/密碼組合、實體裝置 (如智慧卡)，或是人體辨識法 (如指紋)。
若您有遠端使用者，一般而言就必須開放防火牆，以允許由遠端存取企業網路。標準防火牆可藉由隔離網路層級的內、外網路，讓您略為降低風險 (請參閱 [圖 1])。如需更高的安全性，則可以直接關閉通訊埠。如果內部網路的裝置需要進行通訊，則會將通訊埠轉送到正確的位置。這些技巧的確可提供實質的網路層級保護，但現在的攻擊愈來愈複雜，因此需要多重層級的網路安全性。
圖 1 標準防火牆的通訊埠受阻擋或轉送
圖 1 標準防火牆的通訊埠受阻擋或轉送
由於行動員工最常用的企業服務，通常是電子郵件和訊息服務，因此 Exchange 基礎架構的安全設定，就成為非常重要的課題。讓使用者透過 Outlook® Web Access (OWA) 存取電子郵件，是為行動員工提供安全服務的一種方式。透過智慧卡為 OWA 提供更安全的雙重關卡驗證，則是另一項要素。我們將在本文中深入探討您啟用個人的智慧卡式 OWA 部署時，需要注意哪些組態與安裝相關事項。

比防火牆更好用
在網路上部署 Microsoft® Internet Security and Acceleration (ISA) Server 2006，可以用更安全的方式，簡化為遠端使用者開放網路的作業。ISA Server 2006 包括強化安全性功能，如智慧卡式虛擬私人網路 (VPN)、Active Directory® 的 Lightweight Directory Access Protocol (LDAP) 驗證，以及 Kerberos 限制委派。ISA Server 與您傳統印象中的防火牆不太一樣。它提供的多重安全層級不僅在網路層級運作 (可以取代或搭配標準防火牆硬體使用)，還能提供傳統防火牆通常無法支援的額外安全性功能，例如應用程式篩選器。不想讓其他人使用 HTTP POST 方法進入特定主控網站嗎？想要先強制 RFC 與 SMTP 訊息相容，才能接觸您的 Exchange 伺服器嗎?希望先檢查加密的 Secure Sockets Layer (SSL) HTTP 封包，再放到網路上？ISA Server 可管理上述所有工作，並且確保只有乾淨、篩選過的流量，才能轉送到您的 DMZ 或內部網路。
SSL 工作階段對於標準防火牆而言是一大問題。當封包經由防火牆傳送時，仍維持加密狀態 (也就表示 SSL 運作正常)。因此，若像 OWA 這樣的應用程式使用 SSL 穿過硬體或軟體防火牆發行，實際上標準防火牆除了可以設定狀況的封包檢查外，就無法執行任何有意義的檢查。直接開啟和轉送通訊埠，可能會暴露出可受攻擊的面。既然在邊緣無法真正進行檢查，未檢查和未驗證的封包就可能會傳送到您的內部網路。
ISA Server 2006 可做為 HTTP 用戶端的 SSL 結束點，確保只有經過驗證的流量，才能送達發佈的 Exchange server。ISA Server 支援名為 SSL 橋接的功能。一般而言，封包是由用戶端加密，而該用戶端是經由標準 SSL 工作階段與 SIA Server 進行通訊。有了 SSL 橋接，ISA Server 可於本機終止 SSL 加密、檢查目前未加密的封包、驗證 Active Directory 使用者 (若有必要)、使用 SSL 重新加密封包，以及將加密封包傳送到適當的 Exchange server (請參閱 [圖 2])。利用這項技巧，SSL 橋接可減少隱身在 SSL 工作階段中的攻擊，因為這些攻擊對於無法感知應用程式的防火牆而言，只是已加密的資料 Blob。
圖 2 ISA Server 採取應用程式層級檢視流量
圖 2 ISA Server 採取應用程式層級檢視流量
討論 Kerberos 限制委派時，就免不了要談到送達伺服器的預先驗證流量。在標準防火牆中，僅會將通訊埠轉送至 Exchange Server，前端伺服器本身需要負責針對可能為惡意的使用者，執行驗證工作。需要驗證時，ISA Server 可以直接連絡 Active Directory，並以使用者的身分提出認證要求。若使用者成功通過驗證，ISA Server 會將訊息轉寄到 Exchange 前端伺服器。前端伺服器不再需要隨機驗證不明使用者要求，同時可以專門用於後端伺服器連線要求的 Proxy。ISA Server 2006 亦可使用 Kerberos 限制委派，以啟用認證方式來存取如 Windows SharePoint Service 和 Exchange ActiveSync 等技術。
Exchange Server 2003 包括 OWA 登入的前端與後端伺服器之間的 Kerberos 驗證支援 (您正在使用 IPsec 來保護該用戶端流量，不是嗎？)Exchange Server 亦支援叢集郵件信箱伺服器的 Kerberos 驗證。

啟用智慧卡驗證
為 OWA 執行智慧卡式驗證，曾經是個難題。然而，目前在 ISA Server 2006 上，已經針對 Kerberos 限制委派功能發展出解決方案。這個解決方案可允許使用者透過認證來提交憑證，以便成功為 OWA 驗證。Kerberos 限制委派在使用不限制委派的 Windows® 2000 中，扮演改善 Kerberos 委派支援的角色。Kerberos 的限制功能較為安全，並可限制使用模擬進行複雜攻擊的潛在風險。
在使用智慧卡的情況下，ISA Server 2006 會連絡 Active Directory 來驗證使用者，因為使用者無法從外部網路進行 Key Distribution Center (KDC) 的路由式存取。ISA Server 會依照 Active Directory 的認證與使用者對應，來驗證使用者，接著根據使用者主要名稱 (UPN) 取得其 Kerberos 票證。在這種情況下，ISA Server 是經由應用程式層級的篩選和反向 Proxy 服務，為 Exchange 前端伺服器提供 Kerberos 限制委派功能。若嘗試在沒有反向 Proxy 的情況下進行委派，遭入侵的風險會影響網路或 Active Directory 網域的完整性。
Exchange Server 2003 和 Exchange Server 2007 都允許基本與整合式驗證。但是您需要為 Exchange Server 2003 套用軟體更新，OWA 的智慧卡驗證才能運作 (如需詳細資訊，請參閱文件 " 在 Exchange Server 2003 中，支援新的 Outlook Web Access 智慧卡驗證功能的說明 ")。您在 Windows Server® 2003 原生功能模式中必須備有網域，所有相關 Exchange Server 2003 伺服器都必須套用 SP2 或以上的版本，且必須將 ISA Server 2006 伺服器當做 OWA 站台的反向 Proxy。
安裝軟體更新，並且設定 ISA 及 Exchange server 之後，使用者即可使用智慧卡驗證 OWA 工作階段。[圖 3] 顯示智慧卡驗證所需的事件流程。一開始，使用者要先在 Internet Explorer® 中開啟 OWA 站台 (1)。事實上，使用者會連接到 ISA Server，其中會出現提示要求提供認證，而非使用者名稱和密碼，才能啟動 OWA 工作階段。適當的認證儲存在智慧卡中，而使用者必須有 PIN 才能使用。
圖 3 使用智慧卡驗證 OWA
圖 3 使用智慧卡驗證 OWA
憑證確認 (2) 是經由憑證撤銷清單 (CRL) 或者線上憑證狀態通訊協定 (OCSP) 要求處理，並依據 ISA Server 及其他已安裝軟體的組態為主。ISA Server 會要求網域控制站 (DC) 確認使用者的身分。若要求失敗，ISA Server 會向使用者顯示錯誤訊息頁面，同時不會將任何要求傳送到 Exchange 前端伺服器。
認證的驗證工作完成後，即會產生 Kerberos 票證，並且會使用整合式驗證 (3) 將要求傳送到 Exchange 前端伺服器。Exchange 前端伺服器接收到要求時，會確認 Kerberos 票證並找出使用者的後端電子郵件伺服器 (4)。
前端伺服器會透過 Kerberos 限制委派，為適當的後端伺服器要求 Kerberos 票證，然後使用整合式驗證 (5)，將郵件信箱要求連線 Proxy 到後端伺服器。該要求將由後端伺服器 (6) 服務，然後再把郵件信箱資料傳回 Exchange 前端伺服器 (7)。OWA 頁面的 HTML 資料會傳遞到 ISA Server (8)，接著再傳遞回用戶端電腦 (9)。

設定 Exchange 環境
先前所提到的知識庫文件中，描述了 Exchange Server 2003 的軟體更新，並且包括各種資訊，可利用 ISA Server 2006 和 Exchange Server 2003 協助您逐步完成 Kerberos 限制委派啟用程序。
軟體更新可發揮的主要動作，是將 Kerberos 限制委派的程序自動化，從 Exchange 前端伺服器自動送到對應的後端伺服器。更新並不會將 Kerberos 限制委派從 ISA Server 到前端伺服器的程序自動化，因為 ISA Server 並非 Exchange 組織的一部分。該委派必須以手動方式啟用，從各個 ISA Server 執行個體到每個 Exchange 前端伺服器。
軟體更新會在 Exchange System Manager (ESM) 中加入新的索引標籤，讓您可以將某 Exchange 前端伺服器指定為 KCD-FE (請參閱 [圖 4])，因而允許該伺服器顯示在其對應 Exchange 後端伺服器的委派索引標籤中。
圖 4 啟用 Kerberos 限制委派
圖 4 啟用 Kerberos 限制委派
新的 UI 亦可讓您在管理群組的屬性中，指定要將哪些認證顯示於 msDS-AllowedToDelegateTo (A2D2) 屬性中，如 [圖 5] 所示。這是負責 Kerberos 限制委派的屬性。
圖 5 設定控制委派的帳戶
圖 5 設定控制委派的帳戶
為了達到最少權限的限制原則，您可以使用標準使用者帳戶，並核准其經由群組原則物件 (GPO) 委派使用者和電腦。該帳戶獲得此更高的權限之後，即可視為服務帳戶，以自動化其對應之管理群組的 Kerberos 限制委派程序。
請確認您採取正確的步驟，以確保惡意使用者不會危害到 Kerberos 限制委派服務帳戶。即使該帳戶並非網域管理員，存取時仍可能利用 Kerberos 委派，導致複雜的攻擊。由於該帳戶有能力建立新的 Kerberos 關聯，因此應小心使用。採取必要的預防措施，以確保帳戶的安全性和完整性：使用長而複雜的密碼、增加稽核動作、帳戶停用技巧等。
Exchange 軟體更新亦對於 ESM 介面有極重要的整合性驗證相關變更。過去在 Exchange Server 2003 版本中，伺服器委派為前端伺服器時，啟用 HTTP 虛擬目錄中整合 Windows 驗證的選項 (位於 HTTP 虛擬伺服器項目下)，是無法使用的灰色 (請參閱 [圖 6])。
圖 6a 更新啟用了整合式驗證
圖 6a 更新啟用了整合式驗證
圖 6b 更新啟用了整合式驗證
圖 6b 更新啟用了整合式驗證
這是由於 Exchange 前端伺服器因技術問題而不支援整合式驗證，其中的問題包括如 Proxy 伺服器中斷了 NTLM 工作階段、使用者部署 Kerberos 驗證時需要連接到 Active Directory，以及網際網路使用者通常不屬於該網域。在前述知識庫文件中描述的更新，去除了這些限制。安裝更新之後，即可輕鬆到虛擬目錄中核取 Windows 整合式驗證的方塊，以做為確認使用者身分的機制。核取此項目後，會在 Active Directory 的虛擬目錄物件上，設定名為 msexchAuthenticationFlags 的屬性 (只要在 Microsoft Management Console 使用 Adsiedit.msc 嵌入式管理單元，就可以看到)。
透過 OWA 檢查郵件的使用者或許知道其 Exchange 後端伺服器的名稱，並可於企業內部網路中，利用整合式驗證來進行連結。使用者在使用整合式驗證的不同之處，在於只要登入網路，就不會再提示您輸入使用者名稱和密碼，因為 Internet Explorer 會自動驗證讓您進入網站。這點對於企業網路內部的使用者十分好用，但對於外部使用者 (而且 OWA 使用者大多屬於外部使用者) 而言，通常會從網路外部進入 Exchange 前端伺服器，所以通常不會登入網域中 (此程序在知識庫文件 "IIS 如何驗證瀏覽器用戶端 " 中有詳細說明)。
在 Exchange Server 中，更新會產生 [委派] 索引標籤，並於 Active Directory 中使用 A2D2 屬性來取代服務主要名稱 (SPN) 屬性。若您使用 Adsiedit.msc 來查看 Exchange 電腦物件，應該會發現兩個完全不同的屬性：A2D2 屬性是 Kerberos 限制委派清單；而 SPN 屬性則是 Kerberos 定位程式和帳戶規格點。雖然同時使用兩種屬性，的確可以啟用 Kerberos 限制委派，但您只應透過圖形介面來修改 A2D2 屬性。
Windows 可以使用內建 HOST SPN，做為找出其他服務的別名。這表示 Kerberos 限制委派不一定需要使用 setspn.exe 就能完成 Exchange 前端到後端指派 (雖然明確指定 SPN 屬性清單中的 HTTP/Servername 適用此解決方案，但仍有太多的管理員錯誤空間，而且 Kerberos 限制委派不需要它們也能運作)。Kerberos 限制委派正在 Active Directory 中尋找 A2D2 屬性。未產生此屬性時 (或者產生時有錯誤的 SPN 值)，Kerberos 限制委派無法在對應的伺服器之間運作。不過在 Exchange 叢集上，來自前端伺服器的 A2D2 屬性僅需要指向叢集節點電腦帳戶，就能正常運作。
如先前所述，包含 Exchange 2003 伺服器的 Windows Server 2003 網域，必須採用 Windows Server 2003 原生功能模式。除非已經達到網域功能層級，否則 Kerberos 限制委派無法使用。若您的網域仍為混合模式，而且您已經安裝過先前討論的軟體更新，則會看似正常運作，但 SPN 註冊最後仍會失敗。Kerberos 限制委派也是網域功能，而非樹系層級功能。這表示對於 Exchange Server 2003、ISA Server 和 Exchange 前端和後端伺服器而言，必須是同網域的成員 (雖然來自不同網域的使用者仍可通過 Kerberos 限制委派驗證)。非網域成員或者是其他網或成員的 ISA Server 例項，無法在此解決方案中使用。

設定 OWA 站台
IIS Admin 不應該用來做任何的 OWA 驗證變更。雖然 OWA 在 IIS 下執行，且和其他網站一樣可以回應 Metabase 的變更，但 Exchange 的 Directory Services to Metabase (DS2MB) 處理程序較為複雜。DS2MB 處理程序會以單向程序從 Active Directory 複寫變更到 IIS Metabase，其中會直接複寫所有變更到 IIS。此處理程序的影響，是當系統管理員直接在 IIS Metabase 上執行變更時 (例如設定整合式驗證)，解決方案的運作會看似正常，但是只要下一個 DS2MB 複寫週期開始，就會立刻失敗。
為 HTTP 虛擬目錄啟用整合式 Windows 驗證的選項提供於 ESM 中，因為 ESM 可直接將編輯內容反應至 Active Directory，因而使得變更複寫到 IIS Metabase。請記住，雖然在停止 System Attendant 服務時也會停止 DS2MB 處理程序，這樣可以讓您變更 IIS Metabase 而不直接複寫，但是我們不建議這麼做。因為下次啟動 System Attendant 時，會從 Active Directory 中找出變更，而解決方案就會自動停用。
[委派] 索引標籤會顯示選項，讓您選擇 [只使用 Kerberos] 或者 [使用任何驗證通訊協定]。若以基本邏輯來判斷，應該都會選擇 [只使用 Kerberos]，因為我們所討論的解決方案使用的是 Kerberos 限制委派，但這是眾多 IT 案例中無法套用正常邏輯的個案之一。相反的，您應該選擇 [使用任何驗證通訊協定] 選項 (如 [圖 7] 所示)，因為傳入的要求並非 Kerberos 要求，而是有認證對應到 Active Directory 帳戶的 HTTP 要求。
圖 7 適用於智慧卡的正確驗證設定
圖 7 適用於智慧卡的正確驗證設定
在此案例中，ISA Server 會要求使用者透過 SSL 提供 PKI 認證。傳入的要求並非 Kerberos 票證，所以必須進行轉換，才能讓 Kerberos 限制委派正確運作。因此，若設定為限使用 Kerberos，則會破壞 ISA Server 的通訊鏈結。不過要注意的是，限使用 Kerberos 選項可以用在 Exchange 前端到後端伺服器委派，因為前端伺服器只會從 ISA Server 接收到 Kerberos 票證。
\Exchange 和 \Public 虛擬目錄是唯一應包括私人使用者和公開資料夾資訊的位置。Exchange 的 SSL 組態對於 Kerberos 限制委派或雙重關卡驗證而言並不陌生，而是來自於標準 SSL 為啟用具基本驗證認證的 OWA 延用至今。您應該遵循記錄方法來啟用 OWA 的 SSL，因為以錯誤方式強制 SSL 會破壞 OWA，而且同時會導致 ESM 發生問題。

其他組態細節
在執行此解決方案時，若先以標準方式部署 ISA Server 和 Exchange，可以更輕鬆的完成工作。不要一次加入整個 Kerberos 限制委派解決方案和設定 (尤其是您之前若從未部署過 ISA Server，更不要這麼做)。若處理程序中有元件或步驟失敗，這麼做會使得疑難排解的程序更加複雜。比較簡單的做法是採用標準方式部署 ISA Server 和 Exchange (採取使用者名稱和密碼、但沒有表格式的驗證)，先確保安裝之後可以正常運作，然後再轉換到 Kerberos 限制委派和認證驗證。
一般而言，表格式驗證無法在啟用了智慧卡的 OWA 中使用。表格式驗證表示使用者會透過標準 Outlook 表格，提交使用者名稱和密碼。然而，有了智慧卡的雙重關卡驗證，使用者只會有智慧卡，沒有密碼。因此表格式驗證將無法接受或提交只具有認證的驗證。在鏈結中任一處使用表格式驗證 (例如在 ISA Server 後方的前端伺服器)，都會破壞啟用了智慧卡的 OWA 組態。若您啟用表格式驗證，Exchange 虛擬目錄會強制設定為基本驗證，因此 IIS Metabase 也會同時設定為基本驗證。
如果在您的使用者群組中，有些會用使用者名稱/密碼，有些則用智慧卡，那麼您就可以啟用 ISA Web 接聽程式的後援驗證，當使用者在出現認證提示後按下 ESC 鍵，電腦就會提示使用者輸入標準使用者名稱/密碼認證，即使 Exchange Server 的 ISA Server 已啟用整合式驗證。此外，ISA Server 可以讓 SSL 工作階段逾時，方法和表格式驗證功能大同小異。

結論
使用智慧卡支援 OWA 驗證對於 Exchange Server 2003 和 Exchange Server 2007 來說，都具有加分效果。使用者能夠使用認證登入 OWA，就不再需要擔心記不住又臭又長的密碼，而系統管理員現在也可以利用更有效的工具，來對付以病毒感染系統而竊取使用者身分的按鍵記錄程式與其他惡意程式。如需詳細資訊，請參閱 [資源] 資訊看板。
為 ISA Server 正確設定雙重關卡驗證與智慧卡的功能，可以提升整體安全性，甚至能進一步在發佈的 OWA 應用程式上，執行應用程式層級的篩選工作。此外，ISA Server 2006 具有可透過簡易的發佈精靈，同時發佈 Exchange Server 2003 和 Exchange Server 2007 的內建支援，因此 ISA Server 仍是各組織移轉至 Exchange Server 2007 的有效投資標的。
資源
  • 在 Exchange Server 2003 中，如何共用已由 Outlook Web Access 之 "Safe HTML" 篩選功能移除的檔案
  • 為 Kerberos 委派進行疑難排解
  • Metabase 更新服務
  • ISA Server 2006 中的驗證
  • Kerberos 通訊協定的轉換與限制委派
  • TechNet 網路廣播：使用智慧卡執行多重關卡驗證

Victor Akinnagbe 為 Microsoft 專案領域工程師，工作地點在華盛頓。他的專長包括安全性、基礎架構以及郵件訊息。
Ted Dressel 擔任 Microsoft 顧問，工作地點在華盛頓。他的專長包括安全性和基礎架構。
Jason Opdycke 為 Microsoft 首席專業工程師，工作地點在北卡夏洛特市。他的專長包括安全性和基礎架構。


 Windows 系統管理: Windows Vista 的 ActiveX Installer 服務
Windows 系統管理 Rob Campbell and Joel Yoker

Windows Vista 的 ActiveX Installer 服務
摘要:
  • ActiveX 控制項的常見難題
  • 如何安裝 ActiveX 控制項
  • 具危險性的使用權限
  • Windows Vista 中較安全的處理程序

這是永遠不變的事。若要大幅提升您的安全性，就必須犧牲部分自由度或彈性。如果您的環境和多數企業相同，您一定會熱切希望強化電腦的作業系統，以便提供更安全的運算
環境給終端使用者。IT 系統管理員強化電腦安全性的方法，通常會組合安全性原則設定、使用者權限、檔案和登錄存取控制清單 (ACL)，以及系統服務限制。
在開發安全電腦環境的過程中，有一個常見的困難，就是如何一面減緩惡意 ActiveX® 控制項週遭的威脅，同時仍為環境提供適當的應用程式相容性等級。多年來，這一直是電腦作業系統的一道難題。幸好，Windows Vista™ 中有全新的 ActiveX control Installer Service (AxIS)，可以在企業環境中解決特屬 ActiveX 控制項管理的問題。AxIS 可以為標準使用者提供簡單且可管理的方法，從允許的網站安裝 ActiveX 控制項 (通常並不會允許使用者安裝 ActiveX 控制項)。可控制 AxIS 的群組原則，能夠讓 IT 系統管理員判斷使用者 (不論其權限) 可安裝哪些控制項。
在本文中，我們將討論 Active X 控制項相關的系統管理難題，在舊版 Windows® 中如何解決這些問題，以及 Windows Vista 的 AxIS 如何以獨特、更有效的方式來管理 ActiveX 控制項的安裝作業。

什麼是 ActiveX 控制項？
ActiveX 控制項是可執行的程式碼 (通常是封裝在 CAB 檔內的 OCX 檔)，由使用者透過 Internet Explorer® 安裝和叫用。Web 開發人員建立 ActiveX 控制項，以便於 Web 應用程式中加入功能，這是使用標準 HTML 或簡易指令碼所難以達到的目標。
ActiveX 控制項的主要特性，在於簡單的「下載並執行」部署模式。ActiveX 控制項會透過 HTML 物件標記安裝和叫用，此標記有一種名為 CODEBASE 的屬性，若使用者電腦上尚未安裝控制項，便會告知 Internet Explorer (使用 URL) 到何處取得。在這種情況下，Internet Explorer 會下載安裝套件，為物件執行信任驗證，並且透過 Internet Explorer 資訊列 (如 [圖 1] 所示) 詢問使用者是否授與安裝權限。在安裝期間，會註冊控制項並由呈現頁面叫用。安裝完成後，任何一般使用者皆可叫用該控制項。這項簡單的散佈與執行機制，目的在提供開發人員簡便的方式，將元件散佈給 Web 應用程式使用者。此散佈方法的問題是，標準使用者無法直接安裝 ActiveX 控制項，因為必須有系統管理權限才能完成安裝程序。
圖 1 ActiveX 控制項安裝資訊列
圖 1 ActiveX 控制項安裝資訊列
Internet Explorer 4.0 中首次推出 ActiveX 控制項功能時，網路就變得更好用了。現在，透過 Web 發佈的可執行程式碼都可能會有安全性的威脅，因此 Windows 只允許具有本機系統管理員權限的使用者安裝 ActiveX 控制項，也只允許符合原則設定的安裝。ActiveX 控制項一旦由系統管理員安裝後，系統上的任何使用者皆可叫用。此行為由一組檔案和 Windows 中的登錄 ACL 促成。雖然這可以避免標準使用者安裝 ActiveX 控制項，但是無法將風險移轉至安裝這些控制項的本機系統管理員和標準使用者 (預設權限已修改)。
然而 Windows 的預設保護 (只允許具有系統管理員權限的使用者進行安裝) 可解決個別電腦上的 ActiveX 控制項，卻無法在大型組織內管理這些控制項。企業環境中常見的難題，是如何允許受 IT 組織信任的 ActiveX 控制項的使用，同時又能保護電腦不受外部、不信任的控制項的威脅。最終決定要安裝特定 ActiveX 控制項究竟是好是壞，通常還是得根據個別使用者的權限來論定。為了抵抗這些威脅，有些公司會阻擋所有的 ActiveX 控制項，有些則允許終端使用者安裝控制項，但是會另外設法管理可能安裝的惡意程式。
另一種避免安裝惡意控制項的方式，是強制賦予標準使用者限制權限，並且由 IT 系統管理員預先將所有需要的控制項安裝在電腦平台上。若需要使用的 ActiveX 控制項較為靜態、會以固定排程搭配電腦的更新進行修改，或者企業有使用如 Systems Management Server 的軟體發佈機制時，此方法就十分有效。然而，長期的管理、不斷變化的內部應用程式開發人員需求，以及對外部控制項的依賴，仍是這些方法的主要難題。
若使用者具有系統管理員權限，問題則大不相同；其中涉及如何不讓這些使用者安裝未經核准的控制項。在這種情況下，由於使用者具有系統管理員權限，因而會假設終端使用者具有安裝 ActiveX 控制項的權利 (請注意，若終端使用者以本機系統管理員身分執行，企業就會陷入高風險情形，通常都不建議企業環境如此做)。
解決方法之一，是採用裝載已核准控制項的內部網際網路元件下載伺服器。這個方法需要修改用戶端登錄中的 CodeBaseSearchPath 字串。一般而言，若於要求的 HTML 頁面中找到包含 CODEBASE 屬性的物件標記，Windows 用戶端會導向 CodeBaseSearchPath 資料中指定的位置。根據預設，此登錄字串會包含 CODEBASE 關鍵字以及 ActiveX 控制項檔案庫的網際網路 URL。若要實作網際網路元件下載伺服器，必須將 CodeBaseSearchPath 的預設資料，置換為企業核准用來裝載控制項之內部伺服器的 URL。如同上一個方法，此解決方案仍需要長期管理，且尚需負擔裝載 ActiveX 控制項內部伺服器的成本與複雜度。
還有其他解決方案，諸如修改 Internet Explorer 區域 URLActions、透過群組原則指定系統管理員核准控制項，以及利用防火牆規則阻擋所有週邊控制項的安裝程序。但是正如您所見，這些方法全都有其問題，且許多方法最後都會因為缺乏彈性而被廢棄。更糟的是，有部分解決方法仍要求使用者具備系統管理員權限。這些修改方法只能解決部分問題 (例如控制 (或阻擋) ActiveX 控制項的來源、可叫用的位置等)，然而到最後，這些解決方案仍無法減輕最根本的問題：沒有系統管理員權限的使用者不得安裝 ActiveX 控制項。

AxIS 有哪些用途？
Windows Vista 的 AxIS 可以讓企業系統管理員有效管理 ActiveX 控制項，同時維護安全狀態，因為使用者將以預設檔案系統的設定加上標準使用者的身分執行。AxIS 提供的群組原則選項，能夠設定 ActiveX 控制項的信任來源和代理程序，以便從這些信任來源為標準使用者安裝控制項。主要的優勢在於能夠在使用者工作站上，維持非系統管理員的安全狀態，同時配合集中式系統管理控制。AxIS 會仰賴 IT 系統管理人員識別出 ActiveX 控制項的信任來源 (一般為網際網路或內部網路)。當物件標記引導 Internet Explorer 叫用控制項時，AxIS 會採取下列步驟：
  1. 檢查控制項是否已安裝。若尚未安裝，則必須先行安裝方可使用。
  2. 檢查 AxIS 原則設定，以驗證控制項是否來自信任來源。檢查時會對照原則中指定的信任位置清單，與物件標記之 CODEBASE 屬性中所指定 URL 的主機名稱，確認兩者符合。
  3. 為使用者下載和安裝控制項。
若來源 URL 的主機名稱並未列在 AxIS 原則設定中，則會叫用正常使用者帳戶控制 (UAC) 提示，要求系統管理員權限來完成安裝。此外，AxIS 會從來源 AxInstallService 於應用程式事件記錄中以 ID 4097 記錄事件，概述嘗試安裝 ActiveX 控制項的過程，以及控制項的特定下載路徑。4097 事件的範例顯示於 [圖 2] 中。此事件記錄項目的資料可由企業系統管理員用來修改群組原則，以允許後續造訪網站時由 AxIS 安裝控制項。
圖 2 4097 AxInstallService 事件
圖 2 4097 AxInstallService 事件
AxIS 是選擇性元件，隨附於 Windows Vista 的 Business、Enterprise 及 Ultimate SKU 版本中，可以經由自動選項或者透過 [控制台] 對話方塊 ([所有程式] | [程式和功能] | [開啟或關閉 Windows 功能])，如 [圖 3] 所示。啟用之後，每次 Internet Explorer 要求控制項時，AxIS 就會逐步進行上述步驟。
圖 3 在 [控制台] 中啟用 AxIS
圖 3 在 [控制台] 中啟用 AxIS
在 Windows Vista 中附加工作到事件的功能，是系統管理員從 AxIS 服務接收通知的簡便方式，例如 ActiveX 控制項安裝受阻的通知。必須注意的一點是，不得假設 ActiveX 控制項永遠都會透過終端使用者所存取網站的相同 URL 主機名稱進行安裝。基於此原因，AxInstallService 4097 (嘗試安裝) 事件所提供的資訊，包含可用來識別控制項是從哪一台主機在嘗試安裝，極為有用。
經由該事件所得到的資訊，您可以設定群組原則中的信任位置。本機或群組原則的 AxIS 設定，會在 [電腦組態設定] 中 (如 [圖 4] 所示)。[ActiveX 控制項的認可安裝網站] 原則設定，可允許您指定信任位置的主機 URL (請參閱 [圖 5])。認可的網站設定共需要兩種資訊：ActiveX 控制項的安裝來源，以及安裝的行為。
圖 4 群組原則物件編輯器中的設定
圖 4 群組原則物件編輯器中的設定
圖 5 AxIS 認可的安裝網站
圖 5 AxIS 認可的安裝網站
首先，如之前所述，必須有主機 URL 來指出控制項的信任位置。這與先前的解決方案不同，後者必須得知控制項的 CLSID (經常因為開發人員修改控制項而改變)，AxIS 則允許從信任位置安裝任何控制項，以減輕整體系統管理上的負擔。第二種資訊是以半形逗號區隔的字串，共有四個值，每個皆負責 ActiveX 控制項下載的行為。這些數值可指定四種屬性：TPSSignedControl、SignedControl、UnsignedControl 以及 ServerCertificatePolicy。前兩個屬性 (TPSSignedControl 和 SignedControl) 可為下列三個數值中任一個：0、1 或 2。這些數值與 URLAction 設定中找到的數值相似。0 值會阻止控制項的安裝，1 值會導致出現提示，要求使用者提出安裝權限，2 值可以讓控制項直接以使用者的身分安裝。未簽署的控制項無法自動安裝，因此 UnsignedControl 數值只能為 0 或 1。請注意如果未指定原則，就會使用預設值 2、1 和 0。
最後一項屬性會根據已簽署設定控制項的憑證設定，來指定安裝行為。和多數 SSL 網站一樣，憑證必須通過一系列安全性測試，才能確保該憑證有效。無效的憑證屬性，有時候也會出現在已簽署 ActiveX 控制項的實作中。透過這項組態，AxIS 可以讓系統管理員減少無效的資訊，這些資訊有時候是以逐個 URL 的方式，一一藉由憑證來呈現。最後的屬性會以位元遮罩的數值組合表現，如 [圖 6] 所示。
Figure 6 ServerCertificatePolicy (Close Figure 6)

數值 | 定義
0x00001000 | 在憑證中略過無效的正式名稱 (CN)。
0x00000100 | 略過未知的憑證授權單位 (CA)。
0x00002000 | 略過無效的憑證日期。
0x00000200 | 略過錯誤的憑證使用率。
預設值為 0，表示必須通過所有安全性檢查，AxIS 才能完成安裝程序。主機設定和這四個數值的組合，皆於原則設定中指定，如 [圖 7] 所示。
圖 7 認可的 AxIS 主機 URL
圖 7 認可的 AxIS 主機 URL

結論
AxIS 可以讓您設定群組原則，來控管使用者可以直接安裝的 ActiveX 控制項，而無須系統管理權限或複雜的組態。在前一版的 Windows 中，要達到此層級的控制項管理較為困難，而過去可用的解決方案，則通常附帶有極多的限制，或者會增加管理上的成本。AxIS 提供企業另一種工具，可以在電腦系統上為終端使用者提供最低權限的方法，讓終端使用者不需要系統管理員的權限，即可實作標準使用者模式。Windows Vista 讓 IT 系統管理員再次掌握控管權，由企業選擇在環境中可信任的 ActiveX 控制項，而非由終端使用者來選擇。

Rob Campbell 是 Microsoft Federal 小組的資深技術專家。Rob 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。
Joel Yoker 是 Microsoft Federal 小組的資深顧問。Joel 專門負責為美國聯邦政府客戶開發及部署安全性解決方案。


 編輯的話: 第六階層
編輯的話
第六階層
Joshua Trupin

您是否曾經覺得很空虛？ 有沒有曾經獨自坐在辦公桌前發呆，思考宇宙中到底是否有其他的生命？還是根本就沒有？或許您不曾經歷過這樣的事件，特別是如果您的收件匣跟我的一樣 -- 已經塞到爆了。
無論如何，我最近體驗了這樣的折騰，所以覺得我需要多與外界聯繫。於是我登錄了一個商業性質的社交網站，然後開始新增連絡人 -- 包括所有曾經共事的人、曾經向他們取得文章的人，或是在研討會中一起聊過的人。在短短的一週內，我的清單上就出現了 58 位連絡人。真棒！
但是這僅涵蓋第一階層。到了第二階層 -- 若包括我相識的人所相識的人 -- 我就會有超過 3,500 位朋友。當然，由於這 3,500 位連絡人也都有他們相識的連絡人，所以我的第三階層連絡人便暴增到 277,000 人。我使用 Excel 掐指一算：假設每一個人平均都有 50 位連絡人，到了第六階層的範圍，我的連絡人名單將超過 340 億耶。而且還包括大明星凱文貝肯呢！實際上，我所認識的人數將會超過地球上的總人口。我赫然發現世界變得很擁擠，完全不空虛。
但是這又導致另一個問題的浮現。我要如何才能維持與這些人的關係？歡迎各位提出意見。您是否有加入這樣的社交/商務網站？您是如何篩選連絡人，以區分想要接觸的人與想要避開的人？請造訪 TechNet Magazine 部落格，告訴我們您對於此棘手問題的看法。
如果您對於 Web 2.0 網路不是很清楚，別怕。本月的 TechNet Magazine 將協助您充分發揮 Exchange Server 來提升通訊能力。其中有五篇文章都有豐富的知識，可以讓您延伸組織的訊息涵蓋範圍。
使用 Outlook Web Access 進行智慧卡驗證，正是本月的焦點主題之一。授與公司資源的存取權之前先要求實體的驗證方式，是一項理想的機制，而智慧卡就是可以隨時隨地實現此機制的關鍵。我們還會探索 Exchange Server 的嚴重損壞修復功能，如何使用 SharePoint 在 Exchange Server 2007 中取代公用資料夾，以及如何以 Windows Mobile 6 加強行動裝置的安全性。本月當然也少不了 Exchange 佇列問題與解答，其中含有各種與訊息傳遞系統相關的內容。哇，剛剛又有三人加入我的網路。我該去看看是否要打個招呼，或假裝我在睡覺。
—Joshua Trupin

感謝下列 Microsoft 技術專家： Kristian Andaker、Chris Corio、Jim Harrison、Chad Jones、Michael Lee、Shawn McGrath、Michael Murgolo、Eric Perlin、Michelle Rutzer、Gavriella Schuster 及 Jim Truher。


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

監控遠端連線
RecordTS
www.tsfactory.com
您是否曾希望自己能隨時監看終端機伺服器或遠端桌面工作階段？或許您是想要知道在網站發生問題之前，遠端桌面工作階段中到底在做什麼。或許您的終端機伺服器有問題，但一直無法複製問題。也或許您擔心有關智慧財產權的安全性。或者您需要快速記錄或呈現出您在測試環境中設定 SharePoint® 伺服器的方法。如果您符合上述任何一項情況，就應該試試 TSFactory 的 RecordTS (TSFactory 是由 Microsoft 終端機服務的 MVP：Cláudio Rodrigues 所成立)。
RecordTS 有兩種版本：終端機伺服器 (Terminal Server) 和遠端桌面 (Remote Desktop)。至於哪個版本適合自己使用，必須根據您要監控的連線類型而定。正如其產品網站所宣稱，RecordTS 可做為終端機伺服器或遠端桌面工作階段中的「安全監控攝影機」。這個軟體基本上扮演著終端機服務和一般使用者工作階段之間的 Proxy 角色，可用來記錄工作階段中的所有動作和採取的行動。
直覺式的安裝採用簡易的精靈導引，只要把應用程式指向您要用來儲存工作階段的資料目錄即可。應用程式安裝有 MMC 嵌入式管理單元 (可供您設定服務)、RecordTS 服務，以及可觀看工作階段記錄的工作階段播放公用程式。開啟 MMC 嵌入式管理單元後，用滑鼠右鍵按一下 Service 資料夾，就會出現屬性畫面，您可以在其中進行各種設定，像是要執行服務的通訊埠 (若您已將終端機服務工作階段移至非標準通訊埠，則本設定十分有用)。在 [儲存 (Storage)] 索引標籤上，您可以將 [預設儲存資料夾 (Default Storage Folder)] 設定為本機資料夾或 UNC 路徑。
您也可以設定已儲存工作階段的目錄結構。例如，您可以使用網域、使用者、日期和時間，來組織已儲存的資料。如果您把工作階段儲存在本機磁碟中，那麼這或許是最重要的設定項目：您可以告知服務若磁碟空間不夠時該如何處理。您可以選擇不允許新連線，並中斷目前的工作階段連線 (這適用於安全性需求極高的使用者)，或者亦可選擇關閉工作階段記錄 (若您不想中斷系統的運作，即可採用這個選項)。
在 [安全性 (Security)] 索引標籤下，您可以指定是否想要選取某個現有憑證，或者建立自我簽署憑證，來數位簽章所有記錄下來的工作階段。若您計劃使用此工具進行稽核或責任歸屬用途，最好這麼做。在 [使用者 (Users)] 索引標籤上，您可以指定哪些使用者的工作階段需要記錄，哪些不需要記錄。
整體來說，RecordTS 對於安全性和稽核工作而言，是價值難以估計的重要工具，其用途相當廣泛，例如可允許您記錄一個基本操作指南的簡報。對我而言，這的確是我工具箱內的法寶之一。

價格： RecordTS Remote Desktop Edition 的售價為 $495 美元起。RecordTS Terminal Services Edition 的售價則為 $995 美元起。

主機監控
Advanced Host Monitor
www.ks-soft.net
若您的工作需要提供任務關鍵之基礎架構的作業支援，那麼有一樣東西絕對少不了：良好、可靠的主機監控程式。即使您已經擁有堅若盤石的硬體設備，以及穩固可靠又不會出錯的應用程式，您仍然需要功能完備的主機監控程式，來告訴您容錯/備援的系統何時應該啟動。
KS-Soft 的 Advanced Host Monitor 共有 58 種不同的測試方法，以及 30 種警示方法。您可以用來檢查諸如處理程序資訊、使用者工作階段、平均負載、記憶體使用率等等。該應用程式提供的檢查包括 Windows® 專用測試、Linux/UNIX 測試，以及獨立平台測試。Linux/UNIX 測試和 Windows 測試不同，前者必須在用戶端上安裝遠端監控代理程式。
此外還有 Windows Management Instrumentation (WMI) 監控測試。您可使用內嵌式 WMI Explorer 來瀏覽正確的查詢語法，以便讓您輕鬆導覽並選擇適當的項目，同時執行查詢來確認可以取得您所需的資料。
Advanced Host Monitor 還有許多資料庫相關的測試，例如 ODBC 查詢測試，其中可以驗證 ODBC 資料來源的可用性、執行查詢，並使用已知數值確認結果。您也可以檢查主機對於 SQL Server™、MySQL、Oracle、Postgres、Sybase 及 Interbase 資料庫伺服器等傳入工作階段的接受能力。
也有許多磁碟和檔案相關測試，皆可幫助您密切注意可用空間、配額、資料夾或檔案可用性，以及 UNC 分享的可用性。此外，還有標準的網路相關測試：一般 TCP/UDP 檢查、郵件測試 (針對 SMTP、POP3 及 IMAP)、郵件轉送檢查、HTTP 內容和計時測試等。您也可以建立監控測試的相互依存性，以便安排階段式的檢查，這是很好用的選項。測試更可以根據定期和不定期的項目排程，以便您自行安排詳細的測試模式。
警示方法包括傳送訊息到 SMS、ICQ、e-mail、事件記錄或快顯視窗。這些方法亦可觸發其他事件，例如啟動或停止服務、重新啟動電腦，或者執行外部程式。
Advanced Host Monitor 的專業 (Professional) 和企業 (Enterprise) 版本，都有提供 KS-Soft IP 工具：一組 19 個 TCP/IP 相關的網路公用程式，其中包括通訊埠/通訊協定掃描器，以及 SNMP 陷阱看守員，以便您接收和處理 SNMP 陷阱訊息。此外，這兩個版本都有記錄分析器和報告元件，可讓您分析歷史監控資料，以便掌握正常運行時間報告和效能分析的趨勢。
程式介面本身則提供絕佳的多重測試同步快速導覽功能。此產品可以讓您輕鬆監控主機、掃描問題。
價格： 企業版為 $599 美元。 專業版為 $275 美元。

清理磁碟
WinDirStat
www.windirstat.info
就像您的住家或公寓一樣，檔案儲存空間經過一段時間也會變得凌亂，有些曾經有用的東西，現在或許只是在佔用寶貴的空間而已。其實只要稍做清理，就有一定的效用；但是檔案空間不像住家，目錄樹結構無法提供明確的視覺提示，告訴您應該要從哪裡開始移除雜物。幸好有一種很棒的視覺化工具，可以幫助您看出哪些檔案佔用了環境中的空間。
GPL 程式 WinDirStat 是一項 Windows 工具，靈感源自 Linux KDE kdirstat，可透過一組不同色彩的方塊，來顯示出所選取磁碟上的檔案。方塊的大小代表檔案大小，因此您可以輕鬆找出不需要使用又佔空間的 ISO 或 ZIP 舊檔案。
選取本機磁碟 (或者多個本機磁碟) 之後，程式會掃描目錄樹，並在記憶體中建立檔案的地圖。接著會在 GUI 底端的窗格內，顯示出視覺化的圖像。按一下窗格內的任一彩色方塊，即可在頂端窗格中，以如同 Windows 檔案總管的畫面導覽至檔案位置。頂端的窗格中會提供好用的資料，例如檔案大小、上次檔案修改日期，以及其他屬性。另外，您可以看到該檔案在子目錄中所佔用空間的百分比。
最酷的是，不同的檔案類型會使用特定的色彩，只要在右上方按一下偵測到的檔案類型，就可以在底端窗格內反白顯示所有該類型的檔案。這項功能可以靈活運用，例如，您可以找出使用者隱藏在檔案伺服器上的所有 MP3 檔案。您也可以看到這些檔案在該硬碟分割區內所佔用空間的百分比。
價格：可免費下載。

書評
Enemy at the Water Cooler
syngress.oreilly.com
幾乎所有企業都需要網際網路連線，且大多數企業也都發現，即使資訊基礎架構內部已經和外部網路隔離，網外仍經常有人試圖入侵，因而產生相對的危險性。不過，許多企業忽略了一項組織內部更具破壞力的潛在威脅。這些稱之為內部人士所代表的風險，在 Brian Contos 所著的 Enemy at the Water Cooler :Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures (Syngress, 2006) 一書中有完整的說明。
Contos 提供了過去在公司所見聞的真實攻擊和衝擊事件。他表示安全性是持續不斷的過程，其中涉及人員、處理程序和技術的整合。他藉由本書，說明企業安全性管理 (Enterprise Security Management，ESM) 軟體解決方案如何能夠降低涉及內部人士之安全性威脅的力量。
身為 ArcSight 公司的安全室主管，Contos 在書中十分仰賴公司自創的 ESM 軟體解決方案，但是這並不會因而減低本書的整體價值。書中雖然缺乏深入的技術說明，但是看過其他公司的失敗經驗，以及了解 ESM 解決方案在減少內部攻擊方面的實作效用後，倒是可以了解如何強化自身企業的安全性。
在背景說明章節＜Cyber Crime and Cyber Criminals 101＞中，Contos 簡要說明部分需要提防的不同類型攻擊者，及其攻擊動機。書中還提供某些攻擊技巧的簡要對照，例如緩衝區溢位、程式碼封包，以及 Warhol 威脅。
下一個章節則深入探討內部威脅的特點，包括內部人士破壞企業的方法、風險管理的概念，以及如何從技術層面解除威脅。其中的技術觀點提供最低權限、強化驗證、存取控制，以及事件偵測和管理等看法的簡介。透過這個單元的舖陳，接著就進一步討論 ESM 軟體解決方案。再次說明，本書大多僅討論 ArcSight 產品，但其主要功能的分析仍適用於所有系統。
書中有提出多個具代表性的產業和環境案例，並詳細說明不同類型的內部威脅，以及找出威脅的方法 (有些情況下還包括如何因應威脅)。這些個案研究或許對於您所在企業的情況有所啟發，也或許能做為解決方案，減低在您環境中發生內部攻擊的風險。
價格： $49.95 美元。

歡迎來信「工具箱」單元
若希望在此專欄中看到您喜好之工具或公用程式的介紹，請寫信給作者，電子郵件地址為：tntools@microsoft.com。

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


 SQL 問題與解答: 深入探索叢集、意外當機、SA 帳戶等
SQL 問題與解答
深入探索叢集、意外當機、SA 帳戶等
由 Nancy Michell 編輯

問：我需要進一步了解叢集的運作方式。我們的環境將包含執行 SQL Server™ 2005 的 64 位元 Windows Server® 2003、SQL Server Reporting Services (SSRS) Web 伺服陣列 (一種報告伺服器擴充部署)、SSRS TempDB Catalog 伺服器，以及經由連結伺服器提取協力廠商資料庫之資料的 SQL Server，並將儲存 SSRS 的資料。
我們想要由 3 個節點構成的「主動/主動/被動」叢集。Node1 為主動節點，它會儲存從協力廠商資料庫提取的資料。Node2 為主動節點，它會儲存 SSRS Catalog。Node3 為被動節點，它是 Node1 或 Node2 的容錯移轉節點。您可以幫忙嗎？

答：很遺憾，在參照到 SQL Server 叢集時，有太多人被「主動/主動」和「主動/被動」的術語所誤導。他們以為 SQL 叢集可支援在多部伺服器之間擴充一個資料庫或 SQL 執行個體。其實根本不是這麼回事。在 SQL Server 上，並沒有「主動/主動」資料庫或執行個體這種東西。「執行個體」是指有相對應資料庫的 SQL Server 安裝。每個 SQL Server 執行個體的叢集一律為主動 (1) 到被動 (n) (請注意，n 值的範圍是從 1 到 7，視您的 SQL Server 版本而定)。因此稱為容錯移轉叢集。
了解這一點之後，就可以開始考慮在一組節點上安裝容錯移轉叢集的多個執行個體。例如，有三個實體伺服器全部都使用共用磁碟，它們可以在 Node 1 具有一個預設為主動的執行個體，在 Node 2 具有一個預設為主動的第二個執行個體，兩者均可容錯移轉至 Node 3。這兩個執行個體完全分開；它們不共用資料，也不是「主動/主動」。它們都是「主動/被動」，且共用相同的容錯移轉執行個體。如果兩個執行個體都容錯移轉至 Node 3，則如何得知它是否會承受不了負載，將成為日後需要觀察和了解的挑戰。容錯移轉的設計是仰賴容錯移轉的同等處理能力。在正常操作之下，如果尖峰負載需要兩個節點才能處理，則在正常指派給兩個節點的尖峰負載之下，Node 3 不太可能存活 (無法負荷)。
也就是說，由於執行叢集的硬體成本考量，我們知道一般會考慮到兩個主體節點應該不會同時發生問題而強迫單一節點承受全部負載。了解這一點之後，通常會做出的商業決策將是承擔這樣的風險，而不會購買雙倍的裝置以實現 100% 容錯移轉容量。
還好，有一些好消息：SQL Server 2005 提供更多高可用性 (HA) 選項，包括比叢集更快速容錯移轉的替代方案，甚至表示可以複製資料 (叢集仰賴單一 SAN)。這些選項包括鏡像、點對點複寫等。有了這些新的替代方案，就有更多選項可以滿足各種類型的需求，包括可合併許多 HA 功能的選項。
可供下載的 Microsoft® Cluster Configuration Validation Wizard (ClusPrep)，可以取代以前的 Hardware Certification List (HCL) 測試，該測試以往可能需要花費數個月驗證全部組態之後，才能認定它在叢集之下是否為「可支援的」。如今把硬體驗證工具交到 DBA 手上，將可以進一步降低備妥合格硬體的成本 (包括時間和金錢)。它甚至可以在一個叢集節點集內驗證和部署異質硬體。

問：我其中一部機器上的刪除程序似乎當掉超過 12 小時。它並未遭到封鎖。查看最慢的查詢計劃，發現有一個觸發程序執行 87,327 秒，因此我假設程序是在該觸發程序上當掉。我如何得知究竟是哪一個陳述式當掉？

答：很可能是觸發程序內的迴圈基於各種原因而未結束。如果當掉時間很久，而您想要知道是哪一個陳述式在執行，請執行 [圖 1] 的程式碼。它會告訴您目前正在執行的是哪一個陳述式，而這就是造成機器當掉的那個陳述式。
Figure 1 尋找目前正在執行的陳述式 (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

問：我需要支援透過防火牆的交易式複寫。發行者和散發者位於防火牆外，訂閱者則位於防火牆內。訂閱者是設定為在 1433 接聽，而這些是我的電腦名稱：發行者：PUBMACHINE，散發者：DISTMACHINE，訂閱者：SUBMACHINE。我需要開啟哪些通訊埠，才能讓初始快照集和發行集發送成功？

答：如果您是使用發送訂閱，則開啟 SQL Server 通訊埠 (以您的情況為 1433) 應該已足夠，因為散發代理程式將在散發者電腦上執行 (在防火牆外)，並且對快照集代理程式所產生的快照檔案可能具有本機存取權。但如果您使用提取訂閱，則在訂閱者電腦上執行的散發代理程式將需要透過防火牆來存取快照集檔案。以下是您可以考慮的選項。
假設已經可以從防火牆外的檔案共用來存取快照集檔案，您可以透過防火牆開啟 Windows® 檔案共用埠，使得在防火牆內執行的散發代理程式可以存取外面的快照集檔案 (不過要注意這對於基礎結構的其他部分可能會有安全隱憂)。請注意，如果您已設定本機路徑做為預設快照集位置 (SSMS 預設值)，則您需要使用散發代理程式的 /AltSnapshotFolder 選項來覆寫快照集檔案選取位置。
您也可以設定複寫來使用 FTP 傳送快照集檔案 (為此，您需要開啟通訊埠 21)。

問：我想知道在 SQL Server 2005 中停用 SA 帳戶是否有任何缺點，以及停用 SA 是否真的可以提高安全性。此問題是否有白皮書可供參考？

答：在新的 SQL Server 2005 安裝上，當未啟用混合模式時，根據預設，會停用 SA 帳戶，並且會為它產生一個隨機密碼。您也可以自行將其停用。並沒有它的白皮書，但在最佳作法文件中有討論到停用及重新命名登入。
如果您希望自己不要破壞 SA 帳戶，也可以將它重新命名。只要記住，如果要啟用一個已停用的帳戶，就應該為它設定新密碼。
關於這樣做是否真的能提高安全性，只要記住停用帳戶之所以能夠增加安全性，是因為停用帳戶之後，猜測密碼的行為根本無效。不論駭客或病毒有多少時間，對已鎖定帳戶進行暴力破解攻擊是不會成功的。重新命名或停用 SA 會中斷需要使用 SA 帳戶進行連線的應用程式。無論如何，尋找並更正或刪除這些應用程式才是首要任務。如上所述，在重新啟用帳戶之前，不能用它來連接到資料庫。還有，由於驗證程序會更快失敗，嘗試對受攻擊系統造成的負荷也將會減輕。

問：我其中一個較大的線上交易處理 (OLTP) 資料庫含有一個記錄檔，它是資料檔的兩倍大。我曾經試著使用下列命令使記錄檔減為合理大小，但它還需要進一步縮小：
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

答：您應該將備份資料庫變更為備份記錄檔陳述式。另外，您也可以使資料庫成為簡單修復模式，並發出 shrinkfile 陳述式。在完成記錄檔縮小之後，將資料庫設為其先前的修復模式並備份資料庫。如果它仍未縮小，請檢查並確定您沒有開啟的交易 (使用 dbcc opentran)。下列知識庫文章提供詳細資訊：support.microsoft.com/kb/907511。

問：如果在排定的 SQL Server Agent 作業期間發生容錯移轉，在容錯移轉之後，該作業會發生什麼情況？我需要手動重新啟動它嗎？

答：是的，如果您沒有備妥一些其他程序，就需要手動啟動它。如果您不想要手動重新啟動作業，則可撰寫指令碼於作業完成時更新資料表。如果值 = 1，表示已執行作業；其他值表示作業未完成，且稍後會有第二個作業，以發出啟動命令。因此，如果作業執行期間發生容錯移轉，您就必須重新執行該作業，但是藉由撰寫指令碼，就可以確保那些必須在下一個工作天之前完成的重要作業，能夠有備援的機制。
提示：升級與 DBCC UPDATEUSAGE
您是否要從 SQL Server 2000 升級到 SQL Server 2005？
如果是，請確定您在資料庫升級之後有執行 DBCC UPDATEUSAGE。
DBCC UPDATEUSAGE 會在目錄檢視中報告並更正頁面和資料列計數的錯誤。這些錯誤需要更正，因為它們會造成 sp_spaceused 系統預存程序傳回不正確的空間使用量報告。在 SQL Server 2005 中，一定會正確維護這些值，因此這些資料庫絕對不會發生不正確計數。不過，升級到 SQL Server 2005 的資料庫可能包含無效計數，因此您應該在升級之後執行 DBCC UPDATEUSAGE。
以下是 DBCC UPDATEUSAGE 的運作方式。它會在資料表或索引中更正每一個資料分割的資料列、使用的頁面、保留的頁面、分葉頁面和資料頁計數。如果系統資料表沒有錯誤，DBCC UPDATEUSAGE 就不會傳回資料。如果發現錯誤並予以更正，且您未使用 WITH NO_INFOMSGS，則 DBCC UPDATEUSAGE 會傳回系統資料表中更新的資料列和資料行。
DBCC UPDATEUSAGE 也可以用來同步處理空間使用量計數器。因為 DBCC UPDATEUSAGE 在大型資料表或資料庫上需要多花一點時間，因此通常只有當您懷疑 sp_spaceused 傳回不正確值時才要使用它。請注意，sp_spaceused 可以在傳回資料表或索引的空間資訊之前，接受執行 DBCC UPDATEUSAGE 的可選用參數。
在 SQL Server 2005 中，DBCC CHECKDB 已增強功能，會偵測到頁面或資料列計數何時變為負數。偵測到負數時，DBCC CHECKDB 會發出警告，並建議執行 DBCC UPDATEUSAGE 來解決此問題。雖然看起來是將資料庫升級到 SQL Server 2005 造成此問題，其實是在升級程序進行之前就已經造成無效的計數。
下面的範例將告訴您，如何為目前資料庫中的所有物件更新頁面或資料列計數或是兩者。下列命令指定 0 為資料庫名稱，且 DBCC UPDATEUSAGE 報告目前資料庫的更新資訊：
DBCC UPDATEUSAGE (0);
GO
例如，若要針對 AdventureWorks 更新頁面或資料列計數或是兩者，並隱藏參考訊息，您需要執行類似下面的命令，其中會指定 AdventureWorks 做為資料庫名稱，然後隱藏所有參考訊息：
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
如需詳細資訊，請搜尋《SQL Server 線上叢書》的＜DBCC UpdateUsage＞。

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 公用程式焦點: SMSMap
公用程式焦點
SMSMap
Jeff Tondt
下載本文程式碼: UtilitySpotlight2007_07.exe (2477KB)

一張圖片勝過千言萬語。這句耳熟能詳的諺語，在這裡指的是透過一張圖片，就能詮釋出複雜的故事背景。或者也可以這麼說：一張簡單的圖片，遠比大量的文字更具影響力。此外，圖片也能適切地描繪出想像的結果，以便快速吸收大量資料。
對於像我這樣的 System Management Server (SMS) 玩家而言，若能在單一圖片中清楚看到整個 SMS 階層架構，將有助於我了解整個基礎結構配置的方式。或許您可以利用這樣的圖片，向管理階層顯現出 SMS 移轉計劃的前後差異。在某些疑難排解個案中，這樣的圖表對於尋找解決方案，或者至少在尋求他人協助時，確實有很大的幫助。當然，身為一位有責任感的 SMS 管理員，您必定還有諸多理由而必須記錄系統階層架構。

製作架構圖
您當然也可以自行繪製出類似的圖表。只要捲起袖子，手工繪出 SMS 階層架構，然後再用雙手記錄網站上所有設定內容，也能辦得到。但若您使用 Microsoft® Operations Manager (MOM) 來監控 SMS server，就可以利用它來繪製出您的階層架構。不過我得在此說明，MOM 並非好用的圖片編輯器，當然也無法為您記錄網站設定。市面上或許有其他方法或現成好用的工具，但是到目前為止，我還找不到任何一種能夠建立出漂亮的圖片，又能記錄網站設定的工具 (至少至今仍無法讓我滿意)。
因此，我決定自行製作工具。而 SMSMap 1.0 也就此誕生。SMSMap 屬於 Visual Basic® .NET 應用程式，在 SMS SDK 中使用 SMS managed 程式庫，並可透過 COM 將 Microsoft Visio® 自動化。公用程式查詢目標的 SMS 站台伺服器，然後建立視覺效果吸引人的 Visio 圖表，並且將網站設定匯出為 XML 檔案。由於 XML 是最適合記錄網站設定的方式，因此選擇此語言撰寫。此外，我還選擇顯示 SMS 的角色，而不僅只顯示與其他 SMS Server 相關的實體伺服器。此舉可允許透過 Visio 層級修補圖表，以便透過各種觀點來看 SMS 階層架構。
圖 1 弧形格式
圖 1 弧形格式
目前這個程式共有六種不同的 Visio 圖表格式可供選擇。例如，[圖 1] 使用弧形格式顯示一個非常簡單的 SMS 階層架構，而 [圖 2] 則使用流程圖格式顯示相同的階層架構。此公用程式即使在大型階層架構中，仍可運作良好，但我希望儘量能將作業簡化。
圖 2 流程圖格式
圖 2 流程圖格式
總有一天，SMSMap 極有可能持續發展，並且能夠記錄所有網站設定。但目前則只能記錄 SMS 站台角色及所有界限。輕輕鬆鬆就能將許多網站設定匯出為 XML 檔案。

使用 SMSMap
SMSMap 的來源程式碼以及安裝檔案位於 TechNet Magazine 網站。安裝時，只要執行 SMSMapSetup.msi，即可帶領您逐步完成安裝程序。請記住，SMSMap 需要使用 Visio，因此必須先安裝 Visio。安裝完成後，請執行 C:\Program Files\Microsoft\smsmap\smsmap.exe (除非您將檔案安裝到非預設的其他位置)。
您可以從任何電腦上執行 SMSMap；不一定要從 Site Server 執行 (況且大多數 SMS Site Server 未必安裝有 Visio)。輸入您希望展開查詢的 SMS Site Server 名稱。如果您要查詢整個階層架構，則有可能是中心站台，或者可能是任何子系主要 Site Server，但若是後者的情況下，就只能取得該子系主要站台以下的階層架構。接下來，輸入具權限可使用 domain\username 格式查詢 SMS 的帳戶，然後輸入該帳戶的密碼 (密碼不會顯示出來，因此即便有其他人在場亦可執行)。
六個選項按鈕可供您選擇配置方式，而您也可以選擇是否允許或防止 SMS 角色顯示於圖表中。這些核取方塊位於 [選項 (Options)] 索引標籤下。按下 [繪圖 (Draw)] 按鈕即可開始使用該公用程式。一開始會先檢查是否有 Visio 可供使用，接著查詢指定的 SMS primary site server，並將物件新增至 Visio 圖表中。Visio 圖表在 SMSMap 處理物件的過程中，或許看起來不美觀，但最後公用程式會依照您一開始所指定的格式整理圖表。
深入探討
現在，您已經知道為何要使用 SMSMap 來記錄 SMS 階層架構，也了解其使用方法。如果有人還想要更進一步發揮開發人員的專長，我們不妨來深入了解這個公用程式的運作方式。
SMSMap 會使用 Managed SMS Site Server 介面來收集 SMS 資訊，而 Visio 主要 Interop 組件會產生 Visio 圖表，以進行所有必要的圖形配置。SMS 2003 SDK 3.1 版包含最新版本的 Managed SMS Site Server 介面。這組 Managed 介面可讓您透過任何支援 Microsoft .NET Framework 的程式語言或應用程式，來連接和設定 SMS Site Server。
這些介面使用 System.Management 命名空間，以透過 Windows® Management Instrumentation (WMI) 與 SMS 提供者互動。若要使用這些介面，您必須使用 .NET 相容的程式語言來開發自己的應用程式 (例如 C#、Visual Basic .NET 等)，並參考 .NET 組件在 SMS SDK 中所提供的 Microsoft.SystemsManagementServer.Automation.dll。
.NET Management 類別可以有效整理許多 WMI 物件模型的特性，以呈現出一致、物件導向的模型。WMI 連接、物件列舉、方法執行、物件刪除、物件擷取和事件補捉的基本工作，全部都能透過 .NET Management 類別達成。

Visio 主要 Interop 組件
主要 Interop 組件可讓您利用 Managed 程式碼，以程式設計的方式來控制如 Visio 等的 COM 應用程式。Visio 主要 Interop 組件可讓您將 Visio 功能整合與延伸至 Managed 應用程式中。
如果您的電腦上已安裝 .NET Framework，當您後續安裝 Visio 時，安裝程式就會將 Visio 主要 Interop 組件加入您電腦的全域組件快取 (Global Assembly Cache，GAC) 中。您可以從 Managed 應用程式加入 Visio 主要 Interop 組件的參考。
將參考加入專案之後，即可從 Managed 應用程式開始處理 Visio 物件。Visio 具有可擴充的物件模型，可提供一組類別、介面和列舉，以便透過程式設計的方式建立圖表。

程式流程
現在我已經介紹了 Visio 和 SMS 的主要元件介面，接下來則要說明公用程式本身的流程。
使用 Managed 介面的第一步，是連接到 SMS 提供者。只要建立一個 SMSProvider 類別的新執行個體，即可完成第一步。就內部而言，此類別會找出指定之 Site Server 的 SMS 提供者，並使用固定的一組認證與其連接。如果提供者位於本機電腦上，連接到提供者時就會以目前登入的認證來取代提供的認證。雖然您可以在 SMS server 上執行 SMSMap，我仍建議在另一個已安裝 Visio 的工作站上執行 SMSMap。大多數的 SMS site server 基於諸多因素考量，並未安裝 Visio。
當您在 SMS 站台上透過 SMSProvider 類別存取資料時，安全性權限會視為您使用 SMS 管理員主控台 (SMS Administrators Console)。也就是說，例如您嘗試透過 SMSProvider 組態某個 site server 的設定，您用來連接到提供者的帳戶權限，必須和使用系統管理員主控台的權限相同。
SMSProvider 類別提供 GetSiteSettings 方法，以便您取得目前站台 (也就是提供者所屬站台) 或者任何具有特定站台碼的網站設定。[圖 3] 中的程式碼片段顯示 SMSMap 如何連接到目標 site server 的提供者。使用者認證應該以 Domain\User 格式傳遞。您也可以指定 "." 來表示目前使用的電腦。[圖 3] 中的程式碼亦有助於在 UI 中顯示結果，以及進行記錄。
Figure 3 GetSiteSettings 程式碼片段 (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
下一步是設定 XML 檔案，以針對目標 site server 收集和記錄 SMS 資訊，如 [圖 4] 所示。
Figure 4 建立 XML 檔案 (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
接下來，必須在 Visio 圖表中繪製目標站台，並且於 UI 和記錄中更新，如 [圖 5] 所示。
Figure 5 在 Visio 中繪製站台 (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
若要在目標站台下描繪整個階層架構，就要執行上述用來查詢 SMS 以及在 Visio 中繪圖的基本程式碼。這是一個稱為 Level 的函數，藉由重覆呼叫此函數，即可確保不論階層有多大，都能查詢到所有的子站台。Level 會收集 SMS 站台資訊並記錄於 XML 中，也會收集目標站台底下之每個子站台的 UI 和記錄檔。最後，[圖 6] 顯示如何利用公用程式啟動時的格式選項，將 Visio 圖表格式化。然後關閉 XML 和記錄檔。
Figure 6 結論 (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

這只是一切的開端
當然，這一切才剛剛開始，尚有許多可改善的空間。裝置管理點 (Device Management Points) 需要進一步研究調查，因為我在 SDK 中找不到。另外還可以加入許多其他的網站設定，以便完整記錄站台。或許還需要花更多的心力來加入更廣泛的 Visio 配置設定，好讓大大小小的階層架構看起來更漂亮。每個配置類型在嘗試建立有效的顯示結果時，都有其困難之處。此外，加入對 System Center Configuration Manager 2007 的支援，當然也是接下來十分重要的步驟。但即便這個 SMSMap 甫推出第一版，仍可以幫助 SMS 管理員顯示整體結構，並可以使用 Visio 層級與透明度來嘗試一些假設案例。
如果您下載來源程式碼，即可擴充公用程式以符合您個人的需求。我已經在 Windows XP SP2 with Visio 2003 和 Windows Vista™ Enterprise with Visio 2007 上測試過 SMSMap。如果您對於此公用程式有任何建議，歡迎寫信給我，我的電子郵件是 jeff.tondt@microsoft.com。

Jeff Tondt 是 Microsoft Consulting Services 的資深顧問 (Senior Consultant II)，專精的領域包括系統管理、自動化以及修補程式管理。他是 SMS 專家，連絡方式為 jeff.tondt@microsoft.com。


 IT 如何運作: RPC 錯誤的疑難排解
IT 如何運作
RPC 錯誤的疑難排解
Zubair Alexander

若您使用 Windows 伺服器平台已有多年，遠端程式呼叫 (RPC) 錯誤對您而言應該是家常便飯了。碰到的錯誤可能包含 RPC 伺服器不存在，或者已經沒有結束點可用了，甚至提出其他難以理解的警訊。如果您對於這些訊息也感到困惑，請繼續閱讀本文。我將
在文中探討各種常見錯誤、可用來辨識 RPC 錯誤的多項技巧，以及討論解決特定問題的方法。不過在討論特定 RPC 錯誤和解決方法之前，讓我們先針對 RPC 的相關名詞打好基礎。

什麼是 RPC？
RPC 是一種處理程序之間的通訊 (IPC) 方法，由用戶端與伺服器之間用於通訊。簡單地說，RPC 通常會由用戶端電腦上的程式使用，以執行伺服器電腦上的程式。例如，Microsoft® Outlook® 用戶端會透過 RPC 與 Microsoft Exchange Server 進行通訊。用戶端電腦會在訊息中加上某些引數，一併傳送給伺服器電腦。伺服器會向用戶端回覆訊息，其中會包含執行程式的結果。
此處理程序中不可或缺的就是結束點 -- 亦即電腦的名稱、單一連接埠或整組連接埠，讓伺服器監控傳入的用戶端要求。更具體而言，這是 RPC 使用的伺服器處理程序的特定網路位址。
結束點對應程式屬於 RPC 子系統的一部分，負責回應用戶端要求，以解析動態結束點。在某些情況下，結束點對應程式亦負責將結束點動態指派給伺服器。
另一項重要的 RPC 元件是定位服務 (Locator Service)，其中會維護網路上的 RPC 服務與伺服器的清單。Windows® 用戶端會經由伺服器訊息區 (Server Message Block，SMB) 連接埠 (TCP 139 和 445) 連線到網域控制站，並透過定位服務搜尋 RPC 服務或伺服器。
多數內建 Windows 服務都使用 RPC 彼此通訊。例如：憑證服務、DCOM、FRS、MSMQ、MAPI 及 Active Directory® 複寫服務等，皆使用 RPC 進行通訊。因此，若 RPC 服務在網路上無法正常運作，或多或少都會發生通訊問題。

RPC 錯誤
現在讓我們來看看您可能在 RPC 服務失敗時所遭遇到的錯誤 (這並非完整的清單)。
當檔案複寫服務 (FRS) 失敗時，可能是「RPC 無法使用」錯誤所導致。若您嘗試對應磁碟機，有可能發生「拒絕存取」錯誤。在使用 Active Directory 使用者和電腦時，可能會出現如下錯誤：「指定的網域可能不存在或無法連線」。登入網域時，可能出現如下錯誤：「系統無法讓您登入網域，因系統的主要網域電腦帳戶已遺失，或者該帳戶的密碼錯誤」。
當 Microsoft Outlook 用戶端嘗試與 Exchange Server 通訊時，RPC 的錯誤可能會導致在用戶端出現令人誤解的錯誤，諸如：「您的登入資訊錯誤」，或者「Outlook 無法登入」。
除了這些錯誤之外，如果 RPC 服務無法使用，可能還會產生其他問題。例如，有可能無法在 [網路上的芳鄰] 瀏覽網域，或者無法開啟 [群組原則] 嵌入式管理單元。
這些只是部分您可能未料到問題會是 RPC 所導致的例子。 事實上還有更多例子，只要是涉及遠端處理程序，RPC 的問題就可能是造成困擾的主因。如此說來，您要如何確知錯誤的根源，更重要的是要如何精準地追蹤錯誤呢？讓我們一起找出答案。

疑難排解
若您懷疑自己的 RPC 服務出現問題，可利用幾種工具來診斷這些問題。
其中一種是 Repadmin 工具。這個程式一般是用來針對 Active Directory 複寫問題進行監控和疑難排解，但也可以用來解決 RPC 結束點對應程式的問題。若要執行此程式，請在命令提示字元中輸入 repadmin /bind。如果有發生 RPC 問題，您可能會看見如下訊息：「終點對應表中無更多可用的終點」。這是代表此問題可能與 RPC 相關的第一條線索。
另一項選擇是使用網域控制站診斷工具 (DCDiag)，這是用來診斷網域控制站相關問題時使用的命令列程式。若您看到的錯誤是「狀態是 1722:RPC 伺服器無法使用」，就表示網域控制站診斷工具剛好發現您有一個 RPC 問題。
有時候在使用 Ntdsutil 時 (一種命令列工具，用來管理 Active Directory 和執行各種維護工作)，若嘗試連線到伺服器就會發生 RPC 錯誤。一般會出現較常見的錯誤訊息，例如：「終點對應表中無更多可用的終點」。再次提醒您，這是代表問題可能與 RPC 服務有關的線索。用來檢查網域控制站的 Group Policy 物件一致性的 Gpotool 工具，也會在 RPC 發生問題時出現類似的錯誤。
在您使用 Dcpromo 工具將 Windows 2000 Server 或 Windows Server® 2003 伺服器升級為網域控制站時，所產生的 Dcpromo.log 也可以顯示出 RPC 的相關問題。例如，倘若升級失敗，請檢查記錄檔。該檔位於 %windir%\debug 資料夾中。列出的錯誤會指出目錄服務無法複寫磁碟分割，或者無法建立物件的訊息。在訊息末端會有一個錯誤碼。以下是可能出現在 Dcpromo.log 中之錯誤訊息的範例：

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
請注意這裡的錯誤碼為 1722，一共在本訊息中出現四次，即指出 RPC 伺服器無法使用。[圖 1] 列出部分錯誤碼及其說明，更詳細的錯誤碼資料位於 msdn2.microsoft.com/ms681386。
Figure 1 錯誤碼及描述 (Close Figure 1)

錯誤碼 | 描述
58 | 指定的伺服器無法執行要求的操作。
1721 | 資源不足無法完成此操作。
1722 | RPC 伺服器無法使用。
1723 | RPC 伺服器忙線中，無法完成此操作。
1727 | 遠端程序呼叫失敗且不執行。
1753 | 終點對應表中無更多可用的終點。

解決 RPC 錯誤
您已經了解如何偵測出部分 RPC 錯誤，現在就讓我們一起看看其解決之道。
Microsoft 用戶端會透過連接埠 135 連接到 RPC 結束點對應程式。接著結束點對應程式就會告知用戶端要求的服務所接聽的連接埠。連接埠號碼會動態指派，且是介於 1024 和 65,535 之間的任意號碼。在您看到如 1753 這種錯誤，告訴您結束點對應程式沒有可用的結束點時，則代表 RPC 結束點對應程式無法針對某服務使用大於 1024 的連接埠。我稍後會進一步探討這個議題。
您首先必須做的，是檢查伺服器上的 RPC 服務的狀態。根據伺服器角色的類型，RPC 和 RPC 定位服務的狀態應該如 [圖 2] 所示。若這兩種服務皆未如圖中設定，請嘗試調整狀態、重新啟動伺服器，然後進行測試，以判斷問題是否已解決。
Figure 2 RPC 服務狀態 (Close Figure 2)

伺服器角色 | RPC 服務 | RPC 定位服務
Windows Server 2003—網域控制站 | 已啟動，自動 | 已停止，手動
Windows Server 2003—成員伺服器 | 已啟動，自動 | 已停止，手動
Windows Server 2003—獨立伺服器 | 已啟動，自動 | 已停止，手動
Windows 2000 Server—網域控制站 | 已啟動，自動 | 已停止，自動
Windows 2000 Server —成員伺服器 | 已啟動，自動 | 已啟動，手動
Windows 2000 Server—獨立伺服器 | 已啟動，自動 | 已停止，手動
確認您的用戶端可以成功 Ping 到有連接問題的伺服器。舉例來說，若您無法與名為 DC1 的伺服器通訊，且該伺服器的 IP 位址是 192.168.1.200，請於命令提示字元中使用以下命令，以確認 DNS 可以正確解析主機 DC1：
Ping –a 192.168.1.200
請確認您使用的是 a 參數和 IP 位址，而非主機名稱。
若一切運作正常，應可取得 DC1 的回應，結果就如 [圖 3] 中的 Ping 回應所示。您或許也注意到，Ping 並不只會解析 IP 位址 192.168.1.200，同時也會解析主機名稱 dc1.contoso.com。這證實了 DNS 名稱解析運作正常，而主機 dc1.contoso.com 的解析恰如預期。
Figure 3 Ping 回應 (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
您也應該確認 Windows XP 或 Windows 2000 用戶端的登錄中，至少包含 [圖 4] 中列於右側窗格內的四個 ClientProtocols。
圖 4 列於登錄中的 RPC ClientProtocols
圖 4 列於登錄中的 RPC ClientProtocols
若缺少任一項目，請如 [圖 4] 所示，新增具有相對名稱和資料型別的字串值。根據預設，會有第五個項目，稱為 ncacn_nb_tcp，這是用來識別 TCP over NetBIOS 做為結束點的通訊協定家族。根據您的設定，ClientProtocols 下方不一定會列出該項目，您可以手動新增以嘗試解決 RPC 錯誤。
在圖中左窗格的 Rpc 資料夾下，分別列出幾個機碼，包括 ClientProtocols、NameService、NetBios 及 SecurityService。若您正好看到名為 Internet 的機碼沒有數值，請嘗試移除該機碼，並重新啟動電腦。這樣可能可以幫您解決問題。不過，請永遠記得在修改 Windows 登錄時要特別小心。
如上所述，RPC 可使用介於 1024 和 65,535 之間的連接埠，因此您必須確認這些連接埠並未受到防火牆的阻擋。若要確認連接埠是否通暢，最簡單的方法就是使用 Port Query 工具。此工具共有兩種型態：一是命令列版本 (PortQry)，二是 GUI 版本 (PortQueryUI)。
PortQry 可以從 Microsoft 下載中心下載。如需詳細資訊，請參閱文章 Portqry.exe 命令列公用程式的說明。該文章內包括 PortQry 狀態報告的簡要說明，以及可用來解決問題的命令範例。請記住，您也可以使用更簡便的 GUI 版本，下載位置為：go.microsoft.com/fwlink/?LinkId=73740。
在使用 Port Query 時，請確保是在未發生 RPC 錯誤的電腦上執行，並且針對具有 RPC 問題的雷腦進行操作。例如，若您想要確認連接埠 135 (由 RPC 結束點對應程式使用) 已開啟，請於命令提示字元中使用 PortQry，如下所示：
portqry -n [servername] -e 135
不論您使用 PortQuery 或 PortQueryUI，都有可能得到如下的結果：
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
最後一行表示連接埠 135 已開啟。否則，最後一行會表示 NOT LISTENING (並未進行接聽)。
若要檢查某範圍內的連接埠，請輸入連接埠編號範圍，中間以半形逗號隔開，如 "135,1024-5000"。

其他解決方案
若您已嘗試上述所有方法，但仍無法解決問題，這裡還有其他選項可供參考。根據您環境中的特定問題，或許可以嘗試下列方式之一，來變更登錄 (等一下！在變更登錄之前，請務必備份系統，特別是登錄，這樣才能在萬一發生錯誤時，將電腦還原到之前的狀態)。
其中一種方法是調整 MaxUserPort，以指定 TCP 可指派的最高連接埠號碼，於應用程式向系統要求使用者連接埠時使用。根據預設，Windows Server 2003 會將 MaxUserPort 值設定為 5000，這表示即使該項目不存在，仍使用 5000 做為最高連接埠號碼。根據您的組態而定，登錄中不一定會有此項目；如果沒有，您可以將此項目加入 [圖 5] 中顯示的位置。
圖 5 登錄中的 MaxUserPort 設定
圖 5 登錄中的 MaxUserPort 設定
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
在修改登錄時，您必須注意是否有任何潛在的副作用，然而這並不容易。如果此值設定為低於 50,000，修改此項目可能會對 Microsoft Exchange Server 產生影響。若 Exchange Server Best Practices Analyzer (BPA) 發現 MaxUserPort 登錄機碼的值小於 50,000，就會顯示警告。Microsoft 建議您將此值設定為 60,000，否則可能導致 Name Service Provider Interface (NSPI) Proxy 發出警告，例如事件 9040。如需詳細資訊，請參閱 Microsoft 文件《MaxUserPort 值太低》。
您也可以調整 TcpMaxDataRetransmissions。TCP 封包預期會從接收端收到通知。如果在計時器過期之前仍無通知，封包就會根據 TcpMaxDataRetransmissions 的次數進行重新傳送。此參數的預設值為 5，但您不妨嘗試 4 甚至 3。請勿使用低於 3 的值。
如果 TcpMaxDataRetransmissions 登錄項目不存在，您可以將其加入登錄中的下列位置：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
如需 TcpMaxDataRetransmissions 的詳細資訊，請參閱 Microsoft 知識庫文件 170359，《如何修改 TCP/IP 重新傳輸等候逾時上限》。
另一個值得一試的登錄值為 TcpTimedWaitDelay。若用戶端使用太多連接埠，則很有可能在 TCP/IP 釋出已關閉的連線之前，造成沒有連接埠可用。這是因為 TCP/IP 在兩個 Maximum Segment Lives (MSL) 結束之前 (代表等待時間狀態)，都不會釋出連線。此外，由於每個 MSL 皆定義為 120 秒，而 TCP/IP 在兩個 MSL 結束前都不會釋放連線，因此 TCP/IP 需要 240 秒 (4 分鐘) 的時間才會釋出已關閉的連線。注意：這是 Windows NT® 中的已知問題，並且已經有 Service Pack 修正此問題。因此現在已不太可能遇到這樣的問題。然而，Microsoft 仍建議調整此設定，做為嘗試解決 RPC 結束點對應程式錯誤的方法，如知識庫文件《如何為 RPC 結束點對應程式錯誤進行疑難排解》所述。
TcpTimedWaitDelay 可加入登錄的下列位置：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
如需 TcpTimedWaitDelay 的詳細資訊，請參閱知識庫文件《Windows NT 用戶端用盡連接埠》。雖然文章中未建議任何特定數值，但您不妨試著以十進位方式將 TcpTimedWaitDelay 減少 60 (秒)，也就是十六進位的 3c。

結論
RPC 錯誤可能是網路中各種通訊錯誤的禍源。幸好有各種創意十足的方式可以解決這些難以捉摸的問題。我在本文中建議的部分工具為內建，但有部分則位於 Windows Server Resource Kit 中。大多數都列於 [圖 6] 中。您可以使用這些工具來偵測 RPC 錯誤的原因和位置，然後利用本文敍述的技巧來解決錯誤。
Figure 6 RPC 疑難排解工具 (Close Figure 6)

工具 | 描述
DCDiag | 分析網域控制站的狀態。
事件檢視器 | 顯示記錄的事件。
Gpotool | 判斷原則是否有效且一致。
NetDiag | 用來測試網路連線能力。
網路監視器 | 監視與擷取網路流量。
Ntdsutil | 提供 Active Directory 管理機能。
PortQry、PortQueryUI | 用來測試 TCP/IP 連線能力。
Repadmin | 診斷 Windows DC 之間的複寫問題。
RPCDump | 通常與網路監視器同時使用。
RPCPing | 用來確認 RPC 連線能力。

Zubair Alexander 是 MCSE、MCT 和 Microsoft MVP，也是 SeattlePro Enterprises 這家 IT 訓練與諮商公司的負責人。他的經歷涵蓋 IT 教育的以下範疇：作家、大學講師、諮商顧問、網路工程師、公開演說家、安全性設計師、系統管理員、技術編輯以及訓練員。Zubair 的連絡方式為 alexander@techgalaxy.net。


 The Cable Guy: 經過 VPN 連線的 IPv6 流量
The Cable Guy
經過 VPN 連線的 IPv6 流量
Joseph Davies

當您在內部網路上開始評估網際網路通訊協定第 6 版 (Internet Protocol version 6，IPv6) 的角色並開始規劃其部署時，您應該要先瞭解 Windows 對於 IPv6 流量如何經過虛擬私人網路 (VPN) 連線進行傳輸的支援。使用 VPN 連線，您就可以延伸您的網路，包含使連結經過公用
網路 (例如網際網路)。VPN 連線均受到增強式驗證通訊協定的保護，以驗證連線使用者的認證，還有各種可保護資料機密性的加密方法。
Windows® XP 和 Windows Server® 2003 都有包含一個 IPv6 通訊協定堆疊，但是許多核心服務和網路元件都沒有支援 IPv6。Windows Vista™ 和 Windows Server 2008 (先前的代號為 "Longhorn") 都有提供完整的 IPv6 支援，根據預設會安裝並啟用。事實上，幾乎所有 Windows Vista 和 Windows Server 2008 包含的網路應用程式和服務，都支援 IPv6。本月，我將研討 Windows Vista、Windows Server 2008、Windows XP 及 Windows Server 2003 對於經過 VPN 連線傳送之 IPv6 流量的支援，其中將涵蓋以網際網路通訊協定版本 4 (Internet Protocol version 4，IPv4) 以及 IPv6 建立的 VPN 連線。

經過 IPv4 網際網路的 VPN 連線
就目前大部分的內部網路而言，VPN 連線都是經過 IPv4 網際網路。[圖 1] 顯示此 VPN 連線類型的 Windows 元件。這些元件是由下列項目所組成：
圖 1 經過 IPv4 網際網路之 VPN 連線的 Windows 元件
圖 1 經過 IPv4 網際網路之 VPN 連線的 Windows 元件
VPN 用戶端 這是初始化遠端存取 VPN 連線至 VPN 伺服器並與內部網路資源進行通訊的電腦。遠端存取 VPN 連線可以讓 VPN 用戶端執行有如直接連線到內部網路的動作。VPN 用戶端可以執行 Windows 的用戶端版本或伺服器版本。
VPN 伺服器 此電腦會接聽是否有遠端 VPN 連線嘗試、強制執行驗證和確認連線條件，以及在 VPN 用戶端和內部網路資源之間路由封包。VPN 伺服器通常會執行 Windows 的伺服器版本，加上 [路由及遠端存取] 服務。
VPN 路由器 VPN 路由器是初始化或接聽網站對網站之 VPN 連線嘗試的電腦。網站對網站的 VPN 連線會連接內部網路的兩個部分。VPN 路由器會執行 Windows 的伺服器版本，加上 [路由及遠端存取] 服務。
VPN 連線 VPN 連線是 VPN 用戶端和 VPN 伺服器之間的邏輯連結，或是由 VPN 通訊協定的封裝所定義之 VPN 路由器之間的邏輯連結。
具備 IPv6 能力的內部網路 此內部網路可以轉送 IPv6 流量，其中可採用原始格式或透過 IPv4 封包。
IPv6/IPv4 主機 此內部網路節點可以傳送與接收 IPv6 流量，其中可採用原始格式或透過 IPv4 封包。
Windows 的 VPN 用戶端、伺服器及路由器，都可以使用下列 VPN 通訊協定來封裝經過 VPN 連線傳送的封包。點對點通道通訊協定 (Point-to-Point Tunneling Protocol，PPTP)、IPsec 上加第二層通道通訊協定 (Layer Two Tunneling Protocol with Internet Protocol security，L2TP/IPsec)，以及安全通訊端通道通訊協定 (Secure Socket Tunneling Protocol，SSTP)。只有 Windows Vista 含 Service Pack 1 (SP1，正在進行 Beta 測試) 以及 Windows Server 2008 才能支援 SSTP。
針對經過 IPv4 網際網路的 VPN 連線，有兩種方法會用於傳送 IPv6：透過 IPv4 封包傳送的 IPv6 封包 (以下將稱為 IPv6-over-IPv4 流量)，以及原始 IPv6 流量。
在本專欄中，對於經過 VPN 連線的 IPv6 流量支援，都會以 VPN 通訊協定和 Windows 版本指出。對於遠端存取 VPN 連線，給定的 VPN 通訊協定和 Windows 版本的組合，即隱含 Windows 遠端存取用戶端以及遠端存取伺服器元件的支援。

IPv6-over-IPv4 流量
在此方法中，遠端存取用戶端或內部網路上的 IPv6/IPv4 主機會使用 IPv4 標頭封裝 IPv6 封包，然後以 IPv4 封包傳送結果。在內部網路上，IntraSite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 轉換技術 (RFC 4214) 可以讓 IPv6/IPv4 節點在僅有 IPv4 的內部網路上交換 IPv6 流量。有了 ISATAP，您就可以在僅有 IPv4 的內部網路上啟用 IPv6 連線，不需要設定或升級現有的路由器即可支援原始 IPv6 定址與轉送。如需有關 ISATAP 的詳細資訊，請參閱 microsoft.com/technet/network/ipv6/ipv6coexist.mspx 的 "IPv6 Transition Technologies"。
[圖 2] 顯示經過 IPv4 網際網路的 VPN 連線傳送 IPv4 封包時的一般封包結構。IPv4 封包會以 VPN 通訊協定的標頭封裝，且視 VPN 通訊協定而定，可能還會有 VPN 結尾。結果會以 IPv4 標頭封裝，以允許封包經過 IPv4 網際網路轉送。
圖 2 使用經過 IPv4 網際網路之 VPN 連線的 IPv4 封包
圖 2 使用經過 IPv4 網際網路之 VPN 連線的 IPv4 封包
對於 IPv6-over-IPv4 流量而言，經過 VPN 連線傳送之 IPv4 封包的內容，是 IPv6 封包。[圖 3] 顯示經過 IPv4 網際網路的 VPN 連線傳送 IPv6-over-IPv4 封包時的一般封包結構。
圖 3 使用經過 IPv4 網際網路之 VPN 連線的 IPv6-over-IPv4 封包
圖 3 使用經過 IPv4 網際網路之 VPN 連線的 IPv6-over-IPv4 封包
對於遠端存取 VPN 連線，經過 IPv4 網際網路的 IPv6-over-IPv4 流量在 Windows Vista、Windows Server 2008、Windows XP SP1 或以上以及 Windows Server 2003 上，均由 PPTP 和 L2TP/IPsec 支援，而在 Windows Vista SP1 以及 Windows Server 2008 上，則是由 SSTP 支援。對於網站對網站 VPN 連線，經過 IPv4 網際網路的 IPv6-over-IPv4 流量在 Windows Server 2008 以及 Windows Server 2003 上，是由 PPTP 和 L2TP/IPsec 支援。

原始 IPv6 流量
對於原始 IPv6 流量而言，經過 VPN 連線傳送 IPv6 封包時，VPN 用戶端、伺服器或路由器不會使用 IPv4 封裝。這樣的方法適用於有原始 IPv6 連線的內部網路，而且 VPN 用戶端、伺服器及路由器都必須支援 IPv6 控制通訊協定 (IPv6 Control Protocol，IPV6CP)，RFC 2472，其中定義 IPv6 節點如何在採用點對點通訊協定 (Point-to-Point Protocol，PPP) 的連線中交涉 IPv6 的組態選項。Windows Vista 以及 Windows Server 2008 都有支援 IPV6CP，但是 Windows XP 以及 Windows Server 2003 都沒有。[圖 4] 顯示經過 IPv4 網際網路的 VPN 連線傳送原始 IPv6 封包時的一般封包結構。
圖 4 使用經過 IPv4 網際網路之 VPN 連線的原始 IPv6 封包
圖 4 使用經過 IPv4 網際網路之 VPN 連線的原始 IPv6 封包
對於遠端存取 VPN 連線，經過 IPv4 網際網路的原始 IPv6 流量在 Windows Vista 以及 Windows Server 2008 上，均由 PPTP 和 L2TP/IPsec 支援，而在 Windows Vista SP1 以及 Windows Server 2008 上，則是由 SSTP 支援。對於網站對網站 VPN 連線，經過 IPv4 網際網路傳送的原始 IPv6 流量在 Windows Server 2008 上，是由 PPTP 和 L2TP/IPsec 支援。

經過 IPv6 網際網路的 VPN 連線
您也可以建立經過 IPv6 網際網路的 VPN 連線。如此的 VPN 連線目前較為罕見，但是隨著愈來愈多網際網路服務供應商提供 IPv6 給客戶，而愈來愈多組織開始在內部邊緣網路上使用 IPv6 網際網路連線，此連線方式將會普及化。
若要支援經過 IPv6 網際網路的 VPN 連線，使用的 VPN 通訊協定必須支援經過 IPv6 的連線。在 Windows Vista 以及 Windows Server 2008 上，L2TP/IPsec 和 SSTP VPN 通訊協定均支援經過 IPv6 的遠端存取 VPN 連線。在 Windows Server 2008 上，L2TP/IPsec 支援經過 IPv6 的網站對網站連線。經過 IPv6 網際網路的 VPN 連線所使用的元件集合，與經過 IPv4 網際網路的 VPN 連線所使用的元件集合相同，無論是遠端存取的 VPN 連線或網站對網站的 VPN 連線。
經過 IPv6 網際網路傳送 IPv6 封包的方法也有兩種：IPv6-over-IPv4 流量以及原始 IPv6 流量。[圖 5] 顯示經過 IPv6 網際網路的 VPN 連線傳送 IPv6-over-IPv4 封包時的一般封包結構。
圖 5 使用經過 IPv6 網際網路之 VPN 連線的 IPv6-over-IPv4 封包
圖 5 使用經過 IPv6 網際網路之 VPN 連線的 IPv6-over-IPv4 封包
對於遠端存取 VPN 連線，經過 IPv6 的 IPv6-over-IPv4 流量在 Windows Vista 以及 Windows Server 2008 上，是由 L2TP/IPsec 支援，而在 Windows Vista SP1 以及 Windows Server 2008 上，則是由 SSTP 支援。對於網站對網站 VPN 連線，經過 IPv6 網際網路的 IPv6-over- IPv4 流量在 Windows Server 2008 上，是由 L2TP/IPsec 支援。有如經過 IPv4 網際網路的 IPv6-over-IPv4 流量，經過 IPv6 網際網路的 IPv6-over-IPv4 流量也需要您在內部網路上部署 IPv6 轉換技術 (例如 ISATAP)。
[圖 6] 顯示經過 IPv6 網際網路的 VPN 連線傳送 IPv6 封包時的一般封包結構。有如經過 IPv4 網際網路的原始 IPv6 流量，經過 IPv6 網際網路的原始 IPv6 流量也需要有 IPV6CP 支援，以及需要您在內部網路上部署原始 IPv6 連線。
圖 6 使用經過 IPv6 網際網路之 VPN 連線的原始 IPv6 封包
圖 6 使用經過 IPv6 網際網路之 VPN 連線的原始 IPv6 封包
對於遠端存取 VPN 連線，經由 IPv6 網際網路的原始 IPv6 流量在 Windows Vista 以及 Windows Server 2008 上，是由 L2TP/IPsec 支援，而在 Windows Vista SP1 以及 Windows Server 2008 上，則是由 SSTP 支援。對於網站對網站 VPN 連線，經過 IPv6 網際網路的 IPv6 流量在 Windows Server 2008 上，是由 L2TP/IPsec 支援。

結論
[圖 7] 顯示透過 VPN 連線傳送 IPv6 流量的四種方法，以及 Windows 對於其中兩種 VPN 連線類型的支援。總而言之，如果您有在內部網路上使用 IPv6 轉換技術 (例如 ISATAP)，您就可以使用經過 IPv4 網際網路的 VPN 連線或經過 IPv6 網際網路的 VPN 連線，來傳送 IPv6-over-IPv4 流量。如果您的內部網路支援原始 IPv6 連線，您就可以在 Windows Vista 以及 Windows Server 2008 中，使用經過 IPv4 網際網路的 VPN 連線或經過 IPv6 網際網路的 VPN 連線，來傳送原始 IPv6 流量。
Figure 7 Windows 對於透過 VPN 連線傳送 IPv6 流量的支援 (Close Figure 7)

傳送 IPv6 流量的方法 | 遠端存取 VPN 連線 | 網站對網站 VPN 連線
經過 IPv4 網際網路的 IPv6-over-IPv4 流量 | 在 Windows Vista、Windows Server 2008、Windows XP SP1 或以上以及 Windows Server 2003 上為 PPTP 和 L2TP/IPsec，在 Windows Vista SP1 以及 Windows Server 2008 為 SSTP | 在 Windows Server 2008 以及 Windows Server 2003 上為 PPTP 和 L2TP/IPsec
經過 IPv4 網際網路的原始 IPv6 流量 | 在 Windows Vista 以及 Windows Server 2008 上為 PPTP 和 L2TP/IPsec，在 Windows Vista SP1 以及 Windows Server 2008 上為 SSTP | 在 Windows Server 2008 上為 PPTP 和 L2TP/IPsec
經過 IPv6 網際網路的 IPv6-over-IPv4 流量 | 在 Windows Vista 以及 Windows Server 2008 上為 L2TP/IPsec，在 Windows Vista SP1 以及 Windows Server 2008 上為 SSTP | 在 Windows Server 2008 上為 L2TP/IPsec
經過 IPv6 網際網路的原始 IPv6 流量 | 在 Windows Vista 以及 Windows Server 2008 上為 L2TP/IPsec，在 Windows Vista SP1 以及 Windows Server 2008 上為 SSTP | 在 Windows Server 2008 上為 L2TP/IPsec

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


 Windows PowerShell: 重新探討管線
Windows PowerShell
重新探討管線
Don Jones

雖然 Windows PowerShell 是以歷史悠久的命令列介面概念為基礎，且主要使用於 UNIX 和 Linux 作業系統，但已經有太多人稱讚它的與眾不同、創新和趣味。不過 Windows PowerShell 與其前身所共通使用的名詞，卻讓人很容易就
忽略了 Windows PowerShell™ 真正的彈性與獨特性，以及它在 Windows® 環境中顯著的合適性。
Windows PowerShell 最廣為討論的一項功能，就是管線。但不幸的是，這也是經常令人誤解的一項功能。這是因為管線是源自 1970 年代早期所訂定的名詞，當時所代表的是截然不同且遜色許多的功能。

管線的由來
史上第一個 UNIX 殼層為 Thompson 殼層，只具有基本功能，而且功能僅限於最基本的指令碼語言元件，沒有變數。殼層刻意設計的十分樸素，因為其真正的目的只是要執行程式。但是其中仍提出了一項重要概念，並且改善了當時其他的殼層設計：那就是「管線」。藉由使用 < 和 > 符號，可指示殼層將輸入與輸出重新導向其他命令。例如，使用者能夠重新將命令輸出導向某個檔案。
此語法後來又繼續發展，因此一個命令的輸出可以透過管線傳遞給另一命令當做輸入，允許大量命令鏈結在一起，以完成更多複雜的工作。到了殼層的第 4 版，便採納直線字元 "|" 用於管線語法，也因此稱之為管線字元。就算是最早的 MS-DOS® 版本，只要透過這些字元實作基本管線傳遞，就能讓使用者將 Type 命令的輸出結果，傳遞給 More 命令當做輸入，因此為較長的文字檔案建立出一次顯示一頁的功能。
雖然在 1975 年推出 UNIX 第六版的時候，大多數的人都認為 Thompson 殼層不敷使用，但管線的概念卻深植入殼層開發人員與使用者心中，同時也繼續發展為現今所使用的多項技術。

以管線傳遞文字
所有殼層幾乎都有一項限制，就是以文字為基礎的本性。在 UNIX 作業系統中，這點其實不算是限制條件，而是反應出 OS 本身的運作方式。幾近所有 UNIX 中的資源都可以透過某種檔案方式呈現，也就是說，從某命令透過管線傳遞文字到另一個命令的能力，可提供極大的功能與彈性。
然而文字本身就管理資訊方面而言，絕對有其限制。例如，如果我在 Windows 電腦上顯示一張服務清單給您看，您應該都能理解其中的內容。我可能會把服務名稱放在第一欄，再把啟動模式放在第二欄。您強大的人腦可以明快、即時的將顯示的文字，剖析或解譯為可處理且有意義的資訊。然而電腦就沒那麼聰明了：如果要電腦針對該清單做出有意義的事，您必須先告訴電腦第一欄包括字元 1 到 20，而字元 22 到 40 則為第二欄，以此類推。
多年來，這種類型的文字檔案剖析，是管理員用來將多個命令鏈結在一起的唯一方法。事實上，諸如 VBScript 和 Perl 等指令碼語言的優點在於字串管理，因為他們必須能夠接受某程式或命令的文字輸出結果，並且將該輸出剖析為某種有用的資料，以便用於某些後續工作。例如，我曾寫過的 VBScript 可接受 Dir 命令的文字輸出，剖析檔案名稱和日期的輸出，接著將老舊未使用的檔案移至壓縮保存檔位置。字串剖析極難處理，因為例外 (輸入資料中的變化) 幾乎每次都會出現，需要您修改指令碼中的邏輯，以因應所有可能的變化。
字串剖析在 Windows 環境下若要當做管理指令碼或自動化使用，就比較沒有辦法發揮。這是由於 Windows 中的資訊，大多並非以便於存取的文字格式儲存。相反的，它採用以資料為中心的儲存方式，例如 Active Directory®、Windows 登錄以及憑證存放區，讓指令碼編寫者必須先使用某種工具來產生文字格式的輸出，再以指令碼剖析該文字，進而運用這些文字。

簡便的物件
Windows 軟體開發人員的日子總是比較好過。一開始，Microsoft 開發 COM 是為了以簡單好用的方式，呈現出 Windows 複雜的內部作業。現在，Microsoft® .NET Framework 仍繼續相同的工作，以標準化的方式呈現出軟體的內部作業。
一般來說，COM 和 .NET 皆以物件來顯示項目 (軟體開發人員可能會避免這樣的簡化方式，但對於本文的討論內容而言，簡單的名詞已經足夠)。這些物件全部都有不同類型的成員。為了達到目的，我們最感與趣的是物件的屬性和方法。屬性主要以某種方式描述物件，或者可修改物件本身或其行為。例如，服務物件的某個屬性可能包含服務名稱，而另一個屬性則包括服務的啟動模式。方法會致使物件採取行動。服務物件可能有名為 Stop、Start、Pause 和 Resume 等方法，用來代表您可以針對服務採取的各種行動。
從程式設計 (或指令碼) 的觀點而言，物件的成員會使用半形句點的標記格式指出。物件通常會指派給變數，以便您實際操作物件。舉例來說，如果我將服務指派給變數 $service，就可以使用語法 $service.Stop 來停止該服務。或者我可以藉由顯示 $service.Name 來擷取服務的顯示名稱。

管線中的物件
由於 Windows 是大型而複雜的作業系統，也因為它並未將管理資料以文字方式儲存，因此較舊的殼層技巧並非真正合用。例如，假設我有一個名為 SvcList.exe 的命令列工具，可產生格式化的服務與啟動模式清單。在 Windows 命令列殼層中 (該殼層穩固紮根於悠久的 MS-DOS 殼層中)，我或許會執行如下指令：
SvcList.exe | MyScript.vbs
此陳述式會擷取一份服務清單，並透過管線導向 VBScript 檔案。我必須撰寫 VBScript 檔案以剖析格式化清單，並且依我的需要執行任何動作，例如使用 Disabled 啟動模式來輸出任何服務。這項工作必須耗費不少時間。最終的問題在於 SvcList.exe 的輸出具有唯一性，並非通用格式，所以其他命令不易使用其輸出的內容。
然而，物件卻可提供通用格式，這也就是為什麼 Windows PowerShell 管線能夠處理所有物件，而不僅只於文字而已。在您執行如 Get-WMIObject 的 cmdlet 時，也就是在產生物件的群組 (就程式設計的專有名詞而言，即物件的集合)。每個物件都有完整的屬性和方法可供您操作。如果我將物件以管線傳遞至 Where-Object cmdlet，我就可以將其過濾，僅顯示出我想要的物件。Where-Object 不需要剖析任何文字，因為它不接收任何文字，只接收物件。例如：
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
或者，如果您偏好較短的語法，可使用別名：
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
有趣的是 Windows PowerShell 會永遠透過管線傳遞物件。殼層要到達管線末端為止 (也就是沒地方可繼續傳遞物件為止)，才會使用其內建格式化規則來產生物件的文字代表。就以下面的情況舉例來說：
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
這三個 cmdlets 會從我的本機電腦擷取所有服務，過濾掉所有未使用 LocalSystem 帳戶登入的項目，接著將剩下的服務傳遞到 Select-Object cmdlet，最後僅輸出兩個我要求選取的屬性：Name 和 StartMode。輸出結果是以 LocalSystem 登入的簡單服務清單 (可用於安全性稽核目的)。
由於所有 cmdlet 皆採用共同的資料格式：物件，因此可以彼此共享資料，而無需任何複雜的字串剖析。此外，由於 Windows PowerShell 原生即可建立物件的文字代表，因此這個管線的末端一定是人類可以閱讀的文字輸出。[圖 1] 顯示已產生的輸出範例。
圖 1 透過管線傳遞物件的一組 cmdlet 所產生的文字輸出。
圖 1 透過管線傳遞物件的一組 cmdlet 所產生的文字輸出。

奇妙的管線
Windows PowerShell 中的管線傳遞功能之所以如此奇妙，是因為 Windows PowerShell 內的一切都是物件，且有完整的屬性與方法可搭配使用。技術上而言，文字檔也只是一組字串物件，而檔案中的每一行都是具有唯一性，同時也是獨立的字串物件。例如，(使用 Notepad) 建立名為 C:\Computers.txt 的文字檔。在檔案中填入文字，接著在 Windows PowerShell 中執行以下動作：
Get-Content C:\Computers.txt | Select-Object Length | Format-List
或者，如果你不想打那麼多字，一樣可使用別名：
gc C:\Computers.txt | select Length | fl
此程式碼提供的清單，會指出文字檔案中每一行的字元數長度。Get-Content 會從檔案擷取字串物件，Select-Object 會找出每個物件的 Length 屬性，接著再由 Format-List 為您建立整齊、可讀的文字輸出。這或許不是很實用的系統管理工具，但足以顯示即使是一行文字這樣簡單的內容，也可以成為 Windows PowerShell 的物件。
能夠從 cmdlet 經由管線傳遞物件到另一個 cmdlet (甚至從 cmdlet 傳遞到指令碼)，就可以開始建立功能強大的「單行指令碼」囉。這些簡單的 cmdlets 字串經過一系列的管線之後，即可進一步調整物件組合，以完全符合您的需求。在幾乎沒有任何指令碼或程式設計的情況下，Windows PowerShell cmdlets (在適當的管線中繫結在一起) 即可達到絕佳的成果。

支援未來的新產品
未來的 Microsoft Server 產品同樣會建立在 Windows PowerShell 基礎上，這樣的事實更能拓展這項特性。例如，在實作新的 Exchange Server 2007 電腦時，您可以使用 Windows PowerShell 來擷取所有郵件信箱，篩選過濾掉辦公室以外的並找出新郵件伺服器，接著將這些郵件信箱移動至新伺服器；上述功能只需要一行文字就能辦到，完全無須指令碼。Exchange Server 2007 工作小組發行了功能強大的單行指令碼。這些單行指令碼真正展現出管線的強大功能，及其能夠完成的系統管理工作。
若要充分運用 Windows PowerShell 的技巧，就必須了解它雖然建立在原則與觀念由來已久的 UNIX 世界，但這項新工具卻非常適用於 Windows 系統管理。不要被通用的詞彙騙了，還誤以為 Windows PowerShell 只是 Windows 在冒用 UNIX 殼層。Windows PowerShell 包含全新的概念，不但可以善加利用 Windows 平台，還能夠與各項 Windows 技巧緊密結合。

Don Jones 是 Windows PowerShell MVP，也是 Windows PowerShell 101 (ScriptingTraining.com) 的作者。他的電子郵件為 www.ScriptingAnswers.com。


 嗨，Scripting Guy！: 指令碼世界和現實生活一樣，外觀很重要
嗨，Scripting Guy！
指令碼世界和現實生活一樣，外觀很重要
Microsoft Scripting Guy

數百年來， 其實應該說數千年來，哲學家和聖人們都一直告訴我們，「人不可貌相」(雖說我們不該對他人有成見，但話又說回來，「情人眼裡出西施」，所以還是要看一下吧)。您應該聽過這句話：「真正的美麗發自於內心，而非外觀，所以您所活出的模樣比外貌更重要」。
對於這樣的說法，Scripting Guy 只能加一句：「廢話連篇」。
沒錯，就是廢話連篇。Scripting Guy 應該是第一個承認在完美的世界裡外貌沒有任何影響力的人。但是，我們不是住在一個完美的世界裡。如果是的話，炸薯條和巧克力聖代就會成為兩種主要的食品類別。無論您是否同意，外貌還是很重要。這對於指令碼也是一樣。
Scripting Guy 其實知道有少數人看到 VBScript 指令碼正在命令視窗中執行時，會喜極而泣 (至少 Scripting Guy Dean Tsaltas 就是這樣的人，目前我們名單上只有他)。
另一方面，在當下的數位時代，指令碼撰寫者們的作品已不再限於命令視窗中執行了。由於有了 HTML 應用程式 (HTML Application，HTA)，指令碼撰寫者們可以利用 DHTML 的威力，來建立指令碼的圖形使用者介面 (GUI)。這樣的 HTML 技能還可以用來建立 Windows Vista™ 小工具，如此的彈性甚至可能革新系統管理指令碼的世界。但是，您知道嗎？一旦您開始談論 GUI，所有勸導大家不要以貌取人的美德都將成為廢話。因為在圖形環境中執行的指令碼，外觀與功能和效能一樣重要。
而這是一大問題。再怎麼說，我們也只是指令碼撰寫者，我們哪會知道如何建立圖形使用者介面呢？看來我們是否又陷入困境了？
也許是，也許不是喔。剛剛是不是有人說，「還好有 Scripting Guy！」？
我真的好像有聽到耶。明明就有人說這樣的話，沒有嗎？也許是有人以自言自語的方式說的...
好啦，反正不重要。理當有人會這樣說，因為畢竟 Scripting Guy 就是要為大家提供協助的嘛 (無論您是否想要我們的協助)。
為了讓您初步了解 GUI 世界的美妙，讓我們先看看一個簡單的 HTA (如果您想要建立 HTA 的詳細資訊，請參閱 HTA 開發人員中心)。
[圖 1] 中所顯示的，就是一個花俏的桌面資訊系統。如您所見，我們首先將一個圖形放置在 HTA 視窗中的右上角。目的是要在 HTA 載入時，擷取登入的使用者名稱，然後將他/她的名字和電腦名稱顯示在此影像的上方。稍後我們會在 HTA 中加入各種酷炫的內容，但就像他們說的，凡事不要操之過急，讓我們一步一步來。
圖 1 美美的 HTA 圖形介面的形成
圖 1 美美的 HTA 圖形介面的形成
其實我們也不確定說這些話的「他們」是誰。可能又是一位哲學家。可能是伏爾泰吧。反正聽起來就像是哲學家會說的話嘛。
沒錯，這只是一個小小的應用程式，而且其...美貌...目前可能連 Scripting Guy Dean 都還無法打動。然而，這是一個好用的示範工具，其中的基本概念適用於很多情形。畢竟許多令人嘆為觀止的 Windows Vista 小工具都採用類似的作用原理；他們都只是顯示一個耀眼的圖形 (例如儀表或刻度盤)，然後在該圖形上撰寫文字。如此一來，您看到就好像一個很酷炫的可用磁碟空間儀表，但是事實上只是動態文字重疊顯示於一個圖形上面。
是呀，我們也聽不太懂以上的敘述。但是本專欄後續會進一步說明。
對於顯示圖形然後在圖形上面重疊顯示文字的觀念，只有一個問題：行不通。若改用 HTML 標記，我們會得到如 [圖 2] 所示的結果。跟我們想像的不太一樣。或許當 Nietzsche 說：「人類永遠無法把文字重疊顯示在圖形之上，至少在 HTA 中不可能」時，是對的。
圖 2 首次嘗試重疊顯示文字
圖 2 首次嘗試重疊顯示文字
抑或 Nietzsche 是錯的：我們是不是又聽到有人說...唉，算了。反正我們就是無法使用單純的 HTML 達到想要的效果。當然，理論上我們可以把圖形變成背景圖形，然後使用表格和不分行空格以及各種伎倆，讓文字重疊顯示在圖片上。我們之所以會說「理論上」，是因為除了很陽春的案例以外，這樣的策略是行不通的。
若要在 HTA 或 Windows Vista 小工具中建立耀眼的配置，其實有更好的方法：就是用「階層式樣式表 (Cascading Style Sheets，CSS)」。
CSS 是用來定義字型、邊界、對齊方式、色彩以及其他文件外觀的方法 (這特別適用於網頁，而由於 HTA 和小工具的本質其實就是網頁，所以 CSS 也適用)。發揮 CSS 的可能性不勝枚舉，因此如需完整的詳細資訊，請參閱 MSDN® 上的 Cascading Style Sheets 參考文件。就我們的討論範圍而言，僅需要知道我們可以使用 CSS 來控制 HTA 的配置細節，包括可以重疊顯示一個項目 (我們的文字) 到另一個項目 (我們的圖形) 上。
我們將說明如何完成這一切。但是在我們開始進行說明之前，讓我們先看看一個簡單 HTA 的程式碼，如 [圖 3] 所示。
Figure 3 最後的指令碼結果... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
如您所見，這其實沒什麼。其中有一個 Window_OnLoad 副常式 (顧名思義)，這會在每一次 HTA 重新整理時自動執行。我們稍後會討論這個副常式。此外，我們還有兩個 HTML 項目：我們的圖形項目和一個 Span 項目。相信您一定看得出來，這些標記是用來插入圖形，其中使用 Align 屬性來確保圖片顯示在視窗的右手邊：
<img src=”test2.jpg” align=”right”>
接下來就是 Span 的 HTML 標記：
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
是的，我們在此處用了 Span 的標記。Span 標記到底是啥？說穿了，其實 Span 只是 HTA 的一個命名區域；也就是在 HTA 視窗中，一個可以透過程式設計的方式是別的「標記」區段 (因為我們已將 Span 的 ID 命名為 UserData)。設定 Span 之後，就可以撰寫副常式來指定文字或 HTML 程式碼給該 Span。事實上，我們已經在 HTA 中這麼做。
然而，我們還是要稍後再來討論這一點。在此之前，我們需要先看看 Span 標記中所加入的 Style 參數：
style=”position:absolute;left:770px;top:150px”
此參數正是把動態文字重疊顯示在圖形上方的關鍵。我們在此處指定了三個 Style (樣式) 屬性。
Position (位置) 我們告訴 HTA 我們的 Span 位置要採用絕對的配置。這代表我們要 Span 永遠在同一個位置上，即使文字會重疊顯示在另一個項目 (例如圖形) 之上。
Left (左邊界) 這是在指定 Span 的位置與 HTA 視窗之最左邊緣的相對位置。在此案例中，我們希望 Span 的區域是從最左邊緣算起，往右 770 個像素 (770px) 的地方開始。
Top (上邊界) 此設定與 Left 屬性很類似，但這是在定義 Span 的位置與 HTA 視窗之頂端邊緣的相對位置。在此案例中，我們希望 Span 的區域是從頂端邊緣算起，往下 150 個像素 (150px) 的地方開始。
您是否要問，我們是如何知道要將 Span 的左邊設定在 770 個像素，而將頂端設定在 150 個像素？老實說，我們並沒有用什麼秘訣，而是用猜測的；我們只是將圖形放置到頁面上，然後指定 Span 的 Left 和 Top 屬性值。接著我們開啟 HTA 來查看結果。可想而知，一開始我們的設定會有些偏差，於是我們調整設定值，重新整理 HTA，然後再查看一次。調整數次之後，就像《三隻小熊與金髮女孩 (Goldilocks)》的故事一樣，我們反覆實驗就找出了理想的設定值。
注意：您應該知道三隻小熊與金髮女孩的三個床、三個椅子，以及三碗太熱或太冷的麥片等故事吧。其實我們不確定 Goldilocks 這一位金髮女孩是否可稱為知名的哲學家。至少您可以說，這一位女孩會擅自闖入他人的房子、試吃他們的麥片、試坐他們的椅子，以及試睡他們的床鋪，應該有她獨特的生活哲學吧。
反正 [圖 4] 顯示我們的 HTA 現在的樣貌。雖然這稱不上是藝術品，但是您要知道，連畢卡索也無法以程式設計的方式將文字資訊重疊顯示在圖形的上面呀。
圖 4 樣式定義的威力
圖 4 樣式定義的威力
說到這裡，我們到底是如何以程式設計的方式，讓文字重疊顯示在圖形的上方？您期盼已久的好消息來了：我們終於要討論 Window_OnLoad 副常式了，如 [圖 5] 所示。
Figure 5 Window_OnLoad 副常式 (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
您知道嗎，仔細看一下此副常式之後，我們發現根本沒有什麼需要討論的耶，同意吧？如您所見，我們首先建立了 Wscript.Network 物件的執行個體。然後我們使用下列程式碼，來擷取使用者名稱和網域以及電腦名稱：
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
這些剛好是我們想要寫入 HTA 視窗中的資訊。我們只需要運用少許 HTML 標記結合 strUser 和 strComputer 變數，然後將結果字串指定給 Span 的 InnerHTML 屬性即可：
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>”_
  & strUser & “<br>” & strComputer & _
  “</font></p>”
是的，我們知道這些程式碼看起來好像很複雜。但事實上不然。看似複雜是因為我們要結合數個項目成為單一字串。首先是一個段落開頭標記，以指定我們要在段落中將文字置中對齊。
“<p align = ‘center’> “
接下來是一個字型 (Font) 開頭標記，以指定我們要使用點數為 18 的白色文字：
“<font style=’font-size:18pt;color:white’>”
strUser 是儲存使用者名稱的變數，格式為 Domain\UserName。"<br>" 則會插入換行符號。我們插入換行符號是為了要讓使用者的名字單獨出現在一行上，然後讓電腦名稱出現在第二行。strComputer 則是儲存電腦名稱的變數。最後，我們個別加上字型和段落的結尾標記：
“</font></p>”
當您查看各個部分，不難發現其實程式碼完全沒有像您想像的那麼複雜。
順便提醒您，針對位置的設定，您可以使用任何 HTML 項目進行配置。例如，假設您想要在圖形下方置中對齊一個按鈕。若要這麼做，只需要將下列加入您的 HTA 程式碼：
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
這將使您的 HTA 變成如 [圖 6] 所示。
圖 6 美美的按鈕
圖 6 美美的按鈕
再次強調，您必須要反覆試驗，才能夠找到最理想的配置設定，但是應該不需要花費太久的時間。事實上，如果您願意做點數學運算，就可以事先判斷正確的位置設定。您只需要知道每一個物件的寬度和高度 (您可以使用 Style 參數來指定)，以及 HTA 視窗的寬度和高度。根據預設 (至少在 Scripting Guy 的測試用電腦上)，HTA 大約是 1020 個像素寬，乘以 685 個像素高 (當然，實際結果可能會有所不同)。您可以先用這些數據做為起點，然後根據實際需求進行調整。
以上僅為 CSS 的「非常簡略」介紹，但應該足以讓您開始呈現美麗耀眼的指令碼。哲學家們或許會潑您冷水，說您不需要這麼努力，因為指令碼的美應該來自內涵而不是外觀。但是請試想一下：目前最偉大的哲學家們有誰？沒錯：就是柏拉圖、蘇格拉底、亞里斯多德等這些傢伙。確認這一點之後，我們想要提問：您是否看過這些哲學家們的照片？您不覺得整天說外觀的美不重要的這些人，連一張照片都沒有留下來，是一件很有趣的事嗎？您不會覺得這有點詭異嗎？這的確值得深思。

Microsoft Scripting Guy 為 Microsoft 做事，也就是受雇於 Microsoft。在比賽、訓練、看棒球賽 (以及其他各種活動) 之餘，他們也負責管理 TechNet Script Center。請造訪他們的網站 www.scriptingguys.com。


 Exchange 佇列問題與解答: 邊緣和集線器傳輸角色、虛擬機器等
Exchange 佇列問題與解答
邊緣和集線器傳輸角色、虛擬機器等
KC Lemson and Nino Bilic

在 2007 年 5 月號的《Exchange 佇列問題與解答》中，我們討論了在網路共用位置上儲存 .pst 檔的問題。Windows Server 效能小組最近成立了部落格，討論
此主題的冗長技術性細節，因此，我們很樂意提供該部落格的連結。現在讓我們開始回答問題吧。

問：如果我想要部署 Microsoft Exchange Server 2007，我需要部署邊緣伺服器角色嗎？

答：不，您不需要部署邊緣伺服器角色就可以部署 Exchange Server 2007。您可以只有一部機器來執行所有核心伺服器角色 (例如信箱、用戶端存取和集線器傳輸)、接受您網域的網際網路電子郵件，以及執行反垃圾郵件和防毒程式。

問：邊緣和集線器傳輸伺服器角色之間有何差異？如果我沒有部署邊緣伺服器，會失去什麼？

答：集線器角色的主要用途是在組織內路由郵件，以及對那些郵件套用商業原則。使用集線器角色時，傳輸規則是根據 Active Directory® 物件：使用者、通訊群組清單等。集線器角色也可以讓您在傳送郵件時，在其中加入免責聲明，或在傳送郵件給使用者群組時，記錄所傳送的郵件訊息，因為您可能希望那些規則以 Active Directory 成員資格作為基礎。例如，您可以記錄傳送給 DLOfUsersOnLitigationHold 的所有訊息，或在 DLOfMembersOfLegalTeam 傳送的外寄郵件中加入免責聲明。雖然可以在集線器伺服器上執行反垃圾郵件代理程式，但根據預設並不會啟用，因此您需要執行伺服器上的 \scripts 目錄中可用的 install-antispamagents 指令碼，來手動安裝代理程式。
邊緣角色的主要用途是將郵件路由進入組織，以及從組織將郵件路由出去，以及對那些郵件執行訊息檢疫 (反垃圾郵件、防毒、內容或附件篩選等)。當您安裝邊緣伺服器時，預設會立即啟用反垃圾郵件功能。邊緣角色的特性之一，是它不需要加入 Windows® 網域，它可以在不屬於 Windows 網域的 Windows Server® 安裝中執行，但邊緣伺服器仍然可以當成公司樹系中的 Exchange 2007 組織的一部分加以管理。
這在周邊網路中特別有利，因為您會希望該伺服器位於工作群組中，或者，您可以對周邊網路中的機器明確提供個別的樹系。正好，在此情況下部署的邊緣伺服器可以執行所有訊息檢疫，以及在公司網路和網際網路之間路由郵件，而且仍然可以與其他的 Exchange 2007 系統管理工作一致的方式加以管理。
在邊緣伺服器上，傳輸規則是根據 SMTP 位址而不是 Active Directory 物件，不過，您當然可以使用 Active Directory 中，DL 或使用者的 SMTP 位址。大致上來說，邊緣傳輸規則是集線器傳輸規則的子集，唯一例外的是只有邊緣伺服器才有的隔離動作。
邊緣伺服器也有一些功能會透過代理程式公開，而在集線器傳輸伺服器上是沒有的：附件移除和位址重寫。附件移除是指可選擇性地移除具危險性 (例如副檔名為 .exe 和 .com) 之附件的功能。位址重寫代理程式可讓您重寫電子郵件標頭，例如，雖然使用者帳戶上的網域和預設 SMTP Proxy 位址可能是 @contoso.com，外寄至網際網路的郵件卻可以是 @northwindtraders.com。而且，邊緣伺服器只會根據網域或位址空間執行路由，因此，如果您在 Exchange 和另一個電子郵件系統之間共用相同的 SMTP 位址空間，就需要在集線器伺服器上執行路由，或是搭配邊緣伺服器上的位址重寫代理程式執行路由。
另一個重要考量是 Exchange 2007 伺服器是否直接為網際網路方向連線 (不論是集線器或邊緣伺服器角色)。換句話說，您網域的 MX 記錄上之連接埠 25 的連線，是否會連線到 Exchange 2007？您可能已經在網際網路上加設 SMTP 閘道、防毒機制或其他解決方案，來接受您網域的郵件，然後將它傳遞到公司網路內的 Exchange。如果您將邊緣伺服器或集線器伺服器部署為網際網路方向連線，則您可以利用 Exchange 2007 最炫的功能之一：安全清單彙總。有了安全清單彙總，使用者在 Microsoft Outlook® 的安全清單中加入寄件者 (他們通常會對網際網路電子報或來自零售商的電子郵件這麼做) 之後，就可安全地將那些清單傳播至邊緣伺服器或集線器角色，使來自那些寄件者的郵件略過內容篩選。當然，一位使用者的垃圾郵件有可能是另一位使用者重要的電子報，因此，安全清單彙總功能會針對個別使用者執行。若要進一步了解其運作方式，您可以參閱 Exchange 2007 文件。
如果您最後的部署，是使用以集線器角色執行的伺服器來接受您網域的網際網路電子郵件，則有幾件事請謹記在心：當然，首先要確定您已經設置了理想的防火牆或連接埠篩選解決方案，使伺服器只接受必要連接埠的連線，例如連接埠 25。並請記住，您需要安裝反垃圾郵件代理程式，因為依預設並不會安裝或啟用它們。因為集線器伺服器最常見的部署方式是在公司網路內，所以根據預設不會允許匿名連線，您需要檢查連接埠 25 接收連接器的 AnonymousUsers 使用權限群組。您也要確保已啟用安全清單彙總，並安排定期的執行，才能在使用者更新其信箱的安全清單時，來自安全寄件者清單上的郵件會略過內容篩選。如需詳細資訊，請參閱我們的部落格。
下列程式碼顯示的 AT 命令，會使用名稱為 SafeList.bat 的批次檔，在每天晚上 11 點更新所有伺服器上的所有信箱：
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
此程式碼會顯示 SafeList.bat 檔案的內容：
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
如果您需要確認設定是否可以正確運作，請參閱 Exchange 2007 文件中的詳細資訊。

問：在啟動我的 Virtual PC 影像檔 (內含 Exchange) 之後，我一直遇到連接目錄或 LDAP 伺服器的問題。以 Telnet 方式連接到 389 的運作正常，且所有伺服器都在執行。為什麼會這樣？

答：我自己去年在 Tech•Ed 也碰到這個問題。我的筆記型電腦上有一個 Virtual PC 版本，這是我從工作用的電腦上複製來的，我打算要用來為也經常在發佈文章的記者們做示範，因為下個月剛好要推出 Exchange 2007 Beta 2。
我做過無數次的產品示範，知道這一個建置很穩定，因此我並沒有在事先做很多準備。可想而知，當我在週一早上 (就在會議的前幾個小時) 啟動我的 Virtual PC，而我的建置卻完全無法連上網域控制器時，我額頭上一直在冒冷汗。多虧屋子裡匯集了一堆超級聰明的人，我們才能夠很快就找出答案。
我在 Tech•Ed 災難現場遇到的問題，就是因為我是在我的超慢速筆記型電腦上執行 Virtual PC 的結果。問題根源在於 DNS 與 Active Directory 的競賽條件。影像檔上的 DNS 伺服器是設定為與 Active Directory 整合，但由於影像檔上的服務的載入順序 (還有，我筆記型電腦的速度太慢)，必要的目錄服務並未在 DNS 伺服器嘗試連上 Active Directory 時即時啟動。
此情況可能發生在同一部機器上有 DC 和 Exchange 的任何伺服器上 (它不必是虛擬化影像檔)，但是它更可能發生在會導致速度變慢的虛擬化環境中，尤其是在像我這種力道不足的筆記型電腦上。
我也看過類似的問題發生在兩部機器之間複製的 Virtual PC 影像檔上，尤其是當其中一部機器位於不同的網路上。如果您遇到過這種情況，請檢查影像檔中的 OS 的 IP 位址；它可能含有來自舊網路的舊 IP 位址。請更新它，以取得新網路的 IP，看看這樣做能否解決問題。
為了避免未來又發生這類問題，一個替代方案是使虛擬環境中的 DNS 伺服器不要與 Active Directory 整合，並同時在主機環境與來賓環境中安裝 DNS。讓來賓系統將不明記錄轉寄至主機，並讓主機將不明記錄轉寄至適當的 DNS 伺服器。當影像檔啟動並嘗試更新 DNS 記錄時，就比較不容易失敗。

問：Exchange 2007 安裝似乎與舊版 Exchange 的安裝大不相同。它到底如何進行？

答：是的，Exchange 2007 的安裝會分為數個階段。以下概述整個過程。

當您第一次執行 setup.exe 時，在您開始安裝實際伺服器角色之前會啟動一項程序，其中會提供您需要先安裝之大部分必要條件的連結。當您安裝所有這些必要條件之後，[安裝 Microsoft Exchange] 連結就會變成可點選的連結 (請參閱 [圖 1])。
圖 1 符合一般必要條件之後可用的安裝連結
圖 1 符合一般必要條件之後可用的安裝連結
如果您從網路執行 setup.exe，並按一下 [安裝] 連結，則核心安裝檔案會複製到本機電腦上的 %TEMP%\ExchangeServerSetup\ 資料夾。接著會啟動安裝精靈。
安裝精靈將逐步引導您完成各個選項，例如授權合約、錯誤報告和安裝類型 (您可以在此挑選要安裝的伺服器角色)。精靈頁面將視目前的 Exchange 組織 (如果有的話) 是否存在以及其狀態而異。
在完成此步驟之後，安裝程式會執行準備檢查 -- 其實就是 Microsoft Exchange Server Best Practices Analyzer (BPA) 的改良版，根據預設，它將連現到網際網路來下載包含最新必要條件的 XML 檔案。這可以讓您定期更新必要條件，或解決 Exchange 小組自從產品出貨以來所發現的任何問題。準備檢查完成之後，您可以檢閱結果並繼續進行；否則您會看到在繼續安裝之前需要解決的問題。如果伺服器沒有通過準備檢查，在大部分情況下，精靈會讓您重試檢查。
通過準備檢查之後，您才會看到 [安裝] 按鈕，讓您開始進行先前選擇之角色的安裝。安裝程式只會複製及安裝您所選取之角色的檔案。
在安裝程序的最後，您將有機會啟動 Exchange Management Console 以及套用任何可用的 Exchange 2007 更新項目。

KC Lemson 是 Exchange Server 使用者經驗的專案經理。她的線上銀行帳戶暫時遭到凍結。
Nino Bilic 是 Exchange Server 的技術支援專案經理。他最近在自己的信用卡資料上增加了第二個電子郵件地址。


 安全性監控: 管理 ACL 的工具
安全性監控
管理 ACL 的工具
Jesper M. Johansson

在 Windows 中，存取控制清單 (ACL) 可以讓您細微地控管使用者和處理程序使用如檔案和資料夾等資源的能力。ACL 的管理在保護使用者系統安全的作業中，是較為複雜的作業之一。幸好，有一些好用的公用程式
可協助自動化及簡化權限與 ACL 的相關作業。
大部分讀者都熟悉古老的 cacls.exe 工具，自從此工具第一次推出之後，每一個 Windows NT® 版本就少不了它。如果您在 Windows Vista™ 執行 cacls.exe，就會出現以下訊息：
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
除了 Windows Vista 的 ACL 更新之外 (我在 TechNet Magazine 2007 年 6 月號已討論過；請參閱 technetmagazine.com/issues/ 2007/06)，Microsoft 也更新了用來管理 ACL 的一些工具。有趣的是，在這些更新項目當中，最大的變更是命令列工具。
Icacls.exe 是 Windows Vista (以及舊版 Windows Server® 2003 Service Pack 2) 的新工具。它最後會取代 cacls.exe，您可能已發現，cacls.exe 從未完整更新以支援 Windows® 2000 所推出的更細微權限，使得這項更新大約逾期七年。
令人驚訝的是，雖然被淘汰了，cacls.exe 實際上還包含一些新功能。第一，它可察覺交叉點和符號連結，也知道要周遊它們。第二，它可以使用安全性描述定義語言 (Security Description Definition Language，SDDL) 字串來列印及設定 ACL。
不過，雖然 cacls.exe 有這些更新項目，但您真正想要的是 icacls.exe 提供的功能。

儲存及還原 ACL
過去這 10 年來，至少我一直希望有儲存 ACL 的能力，讓您可以在未來還原它。這是您可以對 ACL 執行的作業當中，最複雜的其中一項。除了某些特殊案例之外，其實很難回到您沒有摧毀 ACL 的原狀。不過，此功能非常有用。
在開始討論如何儲存或還原 ACL 之前，首先讓我們了解一下為何如此困難。假設您有一個包含當地大學生使用者資料的階層。您在 2 月 1 日儲存 ACL。在 4 月 17 日，您發現 ACL 有損毀的現象，因此從儲存的複本中進行還原。這項作業會有何複雜之處？
首先，新的一季是從 4 月 2 日開始。大約有 15% 的學生已畢業；因此，他們的目錄不復存在。於是，您的備份檔中會包含無效的 ACL。新的一季開始，所以也有一批新學生，這又是另一個 15 %。他們現在有 home 目錄，但備份檔中沒有 ACL。他們的 ACL 應該有什麼內容？當然，接下來您還有 70% 需要考慮，而他們已在這期間建立新檔案和資料夾，以及刪除其他的檔案和資料夾。您可以忽略已刪除的，但您要如何設定他們所建立的新資料夾？如果某一位學生在 3 月 4 日開始與朋友們共用某個資料夾，該怎麼辦？當您還原 ACL 時，是否會破壞它的設定？
許多人認為 ACL 的儲存及還原是一件簡單的作業，事實絕非如此。您在執行此作業時需要非常小心地處理。結果極有可能會導致一些未定義的行為。ACL 的還原絕對是最後不得已的選擇；因為自從您將它備份以來，時間越久，當您還原它時，就越有可能造成損壞。
如果您還是想要試試此功能，請在執行 icacls.exe 時使用 /save 參數：
icacls <target> /save acls.bin /t
這樣會將 ACL 儲存到一個叫做 acls.bin 的檔案。此檔案中的每一行將包含一個含有 ACL 的物件，且後面會有一行以 SDDL 指定 ACL 的內容。若使用 /t 參數，這個命令將對您指定的物件及其下的所有物件和容器進行操作。
這項儲存功能是一項受歡迎的工具箱項目，但它有一些缺點。例如，它只會儲存判別存取控制清單 (DACL)，而不會儲存系統存取控制清單 (SACL)。事實上，如果有 SACL，它會儲存虛擬值來指出這一點，但它其實不會儲存 SACL 的任何部分。
此外，儲存 ACL 的方式會產生有趣的問題。在您喜愛的文字編輯器中開啟已儲存的 ACL 之前，請記住：
切勿編輯已儲存的 ACL！
如果您在文字編輯器中開啟包含已儲存 ACL 的檔案，會發現它看起來像是 Unicode (UTF-16) 格式的文字檔。事實也差不多。這可能會讓您以為可以編輯它，並從文字編輯器進行儲存。請不要這麼做！
如果您在文字編輯器中開啟包含已儲存 ACL 的檔案，然後儲存它，您將無法從該檔案還原 ACL。畢竟，它並非完全是 Unicode 文字檔。此種檔案的開頭必須是 2 位元組 0xfffe。如果您以文字編輯器 (例如記事本) 儲存該檔案，就會將該旗標放到檔案的前 2 個位元組中。不過，icacls.exe 工具會預期 ACL 資料的開頭，會從該檔案的位元組 0 開始。因此，工具將無法剖析檔案中的 ACL，因為它預期前兩個位元組是字串的一部分，其中應該指定要操作的物件。於是您的備份檔將變得無法使用。
Microsoft 知道這個問題，但由於它直到 Windows Vista 在 Beta 週期很晚的時候才獲得通報，因此，這項缺點未在發行之前加以解決。目前，我們不知道這何時可以解決，甚至是否會解決。因此，現在最好的建議就是不要編輯已儲存的 ACL。如果您需要這麼做，請將檔案另存為 .bin 檔，並使用十六進位編輯器，例如您喜愛的開發環境。
使用 /save 參數儲存 ACL 之後，您就可以使用含有 /restore 參數的 icacls.exe 來還原它。最簡單的 restore 命令語法如下：
icacls <directory> /restore acls.bin
還原程序不會對檔案進行操作。若要了解，請看 [圖 1] 顯示的命令順序。此處我將 icacls.exe 指向一個檔案，來建立儲存檔。然後我試著以 /restore 替代 /save 來還原它。結果失敗，因為 restore 命令只能對目錄進行操作。它應該修改的檔案已指定在 acls.bin 檔中。若要還原 ACL，我必須指向目錄而非檔案。這就是我在上一個命令中執行的動作，我指定 "." 作為要操作的物件。
Figure 1 儲存及還原 ACL (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
另請注意，restore 命令必須以更高的權限執行！您可以從命令提示中以低階系統管理員或甚至標準使用者的身分來執行 save 命令，只要您有讀取 ACL 的權限即可。不過，若要還原 ACL，您需要有完整的系統管理員權仗。

替換 SID
icacls.exe 另一項非常有用的功能，就是能夠以一位使用者的權限，來取代另一位使用者的權限。方法是在還原期間使用 /substitute 參數。替代參數的文件上說它需要 SID，但後來又解釋這實際上也可以是一般使用者名稱。因此，[圖 2] 所顯示的操作順序可行。
Figure 2 在還原期間替換 SID (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
誠如您所看到的，最後我還是使用以前的相同 ACL，但原先用來指定 foo 的權限的 ACE，現在則改用來指定 bar 的權限。

變更擁有者
數年來，chown 一直是 UNIX 系統上的主要工具之一。Windows 原本沒有內建可變更物件擁有者的方式。後來在 Resource Kit 中出現了 setowner 工具。然後，我們在 Windows NT 4.0 中有了 takeown.exe 工具，但此公用程式只能讓您取得擁有權，除非您有其他人的密碼，否則不能授與擁有權給其他人。現在 icacls.exe 已內建可以讓您設定物件擁有者的功能，只要您有權限對其設定擁有者：
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
遺憾的是，icacls.exe 不能顯示物件的擁有者。您無法從命令列看到物件的擁有者是誰。不僅如此，如果您儲存物件的 ACL，它不會儲存物件的擁有者。
icacls.exe 中還含有一個問題，亦即它不會呼叫 SeTakeOwnershipPrivilege 來變更擁有者。根據 ACL，如果您有變更物件擁有者的權限，則 icacls.exe 的運作就沒有問題。不過，如果您是系統管理員，而根據物件的 ACL，您並沒有變更擁有者的權限，則您將無法使用 icacls.exe 這麼做，這是因為上述已知問題的緣故。在此情況下，您需要使用 takeown.exe 工具，它會呼叫 SeTakeOwnershipPrivilege，但只能將擁有者變更為您的帳戶或系統管理員群組，而非任意帳戶：
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
當然，也請注意，可從 Microsoft 下載中心下載的 subinacl 工具，也有 setowner 參數。在許多情況下，Subinacl 的運作方式實際上比 icacls 更容易了解，但使用起來較為複雜。

尋找特定使用者的檔案
Icacls 有另一項好用的功能：它可以尋找特定使用者擁有權限的檔案。例如：
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
如果您想要知道某一位使用者可以存取的所有項目，這將很有幫助。

重設及變更 ACL
如果 ACL 受損或毀壞，icacls.exe 有辦法將它重設為繼承其父代。這對於 2006 年秋天發生的 zero-day 安全性問題可以有很大的幫助。用來解決 Windows 元件發生這個問題的方法之一，是拒絕物件的 Everyone 存取權。這個部分聽起來很簡單，但要使用 Windows XP 和 Windows Server 2003 的內建工具來移除該存取控制項目 (Access Control Entry，ACE) 幾乎不可能。不過，若換做在 Windows Vista 中，您只需要執行下列命令：
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
當然，Icacls.exe 可以執行所有標準的 grant/deny/remove 作業。這份清單中唯一真正的新項目是 remove。使用此參數，您就可以針對特定使用者，從特定物件或階層中移除所有容許 ACE 的權限、所有拒絕 ACE 的權限，或兩者。[圖 3] 顯示一些不同的 grant、remove 和 deny 作業的範例。
Figure 3 Grant、deny 及 remove 作業 (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
如果您想要對特定群組或使用者開啟物件的存取權，則只移除拒絕 ACE 的功能將很有幫助。

設定整合層級
Icacls.exe 也有顯示及設定完整性層級的功能。Windows Vista 支援對物件加上完整性標籤。Icacls.exe 正是用來執行此功能的命令列工具：
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
請注意，唯有當物件有明確設定完整性標籤時，icacls.exe 才會顯示完整性標籤。大部分檔案並沒有設定，因此您通常看不到此標籤。
最後，icacls.exe 可確認物件是否有標準 ACL。如前所述，有協力廠商的工具會在 ACL 中以錯誤的順序放置 ACE。Icacls.exe 可驗證及修正這類型的問題，如下所示：
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

ACL UI
ACL UI 或 ACL 使用者介面，從 Windows XP 之後已經做了一點修改。[圖 4] 和 [圖 5] 分別顯示 Windows XP 和 Windows Vista 中的 ACL UI 對話方塊。
圖 4 Windows XP 中的 ACL UI 對話方塊
圖 4 Windows XP 中的 ACL UI 對話方塊
圖 5 Windows Vista 中的 ACL UI 對話方塊
圖 5 Windows Vista 中的 ACL UI 對話方塊
誠如您所看到的，此處有一些變更。第一，對話方塊最後很清楚地顯示您操作的物件，如果您一次處理數個物件，則這樣很有幫助。第二，底端有一些說明的超連結。不過，最明顯的變更是其中移除了 [新增] 和 [移除] 按鈕，並以 Windows Vista 中的使用者存取控制 (User Access Control，UAC) 支援中最常出現的 [編輯] 按鈕取代之。您可以從按鈕的護罩中看出，啟動此對話方塊的使用者沒有權限可編輯 ACL，因此，在編輯權限之前需要提高權限。請注意，如果您在 C: 磁碟機的根目錄中建立資料夾，並立即勾選其內容，則預設行為會不一樣。因為身為資料夾的擁有者，您有隱含權限可編輯 ACL，所以護罩會變不見。護罩象徵 COM Moniker，此機制是用來為某執行中程序的一部分啟動提高權限提示。如果您按一下 [編輯] 按鈕，會看到熟悉的提高權限對話方塊，如果您按一下提高權限對話方塊中的 [繼續]，就會看到幾乎與您在 Windows XP 中按一下 [新增] 按鈕所看到的一模一樣的對話方塊。ACL UI 在許多地方都遵循這種雙對話方塊的概念；您要到提高權限時才會看到一個對話方塊，當您真的提高權限，您會看到如舊版 Windows 中熟悉的對話方塊。
如果您按一下 [進階] 按鈕，然後按一下 [稽核] 索引標籤，就會看到提高權限按鈕，如 [圖 6] 所示。您沒有提高權限就不能修改稽核內容，即使您對物件有完整控制權，且您是擁有者也一樣。那是因為修改物件 SACL 的能力是由 SE_SECURITY_NAME 權限管理，即 GUI 工具中所謂的管理稽核和安全記錄檔。根據預設，只有系統管理員擁有該權限。不過，在管理員核准模式下 (已啟用 UAC)，會移除系統管理員的這個權限，因此，即使您是系統管理員，也需要提高權限。
圖 6 在 Windows Vista 中修改稽核設定時一律需要提高權限
圖 6 在 Windows Vista 中修改稽核設定時一律需要提高權限
當您修改 ACL 時，關於提高權限需求的最後一個注意事項：所有這些陳述都以您未停用 UAC 為前提。如果您停用 UAC，則所有行為會回復到您在 Windows XP 看到的行為，唯一例外的是對話方塊看起來會不一樣。不過，假如您是以系統管理員的身分登入，則不需要提高權限，因為現在您的權杖內將隨時有 Administrators SID。

其他工具
Icacls.exe 是一個非常有用的工具，是比 cacls.exe 更好的改良品，但它仍有一些缺點。或許其中最值得注意的，就是它無法管理非檔案和非目錄之任何物件的存取權。相較於 Windows XP，Windows Vista 對其他物件的 ACL 做了一些稀疏的變更，但有時候您還是需要管理服務、登錄機碼、甚至 Active Directory® 物件的 ACL。
如果您是命令列慣用者，就需要 subinacl.exe 來執行此動作。Subinacl.exe 包含在支援工具中，您也可以經由下載取得。
不過，我必須警告您，subinacl.exe 並不容易使用。事實上，它有時候簡直就很遲鈍。不過 subinad.exe 是管理存取控制的一個超強工具。每一位系統管理員都需要此工具。

登錄 ACL
登錄 ACL 和檔案系統 ACL 一樣，都有所變更。不過，這些變更的範圍遠小於檔案系統的變更。與舊版 Windows 最明顯的差別在於，由於 Power Users 已經廢棄不用，所以幾乎所有 Power User ACE 都不見了。Power Users 不應該比任何其他使用者擁有更大的權限。它是證實 ACL 真的很複雜的證明，雖然 Power Users 的所有 ACE 並非都真的消失了。只是其中很不巧地漏掉了一些。
當您在登錄中查閱 ACL 時，會在一些地方看到一個叫做 RESTRICTED 之 SID 的 ACE。這並不是 Windows Vista 的新項目，而是一般人不太了解卻很有趣的一個 SID。RESTRICTED SID 代表呈現限制的權杖之程序。限制的權杖是使用 CreateRestrictedToken API 的特殊功能所建立的。此權杖有一個或多個限制 SID，亦即使用於個別存取檢查中的 SID。假設我們有一個以限制的權杖執行之程序。如果該程序嘗試以 RESTRICTED SID 的 ACE 存取物件，則 Windows 實際上會執行兩項存取檢查。第一項是正常存取檢查。第二項的作用與第一項一樣，但只對權杖中的限制 SID 執行。兩項存取檢查都必須通過才行。
目前，有數個 ACL 都使用 RESTRICTED SID，尤其是在登錄上。[圖 7] 顯示此種 ACL 的螢幕擷取畫面。
圖 7 登錄 ACL 在許多地方都包含 RESTRICTED 的 ACL
圖 7 登錄 ACL 在許多地方都包含 RESTRICTED 的 ACL
目前只有少數程序會利用限制的權杖之功能，尤其是在限制 SID 方面。會這麼做的程序範例為主控 Windows 防火牆、基本篩選引擎及診斷原則服務的服務程序。它也使用寫入限制的權杖。根據我的發現，目前 Windows Vista 中只有九個服務有在使用 RESTRICTED 和寫入限制的權杖。
就像在舊版的 Windows 中一樣，登錄權限的最佳作法就是要非常小心地處理。除非是在迫切需要且很細微的情況下，否則請勿修改登錄中的權限。由於登錄的修改涉及整個繼承模型和作業敏感度，如果您不小心修改登錄中的 ACL，很可能會造成嚴重失敗的後果。

結論
就像大部分 Windows 版本一樣，Windows Vista 在存取控制上也有一些細微的變更。不過，和其他最近幾個版本不同的事，其中是由許多次要變更的累積，而造成行為上的大幅改變。UAC 尤其需要多項變更，例如完整性標籤和對 ACL UI 的修改。此外，這也是歷史上首次的 ACL 大掃除。
在許多方面，Windows 上的預設 ACL 在 Windows Vista 中實際上是變得更簡單，這是前所未見的。不過，就像舊版一樣，您應該小心處理存取控制，必須事先有徹底的了解。尤其是涉及新版的 OS 時更是如此。希望使用本文概述的工具，您可以在探索 ACL 時輕鬆許多。

Jesper M. Johansson 是負責軟體安全性問題的首席安全性工程師，也是 TechNet Magazine 的特約編輯之一。他擁有 MIS 博士學位，在電腦安全性領域有 20 年以上的經驗。本專欄是改編自 Roger Grimes 和 Jesper Johansson 所寫的新書 Windows Vista Security:Securing Vista Against Malicious Attacks (Wiley，2007)。


 桌面檔案: Microsoft Desktop Optimization Pack
桌面檔案
Microsoft Desktop Optimization Pack
Wes Miller
此專欄的內容是以 Microsoft Desktop Optimization Pack 搶先版為基礎。本文包含的所有資訊均有可能變更。

自從數年前開始推出軟體保證 (Software Assurance，SA) 授權計劃之後，Microsoft 就持續在 SA 中加入更多內容，為使用者提供更高的附加價值。除了提供授權中所包含之 Microsoft 產品的升級程式，Microsoft 也極力提供
可以協助組織改善 Windows、Office 及其他 Microsoft 軟體使用經驗的產品和技術 (Windows® PE 就是首例之一)。
Microsoft 希望藉由這些工具和程式為使用者提供額外的功能，以降低組織 SA 涵蓋範圍內的 Windows、Office 及其他 Microsoft 應用程式的總持有成本。
Microsoft 在 2006 年併購了數家公司，這些公司也有相似的目標：降低 Windows 和 Windows 應用程式在管理和修復方面的總持有成本和複雜度。Microsoft 已將這些併購的新技術整合在新的產品套件中，以提供更高的附加價值給具有 SA 的客戶。來自 Softricity、DesktopStandard、AssetMetrix 及 Winternals Software 的多項技術，將會在這一年內以 Microsoft® Desktop Optimization Pack (MDOP) 發行。此外，MDOP 也將包含 Microsoft 內部開發的元件，稱為 Microsoft System Center Desktop Error Monitoring。
置於可節省的成本，Microsoft 預估 MDOP 將可以協助組織為每一部桌上型電腦每年節省 $100 美元至 $500 美元，端視您套用 MDOP 時所實施的最佳作法。有關 MDOP 的詳細資訊可以從線上存取，網址為：windowsvista.com/optimizeddesktop。

Microsoft Desktop Optimization Pack 的目標
簡單地說，MDOP 的主要目標是要讓 Microsoft 能夠以更積極、更有彈性的時間表，提供使用者更新穎的管理技術，而不受作業系統發行時程的限制。亦即，Microsoft 希望 Windows XP 和 Windows Vista™ 之間的冗長產品更新空窗期不再出現。藉由在新發行版本之間以可預期的時間表提供新的工具，MDOP 可以讓 Microsoft 彈性滿足使用者的需求，如此便可以讓企業客戶最佳化他們的軟體投資報酬率。
為了要協助企業提升彈性，Microsoft 擬定了一套可以協助客戶實現動態基礎結構的策略 -- 所謂的「動態」是 Microsoft 在 Dynamic Systems Initiative (DSI) 中所定義。如需 DSI 的詳細資訊，請閱讀位於 microsoft.com/business/dsi 中的資訊。
高層的策略理論就此打住。讓我們來看看 MDOP 中所包含的五項技術：
  • SoftGrid Application Virtualization (SoftGrid 應用程式虛擬化)
  • Asset Inventory Service (資產清查服務)
  • Diagnostics and Recovery Toolset (診斷與修復工具組)
  • Advanced Group Policy Management (進階群組原則管理)
  • System Center Desktop Error Monitoring (System Center 桌上型電腦錯誤監控)

SoftGrid Application Virtualization (SoftGrid 應用程式虛擬化)
SoftGrid Application Virtualization 是從 Softricity 取得的技術，顧名思義，其中提供的正是應用程式虛擬化技術。當我首次探索 SoftGrid 時，發現這其實是當初 Windows 2000 IntelliMirror® 應該仿效的模式。為什麼呢？因為應用程式不會發行到用戶端電腦上，而是完全以虛擬化的模式運作。如此可以讓應用程式輕易地提供給用戶端 (或終端伺服器) 系統使用。再者，應用程式還能夠透過集中式管理，甚至在需要時進行回收或更新。相較於傳統的 MSI 和轉換模型，SoftGrid 的模型可以減輕部署應用程式的複雜度並降低相關風險。
SoftGrid 可以視為一種虛擬映像。您可能已熟悉運用磁碟映像部署 Windows (通常還會在其中包括應用程式) 到電腦系統上的觀念。SoftGrid 等於是將應用程式包裝成一個應用程式映像，而非整個作業系統 (OS) 的映像。
SoftGrid Application Virtualization 是由三個關鍵元件所組成：應用程式虛擬化、應用程式傳遞，以及中央管理主控台。
應用程式虛擬化元件本身包括 Windows 檔案系統 (包含系統檔案) 的虛擬化表示、字型、.ini 檔案、COM/DCOM 物件、服務、核心物件 (信號、Mutex)、命名物件，以及所有元件的命名空間。
請勿將 SoftGrid 的虛擬化與 Windows Vista UAC 執行重新導向混淆，這一點很重要。就 UAC 而言，當應用程式嘗試寫入或修改登錄機碼或檔案系統的受保護區域時，會被重新導向至使用者特定的登錄機碼和檔案系統檢視。但是 SoftGrid 則會真的將應用程式虛擬化供作業系統運用 -- 包括所有構成虛擬化應用程式的登錄機碼以及檔案系統元件。SoftGrid 高竿的地方，在於應用程式的定義並非以一個大檔案囊括。而是由數個檔案構成，如下：
  • 高達 4GB 的 SFT 檔案。此檔案包含一個或多個應用程式以及所有該應用程式依存的資源，除了 Windows 的依存性以外，因為這應該已經存在於目的地系統上。
  • 大約 2KB 的 OSD 檔案。此檔案包含應用程式的要求與執行定義。您可以將 OSD 檔案想成是 EXE。
  • 大約 24KB 的 ICO 檔案。這等於是啟動應用程式的捷徑。
  • 大約 13KB 的 SPRJ 檔案。這是由定序器 (Sequencer) (SoftGrid 的核心) 用來發行、開啟、更新及修復現有套件。
SoftGrid Application Virtualization 運作方式的詳細圖表位於下列網站：softricity.com/ products/architecture.asp。
SoftGrid 解決方案的一大優勢，就是可以使用中央管理主控台 (請參閱 [圖 1]) 來判斷哪一些應用程式可以供給定 Active Directory® 的使用者或使用者群組存取。然後應用程式就可以透過產業標準串流通訊協定，迅速地隨選串流給使用者使用。完成安裝之後，應用程式的行為會有如在本機安裝一樣，其中也會允許使用者自訂設定 (即使是透過漫遊使用者設定檔)，就算是用戶端已離線也可以繼續運作。系統管理員還可以動態地或自動地 (例如在指定時間之後) 停止應用程式的存取。
圖 1 SoftGrid 管理主控台
圖 1 SoftGrid 管理主控台
最重要的是，由於應用程式的特殊部署方式，使用時並不需要整個應用程式的所有檔案。只有使用者需要用於執行應用程式的部分才會被下載。試想一下 Microsoft Office 的所有元件都以套件的方式供使用。如果使用者只執行 Word，只有需要用於執行 Word 的元件會被下載 -- 不會下載用於執行 Excel®、PowerPoint®...等元件。一旦使用者執行其中的一個應用程式 (例如 Excel)，相關的元件就會在需要時下載。
ERD 中有什麼？
  • 命令提示字元 (Command Prompt)
  • 檔案總管 (Explorer)
  • 搜尋 (Search)
  • 記事本 (Notepad)
  • 解決方案精靈 (Solution Wizard)
  • 系統管理工具 (Administrative Tools)：自動執行 (Autoruns)、磁碟管理 (Disk Management)、事件檢視器 (Event Viewer)、登錄編輯程式 (Registry Editor)、服務與驅動程式 (Services and Drivers)、系統資訊 (System Information)
  • 網路工具 (Networking Tools)：檔案共享 (File Sharing)、連線網路磁碟機 (Map Network Drive)、TCP/IP 設定 (TCP/IP Configuration)
  • 系統工具 (System Tools)：當機分析程式 (Crash Analyzer)、磁碟管理 (Disk Commander)、磁碟清除 (DiskWipe)、檔案還原 (FileRestore)、Hotfix 解除安裝 (Hotfix Uninstall)、解除鎖定 (Locksmith)、系統檔案修復 (System File Repair)、系統還原 (System Restore)

SoftGrid 的另一個元件，可以自動計量以及檢查授權。如此一來，您不需要另外購置軟體，也能夠繼續合法的使用軟體授權。
幾乎任何應用程式都可以虛擬化。主要的例外包括 Internet Explorer®、其他 Windows 元件 (包括 Hotfix 和 Service Pack)、防毒軟體，以及裝置驅動程式。如果您有興趣進一步瞭解 SoftGrid 的運作方式，同時想要探索其應用，建議您閱讀下列白皮書：Softricity.com。

Advanced Group Policy Management (進階群組原則管理)
DesktopStandard 之所以會出名，是因為他們所開發的工具，可以補強群組原則的不足。藉由提供先前在 MDOP 中稱為 GPOVault 的工具 (如今稱為 Advanced Group Policy Management)，Microsoft 提供客戶一項非常好用的工具，亦即可將功能強大 (有時瀕臨危險) 的 GPO 推進成為一項更細膩、更能夠微調控管的流程。
如果您熟悉來源控制軟體的基本概念，即可將 Advanced Group Policy Management 想像成 Active Directory 群組原則的來源控制機制 (請參閱 [圖 2]，檢視 Advanced Group Policy Management 主控台的螢幕擷取畫面)。系統管理員可以取出現有的原則修訂版本、進行修改，然後再存回，還可以使用群組原則管理主控台般的報告進行稽核。一旦系統管理員對於原則狀態滿意，就可以認可變更並實際套用。當然，這與任何優良的來源控制軟體一樣，萬一有差錯，所做的變更都可以迅速還原到先前的版本，不會造成任何混淆。
圖 2 Advanced Group Policy Management 主控台
圖 2 Advanced Group Policy Management 主控台
此流程的另一項關鍵點，在於可以離線編輯原則，而不需要透過線上操作的模式，在作用中的系統上進行變更。如此可以先在獨立的系統上測試所做的變更，再將變更套用到整個網域或 OU。
最後，Advanced Group Policy Management 還可以透過以角色為基礎的模型，讓變更藉由設計導向的工作流程完成。系統管理員可以建立角色 (例如編輯者、審閱者及核准者)，遂而確保所有的變更都會遵照一定的控管流程進行。亦即，當執行者認為變更可以認可時，可以透過緊密的變更管理機制來確保所有的變更都通過適當的審核。

Asset Inventory Service (資產清查服務)
Asset Inventory Service 是由 Microsoft 併購 AssetMetrix 而取得的技術，這是一項功能強大的清查和資產管理解決方案。與其他 MDOP 元件不同的是，AIS 採用裝載式 Web 模型。AIS 使用的代理程式僅需要佔用極少的資源和頻寬，而且可以單次執行或定期執行，讓系統管理員得以藉由搜尋含有超過 400,000 個應用程式的龐大資料庫 (由 Microsoft 裝載)，來判斷用戶端系統上所安裝的應用程式。然後 AIS 就可以彙總這些資料，並與所購買的軟體授權資料進行比對，以確保符合性並減少軟體授權數量過多的浪費。
有些系統管理員一開始可能會排斥 AIS 的使用，因為其中涉及裝載在防火牆之外的主機資料，而且還會清查內部系統所安裝的軟體。但是請放心，因為 Microsoft 已經在組織保密防護作業上投入大量的心力，其中包括組成 AIS 的應用程式之核心元件的重新編寫。這絕對不會將個別電腦的資料與組織資料連結在一起。Microsoft 也會透過第三者來提供資料傳輸技術的認證，讓客戶可以完全信賴 AIS 所採用的模型。

Diagnostics and Recovery Toolset (診斷與修復工具組)
您應該已經知道 (如果您曾經在這幾個月閱讀過我在專欄中提供的背景資料)，在 Microsoft 併購 Winternals 時，我當初是 Winternals 的一員。任職於 Winternals 時，我擔任大多數產品的產品經理，其中包括 Winternals Administrator’s Pak。該產品就是 Microsoft Diagnostics and Recovery Toolset (DaRT) 的前身。雖然有些曾經包含在 Administrator’s Pak 中的工具並沒有在 DaRT 中提供，組成 ERD Commander 產品的關鍵元件都依然存在。
DaRT 的目標是要提供一組工具，以協助您診斷系統問題，即使系統無法正常開機。而且您通常可以透過離線模式修復問題。
ERD Commander 會運用 Windows PE 來開啟無法開機或是無法正常開機的電腦系統。一組工具會在一個自訂的、有如 Windows 檔案總管的使用者介面中提供。其中的兩項工具：Crash Analyzer 以及 FileRestore，也可以透過線上使用。但是，這些必須安裝在每一部您想要在其中執行的電腦系統上，如果您沒有使用 ERD Commander 進行離線診斷或修復。
DaRT 版本的 ERD Commander 顯示於 [圖 3] 中。包含在 ERD Commander 元件中的工具清單列於資訊看板中。除了檔案總管 (Explorer) 工具以外，前五項工具與一般 Windows 安裝的應用程式相同。其中的「檔案總管 (Explorer)」與「開始功能表」應用程式都是特別開發的版本，為的就是要能夠在 Windows PE 底下執行。
圖 3 ERD Commander
圖 3 ERD Commander
「自動執行 (Autoruns)」是一項工具，衍生自同名的 Sysinternals 工具，其中可以讓您看到所有已設定在系統開機或使用者登入之後會啟動的應用程式。「磁碟管理 (Disk Management)、事件檢視器 (Event Viewer)、登錄編輯程式 (Registry Editor)、服務與驅動程式 (Services and Drivers)、系統資訊 (System Information)」均為一般使用者介面中的工具，提供的功能與名稱類似之 Windows 工具大致上相同。「服務與驅動程式 (Services and Drivers)」非常好用，因為此工具可以在系統因為裝置驅動程式或服務無法正常運作時，協助您讓系統開機。最後，「Windows 登錄編輯程式 (Windows Registry Editor)」也包含在其中，以便您操作離線系統的登錄機碼。
ERD Commander 底下也有連線到網路的功能。雖然系統已自動組態為透過 DHCP 連線，您可以使用「TCP/IP 設定 (TCP/IP Configuration)」小程式來指定固定的 IP 位址。無論您是使用 DHCP 或固定 IP 位址，都可以連線網路磁碟機並複製檔案至當機的系統或複製該系統上的檔案，或是使用「檔案共享 (File Sharing)」功能將該系統變成檔案伺服器，以便將當機之系統上的檔案，複製到可正常運作的系統上。
最後，其中還包含一系列的其他工具。「當機分析程式 (Crash Analyzer)」會使用 Debugging Tools for Windows (必須另行下載和安裝 -- 雖然這是免費的，可是經常會更新) 來診斷當機的原因。您可以在 ERD Commander 底下以離線的模式執行 (如果系統無法開機)，或是複製 DMP 檔案到正在執行且已安裝 DaRT 的系統上以進行診斷。找出問題之後，如果兇手是新的服務或驅動程式，您就可以使用「服務與驅動程式 (Services and Drivers)」工具來停用該服務或驅動程式，以觀察系統是否可以因而恢復正常運作。
「磁碟管理 (Disk Commander)」可以協助您還原不小心刪除或已損毀的分割區，也可以還原已刪除的檔案群組或目錄。相對的，「磁碟清除 (DiskWipe)」則可以讓您執行符合 DoD 的全磁碟或磁碟區的清除。「檔案還原 (FileRestore)」可以讓您 (透過線上或以離線模式) 還原不小心刪除的單一檔案。請記得無論您使用哪一個工具，檔案的類型以及已刪除的時間和之後的磁碟使用情況，都會影響檔案是否能夠成功還原。
萬一 Windows Hotfix 或 Service Pack 導致系統無法正常開機，您就可以使用「Hotfix 解除安裝 (Hotfix Uninstall)」來選擇性地解除安裝一個或多個 Hotfix 或 Service Pack。您必須重新開機才能完成程序，因為 Windows 無法在離線模式完全移除應用程式。但是這樣通常就可以再正常開機。
「解除鎖定 (Locksmith)」是當初 Winternals 的 ERD Commander 工具組中，最受歡迎的工具之一。此工具可以讓您重設任何本機使用者的密碼。這無法用於網域控制站，也無法重設網域使用者的密碼 -- 這通常會用來重設本機系統管理員的密碼，原因可能是忘記密碼或使用者已離開組織。「系統檔案修復 (System File Repair)」會檢查所有受保護的系統檔案，判斷檔案是否已損毀，並在需要時進行取代。「系統還原 (System Restore)」，顧名思義，可以讓您在 Windows XP 系統上還原至任何 Windows 系統還原點 (若要使用此功能，電腦必須安裝 Windows XP 且已建立系統還原點)。我也是受惠於此獨特功能的眾多使用者之一。
ERD Commander 和 DaRT 中的工具組看似涵蓋範圍很廣，但這些都是 Winternals 一路走來所開發之功能強大的公用程式組合。我相信您一定會在系統修復和疑難排解過程中，發現它們價值不斐且非常好用。

System Center Desktop Error Monitoring (System Center 桌上型電腦錯誤監控)
System Center Desktop Error Monitoring (DEM) 可以讓任何組織以快速又簡便的方法，建立 Windows 當機與應用程式發生錯誤之問題的中央診斷機制。與其將當機和錯誤報告傳送給 Microsoft，DEM 會使用群組原則以及內建的 Windows 錯誤報告 (Windows Error Reporting) 功能，將報告傳送至您指定的組織伺服器以供診斷 (而且這不需要額外的軟體代理程式)。所有的 DEM 伺服器資料都儲存在 SQL Server 資料庫中，因此您可以輕易地查詢所收集到的資料，以進行內部的應用程式和報告分析。這可以讓您主動診斷組織中所發生的問題。有了這些資訊，您就可以委任事件的報告，找出最常造成當機和錯誤的原因，並確保 Windows 和應用程式的修補程式適時安裝，以縮減或避免系統停機時間。
您也可以設定 DEM 伺服器將結果上載給 Microsoft，以及讓 DEM 自動下載 Microsoft 和其他廠商之應用程式的最新疑難排解資料。萬一發生當機或錯誤時，還可以從用戶端蒐集其他的相關資料。

MDOP 的授權
客戶若要取得 MDOP 的授權，首先需要具備現有的 Microsoft SA 合約。具備先決條件之後，此工具的授權費用為每一部桌上型電腦 $7 至 $10 美元。另有提供大量授權折扣以及教育機構優惠價。
MDOP 無法在 SA 合約以外提供，但下列情況除外：客戶可以在終端伺服器 (請參閱 softricity.com/solutions/sbc.asp) 或 SMS (see softricity.com/products/softgrid-sms.asp) 上使用 SoftGrid 技術產品，而且 AssetMetrix 技術產品將會提供於未來的 SMS 以及 System Center Configuration Manager 版本中。

上市時間以及更新消息
MDOP 的基本元件已經發行。元件的發行狀況如下：
  • Microsoft 已經在 2007 年初開始發行 SoftGrid。
  • Microsoft DaRT 已經在 2007 年 5 月發行。
  • GPOVault 技術產品應該會在 2007 年 7 月發行。
  • Desktop Error Monitoring 應該會在 2007 年 7 月加入 MDOP 發行。
  • AssetMetrix 技術產品應該會在 2007 年 7 月發行 Beta 版，且將於 8 月正式發行。
  • 目前計劃將於 2007 年底左右發行 DaRT 元件的更新，主要目的是要加強與 Windows Vista 的相容性。.
計劃未來將持續發行 MDOP 的新版本，以增強功能、提供升級版本及嶄新功能，頻率為每年兩次。

MDOP 的發展方向
如上所述，AssetMetrix 技術產品的關鍵元件將會整合到未來的 System Center Configuration Manager 版本中。事實上，將來 Microsoft 應該會陸續擴充 MDOP 功能，且某些功能將會合併到 Microsoft 的基準部署、管理與組態技術產品中。嶄新技術 (有些由 Microsoft 開發，有些從其他公司取得) 也將會加入未來的 MDOP 版本中。基本上，MDOP 是尖端管理與組態技術的組合，且將持續進化。

Wes Miller 任職於美國德州奧斯丁 Pluck 公司，擔任開發經理。他之前任職於同樣位在奧斯丁的 Winternals Software，並且曾在 Microsoft 擔任 Windows 的專案經理與產品經理。Wes 的連絡方式：technet@getwired.com。
我要特別感謝 Chad Jones 和 Gavriella Schuster 兩位 Microsoft Desktop Optimization Pack 的產品經理，在我撰寫這篇專欄時提供內容上的協助。


 Windows 機密文件: 安全模式的修復能力
Windows 機密文件
安全模式的修復能力
Raymond Chen

當 Windows 安全模式 (亦稱為「完蛋了，怎麼變得亂七八糟，拜託把它修好」模式) 首次在 Windows® 95 中推出時，其目標不僅是要停用驅動程式，更是要修復有機會自動修復的項目。
例如，當您進入安全模式時，[Windows 檔案總管] 會檢查桌面的所有圖示，以確保所有圖示都看得見，因為其實是有可能將圖示置於螢幕以外的位置。
如果您想要體驗我所說的狀況，請先將兩個圖示放在桌面上，一個在螢幕的左邊緣，另一個在右邊緣。使用 Ctrl+ 按一下滑鼠左鍵以同時選取兩個圖示，然後將左邊緣的圖示拖曳到螢幕的右邊緣。當您這麼做，另一個圖示也會跟著移動，以保持與您正在拖曳之圖示的相對位置。於是，另一個圖示會移動到螢幕以外的範圍。
安全模式可以讓使用者對 Windows 進行疑難排解
安全模式可以讓使用者對 Windows 進行疑難排解
如果 [Windows 檔案總管] 沒有在安全模式修復圖示的位置，可想疑難排解的指示將會造成疑惑而無法協助使用者：
  1. 以安全模式開啟電腦。(這可以瞭解)。
  2. 按兩下 [我的電腦] 圖示。(咦，找不到 [我的電腦] 圖示耶)。
  3. ...
原來 [我的電腦] 圖示根本沒有顯示在螢幕上，亦即無法存取。如此一來，您連疑難排解的第二個步驟都將無法執行。
曾經有使用者抱怨說，「您們不應該自動修復圖示。如果使用者碰到問題而打電話給技術支援服務部門，技術支援工程師只要請使用者在桌面上按一下滑鼠右鍵，然後選取 [重新整理] 選項即可。這樣就可以修復此問題，而且安全模式不需要操作我的圖示」。
首先，您真的認為「使用者碰到問題而打電話給技術支援服務部門」的事件會發生嗎？當使用者需要撥打電話求救時，我們就已經失敗了。
此外，如此的建議與安全模式的美意是背道而馳。使用者之所以會進入安全模式，是因為電腦似乎有不尋常的行為，但是他們不見得知道進入安全模式之後要做什麼。他們其實只是在看會發生什麼事情。「有點怪怪的，試試看安全模式吧」。在 Windows 95 中，我們瞭解到並運用這樣的思考模式，於是在安全模式中實作了各種自動修復動作。結果相當不錯。
而且，如果使用者來電，然後我們告訴他「只要在開機時進入安全模式，就可以解決這樣的問題」，他們一定會想，「原來那麼簡單，我應該自己就可以嘗試說」。
但是如果您需要給他們一長串的指示，例如：「開機時進入安全模式，在此處按一下滑鼠右鍵，選取某功能表選項，然後按一下某對話方塊...」，使用者雖然可以根據指示解決問題，但是這將無法提升他們對於電腦的接受度。他們一定會覺得無力而氣餒。電腦應該要為使用者開拓新的創意和空間，而不是讓使用者覺得很複雜又無助。「我肯定無法自己解決這樣的問題。電腦真是複雜又難用」。

Raymond Chen 的網站「The Old New Thing」以及採用相同標題做為個書名的出版品 (Addison-Wesley，2007)，都討論 Windows 的歷史和 Win32 程式設計。他是一位注重安全的人。