SharePoint Server 設計範例:公司入口網站及外部網站SharePoint Server design samples: Corporate portal and extranet sites

摘要:說明最常用之 SharePoint 2013 和 SharePoint Server 2016 設計範例的邏輯架構設計選擇。Summary: Describes logical architecture design choices for the most common SharePoint 2013 and SharePoint Server 2016 design samples.

本文討論可作為 SharePoint 網站起始點架構的幾種設計範例。本文所述的設計範例說明公司或組織內最常部署之 SharePoint 網站類型的標準架構。This article discusses several design samples that can be used as starting-point architectures for SharePoint sites. The design samples described in this article illustrate standard architectures for the most common types of SharePoint sites that are deployed within a company or organization.

重要

[!重要事項] 本文資訊適用於 SharePoint Foundation 2013 和 SharePoint Server。但是,本文討論 SharePoint Foundation 2013 不提供的特定功能,例如「我的網站」及企業搜尋。The information in this article applies to SharePoint Foundation 2013 and SharePoint Server. However, the article discusses certain features, such as My Sites and enterprise search, that are not available in SharePoint Foundation 2013.

關於設計範例About the design samples

本文說明下列設計範例:The following design samples are described in this article:

這些設計範例以虛構公司 Fabrikam, Inc. 的網站進行。這些設計範例幾乎適用於所有邏輯架構元件,並這些元件如何應用在整體設計中。本文範例設計目標,並解釋範例所示的邏輯架構元件如何達成這些目標。The design samples illustrate sites for a fictitious company named Fabrikam, Inc. The design samples apply nearly all of the logical architecture components and illustrate how these are incorporated into the overall design. This article describes the design goals for the samples and explains how the logical architecture components illustrated in the samples achieved these goals.

注意

模型在標題中有 SharePoint 2013,但仍適用於 SharePoint Server 2016The models have SharePoint 2013 in the title, but still apply to SharePoint Server 2016

公司入口網站設計範例 - 兩種版本Corporate Portal design sample — two versions

SharePoint Server 的主機命名型網站集合在單一 Web 應用程式內,提供網站的 URL 管理及延展性。這兩種公司入口網站設計範例版本顯示以傳統路徑型網站集合或主機命名型網站集合為使用基礎的實作。這兩種設計範例均搭配單一區域使用宣告式驗證。本文稍後將更詳細討論這些範例。Host-named site collections in SharePoint Server provide URL management and scalability of sites within a single web application. The two versions of the Corporate Portal design sample show implementations that are based on the use of the traditional path-based site collections or host-named site collections. Both of these design samples utilize claims-based authentication with a single zone. These samples are discussed in greater detail later in this article.

除非有需求指出必須要有搭配了備用存取對應的路徑型網站 (如需詳細資訊,請參閱<已指定主機的網站集合架構與部署 (SharePoint 2013)>),否則建議使用以主機命名型網站集合為基礎的設計。建議採用此種設計的原因是因為它的架構與 Office 365 環境所使用的架構相同。因此,這是受到最嚴厲測試的組態。新功能 (包括應用程式模型和要求管理) 已針對此組態最佳化,因此此組態是從今以後的版本最可靠的組態。We recommend using the design based on host-named site collections unless requirements dictate that path-based sites with alternate access mapping are necessary (see Host-named site collection architecture and deployment (SharePoint 2013), for more information). This design is recommended because it is the same architecture that the Office 365 environment uses. Consequently this is the most heavily tested configuration. New features, including the App model and Request Management, are optimized for this configuration, and it is the most reliable configuration going forward.

設有驗證專用區域的外部網路Extranet with Dedicated Zones for Authentication

「具有驗證專用區域的外部網路」設計範例僅包含合作夥伴網站。此設計範例提供合作夥伴共同作業的其他設定,在此設定中,每個驗證方法各有專用區域。每個設計範例針對 Web 應用程式使用宣告模式驗證。公司入口網站設計範例與外部網路設計範例之間的差異在於區域的設定方式。「具有驗證專用區域的外部網路」設計範例使用多個區域,且每個區域設定一種驗證方法。公司入口網站設計範例使用一個區域,並針對不同類別的使用者設定多種驗證方法。The Extranet with Dedicated Zones for Authentication design sample includes only the partner web site. It provides an alternate configuration for partner collaboration in which dedicated zones are used for each authentication method. Each design sample uses claims mode authentication for web applications. The difference between the Corporate Portal design samples and the Extranet Design sample is how the zones are configured. The Extranet with Dedicated Zones for Authentication design sample uses multiple zones, and one method of authentication is configured for each zone. The Corporate Portal design samples use one zone, and multiple authentication methods are configured for different classes of users.

「具有驗證專用區域的外部網路」設計範例也引進新的遠端員工存取建議 (透過 Windows Server 2012 直接存取)。此建議的另外一種作法是建立虛擬私人網路 (VPN)。您也可以視需要在防火牆或閘道產品上使用表單型驗證,以收集及轉送認證。The Extranet with Dedicated Zones for Authentication design sample also introduces a new recommendation for remote employee access — Direct Access with Windows Server 2012. An alternative to this recommendation is to create a virtual private network (VPN). You can also use forms-based authentication on the firewall or gateway product to collect and forward credentials, if desired.

設計範例中實作網站集合的方式How site collections are implemented in the design samples

雖然舊版的公司入口網站設計範例使用路徑型網站集合,但是建議從今以後的版本都使用主機命名型網站集合,除非有需求指出必須使用搭配了備用存取對應 (AAM) 的傳統路徑型網站。這會在設計範例中以下列方式反映:Whereas previous versions of the Corporate Portal design sample made use of path-based site collections, going forward host-named site collections are recommended unless requirements indicate that the traditional path-based sites with alternate access mapping (AAM) are necessary. This is reflected in the design samples in the following ways:

  • 採用路徑型網站集合的公司入口網站 - 此範例傳統路徑型網站集合,網站會組織在專用的 Web 應用程式中,且每個 Web 應用程式各有一個頂層網站集合。如果您想透過使用個別應用程式集區的多個 Web 應用程式提供額外的安全性,請使用此方法。Corporate Portal with Path-based Site Collections — This sample illustrates path-based site collections in the traditional way with sites organized into dedicated Web applications and a single top-level site collection per Web application. Use this approach if you want the additional security provided by multiple web apps with separate app pools.

  • 採用主機命名型網站集合的公司入口網站 - 此範例使用主機命名型網站集合,將所有網站部署在伺服器陣列上的單一 Web 應用程式中。此方法的延展性極高,並可更彈性地管理 URL。Corporate Portal with Host-named Site Collections — This sample illustrates the use of host-named site collections with all sites deployed in a single Web application on the farm. This method is highly scalable and provides more flexibility in managing URLs.

  • 設有驗證專用區域的外部網路 - 此範例使用虛名 URL 的許多頂層專案網站,其方式是使用主機名稱網站代表每個專案網站 (而不是在頂層網站集合之下組織專案網站)。以此方式使用主機命名型網站集合的一項優點,是建立網域 URL 之間的額外隔離,合作夥伴共同作業解決方案可能需要此額外的隔離。但是,此方法的缺點是由於管理更多主機名稱 (包括管理 SSL 憑證),而導致成本增加。此外,如果使用 SAML 驗證,也需要其他設定 (請參閱本文稍後的<搭配主機名稱網站使用 SAML 驗證>)。Extranet with Dedicated Zones for Authentication — This sample illustrates many top-level project sites with vanity URLs by using host-named sites for each project site (instead of organizing project sites underneath a top-level site collection). One advantage of using host-named site collections in this manner is creating additional isolation between domain URLs, which might be desired in a partner collaboration solution. However, the tradeoff of this approach is the additional costs of managing a greater number of host names, including managing SSL certificates. Also, if SAML authentication is used, additional configuration is required (see "Using SAML authentication with host-named sites" later in this article).

SharePoint Server 的宣告式驗證Claims-based authentication for SharePoint Server

SharePoint Server 中的驗證運作方式,會影響與實作這些設計範例所代表之選項相關的設計決策。以下為一些範例:The way that authentication works in for SharePoint Server might influence design decisions that are related to implementing choices represented by these design samples. Here are some examples:

  • 在 SharePoint Server 中,宣告式驗證是預設模式,也是唯一透過管理中心提供的選項。傳統模式驗證可透過 PowerShell 實作。In SharePoint Server, claims-based authentication is the default mode and the only option available through Central Administration. Classic-mode authentication can be implemented by using PowerShell.

  • 在 SharePoint Server 中,您不需要在負載平衡器上設定伺服器相關性,以使用 SAML 宣告驗證。SharePoint Server 完全支援非相關性負載平衡。In SharePoint Server, you don't have to configure server affinity on the load balancer to use SAML claims authentication. SharePoint Server fully supports non-affinity load balancing.

在 SharePoint Server 中,搜尋編目帳戶必須使用整合式 Windows 驗證 (NTLM 或 Kerberos) 透過「預設」區域存取內容。由於宣告驗證允許一個區域有多種驗證類型,因此這項需求應該不會影響其他驗證需求。In SharePoint Server the search crawl account requires access to content through the Default zone by using Integrated Windows authentication (NTLM or Kerberos). Because claims authentication allows multiple types of authentication in one zone, this requirement should not affect other authentication requirements.

設計範例功能摘要Summary of design sample features

下表摘要本文所討論的三種設計範例。The following table summarizes the three design samples that are discussed in this article.

表:設計範例摘要Table: Summary of design samples

設計範例Design Sample 包含Includes 主要設計元素Key design elements
採用路徑型網站的公司入口網站Corporate Portal with Path-based Sites
組織內最常部署的網站類型。Most common types of sites deployed within an organization.
路徑型網站集合Path-based site collections
宣告式驗證Claims-based authentication
單一區域實作多個驗證提供者及驗證類型Multiple authentication providers and authentication types implemented in a single zone
採用主機名稱網站的公司入口網站Corporate Portal with Host-names sites
組織內最常部署的網站類型。Most common types of sites deployed within an organization.
主機命名型網站集合Host-named site collections
宣告式驗證Claims-based authentication
單一區域實作多個驗證提供者及驗證類型Multiple authentication providers and authentication types implemented in a single zone
設有驗證專用區域的外部網路Extranet with Dedicated Zones for Authentication
僅限合作夥伴網站。提供合作夥伴共同作業的其他設定。Only the partner web site. Provides an alternate configuration for partner collaboration.
主機命名型網站集合Host-named site collections
宣告式驗證Claims-based authentication
每個驗證方法使用不同區域Different zone for each authentication method

