Amostras de design no SharePoint Server: sites extranet e portal corporativo

Artigo
03/08/2023

APLICA-SE A: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint no Microsoft 365

Este artigo discute várias amostras de design que podem ser usadas como arquiteturas iniciais para sites do SharePoint. As amostras de design descritas neste artigo ilustram arquiteturas padrões para os tipos mais comuns de sites do SharePoint implantados em uma empresa ou organização.

Importante

As informações neste artigo se aplicam ao SharePoint Foundation 2013 e ao SharePoint Server. No entanto, o artigo discute determinados recursos, como Meus Sites e pesquisas corporativas, que não estão disponíveis no SharePoint Foundation 2013.

Sobre as amostras de design

As seguintes amostras de design são descritas neste artigo:

A amostra de design ilustra sites de uma empresa fictícia chamada Fabrikam, Inc. As amostras de design aplicam-se a quase todos os componentes de arquitetura lógica e ilustra como são incorporados no design geral. Este artigo descreve as metas de design para as amostras e explica como os componentes da arquitetura lógica ilustrados nas amostras atingem estes objetivos.

Observação

Os modelos possuem SharePoint 2013 no título, mas ainda se aplicam ao SharePoint Server 2016

Modelo de design do Portal corporativo: duas versões

Coleções de sites nomeadas pelo host no SharePoint Server fornecem gerenciamento de URL e escalabilidade de sites em um único aplicativo Web. As duas versões do modelo de design do Portal empresarial mostra implementações baseadas no uso de conjuntos de sites baseados em caminho tradicional ou conjuntos de site nomeados por host. Ambas as amostras de design utilizam autenticação baseada em declarações com uma única zona. Estas amostras são discutidas em mais detalhes posteriormente neste artigo.

Recomendamos o uso do design baseado em conjuntos de sites denominados de host, a menos que os requisitos indiquem a necessidade de usar os sites baseados em caminho com mapeamento alternativo de acesso, (consulte Host-named site collection architecture and deployment (SharePoint 2013), para obter mais informações). Esse design é recomendado porque é a mesma arquitetura que o ambiente do Microsoft 365 usa. Consequentemente, essa é a configuração mais fortemente testada. Os novos recursos, como o Modelo de Aplicativo e o Gerenciamento de Solicitações, são otimizados para essa configuração, e ela é a configuração mais confiável.

Extranet com zonas dedicadas à autenticação

A Extranet com amostras de design de zonas exclusiva para autenticação inclui apenas o site da Web parceiro. Oferece uma configuração alternativa para a colaboração de parceiros na qual as zonas exclusivas são usadas para cada método de autenticação. Cada modelo de design usa a autenticação do modo de declarações para aplicativos da Web. A diferença entre os modelos de design do Portal empresarial e o modelo de design Extranet é como as zonas são configuradas. A amostra de design Extranet com zonas exclusivas para autenticação usam várias zonas e um método de autenticação é configurada para cada zona. O modelo de design do Portal empresarial usa uma zona e vários métodos de autenticação são configurados para diferentes classes de usuários.

O exemplo de design Extranet with Dedicated Zones for Authentication também apresenta uma nova recomendação para acesso remoto de funcionários – Acesso Direto com Windows Server 2012. Uma alternativa para essa recomendação é criar uma rede privada virtual (VPN). Também é possível usar a autenticação baseada em formulários no firewall ou produto gateway para coletar e encaminhar credenciais, se desejado.

Como os conjuntos de sites são implementados nas amostras de design

Embora as versões anteriores da amostra de design do Portal Empresarial usassem conjuntos de sites baseados em caminho, os conjuntos de sites denominados de host são recomendados, a menos que os requisitos indiquem que os sites baseados em caminho tradicionais com mapeamento alternativo de acesso (AAM) são necessários. Isso é refletido nas amostras de design das seguintes maneiras:

Portal empresarial com conjuntos de sites baseados em caminho — Esta amostra ilustra os conjuntos de site baseado em caminho da forma tradicional com os sites organizados em aplicativos da Web exclusivos e um conjunto de site de nível superior único por aplicativo da Web. Use esta abordagem se você deseja oferecer mais segurança para vários aplicativos da Web com pools de aplicativos separados.
Portal empresarial com conjuntos de sites nomeados por host — Esta amostra ilustra o uso de conjuntos de sites nomeados por host com todos os sites implantados em um único aplicativo da Web no farm. Este método é altamente escalonável e oferece mais flexibilidade no gerenciamento de URLs.
Extranet com autenticação para zonas exclusivas — Esta amostra ilustra vários sites de projeto de nível superior com uma variedade de URLs usando sites nomeados por host para cada site de projeto (ao invés de organizar sites de projeto abaixo de um conjunto de site de nível superior). Uma vantagem de usar os conjuntos de site nomeados por host é a forma de criar isolamento adicional entre URLs de domínio, que pode ser desejado em uma solução de colaboração parceiro. No entanto, a troca desta abordagem é o custo adicional de gerenciar um número maior de nomes de hosts, incluindo o gerenciamento de certificados SSL. Além disso, se a autenticação SAML for usada, a configuração adicional será necessária (consulte "Usando a autenticação SAML com sites nomeados pelo host" mais adiante neste artigo).

