規劃編目與同盟 (SharePoint Server 2010)

適用版本： SharePoint Server 2010

上次修改主題的時間： 2016-11-30

您必須對要提供給使用者搜尋的內容進行編目或同盟，使用者才可以使用 Microsoft SharePoint Server 2010 的企業搜尋功能。編目或同盟的規劃工作包括：

• 規劃內容來源

• 規劃包含的檔案類型與 IFilter

• 規劃驗證

• 規劃連接器

• 規劃編目影響的管理

• 規劃編目規則

• 規劃在伺服器陣列層級管理的搜尋設定

• 規劃同盟

規劃內容來源

「內容來源」是一組選項，可以用於指定編目的內容類型、編目的 URL，以及編目的深度與時間。預設的內容來源為 [本機 SharePoint 網站]。您可以使用此內容來源，指定特定 Search Service 應用程式所關聯之完整 Web 應用程式全部內容的編目方式。對於每一個使用特定 Search Service 應用程式的 Web 應用程式，SharePoint Server 2010 預設會將每個網站集合之頂層網站的起始位址，新增至預設的內容來源。

某些組織可能只要使用預設內容來源，即可滿足其搜尋需求；但有許多組織則必須新增其他內容來源。您如有需要執行下列作業，請規劃其他內容來源：

• 編目不同內容類型：例如 SharePoint 網站、檔案共用及商務資料。

• 根據不同於其他內容的排程編目某些內容。

• 限制或增加所編目之內容的數量。

• 對於編目不同的網站設定不同的優先順序。

您最多可以在每個 Search Service 應用程式中建立 500 個內容來源，且每個內容來源最多可以包含 500 個起始位址。為儘可能簡化管理，建議您限制所建立的內容來源數目。

規劃編目不同種類的內容

每個內容來源只可編目一種內容。亦即，您可以分別建立內含 SharePoint 網站起始位址的內容來源，以及包含檔案共用起始位址的內容來源；但您不可建立同時包含 SharePoint 網站起始位址與檔案共用起始位址的內容來源。下表列出可供設定的內容來源類型。

規劃商務資料的內容來源

商務資料內容來源需要在 Business Data Connectivity Service 應用程式的應用程式模型中，指定主控資料的應用程式。您可以建立一個內容來源，編目所有在 Business Data Connectivity Service 中的應用程式；您也可建立個別的內容來源，編目各種不同的應用程式。

規劃將商務資料整合到網站集合的人員，大多不會是參與整體內容規劃程序的人員。因此，請將商務應用程式管理員一併納入內容規劃小組，以便其能夠建議您如何將商務應用程式資料整合到內容中，並有效地在網站集合中呈現資料。

在不同的排程時間編目內容

您必須比較不同內容的編目頻率。編目的內容量愈大，編目不同內容存放庫之內容的機率也愈大。這些內容的類型與所在伺服器的容量可能各有不同。下列因素可能會需要您新增內容來源，以在不同的排程時編目不同的內容存放庫。

在不同的排程時間編目內容的主要原因包括：

• 調節停機時間與尖峰使用量時段。

• 增加較常更新之內容的編目頻率。

• 分隔較慢伺服器上之內容與較快伺服器上之內容的編目時間。

在許多情況下，您必須等到 SharePoint Server 2010 完成部署，並執行一段時間之後，才可得知上述所有資訊。因此，您必須等到伺服器陣列實際執行之後，再指定編目排程。但您仍可將這些因素納入規劃考量，根據所得到的資訊規劃編目排程。

下列兩節提供在不同排程時間編目內容的詳細資訊。

規劃編目排程的考量

您可以就每個內容來源個別設定編目排程。您可以為每個內容來源指定執行完整編目的時間及累加編目的時間。請注意，執行累加編目之前，必須先執行內容類型的完整編目。若對尚未編目的內容執行累加編目，系統仍會執行完整編目。

建議您根據編目及查詢伺服器的可用性、效能及頻寬考量規劃編目排程。

當您規劃編目排程時，可以考慮下列最佳作法：

• 將裝載內容伺服器上之內容來源中的起始位址，依可用性的相似程度與可接受的整體資源使用狀況進行分組。