設計範例所包含的網站Sites included in the design samples

本節設計範例中包含的頂層網站。This section describes the top-level sites that are included in the design samples.

內部網路網站Intranet sites

公司入口網路包含下列用於內部網路的網站:The corporate portal includes the following sites for intranet use:

  • 已發佈的內部網路內容 (例如 HRweb)Published intranet content (such as HRweb)

  • 共同作業小組網站Collaborative team sites

  • 我的網站My Sites

這些都是員工每天使用的內容和共同作業網站。這些應用程式各自代表特殊的內容類型。每種內容類型包含下列屬性:Together, these are the content and collaboration sites that employees use on a day-to-day basis. Individually, each of these applications represents a distinct type of content. Each type of content has the following properties:

  • 強調 SharePoint Server 的不同功能。Emphasizes different features of SharePoint Server.

  • 主控不同資料特性的資料。Hosts data with different data characteristics.

  • 會因不同使用設定檔而異。Is subject to a different usage profile.

  • 需要不同的權限管理策略。Requires a different permissions management strategy.

因此,上述每個應用程式的設計選擇都是要最佳化每個應用程式的效能及安全性。Consequently, design choices for each of these applications are intended to optimize the performance and security for each application.

服務應用程式的設計將結合上述三個應用程式,以提供下列功能:The design of service applications brings these three applications together to provide the following features:

  • 整體企業搜尋Enterprise-wide search

  • 共用設定檔資料及企業中繼資料Shared profile data and enterprise metadata

下圖擷取自「採用路徑型網站集合的公司入口網站」設計範例,顯示組成公司內部網路的三種網站類型。The following illustration, from the Corporate Portal with Path-based Site Collections design sample, shows the three types of sites that make up the corporate intranet.

組成公司內部網路的網站類型Types of sites that make up the corporate intranet

Intranet sites

合作夥伴 Web 應用程式Partner web application

合作夥伴 Web 應用程式會架設可供外部使用的網站,以與合作夥伴公司和個別合作夥伴進行安全的共同作業。此應用程式的目的是要讓員工輕鬆地建立網站以進行安全的共同作業。合作夥伴將無權存取伺服器陣列主控的其他內容類型。區域和服務應用程式均針對此目的而設計。此外,個別網站擁有人可管理其網站的權限,並僅邀請必要的參與者共同作業。The partner web application hosts externally-available sites for secure collaboration with partner companies and individual partners. This application is intended for employees to easily create sites for secure collaboration. Partners cannot access other types of content that the server farm hosts. The design for zones and service applications addresses this goal. Additionally, individual site owners manage permissions for their sites and invite only necessary participants to collaborate.

在外部網路設計範例中,這是唯一的代表性網站類型。In the extranet design sample, this is the only type of represented site.

整體設計目標Overall design goals

設計範例提供 SharePoint Server 功能在數種常見網站類型中的實際實作。本文將討論每種個別應用程式的設計實作。設計範例的主要設計目標如下:The design samples provide practical implementations of SharePoint Server features within several common types of sites. The design implementations for each of the individual applications are discussed in this article. Following are the key design goals for the design samples:

  • 在設計環境時,建立一個可以成長的架構。Create a framework for designing an environment that can grow.

    個別網站類型的設計決策將不會妨礙新增其他網站類型。例如,初始部署可能只包括共同作業小組網站,或只包括構成內部網路的三個網站類型 (小組網站、「我的網站」及已發佈的內部網路內容)。如果使用類似的邏輯架構設計,則可以將網站新增至解決方案,而不會影響初始解決方案的設計。換言之,此設計不包含限制環境使用的設計選擇。Design decisions for individual types of sites do not prevent the addition of other types of sites. For example, an initial deployment might include only collaborative team sites or only the three types of sites that compose an intranet (team sites, My Sites, and published intranet content). If you use a similar logical architecture design, you can add sites to the solution without affecting the design of the initial solution. In other words, the design does not incorporate design choices that limit the use of the environment.

  • 在不影響不同網站類型的內容安全性之下,為多個使用者群組提供存取權。Provide access for several groups of users without compromising the security of the content within the different types of sites.

    來自不同網路區域 (內部網路及外部網路) 且使用不同驗證提供者的使用者都可以參與共同作業。此外,使用者只能存取他們可以存取的內容。如果依照類似的邏輯架構設計,則可對位於多個位置以及具有不同目標的使用者提供存取權。例如,您的初始設計可能只是要讓內部員工存取。不過,如果使用類似設計,您也可以讓遠端員工、合作夥伴員工、合作夥伴公司及客戶進行存取。Users from different network zones (both internal and external) who use different authentication providers can participate in collaboration. Also, users can only access the content they are intended to access. If you follow a similar logical architecture design, you can provide access to users who are in multiple locations and have different objectives. For example, your initial design might be intended only for internal employee access. However, if you use a similar design, you can also enable access to remote employees, partner employees, partner companies, and customers.

  • 確定設計可用於外部網路環境。Ensure that the design can be used in an extranet environment.

    謹慎地做出設計選擇,以確保解決方案能夠安全地部署於周邊網路。Make deliberate design choices to make sure that the solution can be securely deployed in a perimeter network.

本文其餘部分將討論出現在設計範例中的每個邏輯元件 (從上到下),並討論應用於設計範例的設計選擇。此方法的目的在於示範根據應用程式設定邏輯架構元件的不同方式。The rest of this article discusses each of the logical components that appear in the design sample (from top to bottom) and discusses the design choices that are applied to the design sample. The purpose of this approach is to demonstrate the different ways in which logical architecture components can be configured based on the application.

伺服器陣列Server farms

本節設計範例所述的伺服器陣列拓撲,並討論如何擴充超過一個伺服器陣列。This section describes the topologies of the server farms that are illustrated in the design sample and discusses scaling beyond a single farm.

伺服器陣列的拓撲Topology of the server farms

設計範例中的每個伺服器陣列都是由具有下列容錯拓撲的六部伺服器所組成:Each server farm in the design sample is composed of six servers with the following fault-tolerant topology:

  • 兩部前端網頁伺服器Two front-end web servers

  • 兩部應用程式伺服器Two application servers

  • 兩部安裝 SQL Server 並設定為支援 SQL Server 叢集、鏡像或 AlwaysOn 的資料庫伺服器。AlwaysOn 需要 SQL Server 2012。Two database servers with SQL Server installed and configured to support SQL Server clustering, mirroring, or AlwaysOn. AlwaysOn requires SQL Server 2012.

前端和應用程式伺服器的概念不同於 SharePoint Server 2016 的概念,請參閱<SharePoint Server 2016 的 MinRole 伺服器角色概觀The concept of front-end and application server is different in SharePoint Server 2016, see Overview of MinRole Server Roles in SharePoint Server 2016

此設計範例 SharePoint Server 的邏輯架構,如下所示:The design sample illustrates the logical architecture of SharePoint Server by showing that the following:

  • 在前端網頁伺服器間鏡像所有網站。All sites are mirrored across front-end web servers.

  • 管理中心網站安裝在應用程式伺服器上,讓使用者無法直接存取。The Central Administration site is installed on an application server to protect it from direct user access.

實際上,伺服器電腦數目及伺服器陣列拓撲只在增加容量和提升效能時,對邏輯架構而言才重要。您可以設計與伺服器陣列拓撲無關的邏輯架構。效能及容量規劃程序可協助您規劃伺服器陣列的大小,以符合效能及容量目標。如需詳細資訊,請參閱<規劃 SharePoint Server 2013 中規劃效能>。In reality, the number of server computers and the topology of the server farm are important to the logical architecture only to increase capacity and improve performance. You can design the logical architecture independent of the server farm topology. The process of planning performance and capacity helps you plan the size the server farm to meet performance and capacity goals. For more information, see Performance planning in SharePoint Server 2013.

使用者、區域及驗證Users, zones, and authentication

宣告是 SharePoint Server 的預設驗證模式,因此每個設計範例都會採用宣告式驗證。您可以使用 Windows PowerShell 實作傳統模式驗證,但是在傳統模式中無法使用某些 SharePoint Server 功能。如需採用傳統模式驗證之設計範例的詳細資訊,請參閱<設計範例:公司部署 (SharePoint Server 2010)Claims is the default mode of authentication in SharePoint Server and each design sample incorporates claims-based authentication. You can use Windows PowerShell to implement classic-mode authentication; however, some features of SharePoint Server are not available in classic mode. For more information about design samples that incorporate classic-mode authentication, see Design sample: Corporate deployment (SharePoint Server 2010)

下表列出公司入口網站設計範例與外部網路設計範例分別代表的兩個方法之間的差異。The following table lists the differences in the two approaches that are represented by the Corporate Portal Design sample and the Extranet Design sample.

表:比較設計範例中區域設定的方法Table: Contrasting approaches for zone configurations in the design samples

