Esempi di progettazione di SharePoint Server: siti per portale aziendale ed Extranet

2023-03-08

SI APPLICA A: yes-img-13 2013 yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

In questo articolo vengono presentati diversi esempi di progettazione che è possibile usare come architetture di partenza per i siti di SharePoint. Negli esempi di progettazione descritti in questo articolo vengono illustrate le architetture standard per i tipi più comuni di siti di SharePoint distribuiti in una società o un'organizzazione.

Importante

[!IMPORTANTE] Le informazioni contenute in questo articolo si applicano a SharePoint Foundation 2013 e SharePoint Server. Negli articoli, tuttavia, vengono trattate alcune caratteristiche, come i siti personali e Ricerca contenuti organizzazione, non disponibili in SharePoint Foundation 2013.

Informazioni sugli esempi di progettazione

In questo articolo vengono descritti gli esempi di progettazione seguenti:

Negli esempi di progettazione vengono illustrati i siti per una società fittizia denominata Fabrikam, Inc. Gli esempi di progettazione possono essere applicati quasi a tutti i componenti dell'architettura logica e descrivono il modo in cui i componenti sono integrati nella progettazione generale. In questo articolo vengono illustrati gli obiettivi di progettazione e il modo in cui i componenti dell'architettura logica presentati negli esempi consentono di realizzarli.

Nota

I modelli che presentano SharePoint 2013 nel titolo, valgono anche per SharePoint Server 2016

Esempio di progettazione basato su portale aziendale, due versioni

Le raccolte siti con nome host in SharePoint Server offrono gestione degli URL e scalabilità dei siti in una singola applicazione Web. Nelle due versioni dell'esempio di progettazione basato su portale aziendale vengono illustrate implementazioni che utilizzano le tradizionali raccolte siti basate su percorso o con nome host. Entrambi gli esempi di progettazione utilizzano l'autenticazione basata sulle attestazioni con una singola area. Gli esempi vengono ulteriormente approfonditi più avanti in questo articolo.

È consigliabile usare la progettazione basata su raccolte siti con nome host a meno che i requisiti non indichino la necessità di siti basati su percorso con mapping di accesso alternativo (per altre informazioni, vedere Host-named site collection architecture and deployment (SharePoint 2013)). Questa progettazione è consigliata perché è la stessa architettura usata dall'ambiente Microsoft 365. Di conseguenza, questa è la configurazione più testata. Di conseguenza, questa è la configurazione che risulterà più affidabile in futuro.

Extranet con aree dedicate per l'autenticazione

L'esempio di progettazione Extranet with Dedicated Zones for Authentication include solo il sito Web partner. Fornisce una configurazione alternativa per la collaborazione con i partner in cui vengono usate zone dedicate per ogni metodo di autenticazione. Ogni esempio di progettazione usa l'autenticazione in modalità attestazioni per le applicazioni Web. La differenza tra gli esempi di progettazione del portale aziendale e l'esempio di progettazione Extranet è la modalità di configurazione delle zone. L'esempio di progettazione Extranet con zone dedicate per l'autenticazione usa più zone e un metodo di autenticazione è configurato per ogni zona. Gli esempi di progettazione del portale aziendale usano una zona e sono configurati più metodi di autenticazione per classi di utenti diverse.

Nell'esempio di progettazione basato su rete Extranet con aree dedicate per l'autenticazione è incluso un nuovo metodo consigliato per l'accesso dei dipendenti remoti, ovvero l'accesso diretto con Windows Server 2012. Un'alternativa a questo metodo consigliato consiste nel creare una rete privata virtuale (VPN). Se lo si desidera, è anche possibile usare l'autenticazione basata su moduli per il prodotto firewall o gateway per la raccolta e l'inoltro delle credenziali.

Modalità di implementazione delle raccolte siti negli esempi di progettazione

Mentre nelle versioni precedenti dell'esempio di progettazione basato su portale aziendale vengono utilizzate raccolte siti basate su percorso, in quelle successive sono consigliate le raccolte siti con nome host, a meno che i requisiti non richiedano i tradizionali siti basati su percorso con mapping di accesso alternativo. Ciò influisce sugli esempi di progettazione nei modi seguenti:

Portale aziendale con raccolte siti basate su percorso: in questo esempio vengono illustrate le raccolte siti basate su percorso tradizionali, in cui i siti sono organizzati in applicazioni Web dedicate e una singola raccolta siti principale per ogni applicazione Web. Utilizzare questo approccio se si desidera ottenere la sicurezza aggiuntiva offerta dalla presenza di più app Web con pool di app distinti.
Portale aziendale con raccolte siti con nome host: in questo esempio viene illustrato l'utilizzo delle raccolte siti con nome host, in cui tutti i siti sono distribuiti in una singola applicazione Web nella farm. Questo metodo offre scalabilità elevata e maggiore flessibilità nella gestione degli URL.
Extranet con zone dedicate per l'autenticazione: questo esempio illustra molti siti di progetto di primo livello con URL vanity usando siti denominati dall'host per ogni sito di progetto (invece di organizzare siti di progetto sotto una raccolta siti di primo livello). Un vantaggio dell'uso di raccolte siti denominate dall'host in questo modo consiste nel creare un isolamento aggiuntivo tra gli URL di dominio, che potrebbe essere desiderato in una soluzione di collaborazione con i partner. Tuttavia, il compromesso di questo approccio è costituito dai costi aggiuntivi della gestione di un numero maggiore di nomi host, inclusa la gestione dei certificati SSL. Inoltre, se viene usata l'autenticazione SAML, è necessaria una configurazione aggiuntiva (vedere "Uso dell'autenticazione SAML con siti denominati dall'host" più avanti in questo articolo).