• 將各項內容來源之累加編目排程在裝載內容伺服器可供使用，且伺服器上的資源需求低時執行。

• 錯開編目排程，以將伺服器陣列中之伺服器的負載分散於不同時間執行。

• 只有在因為下節所列的原因而必須執行完整編目時，才排程完整編目。建議您多執行累加編目，而少執行完整編目。

• 排程管理變更在所規劃之完整編目排程之前進行。例如您最好能夠將建立編目規則作業的排程，安排在下一個排定的完整編目之前執行，如此即無需再額外執行其他完整編目。

• 只在容量許可的情況下執行並行編目。為能獲致最佳效能，建議您錯開內容來源的編目排程。經過一段時間之後，隨著您愈來愈熟悉各種內容類型的正規持續時間，即可最佳化編目排程。

執行完整編目的原因

需要 Search Service 應用程式管理員執行完整編目的原因包括：

• 伺服器陣列中的伺服器安裝了軟體更新或 Service Pack。如需詳細資訊，請參閱軟體更新或 Service Pack 的說明。

• Microsoft Office SharePoint Server 2007 共用服務管理員或 SharePoint Server 2010 Search Service 應用程式管理員新增了 Managed 屬性。新增的 Managed 屬性需要完整編目之後才會立即生效。若您不想讓新的 Managed 屬性立即生效，即無需執行完整編目。

• 您要為 Windows SharePoint Services 3.0 或 Microsoft Office SharePoint Server 2007 網站上的 ASPX 頁面重新編製索引。

  注意

  編目程式不會察覺 Windows SharePoint Services 3.0 或 Office SharePoint Server 2007 網站上的 ASPX 頁面變更。因此在刪除個別清單項目之後，累加編目並不會針對檢視或首頁重新編製索引。建議您定期對包含 ASPX 檔案的網站執行完整編目，讓這些頁面能夠重新編製索引。

• 您要解決連續累加編目失敗。當累加編目在存放庫的任意層級連續失敗一百次時，系統會從索引中移除受影響的內容。

• 新增、刪除或修改了編目規則。

• 您要修復損毀的索引。

• Search Service 應用程式管理員建立了一或多個伺服器名稱對應。

• 指定給預設內容存取帳戶或編目規則的使用者帳戶認證有所變更。

在下列情況下，會在要求累加編目時執行完整編目：

• 搜尋管理員停止了先前的編目。

• 已還原內容資料庫，或伺服器陣列管理員卸離並重新附加了內容資料庫。

  注意

  執行 Office SharePoint Server 2007 時，若是並用了 Microsoft Office Servers 基礎結構更新 或 SharePoint Server 2010，您可以使用 Stsadm 命令列工具的還原作業，變更內容資料庫還原作業是否需要觸發完整編目。

• 從未從此 Search Service 應用程式執行網站的完整編目。

• 變更記錄不含所要編目的位址項目。變更記錄中若不含所要編目的項目，即不會執行累加編目。

您可以在初始部署之後，根據伺服器陣列中之伺服器及裝載內容伺服器的效能與容量調整排程。

限制或增加編目的內容數量

您可以為每個內容來源指定所要編目之起始位址的範圍。您也可以變更編目設定，以指定編目的行為。各種內容來源所能使用的選項，會隨您選取的內容來源不同。但大多數編目選項會指定階層中，從每一個起始位址開始起算的編目深度。請注意，此行為只會套用至特定內容來源中的所有起始位址。您如需編目位於更深層級中的某些網站，您可以建立其他內容來源納入這些網站。

您可以使用編目設定選項限制或增加編目的內容數量。每個內容來源屬性中所提供的選項，會隨選取的內容來源類型不同。下表是設定編目設定選項的最佳作法。

規劃內容來源時的其他考量

您無法在相同的 Search Service 應用程式中，使用多個內容來源編目相同的起始位址。例如，若已使用某內容來源編目網站集合及其所有子網站，即無法再於其他的排程時間，另外使用其他的內容來源編目該網站集合中的任何子網站。

