Architettura e distribuzione di raccolte siti con nome host in SharePoint Server

 

**Si applica a:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Ultima modifica dell'argomento:**2017-08-18

Riepilogo: informazioni su come pianificare e implementare raccolte siti con nome host in SharePoint 2013 e SharePoint Server 2016 e sul modo in cui le raccolte siti basate su percorso influiscono sull'ambiente esistente.

Le raccolte siti con nome host rappresentano il metodo consigliato per la distribuzione di siti in SharePoint Server. Poiché nell'ambiente di Office 365 vengono utilizzate le raccolte siti con nome host, le nuove caratteristiche sono ottimizzate per le raccolte siti di questo tipo, in modo da garantire una maggiore affidabilità. In questo articolo viene illustrato come pianificare e implementare raccolte siti con nome host, nonché progettare e gestire gli URL.

Contenuto dell'articolo:

• Architettura e progettazione delle raccolte siti con nome host

  • Architettura consigliata per le raccolte siti con nome host

  • Confronto tra raccolte siti con nome host e raccolte siti basate su percorso

  • Progettare e gestire gli URL per le raccolte siti con nome host

  • Quando utilizzare raccolte siti basate su percorso

  • Usare intestazioni host e raccolte siti con nome host

  • Combinare raccolte siti con nome host e raccolte siti basate su percorso nella stessa applicazione Web

• Distribuzione e configurazione delle raccolte siti con nome host

  • Creare un'applicazione Web per le raccolte siti con nome host

  • Creare una raccolta siti radice

  • Creare raccolte siti con nome host

  • Usare percorsi gestiti con le raccolte siti con nome host

  • Mappare gli URL alle raccolte siti con nome host

  • Configurare certificati SSL per le raccolte siti con nome host

  • Usare raccolte siti con nome host con terminazione SSL off-box

  • Abilitare app in ambienti con più aree

• 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

  • Convertire le raccolte siti basate su percorso in raccolte siti con nome host

• Utilizzo di più applicazioni Web con raccolte siti con nome host

  • Creare più applicazioni Web con raccolte siti con nome host

  • Creare più applicazioni Web per raccolte siti con nome host

  • Aggiungere indirizzi IP virtuali in IIS

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 utilizzando gli indirizzi http://TeamA.contoso.com e http://TeamB.contoso.com. In questo modo è possibile distribuire nella stessa applicazione Web più siti con nomi DNS univoci. I provider di servizi di hosting avranno inoltre la possibilità di adattare un ambiente a numerosi clienti. Se non si utilizzano raccolte siti con nome host, l'applicazione Web di SharePoint conterrà numerose raccolte siti basate su percorso che condividono lo stesso nome host (nome DNS). Ad esempio, il Team A disporrà di una raccolta siti all'indirizzo https://contoso.com/siti/teamA e il Team B disporrà di una raccolta siti all'indirizzo https://contoso.com/siti/teamB.

Se l'utilizzo di siti basati su percorso con mapping di accesso alternativo (descritto più avanti in questo articolo) non costituisce un requisito, è consigliabile utilizzare raccolte siti con nome host. 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 dei siti prevede di utilizzare raccolte siti con nome host con tutti i siti 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