Autenticazione basata sulle attestazioni per SharePoint Server

Il funzionamento dell'autenticazione per SharePoint Server può influire sulle decisioni di progettazione correlate alle scelte di implementazione rappresentate da questi esempi di progettazione. Di seguito vengono descritti alcuni esempi:

In SharePoint Server l'autenticazione basata sulle attestazioni è la modalità predefinita e l'unica opzione disponibile tramite Amministrazione centrale. L'autenticazione in modalità classica può essere implementata utilizzando PowerShell.
In SharePoint Server non è necessario configurare l'affinità del server nel servizio di bilanciamento del carico per l'utilizzo dell'autenticazione basata sulle attestazioni SAML. SharePoint Server offre supporto completo per il bilanciamento del carico senza affinità.

In SharePoint Server l'account per la ricerca per indicizzazione deve poter accedere al contenuto tramite l'area predefinita utilizzando 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.

Riepilogo delle caratteristiche degli esempi di progettazione

La tabella seguente contiene un riepilogo dei tre esempi di progettazione trattati in questo articolo.

Tabella: riepilogo degli esempi di progettazione

Esempio di progettazione	Include	Principali elementi di progettazione
Portale aziendale con siti basati su percorso	Tipi di siti più comuni distribuiti in un'organizzazione.	Raccolte siti basate su percorso Autenticazione basata sulle attestazioni Più provider di autenticazione e tipi di autenticazione implementati in una singola area
Portale aziendale con siti con nome host	Tipi di siti più comuni distribuiti in un'organizzazione.	Raccolte siti con nome host Autenticazione basata sulle attestazioni Più provider di autenticazione e tipi di autenticazione implementati in una singola area
Extranet con aree dedicate per l'autenticazione	Solo il sito Web di partner. Offre una configurazione alternativa per la collaborazione con i partner.	Raccolte siti con nome host Autenticazione basata sulle attestazioni Aree diverse per ogni metodo di autenticazione

Siti inclusi negli esempi di progettazione

In questa sezione vengono descritti i siti principali inclusi negli esempi di progettazione.

Siti Intranet

Il portale aziendale include i siti seguenti per l'utilizzo della rete Intranet:

Contenuto dell'Intranet pubblicato (ad esempio HRweb)
Siti per la collaborazione in team
Siti personali

Insieme, questi sono i contenuti e i siti di collaborazione che i dipendenti usano quotidianamente. Singolarmente, ognuna di queste applicazioni rappresenta un tipo distinto di contenuto. Ogni tipo di contenuto ha le proprietà seguenti:

Enfatizza le diverse funzionalità di SharePoint Server.
Ospita dati con caratteristiche differenti.
È soggetta a un diverso profilo di utilizzo.
Richiede una diversa strategia di gestione delle autorizzazioni.

Di conseguenza, le scelte di progettazione per ognuna di queste applicazioni sono volte a ottimizzare le prestazioni e la sicurezza della specifica applicazione.

La progettazione delle applicazioni di servizio riunisce queste tre applicazioni per offrire le caratteristiche seguenti:

Ricerca contenuti nell'organizzazione
Dati di profilo condivisi e metadati aziendali

Nella figura seguente, tratta dall'esempio di progettazione basato su portale aziendale con raccolte siti basate su percorso, vengono illustrati i tre tipi di siti che costituiscono la rete Intranet aziendale.

Tipi di siti che costituiscono la rete Intranet aziendale

Siti Intranet

Applicazione Web di partner

L'applicazione Web di partner ospita siti disponibili esternamente per garantire una collaborazione sicura con le società partner e i singoli partner. Questa applicazione è concepita per consentire ai dipendenti di creare facilmente siti per la collaborazione sicura. I partner non possono accedere ad altri tipi di contenuto ospitato dalla server farm. La progettazione per le aree e le applicazioni di servizio mira a raggiungere questo obiettivo. Singoli proprietari dei siti, inoltre, gestiscono le autorizzazioni per i siti, invitando a collaborare solo i partecipanti necessari.

Nell'esempio di progettazione basato su rete Extranet, si tratta dell'unico tipo di sito rappresentato.

Obiettivi generali di progettazione

Gli esempi di progettazione offrono le implementazioni pratiche delle caratteristiche di SharePoint Server in vari tipi comuni di siti. Le implementazioni di progettazione per le singole applicazioni vengono esaminate in questo articolo. Di seguito vengono indicati i principali obiettivi di progettazione per gli esempi di progettazione:

Creare un framework per progettare un ambiente potenzialmente in grado di crescere.

