哪些 SharePoint 技術適合您？為了努力找出答案，您可能已經仔細檢查過沒有盡頭似的類別列表（包括協作和社會性計算、門戶、企業搜索、企業內容管理、業務流程和形式、商業智能，以及開發人員平臺功能），也可能比較過 Windows SharePoint Services (WSS) 3.0、Microsoft Office Search Server 2008 Express、Microsoft Office Forms Server 2007 和 Microsoft Office SharePoint Server (MOSS) 2007 提供的功能。不過，有項技術您可能從未考慮過，因為 Microsoft 沒有將其列在 SharePoint 產品及技術范圍內，這就是企業項目管理（Enterprise Project Management，EPM），該技術通過 Microsoft Office Project Server (MOPS) 2007 啟用。

但 MOPS 2007 是 SharePoint 技術，它構建在 WSS 3.0 的基礎之上，并以與 MOSS 2007 兼容的方式進行擴展。如果您希望通過任務、資源和預算管理（而不是使用 WSS 3.0 和 MOSS 2007 中包含的輕型任務管理功能）的方式提高部門內部以及各部門之間的小組協作效率，MOPS 2007 可以說是正確的選擇。通過 MOPS，您可以將小組站點轉變成項目工作區、管理部門內部和各部門之間的小組協作，以及為整個組織建立牢固的 EPM 基礎。不過，您首先需要戰勝部署挑戰。

在本專欄中，我將討論在 Windows Server 2008 環境中通過 SQL Server 2005 SP2 和 WSS 3.0 SP1 來部署 MOPS 2007。首先，我將從系統架構師的角度對 MOPS 體系結構做簡短評論，說明各組件如何與 WSS 3.0 集成。了解這一信息后，將更容易進一步討論典型部署和您可能遇到的集成挑戰（例如，應用程序池配置問題、缺少訪問權限、隊列系統啟動錯誤以及與 SQL Server 2005 Analysis Services 相關的問題）。

為了演示部署和故障排除步驟，我將使用一個基本的測試環境，其中包括服務器場中的兩個 WSS 3.0 服務器、一臺專用的域控制器以及一臺單獨運行 SQL Server 的計算機，這個環境類似于一直用于此 SharePoint 專欄的測試環境。您可以在 TechNet 雜志網站上本專欄的附屬材料中找到相應的工作表和分步說明。

Project Server 體系結構

MOPS 2007 是最先進、最復雜的 SharePoint 應用程序之一。它充分利用了 WSS 3.0 平臺進行集中式管理、站點配置、身份驗證和安全性設置。另外，MOPS 2007 還添加了更多組件，例如 25 個通用和專用的 MOPS Web 部件、每個 Project Web Access (PWA) 站點有多達四個 MOPS 數據庫的新集合。每個組件都通過一組 21 個公用和內部 MOPS Web 服務進行訪問，這些 Web 服務聯合構成 Project Server Interface (PSI)，如圖 1 所示。您可以在 MSDN 上查找有關 MOPS Web 服務的詳細信息。

圖 1 SharePoint 與 MOPS 2007 集成（單擊圖像可查看大圖）

MOPS 2007 體系結構依賴于分布在客戶端工作站、應用程序服務器和數據庫服務器間的各種組件。我會在本專欄中討論其中最重要的組件，但如果您對所有的技術細節都感興趣，請閱讀 Project 2007 SDK 中的“Project Server 體系結構”文檔。

請記住，在閱讀 SDK 時，PWA Web 部件和 Microsoft Office Project Professional 2007 并不直接訪問 PSI Web 服務。SDK 建議客戶端直接呼叫 PSI，但大多數應用程序實際上使用 PSI Forwarder，這是 PWA 站點中的一個組件，提供對 PSI Web 服務的間接訪問。只有使用系統級權限運行的基于服務器的組件（如隊列服務和事件服務），才直接呼叫 PSI。在故障排除環境中記住這個小細節很重要，這是由多種原因決定的，特別是：

1. PWA 站點定義數據庫的上下文（每個 PWA 站點都有獨立的草稿、已發布、存檔和報告數據庫）和用戶權限，但不會授權一般用戶帳戶訪問 PSI Web 服務。
2. PSI Forwarder 不支持模擬，但可以使用 PWA 站點的應用程序池帳戶代表用戶訪問 PSI Web 服務。
3. 如果服務器場包含多個應用程序服務器實例，則 PSI 呼叫并不一定需要使用本地 PSI Web 服務。

SharePoint 集成