對於要將起始位址歸入單一內容來源，或是另建立其他內容來源，除了考慮編目排程之外，絕大部分還是取決於管理考量。管理員經常需要變更以更新特定的內容來源。變更內容來源必須對該內容來源中所指定的內容存放庫進行完整編目。為了讓管理更加方便，建議採用管理員易於更新內容來源、編目規則及編目排程的方式組織內容來源。

規劃包含的檔案類型與 IFilter

唯有在檔案類型包含清單中包含相關的副檔名，且支援這些檔案類型的編目伺服器上安裝了 IFilter 時，才可編目內容。初始安裝期間會自動納入數種檔案類型及 IFilter。當您規劃初始部署的內容來源時，必須決定編目內容時是否要使用未被納入的檔案類型。對於未包含的檔案類型，您必須在部署時，於 [管理檔案類型] 頁面上新增這些檔案類型，並確定已安裝及註冊可以支援該檔案類型的 IFilter。

若要排除某些檔案類型而不進行編目，可以從檔案類型包含清單中，刪除該檔案類型的副檔名。如此一來即會將具有該副檔名的檔案名稱，排除在編目之外。如需預設會安裝的檔案類型及 IFilter 清單，請參閱＜檔案類型與 IFilter 參照 (SharePoint Server 2010)＞。

規劃驗證

當編目程式存取內容來源中所列的起始位址時，必須經過裝載該內容之伺服器的驗證，並獲授與該伺服器的存取權。這表示編目程式所使用的網域帳戶至少須具備內容的讀取權限。

系統預設會使用預設的內容存取帳戶。此外，您也可使用編目規則，指定其他要在編目特定內容時使用的內容存取帳戶。無論是使用預設的內容存取帳戶或編目規則指定的其他內容存取帳戶，所使用的內容存取帳戶皆必須具備所有編目內容的讀取權限。若內容存取帳戶不具備讀取權限，不僅無法編目內容，也無法編製索引，更無法用於查詢。

建議您讓指定為預設內容存取帳戶的帳戶具備大部分編目內容的存取權。只有在基於安全性考量而需要不同的內容存取帳戶時，才使用其他內容存取帳戶。

針對所規劃的各個內容來源，指定預設內容存取帳戶無法存取的起始位址，然後再規劃新增這些起始位址適用的編目規則。

另一項重要的考量是編目程式必須使用主機伺服器所使用的驗證通訊協定。編目程式預設會使用 NTLM 進行驗證。如有必要，可以設定編目程式使用其他驗證通訊協定。

若是使用宣告式驗證，請確認所要編目之 Web 應用程式已有啟用 Windows 驗證。

規劃連接器

您必須使用連接器 (舊版中稱為通訊協定處理常式)，才可取得所有編目內容的存取權。SharePoint Server 2010 會提供所有公用網際網路通訊協定的連接器。但所要編目的內容若是需要 SharePoint Server 2010 安裝未附的連接器，即須安裝第三方或自訂連接器，才可編目該內容。如需預設安裝的連接器清單，請參閱＜預設連接器 (SharePoint Server 2010)＞。如需如何安裝連接器的相關資訊，請參閱＜安裝連接器 (SharePoint Server 2010)＞。

規劃編目影響的管理

編目內容可能會大幅降低裝載內容伺服器的效能。此作業對於伺服器的影響，會隨編目之目標主機伺服器的負載，以及伺服器的資源 (特別是 CPU 及 RAM) 是否足以在一般或尖峰使用狀況下維持相同的服務水準而不同。

搜尋管理員可以使用編目程式影響規則，管理編目程式對所要編目之伺服器的影響。您可以在每個編目程式影響規則中，指定套用規則的單一 URL，或在 URL 路徑中使用萬用字元以包含 URL 區塊。然後，您可以指定可以同時對指定 URL 所屬頁面發出的要求數，或指定一次只可要求一份文件，然後等候經過所選擇的秒數之後，再進行下一個要求。

編目程式影響規則可指定編目程式從特定起始位址或起始位址範圍 (又稱為網站名稱) 要求內容的頻率。編目程式影響規則會套用至 Search Service 應用程式中的所有內容來源，並依照編目元件套用要求頻率。下表顯示新增或編輯編目程式影響規則時，可以在網站名稱中使用的萬用字元。

