深入剖析 Sharepoint 企業專案管理與 SharePoint

Pav Cherny

代碼下載位置： ChernySharePoint2008_12.exe(959 KB)

目錄

Project Server 體系結構
SharePoint 集成
伺服器場部署
歡迎使用 IIS 7
會話資料庫許可權
共用服務許可權
Windows 防火牆
MOPS 服務和服務帳戶
Analysis Services 集成
結論

哪些 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。 在故障排除環境中記住這個小細節很重要，這是由多種原因決定的，特別是：

• PWA 網站定義資料庫的上下文（每個 PWA 網站都有獨立的草稿、已發佈、存檔和報告資料庫）和使用者許可權，但不會授權一般使用者帳戶訪問 PSI Web 服務。
• PSI Forwarder 不支援類比，但可以使用 PWA 網站的應用程式池帳戶代表使用者訪問 PSI Web 服務。
• 如果伺服器場包含多個應用程式伺服器實例，則 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 應用程式伺服器上的安全性，都由您選擇。

SharePoint 資源

SharePoint 產品和技術網站
microsoft.com/sharepoint

Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/sharepoint

Windows SharePoint Services Developer Center
msdn.microsoft.com/sharepoint

Microsoft Office Project 2007 一般性參考資料
msdn.microsoft.com/library/bb258902

Microsoft SharePoint 產品和技術團隊博客
blogs.msdn.com/sharepoint

規劃管理和服務帳戶 (Office SharePoint Server)
technet.microsoft.com/library/cc263445

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 的總裁，該公司主要經營託管文檔和當地語系化服務。