採用主機名稱網站的公司入口網站及採用路徑型網站的公司入口網站Corporate Portal with Host-named sites and Corporate Portal with Path-based sites 設有驗證專用區域的外部網路Extranet with Dedicated Zones for Authentication
驗證模式Mode of authentication
宣告Claims
宣告Claims
區域設定Zone configuration
一個區域,其中包含針對不同類別之使用者設定的多種驗證方法。One zone with multiple authentication methods configured for different classes of users.
多個區域,其中每個區域設定一種驗證方法。Multiple zones with one method of authentication configured for each zone.
URLURLs
所有類別的使用者使用相同的 URL 來存取所有網站。不論員工在公司網路內部或在遠端工作,都會使用相同的 URL。All classes of users use the same URL for each site. Employees use the same URL regardless of whether they are inside the corporate network or working remotely.
各類別的使用者使用不同的 URL 來存取網站。員工根據在公司網路內部或在遠端工作使用不同的 URL。Each class of user uses a different URL to access a site. Employees use a different URL depending on whether they are inside the corporate network or working remotely.
內部要求Internal requests
在公司網路內部起始的要求會透過閘道或 Proxy 伺服器傳出再傳回網路。這些要求使用 Secure Sockets Layer (SSL) 通訊協定保護。Requests that initiate inside the corporate network are routed out of the network and then back in through the gateway or proxy server. These requests are secured by using the Secure Sockets Layer (SSL) protocol.
您也可以使用分割 DNS 將要求直接路由傳送至伺服器的內部介面。Alternatively, split DNS can be used to route the requests directly to the internal interface for the servers.
在公司網路內部起始的要求會保留在公司內部。Requests that initiate inside the corporate network remain internal to the network.
使用者經驗User experience
系統會提示所有使用者選擇其用來登入的帳戶類型。All users are prompted to choose the type of account they are using to log in.
驗證方法已預定。使用者不需要透過登入頁面選取帳戶類型。The authentication method is predetermined. Users are not required to select the account type by using a logon page.

下列各節將特別討論如何透過這兩種不同方法使用驗證。The following sections specifically discuss how authentication is incorporated by using the two different approaches.

設有專用區域的外部網路設計範例Extranet with dedicated zones design sample

外部網路設計範例三種類別的使用者,每種類別使用者各指派至不同區域。在每個 Web 應用程式內,使用其中一種可用的區域名稱 (預設、內部網路、網際網路、自訂或外部網路),最多可建立五個區域。如設計範例所述,搜尋編目帳戶必須使用整合式 Windows 驗證 (NTLM 或 Kerberos 通訊協定) 存取「預設」區域。下表顯示外部網路設計範例中的區域設定方式。The extranet design sample illustrates three different classes of users, and each is assigned to a different zone. Within each web application, you can create up to five zones by using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet. The search crawl account requires access to the Default zone by using Integrated Windows authentication (NTLM or the Kerberos protocol), which is accounted for in the design sample. The following table shows how zones are set up in the extranet design sample.

表:外部網路設計範例所規定的區域、使用者及驗證類型Table: Zones, users, and authentication type prescribed by the extranet design sample

區域Zone 使用者Users 驗證Authentication
內部網路Intranet
內部及遠端員工Internal and remote employees
搜尋編目帳戶Search crawl account
NTLM 或 Kerberos 通訊協定NTLM or Kerberos protocol
使用直接存取或 VPN 連線的遠端員工。Remote employees who use Direct Access or VPN to connect.
預設Default
不同的合作夥伴Individual partners
選項:Options:
使用表單型驗證的 LDAP 目錄LDAP directory using forms-based authentication
與內部樹系具有單向信任並使用整合式 Windows 驗證的對外 Active Directory 網域服務 (AD DS) 樹系Externally-facing Active Directory Domain Services (AD DS) forest with a one-way trust to the internal forest and Integrated Windows authentication
使用 SAML 驗證之信任的身分識別提供者Trusted identity provider with SAML authentication
外部網路Extranet
合作夥伴公司Partner companies
使用 SAML 驗證之信任的合作夥伴身分識別提供者Trusted partner identity provider with SAML authentication

公司入口網站設計範例Corporate Portal design samples

宣告式驗證允許同一個區域使用多種驗證類型。公司入口網站設計範例的兩種版本針對所有驗證類型使用「預設」區域。Claims-based authentication allows multiple types of authentication in the same zone. The two versions of the Corporate Portal design sample use the Default zone for all authentication types.

下表顯示設計範例所規定的區域、使用者及驗證類型。The following table shows the zones, users, and authentication types that are prescribed by the design samples.

表:公司入口網站設計範例的區域、使用者及驗證Table: Zones, users, and authentication for the corporate portal design samples

區域Zone 使用者Users 提供者及驗證類型Provider and authentication type
預設Default
內部及遠端員工Internal and remote employees
使用表單型驗證或 SAML 驗證的 Active Directory 網域服務 (AD DS) 或 LDAP 存放區。Active Directory Domain Services (AD DS) or LDAP store with forms-based authentication or SAML authentication.
預設Default
不同的合作夥伴Individual partners
使用 SAML 驗證之信任的身分識別提供者,或使用表單型驗證的 SQL Server 資料庫Trusted identity provider with SAML authentication, or SQL Server database with forms-based authentication
預設Default
合作夥伴公司Partner companies
使用 SAML 驗證之信任的合作夥伴身分識別提供者Trusted partner identity provider with SAML authentication
預設Default
搜尋編目帳戶Search crawl account
使用 Windows NTLM 驗證的 AD DSAD DS with Windows NTLM authentication

在設計範例中,「已發佈的內部網路內容」網站、「小組網站」及「我的網站」僅可供員工 (包括位於內部及外部網路的員工) 存取。本設計範例針對這些可在內部及外部使用的網站,僅實作一個 URL (使用的是 SSL),且使用 AD DS 帳戶。如果需要,表單型驗證或 SAML 可以使用 LDAP,不過這需要額外設定。In the design sample, the Published Intranet Content site, Team Sites, and My Sites are only accessible to employees, whether they are inside or outside the network. The design sample implements only one URL (using SSL) for each of these sites that can be used both internally and externally. AD DS accounts are used. If needed, forms-based authentication or SAML can use LDAP, which requires additional configuration.

在本設計範例中,合作夥伴 Web 應用程式代表的是可讓合作夥伴員工及合作夥伴公司存取的外部網路網站。在此情況下使用的宣告式驗證需要設定與一或多個外部身分識別提供者的信任。您可以使用下列其中一種方式:In the design sample, the partner web application represents an extranet site that partner employees and partner companies can access. Claims-based authentication in this scenario requires you to configure trust with one or more external identity providers. You can use either one of the following approaches:

  • 您可以設定 SharePoint 伺服器陣列信任外部身分識別提供者,例如位於合作夥伴公司的提供者 (以直接驗證合作夥伴目錄)。You can configure the SharePoint farm to trust an external identity provider, such as the provider that resides in a partner company (to authenticate directly against the partner directory).

  • 您可以設定公司環境中的身分識別提供者信任外部身分識別提供者。這兩個組織中的管理員必須明確建立此關係。在此情況下,SharePoint 伺服器陣列會信任位於其自己公司環境內的身分識別提供者。當身分識別提供者傳送 Token 時,伺服器陣列會使用建立信任時所指定的 Token 簽署憑證,來確認 Token 是否有效。建議使用此方法。You can configure the identity provider inside the corporate environment to trust an external identity provider. Administrators in the two organizations must establish this relationship explicitly. In this scenario, the SharePoint farm trusts the identity provider from within its own corporate environment. When the identity provider sends a token, the farm uses the token signing certificate that was specified when the trust was established to confirm the validity of the token. We recommend this approach.

另一種替代宣告式環境驗證合作夥伴的方式是表單型驗證。您可以使用個別存放區 (例如資料庫) 來管理這些帳戶。Forms-based authentication is an alternative to a claims-based environment to authenticate partners. You use a separate store, such as a database, to manage these accounts.

區域Zones

當您設計區域時,有多個對部署成功與否十分重要的重要決策。這些決策包括下列區域的設計和設定決策:When you design zones, several key decisions are critical to the success of the deployment. These decisions include design and configuration decisions for the following zones:

  • 預設區域The Default zone

  • 進行外部存取的區域Zones for external access

下列各節說明設計範例中所採用的決策。The following sections describe the decisions that are incorporated in the design sample.

預設區域的設定需求Configuration requirements of the default zone

最需要仔細考量的區域就是「預設」區域。SharePoint Server 對於「預設」區域的設定方式有下列需求:The zone that involves the greatest consideration is the Default zone. SharePoint Server places the following requirements on how you configure the Default zone:

  • 當使用者要求無法與區域建立關聯時,會套用「預設」區域的驗證和原則。因此,「預設」區域必須是最安全的區域。When a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied. Consequently, the Default zone must be the most secure zone.

  • 管理電子郵件訊息包含「預設」區域的連結。這包括送給將達到配額限制之網站擁有人的訊息。因此,收到這類訊息和提醒的使用者,必須可透過「預設」區域存取連結。這對網站擁有人特別重要。Administrative e-mail messages include links from the Default zone. These include messages to owners of sites that are approaching quota limits. Consequently, users who receive these kinds of messages and alerts must be able to access links through the Default zone. This is especially important for site owners.

在 SharePoint Server 中,已指定主機的網站集合可以從任何區域存取。In SharePoint Server host-named site collections can be access from any zone.

為外部網路環境設定區域Configuring zones for an extranet environment

在外部網路環境中,區域的設計十分重要,原因在於下列兩個因素:In an extranet environment, the design of zones is critical for the following two reasons:

  • 有多個不同的網路可以起始使用者要求。在設計範例中,使用者會從內部網路、網際網路及合作夥伴公司起始要求。Several different networks can initiate user requests. In the design samples, users initiate requests from the internal network, the Internet, and partner companies.

  • 使用者會使用多個 Web 應用程式的內容。在設計範例中,內部網路由三個 Web 應用程式組成。此外,內部及遠端員工可能會在合作夥伴 Web 應用程式中提供和管理內容。Users consume content across multiple web applications. In the design sample, the intranet is composed of three web applications. Additionally, internal and remote employees can potentially contribute to and administer content in the partner web application.