您可以建立編目影響規則，將其套用至特定頂層網域中的所有網站。例如 *.com 會套用至所有位址結尾為 .com 的網際網路網站。又例如，入口網站的管理員可以新增 samples.microsoft.com 的內容來源。除非您專為 samples.microsoft.com 新增編目程式影響規則，否則將會將 *.com 的規則套用至此網站。

您可以與編目組織內容之搜尋系統的管理員協調，要求其根據伺服器的效能及容量設定編目程式影響規則。但大部分的外部網站不可能進行此協調。要求太多的外部伺服器內容或太常提出要求，皆可能會導致這些網站的管理員因為編目使用太多的資源，而對存取進行限制。進行初始部署時，一方面請儘可能將編目程式影響規則對於其他伺服器的影響減至最小，但同時又能讓編目的內容及頻率能夠適當地更新索引，以維持一致的服務水準。您可以在實際執行伺服器陣列之後，根據編目記錄中的資料調整編目程式影響規則。

規劃編目規則

編目規則會套用至 Search Service 應用程式中的所有內容來源。您可以將編目規則套用至單一的 URL 或一組 URL，以執行下列作業：

• 排除一或多個 URL，以避免編目不相關的內容。如此也有助於降低伺服器資源的使用與網路流量，提高搜尋結果的相關性。

• 不編目 URL 本身而只編目 URL 中的連結。此選項適用於網站具有相關內容，但頁面中之連結不含相關資訊的情況。

• 允許編目複雜的 URL。此選項可讓系統編目包含指定以問號之查詢參數的 URL。這些 URL 可能不含相關內容，視網站而定。由於複雜的 URL 經常會重新導向至無關的網站，建議只在您確認複雜 URL 中的內容有所相關時，才在網站上啟用此選項。

• 允許以 HTTP 頁面的形式編目 SharePoint 網站的內容。此選項可讓系統編目受到防火牆保護的 SharePoint 網站，或當編目網站對於編目程式所用之 Web 服務的存取受限時進行編目。

• 指定要使用預設的內容存取帳戶、其他的內容存取帳戶或用戶端憑證，以編目指定的 URL。

由於編目內容會耗用資源及頻寬，所以與其納入可能毫不相關的大量內容，倒不如只納入您確定相關的少量內容。在您完成初始部署之後，即可檢閱查詢與編目記錄，將內容來源與編目規則調整為更切中主題，並包含更多內容。

規劃在伺服器陣列層級管理的搜尋設定

有許多在伺服器陣列層級進行管理的設定，會影響內容的編目方式。規劃編目時，請留意下列伺服器陣列層級搜尋設定：

• **連絡人電子郵件地址：**編目內容會影響所要編目之伺服器的資源。編目內容之前，請務必先在組態設定中，提供管理員在編目對伺服器造成不利影響時，能夠連絡之組織人員的電子郵件地址。此電子郵件地址會顯示在所要編目之伺服器管理員的記錄檔中，以便於管理員能夠在編目對效能及頻寬的影響太大或發生其他問題時連絡該名人員。

  此連絡人電子郵件地址的擁有者必須具備必要的專業知識，且能夠隨時快速地回應要求的人員。除此之外，您也可以使用密切監管的通訊群組清單別名作為連絡人電子郵件地址。無論所要編目的內容是否儲存在組織內部，快速回應皆是首要之務。

• **Proxy 伺服器設定：**您可以選擇是否要在編目內容時使用 Proxy 伺服器。所要使用的 Proxy 伺服器取決於組織中 SharePoint Server 2010 部署的拓撲，以及其他伺服器的架構。編目網際網路內容時，您很可能必須使用 Proxy 伺服器。如需如何設定 Proxy 伺服器之搜尋設定的詳細資訊，請參閱＜設定伺服器層級的 Proxy 伺服器設定 (SharePoint Server 2010) ＞及＜設定搜尋的 Proxy 伺服器設定 (SharePoint Server 2010)＞。