現在，讓我們深入討論一下 MOPS 與 SharePoint 的實際集成。從 SharePoint 管理員的角度來看，MOPS 是共享的 Web 應用程序，作為服務器場服務在 SharePoint 3.0 管理中心進行管理。這對于熟悉 MOSS 2007 中的共享服務提供程序 (SSP) 的管理員來說，就相當簡單了。

不過，如果您是 WSS 3.0 管理員，而且剛剛接觸 SSP 管理，您應該參考一下附屬材料中提供的“部署 Project Server 2007”工作表，以便了解創建和配置 SharePoint 場的共享服務和 PWA 站點的分步說明。安裝和配置 MOPS 之后，您便可以在 IIS 管理器中分析系統實施。如圖 2 所示，在 MOPS 應用程序服務器上會顯示共享服務、SSP 管理和站點集合的各自的網站。

圖 2 通過 PWA 和 PSI Forwarder 訪問 Project Server 2007（單擊圖像可查看大圖）

客戶端通過 PWA 站點中的 _vti_bin/PSI 虛擬目錄訪問 PSI Web 服務。不過，PSI Web 服務并不在此虛擬目錄中。_vti_bin/PSI 虛擬目錄對應以下物理路徑：%COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI。您會發現此目錄包含 web.config 文件，該文件在 <http Handlers> 部分指定對 *.asmx 文件（即基于 ASP.NET 的 Web 服務）的所有 HTTP 請求都應該傳送到自定義 HTTP 處理程序，并通過 Micro soft.Office.Project.Server.PSIForwarder HandlerFactory 實例化。

該自定義 HTTP 處理程序是 PSI Forwarder。PSI Forwarder 建立對實際 PSI Web 服務的新 HTTP 連接，轉發客戶端的 HTTP 請求，然后將結果返回到客戶端。

借助 HTTP，PSI Web 服務可通過共享服務 Web 應用程序（位于 Office Server Web 服務站點中）的 PSI 虛擬目錄供 PSI Forwarder 使用。此虛擬目錄將默認映射到物理路徑 %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI，您可以在此處找到 MOPS 2007 *.asmx 文件。

稍后，我將詳細介紹 Office Server Web 服務站點。現在，從圖 2 獲得的最重要的信息是，PSI Forwarder 使用 PWA 站點的 Web 應用程序池帳戶標識（而不是當前訪問 PWA 站點的用戶）與 PSI Web 服務通信。

服務器場部署

在服務器場部署過程中，PSI Forwarder 的另一個重要作用是采用不同的 Web 前端服務器和應用程序服務器來提高系統可伸縮性和可用性。MOPS 前端服務器是 WSS 3.0 服務器，不能承載 PSI Web 服務或其他 MOPS 服務（例如，隊列服務和事件服務），但可為客戶端提供對 PWA 站點（包括 PSI Forwarder）的訪問權限，如圖 3 所示。

圖 3 中小型 MOPS 2007 服務器場（單擊圖像可查看大圖）

另一方面，應用程序服務器是裝有一套完整的 MOPS 組件和服務的 WSS 3.0 服務器。應用程序服務器可以承載 PWA 站點，但通常只為前端服務器提供后端服務，并且不運行 WSS Web 應用程序服務。您可以在 MOPS 安裝期間選擇服務器角色。

圖 3 說明了中小型服務器場的配置。根據您的組織的需求，您可以添加其他的前端服務器以增強可伸縮性，還可以添加其他應用程序服務器來提高可用性。您沒必要為 MOPS 應用程序服務器配置負載平衡群集，這是因為如果服務器場中存在多個 MOPS 應用程序服務器，PSI Forwarder 會自動對 PSI 請求進行負載平衡。有關 MOPS 部署選項的詳細信息，請參閱Office Project Server 2007 部署指南。

歡迎使用 IIS 7

理論到此為止！現在我們來解決您在部署 MOPS 2007 的過程中可能遇到的一些實際問題。我最喜歡的一個問題與 PWA 站點的主機命名的站點集合有關。在這種情況下，在 Project Web Access Site 頁面上選擇“將 Project Web Access 路徑用作主機標頭”復選框，隨后輸入完整的 PWA URL（例如，pwa），您就可以順利部署 MOPS、配置 SSP 以及在主機標頭模式中配置 PWA 站點。然后，當所有資源都配置成功后，您嘗試打開站點，看到的卻是標準的 IIS 7“歡迎使用”屏幕，而不是 PWA 屏幕。

