• 發行項

Sharepoint 內幕建置 SharePoint 基礎結構

Pav Cherny

下載本文程式碼: SharePoint2008_05.exe (412KB)

正如電子郵件訊息一改商務通訊的面貌，以網路為主的共同作業也改變了你我合作及共享資訊的方式。而 SharePoint 技術正是這樣的一個好例子。透過 Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server

(MOSS) 2007，您可以建立小組網站、入口網站、網站內容管理解決方案、文件庫，以及搜尋中心，還有 2007 Microsoft® Office System 整合、XML 式表單，工作流程、行動支援等等更是不在話下。

然而，著手使用 SharePoint® 不是那麼容易。除了用詞容易令人混淆外，系統架構也可能很複雜，而且 SharePoint 需要您處理的元件不少，包括 IIS、Microsoft .NET Framework、SQL Server®，可能還有其他技術，例如商務智慧、InfoPath® Forms Services、Rights Management Services (RMS)、Exchange Server，以及 ForefrontTM Security。

建立 SharePoint 解決方案的方法繁多，無論是透過內建使用者介面或是透過程式設計，您可能很快會身陷整合和自訂兩難之中。另外，當 SharePoint 應用程式無法運作時，要疑難排解也可能很複雜。您通常需要有應用程式開發人員的腦袋，才能了解當中牽涉的元件，以及它們互動的方式。面臨所有這些挑戰，要從何著手來建置一個穩固、可調整且易管理的 SharePoint 基礎結構呢？

在本專欄中，我將以高階架構的觀點向您說明如何從基礎建置著手進行，然後深入探討 WSS 的部署，包括非常基本的商標自訂。使用 WSS 3.0 的「自助網站管理」功能，您將學會如何將建立和管理 SharePoint 網站的權限委派給個別使用者，並同時對 SharePoint 基礎結構保有集中化管理的控制能力。

先看一下 SharePoint 架構，就不難了解實作富有彈性和可調整之基礎結構所需的部署和設定步驟。所以讓我們約略談一下相依性，之後再切入部署 WSS 3.0 的主題。如需詳細的部署指示，請參閱附隨的參考資料。您可以在 TechNet Magazine 網站的程式碼下載區找到這份資料，網址是 technetmagazine.com。

SharePoint 架構

透過 SharePoint，以系統架構設計師本位思考技術確實有助益。無須了解枝微末節，只要熟悉 SharePoint 架構相關的整體相依性，解決方案就在不遠處，因為您可以預測出需要進行哪些設定，以及進行這些設定的原因。

SharePoint 是一項提供 Web 應用程式和網站的技術。它是以 IIS 為基礎的網站解決方案，透過 ASP.NET 與 IIS 整合，並仰賴 SQL Server 資料庫後端來存放設定資料和內容。簡而言之，SharePoint 的核心結合了三種不同的架構 (IIS、.NET 和 SQL Server)，如 [圖 1] 所示。

Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0

Figure 1** WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0 **(按影像可放大)

別讓上圖給嚇到了，元件數目龐大，架構剛開始看起來可能很讓人吃不消。但是所有這些元件都能融合到邏輯架構中，方便在進行有系統地分析時，深入洞察元件的相依性。

如前所述，SharePoint 仰賴 IIS 和 ASP.NET 來處理 HTTP 要求和回應。標準 IIS 元件，例如 HTTP 核心模式驅動程式 (http.sys) 和工作者處理序 (w3wp.exe)，會執行要求初始的佇列和路由作業，直到它們抵達 ASP.NET ISAPI 篩選器 (aspnet_isapi.dll)。安裝 .NET Framework 時，安裝常式會在 IIS Metabase (C:\Windows\System32\Inetsrv\metabase.xml) 中註冊 aspnet_isapi.dll，如下所示：

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

IIS 一載入 ASP.NET ISAPI 篩選器，就可以將對某網站的所有傳入要求傳送到 ASP.NET，這很重要，因為 SharePoint 最後必須透過 ASP.NET 接收這些要求。為了達成這個目的，SharePoint 會新增萬用字元應用程式對應，將所有傳入要求 (不管檔案名稱副檔名) 路由到 ASP.NET ISAPI 篩選器，藉此擴充選定網站的設定。

您可以在使用基本安裝選項安裝 WSS 3.0 之後，在 IIS 管理員裡面看到結果。WSS 安裝常式會停用伺服器上現有的預設 IIS 網站，並在有定義 ASP.NET 萬用字元應用程式對應的連接埠 80 上建立一個新的預設網站，如 [圖 2] 所示。