• **逾時設定：**逾時設定可用於限制搜尋系統連線至其他服務的等候時間。

• **SSL 設定：**Secure Sockets Layer (SSL) 設定會指出 SSL 憑證是否必須完全相符，才可編目內容。

規劃同盟

同盟搜尋是同時對多項 Web 資源或資料庫進行查詢，然後為使用者產生單一搜尋結果頁面。當您新增同盟位置時，使用者可以在本機系統中搜尋並擷取伺服器尚未編目的內容。同盟位置可以將查詢傳送至遠端搜尋引擎並提供摘要。系統會隨之將同盟內容以編目內容的型態將結果呈現給使用者。

SharePoint Server 2010 支援下列同盟位置類型：

• **此伺服器上的搜尋索引。**您可以使用組織中任何具有 SharePoint Server 2010 伺服器的本機或遠端網站作為同盟位置。例如，假設貴公司之人力資源伺服器上的 SharePoint 網站，是唯一可以提供員工連絡人資訊的來源。即使該網站不在編目範圍內，您仍可為其設定同盟位置，以便於從搜尋中心網站啟始搜尋的使用者，可以擷取其有權檢視的員工連絡人資訊結果。其環境如下：

  1. 位置會設定為 [此伺服器上的搜尋索引]。

  2. 無須查詢範本。SharePoint Server 2010 會使用物件模型查詢位置。

  3. 會使用預設的伺服器驗證。

  4. 不支援進階搜尋查詢。

• **OpenSearch 1.0 或 1.1。**您可以使用任何支援 OpenSearch 標準的公用網站作為同盟位置。像是 Bing 等網際網路搜尋引擎，或支援 RSS 或 Atom 通訊協定的搜尋結果頁面，皆可作為這類位置的範例。例如，假設您希望讓在內部網站上搜尋專利技術研究的使用者，也能看見公用網站的相關搜尋資訊。您只要設定 Bing 搜尋查詢的同盟位置，即可自動為使用者併入 Web 搜尋結果。其環境如下：

  1. 查詢可以 URL 的形式傳送至搜尋引擎，如 http://www.example.com/search.aspx?q=TEST。

  2. 搜尋結果會以 RSS、Atom 或其他結構化的 XML 格式傳回。

  3. 位置功能、查詢範本及回應元素屬於位置相關聯之 OpenSearch 描述 (.osdx) 檔案的一部分。

  4. SharePoint Server 2010 專用之 OpenSearch 延伸功能具備包含觸發程式及關聯 XSL 程式碼與搜尋結果的功能。

  5. 搜尋結果中所顯示的中繼資料選擇取決於 OpenSearch 位置。

  如需 OpenSearch 的詳細資訊，請造訪 https://www.opensearch.org(可能為英文網頁)。

當搜尋查詢傳送至同盟位置時，其會使用稱為查詢範本的格式，以 URL 參數的形式進行傳送。接著，系統會將結果格式化為 XML，然後呈現給搜尋中心網站的使用者。此 XML 會以可以閱讀的文字形式，顯示在搜尋結果頁面的網頁組件中。您可以將搜尋結果頁面上的網頁組件，新增並設定為同盟搜尋結果網頁組件、主要同盟結果網頁組件或核心結果網頁組件。搜尋結果頁面預設會包含同盟搜尋結果網頁組件。

在決定是否要對使用者顯示同盟搜尋結果時，請考慮下列問題：

1. **是否有哪些搜尋需要顯示自訂的結果？**為確保同盟位置傳回的結果與指定的查詢相符，您可以使用觸發規則。當您建立同盟位置的觸發規則時，關聯至該位置的網頁組件只會顯示符合您所指定之模式或前置詞的使用者查詢結果。

2. **您可否使用 URL 指定查詢所要擷取的結果？**若要建立同盟位置，必須指定包含 URL 及傳送搜尋查詢，並以 XML 形式傳回結果所需之參數的查詢範本。當您將此資訊新增至 [新增同盟位置] 頁面上的 [查詢範本] 欄位時，必須正確地格式化字串 (如 [新增同盟位置] 頁面上的範例所示)，否則搜尋結果提供者將不會傳回任何結果。