Autenticação baseada em declarações do SharePoint Server

A forma como a autenticação funciona para o SharePoint Server pode influenciar decisões de design relacionadas à implementação de opções representadas por esses exemplos de design. Aqui estão alguns exemplos:

No SharePoint Server, a autenticação baseada em declarações é o modo padrão e a única opção disponível por meio da Administração Central. A autenticação de modo clássico pode ser implementada usando o PowerShell.
No SharePoint Server, você não precisa configurar a afinidade do servidor no balanceador de carga para usar a autenticação de declarações SAML. O SharePoint Server dá suporte total ao balanceamento de carga sem afinidade.

No SharePoint Server, a conta de rastreamento de pesquisa requer acesso ao conteúdo por meio da zona Padrão usando autenticação do Windows NTLM (NTLM ou Kerberos). Como a autenticação de declarações permite vários tipos de autenticação em uma zona, este requisito não deve afetar outros requisitos de autenticação.

Resumo dos recursos do modelo de design

A tabela a seguir resume as três amostras de design discutidas neste artigo.

Tabela: Resumo das amostras de design

Amostra de design	Inclui	Principais elementos de design
Portal empresarial com sites baseados em caminho	Tipos mais comuns de sites implantados em uma organização.	Conjuntos de sites baseados em caminho Autenticação baseada em declarações Vários provedores de autenticação e tipos de autenticação implementados em uma única zona
Portal empresarial com sites nomeados por host	Tipos mais comuns de sites implantados em uma organização.	Conjuntos de site nomeados por host Autenticação baseada em declarações Vários provedores de autenticação e tipos de autenticação implementados em uma única zona
Extranet com zonas dedicadas à autenticação	Apenas o site da Web parceiro. Oferece uma configuração alternativa para colaboração do parceiro.	Conjuntos de site nomeados por host Autenticação baseada em declarações Diferente zona para cada método de autenticação

Sites incluídos nas amostras de design

Esta seção descreve os sites de nível superior incluídos nas amostras de design.

Sites Intranet

O portal empresarial inclui os seguintes sites para uso na intranet:

Conteúdo intranet publicado (como HRweb)
Sites de equipe colaborativa
Meus Sites

Juntos, eles são os sites de colaboração e conteúdo que os funcionários usam diariamente. Individualmente, cada um destes aplicativos representam um tipo diferente de conteúdo. Cada tipo de conteúdo possui as seguintes propriedades:

Enfatiza os diferentes recursos do SharePoint Server.
Hospeda dados com diferentes características de dados.
Está sujeito a um perfil de uso diferente.
Exige uma estratégia de gerenciamento de permissões diferentes.

Consequentemente, as escolhas de design para cada um destes aplicativos são destinadas para melhorar o desempenho e a segurança de cada aplicativo.

O design dos aplicativos de serviço oferecem estes três aplicativos juntos para fornecer os seguintes recursos:

Pesquisa em toda a empresa
Dados de perfil compartilhados e metadados empresariais

A ilustração a seguir, na amostra de design do Portal Empresarial com conjuntos de site baseado em caminho, mostra os três tipos de sites que criam a intranet empresarial.

Tipos de sites que criam a intranet empresarial

Sites Intranet

Aplicativo da Web parceiro

O aplicativo da Web parceiro hospeda sites disponíveis externamente para colaboração segura com empresas parceiras e parceiros individuais. Este aplicativo é destinado para os funcionários criarem facilmente sites de colaboração segura. Os parceiros não podem acessar outros tipos de conteúdo que o farm do servidor hospeda. O design para zonas e aplicativos de serviço abordam esta meta. Além disso, os propriedades de site individual gerenciam permissões para seu site e convidam apenas os participantes necessários a colaborar.

Na amostra de design de extranet, este é o único tipo de site representado.

Metas gerais de design

Os exemplos de design fornecem implementações práticas de recursos do SharePoint Server em vários tipos comuns de sites. As implementações de design para cada aplicativo individual são discutiras neste artigo. A seguir estão as principais metas de design para as amostras de design:

Criar uma estrutura para projetar um ambiente que pode crescer.