Figure 2 Wildcard application map for ASP.NET ISAPI filter

Figure 2** Wildcard application map for ASP.NET ISAPI filter **(按影像可放大)

為了讓 ASP.NET 轉而將要求傳送給 SharePoint，SharePoint 也必須透過自訂 HttpApplication 物件來擴充 HTTP 要求管線，這個物件是透過 Microsoft.SharePoint 組件中一個叫做 SPHttpApplication 的類別實作而成的。SharePoint 會在 ASP.NET 應用程式檔案 (global.asax) 中定義這個自訂的應用程式物件，您可以到 SharePoint 擴充的網站，從根資料夾裡面的檔案系統中找到這個檔案。下面的程式碼列出了這種 global.asax 檔案的內容：

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

ASP.NET 會動態地剖析和編譯這個檔案，以產生 SharePoint 應用程式物件。

對於每個接收到的要求，ASP.NET 都會觸發一連串 Web 應用程式可以處理的事件，像是 BeginRequest、AuthenticateRequest、ProcessRequest 和 EndRequest。事件處理的細節已超出部署和管理 SharePoint 的討論範圍，不過您應該知道，除了 global.asax 中指定的 SPHttpApplication 之外，SharePoint 也會為網站實作 web.config 檔案中定義的自訂 HTTP 處理常式和模組。例如，SharePoint 會根據 SPRequestModule 類別使用 HTTP 模組，將它註冊成先於標準 ASP.NET 模組的第一個 HTTP 模組。SPRequestModule 會初始化 SharePoint 常式環境，例如透過 ASP.NET 來註冊 SPVirtualPathProvider 元件。SPRequestModule 是供 SharePoint 內部使用，但是 SharePoint 解決方案開發人員可以修改 web.config 檔案來註冊其他元件，像是自訂 HTTP 處理常式和模組。透過自訂和標準 HTTP 模組，SharePoint 便能在利用 ASP.NET 的同時，仍舊對 SharePoint 應用程式的所有要求保持高度的控制能力。

要注意的是，當使用 SharePoint 3.0 管理中心網站建立 Web 應用程式時，WSS 會新增 ASP.NET 萬用字元應用程式對應到選定的 IIS 網站中，並在網站的根資料夾中建立 global.asax 和 web.config 檔案。每個 Web 應用程式都會使用自己一套頂層 global.asax 和 web.config 檔案。

為了處理要求並傳回有意義的資訊給瀏覽器，WSS 3.0 和 MOSS 2007 有賴於標準 ASP.NET 頁面剖析器，它會編譯要求的 ASP.NET 網頁，或是在不編譯的模式下處理它們。但是 SharePoint 傳遞給 ASP.NET 的 ASP.NET 網頁不一定是位在它們應該存在的地方。比方說，您在 SharePoint 擴充的網站 (例如 SharePoint 3.0 管理中心網站) 的根資料夾中，將找不到 default.aspx 檔案，反而是在顯示該網站的首頁時開啟 default.aspx。將環境視覺化的正是 SPVirtualPathProvider 元件，它會從本機檔案系統或 SQL Server 內容資料庫載入頁面內容，然後把它當作虛擬檔案傳遞給 ASP.NET 頁面剖析器。對於管理中心網站，SharePoint 會從 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin 資料夾載入 default.aspx。

首頁，以及大多數其他 SharePoint 網站網頁，都是連結到 ASP.NET 主版網頁 (default.master)，這個主版頁面實作有功能表和巡覽控制的通用配置。Default.master 是位於 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global 資料夾中，而且包含了其他內容網頁已命名的預留位置，這些網頁也位在本機檔案系統或 SQL Server 內容資料庫中。重點是，當您在網頁瀏覽器開啟 SharePoint 網站時，您實際上是從一組內容頁面集合查看資訊，這些內容頁面不一定是位在本機 Web 伺服器上，而且是根據主版頁面內定義的配置排列的。

其中的通則是，未經修改的頁面 (或以 SharePoint 的用語：未自訂的頁面) 在每部 SharePoint 伺服器的本機檔案系統上是以頁面範本的形式存在，而自訂頁面則會寫入內容資料庫中，以便讓 Web 伺服陣列當中的所有 SharePoint 伺服器都能夠存取相同一組的頁面 (見 [圖 3])。根據假設，Web 伺服陣列中所有伺服器和網站之間的未自訂頁面應該都是一樣的。不過，假如您使用 Office SharePoint Designer 2007 在 SharePoint 網站內自訂內容頁面或主版頁面，SharePoint 會自動將自訂的頁面儲存在內容資料庫中。

Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application