如果默認網站未經過 SharePoint 擴展，而且 PWA URL 也沒有其他網站具有適當的站點約定，就會發生這種情況。如果沒有明確的站點約定，IIS 就會將 pwa 請求與非擴展的默認網站關聯，因此，您看到的是“歡迎使用”屏幕。您可能希望 SharePoint 3.0 管理中心將必要的約定添加到您選擇承載 PWA 站點的 SharePoint Web 應用程序，但情況并非如此。

若要解決此問題，您必須按附隨的“故障排除 IIS 和 PWA”工作表說明的那樣，使用 SharePoint 擴展默認網站，然后使用此站點集合來配置 PWA 站點。或者，您可以將 IIS 管理器中缺少的站點約定手動添加到為 PWA 選擇的 Web 應用程序。別忘了在宿主 PWA 站點的所有 WSS 服務器上執行此步驟。

會話數據庫權限

如果您決定擴展默認網站，請確保使用應用程序池的域帳戶 — 請參閱“規劃系統管理和服務帳戶 (Office SharePoint Server)”，否則，在配置 PWA 站點后，您將碰到與權限有關的問題，這些問題通常會在不提供 SharePoint 錯誤消息的情況下顯現出來，如圖 4 中的出現的問題。

圖 4 訪問 SSP 數據庫時出錯（單擊圖像可查看大圖）

若要查找更有用的信息，您應查看位于 %COMMONPROGRAMFILES %\ Microsoft Shared\Web Server Exten sions \12\LOGS 目錄中的跟蹤日志。如果您的服務器場包含多個負載平衡的 Web 前端服務器，這可能是項繁瑣的任務。

出于進行故障排除的考慮，更改 PWA 主機名稱的 DNS 記錄然后將其暫時指向一部前端服務器，是個不錯的辦法。如此一來，您就知道是哪個服務器處理客戶端請求，從而只需檢查一個服務器的跟蹤日志文件即可。

在記事本中打開最近的日志文件，并搜索“無法打開數據庫”的條目。如果找到此條目，就可以知道您要處理數據庫權限的問題。例如，圖 4 中的跟蹤日志說明帳戶 LITWARE\WSS02$ 不具有對數據庫 SharedServices1_DB 的訪問權限。這很清楚地表示 PWA 站點是使用網絡服務標識運行的。

LITWARE\WSS02$ 是 Web 前端服務器的計算機帳戶，而 SharedServices1_DB 是共享服務提供程序數據庫。除了其他用途，此 Web 前端服務器使用此數據庫來在 ASPStateTempSessions 表中維持 ASP.NET 會話階段狀態數據，但是 LITWARE\WSS02$ 并不具備對該數據庫的訪問權限。

要特別注意的是，您必須將共享服務提供程序數據庫包含在每周的數據庫維護活動中，以確保穩定的系統性能。例如，您應該使用 SQL 命令 TRUNCATE TABLE ASPStateTempSessions，將過期的會話階段狀態數據從 ASPStateTempSessions 表中刪除，如“ 將 Project Server 2007 部署到服務器場環境”中所述。

與網絡服務相關的配置問題很容易令人困惑，所以我將仔細討論一番。域帳戶（例如 LITWARE\SspConfig Admin）適用于服務器場中的應用程序池，這是因為它們在所有計算機上完全一樣。而網絡服務帳戶 (NT AUTHORITY\ NETWORK SERVICE) 在每臺計算機上都不一樣。在名為 wss02.litware.com 的前端服務器上，NT AUTHORITY\NETWORK SERVICE 帳戶會轉換成 LITWARE\WSS02$。但在名為 sql01.litware.com 的服務器上，NT AUTHORITY\ NETWORK SERVICE 帳戶則是指 LITWARE\SQL01$。問題就出在這里。

如果在 SQL Server Management Studio 中檢查 SharedServices1_DB 的 SQL Server 權限，您可以看到 NT AUTHORITY\NETWORK SERVICE 帳戶具有 db_owner 權限，并嘗試授權使用網絡服務帳戶的應用程序池訪問共享服務提供程序數據庫。但請記住，這只在單一服務器的安裝環境中奏效。

您可以明確地授與 LITWARE\WSS02$ 及其他所有 WSS 服務器帳戶（可能是 LITWARE\WSS01$ 等）SharedServices1_DB 的 db_owner 權限，但改用應用程序池的域帳戶更妥當，因為這樣一來，所有前端服務器都將使用 SharePoint 已授與其必要數據庫權限的相同標識。