Le decisioni di progettazione per singoli tipi di siti non impediscono l'aggiunta di altri tipi di siti. Una distribuzione iniziale, ad esempio, può includere solo i siti per la collaborazione in team o solo i tre tipi di siti che costituiscono una rete Intranet (siti di team, siti personali e contenuto Intranet pubblicato). Se si utilizza una progettazione dell'architettura logica di questo tipo, è possibile aggiungere siti alla soluzione senza influire sulla progettazione della soluzione iniziale. In altri termini, la progettazione non include scelte che limitano l'utilizzo dell'ambiente.
Consentire l'accesso a vari gruppi di utenti senza compromettere la sicurezza del contenuto nei diversi tipi di siti.

Utenti di diverse aree di rete (sia interne che esterne) che utilizzano provider di autenticazione diversi possono partecipare alla collaborazione. Gli utenti possono inoltre accedere solo al contenuto che li riguarda. Tramite questo tipo di progettazione dell'architettura logica è possibile offrire l'accesso a utenti che si trovano in più posizioni e che hanno obiettivi diversi. La progettazione iniziale, ad esempio, può essere destinata solo all'accesso dei dipendenti interni. Se, tuttavia, si utilizza una progettazione simile, è anche possibile consentire l'accesso ai dipendenti remoti, ai dipendenti dei partner, alle società partner e ai clienti.
Verificare che la progettazione possa essere utilizzata in un ambiente Extranet.

Adottare con attenzione le scelte di progettazione in modo da garantire che la soluzione possa essere distribuita in modo sicuro in una rete perimetrale.

Nella parte restante di questo articolo vengono descritti i singoli componenti logici che sono presenti nell'esempio di progettazione (dall'alto verso il basso) e vengono esaminate le scelte di progettazione applicate all'esempio. Lo scopo di questo approccio è dimostrare i diversi modi in cui è possibile configurare i componenti dell'architettura logica in base all'applicazione.

Server farm

In questa sezione vengono descritte le topologie delle server farm illustrate nell'esempio di progettazione e la scalabilità a più di una farm.

Topologia delle server farm

Ogni server farm nell'esempio di progettazione è costituita da sei server con la topologia a tolleranza di errore seguente:

Due server Web front-end
Due server applicazioni
Due server di database con SQL Server installato e configurato per supportare il clustering, il mirroring o Always On di SQL Server. Always On richiede SQL Server 2012.

Il concetto di front-end e server applicazioni è diverso in SharePoint Server 2016. Vedere Panoramica dei ruoli del server MinRole in SharePoint Server

Nell'esempio di progettazione viene illustrata l'architettura logica di SharePoint Server considerando quanto segue:

Viene eseguito il mirroring di tutti i siti nei server Web front-end.
Il sito di Amministrazione centrale viene installato in un server applicazioni per proteggerlo dall'accesso utente diretto.

In realtà, il numero di computer server e la topologia della server farm non sono importanti per l'architettura logica ai soli fini dell'aumento della capacità e del miglioramento delle prestazioni. È possibile progettare l'architettura logica in modo indipendente dalla topologia della server farm. Il processo di pianificazione delle prestazioni e della capacità consente di definire le dimensioni della server farm per soddisfare gli obiettivi di prestazioni e capacità. Per altre informazioni, vedere Pianificare le prestazioni di pianificazione in SharePoint Server 2013.

Utenti, aree e autenticazione

Le attestazioni costituiscono la modalità di autenticazione predefinita in SharePoint Server; inoltre, in ogni esempio di progettazione è inclusa l'autenticazione basata su attestazioni. È possibile usare Windows PowerShell per implementare l'autenticazione in modalità classica, anche se alcune caratteristiche di SharePoint Server non sono disponibili in questa modalità. Per altre informazioni sugli esempi di progettazione che includono l'autenticazione in modalità classica, vedere Esempio di progettazione: distribuzione aziendale (SharePoint Server 2010)

Nella tabella seguente sono elencate le differenze tra i due approcci rappresentati dall'esempio di progettazione basato su portale aziendale e quello basato su rete Extranet.

Tabella: confronto tra gli approcci per le configurazioni delle aree negli esempi di progettazione

Approccio	Portale aziendale con siti con nome host e portale aziendale con siti basati su percorso	Extranet con aree dedicate per l'autenticazione
Modalità di autenticazione	Attestazioni	Attestazioni
Configurazione delle aree	Un'area con più metodi di autenticazione configurati per diverse classi di utenti.	Più aree con un metodo di autenticazione configurato per ogni area.
URL	Tutte le classi di utenti utilizzano lo stesso URL per ogni sito. I dipendenti utilizzano lo stesso URL sia che si trovino all'interno della rete aziendale sia che lavorino in remoto.	Ogni classe di utenti utilizza un URL diverso per accedere a un sito. I dipendenti utilizzano un URL diverso a seconda che si trovino all'interno della rete aziendale o che lavorino in remoto.
Richieste interne	Le richieste avviate all'interno della rete aziendale vengono indirizzate esternamente alla rete e quindi di nuovo all'interno tramite il server gateway o proxy. Tali richieste vengono protette utilizzando il protocollo Secure Sockets Layer (SSL). In alternativa, è possibile usare un ambiente DNS diviso per indirizzare le richieste direttamente all'interfaccia interna per i server.	Le richieste avviate all'interno della rete aziendale restano interne alla rete.
Esperienza utente	A tutti gli utenti viene richiesto di scegliere il tipo di account utilizzato per accedere.	Il metodo di autenticazione è predeterminato. Gli utenti non devono selezionare il tipo di account utilizzando una pagina di accesso.