Figure 3** Uncustomized and customized ASP.NET pages in a SharePoint application **(按影像可放大)

除了自訂頁面和其他網站內容之外，SharePoint 也會將設定資料儲存在 SQL Server 資料庫中。SharePoint 將設定資料與內容相區隔是因為設定資料在本質上是通用的，而內容則是專用於個別 Web 應用程式和網站集合。因此，Web 伺服陣列只能有一個設定資料庫，但是它可以有多個內容資料庫。

Web 伺服陣列當中所有的 WSS 伺服器都是使用相同的設定資料庫來共用中繼資料、設定值，以及 Web 伺服陣列中每個經過 SharePoint 擴充的 IIS 網站的相關資訊。另一方面說來，個別的 Web 應用程式則可與一或多個內容資料庫相關聯 (但是每個內容資料庫都只能與一個 Web 應用程式相關聯)。

IIS 網站、Web 應用程式、網站集合、網站與內容資料庫之間的關係可能很容易令人混淆。照 SharePoint 的用語，Web 應用程式一詞指的是 SharePoint 擴充的 IIS 網站。Web 應用程式可包含多個網站集合，而且每個網站集合都可以再包含共用相同設定值的頂層網站和子層網站。

此外，建立多個網站集合也可讓您將網站集合的系統管理作業委派給不同的使用者和群組。單一網站集合並不能橫跨多個內容資料庫，但是一個 Web 應用程式可以使用多個網站集合的多個內容資料庫，提高在其他 SharePoint 網站產生大量資料庫活動的大型網站的延展性，並減輕其效能衝擊。不過，將每個 SharePoint 網站放在它自己的網站集合裡面並不是個好主意，因為這種部署方式會限制跨網站的功能。

WSS 3.0 並不支援在多個網站集合間搜尋內容。這類的搜尋作業需要有 MOSS 2007 或 Microsoft Search Server 2008 才能進行。例如，您可以為 建立一個 Web 應用程式和頂層網站，而網站集合管理員之後可以使用 SharePoint 使用者介面建立子層網站，例如 http://contoso/info 和 http://contoso/events。所有這些網站都存在於相同的內容資料庫，因為它們都屬於相同的網站集合。

身為伺服器陣列管理員，您還可以使用受管理的路徑 (例如 /sites)，然後在 SharePoint 3.0 管理中心定義額外的網站集合，例如 http://contoso/sites/IT 和 http://contoso/sites/HR。這三種網站集合 (http://contoso、http://contoso/sites/IT 和 http://contoso/sites/HR) 都可以有不同的網站集合管理員、設定值和內容資料庫，但是它們全都還是透過相同的 IIS 網站 (http://contoso) 存取，而且使用相同的 Web 應用程式的應用程式集區識別。

不用說，其他還有很多相關的細節，但是 IIS、ASP.NET 與 SQL Server 之間的這種關係對於了解熟悉 SharePoint 來說尤其重要。如果您有興趣深入了解 SharePoint 架構，我建議您閱讀 Ted Pattison 在《MSDN® Magazine》發表的＜探索 SharePoint Services 中重大的開發人員改進功能＞一文，網址是 msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview。

SharePoint 基礎結構要素

現在讓我們將之前概括討論的架構，轉化成富有彈性的 SharePoint 基礎結構。您肯定已經注意到，我們需要有 Windows Server®、IIS、.NET Framework 3.0 (用於 ASP.NET 和 Windows® Workflow Foundation)、WSS 3.0 或 MOSS 2007，以及 SQL Server。雖然您可以預期使用 Windows Server 2008 上的 IIS 7.0，但針對本文的目的，我們會使用 Windows Server 2003 上的 IIS 6.0，因為這是在撰寫本文時最常部署的版本。我們還是繼續使用 WSS 3.0，因為初次的 SharePoint 試驗，我們並不需要 MOSS 2007 專用的功能。

要採取精簡策略的話，您可以在單一電腦上安裝 WSS 3.0 與所有必要的元件 (如 WSS 3.0 的 single computer.pdf 上所述，這可在本專欄隨附的資料取得)，這用於實驗室伺服器或小型工作群組環境就綽綽有餘。不過，如果您打算把焦點放在 SharePoint 基礎結構中的靈活度上的話，就不應該從生產環境中的獨立部署開始著手。基於可用性還有未來的延展性，最好是從多層式基礎結構開始，然後在必要時加入更多伺服器。