如果外部網路環境包含多個區域,請務必遵循下列設計原則:If an extranet environment includes more than one zone, ensure that you follow these design principles:

  • 跨多個 Web 應用程式設定區域彼此鏡像。驗證設定和預定使用者應該相同。但各 Web 應用程式中與區域相關的原則可互不相同。例如,您必須確定相同的員工在所有 Web 應用程式中皆是使用內部網路區域。換言之,請勿在某 Web 應用程式設定內部網路區域供內部員工使用,而在另一個 Web 應用程式中將該區域設定供遠端員工使用。Configure zones across multiple web applications to mirror each other. The configuration of authentication and the intended users should be the same. However, policies that are associated with zones can differ across web applications. For example, make sure that you use the Intranet zone for the same employees across all web applications. In other words, do not configure the Intranet zone for internal employees in one web application and remote employees in another.

  • 如果使用路徑型網站集合,請針對每個區域和每個資源,適當且正確地設定備用存取對應。備用存取對應會在您建立區域時自動建立。但是,您可以設定 SharePoint Server 對外部資源 (例如檔案共用) 中的內容進行編目。您必須使用備用存取對應為每個區域手動建立連至這些外部資源的連結。If you use path-based site collections, configure alternate access mappings appropriately and accurately for each zone and each resource. Alternate access mappings are automatically created when you create a zone. However, you can configure SharePoint Server to crawl content in external resources, such as a file share. You must create links to these external resources manually for each zone by using alternate access mappings.

  • 如果使用主機命名型網站集合,請確定使用 PowerShell 將 URL 對應至適當的區域If you use host-named site collections, make sure that you use PowerShell to map URLs to the appropriate zones

如果跨 Web 應用程式中的區域未彼此鏡像,且外部資源連結不正確,則會發生下列風險:If zones across Web applications do not mirror each other and links to external resources are not appropriate, the following risks can occur:

  • 伺服器名稱、網域名稱系統 (DNS) 名稱及 IP 位址可能會公開於內部網路之外。Server names, Domain Name System (DNS) names, and IP addresses can potentially be exposed outside the internal network.

  • 使用者可能無法存取網站和其他資源。Users might be unable to access Web sites and other resources.

搭配主機名稱網站使用 SAML 驗證Using SAML authentication with host-named sites

如果設計需要搭配主機名稱網站使用 SAML 驗證,每個虛名 URL 需要下列項目:If a design includes the use of SAML authentication with host-named sites, each vanity URL requires the following:

  • SPTrustedIdentityTokenIssuer 上的新領域A new realm on the SPTrustedIdentityTokenIssuer

  • 身分識別提供者中的對應信賴憑證者。A corresponding relying party in the Identity Provider.

服務Services

服務架構會隨設計範例而有所不同。「採用主機名稱網站的公司入口網站」設計範例包含最簡單的服務架構。這是因為此設計範例使用一個 Web 應用程式,該 Web 應用程式只能容納一個服務應用程式群組 (又稱為 Proxy 群組)。The service architectures vary depending on the design sample. The Corporate Portal with Host-named Sites design sample includes the simplest architecture for services. This is because it uses one web application, which can accommodate only one service application group (also known as proxy group).

「採用路徑型網站的公司入口網站」範例使用合作夥伴網站的已分割服務,以隔離不同專案的資料。此設計範例包含兩個服務群組,其中一個用於內部網路網站,另一個用於合作夥伴共同作業網站。合作夥伴網站上會部署不同之受管理的中繼資料執行個體及搜尋執行個體,並分割這些服務。分割的服務需要訂閱設定服務,該服務只能透過 PowerShell 部署。The Corporate Portal with Path-based Sites example uses partitioned services for the Partner sites to isolate data between projects. This design sample incorporates two service groups, one for the intranet sites and one for the partner collaboration sites. Separate instances of Managed Metadata and Search are deployed for the Partner sites and these services are partitioned. Partitioned services require the Subscription Settings Service which can only be deployed by using PowerShell.

採用路徑型網站的公司入口網站服務架構Service architecture for the Corporate Portal with Path-based Sites

Services architecture

部署分割的服務會增加架構的複雜性,且稍後會更難將網站移轉至 Office 365。如果 Managed Metadata Service 執行個體和 Search Service 執行個體必須不同,對於合作夥伴網站而言較簡單作法是部署專用但未分割的執行個體。許多組織會依賴搜尋的安全性調整功能,而不是部署 Search Service 的專用執行個體。Deploying partitioned services adds complexity to the architecture and makes it difficult to migrate sites to Office 365 at a later time. A simpler option for the Partner sites is to deploy dedicated but unpartitioned instances of the Managed Metadata service and Search service if these are required to be separate. Many organizations rely on the security trimming feature of Search, rather than deploying dedicated instances of the Search service.

外部網路設計範例只包含一個 Proxy 群組,但是此設計範例也使用 Managed Metadata Service 和 Search Service 應用程式的分割服務。The Extranet design sample includes only one proxy group but it also uses partitioned services for both the Managed Metadata and Search service applications.

部署服務應用程式的主要設計決策,在於如何廣泛使用組織分類。若要簡化服務架構,可在所有 Web 應用程式之間共用受管理的中繼資料、使用者設定檔及搜尋,再藉由安全性調整來管理內容存取權。在「採用路徑型網站的公司入口網站」設計範例中,所有網站共用一個 Managed Metadata Service 執行個體。不過,在此設定下,所有使用者都能存取公司分類。解決方案架構師必須決定是否要實作多個 Managed Metadata Service 執行個體,也需決定如何廣泛共用使用者設定檔資料。The primary design decision for deploying service applications is how broadly to spread the organization taxonomy. To simplify the services architecture, share Managed Metadata, User Profile, and Search across all web apps and rely on security trimming to manage access to content. In the Corporate Portal with Path-based Sites design sample, one instance of the Managed Metadata service is shared across all sites. However, all users can access to the corporate taxonomy with this configuration. Solution architects must decide whether to implement multiple instances of the Managed Metadata service. They'll also need to decide how broadly to share the User Profile data.

在「採用路徑型網站集合的公司入口網站」範例中,合作夥伴網站會設定為透過自訂服務群組使用專用 Search Service 和 Managed Metadata Service 應用程式。其他服務應用程式會加入自訂群組,並透過此預設群組共用。此設計範例不包含 User Profile Service 應用程式,因此可防止合作夥伴使用者瀏覽組織中的人員資料。Within the Corporate Portal with Path-based Site Collections sample, partner web is configured to use dedicated Search and Managed Metadata service applications by using a custom service group. Other service applications are added to the custom group and these are shared with the default group. The design sample does not include the User Profile service application to prevent partner users from browsing people data in the organization.

在「採用主機命名型網站集合的公司入口網站」的簡化架構 (一個服務群組) 中,合作夥伴可存取整個公司分類,也可瀏覽組織中的人員資料。但是,搜尋結果範圍限為合作夥伴可存取的網站及內容。In the simplified architecture of the Corporate Portal with Host-named Site Collections (one service group), partners can access the entire corporate taxonomy and can browse people data in the organization. However, search limits results to sites and content that partners can access.

如果您的合作夥伴網站需要將專案之間的內容加以隔離,部署專用的服務應用程式 (如本文所示) 會是不錯的選擇。此作法雖然會使服務架構變得較複雜,但可以確保合作夥伴無法存取與內部網路內容相關的中繼資料,或甚至是合作夥伴網站內其他專案。外部網路設計範例也使用分割的服務。If your partner sites require content isolation between projects, deploying dedicated service applications is a good choice, as illustrated in this article. This increases the complexity of the services architecture but ensures that partners cannot access metadata that is associated with the Intranet content or even other projects within the partner web site. The Extranet design sample also uses partitioned services.

管理網站Administration sites

在設計範例中,會由應用程式伺服器主控每個伺服器陣列的 SharePoint 管理中心網站。如此可避免使用者直接連接到網站。如果效能瓶頸或安全性危害影響到前端網頁伺服器的可用性,則 SharePoint 管理中心網站會保持在可用狀態。In the design sample, an application server hosts the SharePoint Central Administration website for each server farm. This protects the site from direct user contact. If a performance bottleneck or security compromise affects the availability of the front-end web servers, the SharePoint Central Administration website remains available.

本設計範例及本文不涵蓋管理網站的負載平衡 URL。建議如下:The design sample and this article do not mention the load-balanced URLs for administration sites. Recommendations include the following:

  • 如果管理 URL 使用連接埠號碼,請使用非標準連接埠。URL 預設會包括連接埠號碼。雖然客戶對應 URL 通常不會包括連接埠號碼,不過管理網站使用連接埠號碼將可提高安全性,因為可將對這些網站的存取限制在非標準連接埠上。If administrative URLs use port numbers, use non-standard ports. URLs include port numbers by default. While customer-facing URLs typically do not include port numbers, using port numbers for administration sites can increase security by limiting access to these sites to non-standard ports.

  • 為管理網站建立單獨 DNS 項目。Create separate DNS entries for administration sites.

除了這些建議之外,您還可以讓 SharePoint 管理中心網站在多部應用程式伺服器之間達到負載平衡,以達到備援目的。In addition to these recommendations, you can optionally load-balance the SharePoint Central Administration website across multiple application servers to achieve redundancy.

應用程式集區Application pools

實作單獨 Internet Information Services (IIS) 應用程式集區的目的,一般是為了隔離內容之間的處理序。應用程式集區可讓多個網站在相同的伺服器電腦上執行,且仍然保有其各自工作者處理序及身分識別。這可防止攻擊者透過在其中一個網站插入程式碼,來影響其他網站上的其他伺服器或網站。Separate Internet Information Services (IIS) application pools are typically implemented to achieve process isolation between content. Application pools provide a way for multiple sites to run on the same server computer but still have their own worker processes and identity. This helps to prevent an attacker who injects code on one site from affecting other servers or sites on other sites.

如果將單一應用程式集區和 Web 應用程式搭配主機命名型網站集合使用,則只會在指令碼層級提供網域 URL 之間的隔離。If a single application pool and web application is used together with host-named site collections, isolation is provided between domain URLs but only at the scripting level.

如果選擇實作多個應用程式集區,請考慮針對下列各個案例使用專用應用程式集區:If you choose to implement more than one application pool, consider a dedicated application pool for each of the following scenarios:

  • 要區隔已驗證內容與匿名內容。如果由同一個伺服器陣列架設公司網際網路網站,請將此網站置於專用 Web 應用程式和應用程式集區中。To separate authenticated content from anonymous content. If the same farm hosts the company Internet site, place this site in a dedicated web application and application pool.

  • 要將儲存後端資料系統密碼的網站,與會和後端資料系統互動的網站之間有所隔離 (雖然可改用 Secure Store Service 來達到這個目的)。To isolate sites that store passwords for and interact with backend data systems (although the Secure Store Service can be used for this purpose instead).

