Arquitetura e implantação de conjunto de sites nomeados por host no SharePoint Server
APLICA-SE A:
2013 2019 Subscription Edition 
SharePoint no Microsoft 365
As coleções de sites nomeadas pelo host são uma abordagem opcional para implantar sites no SharePoint Server. Os usuários que desejam ter várias coleções de sites, com cada coleção de sites com seu próprio nome DNS, podem optar por implantar coleções de sites com nome de host. Caso contrário, os usuários devem implantar coleções de sites baseadas em caminho.
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 você deve implantar muitos sites com nomes DNS exclusivos no mesmo aplicativo 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 implantar coleções de sites nomeadas pelo host é colocar todas as coleções de sites nomeadas pelo host em um único aplicativo Web, conforme ilustrado no diagrama a seguir.
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 raiz (
http://webapp.contoso.com).Vários conjuntos de sites nomeados por host para hospedar conteúdo com sites de exemplo:
Conteúdo de intranet publicado (
http://intranet.contoso.com) com subsites para RH, Instalações e Compras.Sites de equipe (
http://teams.contoso.com) com subsites para a Equipe 1, Equipe 2 e Equipe 3.Meus Sites com URLs do site no seguinte formato:
http://my.contoso.com/personal/<site_name>.
O número de sites dentro do aplicativo Web e as URLs para sites não são importantes para este exemplo.
Ao criar um aplicativo Web para coleções de sites nomeadas pelo host, a URL do aplicativo Web e a coleção de sites raiz serão http://<_webapp.contoso.com_>/.
Essa arquitetura é recomendada para implantar coleções de sites nomeadas por host porque é a mesma arquitetura que o ambiente do Microsoft 365 usa. Portanto, essa configuração é a configuração mais fortemente testada. Novos recursos, incluindo o modelo de aplicativo e o Gerenciamento de Solicitações, são otimizados para essa configuração e é a configuração mais confiável daqui para frente.
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. Ao implantar muitas coleções de sites nomeadas para host em um único aplicativo Web, você aumenta a escalabilidade do farm porque os recursos não são usados para dar suporte a vários pools de aplicativos e aplicativos 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. Você não pode usar a Administração Central para criar coleções de sites nomeadas pelo host. | 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 que os usuários não podem acessar. | Normalmente, um único conjunto de sites baseado em caminho serve como o conjunto de sites raiz dentro de um aplicativo da Web. Você pode usar caminhos gerenciados para criar mais coleções de sites no aplicativo Web. |
| Mapeamento de URL | Use comandos do PowerShell para gerenciar URLs (Set-SPSiteUrl, , Remove-SPSiteUrlGet-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. O recurso de Criação de Site de Autoatendimento que faz parte da instalação padrão do SharePoint Server não funciona com coleções de sites nomeadas pelo host. |
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— Adicione ou altere um mapeamento de URL para um site.Remove-SPSiteUrl— Remova um mapeamento de URL de um site.Get-SPSiteUrl— Consulte todas as URLs e zonas associadas para 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 nomeadas pelo host não se limitam à zona padrão. 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 usar zonas diferentes, você precisa estender o aplicativo 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. Essa disposição ocorre porque, se uma zona não for implementada estendendo o aplicativo Web, o SharePoint Server usará a zona padrão.
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). Como a autenticação de declarações permite vários tipos de autenticação em uma zona, esse 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 ambos podem apontar para a mesma coleção de sites, mas http://www.Contoso.com/sites/Site1 não http://www.bar.com/sites/Project1 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. Esses cmdlets não operam em uma coleção de sites de caminho gerenciado que está sob a 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, consulte Usar coleções de sites nomeadas pelo host com término de SSL off-box.
O término off-box do SSL tem suporte, mas não é recomendado porque resulta em tráfego não criptografado sendo enviado do servidor proxy para o servidor Web.
O protocolo usado para uma coleção de sites com nome de host depende do valor do parâmetro de URL especificado quando você usou o Set-SPSiteUrl cmdlet para mapear a URL para uma zona específica: 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
Use as coleções de sites tradicionais baseadas em caminho e o mapeamento de acesso alternativo se alguma das seguintes condições se aplicar:
Você precisa usar o recurso Criação de Sites de Autoatendimento, que faz parte da instalação padrão do SharePoint Server.
Essa condição não se aplica a soluções personalizadas de criação de site de autoatendimento.
O término do SSL é necessário, mas seu dispositivo de terminação SSL não pode ser configurado para produzir o cabeçalho HTTP personalizado necessário.
Você ainda pode usar a ponte SSL com coleções de sites nomeadas pelo host com esses dispositivos se o término do SSL não for um requisito.
Você planeja usar diferentes pools de aplicativos para a segurança extra que esses grupos fornecem ou precisa usar vários grupos de proxy.
Nesses casos, você pode usar conjuntos de sites nomeados por host. No entanto, a configuração extra necessária para mapear URLs para coleções de sites nomeadas pelo host em vários aplicativos Web superam consideravelmente os benefícios do uso de coleções de sites nomeadas pelo host. 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 host permitem que o servidor Web hospede vários sites na mesma combinação de Endereço IP e Porta. Se a solicitação HTTP de entrada incluir um nome de cabeçalho do host e um cabeçalho de host correspondente estiver configurado no IIS, o IIS responderá com o conteúdo do site apropriado.
Os cabeçalhos de host são configurados no nível do aplicativo Web (site do IIS), eles são uma das propriedades de associações do site.
É importante entender a distinção entre cabeçalhos host no IIS e coleções de sites com nome de host. Os cabeçalhos de host no nível do site do IIS destinam-se apenas a coleções de sites baseadas em caminho.
Ao usar coleções de sites nomeadas pelo host, o SharePoint é responsável por resolver o site correto para o endereço com base na solicitação de entrada passada pelo IIS. Na maioria dos casos, a aplicação de uma associação de cabeçalho de host no nível do site do IIS torna impossível acessar coleções de sites nomeadas pelo host por meio do site do IIS. Essa inacessibilidade ocorre porque o IIS não responderá às solicitações de nomes de host que diferem da associação de cabeçalho do host.
Você pode usar uma associação de cabeçalho de host curinga no IIS, mas deve garantir que todas as coleções de sites no aplicativo Web estejam em conformidade com o padrão de cabeçalho do host curinga.
Importante
Se um aplicativo Web existente tiver um conjunto de associação de cabeçalho de host, o IIS não retornará páginas da coleção de sites nomeada pelo host até que você remova a associação 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 estejam acessíveis aos usuários, não coloque associações de cabeçalho de host no site do IIS do seu aplicativo Web, incluindo sites do IIS para zonas estendidas do aplicativo Web. Se um aplicativo Web existente tiver um conjunto de associação de cabeçalho de host, o IIS não retornará páginas da coleção de sites nomeada pelo host até que você remova a associação 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 você não pretende configurar dois ou mais sites do IIS que compartilham o mesmo número de porta no mesmo servidor, crie um aplicativo Web na zona Padrão. Não aplique uma associação de cabeçalho de host no 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 você está executando o cmdlet do Microsoft PowerShell.
Um administrador pode usar o
Add-SPShellAdmincmdlet para conceder permissões para usar cmdlets do SharePoint Server.Observação
Se você não tiver permissões, entre em contato com o administrador de instalação ou SQL Server administrador para solicitar permissões. Para obter mais informações sobre permissões do PowerShell, consulte Add-SPShellAdmin.
Abra o Shell de Gerenciamento do SharePoint.
No prompt de comando do PowerShell (ou seja, PS C:\>), digite 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 raiz é um requisito para qualquer aplicativo Web. Também é necessário para o rastreamento de conteúdo. Essa coleção de sites deve ter a mesma URL que o aplicativo Web. Atualmente, o SharePoint impede a criação de uma coleção de sites nomeada pelo host com a mesma URL de um aplicativo 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. Mesmo que todas as outras coleções de sites nomeadas pelo host no aplicativo Web não apareçam na fonte de conteúdo, por padrão, a pesquisa rasteja automaticamente as outras coleções de sites nomeadas pelo host.
Criar conjuntos de sites nomeados por host
Você deve usar o Microsoft PowerShell para criar um conjunto de sites nomeado por host. Você não pode usar o aplicativo Web da Administração Central do SharePoint Server para criar uma coleção de sites com nome de host, mas pode usar a Administração Central para gerenciar a coleção de sites depois de criá-la.
Você pode criar uma coleção de sites com nome de host usando o cmdlet do Microsoft PowerShell New-SPSite com o parâmetro –HostHeaderWebApplication conforme mostrado no exemplo a seguir:
Para criar coleções de sites nomeadas pelo 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 você está executando o cmdlet do Microsoft PowerShell.
Um administrador pode usar o
Add-SPShellAdmincmdlet para conceder permissões para usar cmdlets do SharePoint Server.Observação
Se você não tiver permissões, entre em contato com o administrador de instalação ou SQL Server administrador para solicitar permissões. Para obter mais informações sobre permissões do PowerShell, consulte Add-SPShellAdmin.
Abra o Shell de Gerenciamento do SharePoint.
No prompt de comando do PowerShell (ou seja, PS C:\>), digite 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'Essa sintaxe cria uma coleção de sites com nome de host que tem a URL, https://portal.contoso.com no aplicativo Web do SharePoint Server chamado "Contoso Sites".
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, consulte Limites e limites de software para o 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 gerenciados para coleções de sites baseados em caminho não se aplicam a coleções de sites baseadas em caminho em outros aplicativos Web. Os caminhos gerenciados 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 , primeiro você deve criar 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 você cria uma nova coleção de sites de nome de host, os mapeamentos de acesso alternativos padrão ainda existirão, mas não poderão ser usados. 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 você não especificar o parâmetro Zone e a entrada de mapeamento de URL for nova, a zona padrão será usada. 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 você estiver usando Edição de Assinatura do SharePoint Server, use o novo recurso de gerenciamento de certificados para instalar e atribuir certificados SSL aos seus aplicativos Web. Esse recurso permite instalar e gerenciar 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 você adquirir um certificado curinga *.contoso.com, deverá gerar URLs de coleção de sites nomeadas pelo host, como https://site1.contoso.com, https://site2.contoso.come assim por diante, para permitir que esses sites passem a validação SSL do navegador. 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. Essa configuração criará um site do IIS com uma associação SSL em vez de uma associação 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 você estiver implementando várias zonas com coleções de sites nomeadas pelo host, verifique se a configuração de certificados e associações (SSL ou HTTP) é apropriada 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
O término off-box do SSL tem suporte, mas não é recomendado porque resulta em tráfego não criptografado sendo enviado 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. Esse cabeçalho é o mesmo cabeçalho personalizado que o Outlook Web Access (OWA) usa: 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. Os servidores proxy reverso nesse cenário devem inserir um cabeçalho HTTP extra na solicitação do usuário quando ele encaminhar a solicitação para o servidor de front-end web do SharePoint. Esse cabeçalho HTTP extra indica ao SharePoint Server o tipo de conexão iniciada pelo usuário final para que o SharePoint Server renderize as URLs adequadamente em sua 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 |
|---|---|
| Ativado | 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. |
| Desativada | 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 casos. Por exemplo, ligado, LIGADO, Ligado e lIGADO são aceitáveis.
Esse cabeçalho personalizado funciona apenas com conjuntos de sites nomeados por host. Ele não funciona com coleções de sites baseadas em caminho.
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 seção se aplica 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. Você não poderia usar o domínio do aplicativo em mapeamentos de acesso alternativos ou configurações de aplicativo Web de cabeçalho de host.
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
Você pode usar o script a seguir para identificar quais coleções de sites existentes são baseadas em caminho e que são nomeadas como host, para que você possa decidir mais tarde se deseja 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
Você pode converter coleções de sites baseadas em caminho em coleções de sites nomeadas pelo host e coleções de sites nomeadas para host em coleções de sites baseadas em caminho usando o cmdlet Set-SPSite do PowerShell. Após a renomeação do site, é recomendável reciclar um pool de aplicativos para forçar a atualização do cache. Você não pode usar o site da Administração Central do SharePoint ou Windows PowerShell cmdlets que anexam e desanexam ou montam e desmontam bancos de dados de conteúdo 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 nomeadas pelo host com vários aplicativos Web em um farm porque você deve concluir mais etapas 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 gerenciar e replicar essa configuração entre servidores; no entanto, essa replicação de 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
Edição de Assinatura do SharePoint Server Versão 23H1 permite que os usuários atribuam associações de cabeçalho de host curinga a seus aplicativos Web. Este novo recurso pode ajudá-lo a usar vários aplicativos Web com coleções de sites nomeadas pelo host das seguintes maneiras:
Os usuários não precisam mais atribuir manualmente associações de endereço IP exclusivas a seus aplicativos Web em cada um de seus servidores do SharePoint. Os usuários que executam o SPSE Versão 23H1 podem, em vez disso, atribuir cabeçalhos de host curinga a cada um de seus aplicativos Web, o que é mais simples de gerenciar.
Os cabeçalhos de host curinga atribuídos a cada aplicativo Web devem ser exclusivos. Por exemplo, o aplicativo Web 1 pode ser
*.internal.example.com, o aplicativo Web 2 pode ser*.external.example.com, etc.As coleções de sites nomeadas pelo host nesses aplicativos Web terão que estar em conformidade com o padrão de cabeçalho de host curinga de seu aplicativo Web. Por exemplo, se um aplicativo Web tiver um cabeçalho de host curinga de
*.external.example.com, ele poderá hospedar coleções de sites nomeadas pelo host com nomes DNS comosite1.external.example.com,site2.external.example.cometc.As associações de cabeçalho de host curinga só podem ter um único caractere curinga como o rótulo mais à esquerda no nome DNS. Por exemplo, um cabeçalho de host curinga válido pode ser
*.external.example.com, mas não pode serexternal.*.example.com,*.*.example.com,external*.example.com, etc*external.example.com.
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 | Você pode mapear todas as coleções de sites no DNS para apontar para um único endereço IP que representa o aplicativo 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. | A configuração extra é necessária para garantir que as solicitações de sites que compartilham a mesma porta sejam mapeadas para o aplicativo Web correto. 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 estender o aplicativo Web para várias zonas. Se uma zona não for implementada, a zona padrão será usada. | O número de URLs de uma coleção de sites é 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 estender o aplicativo Web para várias zonas. Se uma zona não for implementada, a zona padrão será usada. |
| 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 | Você não precisa implementar várias zonas para implementar URLs diferentes para a mesma coleção de sites. Se uma zona não for implementada, a zona padrão será usada. | As zonas são necessárias para implantar diferentes URLs para o mesmo conjunto de sites. | Você não precisa implementar várias zonas para implementar URLs diferentes para a mesma coleção de sites. Se uma zona não for implementada, a zona padrão será usada. |
| 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 raiz que não esteja acessível aos usuários (por exemplo, https://HNSC01.fabrikam.com). Crie as coleções de sites nomeadas pelo host com o cabeçalho do host (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 o aplicativo Web com o cabeçalho do host (por exemplo, https://intranet.fabrikam.com). Opcionalmente, configure o mapeamento de acesso alternativo. No exemplo de design, não há necessidade porque há apenas uma zona). Criar o conjunto de site baseado em caminho raiz. |
Criar um aplicativo Web. Crie uma coleção de sites raiz que não esteja acessível aos usuários (por exemplo, https://HNSC01.fabrikam.com). Crie as coleções de sites nomeadas pelo host com o cabeçalho do host (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 a associação do site do IIS manualmente para remover a associação de cabeçalho do host criada quando o aplicativo Web foi criado e substitua essa associação por uma associação de endereço IP. |
Se você usar vários aplicativos Web em endereços IP diferentes, talvez seja necessário concluir a configuração extra para a NIC, 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
Você pode criar um aplicativo Web que não tenha um cabeçalho de host. Se você criar um aplicativo Web que não tenha um cabeçalho de host, não poderá criar vários aplicativos Web com coleções de sites nomeadas pelo host no mesmo servidor Web.
O processo que cria vários aplicativos Web para uma coleção de sites nomeada pelo host 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