如果您要的是直接明瞭且富彈性的系統設定的話，[圖 4] 正說明了我建議的 SharePoint 基礎結構。它包含了兩個 SharePoint 伺服器的 Web 伺服陣列，另外還有一部執行 SQL Server 的電腦。這項設定不僅免去了 Web 伺服器上處理資料庫的負擔，也提高了可用性、延展性，更加速了系統維護的效率。請注意，您還是需要 Active Directory®，因為這是 Web 伺服陣列部署中 WSS 3.0 的軟體需求。如須逐步部署的指示說明，請參閱隨附資料裡面的 Basic SharePoint Infrastructure.pdf 檔案。

Figure 4 Basic SharePoint infrastructure that can accommodate future growth

Figure 4** Basic SharePoint infrastructure that can accommodate future growth **(按影像可放大)

您在這種安排下部署 SharePoint 所用的網域帳戶必須在 Web 伺服器上具備本機系統管理員的權限。您也必須在 SQL Server 2005 中將這個帳戶加入 dbcreator 和 securityadmin 這兩個 SQL Server 角色，還有 Master 資料庫的 db_owner 資料庫角色，如 Basic SharePoint Infrastructure.pdf 中所示。您接著可以在 WSS 3.0 安裝期間使用「SharePoint 產品及技術設定精靈」為 Web 伺服器伺服陣列建立必要的設定資料庫，並為 SharePoint 3.0 管理中心網站建立內容資料庫。不然的話，SQL Server 系統管理員必須為您佈建這些資料庫，並新增 WSS 系統帳戶到 db_owner 角色。

要特別謹記在心的是，您安裝 SharePoint 所用的使用者帳戶並不是 SharePoint 用來存取管理中心網站的設定資料庫或內容資料庫的帳戶。SharePoint 反而是使用設定為 SharePoint 3.0 管理中心網站之應用程式集區識別的系統帳戶。

「SharePoint 產品及技術設定精靈」會提示您輸入帳戶資訊。為此使用專用的網域使用者帳戶是個不錯的主意，例如 CONTOSO\WssConfigAdmin。我向來的作法都是對任何稍後另外建立的 Web 應用程式，使用個別專用的使用者帳戶。對每個 Web 應用程式使用不同的應用程式集區有利於確保隔離處理序，而對每個應用程式集區使用不同的使用者帳戶將有助於維護安全性隔離。不過要注意的是，這只是其中一種方法，而且您應該比照自己的環境和商務需求來評估管理性和可能的效能衝擊。

網域系統管理員應該為您建立的另外一個重要的系統帳戶，是搜尋服務帳戶。您可以使用管理中心帳戶，但是為了提高安全性，最好是使用不具系統管理權限而且不能修改任何內容的專用搜尋帳戶，例如 CONTOSO\WssSearch。因為搜尋服務只會針對製作索引的目的編目內容，並且會將搜尋資料維持在不同的資料庫裡面，所以不用具備寫入內容資料庫的權限。

在伺服器伺服陣列中建立 Web 應用程式時，您可以建立內容資料庫與搜尋伺服器的關聯，這可隱含地新增相對應的搜尋服務帳戶到 Web 應用程式的「完整讀取」原則中。搜尋伺服器是執行 Windows SharePoint Services 搜尋服務的 SharePoint 伺服器。如果您有遵照 Basic SharePoint Infrastructure.pdf 檔案裡面的逐步指示，應該已經將兩部 Web 伺服器都設定成搜尋伺服器，這樣一來，您就可以分散編目和製作多個內容資料庫索引的負載。不過，您也可以在 Web 伺服陣列中設定專用搜尋伺服器，將它從網路負載平衡和用戶端連線排除，如此用戶端連線就不會受到編目活動的影響。

自助網站管理

有了基本的 SharePoint 基礎結構，我們就可以將網站集合和網站的系統管理作業委派給個別的部門和使用者，而不用將系統管理的控制權分散到 Active Directory、Web 伺服器伺服陣列，或 SQL Server 資料庫上。身為伺服器陣列管理員，您可與 Active Directory 和 SQL Server 系統管理員合作為您的 Web 應用程式佈建應用程式集區帳戶和內容資料庫。在這些 Web 應用程式當中，您接著可以建立網站集合，並指定網站集合管理員建立子層網站的權限。這麼一來，各部門當中的網站集合管理員不用 IT 部門太多的協助，就可以管理他們的 SharePoint 資源，如 [圖 5] 所示。