As decisões de design para tipos de sites individuais não evita a adição de outros tipos de sites. Por exemplo, uma implementação inicial pode incluir apenas sites de equipe colaborativas ou apenas os três tipos de sites que compõe uma intranet (sites de equipe, My Sites e conteúdo intranet publicado). Se você usar um design de arquitetura lógica semelhante, é possível adicionar sites na solução sem afetar o design da solução inicial. Em outras palavras, o design não incorpora escolhas de design que limitam o uso do ambiente.
Oferece acesso a vários grupos de usuário sem comprometer a segurança do conteúdo dentro de diferentes tipos de sites.

Os usuários de diferentes zonas de rede (interna e externa) que usam diferentes provedores de autenticação podem participar da colaboração. Além disso, os usuários podem acessar apenas o conteúdo que pretendem. Se você seguir um design de arquitetura lógica semelhante, é possível oferecer acesso ao usuário que está em vários locais e possui diferentes objetivos. Por exemplo, seu design inicial pode ser destinado apenas para acesso do funcionário interno. No entanto, se você usar um design semelhante, também pode permitir o acesso de funcionários remotos, funcionários parceiros, empresas parceiras e clientes.
Certifique-se de que o design pode ser usado em um ambiente extranet.

Faça escolhas de design deliberadas para garantir que a solução pode implantar com segurança em uma rede de perímetro.

O resto deste artigo discute cada componente lógico que aparece na amostra de design (do topo para baixo) e discute as escolhas de design aplicadas à amostra de design. O objetivo desta abordagem é demonstrar as diferentes formas nas quais os componentes de arquitetura lógica podem ser configurados com base no aplicativo.

Farms do servidor

Esta seção descreve as topologias dos farms de servidores ilustrados na amostra de design e discute o escalonamento além de um único farm.

Topologia dos farms de servidores

Cada farm de servidor na amostra de design é composto de seis servidores com a seguinte topologia tolerante à falhas:

Dois servidores da Web de front-end
Dois servidores de aplicativo
Dois servidores de banco de dados com SQL Server instalados e configurados para dar suporte a SQL Server clustering, espelhamento ou Always On. Always On requer SQL Server 2012.

O conceito de servidor de front-end e de aplicativo é diferente no SharePoint Server 2016, confira Visão geral das funções do Servidor MinRole no SharePoint Server

A amostra de design ilustra a arquitetura lógica do SharePoint Server mostrando o seguinte:

Todos os sites são espelhados em servidores da Web de front-end.
O site do Administração Central está instalado no servidor de aplicativos para protegê-lo do acesso de usuário direto.

Na realidade, o número de computadores do servidor e a topologia do farm de servidores são importantes para a arquitetura lógica apenas para aumentar a capacidade e melhorar o desempenho. É possível projetar a arquitetura lógica de modo independente da topologia do farm de servidores. O processo de planejamento do desempenho e da capacidade ajuda você a dimensionar o farm de servidores para cumprir as metas de desempenho e de capacidade. Para obter mais informações, confira Planejamento de desempenho no SharePoint Server 2013.

Usuários, zonas e autenticação

As declarações são o modo padrão de autenticação no SharePoint Server e cada exemplo de design incorpora a autenticação baseada em declarações. Você pode usar Windows PowerShell para implementar a autenticação de modo clássico; no entanto, alguns recursos do SharePoint Server não estão disponíveis no modo clássico. Para obter mais informações sobre exemplos de design que incorporam autenticação de modo clássico, confira Exemplo de design: implantação corporativa (SharePoint Server 2010)

A tabela a seguir lista as diferenças nas duas abordagens representadas pela amostra de Design do Portal empresarial e a amostra de Design Extranet.

Tabela: Contrastar abordagens para configurações de zona nas amostras de design

Abordagem	Portal empresarial com sites nomeados por host e Portal empresarial com sites baseados em caminho	Extranet com zonas dedicadas à autenticação
Modo de autenticação	Declarações	Declarações
Configuração de zona	Uma zona com vários métodos de autenticação configurados para diferentes classes de usuários.	Várias zonas com um método de autenticação configurado para cada zona.
URLs	Todas as classes de usuários utilizam a mesma URL para cada site. Os funcionários usam a mesma URL independente se estão dentro da rede empresarial ou trabalhando remotamente.	Cada classe de usuário utiliza uma URL diferente para acessar um site. Funcionários usam uma URL diferente dependendo se estão dentro da rede empresarial ou trabalhando remotamente.
Solicitações internas	Solicitações que iniciam dentro da rede empresarial são roteadas da rede e retornadas através do gateway ou servidor de proxy. Estas solicitações são protegidas usando o protocolo SSL. Em alternativa, o DNS dividido pode ser usado para rotear solicitações diretamente para a interface interna dos servidores.	Solicitações iniciadas dentro da rede empresarial permanecem internas na rede.
Experiência do usuário	Todos os usuários são solicitados a escolher o tipo de conta que estão usando para fazer o logon.	O método de autenticação é pré-determinado. Os usuários não são obrigados a selecionar o tipo de conta utilizando uma página de login.

