Architettura e distribuzione di raccolte siti con nome host in SharePoint Server
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Le raccolte siti con nome host sono un approccio facoltativo per distribuire i siti in SharePoint Server. Gli utenti che desiderano avere più raccolte siti, con ogni raccolta siti con il proprio nome DNS, possono scegliere di distribuire raccolte siti con nome host. In caso contrario, gli utenti devono distribuire raccolte siti basate su percorso.
In questo articolo viene illustrato come pianificare e implementare raccolte siti con nome host, nonché progettare e gestire gli URL.
Architettura e progettazione delle raccolte siti con nome host
Le raccolte siti con nome host consentono di assegnare un nome DNS univoco alle raccolte siti. Ad esempio, è possibile risolverli come http://TeamA.contoso.com e http://TeamB.contoso.com. In questo esempio viene illustrato come distribuire molti siti con nomi DNS univoci nella stessa applicazione Web. Consente inoltre agli hoster di ridimensionare un ambiente a molti clienti.
In questo articolo viene descritto come implementare raccolte siti con nome host in una configurazione consigliata con SharePoint Server. Informazioni sulle configurazioni avanzate sono disponibili nella parte finale dell'articolo: Utilizzo di più applicazioni Web con raccolte siti con nome host.
Architettura consigliata per le raccolte siti con nome host
La configurazione consigliata per la distribuzione di raccolte siti con nome host consiste nel posizionare tutte le raccolte siti con nome host all'interno di una singola applicazione Web, come illustrato nel diagramma seguente.
Configurazione consigliata per le raccolte siti con nome host
La configurazione consigliata illustrata nel diagramma include gli elementi seguenti:
Un pool di applicazioni per le raccolte siti
Un'applicazione Web per le raccolte siti ospitata all'interno dell'unico pool di applicazioni
Raccolta siti radice (
http://webapp.contoso.com).Più raccolte siti con nome host per l'hosting di contenuti, con siti di esempio:
Contenuto Intranet pubblicato (
http://intranet.contoso.com) con siti secondari per risorse umane, strutture e acquisti.Siti del team (
http://teams.contoso.com) con siti secondari per Team 1, Team 2 e Team 3.Siti personali con URL del sito nel formato seguente:
http://my.contoso.com/personal/<site_name>.
Il numero di siti all'interno dell'applicazione Web e gli URL per i siti non sono importanti per questo esempio.
Quando si crea un'applicazione Web per le raccolte siti con nome host, l'URL dell'applicazione Web e della raccolta siti radice sarà http://<_webapp.contoso.com_>/.
Questa architettura è consigliata per distribuire raccolte siti con nome host perché è la stessa architettura usata dall'ambiente Microsoft 365. Questa configurazione è quindi la configurazione più testata. Le nuove funzionalità, tra cui il modello di app e Gestione richieste, sono ottimizzate per questa configurazione ed è la configurazione più affidabile in futuro.
La configurazione consigliata non include gli elementi seguenti:
Abilitazione di app in ambienti con più aree
Combinazione di raccolte siti con nome host e raccolte siti basate su percorso (esclusa la raccolta siti radice)
Più applicazioni Web con raccolte siti con nome host
Confronto tra raccolte siti con nome host e raccolte siti basate su percorso
Quando si utilizzano raccolte siti con nome host, a ogni raccolta siti in un'applicazione Web viene assegnato un nome DNS univoco. Quando si distribuiscono molte raccolte siti con nome host in una singola applicazione Web, si aumenta la scalabilità della farm perché le risorse non vengono usate per supportare più pool di applicazioni e applicazioni Web.
SharePoint Server supporta sia le raccolte siti con nome host sia quelle basate su percorso. Nella tabella seguente sono illustrate le differenze tra le due opzioni e sono disponibili altre informazioni sulle raccolte siti con nome host.
Tabella: confronto tra raccolte siti con nome host e raccolte siti basate su percorso
| Raccolte siti con nome host | Raccolte siti basate su percorso | |
|---|---|---|
| Creazione di siti | È possibile usare Microsoft PowerShell per creare raccolte siti con nome host. Non è possibile usare Amministrazione centrale per creare raccolte siti con nome host. | Per creare raccolte siti basate su percorso è possibile usare Amministrazione centrale o PowerShell. |
| URL | A ogni raccolta siti con nome host in un'applicazione Web viene assegnato un nome DNS univoco. È possibile servirsi delle aree per assegnare fino a cinque URL ai siti con nome host, inclusi gli URL di reindirizzamento a microsito. |
Tutte le raccolte siti basate su percorso in un'applicazione Web condividono lo stesso nome host (nome DNS) dell'applicazione Web. È possibile estendere un'applicazione Web in modo da implementare fino a cinque aree, nonché creare nomi host diversi per ogni area. Il nome host di un'area, tuttavia, si applica a tutte le raccolte siti all'interno dell'applicazione Web. |
| Raccolta siti radice e ricerca | Una raccolta siti radice è necessaria per sottoporre a ricerca per indicizzazione il contenuto all'interno di un'applicazione Web. Una raccolta siti radice può essere una raccolta siti a cui gli utenti non possono accedere. | In genere, una singola raccolta siti basata su percorso svolge la funzione di raccolta siti radice all'interno di un'applicazione Web. È possibile usare i percorsi gestiti per creare altre raccolte siti all'interno dell'applicazione Web. |
| Mapping di URL | Usare i comandi di PowerShell per gestire gli URL (Set-SPSiteUrl, Remove-SPSiteUrl, Get-SPSiteUrl). |
Usare mapping di accesso alternativo per la gestione degli URL. |
| Creazione di siti in modalità self-service | Per le raccolte siti con nome host è necessario utilizzare una soluzione personalizzata per la creazione di siti in modalità self-service. La funzionalità Creazione siti self-service che fa parte dell'installazione predefinita di SharePoint Server non funziona con le raccolte siti denominate dall'host. |
Quando si usa la caratteristica di creazione siti in modalità self-service inclusa nell'installazione predefinita di SharePoint Server, vengono creati siti basati su percorso. |
| Percorsi gestiti | I percorsi gestiti per le raccolte siti con nome host si applicano a livello di farm e sono disponibili per tutte le applicazioni Web. Per creare percorsi gestiti per le raccolte siti con nome host è necessario utilizzare PowerShell. |
I percorsi gestiti per i siti basati su percorso si applicano a livello dell'applicazione Web. Per creare percorsi gestiti per le raccolte siti basate su percorso è possibile usare Amministrazione centrale o Microsoft PowerShell. |
Progettare e gestire gli URL per le raccolte siti con nome host
Tramite i cmdlet di PowerShell è possibile gestire i mapping di URL per le raccolte siti con nome host e mappare gli URL a una singola raccolta siti:
Set-SPSiteUrl— Aggiungere o modificare un mapping di URL per un sito.Remove-SPSiteUrl— Rimuovere un mapping di URL da un sito.Get-SPSiteUrl: vedere tutti gli URL e le zone associate per una raccolta siti.
Questi cmdlet offrono una funzionalità di mapping di URL per raccolte siti con nome host simile al mapping di accesso alternativo.
Aree e raccolte siti con nome host
Le raccolte siti con nome host sono disponibili in qualsiasi zona. Le raccolte siti con nome host non sono limitate all'area predefinita. Se necessario, è possibile implementare più zone e usare zone e raccolte siti con nome host per configurare impostazioni o criteri di autenticazione diversi.
Nota
Per usare zone diverse, è necessario estendere l'applicazione Web esistente nelle nuove zone.
È possibile assegnare un massimo di cinque URL a ogni singola raccolta siti, assegnando un URL per area. Anche se si segue l'architettura consigliata, implementando una sola area, è comunque possibile assegnare fino a cinque URL alle raccolte siti con nome host. Questo provisioning è dovuto al fatto che se una zona non viene implementata estendendo l'applicazione Web, SharePoint Server usa la zona predefinita.
Gli URL seguenti, ad esempio, possono consentire l'accesso allo stesso sito Internet:
L'account per la ricerca per indicizzazione deve poter accedere al contenuto tramite l'area predefinita usando l'autenticazione integrata di Windows (NTLM o Kerberos). Poiché l'autenticazione delle attestazioni consente più tipi di autenticazione in una zona, questo requisito non dovrebbe influire sugli altri requisiti di autenticazione.
Percorsi gestiti e raccolte siti con nome host
URL configurati per la stessa raccolta siti possono includere schemi e domini diversi, ma devono avere gli stessi percorsi gestiti e in particolare tutti gli elementi dopo '/' che seguono il dominio devono essere identici. Ad esempio, e http://www.Fabrikam.com/sites/Site1 possono puntare alla stessa raccolta siti, http://www.Contoso.com/sites/Site1 ma http://www.Contoso.com/sites/Site1http://www.bar.com/sites/Project1 e non possono.
I cmdlet per la gestione degli URL funzionano solo nella raccolta siti radice per un nome host, ad esempio http://www.Contoso.com. Questi cmdlet non funzionano in una raccolta siti del percorso gestito sottostante alla radice, ad http://www.Contoso.com/sites/Project1esempio . I siti all'interno della radice di una raccolta siti con nome host erediteranno le impostazioni relative agli URL di tale raccolta radice.
Terminazione SSL off-box con le raccolte siti con nome host
La terminazione SSL off-box si verifica quando un server proxy termina una richiesta SSL e la inoltra a un server Web tramite HTTP. Per ottenere la terminazione SSL off-box con le raccolte siti con nome host, il dispositivo che termina la connessione SSL, ad esempio un server proxy inverso, deve essere in grado di generare un'intestazione HTTP personalizzata, ovvero Front-End-Https: On. Per altre informazioni, vedere Usare raccolte siti con nome host con terminazione SSL predefinita.
La terminazione predefinita di SSL è supportata ma non consigliata perché comporta l'invio di traffico non crittografato dal server proxy al server Web.
Il protocollo usato per una raccolta siti denominata host dipende dal valore del parametro URL specificato quando si è usato il Set-SPSiteUrl cmdlet per eseguire il mapping dell'URL a una determinata zona: http o https. Verificare che i binding IIS per l'applicazione Web e i certificati SSL siano stati definiti e che la configurazione del proxy inverso e le altre operazioni di configurazione necessarie siano state completate.
Quando utilizzare raccolte siti basate su percorso
Usare le raccolte siti basate su percorsi tradizionali e il mapping di accesso alternativo se si applica una delle condizioni seguenti:
È necessario utilizzare la caratteristica di creazione siti in modalità self-service, inclusa nell'installazione predefinita di SharePoint Server.
Questa condizione non si applica alle soluzioni di creazione di siti self-service personalizzate.
La terminazione SSL è necessaria, ma il dispositivo di terminazione SSL non può essere configurato per produrre l'intestazione HTTP personalizzata necessaria.
È comunque possibile usare il bridging SSL con raccolte siti denominate dall'host con questi dispositivi se la terminazione SSL non è un requisito.
Si prevede di usare pool di applicazioni diversi per la sicurezza aggiuntiva fornita da questi gruppi o è necessario usare più gruppi proxy.
In questi casi è possibile usare raccolte siti con nome host. Tuttavia, la configurazione aggiuntiva necessaria per eseguire il mapping degli URL per le raccolte siti con nome host in più applicazioni Web supera notevolmente i vantaggi derivanti dall'uso di raccolte siti con nome host. Per altre informazioni, vedere Utilizzo di più applicazioni Web con raccolte siti con nome host. Per altre informazioni sulla creazione di raccolte siti basate su percorso, vedere Creare una raccolta siti in SharePoint Server.
Usare intestazioni host e raccolte siti con nome host
Le intestazioni host consentono al server Web di ospitare più siti Web nella stessa combinazione di indirizzo IP e porta. Se la richiesta HTTP in ingresso include un nome di intestazione host e un'intestazione host corrispondente è configurata in IIS, IIS risponderà con il contenuto del sito Web appropriato.
Le intestazioni host sono configurate a livello di applicazione Web (sito Web IIS), sono una delle proprietà delle associazioni di siti Web.
È importante comprendere la distinzione tra le intestazioni host in IIS e le raccolte siti con nome host. Le intestazioni host a livello di sito Web IIS sono destinate solo alle raccolte siti basate su percorso.
Quando si usano raccolte siti con nome host, SharePoint è responsabile della risoluzione del sito corretto per l'indirizzo in base alla richiesta in ingresso passata tramite IIS. Nella maggior parte dei casi, l'applicazione di un'associazione di intestazione host a livello di sito Web IIS rende impossibile accedere alle raccolte siti denominate dall'host tramite il sito Web IIS. Questa inaccessibilità è dovuta al fatto che IIS non risponde alle richieste di nomi host che differiscono dall'associazione dell'intestazione host.
È possibile usare un'associazione di intestazione host con caratteri jolly in IIS, ma è necessario assicurarsi che tutte le raccolte siti all'interno dell'applicazione Web siano conformi al modello di intestazione host con caratteri jolly.
Importante
Se in un'applicazione Web esistente è impostato un'associazione di intestazione host, IIS non restituirà pagine dalla raccolta siti denominata dall'host fino a quando non si rimuove l'associazione da IIS. Per altre informazioni, vedere Aggiornare l'URL e le associazioni IIS di un'applicazione Web per SharePoint Server.
Combinare raccolte siti con nome host e raccolte siti basate su percorso nella stessa applicazione Web
Le raccolte siti con nome host e quelle basate su percorso possono coesistere nella stessa applicazione Web. Per assicurarsi che entrambi i tipi di raccolte siti siano accessibili agli utenti, non inserire associazioni di intestazione host nel sito Web IIS dell'applicazione Web, inclusi i siti Web IIS per le zone estese dall'applicazione Web. Se in un'applicazione Web esistente è impostato un'associazione di intestazione host, IIS non restituirà pagine dalla raccolta siti denominata dall'host fino a quando non si rimuove l'associazione da IIS.
Siti personali
Quando si utilizzano entrambi i tipi di raccolte siti con Siti personali, valutare l'ipotesi di implementare un processo di provisioning personalizzato per creare i Siti personali come siti con nome host anziché come siti basati su percorso.
Distribuzione e configurazione delle raccolte siti con nome host
Creare un'applicazione Web per le raccolte siti con nome host
Se non si intende configurare due o più siti Web IIS che condividono lo stesso numero di porta nello stesso server, creare un'applicazione Web nell'area Predefinita. Non applicare un'associazione di intestazione host a livello di sito Web IIS.
Per creare un'applicazione Web per le raccolte siti con nome host
Verificare di essere membri dei ruoli e dei gruppi seguenti:
Ruolo predefinito del server securityadmin nell'istanza di SQL Server.
Ruolo predefinito del database db_owner in tutti i database da aggiornare.
Gruppo Administrators nel server in cui si esegue il cmdlet di Microsoft PowerShell.
Un amministratore può usare il
Add-SPShellAdmincmdlet per concedere le autorizzazioni per l'uso dei cmdlet di SharePoint Server.Nota
Se non si dispone delle autorizzazioni, contattare l'amministratore del programma di installazione o SQL Server amministratore per richiedere le autorizzazioni. Per altre informazioni sulle autorizzazioni di PowerShell, vedere Add-SPShellAdmin.
Aprire SharePoint Management Shell.
Al prompt dei comandi di PowerShell ,ovvero PS C:\>, digitare la sintassi seguente:
New-SPWebApplication -Name 'Contoso Sites' -port 80 -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'Contoso\JDoe') -AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)
Creare una raccolta siti radice
Una raccolta siti radice è un requisito per qualsiasi applicazione Web. È necessario anche per la ricerca per indicizzazione del contenuto. Questa raccolta siti deve avere lo stesso URL dell'applicazione Web. Attualmente SharePoint impedisce la creazione di una raccolta siti denominata host con lo stesso URL di un'applicazione Web. Di conseguenza, la raccolta siti radice viene creata come raccolta siti basata su percorso.
L'esempio seguente consente di creare una raccolta siti vuota con la funzione di raccolta siti radice:
New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'
Nell'origine contenuto compare solo la raccolta siti radice dell'applicazione Web. Anche se tutte le altre raccolte siti con nome host nell'applicazione Web non vengono visualizzate nell'origine di contenuto, per impostazione predefinita la ricerca per indicizzazione viene eseguita automaticamente nelle altre raccolte siti con nome host.
Creare raccolte siti con nome host
È necessario usare Microsoft PowerShell per creare una raccolta siti con nome host. Non è possibile usare l'applicazione Web Amministrazione centrale SharePoint Server per creare una raccolta siti denominata host, ma è possibile usare Amministrazione centrale per gestire la raccolta siti dopo averla creata.
È possibile creare una raccolta siti denominata host usando il cmdlet di Microsoft PowerShell New-SPSite con il parametro -HostHeaderWebApplication , come illustrato nell'esempio seguente:
Per creare raccolte siti con nome host:
Verificare di essere membri dei ruoli e dei gruppi seguenti:
Ruolo predefinito del server securityadmin nell'istanza di SQL Server.
Ruolo predefinito del database db_owner in tutti i database da aggiornare.
Gruppo Administrators nel server in cui si esegue il cmdlet di Microsoft PowerShell.
Un amministratore può usare il
Add-SPShellAdmincmdlet per concedere le autorizzazioni per l'uso dei cmdlet di SharePoint Server.Nota
Se non si dispone delle autorizzazioni, contattare l'amministratore del programma di installazione o SQL Server amministratore per richiedere le autorizzazioni. Per altre informazioni sulle autorizzazioni di PowerShell, vedere Add-SPShellAdmin.
Aprire SharePoint Management Shell.
Al prompt dei comandi di PowerShell ,ovvero PS C:\>, digitare la sintassi seguente:
New-SPSite 'http://portal.contoso.com' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Portal' -Description 'Customer root' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'Questa sintassi crea una raccolta siti denominata host con l'URL nell'applicazione https://portal.contoso.com Web SharePoint Server denominata "Contoso Sites".
Usare percorsi gestiti con le raccolte siti con nome host
È possibile implementare percorsi gestiti per le raccolte siti con nome host. I provider di servizi di hosting possono fornire allo stesso cliente più raccolte siti che condividono lo stesso nome host univoco del cliente, ma differenziate dal percorso URL dopo il nome host. I percorsi gestiti per le raccolte siti con nome host sono limitati a 20 per farm. Per altre informazioni, vedere Limiti e limiti software per SharePoint Server.
I percorsi gestiti per le raccolte siti con nome host hanno un comportamento diverso rispetto ai percorsi gestiti per le raccolte siti basate su percorso. I primi sono disponibili per tutte le raccolte siti con nome host all'interno della farm, indipendentemente dall'applicazione Web in cui queste si trovano. I percorsi gestiti per le raccolte siti basate su percorso, al contrario, si applicano solo ai siti all'interno della stessa applicazione Web. I percorsi gestiti per le raccolte siti basate su percorso non si applicano alle raccolte siti basate su percorso in altre applicazioni Web. I percorsi gestiti per un tipo di raccolta siti non si applicano all'altro tipo di raccolta siti.
Prima di creare un percorso gestito, è necessario creare una raccolta siti con l'URL di base desiderato. Ad esempio, per creare http://teams.contoso.com/finance è prima necessario creare la raccolta siti per http://teams.contoso.com.
Per creare un percorso gestito da usare con le raccolte siti con nome host, usare il cmdlet New-SPManagedPath di PowerShell con il parametro HostHeader, come illustrato nell'esempio seguente:
New-SPManagedPath 'departments' -HostHeader
È anche possibile usare il parametro Explicit per creare percorsi gestiti espliciti.
Nell'esempio seguente è illustrata una raccolta siti con nome host creata su un percorso gestito:
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'
Per rimuovere un percorso gestito esistente, utilizzare il cmdlet Remove -SPManagedPath di PowerShell, come illustrato nell'esempio seguente:
Remove-SPManagedPath 'departments' -HostHeader
Si può utilizzare PowerShell per rimuovere un percorso gestito anche se esiste una raccolta siti. Se si rimuove un percorso gestito, la raccolta siti non sarà più accessibile. Per accedere alla raccolta siti esistente, utilizzare PowerShell per ricreare il percorso gestito.
Mappare gli URL alle raccolte siti con nome host
Quando si crea una nuova raccolta siti nome host, i mapping di accesso alternativo predefiniti continueranno a esistere, ma non possono essere usati. Usare i comandi di PowerShell per gestire i mapping URL per le raccolte siti con nome host.
Aggiungere un mapping a un sito esistente:
Set-SPSiteUrl (Get-SPSite 'http://teams.contoso.com') -Url 'http://teamsites.contoso.com' -Zone Intranet
Ogni mapping di URL viene applicato a una singola area. Per il mapping degli URL, utilizzare uno dei nomi di area seguenti:
Predefinita
Intranet
Internet
Personalizzato
Extranet
Se non si specifica il parametro Zone e la voce di mapping URL è nuova, viene usata la zona predefinita. È ancora presente un limite di 5 URL per una raccolta siti univoci.
Rimuovere un mapping per un sito:
Remove-SPSiteUrl 'http://teamsites.contoso.com'
Visualizzare tutti i mapping di URL di un sito:
Get-SPSiteUrl -Identity (Get-SPSite 'http://teams.contoso.com')
Configurare certificati SSL per le raccolte siti con nome host
Importante
Se si usa SharePoint Server Subscription Edition, usare la nuova funzionalità di gestione dei certificati per installare e assegnare certificati SSL alle applicazioni Web. Questa funzionalità consente di installare e gestire i certificati SSL direttamente in SharePoint anziché configurare manualmente i certificati SSL in IIS.
È possibile configurare una singola applicazione Web che usa SSL e quindi creare più raccolte siti con nome host al suo interno. Per accedere a un sito su SSL è necessario installare un certificato server e assegnarlo al sito Web IIS. Ogni raccolta siti con nome host in un'applicazione Web condividerà l'unico certificato server assegnato al sito Web IIS.
È necessario acquisire un certificato con caratteri jolly o un certificato SAN (Subject Alternate Name) e quindi utilizzare una raccolta siti con nome host il cui formato URL corrisponda a quello del certificato. Ad esempio, se si acquisisce un certificato con caratteri jolly *.contoso.com, è necessario generare URL di raccolta siti con nome host, ad https://site1.contoso.comesempio , https://site2.contoso.come così via, per consentire a questi siti di passare la convalida SSL del browser. Tuttavia, se sono necessari nomi di dominio di livello secondario univoci per i siti, è necessario creare più applicazioni Web anziché più raccolte siti con nome host.
Per configurare SSL per le raccolte siti con nome host, abilitare SSL al momento della creazione dell'applicazione Web. Questa impostazione creerà un sito Web IIS con un'associazione SSL anziché un'associazione HTTP. Dopo aver creato l'applicazione Web, aprire Gestione IIS e assegnare un certificato a tale binding SSL. Sarà quindi possibile creare le raccolte siti nell'applicazione Web.
Se si implementano più zone con raccolte siti con nome host, assicurarsi che la configurazione di certificati e associazioni (SSL o HTTP) sia appropriata per ogni zona e sito IIS corrispondente.
Usare raccolte siti con nome host con terminazione SSL off-box
È possibile usare raccolte siti con nome host con terminazione SSL off-box. Per utilizzare la terminazione SSL con le raccolte siti con nome host sono previsti diversi requisiti:
Nota
La terminazione predefinita di SSL è supportata ma non consigliata perché comporta l'invio di traffico non crittografato dal server proxy al server Web.
Almeno un sito IIS deve disporre di un binding sulla porta 80 (o su qualsiasi porta alla quale il terminatore inoltra la richiesta). È consigliabile utilizzare il sito IIS di un'applicazione Web (o il sito IIS di un'area di un'applicazione Web) con HTTP/80.
Il terminatore SSL o il proxy inverso deve mantenere l'intestazione host HTTP originale del client.
Se la richiesta SSL del client viene inviata alla porta SSL predefinita (443), il terminatore SSL o il proxy inverso dovrà inoltrare la richiesta HTTP decrittografata al server Web front-end sulla porta HTTP predefinita (80). Se la richiesta SSL del client viene inviata a un porta SSL non predefinita, il terminatore SSL o il proxy inverso dovrà inoltrare la richiesta HTTP decrittografata al server Web front-end sulla stessa porta non predefinita.
Il dispositivo che termina la connessione SSL, ad esempio un server proxy inverso, deve essere in grado di generare un'intestazione HTTP personalizzata: Front-End-Https: On. Questa intestazione è la stessa intestazione personalizzata usata da Outlook Web Access (OWA): Front-End-Https: On/Off. Ulteriori informazioni su questa intestazione personalizzata sono disponibili più avanti in questa sezione.
Per utilizzare raccolte siti con nome host con terminazione SSL off-box, configurare l'applicazione Web normalmente come per la terminazione SSL e assicurarsi che soddisfi i requisiti sopra descritti. In questo scenario, SharePoint Server eseguirà il rendering dei collegamenti delle proprie raccolte siti con nome basato sull'host in tale applicazione Web utilizzando HTTPS anziché HTTP.
I server proxy inversi possono pubblicare raccolte siti con nome host di SharePoint Server ed eseguire la terminazione SSL off-box. In questo scenario, il server proxy inverso modifica il tipo di connessione tra l'utente finale e il server Web front-end di SharePoint da SSL/TLS a HTTP o viceversa. I server proxy inversi in questo scenario devono inserire un'intestazione HTTP aggiuntiva nella richiesta dell'utente quando inoltra la richiesta al server front-end Web di SharePoint. Questa intestazione HTTP aggiuntiva indica a SharePoint Server il tipo di connessione avviata dall'utente finale in modo che SharePoint Server esegua il rendering degli URL in modo appropriato nella risposta. Il nome dell'intestazione HTTP è "Front-End-Https" e i valori accettati sono descritti nella tabella seguente.
Tabella: valori dell'intestazione Front-End-Https
| Valore | Descrizione |
|---|---|
| Attivato | Il server proxy inverso ha ricevuto la richiesta dell'utente finale su una connessione HTTPS crittografata (SSL o TLS). Ad esempio, Front-End-Https: On. |
| Disattivato | Il server proxy inverso ha ricevuto la richiesta dell'utente finale su una connessione HTTP non crittografata. |
I valori non fanno distinzione tra maiuscole e minuscole. Ad esempio, sono accettabili, on, ON, On e oN.
Questa intestazione personalizzata funziona solo con raccolte siti con nome host. Non funziona con le raccolte siti basate su percorso.
Nell'esempio seguente è illustrata una raccolta siti con nome host creata su https:
New-SPSite 'https://portal.contoso.com' -HostHeaderWebApplication (Get-SPWebApplication 'Contoso Sites') -Name 'Portal' -OwnerAlias 'contoso\administrator' -language 1033 -Template 'STS#0'
In questo esempio viene creata una raccolta siti con nome host con l'URL https://portal.contoso.com nell'applicazione Web SharePoint Server con l'URL https://webapp.contoso.com.
Abilitare app in ambienti con più aree
Nota
Questa sezione si applica solo a SharePoint Server 2013.
L'aggiornamento pubblico di marzo 2013 consente di configurare un dominio app per ogni area di applicazione Web e di utilizzare una configurazione basata su mapping di accesso alternativo e applicazioni Web con intestazione host. Prima del rilascio dell'aggiornamento era possibile ospitare un solo dominio app, che doveva trovarsi nell'area predefinita. Non è possibile usare il dominio dell'app nei mapping di accesso alternativi o nelle configurazioni dell'applicazione Web host-header.
Per risolvere questo problema, applicare l'aggiornamento cumulativo di SharePoint Server del 12 marzo 2013. Vedere la pagina Aggiornamenti per SharePoint 2013.
Migrazione di raccolte siti basate su percorso in raccolte siti con nome host
Determinare la presenza di raccolte siti con nome host nelle applicazioni Web esistenti
È possibile usare lo script seguente per identificare quali raccolte siti esistenti sono basate sul percorso e quali sono denominate dall'host, quindi è possibile decidere se convertirne una da un tipo a un altro.
$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' }
}
Convertire le raccolte siti basate su percorso in raccolte siti con nome host
È possibile convertire raccolte siti basate su percorso in raccolte siti con nome host e raccolte siti con nome host in raccolte siti basate su percorso usando il cmdlet di PowerShell Set-SPSite. Dopo la ridenominazione del sito, è consigliabile eseguire il riciclo di un pool di app per forzare l'aggiornamento della cache. Non è possibile usare il sito Web amministrazione centrale SharePoint o Windows PowerShell cmdlet che collegano e scollegano o montare e smontare database del contenuto per convertire le raccolte siti.
L'esempio seguente consente di convertire una raccolta siti standard in una raccolta siti con nome host:
Get-SPSite https://SP2013content.contoso.com/sites/PathBasedSiteCollection|Set-SPSite -url https://HostNamedSiteCollection.contoso.com
Utilizzo di più applicazioni Web con raccolte siti con nome host
L'utilizzo di più applicazioni Web aggiunge complessità al sistema e crea un ulteriore sovraccarico operativo. È consigliabile utilizzare una sola applicazione Web per le raccolte siti. La scelta di implementare raccolte siti in più applicazioni Web può essere tuttavia influenzata dai motivi illustrati di seguito:
I criteri di sicurezza dell'organizzazione richiedono l'utilizzo di applicazioni Web o pool di applicazioni separati.
Le applicazioni Web devono essere configurate in modo diverso.
L'organizzazione richiede l'utilizzo di più gruppi proxy.
È più complesso implementare raccolte siti con nome host con più applicazioni Web in una farm perché è necessario completare più passaggi di configurazione. Ad esempio, gli URL con siti denominati dall'host possono essere distribuiti tra più applicazioni Web che condividono la stessa porta in una singola farm. Questo scenario richiede più passaggi di configurazione per garantire che le richieste vengano mappate alle applicazioni Web corrette. È necessario configurare manualmente i mapping in ogni server Web della farm configurando un indirizzo IP separato per rappresentare ogni applicazione Web. È anche necessario creare e gestire le associazioni host-header per assegnare indirizzi IP univoci per ogni sito. Gli script possono gestire e replicare questa configurazione tra i server; tuttavia, questa replica della configurazione aggiunge complessità alla soluzione. Ogni URL univoco richiede anche un mapping in DNS. In generale, se sono richieste più applicazioni Web, è consigliabile usare raccolte siti basate su percorso con mapping di accesso alternativo.
Importante
SharePoint Server Subscription Edition versione 23H1 consente agli utenti di assegnare associazioni di intestazione host con caratteri jolly alle applicazioni Web. Questa nuova funzionalità consente di usare più applicazioni Web con raccolte siti con nome host nei modi seguenti:
Gli utenti non devono più assegnare manualmente associazioni di indirizzi IP univoci alle applicazioni Web in ognuno dei server SharePoint. Gli utenti che eseguono SPSE versione 23H1 possono invece assegnare intestazioni host con caratteri jolly a ogni applicazione Web, operazione più semplice da gestire.
Le intestazioni host con caratteri jolly assegnate a ogni applicazione Web devono essere univoche. Ad esempio, l'applicazione Web 1 potrebbe essere
*.internal.example.com, l'applicazione Web 2 potrebbe essere*.external.example.come così via.Le raccolte siti con nome host in queste applicazioni Web dovranno essere conformi al modello di intestazione host con caratteri jolly dell'applicazione Web. Ad esempio, se un'applicazione Web ha un'intestazione host con caratteri jolly di
*.external.example.com, può ospitare raccolte siti con nome host con nomi DNS comesite1.external.example.com,site2.external.example.come così via.Le associazioni di intestazione host con caratteri jolly possono avere un solo carattere jolly come etichetta più a sinistra nel nome DNS. Ad esempio, un'intestazione host con caratteri jolly valida può essere
*.external.example.com, ma non può essereexternal.*.example.com,*.*.example.com,external*.example.com,*external.example.come così via.
Nelle due tabelle seguenti vengono confrontate le tre scelte di progettazione disponibili per l'implementazione delle raccolte siti. Le tabelle hanno lo scopo di illustrare le conseguenze di ogni approccio e le variazioni della configurazione in base all'architettura.
Tabella: risultati delle diverse scelte di progettazione per il provisioning di raccolte siti
| Raccolte siti con nome host con tutti i siti in una farm consolidati in una singola applicazione Web | Raccolte siti basate su percorso con mapping di accesso alternativo e più applicazioni Web | Raccolte siti con nome host con più applicazioni Web in una farm | |
|---|---|---|---|
| Provisioning di raccolte siti | Per il provisioning dei siti, utilizzare Microsoft PowerShell o una soluzione di provisioning di raccolte siti personalizzata. | Per la distribuzione dei siti, utilizzare Amministrazione centrale o Microsoft PowerShell. | Per il provisioning dei siti, utilizzare Microsoft PowerShell o una soluzione di provisioning di raccolte siti personalizzata. |
| Gestione degli URL | È possibile eseguire il mapping di tutte le raccolte siti in DNS in modo che puntino a un singolo indirizzo IP che rappresenta l'applicazione Web. | Se sono state implementate più aree, è necessario configurare il mapping di accesso alternativo per l'URL di ogni sito. Per ogni area è anche necessario un mapping in DNS. | È necessaria una configurazione aggiuntiva per garantire che le richieste per i siti che condividono la stessa porta vengano mappate all'applicazione Web corretta. Per ogni nome host univoco è anche necessario un mapping in DNS. Questa configurazione è manuale e deve essere completata in ogni server Web in una farm per ogni sito. |
| Altri URL | È possibile assegnare un massimo di cinque URL a una raccolta siti con nome host, una per area. Non è necessario estendere l'applicazione Web a più zone. Se non viene implementata una zona, viene usata la zona predefinita. | Il numero di URL per una raccolta siti è limitato a cinque perché il numero consentito di zone è cinque. | È possibile assegnare un massimo di cinque URL a una raccolta siti con nome host, una per area. Non è necessario estendere l'applicazione Web a più zone. Se non viene implementata una zona, viene usata la zona predefinita. |
| Applicazioni di servizio | Tutti i siti della farm utilizzano un singolo gruppo di applicazioni di servizio. | È possibile implementare gruppi di applicazioni di servizio personalizzati per applicazioni Web diverse. | È possibile implementare gruppi di applicazioni di servizio personalizzati per applicazioni Web diverse. |
| Aree | Non è necessario implementare più zone per implementare URL diversi per la stessa raccolta siti. Se non viene implementata una zona, viene usata la zona predefinita. | Sono necessarie aree per l'implementazione di URL diversi per la stessa raccolta siti. | Non è necessario implementare più zone per implementare URL diversi per la stessa raccolta siti. Se non viene implementata una zona, viene usata la zona predefinita. |
| Autenticazione | Con un'applicazione Web le opzioni di autenticazione sono limitate a cinque aree. È tuttavia possibile implementare molti metodi di autenticazione in un'area. | È possibile implementare progettazioni diverse di autenticazioni e aree per ogni applicazione Web. | È possibile implementare progettazioni diverse di autenticazioni e aree per ogni applicazione Web. |
| Autenticazione | Consente l'isolamento degli script client tra URL di dominio. | È possibile isolare le applicazioni Web in pool di applicazioni dedicati, se lo si desidera, per ottenere l'isolamento dei processi. Consente l'isolamento tra URL di dominio. |
È possibile isolare le applicazioni Web in pool di applicazioni dedicati, se lo si desidera, per ottenere l'isolamento dei processi. Consente l'isolamento tra URL di dominio. |
| Criteri | È possibile usare le aree per assegnare criteri diversi ai siti con nome host. | È possibile usare criteri a livello di applicazione Web per applicare le autorizzazioni, indipendentemente da quelle configurate per singoli siti e documenti. È inoltre possibile implementare criteri specifici per aree diverse. | È possibile implementare criteri specifici per applicazioni Web diverse per applicare le autorizzazioni, indipendentemente da quelle configurate per singoli siti o documenti. È inoltre possibile implementare criteri specifici per aree diverse. |
Tra i numeri relativi alla scalabilità che possono influire sulle decisioni di progettazione sono inclusi anche i numeri massimi consigliati per raccolte siti, database di contenuto e percorsi gestiti.
La tabella seguente contiene un riepilogo della configurazione necessaria per gestire gli URL in base a ognuna delle tre opzioni di progettazione presentate in questo articolo.
Tabella: configurazione necessaria per le diverse progettazioni di raccolte siti
| Raccolte siti con nome host con tutti i siti di una farm consolidati in una singola applicazione Web | Raccolte siti basate su percorso con mapping di accesso alternativo e più applicazioni Web | Raccolte siti con nome host con più applicazioni Web in una farm | |
|---|---|---|---|
| In SharePoint Server | Creare l'applicazione Web. Creare una raccolta siti radice non accessibile agli utenti, https://HNSC01.fabrikam.comad esempio . Creare le raccolte siti con nome host con l'intestazione host , https://intranet.fabrikam.comad esempio . Aggiungere altri URL per ogni raccolta siti e configurare le aree utilizzando Set-SPSiteUrl. Negli esempi di progettazione basati su portale aziendale questa operazione non è necessaria poiché è presente un'unica area. |
Creare l'applicazione Web con l'intestazione host , https://intranet.fabrikam.comad esempio . Facoltativo: configurare il mapping di accesso alternativo. Nell'esempio di progettazione non è necessario perché è presente una sola zona. Creare la raccolta siti basata sul percorso radice. |
Creare l'applicazione Web. Creare una raccolta siti radice non accessibile agli utenti, https://HNSC01.fabrikam.comad esempio . Creare le raccolte siti con nome host con l'intestazione host , https://intranet.fabrikam.comad esempio . Aggiungere altri URL per ogni raccolta siti e configurare le aree utilizzando Set-SPSiteUrl. Negli esempi di progettazione basati su portale aziendale questa operazione non è necessaria poiché è presente un'unica area. |
| In IIS | Associare un certificato SSL (certificato con caratteri jolly o certificato SAN) per tutti i siti con nome host (dominio) nell'applicazione Web. | Associare un certificato SSL in IIS per ogni area. Ogni area è un'applicazione Web distinta in IIS. | Associare un certificato SSL (certificato con caratteri jolly o certificato SAN) per un sito con nome host (dominio) nelle applicazioni Web. In ogni server Web nella farm e per ogni applicazione Web che condivide una porta: Configurare un indirizzo IP distinto che rappresenti ogni applicazione Web. Modificare manualmente l'associazione del sito Web IIS per rimuovere l'associazione di intestazione host creata al momento della creazione dell'applicazione Web e sostituire l'associazione con un'associazione di indirizzi IP. |
Se si usano più applicazioni Web in indirizzi IP diversi, potrebbe essere necessario completare la configurazione aggiuntiva per la scheda di interfaccia di rete, DNS e il servizio di bilanciamento del carico per ogni server.
Creare più applicazioni Web con raccolte siti con nome host
Per eseguire più applicazioni Web nello stesso server e sulla stessa porta, in combinazione con raccolte siti con nome host, è necessario assegnare indirizzi IP diversi alle applicazioni Web. Per questo tipo di architettura è necessario aggiungere indirizzi IP ai server Web e configurare il router in modo che i nomi host puntino agli indirizzi IP dell'applicazione Web corrispondente.
Nota
È possibile creare un'applicazione Web che non dispone di un'intestazione host. Se si crea un'applicazione Web che non dispone di un'intestazione host, non è possibile creare più applicazioni Web con raccolte siti con nome host nello stesso server Web.
Il processo che crea più applicazioni Web per una raccolta siti denominata host include le attività seguenti:
Creare le applicazioni Web.
Aggiungere un nuovo indirizzo IP virtuale in IIS in ogni server Web della farm.
Creare più applicazioni Web per raccolte siti con nome host
L'esempio seguente consente di creare un'applicazione Web:
New-SPWebApplication -Name 'webapp' 'webapp.contoso.com' -port 80 -ApplicationPool ContosoAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'Contoso\JDoe') -AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)
Ripetere questa attività per ogni applicazione Web.
Aggiungere indirizzi IP virtuali in IIS
I binding IP devono essere applicati in tutti i server che ospiteranno l'applicazione Web. Impostare il comando di sospensione (Sleep) su 60 secondi per assicurare che i binding IP vengano impostati in tutti i server della farm prima della rimozione dell'intestazione host esistente nell'applicazione Web. A questo scopo è possibile usare script remoti.
Usare i comandi seguenti per aggiungere binding IP univoci a ogni applicazione Web creata e quindi rimuovere il binding tra host e intestazioni da tali applicazioni 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