Figure 5 Decentralized site administration in a centralized SharePoint infrastructure

Figure 5** Decentralized site administration in a centralized SharePoint infrastructure **(按影像可放大)

您也可以讓使用者在受管理的路徑 (例如 /sites 路徑，或其他您在 SharePoint 3.0 管理中心建立且包含相對路徑的受管理路徑) 建立網站集合。如果您在 Web 應用程式中啟用「自助網站管理」功能，使用者便可以在 SharePoint 使用者介面當中建立他們自己的網站集合並管理網站群組和權限。跟子層網站不同的是，網站集合並不會繼承父網站的權限。

自助網站管理並不適用於所有 SharePoint 環境，而且預設會停用。您若是啟用它，內容資料庫裡面最後可能會出現一堆不常用的網站集合。然而，這項功能確實鮮明地展示了 SharePoint 系統管理的彈性，建議您在試驗部署中試試看 (此外，SharePoint 當中還有一些通知使用者和/或系統管理員非作用中網站的選項，以便在必要時將它們移除)。您必須明確地啟用 Web 應用程式的自助網站管理功能，如隨附的資料中 Enabling Self-Service Site Management.pdf 檔案所述。

SharePoint 自訂和商標

SharePoint 資源

此時，很自然地您會想要在 SharePoint 使用者介面中加上公司的標誌、名稱和企業識別色。不過要注意的是，這會將 SharePoint 專案帶向 ASP.NET 開發人員層級。您至少要有個開發系統，例如裝有 Microsoft Office SharePoint Designer 2007 的獨立 WSS 3.0 伺服器 (請參閱隨附資料的 SharePoint Designer Installation.pdf)，這樣一來，您就可以建立和測試自訂，而不致影響到生產環境。另外，您也應該造訪 Windows SharePoint Services Developer Center 進一步了解 SharePoint 提供的各種自訂選項，網址是 msdn2.microsoft.com/sharepoint。

雖然 SharePoint 的開發已經超出本專欄的討論範圍，還是容我指出您應該多加考量的幾個層面。SharePoint 會將自訂頁面儲存在相對應網站集合的內容資料庫中。換句話說，您在 SharePoint 網站中套用到網站頁面、應用程式頁面、主版頁面、樣式表等等的任何自訂，只會在網站集合或網站層級套用。這對於想要使用 SharePoint Designer 2007 調整網站外觀的個別網站集合管理員來說是一大福音，但對於想要在 Web 伺服陣列的所有 Web 應用程式、網站集合和網站間強制企業識別的伺服陣列管理員而言，就沒什麼好處了。

您可以根據標準 SharePoint 佈景主題或網站定義的複本，來建立自訂網站佈景主題或自訂網站定義。您也可以建立自訂主版頁面，並將它們新增到主版頁面圖庫中。不過，如果啟用自助網站管理的話，這些選項就沒有一個能夠強制通用商標，因為具備建立網站集合或網站權限的使用者仍舊可以選擇使用不顯示企業識別的標準網站範本。

通用商標會要求您替換預設的 SharePoint 元件，以便改用您的自訂元件。開發人員在不修改原始檔案的情況下，需要大費周章來完成這項作業。其中一個方法是在 IIS 管理員中變更虛擬目錄的設定，把它們指向內含自訂檔案的新資料夾。另外一個方法是實作自訂 HTTP 模組或 ISAPI 篩選器，重寫 URL 以便將對特定預設頁面的要求重新導向到自訂版本。

結論

我把重點集中在使用 WSS 3.0 建立 SharePoint 基礎結構的基本知識，但並沒有探討其他功能，像是工作流程、問卷、訊息整合和防毒，也沒有討論 MOSS 2007 特定的功能，例如入口網站、網站目錄和商務資料目錄。文中也只談到在 SharePoint 內自訂網站系統管理和公司商標的皮毛。您可以透過在 Visual Studio® 中程式設計自訂應用程式的方式，進一步利用 WSS 3.0 發揮自訂。

如果您加入更多 Web 伺服器或資料庫伺服器，整個基礎結構將可穩健地應付未來的成長。試驗推出幾項自訂，讓使用者建立個別的網站，並大致熟悉 SharePoint。這麼一來，您就可以建立讓使用者採納的核心元件，還有相關的軟硬體，這些元件的彈性將可靈活地配合各種變動，並作為完整生產首展的基石。

Pav Cherny 是 IT 專家兼作者，專攻 Microsoft 共同作業與整合通訊技術。他的出版品包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。Pav 是 Biblioso Corporation 的總裁。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.