As seções a seguir discutem especificamente como a autenticação é incorporada usando as duas abordagens diferentes.

Amostra de design de Extranet com zonas exclusivas

A amostra de design extranet ilustra três classes diferentes de usuários e cada uma é atribuída a uma zona diferente. Dentro de cada aplicativo da Web, é possível criar até cinco zonas utilizando um dos nomes de zona disponíveis: Padrão, Intranet, Internet, Personalizado ou Extranet. A conta de rastreamento de pesquisa exige acesso à zona Padrão usando a autenticação Integrada do Windows (NTLM ou protocolo Kerberos), que é responsável pela amostra de design. A tabela a seguir mostra como as zonas são configuradas na amostra de design extranet.

Tabela: zonas, usuários e tipo de autenticação prescritos pela amostra de design extranet

Zona	Usuários	Autenticação
Intranet	Funcionários internos e remotos Conta de rastreamento de pesquisa	Protocolo NTLM ou Kerberos Funcionários remotos que usam o Acesso Direto ou VPN para se conectar.
Padrão	Parceiros individuais	Opções: Diretório LDAP usando a autenticação baseada em formulários Floresta dos Serviços de Domínio do Active Directory (AD DS) externo com uma confiança de uma via para a floresta interna e autenticação integrada do Windows Provedor de identidade confiável com autenticação SAML
Extranet	Empresas parceiros	Provedor de identidade de parceiro confiável com autenticação SAML

Amostras de design do Portal empresarial

Autenticação baseada em declarações permite vários tipos de autenticação na mesma zona. As duas versões do modelo de design do Portal empresarial usam a zona Padrão para todos os tipos de autenticação.

A tabela a seguir mostra as zonas, usuários e tipos de autenticação prescritos pelas amostras de design.

Tabela: Zonas, usuários e autenticação para as amostras de design do portal empresarial

Zona	Usuários	Provedor e tipo de autenticação
Padrão	Funcionários internos e remotos	Serviços de Domínio do Active Directory (AD DS) ou repositório LDAP com autenticação baseada em formulários ou autenticação SAML.
Padrão	Parceiros individuais	Provedor de identidade confiável com autenticação SAML ou banco de dados do SQL Server com autenticação baseada em formulários
Padrão	Empresas parceiros	Provedor de identidade de parceiro confiável com autenticação SAML
Padrão	Conta de rastreamento de pesquisa	AD DS com autenticação Windows NTLM

Na amostra de design, o site de Conteúdo Intranet Publicado, Team Sites e My Sites são acessíveis apenas por funcionários, se eles estiverem dentro ou fora da rede. A amostra de design implementa apenas uma URL (usando SSL) para cada um destes sites podem ser usados interna e externamente. As contas AD DS são usadas. Se necessário, a autenticação baseada em formulários ou SAML pode usar LDAP, que exige configuração adicional.

Na amostra de design, o aplicativo da Web parceiro representa um site extranet que os funcionários parceiros e empresas parceiras podem acessar. A autenticação baseada em declarações neste cenário exige a configuração de confiança com um ou mais provedores de identidade externo. É possível usar uma das seguintes abordagens:

É possível configurar o farm do SharePoint para confiar um provedor de identidade externo, como o provedor que reside em uma empresa parceira (para autenticar diretamente no diretório parceiro).
É possível configurar o provedor de identidade dentro do ambiente empresarial para confiar um provedor de identidade externo. Os administradores nas duas organizações devem estabelecer esta relação explicitamente. Neste cenário, o farm do SharePoint confia no provedor de identidade dentro de seu próprio ambiente empresarial. Quando o provedor de identidade enviar um token, o farm usa o certificado de login do token especificado quando a confiança foi estabelecida para confirmar a validade do token. Recomendamos esta abordagem.

A autenticação baseada em formulários é uma alternativa ao ambiente baseado em declarações para autenticar parceiros. Você usa um repositório separado, como um banco de dados, para gerenciar estas contas.

Zonas

Ao projetar zonas, várias decisões fundamentais são críticas para o sucesso da implantação. Essas decisões incluem decisões de criação e configuração das seguintes zonas:

A zona Padrão
Zonas para acesso externo

As seguintes seções descrevem as decisões incorporadas na amostra de design.

Requisitos de configuração da zona padrão

A zona que envolve a maior consideração é a zona Padrão. O SharePoint Server coloca os seguintes requisitos sobre como você configura a zona Padrão:

Quando uma solicitação do usuário não pode ser associada com uma zona, a autenticação e as políticas da zona Padrão são aplicadas. Consequentemente, a zona Padrão deve ser a zona mais segura.
As mensagens de email administrativos incluem links da zona Padrão. Eles incluem mensagens para proprietários de sites abordando limites de cota. Consequentemente, usuários que recebem estes tipos de mensagens e alertas devem poder acessar links através da zona Padrão. Isto é especialmente importante para proprietários de site.