「採用主機名稱網站的公司入口網站」設計範例及「設有驗證專用區域的外部網路」設計範例會實作單一應用程式集區及 Web 應用程式來存放所有內容。服務應用程式和 SharePoint 管理中心網站需要不同的應用程式集區。The Corporate Portal with host-named sites design sample and the Extranet with Dedicated Zones for Authentication design sample both implement a single application pool and web application for all content. Separate application pools are required for service applications and the SharePoint Central Administration website.

「採用路徑型網站的公司入口網站」設計範例使用下列方式,透過個別應用程式集區來實作內容之間的處理序隔離:The Corporate Portal with Path-based Sites design sample implements process isolation between content by using separate application pools in the following ways:

  • 管理網站都架設在專用應用程式集區中。這是 SharePoint Server 的需求。The administration site is hosted in a dedicated application pool. This is a requirement of SharePoint Server.

  • 所有服務應用程式會部署至單一應用程式集區。除非有其他有力的原因,必須將服務應用程式部署至不同應用程式集區,否則這會是建議的設定。針對所有服務應用程式使用一個應用程式集區可最佳化效能,並減少要管理的應用程式集區數目。All service applications are deployed to a single application pool. Unless there is a compelling reason to deploy service applications to different application pools, this is the recommended configuration. One application pool for all service applications optimizes performance and reduces the number of application pools to manage.

  • 內部網路內容分成兩個不同應用程式集區。其中一個應用程式集區主控共同作業內容 (「我的網站」及小組網站);另一個應用程式集區主控已發佈的內部網路內容。此設定可為較可能使用商務資料連線的已發佈內部網路內容提供處理序隔離。Intranet content is divided into two different application pools. One application pool hosts collaborative content (My Sites and team sites). A separate application pool hosts the published intranet content. This configuration provides process isolation for the published intranet content in which business data connections are more likely to be used.

  • 專用應用程式集區主控合作夥伴 Web 應用程式。A dedicated application pool hosts the partner web application.

Web 應用程式Web applications

Web 應用程式係為 SharePoint Server 所建立並使用的 IIS 網站。每個 Web 應用程式在 IIS 中代表不同網站。A web application is an IIS web site that SharePoint Server creates and uses. Each Web application is represented by a different Web site in IIS.

如果選擇實作多個 Web 應用程式,請考慮下列使用案例:If you choose to implement more than one web application, consider the following use cases:

  • 使匿名內容與已驗證內容之間有所區隔Separate anonymous content from authenticated content.

    如果由同一個伺服器陣列架設公司網際網路網站,請將此網站置於專用 Web 應用程式和應用程式集區中。If the same farm hosts the company Internet site, place this site in a dedicated web application and application pool.

  • 隔離使用者Isolate users

    在設計範例中,會由專用 Web 應用程式及應用程式集區架設合作夥伴網站,確保合作夥伴無法存取內部網路內容。In the design sample, a dedicated web application and application pool hosts the partner web site to make sure that partners do not have access to the intranet content.

  • 強制規定權限Enforce permissions

    專用 Web 應用程式可對 Web 應用程式內的區域實作原則以強制執行權限。例如,您可以為公司網際網路網站建立原則,明確拒絕一或多個使用者群組的寫入權限。不論 Web 應用程式中個別網站或文件上設定的權限為何,都會強制執行原則。A dedicated web application provides the opportunity to implement policies on the zones within the web application to enforce permissions. For example, you can create policies for the company Internet site to explicitly deny write access to one or more groups of users. Policies are enforced regardless of permissions that are configured on individual sites or documents in the web application.

  • 最佳化效能Optimize performance

    若 Web 應用程式與其他具有類似資料特性的應用程式放在一起,則這些應用程式可達到較好的效能。例如,「我的網站」的資料特性包括大量規模較小的網站。相對地,小組網站通常會包含少量的極大型網站。將這兩種不同類型的網站置於不同的 Web 應用程式,產生的資料庫就會包含特性類似的資料,如此可最佳化資料庫效能。在設計範例中,「我的網站」及小組網站並沒有特有的資料隔離需求,它們會共用相同的應用程式集區。不過,「我的網站」及小組網站會置於不同的 Web 應用程式中,以最佳化效能。Applications achieve better performance if you place them in web applications with other applications of similar data characteristics. For example, the data characteristics of My Sites include a large number of sites that are small in size. In contrast, team sites typically encompass a smaller number of very large sites. By placing these two different types of sites in separate web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance. In the design sample, My Sites and team sites do not have unique data isolation requirements—they share the same application pool. Nonetheless, My Sites and team sites are placed in separate web applications to optimize performance.

  • 最佳化管理性Optimize manageability

    建立不同 Web 應用程式會產生不同的網站和資料庫,所以您可以實作不同的網站限制 (資源回收筒、到期時間和大小),以及交涉不同的服務等級協定。例如,如果「我的網站」內容不是您組織中最重要的內容類型,您可能會允許較多時間來還原這些內容。如此可讓您先還原較重要的內容,再還原「我的網站」內容。在設計範例中,「我的網站」位於不同的 Web 應用程式中,可讓管理員能夠較對待其他應用程式採取更積極的方式,管理「我的網站」的成長。Because creating separate Web applications results in separate sites and databases, you can implement different site limits (recycle bin, expiration, and size) and negotiate different service-level agreements. For example, you might allow more time to restore My Site content if this is not the most critical type of content within your organization. This enables you to restore more critical content before you restore My Site content. In the design sample, My Sites are in a separate web application to enable administrators to more aggressively manage growth compared to other applications.

如果搭配單一 Web 應用程式實作主機命名型網站集合,每個頂層網站會是個別網域,以讓您達成其中一些目標,例如透過實作不同的網站限制來最佳化管理性。If you implement host-named site collections with a single web application, each top-level site is a separate domain which enables you to achieve some of these goals, such as optimizing manageability by implementing different site limits.

網站集合Site collections

部署網站時,建議組態為使用主機命名型網站集合,其中所有網站皆位於單一 Web 應用程式內。建議使用此設定來部署網站,因為其與 Office 365 環境使用的架構相同。因此,這是受到最嚴厲測試的組態。新功能 (包括應用程式模型和要求管理) 已針對此組態最佳化,因此此組態是從今以後的版本最可靠的組態。The recommended configuration for deploying sites is using host-named site collections with all sites located within a single web application. This configuration is recommended to deploy sites because it is the same architecture that the Office 365 environment uses. Consequently this is the most heavily tested configuration. New features, including the App model and Request Management, are optimized for this configuration, and it is the most reliable configuration going forward.

儘管建議您對大多數的架構使用主機命名型網站集合,但若有適用下列任一條件的情況,則應該使用傳統路徑型網站集合和備用存取對應:Although we recommend host-named site collections for most architectures, you should use the traditional path-based site collections and alternate access mapping if any of the following conditions apply:

  • 您必須使用屬於 SharePoint Server 2016 預設安裝一部分的自助網站架設功能。You need to use the Self Service Site Creation feature that is part of the default installation of SharePoint Server 2016.

    這不適用於自訂自助網站架設解決方案。This does not apply to custom self-service site creation solutions.

  • Web 應用程式需要唯一的包含相對路徑或包含絕對路徑。A web application requires unique wild card inclusions or explicit inclusions.

    您可以在伺服器陣列層級建立主機命名型網站集合的包含路徑,這些路徑可供所有主機名稱網站使用。伺服器陣列中的所有主機命名型網站集合會共用相同的包含路徑,但不需要使用這些路徑。相反地,您為路徑型網站集合建立的包含路徑只會套用至單一 Web 應用程式。You create inclusions for host-named site collections at the farm level, and they are available for all host-named sites. All host-named site collections in a farm share the same inclusions but do not need to use them. In contrast, inclusions that you create for path-based site collections apply only to a single web application.

  • 需要 SSL 終止,但是無法設定您的 SSL 終止裝置以產生必要的自訂 HTTP 標頭。SSL termination is required but your SSL termination device cannot be configured to produce the necessary custom HTTP header.

    如果不需要 SSL 終止,您仍然可以使用 SSL 橋接主機命名型網站集合與這些裝置。You can still use SSL bridging with host-named site collections with these devices if SSL termination is not a requirement.

  • 您要規劃使用不同的應用程式集區以取得這些應用程式集區所提供的額外安全性,否則您需要使用多個 Proxy 群組。You plan to use different application pools for the additional security that these provide or you need to use multiple proxy groups.

如需包括和路徑型網站集合進行比較在內的主機命名型網站集合詳細資訊,請參閱<已指定主機的網站集合架構與部署 (SharePoint 2013)>。For more information about host-named site collections, including a comparison with path-based site collections, see Host-named site collection architecture and deployment (SharePoint 2013).

網站集合的設計目標Design goals for site collections

網站集合可銜接邏輯架構和資訊架構。網站集合的設計目的,是要滿足 URL 設計需求,以及建立內容的邏輯分隔。針對每個網站集合,管理路徑會加入頂層網站集合的第二層。如需 URL 需求及使用管理路徑的詳細資訊,請參閱本文稍後的<區域及 URL>。在網站集合第二層之下,每個網站都是子網站。Site collections bridge logical architecture and information architecture. The design goals for site collections are to fulfill requirements for URL design and to create logical divisions of content. For each site collection, managed paths incorporate a second tier of top-level site collections. For more information about URL requirements and using managed paths, see Zones and URLs later in this article. Beyond the second tier of site collections, each site is a subsite.

下圖說明「小組網站」的網站層級。The following diagram illustrates the site hierarchy of Team Sites.

小組網站的網站階層Site hierarchy for team sites

小組網站

針對路徑型網站集合和主機名稱集合,資訊架構會以網站集合第二層為主。下列各節說明設計範例如何根據網站本質做出選擇。For both path-based site collections and host-named collections, the information architecture revolves around the second tier of site collections. The following section describes how design samples incorporate choices based on the nature of the sites.

已發佈的內部網路內容Published intranet content