共享服務權限

如果您的 PWA 站點的應用程序池因某種原因使用網絡服務帳戶，您還會碰到與 SSP 相關的權限問題。還記得我曾提到在 PWA 站點應用程序池帳戶的上下文中，PSI Forwarder 可能代表用戶訪問 PSI Web 服務嗎？如果此帳戶不具備訪問 Office Server Web 服務站點的權限，您會再次收到常見的 SharePoint 錯誤消息。這次，前端服務器上的跟蹤日志會指出“請求失敗，HTTP 狀態 401: 未經授權”，如圖 5 所示。

圖 5 請求失敗，HTTP 狀態 401: 未經授權（單擊圖像可查看大圖）

請記住，此錯誤并不是指 PWA 中的用戶權限。在 PWA 站點中授與的 SharePoint 權限確定了哪些用戶可以訪問該站點的 _vti_bin/PSI 虛擬子目錄，但這些用戶并不會獲得對共享服務 Web 應用程序或該應用程序服務器上的 PSI Web 服務的訪問權限。

即使您是 PWA 站點集合管理員，如果 PWA 站點的應用程序池帳戶不具備對 PSI Web 服務的訪問權限，MOPS 也依然會失敗。如果您忽略對服務器場中的應用程序池使用域帳戶的建議，而改用網絡服務帳戶，情況更是如此。

若要驗證應用程序服務器上的 SSP 訪問權限，可在 Office Server Web 服務站點的根目錄中（默認為 %PROGRAMFILES%\ Microsoft Office Servers\12.0\Web Services\Root）查看 web.config 文件。您可能會注意到 <authorization> 部分中的 NT AUTHORITY\NETWORK SERVICE 條目，它應該用于授權使用網絡服務帳戶的應用程序池。但是，此條目還是無法完成該任務，因為它只參考本地計算機，而本地計算機并不是前端服務器。

最佳策略是更改應用程序池配置，并使用域帳戶。但若堅持使用網絡服務帳戶，您必須明確授權前端服務器帳戶。

請勿直接編輯應用程序服務器上的 web.config 文件，否則 SharePoint 會覆蓋您的更改。請改用 SharePoint 3.0 管理中心來授與缺少的權限，如“測試共享服務提供程序訪問權限”工作表所述。另外，還需驗證配置，方法是使用簡單的 ASP.NET 應用程序來建立與 PSI Web 服務的直接 HTTP 連接，例如 SSPCheck（包含于附屬材料中）。請確保您在 PWA 站點的應用程序池下運行 ASP.NET 測試應用程序，以獲取可靠的結果。

Windows 防火墻

到目前為止，打開 PWA 應該不成問題 — 當然啦，除非您嘗試通過 Web 前端服務器訪問 PWA，而 MOPS 應用程序服務器上的 Windows 防火墻阻止了 TCP 端口 56737 和 56738。這些是分配給 Office Server Web 服務站點用于 HTTP 和 HTTPS 通信的默認端口。

當創建 Office Server Web 服務站點時，SharePoint 并不會在 MOPS 應用程序服務器上自動打開這些端口。如果您在應用程序服務器上啟動了 Windows 防火墻，則必須手動創建防火墻規則，以允許這些端口的數據傳輸，使前端服務器能夠訪問 PSI Web 服務。如果防火墻阻止了這些端口，您會收到圖 6 中顯示的錯誤消息，同時前端服務器上的跟蹤日志將指出“連接的主機未能響應”。

圖 6 Project Web Access 無法連接到 Project Server（單擊圖像可查看大圖）

MOPS 服務和服務帳戶

解決了前端/后端通信問題后，您就應該能夠訪問 Project Web Access 了。可喜可賀！現在是時候把重點放在更困難的特定于 MOPS 的問題上了。深吸一口氣，然后打開您的 MOPS 應用程序服務器上的應用程序事件日志，如果您看到成千上萬條錯誤消息指出“無法啟動隊列系統”（如圖 7 所示），千萬別驚訝。您還可能注意到 MOPS 服務導致 CPU 使用率幾乎為 100%。

圖 7 無法啟動隊列系統（單擊圖像可查看大圖）

隊列系統是 MOPS 應用程序基礎結構的主干，用于 MOPS 數據庫的插入和更新請求，以便處理、運行清理和維護任務，它還可以更新用于數據分析任務的報表數據庫。這在“Microsoft Office Project Server 2007 隊列系統”一文中有詳細介紹。根據本文，此隊列系統依靠 Windows 服務，在程序集 Microsoft.Office.Project.Server.Queuing.exe 中實現，并且在 SharePoint 配置管理和計時器服務帳戶的標識下運行，以訪問服務器場的配置數據庫。