No SharePoint Server, os conjuntos de site nomeados por host podem ser acessados de qualquer zona.

Configurar zonas de um ambiente extranet

Em um ambiente extranet, o design das zonas é fundamental pelos seguintes motivos:

Várias redes diferentes podem iniciar solicitações do usuário. Nas amostras de design, os usuários iniciam solicitações da rede interna, a Internet e empresas parceiras.
Os usuários consomem conteúdo em vários aplicativos da Web. Na amostra de design, a intranet é composta de três aplicativos da Web. Além disso, funcionários internos e remotos podem contribuir potencialmente e administrar o conteúdo no aplicativo da Web parceiro.

Se um ambiente extranet inclui mais de uma zona, certifique-se de seguir estes princípios de design:

Configurar zonas entre vários aplicativos da Web para espelhar um ao outro. A configuração da autenticação e os usuários destinados devem ser os mesmos. No entanto, as políticas associadas com as zonas podem diferir entre aplicativos da Web. Por exemplo, certifique-se de usar a zona Intranet para o mesmo funcionário em todos os aplicativos da Web. Em outras palavras, não configure a zona Intranet para funcionários internos em um aplicativo da Web e funcionários remotos em outro.
Se você usar conjuntos de sites baseados em caminho, configure mapeamentos de acesso alternativo apropriadamente e com precisão para cada zona e cada recurso. Os mapeamentos de acesso alternativo são criados automaticamente ao criar uma zona. No entanto, você pode configurar o SharePoint Server para rastrear conteúdo em recursos externos, como um compartilhamento de arquivos. Você deve criar links para estes recursos externos manualmente para cada zona utilizando mapeamentos de acesso alternativo.
Se você usar conjuntos de sites nomeados por host, certifique-se de usar o PowerShell para mapear URLs para zonas adequadas

Se zonas entre aplicativos da Web não espelham uns aos outros e links para recursos externos não são adequados, os seguintes riscos podem ocorrer:

Nomes de servidor, nomes DNS e endereços IP podem ser potencialmente expostos fora da rede externa.
Os usuários podem não ser possível acessar sites da Web e outros recursos.

Usando autenticação SAML com sites nomeados por host

Se um design inclui o uso da autenticação SAML com sites nomeados por host, cada URL exige o seguinte:

Um novo realm no SPTrustedIdentityTokenIssuer
Uma parte confiável correspondente no Provedor de Identidade.

Serviços

As arquiteturas de serviço variam dependendo da amostra de design. A amostra de design do Portal Empresarial com sites nomeados por host inclui a arquitetura mais simples para serviços. Isto ocorre porque usa um aplicativo da Web, que pode acomodar apenas um grupo de aplicativos de serviço (também conhecido como grupo de proxy).

O exemplo do Portal empresarial com sites baseados em caminho usa serviços particionados para sites parceiros para isolar dados entre projetos. Esta amostra de design incorpora dois grupos de serviço, um para sites intranet e um para sites de colaboração parceiros. Instâncias separadas dos Metadados Gerenciados e Pesquisa são implantadas para sites Parceiros e estes serviços são particionados. Os serviços particionados exigem o Serviço de Configurações de Assinatura que só pode ser implantado usando o PowerShell.

Arquitetura de serviço para o Portal empresarial com sites baseados em caminho

Arquitetura de serviços

A implantação de serviços particionados adiciona complexidade à arquitetura e dificulta a migração de sites para o Microsoft 365 posteriormente. Uma opção mais simples para sites Parceiros é implantar instâncias exclusivas, mas não particionadas, do serviço de Metadados Gerenciados e Pesquisa se precisarem ser separados. Várias organizações confiam no recurso de análise de segurança da Pesquisa, ao invés da implantação de instâncias exclusivas do serviço de pesquisa.

A amostra de design Extranet inclui apenas um grupo de proxy, mas também usa serviços particionados para os aplicativos de serviço de Metadados Gerenciados e Pesquisa.

A decisão principal de design para implantar aplicativos de serviço é agora amplamente para divulgar a taxonomia da organização. Para simplificar os serviços de arquitetura, compartilhar Metadados Gerenciados, Perfil do Usuário e Pesquisa em todos os aplicativos da Web e confiar na análise de segurança para gerenciar acesso ao conteúdo. Na amostra de design do Portal empresarial com sites baseados em caminho, uma instância do serviço de Metadados gerenciados é compartilhado em todos os sites. No entanto, todos os usuários podem acessar a taxonomia empresarial com essa configuração. Os arquitetos de solução devem decidir implementar várias instâncias do serviço de Metadados gerenciados. Eles também precisarão decidir de forma ampla o compartilhamento dos dados do Perfil de Usuário.