對於已發佈的內部網路內容 Web 應用程式,將假設公司內多個部門將主控已發佈內容。在設計範例中,會由不同的網站集合主控每個部門的內容。這樣做有下列好處:The assumption for the published intranet content web application is that multiple divisions within the company will host published content. In the design sample, a separate site collection hosts each division's content. This provides the following advantages:

  • 每個部門可單獨管理內容及管理權限。Each division can manage content and administer permissions independently.

  • 每個部門可在專用資料庫中儲存其內容。Each division can store its content in a dedicated database.

多個網站集合的缺點包括:The disadvantages of multiple site collections include the following:

  • 您無法跨網站集合共用主版頁面、頁面配置、範本、網頁組件及導覽方式。You cannot share master pages, page layouts, templates, Web Parts, and navigation be across site collections.

  • 協調不同網站集合的自訂和導覽需要更多心力。Coordination of customizations and navigation across site collections requires more effort.

根據內部網路網站的所有資訊架構及設計,已發佈內容可以向使用者呈現為一個無縫體驗。或者,每個網站集合也可以呈現為單獨網站。Depending on the information architecture and design of the intranet sites together, the published content can appear to the user as a seamless experience. Alternatively, each site collection can appear to be a separate web site.

我的網站My Sites

「我的網站」具有特殊特性,且「我的網站」的部署建議十分簡單。在設計範例中,「我的網站」網站集合所用頂層網站的 URL 為 http://my。所建立的第一個頂層網站集合使用「我的網站主機」範本,而且使用管理路徑 (即使用包含相對路徑),如此可允許使用者建立無限多個網站。所有在管理路徑之下的網站均為使用「個人網站」範本的獨立網站集合。URL 最後會加上使用者名稱,格式為 http://my personal/ username。下圖說明「我的網站」。My Sites have distinct characteristics and the deployment recommendations for My Sites are straightforward. In the design samples, the My Sites site collection incorporates a top-level site with the URL of http://my. The first top-level site collection that is created uses the My Site Host template. A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites below the managed path are independent site collections that use the Personal Site template. The user name is appended to the URL in the form http://my personal/ username. The following illustration illustrates My Sites.

「我的網站」的網站階層Site hierarchy for My Sites

我的網站

小組網站Team sites

您可以使用下面其中一種方式來設計「小組網站」應用程式中的網站集合:You can use either of the following two approaches to design site collections in a Team Site application:

  • 允許小組透過自助網站架設方式來建立網站集合。此方式的優點,在於小組可以視需要輕鬆建立網站,而不需要管理員的協助。此方式的缺點包括:Allow teams to create site collections through self-service site creation. The advantage of this approach is that teams can easily create a site, as needed, without assistance from an administrator. Disadvantages to this approach include the following:

    • 無法實作完善規劃的分類。You lose the opportunity to implement a thoughtful taxonomy.

    • 無法讓可能共用網站集合的專案或小組共用範本及導覽方式。You cannot share templates and navigation across projects or teams that might otherwise share a site collection.

  • 根據組織運作方式,為組織建立有限的網站集合。在此方法中,SharePoint 管理員會建立網站集合。建立網站集合後,小組可以在網站集合中建立網站。此方式可實作完善規劃的分類,提供因應小組網站在管理及成長上的結構。其中還提供許多方式可讓共用網站集合的專案及小組共用範本及導覽方式。但是,此方法也包含下列缺點:Create a finite number of site collections for your organization based on the way your organization operates. In this approach, a SharePoint administrator creates site collections. After a site collection is created, teams can create sites within the site collection. This approach provides the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection. However, this approach also includes some disadvantages.

設計範例採用的是第二種方式,這會使小組網站與已發佈內部網路內容具有類似的網站集合階層。資訊架構師的挑戰就在於建立適合組織的網站集合第二層。下表建議不同的組織類型。The design samples incorporate the second approach, which results in a similar site collection hierarchy for team sites and published intranet content. The challenge for information architects is to create a second tier of site collections that makes sense for the organization. The following table suggests different types of organizations.

表:建議的網站集合分類Table: Suggested site collection taxonomies

組織類型Type of organization 建議的網站集合分類Suggested site collection taxonomies
產品開發Product development
為開發中的每項產品建立網站集合。允許參與小組在網站集合中建立網站。Create a site collection for each product under development. Allow contributing teams to create sites within the site collection.
針對每個長期開發專案,為參與產品工作的每個大型小組,建立網站集合。例如,為下列每個小組建立一個網站集合:設計者、工程師和內容開發人員。For each long-term development project, create a site collection for each large team that contributes to the product. For example, create one site collection for each of the following teams: designers, engineers, and content developers.
研究Research
為每個長期研究專案建立網站集合。Create a site collection for each long-term research project.
為每種類別的研究專案建立網站集合。Create a site collection for each category of research projects.
高等教育機構Higher education institution
為每個學術部門建立網站集合。Create a site collection for each academic department.
國家立法機構State legislative office
為每個政黨建立網站集合。同屬一個政黨的政府官員可以共用範本及導覽方式。Create a site collection for each political party. Government officials who share party affiliation can share templates and navigation.
為每個委員會建立網站集合。或者,為所有委員會建立一個網站集合。Create a site collection for each committee. Or, create one site collection for all committees.
企業法律事務所Corporate law office
為企業客戶建立網站集合。Create a site collection for each corporate client.
製造Manufacturing
為每個產品線建立網站集合。Create a site collection for each line of products.

合作夥伴 Web 應用程式Partner web application

合作夥伴網站主要用於針對設有一定範圍或一定時限的專案,與外部合作夥伴進行共同作業。根據設計,合作夥伴 Web 應用程式內的各個網站不會彼此相關。合作夥伴 Web 應用程式的需求包括必須確保下列事項:Partner web is intended to be used for collaboration with external partners on projects that have finite scopes or finite durations. By design, sites in the partner web application are not intended to be related. The requirements for the partner web application include ensuring that:

  • 專案擁有者可以輕鬆建立合作夥伴共同作業的網站。Project owners can easily create sites for partner collaboration.

  • 合作夥伴及其他參與者只能存取他們所處理的專案。Partners and other contributors can access only the project they work on.

  • 網站擁有人管理權限。Site owners manage permissions.

  • 搜尋某個專案所得的結果不會公開其他專案的內容。Search results from within one project do not expose content from other projects.

  • 管理員可以輕易識別出不再使用的網站,並刪除這些網站。Administrators can easily identify sites that are no longer used and delete these sites.

為滿足這些需求,在設計範例中,每個專案各有一個網站集合。這兩種公司入口網站設計範例都使用管理路徑,在根網站集合下建立網站集合的第二層。或者,外部網路設計範例可以使用主機命名型網站集合,將每個合作夥伴網站設為頂層網站集合。不論哪種方式,個別網站集合都可讓專案之間有適當的隔離層級。To satisfy these requirements, the design sample incorporates a site collection for each project. Both Corporate Portal design samples utilize a managed path to create a second tier of site collections below a root site collection. Alternatively, the Extranet design sample makes each partner site a top-level site collection by using host-named site collections. Either way, individual site collections provide the appropriate level of isolation between projects.

如果您想使用屬於 SharePoint Server 預設安裝一部分的自助網站架設功能 (相對於為組織開發的自訂解決方案),請使用路徑型網站集合。主機命名型網站集合還無法使用此功能。If you plan to use the Self Service Site Creation feature that is part of the default installation of SharePoint Server (as opposed to a custom solution developed for your organization), then use path-based site collections. Host-named site collections do not yet work with this feature.

內容資料庫Content databases

您可以使用下列兩種方式,在設計中加入內容資料庫 (設計範例即同時使用這兩種方式):You can use the following two approaches to incorporate content databases into the design (the design sample incorporates both approaches):

  • 為具有適當大小警告閾值的內容資料庫建立目標大小。在資料庫達到大小警告閾值時,建立新的資料庫。使用此方式,會僅根據大小目標值,自動將網站集合新增至可用的一或多個資料庫。這是最常用的方式。Establish target sizes for content databases with appropriate size-warning thresholds. Create a new database when a database reaches size-warning thresholds. With this approach, site collections are automatically added to the available database or databases, based on size targets alone. This is the most commonly used approach.

  • 建立網站集合與特定內容資料庫的關聯。此方式可讓您將一或多個網站集合放入管理員可以與其他資料庫分開管理的專用資料庫。Associate site collections to specific content databases. This approach enables you to place one or more site collections in a dedicated database that administrators can manage independently from the rest.

若選擇將網站集合關聯至特定內容資料庫,則可以使用下列方法來完成:If you choose to associate site collections to specific content databases, you can use the following methods to accomplish this:

  • 使用 PowerShell 在特定資料庫中建立網站集合。Use PowerShell to create a site collection in a specific database.

  • 套用下列資料庫容量設定,讓資料庫專用於單一網站集合:Dedicate a database to a single site collection by applying the following database capacity settings:

    • 警告事件產生前的網站數目 = 1Number of sites before a warning event is generated = 1

    • 此資料庫中可以建立的最大網站數目 = 1Maximum number of sites that can be created in this database = 1

  • 完成下列步驟,將網站集合群組新增至專用資料庫:Add a group of site collections to a dedicated database by completing the following steps:

  1. 在 Web 應用程式中,建立資料庫,並將資料庫狀態設為 [就緒]。Within the web application, create the database and set the database status to Ready.

  2. 將所有其他資料庫的狀態設定為 [離線]。內容資料庫離線時,無法建立新的網站集合。但是,讀取與寫入作業仍可存取離線資料庫中的現有網站集合。Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still accessible for both read and write operations.

  3. 建立網站集合。它們會自動新增至資料庫。Create the site collections. They are automatically added to the database.

  4. 將所有其他資料庫的狀態設回 [就緒]。Set the status of all other databases back to Ready.

已發佈的內部網路內容Published intranet content

對於已發佈的內部網路內容,公司入口網站設計範例僅使用單一資料庫,以便於管理。如有需要,請根據目標大小值新增資料庫。For published intranet content, the corporate portal design samples incorporate a single database for ease of management. Add databases based on target size goals, if needed.

我的網站My Sites