3. **使用者可否存取同盟位置所提供的連結？**貴組織若只授與您有限的網際網路資源存取權，則使用網際網路搜尋引擎作為同盟位置，可能會讓使用者因為無法檢視部分搜尋結果而感到不便。

4. **是否需要驗證？**若同盟位置需要驗證，必須提供正確的認證。有許多同盟位置 (如網際網路搜尋引擎) 不需要認證。

規劃同盟的驗證類型

有多種使用者驗證、依使用者身分認證及一般認證皆可作為同盟搜尋的對象。但請注意，在依使用者身分驗證中，收集認證必須使用非 Kerberos 驗證類型的網頁組件延伸。您可以在位置定義的驗證及認證資訊區段中，指定同盟位置的驗證類型。驗證類型可以是下列一種：

• 匿名

  連線至同盟位置不需要任何認證。

• 一般

  每種連線皆使用相同的認證集連線至同盟位置。

• 依使用者身分

  使用傳送搜尋查詢之使用者的認證連線至同盟位置。

對於一般及依使用者身分驗證類型，您還須指定下列一種驗證通訊協定：

• 基本

  基本驗證是 HTTP 規格的一部分，大多數的瀏覽器皆支援此項。

  Security Note
  使用基本驗證的網頁瀏覽器會傳輸未加密的密碼。惡意使用者只要監視網路上的通訊，即可使用各種開放使用的工具攔截及解碼這些密碼。因此，除非確認是安全的連線 (例如使用專線或 Secure Sockets Layer (SSL) 連線)，否則不建議使用基本驗證。

• 摘要

  摘要驗證會使用全球資訊網協會 (W3C) 網站上之 RFC 2617 規格中所定義的 HTTP 1.1 通訊協定。由於摘要驗證採行 HTTP 1.1 標準，因此會有一些瀏覽器不支援此驗證。若在啟用摘要驗證之後，出現不相容於 HTTP 1.1 的瀏覽器要求檔案，將會因為用戶端不支援摘要驗證而拒絕此要求。摘要驗證只可用於 Windows 網域，且只可搭配 Windows Server 2008、Windows Server 2003 及 Microsoft Windows 2000 Server 網域帳戶使用。其同時也可能會要求帳戶將密碼儲存為加密的純文字。

• NTLM

  使用者記錄會儲存在安全性帳戶管理員 (SAM) 資料庫或 Active Directory 資料庫中。每個使用者帳戶皆會與兩組密碼相關聯，一組是相容於 LAN Manager，一組是 Windows 密碼。每組密碼皆會經過加密，並儲存在 SAM 資料庫或 Active Directory 資料庫中。

• Kerberos (僅限依使用者身分驗證類型)

  使用 Kerberos 通訊協定時，網路連線任一端的一方皆可驗證另一方是否為其所宣稱的實體。雖然 NTLM 可以讓伺服器驗證其用戶端的身分識別，但卻無法讓用戶端驗證伺服器的身分識別，也無法讓伺服器驗證其他伺服器的身分識別。NTLM 驗證專為網路環境所設計，並假設環境中的所有伺服器皆為信任的伺服器。

• 表單型

  表單型驗證 Cookie 只是驗證票證的容器。每項要求會以 Cookie 值的形式傳遞票證，並在伺服器上使用票證識別經過驗證的使用者。但不具 Cookie 的表單型驗證在 URL 中會以加密格式傳遞票證。使用無 Cookie 之表單型驗證的原因在於用戶端瀏覽器可能會封鎖 Cookie。此功能首次出現在 Microsoft .NET Framework 2.0 中。

若要在環境中使用宣告式驗證，請確定要編目的內容來源中也啟用了 Windows 驗證。如需 SharePoint Server 2010 適用之驗證方法的詳細資訊，請參閱＜規劃驗證方法 (SharePoint Server 2010)＞。

See Also

Concepts

收集目前搜尋環境的相關資訊 (SharePoint Server 2010)
決定企業搜尋團隊與專案關係人 (SharePoint Server 2010)