Nelle sezioni seguenti viene descritta in particolare l'integrazione dell'autenticazione quando si utilizzano i due diversi approcci.

Esempio di progettazione basato su rete Extranet con aree dedicate

Nell'esempio di progettazione basato su rete Extranet vengono illustrate tre diverse classi di utenti, a ciascuna delle quali è assegnata un'area diversa. In ogni applicazione Web è possibile creare fino a cinque aree utilizzando uno dei nomi di area disponibili, ovvero Predefinita, Intranet, Internet, Personalizzata o Extranet. L'account per la ricerca per indicizzazione deve poter accedere all'area predefinita utilizzando l'autenticazione integrata di Windows (NTLM o protocollo Kerberos), cui si fa riferimento nell'esempio di progettazione. Nella tabella seguente viene illustrata la configurazione delle aree nell'esempio di progettazione basato su rete Extranet.

Tabella: aree, utenti e tipo di autenticazione necessari nell'esempio di progettazione basato su rete Extranet.

Area	Utenti	Autenticazione
Intranet	Dipendenti interni e remoti Account per la ricerca per indicizzazione	NTLM o protocollo Kerberos Dipendenti remoti che utilizzano accesso diretto o una rete VPN per connettersi.
Predefinita	Singoli partner	Opzioni: Directory LDAP con autenticazione basata su moduli Foresta di Servizi di dominio Active Directory esterna con un trust unidirezionale alla foresta interna e autenticazione integrata di Windows Provider di identità attendibile con autenticazione SAML
Extranet	Società partner	Provider di identità di partner attendibile con autenticazione SAML

Esempi di progettazione basati su un portale aziendale

L'autenticazione basata sulle attestazioni consente più tipi di autenticazione nella stessa area. Le due versioni dell'esempio di progettazione basato su portale aziendale utilizzano l'area predefinita per tutti i tipi di autenticazione.

Nella tabella seguente vengono illustrati le aree, gli utenti e i tipi di autenticazione necessari negli esempi di progettazione.

Tabella: aree, utenti e autenticazione per gli esempi di progettazione basati su portale aziendale

Area	Utenti	Provider e tipo di autenticazione
Predefinita	Dipendenti interni e remoti	Servizi di dominio Active Directory o archivio LDAP con autenticazione basata su moduli o autenticazione SAML.
Predefinita	Singoli partner	Provider di identità attendibile con autenticazione SAML o database di SQL Server con autenticazione basata su moduli
Predefinita	Società partner	Provider di identità di partner attendibile con autenticazione SAML
Predefinita	Account per la ricerca per indicizzazione	Servizi di dominio Active Directory con autenticazione NTLM di Windows

Nell'esempio di progettazione il sito del contenuto Intranet pubblicato, i siti di team e i siti personali sono accessibili solo ai dipendenti interni o esterni alla rete. Nell'esempio di progettazione viene implemento un solo URL (utilizzando SSL) per ciascuno di tali siti, che può essere utilizzato sia internamente che esternamente. Vengono utilizzati account Servizi di dominio Active Directory. Se necessario, l'autenticazione basata su moduli o SAML può utilizzare LDAP e questo può richiedere l'esecuzione di operazioni di configurazione aggiuntive.

Nell'esempio di progettazione l'applicazione Web di partner rappresenta un sito Extranet a cui possono accedere i dipendenti dei partner e le società partner. Per l'autenticazione in questo scenario, è necessario configurare una relazione di trust con uno o più provider di identità esterni. È possibile usare uno degli approcci seguenti:

È possibile configurare la farm di SharePoint perché consideri attendibile un provider di identità esterno, ad esempio il provider che risiede in una società partner (per l'autenticazione diretta in base alla directory del partner).
È possibile configurare il provider di identità nell'ambiente aziendale perché consideri attendibile un provider di identità esterno. Gli amministratori nelle due organizzazioni devono stabilire questa relazione in modo esplicito. In questo scenario la farm di SharePoint considera attendibile il provider di identità proveniente dal proprio ambiente aziendale. Quando il provider di identità invia un token, la farm utilizza il certificato per la firma di token specificato quando è stata stabilita la relazione di trust per confermare la validità del token. Questo approccio è quello consigliato.

L'autenticazione basata su moduli è un'alternativa all'ambiente basato sulle attestazioni per l'autenticazione dei partner. Per gestire questi account, è necessario utilizzare un archivio separato, ad esempio un database.

Aree

Quando si progettano zone, diverse decisioni chiave sono fondamentali per il successo della distribuzione. Queste decisioni includono decisioni di progettazione e configurazione per le zone seguenti:

Area predefinita
Aree per l'accesso esterno

Nelle sezioni seguenti sono descritte le decisioni incorporate nell'esempio di progettazione.

Requisiti di configurazione dell'area predefinita

L'area che richiede maggiore attenzione è l'area predefinita. In SharePoint Server sono necessari i requisiti seguenti per la configurazione dell'area predefinita:

Quando la richiesta di un utente non può essere associata a un'area vengono applicati l'autenticazione e i criteri di tale area. Di conseguenza, l'area predefinita deve essere la più sicura.
Messaggi di posta elettronica amministrativi contengono collegamenti dall'area predefinita. Tali messaggi comprendono messaggi ai proprietari dei siti che stanno raggiungendo i limiti di quota. Di conseguenza, gli utenti che ricevono questo tipo di messaggi e avvisi devono poter accedere ai collegamenti tramite l'area predefinita. Questo è particolarmente importante per i proprietari dei siti.

In SharePoint Server è possibile accedere alle raccolte siti con nome host da qualsiasi area.

Configurazione di aree per un ambiente Extranet

In un ambiente Extranet la progettazione delle aree è importante per i due motivi seguenti:

Le richieste degli utenti possono essere avviate da numerose reti diverse. Negli esempi di progettazione gli utenti avviano le richieste dalla rete interna, da Internet e dalle società partner.
Gli utenti utilizzano contenuto in più applicazioni Web. Nell'esempio di progettazione la rete Intranet è costituita da tre diverse applicazioni Web. I dipendenti interni e remoti possono inoltre contribuire al contenuto Intranet e amministrarlo nell'applicazione Web di partner.

Se un ambiente Extranet include più di un'area, accertarsi di seguire i principi di progettazione seguenti:

Configurare le aree in più applicazioni Web in modo da consentirne il mirroring reciproco. La configurazione dell'autenticazione e gli utenti previsti devono corrispondere. I criteri associati alle aree possono tuttavia differire tra le applicazioni Web. Assicurarsi, ad esempio, che l'area Intranet venga utilizzata per gli stessi dipendenti in tutte le applicazioni Web. In altri termini, non configurare l'area Intranet per i dipendenti interni in un'applicazione Web e per i dipendenti remoti in un'altra.
Se si utilizzano raccolte siti basate su percorso, configurare i mapping di accesso alternativo in modo corretto e accurato per ogni area e risorsa. I mapping di accesso alternativo vengono creati automaticamente quando si crea un'area. È tuttavia possibile configurare SharePoint Server per la ricerca per indicizzazione di contenuto in risorse esterne, ad esempio una condivisione di file. I collegamenti a tali risorse esterne devono essere creati manualmente per ogni area utilizzando i mapping di accesso alternativo.
Se si utilizzano raccolte siti con nome host, assicurarsi di utilizzare PowerShell per eseguire il mapping degli URL alle aree appropriate

Se non si esegue il mirroring tra le aree delle applicazioni Web e i collegamenti alle risorse esterne non sono appropriati, esistono i rischi seguenti:

I nomi dei server, i nomi DNS e gli indirizzi IP possono essere esposti all'esterno della rete interna.
Gli utenti potrebbero non essere in grado di accedere ai siti Web e ad altre risorse.

Utilizzo dell'autenticazione SAML con siti con nome host

Se una progettazione prevede l'utilizzo dell'autenticazione SAML con siti con nome host, per ogni URL di reindirizzamento a microsito sono necessari gli elementi seguenti:

Una nuova area di autenticazione in SPTrustedIdentityTokenIssuer
Una relying party corrispondente nel provider di identità.

Servizi

Le architetture del servizio variano a seconda dell'esempio di progettazione. L'esempio di progettazione Portale aziendale con siti con nome host include l'architettura più semplice per i servizi. Questo perché usa un'applicazione Web, che può contenere un solo gruppo di applicazioni di servizio (noto anche come gruppo proxy).

L'esempio basato su portale aziendale con siti basati su percorso utilizza servizi partizionati per i siti di partner per isolare dati tra progetti. Questo esempio di progettazione integra due gruppi di servizi, uno per i siti Intranet e uno per i siti di collaborazione con i partner. Vengono distribuite istanze separate dei servizi metadati gestiti e di ricerca per i siti di partner e tali servizi sono partizionati. Per i servizi partizionati è necessario il servizio impostazioni di sottoscrizione, che può essere distribuito solo tramite PowerShell.

Architettura dei servizi per il portale aziendale con siti basati su percorso

Architettura dei servizi

La distribuzione di servizi partizionati aggiunge complessità all'architettura e rende difficile eseguire la migrazione dei siti a Microsoft 365 in un secondo momento. Un'opzione più semplice per i siti di partner consiste nel distribuire istanze dedicate ma non partizionate del servizio metadati gestiti e del servizio di ricerca se questi devono essere separati. Molte organizzazioni utilizzano la caratteristica di limitazione per motivi di sicurezza del servizio di ricerca anziché distribuire istanze dedicate del servizio di ricerca.

L'esempio di progettazione basato su rete Extranet include solo un gruppo proxy, ma utilizza anche servizi partizionati per le applicazioni di servizio metadati gestiti e di ricerca.

La decisione di progettazione principale per la distribuzione di applicazioni di servizio è l'ampia diffusione della tassonomia dell'organizzazione. Per semplificare l'architettura dei servizi, condividere metadati gestiti, profilo utente e ricerca in tutte le app Web e affidarsi alla limitazione della sicurezza per gestire l'accesso al contenuto. Nell'esempio di progettazione Portale aziendale con siti basati su percorso, un'istanza del servizio Metadati gestiti viene condivisa tra tutti i siti. Tuttavia, tutti gli utenti possono accedere alla tassonomia aziendale con questa configurazione. Gli architetti di soluzioni devono decidere se implementare più istanze del servizio Metadati gestiti. Dovranno anche decidere in che modo condividere i dati del profilo utente.

Nell'esempio basato su portale aziendale con raccolte siti basate su percorso il sito Web di partner è configurato per l'utilizzo di applicazioni del servizio di ricerca e applicazioni di servizio metadati gestiti separate tramite un gruppo di servizi personalizzato. Altre applicazioni di servizio vengono aggiunte al gruppo personalizzato e condivise con il gruppo predefinito. L'esempio di progettazione non include l'applicazione di servizio profili utente per impedire agli utenti partner di accedere ai dati sulle persone nell'organizzazione.

Nell'architettura semplificata dell'esempio di progettazione basato su portale aziendale con raccolte siti con nome host (un gruppo di servizi) i partner possono accedere all'intera tassonomia aziendale e possono consultare i dati sulle persone nell'organizzazione. I risultati delle ricerche sono tuttavia limitati ai siti e al contenuto a cui possono accedere i partner.

Se per i siti di partner è necessario l'isolamento del contenuto tra progetti, è consigliabile distribuire applicazioni di servizio dedicate, come illustrato in questo articolo. In questo modo, aumenta la complessità dell'architettura dei servizi, ma i partner non possono accedere ai metadati associati al contenuto Intranet o ad altri progetti nel sito Web di partner. Anche l'esempio di progettazione basato su rete Extranet utilizza servizi partizionati.

Siti di amministrazione

Nell'esempio di progettazione un server applicazioni ospita il sito Web Amministrazione centrale SharePoint per ogni server farm. In questo modo, il sito viene protetto dal contatto diretto con gli utenti. Se un collo di bottiglia delle prestazioni o una violazione della sicurezza compromette la disponibilità dei server Web front-end, il sito Web Amministrazione centrale SharePoint resta comunque disponibile.

Gli URL con bilanciamento del carico per i siti di amministrazione non sono citati nell'esempio di progettazione e in questo articolo. Tra le procedure consigliate sono incluse le seguenti:

Se gli URL amministrativi utilizzano numeri di porta, utilizzare porte non standard. Gli URL includono i numeri di porta per impostazione predefinita. Mentre gli URL pubblici non includono in genere numeri di porta, l'utilizzo di numeri di porta per i siti di amministrazione può aumentare il livello di sicurezza limitando l'accesso a tali siti alle porte non standard.
Creare voci DNS separate per i siti di amministrazione.

Oltre a queste procedure consigliate, è possibile usare il bilanciamento del carico per il sito Web Amministrazione centrale SharePoint tra più server applicazioni per ottenere ridondanza.

Pool di applicazioni

In genere vengono implementati pool di applicazioni Internet Information Services (IIS) separati per garantire l'isolamento dei processi dal contenuto. I pool di applicazioni consentono di eseguire più siti nello stesso computer server, mantenendo tuttavia i relativi processi di lavoro e identità. In questo modo è possibile impedire all'autore di un attacco che introduce codice in un sito di attaccare altri server o siti in altri siti.

Se un singolo pool di applicazioni e una singola applicazione Web vengono utilizzati insieme alle raccolte siti con nome host, viene garantito l'isolamento tra URL di dominio, ma solo a livello di script.

Se si sceglie di implementare più di un pool di applicazioni, valutare se utilizzare un pool di applicazioni dedicato per ognuno degli scenari seguenti:

Per separare contenuto autenticato da contenuto anonimo. Se la stessa farm ospita il sito Internet aziendale, inserire questo sito in un'applicazione Web e in un pool di applicazioni dedicati.
Per isolare siti che interagiscono con sistemi di dati back-end e in cui sono archiviate le relative password, anche se a questo scopo è possibile usare il servizio di archiviazione sicura.

L'esempio di progettazione basato su portale aziendale con siti con nome host e quello basato su rete Extranet con aree dedicate per l'autenticazione implementano entrambi un singolo pool di applicazioni e una singola applicazione Web per tutto il contenuto. Pool di applicazioni separati sono necessari per le applicazioni di servizio e il sito Web Amministrazione centrale SharePoint.

Nell'esempio di progettazione basato su portale aziendale con siti basati su percorso viene implementato l'isolamento dei processi dal contenuto utilizzando pool di applicazioni separati nei modi seguenti:

Il sito di amministrazione è ospitato in un pool di applicazioni dedicato. Questo è un requisito di SharePoint Server.
Tutte le applicazioni di servizio vengono distribuite in un singolo pool di applicazioni. Questa è la configurazione consigliata, a meno che non esista un valido motivo per distribuire le applicazioni di servizio in pool di applicazioni diversi. Un pool di applicazioni per tutte le applicazioni di servizio consente di ottimizzare le prestazioni e di ridurre il numero di pool di applicazioni da gestire.
Il contenuto intranet è suddiviso in due pool di applicazioni diversi. Un pool di applicazioni ospita contenuto collaborativo (siti personali e siti del team). Un pool di applicazioni separato ospita il contenuto Intranet pubblicato. Questa configurazione fornisce l'isolamento del processo per il contenuto Intranet pubblicato in cui è più probabile che vengano usate le connessioni dati aziendali.
Un pool di applicazioni dedicato ospita l'applicazione Web di partner.

Applicazioni Web

Un'applicazione Web è un sito Web IIS creato e utilizzato da SharePoint Server. Ogni applicazione Web è rappresentata da un sito Web diverso in IIS.

Se si sceglie di implementare più applicazioni Web, considerare le modalità di utilizzo seguenti:

Separare il contenuto anonimo da quello autenticato.

Se la stessa farm ospita il sito Internet aziendale, inserire questo sito in un'applicazione Web e in un pool di applicazioni dedicati.
Isolare gli utenti

Nell'esempio di progettazione il sito Web di partner è ospitato in un'applicazione Web e in un pool di applicazioni dedicati per impedire ai partner l'accesso al contenuto Intranet.
Applicare le autorizzazioni

Un'applicazione Web dedicata offre l'opportunità di implementare criteri nelle aree all'interno dell'applicazione Web per applicare le autorizzazioni. È possibile, ad esempio, creare criteri per il sito Internet della società per negare in modo esplicito l'accesso in scrittura a uno o più gruppi di utenti. I criteri vengono applicati indipendentemente dalle autorizzazioni configurate per singoli siti o documenti nell'applicazione Web.
Ottimizzare le prestazioni

Le applicazioni offrono prestazioni migliori se vengono inserite in applicazioni Web con altre applicazioni con caratteristiche dei dati simili. Le caratteristiche dei dati di siti personali, ad esempio, includono in genere un numero elevato di siti di dimensioni contenute. Al contrario, i siti di team comprendono in genere un numero ridotto di siti di dimensioni molto grandi. Se questi due tipi di siti vengono inseriti in applicazioni Web distinte, i database risultanti saranno costituiti da dati con caratteristiche simili, con una conseguente ottimizzazione delle prestazioni dei database. Nell'esempio di progettazione i siti personali e quelli di team non presentano requisiti specifici di isolamento dei dati, ma condividono lo stesso pool di applicazioni. Ciononostante, i siti personali e quelli di team vengono posizionati in applicazioni Web distinte per ottimizzare le prestazioni.
Ottimizzare la gestibilità

Poiché la creazione di applicazioni Web separate determina la creazione di siti e database distinti, è possibile implementare limiti diversi per i siti (Cestino, scadenza e dimensioni) e negoziare contratti di servizio specifici. È ad esempio possibile concedere più tempo per ripristinare il contenuto dei siti personali se non si tratta del tipo di contenuto più importante nell'organizzazione. In questo modo, è possibile ripristinare il contenuto più importante prima del contenuto dei siti personali. Nell'esempio di progettazione i siti personali vengono inseriti in un'applicazione Web distinta per consentire agli amministratori di gestire la crescita in modo più accurato rispetto alle altre applicazioni.

Se si implementano raccolte siti con nome host con una singola applicazione Web, ogni sito principale si trova in un dominio distinto che consente di realizzare alcuni di questi obiettivi, ad esempio l'ottimizzazione della gestibilità tramite l'implementazione di diversi limiti per i siti.

Raccolte siti

La configurazione consigliata per la distribuzione di siti consiste nell'utilizzo di raccolte siti con nome host per tutti i siti all'interno di una singola applicazione Web. Questa configurazione è consigliata per distribuire i siti perché è la stessa architettura usata dall'ambiente Microsoft 365. Inoltre, le nuove caratteristiche, quali il modello di app e Gestione richieste, sono ottimizzate per questa configurazione. Di conseguenza, questa è la configurazione che risulterà più affidabile in futuro.

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 2016.

Questa indicazione non si applica alle soluzioni di creazione siti in modalità self-service personalizzate.
Per un'applicazione Web sono necessarie inclusioni di caratteri jolly o inclusioni esplicite univoche.

Le inclusioni vengono create per le raccolte siti denominate dall'host a livello di farm e sono disponibili per tutti i siti denominati dall'host. Tutte le raccolte siti con nome host in una farm condividono le stesse inclusioni, ma non è necessario usarle. Al contrario, le inclusioni create per le raccolte siti basate su percorso si applicano solo a una singola applicazione Web.
È 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.

Per altre informazioni sulle raccolte siti con nome host e un confronto tra tali raccolte e quelle basate su percorso, vedere Architettura e distribuzione di raccolte siti con nome host (SharePoint 2013).

Obiettivi di progettazione per le raccolte siti

Le raccolte siti rappresentano il collegamento tra l'architettura logica e l'architettura delle informazioni. Gli obiettivi di progettazione per le raccolte siti consistono nel soddisfare i requisiti per la progettazione degli URL e creare divisioni logiche di contenuto. Per ogni raccolta siti, i percorsi gestiti includono un secondo livello di raccolte siti principali. Per altre informazioni sui requisiti relativi agli URL e l'utilizzo di percorsi gestiti, vedere Aree e URL più avanti in questo articolo. Oltre al secondo livello delle raccolte siti, ogni sito è un sito secondario.

Nel diagramma seguente viene illustrata la gerarchia dei siti di team.

Gerarchia dei siti di team

Siti del team

Per le raccolte siti basate su percorso e le raccolte siti con nome host, l'architettura delle informazioni dipende dal secondo livello delle raccolte siti. Nella sezione seguente viene descritto il modo in cui gli esempi di progettazione includono scelte basate sulla natura dei siti.

Contenuto dell'Intranet pubblicato

L'applicazione Web del contenuto Intranet pubblicato si basa sul presupposto che il contenuto pubblicato verrà ospitato in più divisioni all'interno della società. Nell'esempio di progettazione una raccolta siti distinta ospita il contenuto di ogni divisione. In questo modo si ottengono i vantaggi seguenti:

Ogni divisione può gestire contenuto e amministrare le autorizzazioni in modo indipendente.
Il contenuto di ogni divisione può essere archiviato in un database dedicato.

Di seguito vengono indicati gli svantaggi della presenza di più raccolte siti:

Non è possibile condividere tra raccolte siti pagine master, layout di pagina, modelli, web part e strutture di spostamento.
Per il coordinamento delle personalizzazioni e delle strutture di spostamento tra raccolte siti è necessario un impegno maggiore.

In base all'architettura delle informazioni e alla progettazione dei siti Intranet, il contenuto pubblicato può essere mostrato agli utenti come un'esperienza continua. In alternativa, ogni raccolta siti può apparire come un sito Web separato.

Siti personali

I siti personali hanno caratteristiche specifiche e sono associati a semplici procedure consigliate di distribuzione. Negli esempi di progettazione, la raccolta siti siti personali incorpora un sito di primo livello con l'URL di http://my. La prima raccolta siti principale creata utilizza il modello Host siti personali. Viene incorporato un percorso gestito tramite l'inclusione di caratteri jolly, che consente un numero indefinito di siti creati dagli utenti. Tutti i siti all'interno del percorso gestito sono raccolte siti indipendenti che utilizzano il modello Sito personale. Il nome utente viene aggiunto all'URL utilizzando il formato http://mynomeutente. Nella figura seguente vengono illustrati i siti personali.

Gerarchia dei siti personali

Siti personali

Siti del team

È possibile usare uno dei due approcci seguenti per progettare le raccolte siti in un'applicazione per siti di team:

Consentire ai team di creare raccolte siti tramite la caratteristica di creazione siti in modalità self-service. Il vantaggio di questo approccio è che i team possono creare facilmente un sito, in base alle esigenze, senza l'assistenza dell'amministratore. Tra gli svantaggi di questo approccio sono inclusi i seguenti:
- Si perde l'opportunità di implementare una tassonomia ponderata.
- Non è possibile condividere modelli e strutture di spostamento tra i progetti o i team che possono invece condividere una raccolta siti.
Creare un numero definito di raccolte siti per l'organizzazione in base alle modalità operative dell'organizzazione stessa. In questo approccio, un amministratore di SharePoint crea raccolte siti. Dopo la creazione di una raccolta siti, i team possono creare i siti al suo interno. Questo approccio consente di implementare una tassonomia ponderata che costituisca la base per la gestione e la crescita dei siti di team. Esistono inoltre più opportunità di condividere modelli e strutture di spostamento tra progetti e team che condividono una raccolta siti. Questo approccio implica tuttavia anche alcuni svantaggi.

Gli esempi di progettazione includono il secondo approccio, che produce una gerarchia di raccolte siti per i siti di team simile a quella per il contenuto Intranet pubblicato. La difficoltà principale per gli architetti consiste nella creazione di un secondo livello di raccolte siti appropriato per l'organizzazione. Nella tabella seguente sono inclusi suggerimenti per i diversi tipi di organizzazioni.

Tabella: tassonomie consigliate per le raccolte siti

Tipo di organizzazione	Tassonomie consigliate per le raccolte siti
Sviluppo prodotti	Creare una raccolta siti per ogni prodotto in fase di sviluppo. Consentire ai team che contribuiscono di creare siti all'interno della raccolta siti. Per ogni progetto di sviluppo a lungo termine, creare una raccolta siti per ogni team numeroso che contribuisce al prodotto. Creare ad esempio una raccolta siti per ognuno dei team seguenti: progettisti, ingegneri e sviluppatori di contenuti.
Ricerca	Creare una raccolta siti per ogni progetto di ricerca a lungo termine. Creare una raccolta siti per ogni categoria di progetto di ricerca.
Istituto di istruzione superiore	Creare una raccolta siti per ogni dipartimento accademico.
Ufficio legislativo statale	Creare una raccolta siti per ogni partito politico. I rappresentanti del governo che condividono l'affiliazione a uno stesso partito possono condividere modelli e strutture di spostamento. Creare una raccolta siti per ogni comitato. In alternativa, creare una raccolta siti per tutti i comitati.
Ufficio legale aziendale	Creare una raccolta siti per ogni client aziendale.
Produzione	Creare una raccolta siti per ogni linea di prodotti.