對於「我的網站」,公司入口網站設計範例藉由管理資料庫達到目標大小上限,而獲得規模效益。為達到此目的,設定了下列設定:For My Sites, the corporate portal design samples achieve scale efficiency by managing databases to the maximum target size. The following settings are configured to achieve this goal:

  • 限制網站儲存量的最大值: 這個設定設定於管理中心的 [配額範本] 頁面上,可限制個人網站大小。Limit site storage to a maximum of: This setting, which you configure on the Quota Templates page in Central Administration, limits the size of a personal site.

  • 第二階段資源回收筒: 您Web 應用程式一般設定] 頁面設定此設定可決定的額外配置給第二階段資源回收筒的空間量。Second stage Recycle Bin: This setting, which you configure on the Web Application General Settings page, determines the amount of additional space that is allocated to the second-stage recycle bin.

  • 這個資料庫可以建立的網站數目上限:此設定是在您建立資料庫時設定。請根據您在前面兩項所指定的值,來計算總共可允許的網站大小。然後,根據每個資料庫的大小目標,決定資料庫可容納的網站數目。Maximum number of sites that can be created in this database: This setting is configured when you create a database. Calculate the total allowable size of sites by using the numbers you specify for the previous two values. Then, based on the size goal for each database, determine how many sites will fit in the database.

在設計範例中,根據 175 GB 的資料庫目標大小和 1 GB 的「我的網站」目標大小,提供了下列範例大小設定:The design samples provide the following example size settings based on a target database size of 175 gigabytes (GB) and a target My Site size of 1 GB:

  • 每個網站的網站大小限制 = 1 GBSite size limits per site = 1 GB

  • 資料庫目標大小 = 175 GBTarget size of database = 175 GB

  • 保留給第二階段資源回收筒使用的空間 = 15%Reserved for second-stage recycle bin = 15%

  • 網站數目上限 = 180Maximum number of sites = 180

  • 網站層級警告 = 150Site level warning = 150

達到網站層級警告時,會建立新的資料庫。建立新的資料庫之後,新的「我的網站」會新增至具有最少網站集合的內容資料庫。When the site-level warning is reached, create a new database. After you create the new database, new My Sites are added to the content database that has the fewest site collections.

小組網站Team sites

大多數組織的小組網站應會遠大於「我的網站」。小組網站是建立在受管理路徑底下,每個小組網站集合可各有一個內容資料庫。在設計範例中,所提供的資料庫設定是以 30 GB 的網站集合限制為根據。請為您組織的小組網站選擇適當限制。Team sites for most organizations are expected to be much larger than My Sites. Team sites are created under a managed path, allowing one content database per team site collection. The design sample provides database settings based on a 30-GB limit for site collections. Choose a limit that is appropriate for team sites in your organization.

合作夥伴網站Partner web

類似「我的網站」,合作夥伴網站藉由管理資料庫達到目標大小上限,而獲得規模效益。Similar to My Sites, partner web achieves scale efficiency by managing databases to the maximum target size.

此設計範例提供了下列範例大小設定:The design samples provide the following example size settings:

  • 資料庫目標大小 = 200 GBTarget size of database = 200 GB

  • 每個網站的儲存配額 = 5 GBStorage quota per site = 5 GB

  • 網站數目上限 = 40Maximum number of sites = 40

  • 將製作網站集合架設在專用資料庫中Authoring site collection hosted in dedicated database

區域及 URLZones and URLs

設計範例說明如何在公司部署中協調多個網站之間的 URL。下列目標會影響 URL 的設計決策:The design samples illustrate how to coordinate URLs across multiple sites within a corporate deployment. The following goals influence design decisions for URLs:

  • URL 慣例不限制使用者藉以存取內容的區域。URL conventions do not limit the zones through users can access content.

  • 在設計範例中,標準 HTTP 及 HTTPS 連接埠 (80 及 443) 可用於所有應用程式。The standard HTTP and HTTPS ports (80 and 443) can be used across all applications in the design sample.

  • URL 不包括連接埠號碼。實際上,連接埠號碼一般不會用於實際執行環境。Port numbers are not included in URLs. In practice, port numbers are typically not used in production environments.

設計負載平衡 URLDesigning load-balanced URLs

在建立 Web 應用程式時,您必須選擇負載平衡 URL 以指派給該應用程式。您選擇的 URL 會套用至「預設」區域。此外,還必須為每個在 Web 應用程式中建立的額外區域建立負載平衡 URL。負載平衡的 URL 包括通訊協定、配置、主機名稱及連接埠 (若有使用)。在所有 Web 應用程式及區域中,負載平衡 URL 必須是唯一的。因此,每個應用程式及每個應用程式中的每個區域,在整個設計範例中都需使用唯一的 URL。When you create a web application, you must choose a load-balanced URL to assign to the application. The URL that you choose applies to the Default zone. Additionally, you must create a load-balanced URL for each additional zone that you create within a web application. The load-balanced URL includes the protocol, scheme, hostname, and port, if used. The load-balanced URL must be unique across all web applications and zones. Consequently, each web application and each zone within each web application requires a unique URL across the design sample.

內部網路Intranet

構成內部網路的三個網站集合都需使用唯一的 URL。在公司入口網站設計範例中,內部網路內容的目標對象包括內部員工及遠端員工。無論員工位於公司內部還是位於遠端,他們對這些網站都使用相同 URL。雖然此方法會讓 SharePoint 設計多一層安全性 (因為所有流量都屬於 SSL),不過此方法需要您選擇其他設定的替代方法:Each of the three site collections that make up the intranet requires a unique URL. In Corporate Portal design samples, the target audience for the intranet content is internal employees and remote employees. Employees use the same URLs for each of these sites regardless of whether they are on site or remote. This approach adds a layer of security to the SharePoint design (all traffic is SSL). However, this approach requires you to choose an alternative for additional configuration:

  • 透過防火牆或閘道產品路由內部流量及遠端流量。Route internal traffic through the firewall or gateway product along with remote traffic.

  • 設定分割 DNS 環境,以在內部網路中解析內部要求。Set up a split DNS environment to resolve internal requests within the internal network.

合作夥伴網站Partner web site

在設計範例中,內部員工、遠端員工及合作夥伴員工會存取合作夥伴網站。在公司入口網站設計範例中,所有使用者都輸入相同 URL,無論所用的驗證方法為何。在外部網路設計範例中,不同類型使用者分別輸入不同 URL。雖然個別合作夥伴及合作夥伴公司都是使用 SSL (HTTPS) 從外部存取合作夥伴網站,每一組人員還是需要不同 URL 才能享受到不同區域 (亦即,不同驗證方法及不同區域原則) 的好處。In the design samples, internal employees, remote employees, and partner employees access the partner web site. In the Corporate Portal design samples, all users enter the same URL regardless of the authentication method. In the Extranet design sample, each different type of user enters a different URL. Although both individual partners and partner companies use SSL (HTTPS) to access the partner web site externally, each group requires a different URL to apply the benefits of separate zones—that is, different authentication methods and different zone policies.

由於外部網路設計範例使用直接存取或 VPN 進行遠端員工存取,因此遠端員工和內部員工都使用相同的 URL。如果透過反向 Proxy 裝置設定遠端員工存取,則遠端員工需要使用 SSL 的個別 URL,因此需要額外的區域。最後,外部網路設計範例使用主機命名型網站集合,而不是單一頂層網站集合。因此,每個專案網站會有不同的 URL。Because the Extranet design sample uses Direct Access or VPN for remote employee access, both remote employees and internal employees use the same URLs. If access for remote employees is configured through a reverse proxy device, remote employees would require a separate URL using SSL, requiring an additional zone. Finally, the Extranet design sample incorporates host-named site collections instead of a single top-level site collection. Consequently, each project site has a different URL.

下表顯示內部員工、遠端員工及合作夥伴存取合作夥伴網站所用的範例 URL,如外部網路設計範例所示。The following table shows example URLs that internal employees, remote employees, and partners use to access the partner web site, as shown in the Extranet design sample.

表:外部網路設計範例的範例 URLTable: Example URLs from the Extranet design sample

區域Zone 範例 URLExample URL
內部及遠端員工Internal and remote employees
http://project1
不同的合作夥伴Individual partners
https://project2.fabrikam.com
合作夥伴公司Partner companies
https://TrustedPartnerProject1.fabrikam.com

在 URL 路徑中使用包含絕對路徑及包含相對路徑Using explicit and wildcard inclusions for URL paths

管理路徑可讓您指定 Web 應用程式之 URL 命名空間中用於網站集合的路徑。您可以指定在根網站的不同路徑下有一個或多個網站集合。若沒有管理路徑,所有在根網站集合下的網站都會是根網站集合的一部分。Managed paths enable you to specify the paths in the URL namespace of a web application that are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path below the root site. Without managed paths, all sites below the root site collection are part of the root site collection.

您可以建立下列兩種類型的管理路徑:You can create the following two types of managed paths:

  • 包含絕對路徑:指派具有明確 URL 的網站集合。一個包含絕對路徑只能套用至一個網站集合。您可以在根網站集合下建立許多包含絕對路徑。使用此方法建立的網站集合 URL 範例為 http://intranet/hr。每個新增的包含絕對路徑都會影響效能,因此,建議您使用包含絕對路徑建立的網站集合限制在 20 個左右。Explicit inclusion: A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can create many explicit inclusions below a root site collection. . An example URL for a site collection created by using this method is http://intranet/hr. There is a performance impact for every explicit path added so the recommendation is to limit the number of site collections created with an explicit inclusion to about 20.

  • 包含相對路徑:新增至 URL 的路徑。此路徑表示緊跟在路徑名稱後所指定的所有網站,都是唯一的網站集合。此選項常用於支援自助網站架設的網站集合 (例如「我的網站」)。使用此方法建立的網站集合 URL 範例為 http://my/personal/user1。Wildcard inclusion: A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used for site collections that support self-site creation, such as My Sites. An example URL for a site collection that is created by using this method is http://my/personal/user1.