Dentro da amostra do Portal empresarial com conjuntos de site baseados em caminho, a Web do parceiro é configurada para usar os aplicativos de serviço de Metadados gerenciadas e Pesquisa exclusivo utilizando um grupo de serviço personalizado. Outros aplicativos de serviço são adicionados para o grupo personalizado e são compartilhados com o grupo padrão. A amostra de design não inclui o aplicativo de serviço Perfil de Usuário para evitar que usuários parceiros naveguem pelos dados das pessoas na organização.

Na arquitetura simplificada do Portal empresarial com conjuntos de site nomeados por host (um grupo de serviço), os parceiros podem acessar toda a taxonomia empresarial e navegar pelos dados das pessoas na organização. No entanto, a pesquisa limita os resultados dos sites e conteúdo que os parceiros podem acessar.

Se seus sites parceiros exigem isolamento de conteúdo entre projetos, implantar aplicativos de serviço exclusivos é uma boa escolha, como ilustrado neste artigo. Isto aumenta a complexidade da arquitetura de serviços, mas garante que os parceiros não podem acessar metadados associados com o conteúdo Intranet ou mesmo outros projetos dentro do site da Web parceiro. A amostra de design Extranet também usa serviços particionados.

Sites de administração

No exemplo de design, um servidor de aplicativo hospeda o site da Administração Central do SharePoint para cada farm de servidores. Isto protege o site do contato direto do usuário. Se um gargalo de desempenho ou um compromisso de segurança afetar a disponibilidade dos servidores Web front-end, o site da Administração Central do SharePoint permanecerá disponível.

A amostra de design e este artigo não mencionam as URLs de balanceamento de carga para sites de administração. As recomendações incluem o seguinte:

Se as URLs administrativas usam números de porta, usam portas não padrões. As URLs incluem números de porta por padrão. Enquanto as URLs do cliente não incluem números de porta, usar números de porta para sites de administração podem aumentar a segurança limitando o acesso a estes sites para portas não padrões.
Criar entradas DNS separadas para sites de administração.

Além destas recomendações, é possível opcionalmente balancear a carga do site da Administração Central do SharePoint entre vários servidores de aplicativo para atingir redundância.

Pools de aplicativos

Pools de aplicativos IIS separados são geralmente implementados para atingir um isolamento do processo entre o conteúdo. Os pools de aplicativos oferecem uma forma de vários sites executarem no mesmo computador do servidor, mas ainda possuem seus próprios processos do trabalhador e identidade. Isto ajuda a evitar que um atacante que injeta o código em um site afete outros servidores ou sites em outros sites.

Se um único pool de aplicativos e aplicativo da Web é usado em conjunto com conjuntos de sites nomeados por host, o isolamento é oferecido entre URLs de domínio, mas apenas a nível de script.

Se você escolher implementar mais de um pool de aplicativos, considere um pool de aplicativos exclusivo para cada um dos seguintes cenários:

Para separar o conteúdo autenticado do conteúdo anônimo. Se o mesmo farm hospeda o site Internet da empresa, coloque este site em um aplicativo da Web excluído e pool de aplicativos.
Para isolar sites que armazenam senhas e interagem com sistemas de dados de backend (embora o Serviço de Repositório Seguro possa ser usado para este fim).

A amostra de design do Portal empresarial com sites nomeados por host e a amostra de design de Extranet com zonas exclusivas para autenticação implementam um único pool de aplicativos para todo o conteúdo. Pools de aplicativos separados são necessários para aplicativos de serviço e para o site da Administração Central do SharePoint.

A amostra de design do Portal empresarial com sites baseados em caminho implementa o isolamento de processo entre o conteúdo usando pools de aplicativos separados das seguintes formas:

O site de administração é hospedado em um pool de aplicativos diferente. Esse é um requisito do SharePoint Server.
Todos os aplicativos de serviço são implantados em um único pool de aplicativos. A não ser que haja um motivo para implantar os aplicativos de serviço em pools de aplicativo diferentes, é a configuração recomendada. Um pool de aplicativos para todos os aplicativos de serviço otimiza o desempenho e reduz o número de pools de aplicativos para gerenciar.
O conteúdo Intranet é dividido em dois pools de aplicativos diferentes. Um pool de aplicativos hospeda o conteúdo de colaboração (My Sites e sites de equipe). Um pool de aplicativo separado hospeda o conteúdo intranet publicado. Esta configuração oferece isolação para o conteúdo da intranet publicado no qual as conexões de dados comerciais provavelmente serão usadas.
Um pool de aplicativo exclusivo hospeda o aplicativo da Web parceiro.

Aplicativos web

Um aplicativo Web é um site do IIS que o SharePoint Server cria e usa. Cada aplicativo da Web é representado por um site da Web diferente no IIS.

Se você escolher implementar mais de um aplicativo da Web, considere os seguintes casso:

Separar conteúdo anônimo do conteúdo autenticado.

Se o mesmo farm hospeda o site Internet da empresa, coloque este site em um aplicativo da Web exclusivo e pool de aplicativos.
Isolar usuários

Na amostra de design, um aplicativo da Web exclusivo e pool de aplicativos hospeda o site da Web parceiro para garantir que os parceiros não tenham acesso ao conteúdo intranet.
Forçar permissões

Um aplicativo da Web exclusivo oferece a oportunidade de implementar políticas em zonas dentro do aplicativo da Web para forçar permissões. Por exemplo, é possível criar políticas para o site Internet da empresa para negar explicitamente acesso de gravação em um ou mais grupos de usuários. As políticas são usadas independente das permissões configuradas em sites individuais ou documentos no aplicativo da Web.
Otimizar desempenho

Aplicativos têm melhor desempenho se colocá-los em aplicativos da Web com outros aplicativos de características de dados semelhantes. Por exemplo, as características de dados do My Sites incluem um grande número de sites pequenos em tamanho. Em contraste, os sites da equipe geralmente possuem um número menor de grandes sites. Colocando estes dois tipos diferentes de sites em aplicativos da Web separados, os bancos de dados resultados são compostos de dados com características semelhantes, o que otimiza o desempenho do banco de dados. Na amostra de design, o My Sites e os sites de equipe possuem requisitos de isolamento de dados exclusivos—eles compartilham o mesmo pool de aplicativos. Independente, o My Sites e sites da equipe são colocados em aplicativos da Web separados para otimizar o desempenho.
Otimizar a administração

Como a criação de aplicativos da web separados resulta em sites e bancos de dados separados, é possível implementar limites de site diferentes (lixeira, expiração e tamanho) e negociar acordos de nível de serviço diferentes. Por exemplo, você pode permitir mais tempo para restaurar o conteúdo do My Site se não é o tipo mais crítico de conteúdo na sua organização. Isto permite restaurar mais conteúdo crítico antes de restaurar o conteúdo do My Site. Na amostra de design, o My Sites estão no aplicativo da Web separado para permitir aos administradores a gerenciarem agressivamente o crescimento em comparação com outros aplicativos.

Se você implementar conjuntos de sites nomeados por host com um único aplicativo da Web, cada site de nível superior é um domínio separado que permite atingir algumas destas metas, como otimizar a administração implementando diferentes limites de site.

Conjuntos de site

A configuração recomendada para implantar sites é usar conjuntos de sites nomeados por host com todos os sites localizados dentro de um único aplicativo web. Essa configuração é recomendada para implantar sites porque é a mesma arquitetura que o ambiente do Microsoft 365 usa. Como consequência, é a configuração mais amplamente testada. Novos recursos, incluindo o modelo de aplicativo e o Gerenciamento de Solicitação, são otimizados para essa configuração e é a configuração mais confiável para o futuro.

Apesar de recomendarmos os conjuntos de sites nomeados por host para a maioria das arquiteturas, você deve usar os conjuntos de sites baseados no caminho tradicionais e o mapeamento de acesso alternativo se alguma das condições a seguir se aplicar:

Você precisa usar o recurso Criação de Sites de Autoatendimento, que faz parte da instalação padrão do SharePoint Server 2016.

Isto não se aplica às soluções de criações de site self-service personalizado.
Um aplicativo da Web exige inclusões curinga exclusivas ou inclusões explícitas.

Você cria inclusões para conjuntos de sites nomeados por host e estão disponíveis para todos os sites nomeados por host. Todos os conjuntos de sites nomeados por host em um farm compartilham as mesmas inclusões, mas não precisarão usá-los. Em contraste, as inclusões criadas para conjuntos de sites baseados em caminho aplicam-se apenas a um único aplicativo web.
A terminação SSL é necessária, mas seu dispositivo de terminação SSL não pode ser configurado para produzir o cabeçalho HTTP personalizado necessário.

Ainda é possível usar a ponte SSL com conjuntos de sites nomeados por host com estes dispositivos se as terminações SSL não são um .
Você planeja usar pools de aplicativos diferentes pela segurança adicional oferecida ou precisa usar vários grupos de proxy.

Para saber mais sobre coleções de sites com nome de host, incluindo a comparação com coleções de sites baseados em caminho, confira Arquitetura e implantação de conjunto de sites nomeados por host (SharePoint 2013).

Metas de design para conjuntos de sites

Conjuntos de sites ligam arquitetura lógica e arquitetura de informação. As metas de design para conjuntos de sites são os requisitos de preenchimento para design de URL e para criar divisões lógicas do conteúdo. Para cada conjunto de sites, os caminhos gerenciados incorporam uma segunda camada dos conjuntos de site de nível superior. Para obter mias informações sobre requisitos de URL e usando caminhos gerenciados, consulte Zonas e URLs posteriormente neste artigo. Por trás da segunda camada do conjunto de sites, cada site é um subsite.