• Una raccolta siti radice (http://webapp.contoso.com).

• Più raccolte siti con nome host per l'hosting di contenuti, con siti di esempio:

  • Contenuto dell'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 il Team 1, il Team 2 e il Team 3.

  • Siti personali con URL nel formato seguente: webapp.contoso.comhttp://my.contoso.com/personal/<nome_sito>.

Il numero di siti all'interno dell'applicazione Web e gli URL dei siti non hanno importanza nell'ambito di questo esempio.

Quando si crea un'applicazione Web per raccolte siti con nome host, l'URL dell'applicazione Web e della raccolta siti radice sarà http://< webapp.contoso.com>/.

Questa è l'architettura consigliata per la distribuzione dei siti perché corrisponde a quella usata nell'ambiente di Office 365 ed è quindi la più testata e affidabile. Le nuove caratteristiche, tra cui il modello di app e la gestione delle richieste, sono ottimizzate per questa configurazione.

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. Distribuendo più raccolte siti con nome host in una singola applicazione Web si aumenta la scalabilità della farm, in quanto non vengono utilizzate risorse per il supporto di 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, mentre non è possibile usare Amministrazione centrale per lo stesso scopo.	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. Può trattarsi di una raccolta siti non accessibile agli utenti.	In genere, una singola raccolta siti basata su percorso svolge la funzione di raccolta siti radice all'interno di un'applicazione Web. È possibile usare percorsi gestiti per creare raccolte siti aggiuntive nell'applicazione Web.
Mapping di URL	Usare i comandi di PowerShell per la gestione degli 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 caratteristica di creazione siti in modalità self-service inclusa nell'installazione predefinita di SharePoint Server non funziona con le raccolte siti con nome 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: aggiunge o modifica un mapping di URL per un sito.

• Remove-SPSiteUrl: rimuove un mapping di URL da un sito.

• Get-SPSiteUrl: visualizza tutti gli URL e le aree 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 tramite tutte le aree e non sono limitate all'area predefinita. Se necessario, è possibile implementare più aree e utilizzare le aree e le raccolte siti con nome host per configurare impostazioni o criteri di autenticazione diversi.

È 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. Ciò è dovuto al fatto che, se un'area non viene implementata estendendo l'applicazione Web, SharePoint Server utilizza l'area predefinita.

Gli URL seguenti, ad esempio, possono consentire l'accesso allo stesso sito Internet:

• www.Contoso.com

• www.Contoso.uk

• www.Contoso.ca

• www.Contoso.au

• www.Contoso.ie

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 basata sulle attestazioni consente più tipi di autenticazione in un'area, questo requisito non influisce su 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, https://www.Contoso.com/siti/Sito1 e http://www.Fabrikam.com/siti/Sito1 possono puntare entrambi alla stessa raccolta siti, ma https://www.Contoso.com/siti/Sito1 e http://www.bar.com/siti/Progetto1 non possono fare altrettanto.

I cmdlet per la gestione degli URL funzionano solo nella raccolta siti radice per un nome host, ad esempio https://www.Contoso.com. Questi cmdlet non funzionano su una raccolta siti con percorso gestito all'interno della radice, ad esempio https://www.Contoso.com/siti/Progetto1. 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 off-box più avanti in questo articolo.

Il protocollo utilizzato per una raccolta siti con nome host dipende dal valore del parametro relativo all'URL specificato quando si è utilizzato il cmdlet Set-SPSiteURL per mappare l'URL a una particolare area, ovvero 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

Anche se le raccolte siti con nome host sono consigliate per la maggior parte delle architetture, è opportuno utilizzare le raccolte siti basate su percorso tradizionali e il mapping di accesso alternativo quando si verifica una delle condizioni seguenti:

• È necessario utilizzare la caratteristica di creazione siti in modalità self-service, inclusa nell'installazione predefinita di SharePoint Server.

  Questa indicazione non si applica alle soluzioni di creazione siti in modalità self-service personalizzate.

• È necessaria la terminazione SSL, ma il dispositivo di terminazione SSL non può essere configurato per produrre l'intestazione HTTP personalizzata necessaria.

  È comunque possibile usare il bridging con le raccolte siti con nome host con tali dispositivi se la terminazione SSL non costituisce un requisito.

• Si intende utilizzare pool di applicazioni diversi per usufruire della maggiore sicurezza disponibile oppure è necessario utilizzare più gruppi proxy.

  In questi casi è possibile usare raccolte siti con nome host. Tuttavia, le ulteriori operazioni di configurazione necessarie per mappare gli URL per le raccolte siti con nome host tra più applicazioni Web superano di gran lunga i vantaggi offerti dall'utilizzo di raccolte siti con nome host. Per altre informazioni, vedere Usare 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 con la stessa combinazione di porta e indirizzo IP. Se la richiesta HTTP in arrivo include un nome di intestazione host e in IIS è configurata un'intestazione host corrispondente, IIS risponderà con il contenuto del sito Web appropriato.

Le intestazioni host vengono configurate a livello di applicazione Web (sito Web IIS) e sono una delle proprietà di binding dei siti Web.

È importante comprendere la distinzione tra intestazioni host in IIS e raccolte siti con nome host. Le intestazioni host a livello di sito Web IIS vengono usate solo per le raccolte siti basate su percorso.

Quando si usano raccolte siti con nome host, è SharePoint a risolvere il sito corretto per l'indirizzo sulla base della richiesta in arrivo passata tramite IIS. Nella maggior parte dei casi applicando un binding di intestazione host a livello di sito Web IIS diventa impossibile accedere a raccolte siti con nome basato sull'host tramite il sito Web IIS poiché IIS non risponde alle richieste di nomi host diversi dal binding di intestazione host.

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 assicurare che entrambi i tipi di raccolte siti siano accessibili agli utenti, non inserire binding tra host e intestazioni nel sito Web IIS dell'applicazione Web, compresi i siti Web IIS per aree estese dall'applicazione Web. Se un'applicazione Web esistente dispone di un binding tra host e intestazioni, IIS non restituirà pagine dalla raccolta siti con nome host finché non si rimuove il binding 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 prevede di 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 binding tra host e intestazioni a livello di sito Web IIS.

Per creare un'applicazione Web per le raccolte siti con nome host

1. 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ò utilizzare il cmdlet Add-SPShellAdmin per concedere le autorizzazioni per l'utilizzo dei cmdlet di SharePoint Server.

   Nota

   Se non si dispone delle autorizzazioni, richiederle all'amministratore dell'installazione o all'amministratore di SQL Server. Per altre informazioni sulle autorizzazioni di PowerShell, vedere Add-SPShellAdmin.

2. Aprire Management Shell di SharePoint.

3. 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 costituisce un requisito per qualsiasi applicazione Web ed è inoltre necessaria per la ricerca per indicizzazione del contenuto. L'URL della raccolta siti radice deve essere lo stesso dell'applicazione Web. Attualmente in SharePoint non è consentita la creazione di una raccolta siti con nome host con lo stesso URL di un'applicazione Web. Di conseguenza, la raccolta siti radice viene creata come una 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 compaiono nell'origine contenuto, la ricerca per indicizzazione nelle altre raccolte siti con nome host viene effettuata per impostazione predefinita.

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 di SharePoint Server per creare una raccolta siti con nome host, ma è possibile usare Amministrazione centrale per gestire la raccolta siti dopo averla creata.

È possibile creare una raccolta siti con nome host utilizzando il cmdlet New-SPSite di Microsoft PowerShell con il parametro -HostHeaderWebApplication, come illustrato nell'esempio seguente:

Per creare raccolte siti con nome host

1. 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ò utilizzare il cmdlet Add-SPShellAdmin per concedere le autorizzazioni per l'utilizzo dei cmdlet di SharePoint Server.

   Nota

   Se non si dispone delle autorizzazioni, richiederle all'amministratore dell'installazione o all'amministratore di SQL Server. Per altre informazioni sulle autorizzazioni di PowerShell, vedere Add-SPShellAdmin.

2. Aprire Management Shell di SharePoint.

3. 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'
   

In questo modo viene creata una raccolta siti con nome host con l'URL http://webapp.contoso.com nell'applicazione Web SharePoint Server con l'URL http://webapp.contoso.com.

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 Web application limits.

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*, bisogna prima 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 con nome host, il mapping di accesso alternativo predefinito continua ad esistere, ma non è possibile utilizzarlo. 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

• Custom

• Extranet

Se non si specifica il parametro Zone e la voce relativa al mapping di URL è nuova, verrà utilizzata l'area 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

È 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. Se ad esempio si acquisisce un certificato con caratteri jolly *.contoso.com, è necessario generare URL di raccolta siti con nome host URL del tipo https://sito1.contoso.com, https://sito2.contoso.com e così via, per consentire a questi siti di superare 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. In questo modo verrà creato un sito Web IIS con un binding SSL anziché un binding 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 stanno implementando più aree con raccolte siti con nome host, verificare che la configurazione dei certificati e dei binding (SSL o HTTP) sia appropriata per ogni area 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:

• 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. Si tratta della stessa intestazione personalizzata utilizzata in Outlook Web Access, ovvero 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 questa viene inoltrata al server Web front-end di SharePoint. Questa intestazione HTTP aggiuntiva indica a SharePoint Server il tipo di connessione avviata dall'utente finale, in modo che SharePoint Server possa eseguire correttamente il rendering degli URL 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
On	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.
Off	Il server proxy inverso ha ricevuto la richiesta dell'utente finale su una connessione HTTP non crittografata.

Per i valori non viene applicata la distinzione tra maiuscole e minuscole. Ad esempio, sono accettabili, on, ON, On e oN.

Questa intestazione personalizzata funziona solo con le raccolte siti con nome host e non con quelle 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 http://portal.contoso.com nell'applicazione Web SharePoint Server con l'URL http://webapp.contoso.com.

Abilitare app in ambienti con più aree

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 era possibile usare il dominio app in configurazioni basate su mapping di accesso alternativo o applicazioni Web con intestazione host.

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

Quando si esegue la migrazione da SharePoint Server 2010 a SharePoint Server, è consigliabile determinare la modalità di creazione dei siti di SharePoint Server 2010. Se sono stati creati come siti basati su percorso, valutare l'opportunità di eseguirne la migrazione in raccolte siti con nome host. Se sono stati implementati sia siti con nome host che siti basati su percorso, identificare i siti basati su percorso e valutare l'opportunità di eseguirne la migrazione in raccolte siti con nome host. A questo scopo, cercare il flag 'HostHeaderIsSiteName'.

L'esempio seguente consente di determinare se una data applicazione Web è stata creata come basata su percorso oppure con nome host:

$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 le raccolte siti basate su percorso in raccolte siti con nome host e viceversa. Per la conversione delle raccolte siti è necessario usare i cmdlet di backup e ripristino di PowerShell. Non è possibile usare per questo scopo il il sito Web Amministrazione centrale SharePoint o i cmdlet di PowerShell che consentono di collegare o scollegare i database del contenuto, o montare e smontare i database del contenuto.

L'esempio seguente consente di convertire una raccolta siti standard in una raccolta siti con nome host:

Backup-SPSite -Identity 'http://portalOld.contoso.com' -Path 'c:\Backup\portalContoso.bak' -Force -UseSQLSnapShot
Restore-SPSite -Identity 'http://portal.contoso.com' -Path 'c:\Backup\portalContoso.bak' -DatabaseName 'portal_content' -Force -HostHeaderWebApplication 'http://webapp.contoso.com' -Confirm:$false

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.

L'implementazione di raccolte siti con nome host con più applicazioni Web in una farm risulta più complessa poiché richiede l'esecuzione di operazioni di configurazione aggiuntive. È possibile, ad esempio, distribuire URL con siti con nome host tra più applicazioni Web che condividono la stessa porta in una singola farm. In questo scenario sono necessari più passaggi di configurazione per garantire il mapping delle richieste alle applicazioni Web corrette. È necessario configurare manualmente i mapping in ogni server Web nella farm tramite la configurazione di un indirizzo IP distinto per rappresentare ogni applicazione Web e quindi creare e gestire binding tra host e intestazioni per assegnare indirizzi IP univoci per ogni sito. Benché sia possibile usare script per gestire e replicare questa configurazione tra server, questa scelta ha l'effetto di rendere più complessa la soluzione. Per ogni URL univoco è inoltre necessario un mapping DNS. In generale, se la presenza di più applicazioni Web costituisce un requisito, è consigliabile utilizzare raccolte siti basate su percorso con il mapping di accesso alternativo.

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.	Sono necessarie operazioni di configurazione aggiuntive per garantire il mapping delle richieste di siti che condividono la stessa porta 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.
URL aggiuntivi	È 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ù aree. Se un'area non è implementata, verrà utilizzata quella predefinita.	Il numero di URL per una raccolta siti è limitato a cinque perché questo è il numero di aree consentito.	È 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ù aree. Se un'area non è implementata, verrà utilizzata quella 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	Per implementare URL diversi per la stessa raccolta siti non è necessario implementare più aree. Se un'area non è implementata, verrà utilizzata quella predefinita.	Sono necessarie aree per l'implementazione di URL diversi per la stessa raccolta siti.	Per implementare URL diversi per la stessa raccolta siti non è necessario implementare più aree. Se un'area non è implementata, verrà utilizzata quella 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, ad esempio https://HNSC01.fabrikam.com. Creare le raccolte siti con nome host con l'intestazione host, ad esempio https://intranet.fabrikam.com. 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, ad esempio https://intranet.fabrikam.com. Facoltativo: configurare il mapping di accesso alternativo. Nell'esempio di progettazione non è necessario perché è presente un'unica area. Creare la raccolta siti basata sul percorso radice.	Creare l'applicazione Web. Creare una raccolta siti radice non accessibile agli utenti, ad esempio https://HNSC01.fabrikam.com. Creare le raccolte siti con nome host con l'intestazione host, ad esempio https://intranet.fabrikam.com. 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 il binding dei siti Web IIS per rimuovere il binding tra host e intestazioni definito alla creazione dell'applicazione Web e sostituirlo con un binding di indirizzo IP.

Se si utilizzano più applicazioni Web su indirizzi IP diversi, può essere necessario eseguire operazioni di configurazione aggiuntive per la scheda NIC, il DNS e il servizio di bilanciamento del carico di 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.

La procedura per la creazione di più applicazioni Web per raccolte siti con nome 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

See also

Pianificare architetture logiche per SharePoint Server

Get-SPSiteUrl
Set-SPSiteUrl
Remove-SPSiteUrl