啟動時，Windows 服務將檢索配置數據庫的所有 SSP 的列表，包括相應的 SSP 管理員帳戶及其加密密碼，然后在相應的 SSP 管理員帳戶的上下文中，針對與 PWA 站點相關的每個 SSP 啟動額外的 Microsoft.Office.Project.Server.Queuing.exe 進程。換句話說，Microsoft.Office.Project.Server.Queuing.exe 在不同的帳戶下啟用自身的多個實例，因此，在 MOPS 應用程序服務器上運行的 Microsoft.Office.Project.Server.Queuing.exe 進程總數等于 SSP 的數量與一之和。

額外的進程實例是隊列工作進程。每個單獨的隊列工作進程都將從與它相關聯的 SSP 確定自己的一組 PWA 站點、為每個 PWA 站點啟動不同的輪詢線程，以及開始處理排隊等候在相應 PWA 站點數據庫的任務。這正是隊列系統的工作方式，您可以在 Windows 任務管理器中就此進行驗證。

在服務器場的 MOPS 應用程序服務器上，若有一個 SSP 與 PWA 站點相關聯，則會出現兩個 Microsoft.Office.Project.Server.Queuing.exe 進程 — 一個以配置管理帳戶的身份運行，另一個則以 SSP 管理員帳戶的身份運行。在我的測試環境中，這些帳戶是 WssConfigAdmin 和 SspConfig Admin，如圖 8 所示。

圖 8 進程間通訊因訪問被拒絕而失敗（單擊圖像可查看大圖）

為什么無法啟動隊列系統？應用程序事件日志中的錯誤條目提供的信息不足，但是，如果您在 SharePoint 3.0 管理中心中的“操作”選項卡上的“診斷日志記錄”下，暫時將最低級別事件設置為所有類別的跟蹤日志報告，即可獲得更多詳細信息。

圖 8 顯示了最終的跟蹤日志，如果您仔細查看，會看到 ProjectQueueService（整體 Window 服務）啟動了 QueueExecService（隊列工作進程），但 QueueExecService 進程因訪問被拒絕而失敗。因為 QueueExecService 失敗，ProjectQueueService 便嘗試重新啟動它，但是又因相同的原因再次失敗，所以它繼續耗用 CPU 周期，以上千個錯誤填充事件并跟蹤日志，像個無盡的循環。

可惜的是，即使是最詳盡的跟蹤日志也不會揭示訪問被拒錯誤的特定原因。但是別泄氣，通過排除，您就可以迅速地找出根本原因。

如果您在 SharePoint 3.0 管理中心中更改 SSP 管理員帳戶，并且指定配置管理帳戶 (WssConfigAdmin)，隊列系統便會啟動。反過來做也奏效，只要將 SSP 管理員帳戶 (SspConfigAdmin) 保持不變，然后將它用作 Windows 服務的服務帳戶，隊列系統也會啟動。

隨后，配置管理帳戶和 SSP 管理員帳戶就都具備了所有必要的權限，隊列系統只在 Project QueueService 和 QueueExecService 使用不同的帳戶時才不會啟動。

這很清楚地指出了要在本地計算機上彼此交互的不同進程之間存在權限問題。畢竟，ProjectQueueService 和 QueueExecService 進程都必須彼此監控，才能確保服務行為的一致性（注意圖 8 的跟蹤日志中的 ProcessWatcher 條目）。例如，當您關閉 ProjectQueueService Windows 服務時，所有 QueueExecService 工作進程也必須隨之關閉。

之所以會產生錯誤，是因為嘗試訪問在不同的安全性上下文中運行的進程。訪問另一個安全性上下文中的進程需要提升的權限。即使服務帳戶可能具有這些權限，但 Windows Server 2008 仍會拒絕訪問，這是因為系統會默認啟用用戶帳戶控制 (UAC)，而這會導致進程以標準權限運行。

只要您禁用 UAC，ProjectQueueService 和 QueueExecService 進程便可以使用提升的權限運行，而且隊列系統也將啟動。是使用配置管理帳戶作為所有 SSP 的管理員帳戶，進而以相同的帳戶來運行所有隊列進程，還是通過禁用 UAC 來減弱 MOPS 應用程序服務器上的安全性，都由您選擇。

Analysis Services 集成