實作主機命名型網站集合的管理路徑時,會在伺服器陣列層級建立這些管理路徑,且如果解決方案中包含多個 Web 應用程式,這些路徑會套用至所有 Web 應用程式。實作路徑型網站集合的管理路徑時,這些管理路徑只會套用至建立管理路徑的 Web 應用程式。When managed paths for host-named site collections are implemented, these managed paths are created at the farm level and paths apply across all web applications, if multiple web applications are included in the solution. When managed paths for path-based sites are implemented, these managed paths apply only to the Web application in which they were created.

設計範例同時使用這兩種管理路徑類型 (包含絕對路徑和包含相對路徑),如下列各節所述。The design sample incorporates the use of both types of managed paths (explicit inclusions and wildcard inclusions, as described in the following sections.

包含絕對路徑:已發佈的內部網路內容Explicit inclusions: Published intranet content

在設計範例中,已發佈的內部網路網站集合針對每個子網站 (例如,HR、設備和採購) 使用包含絕對路徑。這些網站集合都可以與不同內容資料庫產生關聯 (如有需要)。除非使用主機命名型網站集合,否則在此範例中使用包含絕對路徑,係假設 Web 應用程式中沒有建立其他類型的網站,包括包含相對路徑。In the design samples, the published intranet site collection incorporates explicit inclusions for each subsite, for example, HR, Facilities, and Purchasing. Each of these site collections can be associated with a different content database, if needed. Unless host-named site collections are used, the use of explicit inclusions in this example assumes that no other types of sites are created in the web application, including wildcard inclusions.

使用包含絕對路徑會產生下列 URL:The use of explicit inclusions results in the URLs:

在此範例中,根網站集合 http://intranet.fabrikam.com 代表內部網路的預設首頁。此網站預定會主控使用者的內容。In this example, the root site collection, http://intranet.fabrikam.com, represents the default home page for the intranet. This site is intended to host content for users.

包含相對路徑:小組網站、「我的網站」及合作夥伴網站Wildcard inclusions: Team Sites, My Sites, and Partner Web

小組網站、「我的網站」及合作夥伴 Web 應用程式使用包含相對路徑。包含相對路徑適用於允許使用者建立其自己的網站集合的應用程式,也適用於包含大量網站集合的 Web 應用程式。包含相對路徑表示萬用字元後面的下一個項目是網站集合的根網站。Team Sites, My Sites, and the partner web application incorporate the use of a wildcard inclusion. Wildcard inclusions are ideal for applications that allow users to create their own site collections and for web applications that include many site collections. A wildcard inclusion indicates that the next item after the wildcard is a root site of a site collection.

小組網站Team sites

在小組網站應用程式內,每個小組網站集合皆使用包含相對路徑。良好的控管作法建議將頂層小組網站數目保持在可管理的數目內。此外,小組網站的分類邏輯應該配合公司運作方式。Within the Team Sites application, wildcard inclusion is used for each team site collection. Good governance practices recommend that you keep the number of top-level team sites within a manageable number. Also, the taxonomy for team sites should be logical for the way your business operates.

使用包含相對路徑會產生下列 URL:The use of wildcard inclusions results in the URLs:

在此範例中,根網站集合 https://teams.fabrikam.com 不一定主控使用者的內容。In this example, the root site collection, https://teams.fabrikam.com, does not necessarily host content for users.

我的網站My Sites

「 我的網站提供自助網站架設。當瀏覽內部網路的使用者先按一下「 我的網站時、 「 我的網站會自動建立的使用者。在設計範例中,「 我的網站包含相對路徑具名/個人 (http://my/personal)。「 我的網站 」 功能會自動附加的使用者名稱的 url。My Sites offer self-service site creation. When a user who browses the intranet first clicks My Site, a My Site is automatically created for the user. In the design sample, My Sites include a wildcard inclusion named /personal (http://my/personal). The My Site feature automatically appends the user name to the URL.

這會產生下列格式的 URL:This results in URLs of the format:

合作夥伴網站Partner web

如果使用路徑型網站集合,您可以實作自助網站架設功能,以讓員工建立可與外部合作夥伴共同作業的安全網站。如果使用主機命名型網站集合,您可以實作自訂自助網站架設功能,或管理員可以在要求下建立合作夥伴專案網站。If path-based site collections are used, you can implement the self-service site creation feature to allow employees to create secure sites for collaboration with external partners. If host-named site collections are used, you can implement a custom self-service site creation feature or administrators can create partner project sites by request.

在公司入口網站設計範例中,合作夥伴 Web 應用程式包括包含相對路徑 /sites (http://partnerweb/sites)。這會產生下列格式的 URL:In Corporate Portal design samples, the partner web application includes a wildcard inclusion named /sites (http://partnerweb/sites). This results in URLs of the following format:

使用 AAM 和 DNS 協調 URLCoordinating URLs with AAM and DNS

如果實作路徑型網站集合,請為伺服器陣列中的每個網站 URL 設定備用存取對應 (AAM)。如此可確保 Web 要求對應至正確的網站,特別是在使用負載平衡或反向 Proxy 技術的環境中。If path-based site collections are implemented, configure alternate access mappings (AAM) for each site URL in the farm. This makes sure that web requests are mapped to the correct site, especially in environments that use load balancing or reverse proxy technologies.

您可以為內部網路存取設定單一名稱 URL (例如 http://teams。用戶端電腦會透過附加其 DNS 尾碼 (例如 fabrikam.com),然後發出具有該尾碼之名稱的 DNS 查閱,來解析這些 URL。例如,當 fabrikam.com 網域中的用戶端電腦要求 http://teams 時,電腦會將 http://teams.fabrikam.com 的要求傳送至 DNS。Single-name URLs, such as http://teams, can be configured for intranet access. A client computer resolves these URLs by appending the DNS suffix of the client computer, such as fabrikam.com, and then issuing a DNS lookup for the name with the suffix. For example, when a client computer in the fabrikam.com domain requests http://teams, the computer sends a request to DNS for http://teams.fabrikam.com.

您必須設定 DNS,才可以針對每個完整網域名稱 (FQDN) 使用 A 記錄 (或適用於 IPv6 的 AAAA)。此記錄會指向架設網站之網頁伺服器的負載平衡 IP 位址。在一般的實際執行部署中,除了 DNS 中靜態指派的 A 或 AAAA 記錄之外,您還可以設定伺服器使用靜態指派的 IP 位址。DNS must be configured to use an A record, or AAAA for IPv6, for each fully qualified domain name (FQDN). The record points to the load-balanced IP address for the web servers that host a site. In a typical production deployment, servers are configured to use statically assigned IP addresses, in addition to statically assigned A or AAAA records in DNS.

用戶端瀏覽器收到負載平衡 IP 位址之後,用戶端瀏覽器會連線至伺服器陣列中的前端網頁伺服器,然後傳送具有原始單一名稱 URL (http://teams 的 HTTP 要求。IIS 和 SharePoint Server 會根據在備用存取對應中進行的設定,將此要求辨識為內部網路區域的要求。如果使用者改為要求 https://teams.fabrikam.com,程序會類似,不同之處在於 IIS 和 SharePoint Server 會收到此 FQDN,因此會將此要求辨識為「預設」區域的要求。After a client browser receives the load-balanced IP address, the client browser connects to a front-end web server in the farm, and then sends an HTTP request that has the original single-name URL, http://teams. IIS and SharePoint Server recognize this as a request for the Intranet zone, based on the settings that are configured in alternate access mappings. If a user instead requests https://teams.fabrikam.com, the process is similar, but IIS and SharePoint Server receive this FQDN instead, and therefore recognize this request for the Default zone.

在具有多個網域的環境中,輸入網站所在以外的網域 DNS 的 CNAME 記錄。例如,如果 Fabrikam 網路環境包含第二個網域 europe.fabrikam.com,則會輸入歐洲網域之網站的 CNAME 記錄。針對小組網站的內部網路網站 (http://teams),會將名為 teams 的 CNAME 記錄新增至 europe.fabrikam.com 網域,以指向 teams.fabrikam.com。然後,當用戶端電腦的 DNS 尾碼附加至 DNS 查閱要求時,來自歐洲網域的 http://teams 要求會發出 teams.europe.fabrikam.com 的 DNS 查閱,再由 CNAME 記錄導向至 teams.fabrikam.com。In environments that have multiple domains, enter CNAME records for DNS in the domains that the sites do not reside in. For example, if the Fabrikam network environment includes a second domain named europe.fabrikam.com, CNAME records are entered for these sites in the Europe domain. For the Team Sites intranet site (http://teams), a CNAME record named teams is added to the europe.fabrikam.com domain that points to teams.fabrikam.com. Then, when a client computer's DNS suffix is appended to DNS lookup requests, a request for http://teams from the Europe domain will issue a DNS lookup of teams.europe.fabrikam.com, and will be directed by the CNAME record to teams.fabrikam.com.

注意

某些使用 Kerberos 驗證的用戶端及解析 CNAME 記錄有已知問題。如需詳細資訊,請參閱<Kerberos configuration known issues (SharePoint Server 2010)>。There is a known issue with some clients that use Kerberos authentication and resolving CNAME records. For more information, see Kerberos configuration known issues (SharePoint Server 2010).

區域原則Zone policies

您可以設定一或多個區域的原則,以對 Web 應用程式中的所有內容強制執行權限。在宣告模式中,只能針對特定區域定義原則 (而不是針對一般的 Web 應用程式)。原則可強制執行使用者透過區域存取所有內容的權限。原則權限會覆寫針對網站和內容設定的其他所有安全性設定。您可以根據使用者或使用者群組來設定原則,但不能根據 SharePoint 群組設定原則。如果新增或變更區域原則,搜尋必須重新編目網站,才能套用新的權限。You can configure policies for one or more zones to enforce permissions for all content within a web application. In claims mode, a policy can be defined only for a specific zone (not for the web application in general). A policy enforces permissions on all content that users access through a zone. Policy permissions override all other security settings that are configured for sites and content. You can configure policy based on users or user groups, but not SharePoint groups. If you add or change a zone policy, search must crawl sites again to apply the new permissions.

由於單一區域上已啟用多種驗證類型,以及 (或) 所有網站包含在一個 Web 應用程式中,因此設計範例不會使用原則。The design samples do not use policies because either multiple types of authentication are enabled on a single zone or all sites are contained within on web application (or both).