Arquitetura e implantação de conjunto de sites nomeados por host no SharePoint Server
APLICA-SE A:
2013 2016 2019 Subscription Edition 
SharePoint no Microsoft 365
As coleções de sites com nome de anfitrião são uma abordagem opcional para implementar sites no SharePoint Server. Os utilizadores que pretendam ter múltiplas coleções de sites, com cada coleção de sites com o seu próprio nome DNS, podem optar por implementar coleções de sites com nome de anfitrião. Caso contrário, os utilizadores devem implementar coleções de sites baseadas em caminhos.
Saiba como planejar e implantar conjuntos de sites nomeados por host, projetar URLs e gerenciar URLs.
Arquitetura e design para conjuntos de sites nomeados por host
Conjuntos de sites nomeados por host permitem designar um nome DNS único a conjuntos de sites. Por exemplo, você pode intitulá-los como http://TeamA.contoso.com e http://TeamB.contoso.com. Este exemplo mostra que vai implementar muitos sites com nomes DNS exclusivos na mesma aplicação Web. Também permite que os hosters dimensionem um ambiente para muitos clientes.
Este artigo descreve como implantar conjuntos de sites nomeados por host em uma configuração recomendada com o SharePoint Server. Informações sobre configurações avançadas estão incluídas no fim do artigo sobre o uso de vários aplicativos da Web com conjuntos de sites nomeados por host.
Arquitetura recomendada para conjuntos de sites nomeados por host
A configuração recomendada para implementar coleções de sites com nome de anfitrião é colocar todas as coleções de sites com nome de anfitrião numa única aplicação Web, conforme ilustrado no diagrama seguinte.
Configuração recomendada para conjuntos de sites nomeados por host
Essa configuração recomendada no diagrama inclui os seguintes elementos:
Um pool de aplicativos para conjuntos de sites.
Um aplicativo da Web para conjuntos de sites hospedados dentro de um pool de aplicativos.
Uma coleção de sites de raiz (
http://webapp.contoso.com).Vários conjuntos de sites nomeados por host para hospedar conteúdo com sites de exemplo:
Conteúdo da intranet publicado (
http://intranet.contoso.com) com subsites para RH, Instalações e Compras.Sites de equipa (
http://teams.contoso.com) com subsites para a Equipa 1, Equipa 2 e Equipa 3.Os Meus Sites com URLs do site no seguinte formato:
http://my.contoso.com/personal/<site_name>.
O número de sites na aplicação Web e os URLs dos sites não são importantes para este exemplo.
Ao criar uma aplicação Web para coleções de sites com nome de anfitrião, o URL da aplicação Web e a coleção de sites de raiz serão http://<_webapp.contoso.com_>/.
Esta arquitetura é recomendada para implementar coleções de sites com nome de anfitrião porque é a mesma arquitetura que o ambiente do Microsoft 365 utiliza. Portanto, esta configuração é a configuração mais testada. As novas funcionalidades, incluindo o Modelo de aplicação e a Gestão de Pedidos, estão otimizadas para esta configuração e é a configuração mais fiável a seguir.
A configuração recomendada não inclui os seguintes elementos:
Habilitar aplicativos em ambientes com múltiplas zonas.
Combinar conjuntos de sites nomeados por host e conjuntos de sites baseados em caminho (exceto a raiz do conjunto de sites).
Múltiplos aplicativos web com conjuntos de site nomeados por host.
Conjuntos de sites nomeado por host verso conjuntos de sites baseados por caminho
Quando você usa conjuntos de sites nomeados por host, cada conjunto de sites em um aplicativo da Web recebe um nome DNS único. Quando implementa muitas coleções de sites com nome de anfitrião numa única aplicação Web, aumenta a escalabilidade do farm porque os recursos não são utilizados para suportar vários conjuntos aplicacionais e aplicações Web.
O SharePoint Server tem suporte para conjuntos de sites baseados em caminho e nomeados por host. A tabela a seguir detalha as diferenças entre as duas opções e fornece mais informações sobre conjuntos de sites nomeados por host.
Tabela: Comparação de conjuntos de sites nomeados por host e conjuntos de sites baseados em caminho
| Conjuntos de site nomeados por host | Conjuntos de sites baseados em caminho | |
|---|---|---|
| Criando sites | Você pode usar o Microsoft PowerShell para criar conjuntos de sites nomeados por host. Não pode utilizar a Administração Central para criar coleções de sites com nome de anfitrião. | Você pode usar o Administração Central ou o PowerShell para criar conjuntos de sites baseados em caminho. |
| URLs | Cada conjunto de site nomeado por host em um aplicativo da Web recebe um nome DNS único. Você pode usar zonas para designar até cinco URLs para conjuntos de sites nomeados por host, incluindo URLs personalizadas. |
Todos os conjuntos de sites baseados em caminho em um aplicativo da Web compartilham o mesmo nome de host (nome DNS) que o aplicativo da Web. Você pode estender um aplicativo da Web para implantar até cinco zonas e criar diferentes nomes de host para cada zona. Porém, o nome de host para uma zona aplica-se a todos os conjuntos de sites dentro do aplicativo da Web. |
| Pesquisa e conjunto de sites raiz | Um conjunto de sites raiz é necessário para rastrear o conteúdo em um aplicativo da Web. Uma coleção de sites raiz pode ser uma coleção de sites à qual os utilizadores não podem aceder. | Normalmente, um único conjunto de sites baseado em caminho serve como o conjunto de sites raiz dentro de um aplicativo da Web. Pode utilizar caminhos geridos para criar mais coleções de sites na aplicação Web. |
| Mapeamento de URL | Utilize comandos do PowerShell para gerir URLs (Set-SPSiteUrl, Remove-SPSiteUrl, Get-SPSiteUrl). |
Use Mapeamentos de Acesso Alternativo para gerenciar URLs. |
| Criação de site de autoatendimento | Você precisa usar uma solução personalizada para a criação de um site de autoatendimento com conjuntos de sites nomeados por host. A funcionalidade Criação Personalizada de Sites que faz parte da instalação predefinida do SharePoint Server não funciona com coleções de sites com nome de anfitrião. |
Ao usar o recurso de Criação de Sites de Autoatendimento, que é parte da instalação padrão do SharePoint Server, você cria sites baseados em caminhos. |
| Caminhos gerenciados | Caminhos gerenciados para conjuntos de sites nomeados por host aplicam-se no nível do farm e estão disponíveis para todos os aplicativos da Web. Você precisa usar o PowerShell para criar caminhos gerenciado para conjuntos de sites nomeados por host. |
Caminhos gerenciados para sites baseados em caminho aplicam-se no nível do aplicativo da Web. Você pode usar o Administração Central ou o Microsoft PowerShell para criar caminhos gerenciados para conjuntos de sites baseados em caminho. |
Projete e gerencie URLs para conjuntos de sites nomeados por host
Os cmdlets do PowerShell gerenciam mapeamentos de URL para conjuntos de sites nomeados por host e permitem que você mapeie URLs para um único conjunto de sites:
Set-SPSiteUrl— Adicionar ou alterar um mapeamento de URL de um site.Remove-SPSiteUrl— Remova um mapeamento de URL de um site.Get-SPSiteUrl— Veja todos os URLs e zonas associadas de uma coleção de sites.
Esses cmdlets fornecem funcionalidade de mapeamento de URL para conjuntos de sites nomeados por host similar a mapeamento de acesso alternativo.
Zonas e conjuntos de sites nomeados por host
Conjuntos de sites nomeados por host estão disponíveis através de qualquer zona. As coleções de sites com nome de anfitrião não estão limitadas à zona predefinida. Se necessário, você pode implantar várias zonas e usar zonas e conjuntos de sites nomeados por host para definir diferentes políticas ou configurações de autenticação.
Observação
Para utilizar zonas diferentes, tem de expandir a aplicação Web existente para as novas zonas.
Você pode designar até cinco URLs a um único conjunto de sites designando uma URL por zona. Mesmo que você siga a arquitetura recomendada implantando apenas uma zona, ainda pode designar até cinco URLs para conjuntos de sites nomeados por host. Esta aprovisionamento deve-se ao facto de uma zona não ser implementada ao expandir a aplicação Web, o SharePoint Server utiliza a zona predefinida.
Por exemplo, as seguintes URLs pode oferecer acesso ao mesmo site da Internet:
A conta de rastreamento de pesquisa exige acesso ao conteúdo através da zona Padrão usando a autenticação Integrada do Windows (NTLM ou Kerberos). Uma vez que a autenticação de afirmações permite vários tipos de autenticação numa zona, este requisito não deve afetar outros requisitos de autenticação.
Caminhos gerenciados e conjuntos de sites nomeados por host
URLs configuradas para o mesmo conjunto de sites possuem vários esquemas e domínios diferentes, mas devem ter os mesmos caminhos gerenciados, nomeando tudo após o '/' que segue o domínio deve ser o mesmo. Por exemplo, http://www.Contoso.com/sites/Site1 e http://www.Fabrikam.com/sites/Site1 podem apontar para a mesma coleção de sites, mas http://www.Contoso.com/sites/Site1 e http://www.bar.com/sites/Project1 não podem.
Os cmdlets que gerenciam os URLs somente operam no conjuntos de sites raiz para um nome de host, por exemplo, http://www.Contoso.com. Estes cmdlets não funcionam numa coleção de sites de caminho gerido que esteja por baixo da raiz, como http://www.Contoso.com/sites/Project1. Os sites abaixo da raiz de um conjunto de sites nomeados por host herdarão as configurações de URL desse conjunto de sites nomeados por host.
Terminação alternativa de SSL com conjuntos de sites nomeados por host
A terminação alternativa de SSL ocorre quando um servidor proxy termina uma solicitação SSL e usa HTTP para encaminhar a solicitação para um servidor da Web. Para atingir terminação alternativa de SSL com conjuntos de sites nomeados por host, o dispositivo que termina a conexão SSL, como um servidor proxy reverso, deve ser capaz de gerar um cabeçalho HTTP personalizado: Front-End-Https: Ligado. Para obter mais informações, veja Utilizar coleções de sites com nome de anfitrião com terminação SSL off-box.
A terminação off-box do SSL é suportada, mas não é recomendada porque resulta no envio de tráfego não encriptado do servidor proxy para o servidor Web.
O protocolo utilizado para uma coleção de sites com o nome de anfitrião depende do valor do parâmetro de URL que especificou quando utilizou o Set-SPSiteUrl cmdlet para mapear o URL para uma determinada zona: http ou https. Garanta que as ligações do IIS para o aplicativo da Web, certificados SSL, configuração de proxy reverso e quaisquer outras configurações necessárias estejam completas.
Quando usar conjuntos de sites baseados em caminho
Utilize as coleções de sites tradicionais baseadas no caminho e o mapeamento de acesso alternativo se se aplicar alguma das seguintes condições:
Você precisa usar o recurso Criação de Sites de Autoatendimento, que faz parte da instalação padrão do SharePoint Server.
Esta condição não se aplica a soluções personalizadas de criação personalizada de sites.
A terminação SSL é necessária, mas o dispositivo de terminação SSL não pode ser configurado para produzir o cabeçalho HTTP personalizado necessário.
Ainda pode utilizar o bridging SSL com coleções de sites com nome de anfitrião com estes dispositivos se a terminação de SSL não for um requisito.
Planeia utilizar conjuntos aplicacionais diferentes para a segurança adicional que estes grupos fornecem ou precisa de utilizar vários grupos de proxy.
Nesses casos, você pode usar conjuntos de sites nomeados por host. No entanto, a configuração adicional necessária para mapear URLs para coleções de sites com nome de anfitrião em várias aplicações Web supera consideravelmente os benefícios da utilização de coleções de sites com nome de anfitrião. Para saber mais, confira o arquivo sobre o Utilização de vários aplicativos da Web com conjuntos de sites nomeados por host. Para obter mais informações sobre a criação de conjuntos de sites baseados em caminho, consulte Criar um conjunto de sites no SharePoint Server.
Use cabeçalhos de host e conjuntos de sites nomeados por host
Os cabeçalhos de anfitrião permitem que o servidor Web aloje vários sites na mesma combinação de Endereço IP e Porta. Se o pedido HTTP recebido incluir um nome de cabeçalho de anfitrião e um cabeçalho de anfitrião correspondente estiver configurado no IIS, o IIS responderá com o conteúdo do site adequado.
Os cabeçalhos de anfitrião são configurados ao nível da Aplicação Web (site do IIS), são uma das propriedades de enlaces do site.
É importante compreender a distinção entre cabeçalhos de Anfitrião no IIS e coleções de sites com nome de anfitrião. Os cabeçalhos de anfitrião ao nível do site do IIS destinam-se apenas a coleções de sites baseadas no caminho.
Ao utilizar coleções de sites com nome de anfitrião, o SharePoint é responsável por resolver o site correto para o endereço com base no pedido recebido transmitido através do IIS. Na maioria dos casos, aplicar um enlace de cabeçalho de anfitrião ao nível do site do IIS torna impossível aceder a coleções de sites com nome de anfitrião através do site do IIS. Esta inacessibilidade deve-se ao facto de o IIS não responder aos pedidos de nomes de anfitrião que diferem do enlace do cabeçalho do anfitrião.
Pode utilizar um enlace de cabeçalho de anfitrião de carateres universais no IIS, mas tem de garantir que todas as coleções de sites na aplicação Web estão em conformidade com o padrão de cabeçalho do anfitrião de carateres universais.
Importante
Se uma aplicação Web existente tiver um conjunto de enlaces de cabeçalho de anfitrião, o IIS não devolverá páginas da coleção de sites com o nome de anfitrião até remover o enlace do IIS. Para saber mais, confira Atualizar as associações de URL e IIS do aplicativo Web para SharePoint Server.
Combinar conjuntos de site nomeados por host e conjuntos de sites baseados em caminho no mesmo aplicativo da Web
Você pode usar conjuntos de sites baseados em caminho e nomeados por host no mesmo aplicativo da Web. Para garantir que ambos os tipos de coleções de sites estão acessíveis aos utilizadores, não coloque enlaces de cabeçalhos de anfitrião no site do IIS da sua aplicação Web, incluindo sites do IIS para zonas expandidas a partir da aplicação Web. Se uma aplicação Web existente tiver um conjunto de enlaces de cabeçalho de anfitrião, o IIS não devolverá páginas da coleção de sites com o nome de anfitrião até remover o enlace do IIS.
Meus Sites
Quando usar ambos os tipos de conjuntos de sites com o Meus Sites, considere implantar seu próprio processo de provisionamento para criar o Meus Sites como sites nomeados por host, em vez de sites baseados em caminho.
Implantação e configuração para conjuntos de sites nomeados por host
Criar um aplicativo da Web para conjuntos de sites nomeados por host
Se não pretender configurar dois ou mais sites do IIS que partilham o mesmo número de porta no mesmo servidor, crie uma aplicação Web na zona Predefinida. Não aplique um enlace de cabeçalho de anfitrião ao nível do site do IIS.
Para criar um aplicativo Web para conjuntos de sites nomeados por host
Verifique se você possui as seguintes associações:
A função de servidor fixa securityadmin na instância do SQL Server.
A função de banco de dados fixa db_owner em todos os bancos de dados que devem ser atualizados.
O grupo Administradores no servidor no qual está a executar o cmdlet do Microsoft PowerShell.
Um administrador pode utilizar o
Add-SPShellAdmincmdlet para conceder permissões para utilizar cmdlets do SharePoint Server.Observação
Se não tiver permissões, contacte o administrador de Configuração ou o administrador do SQL Server para pedir permissões. Para obter mais informações sobre as permissões do PowerShell, veja Add-SPShellAdmin.
Abra o Shell de Gerenciamento do SharePoint.
Na linha de comandos do PowerShell (ou seja, PS C:\>), escreva a seguinte sintaxe:
New-SPWebApplication -Name 'Contoso Sites' -port 80 -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'Contoso\JDoe') -AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)
Crie um conjunto de sites raiz
Uma coleção de sites de raiz é um requisito para qualquer aplicação Web. Também é necessário para pesquisar conteúdo. Esta coleção de sites tem de ter o mesmo URL que a aplicação Web. Atualmente, o SharePoint impede a criação de uma coleção de sites com o nome de anfitrião com o mesmo URL que uma aplicação Web. Portanto, o conjunto de sites raiz é criado como um conjunto de sites baseado em caminho.
O exemplo a seguir cria um conjunto de sites vazio que é o conjunto de sites raiz:
New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'
Somente o conjunto de sites raiz do aplicativo da Web aparece na fonte de conteúdo. Apesar de todas as outras coleções de sites com nome de anfitrião na aplicação Web não aparecerem na origem de conteúdo, por predefinição, a pesquisa pesquisa automaticamente as outras coleções de sites com nome de anfitrião.
Criar conjuntos de sites nomeados por host
Você deve usar o Microsoft PowerShell para criar um conjunto de sites nomeado por host. Não pode utilizar a aplicação Web da Administração Central do SharePoint Server para criar uma coleção de sites com nome de anfitrião, mas pode utilizar a Administração Central para gerir a coleção de sites depois de a criar.
Pode criar uma coleção de sites com o nome de anfitrião com o cmdlet do Microsoft PowerShell New-SPSite com o parâmetro -HostHeaderWebApplication conforme mostrado no exemplo seguinte:
Para criar coleções de sites com nome de anfitrião:
Verifique se você possui as seguintes associações:
A função de servidor fixa securityadmin na instância do SQL Server.
A função de banco de dados fixa db_owner em todos os bancos de dados que devem ser atualizados.
O grupo Administradores no servidor no qual está a executar o cmdlet do Microsoft PowerShell.
Um administrador pode utilizar o
Add-SPShellAdmincmdlet para conceder permissões para utilizar cmdlets do SharePoint Server.Observação
Se não tiver permissões, contacte o administrador de Configuração ou o administrador do SQL Server para pedir permissões. Para obter mais informações sobre as permissões do PowerShell, veja Add-SPShellAdmin.
Abra o Shell de Gerenciamento do SharePoint.
Na linha de comandos do PowerShell (ou seja, PS C:\>), escreva a seguinte sintaxe:
New-SPSite 'http://portal.contoso.com' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Portal' -Description 'Customer root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'Esta sintaxe cria uma coleção de sites com o nome de anfitrião que tem o URL, https://portal.contoso.com na aplicação Web do SharePoint Server denominada "Sites Contoso".
Usar caminhos gerenciados com conjuntos de sites nomeados por host.
Você pode implantar caminhos gerenciados com conjuntos de site nomeados por host. Os hosters podem fornecer vários conjuntos de sites para o mesmo cliente com cada conjunto de site compartilhando o nome de host único do cliente, mas diferenciado pelo caminho da URL após o nome de host. Caminhos gerenciados para conjuntos de sites nomeados por host são limitados a 20 por farm. Para obter mais informações, veja Limites de software e limites do SharePoint Server.
Caminhos gerenciados para conjuntos de sites nomeados por host comportam-se de maneira diferente de caminhos gerenciados para conjuntos de sites baseados em caminho. Os caminhos gerenciados para conjuntos de sites nomeados por host estão disponíveis a todos os conjuntos de site nomeados por host dentro do farm, não importa o aplicativo da Web em que o conjunto de sites nomeados por host está. Em contraste, caminhos gerenciados para conjuntos de sites baseados em caminho somente se aplicam a sites dentro do mesmo aplicativo da Web. Os caminhos geridos para coleções de sites baseadas em caminhos não se aplicam a coleções de sites baseadas em caminhos noutras aplicações Web. Os caminhos geridos para um tipo de coleção de sites não se aplicam ao outro tipo de coleção de sites.
Para criar um caminho gerenciado, crie primeiro um conjunto de sites com a URL base desejada. Por exemplo, para criar http://teams.contoso.com/finance tem de criar primeiro a coleção de sites para http://teams.contoso.com.
Para criar um caminho gerenciado para usar com conjuntos de site nomeados por host, use o cmdlet PowerShell New-SPManagedPath com o parâmetro HostHeader, como mostra o exemplo a seguir:
New-SPManagedPath 'departments' -HostHeader
Você também pode usar o parâmetro Explicit para criar caminhos gerenciados explícitos.
O exemplo a seguir mostra um conjunto de sites nomeado por host criado em um caminho gerenciado:
New-SPSite 'http://portal.contoso.com/departments/marketing' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Marketing' -Description 'Portal Marketing' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'
Para remover um caminho gerenciado existente, use o cmdlet PowerShell Remove -SPManagedPath, como mostra o exemplo a seguir:
Remove-SPManagedPath 'departments' -HostHeader
Você pode usar o PowerShell para remover um caminho gerenciado mesmo que um conjunto de sites exista. Se você remover um caminho gerenciado, o conjunto de sites não pode mais ser acessado. Para acessar o conjunto de sites existente, use o PowerShell para recriar o caminho gerenciado.
Mapear URLs para conjuntos de sites nomeados por host
Quando cria uma nova coleção de sites de nome de anfitrião, os mapeamentos de acesso alternativos predefinidos continuarão a existir, mas não podem ser utilizados. Use os comandos do PowerShell para gerenciar mapeamentos de URL para conjuntos de sites nomeados por host.
Adicionar um mapeamento a um site existente:
Set-SPSiteUrl (Get-SPSite 'http://teams.contoso.com') -Url 'http://teamsites.contoso.com' -Zone Intranet
Cada mapeamento de URL é aplicado a uma única zona. Utilize um dos seguintes nomes de zona ao mapear URLs:
Padrão
Intranet
Internet
Personalizado
Extranet
Se não especificar o parâmetro Zone e a entrada de mapeamento de URL for nova, será utilizada a zona predefinida. Você ainda tem uma limitação de 5 URLs para um único conjunto de sites.
Remover um mapeamento para um site:
Remove-SPSiteUrl 'http://teamsites.contoso.com'
Exibir todos os mapeamentos de URL para um site:
Get-SPSiteUrl -Identity (Get-SPSite 'http://teams.contoso.com')
Configurar certificados SSL para os conjuntos de sites nomeados por host
Importante
Se estiver a utilizar o SharePoint Server Subscription Edition, utilize a nova funcionalidade de gestão de certificados para instalar e atribuir certificados SSL às suas aplicações Web. Esta funcionalidade permite-lhe instalar e gerir os seus certificados SSL diretamente no SharePoint em vez de configurar manualmente certificados SSL no IIS.
Você pode configurar um único aplicativo da Web que use SSL e então criar vários conjuntos de sites nomeados por host dentro desse aplicativo da Web. Para navegar para um site sobre SSL, é preciso instalar e designar um certificado de servidor para o site do IIS. Cada conjunto de sites nomeado por host em um aplicativo da Web compartilhará o certificado de servidor único designado ao site do IIS.
Você precisa adquirir um certificado curinga ou um certificado de nome alternativo de entidade (SAN) e então usar o formato da URL do conjunto de sites nomeados por host que corresponde ao certificado. Por exemplo, se adquirir um certificado de caráter universal *.contoso.com, tem de gerar URLs de coleção de sites com nome de anfitrião, como https://site1.contoso.com, https://site2.contoso.come assim sucessivamente, para permitir que estes sites passem a validação SSL do browser. Porém, se precisar de nomes de domínio de segundo nível para sites, deve criar vários aplicativos da Web, em vez de vários conjuntos de sites nomeados por host.
Para configura SSL para conjuntos de sites nomeados por host, habilite SSL quando criar o aplicativo da Web. Esta definição irá criar um site do IIS com um enlace SSL em vez de um enlace HTTP. Depois de criar o aplicativo da Web, abra o Gerenciador do IIS e designe um certificado para essa ligação SSL. Você então pode criar conjuntos de sites nesse aplicativo da Web.
Se estiver a implementar várias zonas com coleções de sites com nome de anfitrião, certifique-se de que a configuração de certificados e enlaces (SSL ou HTTP) é adequada para cada zona e site IIS correspondente.
Usar conjuntos de sites nomeados por host com a terminal alternativo de SSL
Você pode usar os conjuntos de sites nomeados por host com terminação alternativa de SSL. Há várias exigências para usar a terminação SSL com conjuntos de sites nomeados por host.
Observação
A terminação off-box do SSL é suportada, mas não é recomendada porque resulta no envio de tráfego não encriptado do servidor proxy para o servidor Web.
Pelo menos um site do IIS deve ter uma ligação na porta 80 (ou qualquer porta que o terminador encaminhe para a solicitação). A Microsoft recomenda usar o site IIS de um aplicativo da Web (ou o site IIS de uma zona para um aplicativo da Web) com HTTP/80.
O terminador SSL no proxy reverso deve preservar o cabeçalho de host HTTP original do cliente.
Se a solicitação SSL do cliente for enviada para a porta SSL padrão (443), o terminador SSL ou um proxy reverso deve encaminhar a solicitação HTTP descriptografada para o servidor da Web do front-end nessa porta HTTP padrão (80). Se a solicitação SSL do cliente for enviada para uma porta SSL não padrão, o terminador SSL ou o proxy reverso deve encaminhar a solicitação HTTP descriptografada para o servidor da Web do front-end na mesma porta não padrão.
O dispositivo que termina a conexão SSL, como um servidor proxy reverso, deve ser capaz de gerar um cabeçalho HTTP personalizado: Front-End-Https: Ligado. Este cabeçalho é o mesmo cabeçalho personalizado que o Outlook Web Access (OWA) utiliza: Front-End-Https: Ativado/Desativado. Mais informações sobre esse cabeçalho personalizado estão incluídas mais adiante nesta seção.
Para usar conjuntos de sites nomeados por host com a terminação alternativa SSL, configure o aplicativo da Web como normalmente faria para terminação SSL e garanta que ele atenda os requisitos descritos acima. Nesse cenário, o SharePoint Server usará HTTPS, em vez de HTTP, para renderizar links dos seus conjuntos conjuntos de sites nomeados por host nesse aplicativo da Web.
Servidores de proxy reversos podem publicar conjuntos de sites nomeados por host do SharePoint Server e realizar terminação alternativa de SSL. Nesse cenário, o servidor proxy reverso muda o tipo de conexão entre o usuário final e o servidor de front-end da Web do SharePoint de SSL/TLS para HTTP, ou vice-versa. Neste cenário, os servidores proxy inversos têm de inserir um cabeçalho HTTP adicional no pedido do utilizador quando reencaminhar o pedido para o servidor front-end web do SharePoint. Este cabeçalho HTTP adicional indica ao SharePoint Server o tipo de ligação que o utilizador final iniciou para que o SharePoint Server componcione os URLs adequadamente na respetiva resposta. O nome do cabeçalho HTTP é "Front-End-Https" e seus valores aceitáveis são os seguintes.
Tabela: valores de cabeçalho Front-End-Https
| Valor | Descrição |
|---|---|
| Habilitado | O servidor de proxy reverso recebeu a solicitação do usuário final por uma conexão HTTPS (SSL ou TLS) criptografada. Por exemplo, Front-End-Https: Ligado. |
| Desligado | O servidor proxy reverso recebeu a solicitação do usuário final por uma conexão HTTP não criptografada. |
Os valores não são sensíveis a maiúsculas e minúsculas. Por exemplo, ligado, LIGADO, Ligado e lIGADO são aceitáveis.
Esse cabeçalho personalizado funciona apenas com conjuntos de sites nomeados por host. Não funciona com coleções de sites baseadas em caminhos.
O exemplo a seguir mostra um conjunto de sites nomeado por host criado em um https:
New-SPSite 'https://portal.contoso.com' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Portal' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'
Esse exemplo cria um conjunto de sites nomeado por host que possui a URL https://portal.contoso.com, no aplicativo Web do SharePoint Server que possui a URL https://webapp.contoso.com.
Habilitar aplicativos em ambientes com várias zonas
Observação
Esta secção aplica-se apenas ao SharePoint Server 2013.
A Atualização Pública de março de 2013 permite configurar um domínio de aplicativo para cada zona de aplicativo da Web e usar mapeamento de acesso alternativo e configuração de aplicativo da Web com cabeçalho de host. Antes da liberação dessa atualização, você poderia apenas hospedar um domínio de aplicativo e colocá-lo na zona Padrão. Não foi possível utilizar o domínio da aplicação em mapeamentos de acesso alternativos ou configurações de aplicações Web com cabeçalho de anfitrião.
Para resolver esse problema, aplique o Pacote de correção com atualização cumulativa para servidor do SharePoint Server: 12 de março de 2013, consulte as Atualizações do SharePoint 2013.
Migrar conjuntos de sites baseados em caminho para conjuntos de sites nomeados por host
Determina conjuntos de sites nomeados por host em aplicativos da Web existentes
Pode utilizar o seguinte script para identificar que coleções de sites existentes são baseadas no caminho e que têm o nome de anfitrião, para que possa decidir mais tarde se pretende converter qualquer uma delas de um tipo para outro.
$webApp = Get-SPWebapplication 'http://webapp.contoso.com'
foreach($spSite in $webApp.Sites)
{
if ($spSite.HostHeaderIsSiteName)
{ Write-Host $spSite.Url 'is host-named' }
else
{ Write-Host $spSite.Url 'is path based' }
}
Converter conjuntos de sites baseados em caminho para conjuntos de site nomeados por host
Pode converter coleções de sites baseadas no caminho em coleções de sites com nome de anfitrião e coleções de sites com nome de anfitrião em coleções de sites baseadas no caminho com o cmdlet do PowerShell Set-SPSite. Após o nome do site, é recomendada uma reciclagem do conjunto de aplicações para forçar a atualização da cache. Não pode utilizar o site da Administração Central do SharePoint nem os cmdlets do Windows PowerShell que anexam e desanexam, nem montar e desmontar bases de dados de conteúdos para converter coleções de sites.
O exemplo a seguir converter um conjunto de sites padrão em um conjunto de sites nomeado por host:
Get-SPSite https://SP2013content.contoso.com/sites/PathBasedSiteCollection|Set-SPSite -url https://HostNamedSiteCollection.contoso.com
Utilização de vários aplicativos da Web com conjuntos de sites nomeados por host
Se você usar mais de um aplicativo da Web, adicionará mais sobrecarga operacional e complexidade ao sistema. Recomendamos usar um aplicativo da Web para conjuntos de sites. Porém, os seguintes motivos podem influenciar na implantação de conjuntos de sites através de vários aplicativos da Web:
As políticas de segurança de uma organização exigem aplicativos da Web ou pools de aplicativos separados.
Os aplicativos da Web precisam ser configurados de maneira diferente.
Uma organização exibe o uso de vários grupos de proxy.
É mais complexo implementar coleções de sites com nome de anfitrião com múltiplas aplicações Web num farm, porque tem de concluir mais passos de configuração. Por exemplo, URLs com sites nomeados por host podem espalhar entre vários aplicativos da Web que compartilham a mesma porta em um único farm. Este cenário exige mais etapas de configuração para garantir que as solicitações sejam mapeadas para os aplicativos da Web corretos. Você precisa configurar manualmente os mapeamentos em cada servidor da Web no farm configurando um endereço IP separado para representar cada aplicativo da Web. Você também precisa criar e gerenciar ligações de cabeçalho de host para designar endereços IP únicos para cada site. Os scripts podem gerir e replicar esta configuração entre servidores; no entanto, esta replicação da configuração adiciona complexidade à solução. Cada URL única também exige um mapeamento no DNS. De um modo geral, se vários aplicativos da Web são uma exigência, recomendamos conjuntos de sites baseados em caminho com mapeamento de acesso alternativo.
Importante
A Edição de Subscrição do SharePoint Server Versão 23H1 permite que os utilizadores atribuam enlaces de cabeçalho de anfitrião de carateres universais às respetivas aplicações Web. Esta nova funcionalidade pode ajudá-lo a utilizar várias aplicações Web com coleções de sites com nome de anfitrião das seguintes formas:
Os utilizadores já não precisam de atribuir manualmente enlaces de endereços IP exclusivos às respetivas aplicações Web em cada um dos respetivos servidores do SharePoint. Os utilizadores que executam a Versão 23H1 do SPSE podem, em vez disso, atribuir cabeçalhos de anfitrião de carateres universais a cada uma das respetivas aplicações Web, o que é mais simples de gerir.
Os cabeçalhos de anfitrião de carateres universais atribuídos a cada aplicação Web têm de ser exclusivos. Por exemplo, a aplicação Web 1 pode ser
*.internal.example.com, a aplicação Web 2 pode ser*.external.example.com, etc.As coleções de sites com o nome de anfitrião nestas aplicações Web terão de estar em conformidade com o padrão de cabeçalho do anfitrião de carateres universais da respetiva aplicação Web. Por exemplo, se uma aplicação Web tiver um cabeçalho de anfitrião de carateres universais do
*.external.example.com, pode alojar coleções de sites com nome de anfitrião com nomes DNS comosite1.external.example.com,site2.external.example.com, etc.Os enlaces de cabeçalho do anfitrião de carateres universais só podem ter um caráter universal como a etiqueta mais à esquerda no nome DNS. Por exemplo, um cabeçalho de anfitrião de carateres universais válido pode ser
*.external.example.com, mas não pode serexternal.*.example.com,*.*.example.com,external*.example.com,*external.example.com, etc.
As duas tabelas a seguir contrastam três opções de design diferentes para implantar conjuntos de sites. Essas tabelas são feitas para ajudá-lo a entender as consequências de cada abordagem e como a configuração varia conforme a arquitetura.
Tabela: Resulta de diferentes escolhas de design para provisionar conjuntos de sites
| Conjuntos de sites nomeadas em host com todos os sites em um farm consolidado em um aplicativo da Web | Conjuntos de site baseado em caminho com mapeamento de acesso alternativo e vários aplicativos da Web | Conjuntos de sites nomeados por host com vários aplicativos Web em um farm | |
|---|---|---|---|
| Provisionamento do conjunto de sites | Use o Microsoft PowerShell ou uma solução de provisionamento do conjunto de sites personalizada para provisionar os sites. | Use o Administração Central ou o Microsoft PowerShell para implantar sites. | Use o Microsoft PowerShell ou uma solução de provisionamento do conjunto de sites personalizada para provisionar os sites. |
| Gerenciamento de URL | Pode mapear todas as coleções de sites no DNS para apontarem para um único endereço IP que representa a aplicação Web. | Se você implantar mais de uma zona, configurar mapeamento de acesso alternativo para cada URL do site. Cada zona também exige um mapeamento no DNS. | É necessária uma configuração adicional para garantir que os pedidos de sites que partilham a mesma porta são mapeados para a aplicação Web correta. Cada nome de host exclusivo também exige um mapeamento no DNS. Essa configuração é manual e você deve concluí-la em cada servidor web em um farm para cada. |
| Mais URLs | Você pode atribuir até cinco URLs para um conjunto de sites nomeado por host, onze por zona. Não é necessário expandir a aplicação Web para várias zonas. Se uma zona não for implementada, é utilizada a zona predefinida. | O número de URLs de uma coleção de sites está limitado a cinco porque o número permitido de zonas é cinco. | Você pode atribuir até cinco URLs para um conjunto de sites nomeado por host, onze por zona. Não é necessário expandir a aplicação Web para várias zonas. Se uma zona não for implementada, é utilizada a zona predefinida. |
| Aplicativos de serviço | Todos os sites no farm usam um único grupo de aplicativo de serviço. | Você pode implementar grupos de aplicativos de serviço personalizados para diferentes aplicativos Web. | Você pode implementar grupos de aplicativos de serviço personalizados para diferentes aplicativos Web. |
| Zonas | Não tem de implementar várias zonas para implementar URLs diferentes para a mesma coleção de sites. Se uma zona não for implementada, é utilizada a zona predefinida. | As zonas são necessárias para implantar diferentes URLs para o mesmo conjunto de sites. | Não tem de implementar várias zonas para implementar URLs diferentes para a mesma coleção de sites. Se uma zona não for implementada, é utilizada a zona predefinida. |
| Autenticação | Com um aplicativo da Web, as opções de autenticação são limitadas para cinco zonas. Porém, você pode implantar muitos métodos de autenticação em uma zona. | Você pode implementar diferentes designs de zona e autenticação para cada aplicativo Web. | Você pode implementar diferentes designs de zona e autenticação para cada aplicativo Web. |
| Autenticação | Oferece isolamento de script do cliente entre URLs de domínio. | Você pode isolar os aplicativos Web em pools de aplicativos exclusivos, se desejado, para obter o isolamento do processo. Oferece isolamento entre URLs de domínio. |
Você pode isolar os aplicativos Web em pools de aplicativos exclusivos, se desejado, para obter o isolamento do processo. Oferece isolamento entre URLs de domínio. |
| Política | Você pode usar zonas para designar diferentes políticas para sites nomeados por host. | Você pode usar políticas no nível do aplicativo da Web para aplicar permissões, independentemente das permissões configuradas nos sites ou documentos individuais. Além disso, pode implantar diferentes políticas para diferentes zonas. | Você pode implantar diferentes políticas para diferentes aplicativos da Web para aplicar permissões, independentemente das permissões configuradas para sites ou documentos individuais. Além disso, pode implantar diferentes políticas para diferentes zonas. |
Os números de escalabilidade que também podem afetar as decisões de design incluem os máximos recomendados para conjuntos de sites, bancos de dados de conteúdo e caminhos gerenciados.
A tabela a seguir resume a configuração necessária para gerenciar URLs com base em cada uma das três opções de design apresentadas neste artigo.
Tabela: Configuração necessária para diferentes designs do conjunto de site
| Conjuntos de sites nomeados por host com todos os sites em um farm consolidados em um aplicativo da Web | Conjuntos de site baseado em caminho com mapeamento de acesso alternativo e vários aplicativos da Web | Conjuntos de sites nomeados por host com vários aplicativos Web em um farm | |
|---|---|---|---|
| Dentro do SharePoint Server | Criar um aplicativo Web. Crie uma coleção de sites de raiz que não esteja acessível aos utilizadores (por exemplo, https://HNSC01.fabrikam.com). Crie as coleções de sites com o nome de anfitrião com o cabeçalho do anfitrião (por exemplo, https://intranet.fabrikam.com). Opcionalmente, adicione mais URLs a cada conjunto de sites e configure zonas usando Set-SPSiteUrl. (Nas amostras de design do portal corporativo não é necessário porque há apenas uma zona.) |
Crie a aplicação Web com o cabeçalho do anfitrião (por exemplo, https://intranet.fabrikam.com). Opcionalmente, configure o mapeamento de acesso alternativo. No exemplo de estrutura, não é necessário porque existe apenas uma zona). Criar o conjunto de site baseado em caminho raiz. |
Criar um aplicativo Web. Crie uma coleção de sites de raiz que não esteja acessível aos utilizadores (por exemplo, https://HNSC01.fabrikam.com). Crie as coleções de sites com o nome de anfitrião com o cabeçalho do anfitrião (por exemplo, https://intranet.fabrikam.com). Opcionalmente, adicione mais URLs a cada conjunto de sites e configure zonas usando Set-SPSiteUrl. (Nas amostras de design do portal corporativo não é necessário porque há apenas uma zona.) |
| Dentro do IIS | Associar um certificado SSL (certificado curinga ou certificado SAN) para todos os sites nomeados por host (domínio) no aplicativo da Web. | Associar um certificado SSL no IIS para cada zona (cada zona é um aplicativo da Web separado no IIS). | Associe um certificado SSL (certificado curinga ou certificado SAN) para um site nomeado por host (domínio) nos aplicativos da Web. Em cada servidor da Web no farm e para cada aplicativo da Web que compartilhe uma porta: Configurar um endereço IP separado para representar cada aplicativo da Web. Edite manualmente o enlace do site do IIS para remover o enlace de cabeçalho do anfitrião que foi criado quando a aplicação Web foi criada e substitua este enlace por um enlace de endereço IP. |
Se utilizar várias aplicações Web em diferentes endereços IP, poderá ter de concluir a configuração adicional para o NIC, o DNS e o balanceador de carga para cada servidor.
Criar vários aplicativos da Web com conjuntos de sites nomeados por host
Para executar vários aplicativos da Web no mesmo servidor e porta em combinação com conjuntos de site nomeados por host, pode precisar designar diferentes endereços IP aos aplicativos da Web. Esse tipo de arquitetura requer que você adicione endereços IP aos servidores da Web e configure os roteadores de rede para apontar nomes de host para o endereço IP do seu aplicativo da Web.
Observação
Pode criar uma aplicação Web que não tenha um cabeçalho de anfitrião. Se criar uma aplicação Web que não tenha um cabeçalho de anfitrião, não poderá criar várias aplicações Web com coleções de sites com nome de anfitrião no mesmo servidor Web.
O processo que cria várias aplicações Web para uma coleção de sites com o nome de anfitrião inclui as seguintes tarefas:
Crie os vários aplicativos da Web.
Adicione um novo endereço IP virtual no IIS em cada servidor da Web no farm.
Criar vários aplicativos da Web para conjuntos de sites nomeados por host
O exemplo a seguir cria um aplicativo da Web:
New-SPWebApplication -Name 'webapp' 'webapp.contoso.com' -port 80 -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'Contoso\JDoe') -AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)
Repita essa tarefa para cada aplicativo da Web.
Adicionar endereços IP virtuais no IIS
As ligações IP devem ser aplicadas em todos os servidores que hospedarão o aplicativo da Web. Defina o comando de suspensão para 60 segundos para garantir que as ligações IP estejam definidas para todos os servidores no farm antes de o cabeçalho de host existente no aplicativo da Web ser removido. Script remoto pode ser usado para esse trabalho.
Use os seguintes comandos para adicionar ligações IP únicas para cada um dos aplicativos da Web criados e então remover a ligação do cabeçalho de host desses aplicativos da Web.
Import-Module WebAdministration
#add empty binding to webapp on IP 192.168.10.20
New-WebBinding -Name 'webapp' -IPAddress '192.168.10.20' -HostHeader ''
Sleep 60
# remove existing binding webapp.contoso.com from existing web application
Get-WebBinding -Name 'webapp' -HostHeader 'webapp.contoso.com'|Remove-WebBinding