O seguinte diagrama ilustra a hierarquia de sites do Team Sites.

Hierarquia de sites para sites de equipe

Sites de equipe

Para conjuntos de sites baseados em caminho e conjuntos nomeados por host, a arquitetura de informação fala sobre a segunda camada dos conjuntos de sites. A seguinte seção descreve como as amostra de design incorporam escolhas com base na natureza dos sites.

Conteúdo de intranet publicado

A ideia para o aplicativo da Web de conteúdo intranet publicado é que várias divisões na empresa não hospedarão conteúdo publicado. Na amostra de design, um conjunto de site separado hospeda cada conteúdo da divisão. Isto oferece as seguintes vantagens:

Cada divisão pode gerenciar o conteúdo e administrar as permissões independentemente.
Cada divisão pode armazenar seu conteúdo em um banco de dados exclusivo.

As desvantagens de vários conjuntos de sites incluem as seguintes:

Não é possível compartilhar páginas mestres, layouts de página, Web Parts e navegação entre os conjuntos de sites.
Coordenação das personalizações e navegação entre conjuntos de sites exige mais esforço.

Dependendo da arquitetura de informação e design dos sites intranet, o conteúdo publicado pode aparecer para o usuário como uma experiência contínua. Em alternativa, cada conjunto de site pode parecer ser um site da Web separado.

Meus Sites

My Sites possuem características distintas e recomendações de implantação para My Sites são avançadas. Nos exemplos de design, a coleção de sites Meus Sites incorpora um site de nível superior com a URL de http://my. O primeiro conjunto de site de nível superior criado usa o modelo de host My Site. Um caminho gerenciado é incorporado (usando a inclusão curinga), que permite um número indefinido de sites criados pelo usuário. Todos os sites baixo do caminho gerenciado são conjuntos de sites independentes que usam o modelo de Site Pessoal. O nome de usuário é acrescentado à URL no formulário http://my pessoal/ nome de usuário. A ilustração a seguir mostra My Sites.

Hierarquia do site para Meus Sites

Meus Sites

Sites de equipe

É possível usar as seguintes duas abordagens para projetar conjuntos de site em um aplicativo do Team Site:

Permite as equipes criarem conjuntos de site através da criação de site self-service. A vantagem desta abordagem é que as equipes podem criar um site, conforme necessário, sem ajuda de um administrador. As desvantagens desta abordagem incluem o seguinte:
- Você perde a oportunidade para implementar uma taxonomia detalhada.
- Não é possível compartilhar modelos e navegação entre projetos ou equipes que podem compartilhar um conjunto de site.
Cria um número finito de conjuntos de sites para sua organização com base na forma que sua organização opera. Nessa abordagem, um administrador do SharePoint cria coleções de sites. Após um conjunto de site ser criado, as equipes podem criar sites dentro do conjunto de sites. Esta abordagem oferece a oportunidade de implementar uma taxonomia detalhada para a forma que os team sites são gerenciados e crescem. Há mais oportunidade de compartilhar modelos e navegação entre projetos e equipes que compartilham um conjunto de sites. No entanto, esta abordagem também inclui algumas desvantagens.

As amostras de design incorporam a segunda abordagem, que resulta em uma hierarquia do conjunto de sites semelhante para team sites e conteúdo intranet publicado. O desafio para os arquitetos da informação é criar uma segunda camada do conjunto de sites que faz sentido para a organização. A tabela a seguir sugere os diferentes tipos de organizações.

Tabela: Taxonomias do conjunto de sites sugerido

Tipo de organização	Taxonomias do conjunto de site sugerido
Desenvolvimento do produto	Criar um conjunto de sites para cada produto em desenvolvimento. Permite a contribuição de equipes para criar sites dentro do conjunto de sites. Para cada projeto de desenvolvimento de longo prazo, criar um conjunto de sites pra cada grande equipe que contribui com o produto. Por exemplo, criar um conjunto de sites para cada uma das seguintes equipes: designers, engenheiros e desenvolvedores de conteúdo.
Pesquisa	Criar um conjunto de sites para cada projeto de pesquisa de longo prazo. Criar um conjunto de sites para cada categoria dos projetos de pesquisa.
Maior instituição de educação	Criar um conjunto de sites para cada departamento acadêmico
Declarar o escritório legislativo	Criar um conjunto de site para cada partido político. Oficiais do governo que compartilham afiliação política podem compartilhar modelos e navegação. Criar um conjunto de sites para cada comitê. Em alternativa, criar um conjunto de site para todos os comitês.
Diretor jurídico	Criar um conjunto de sites para cada cliente empresarial.
Fabricação	Criar um conjunto de sites para cada linha de produtos.