如果您按照“將 SQL Server 2005 Analysis Services 與 Project Server 2007 多維數據集生成服務配合使用的要求”（發表日期為 2007-04-05）中的說明操作，可能會碰到 SQL Server 2005 Analysis Services 問題，就讓我們就此為本專欄下結語。如果您按照說明中的方法，通過創建 SQL Server 2005 數據庫來創建 Analysis Services 存儲庫，當嘗試在 PWA 中生成多維數據集時，最后可能會收到圖 9 中所示的錯誤。

圖 9 由于不正確的 Analysis Services 配置而產生多維數據集生成錯誤（單擊圖像可查看大圖）

重點是，MOPS 2007 是針對 SQL Server 2000 Analysis Services 而設計的。SQL Server 2005 Analysis Services 需要其他配置步驟才能實現向后兼容性。SQL Server 2000 版本將關于多維數據集生成的存儲庫信息存儲在 Microsoft Jet 數據庫中，雖然您可以遷移 Jet 數據庫以與 SQL Server 2005 搭配使用，但在全新的 MOPS 部署中沒必要這么做。

我剛剛提到的 TechNet 文章介紹了如何配置 SQL Server 2005 來模擬 Jet 數據庫的功能（無論 Jet 數據庫是否真的存在）。但該文卻沒有提到，無論是將 Analysis Services 配置為使用 Jet 數據庫（舊方法），還是使用預先配置的 SQL Server 2005 數據庫（首選方法），MOPS 仍會在數據庫服務器上檢查 .dso 文件共享中的存儲庫鎖定信息。

除非此文件共享確實存在，并且 SSP 管理員帳戶對此文件共享具備完全控制訪問權，否則，多維數據集生成將失敗，并顯示圖 9 所示的權限錯誤。為了使 SQL Server 2005 Analysis Services 與 MOPS 多維數據集生成服務正常運行，請遵循“配置多維數據”集隨附工作表中所述的步驟。

結論

MOPS 2007 并不容易部署，它的體系結構復雜，而且成功部署涉及到許多步驟，其中包括從正確規劃服務器場配置、在應用程序服務器和 Web 前端服務器上安裝二元文件和運行 SharePoint 產品和技術配置向導，到在 SharePoint 3.0 管理中心內配置應用程序池、共享服務、SSP 管理站點和 PWA 站點，最后到在 SQL Server Management Studio 中安裝 Analysis Services 等。

使部署更具挑戰性的是 Windows Server 2008 干擾安全性功能，例如 Windows 防火墻和 UAC、SharePoint 管理工具中的漏洞，以及 MOPS 部署文檔的疏漏。您不能單靠 SharePoint 3.0 管理中心來警告您應用程序池是否在服務器場中使用網絡服務帳戶、是否自動應用所有必要的配置更改（例如 IIS 站點綁定和 Windows 防火墻規則），或是檢查已配置的 PWA 站點的操作狀態。

另外，也別期望一切都有現成的可用。請確保您充分了解 MOPS 體系結構和依賴項，遵守產品建議，并且通過創建測試項目計劃和資源，徹底驗證 MOPS 配置和功能，以確保部署成功。

盡管有這些挑戰，MOPS 仍然繼承了作為企業平臺的 SharePoint 的強大功能。借助 SharePoint 和 Web 服務技術，MOPS 使得客戶端工作站上不再需要進行直接的數據庫連接。通過隊列系統，MOPS 提高了高峰期的持續性（所有項目經理都希望在星期一早上更新他們的項目，原因無法解釋清楚），而通過其他 MOSS 技術，將 MOPS 與更多行業應用程序集成也是可行的。

自過去為 Project Server 2003 開發業務解決方案以來，我發現，與以往的可伸縮性問題、以前因緩慢的網絡連接而產生的 ODBC 連接問題，以及構建包含許多 JOIN 語句（多到我必須使用 Excel 跟蹤記錄所有子查詢）的數據庫查詢比起來，MOPS 2007 部署挑戰簡直是小巫見大巫。MOPS 2007 是 EPM 解決方案中的重要里程碑，值得花功夫去部署。

Pav Cherny 是一位 IT 專家兼撰稿人，專門研究 Microsoft 協作與統一通信技術。其著述包括白皮書、產品手冊和書籍，這些著述主要討論 IT 運營和系統管理。同時，Pav 是 Biblioso Corporation 的總裁，該公司主要經營托管文檔和本地化服務。

原文 | 來源：微軟TechNet中文站