Condividi tramite

Progettare l'architettura logica dei siti di collaborazione

  • Articolo

Contenuto dell'articolo:

  • Informazioni sui siti dei team in un ambiente di rete Intranet

  • Suggerimenti per la progettazione dei siti dei team

  • Ospitare i siti dei team in un'applicazione Web dedicata

  • Pianificare le impostazioni generali dell'applicazione Web

  • Stabilire se consentire o meno agli utenti di creare raccolte siti

  • Progettare le impostazioni dei database del contenuto per i siti dei team

  • Eliminare automaticamente i siti inutilizzati

  • Utilizzare i percorsi per organizzare gli URL dei siti dei team

  • Pianificare elementi personalizzati

  • Pianificare le autorizzazioni da applicare ai siti dei team

In Microsoft Office SharePoint Portal Server 2003 i siti dei team hanno funzionalità più limitate rispetto ai siti portale. In Microsoft Office SharePoint Server 2007 non è così. In Microsoft Office SharePoint Server 2007 i siti di collaborazione creati in un ambiente Intranet possono avvalersi delle stesse caratteristiche dei siti portale Intranet pubblicati, se tali caratteristiche sono state rese disponibili anche nell'ambiente Intranet. In questo articolo, per fare riferimento a tali siti verrà utilizzata la consueta espressione "siti dei team", ma è necessario ricordare che tali siti non sono più limitati alle sole caratteristiche che contengono, come avviene con la versione precedente del prodotto. L'espressione "siti dei team" indica semplicemente che tali siti vengono utilizzati da gruppi più ristretti o per un tipo di collaborazione più specifico, rispetto ai siti portale Intranet pubblicati e controllati.

I siti dei team costituiscono un aspetto importante nella maggior parte delle distribuzioni di Microsoft Office SharePoint Server 2007, soprattutto nelle distribuzioni Intranet. I siti dei team offrono opportunità di collaborazione e spazio di archiviazione che possono risultare utili sia per i progetti a breve che a lungo termine, per le comunicazioni e per la collaborazione tra gruppi. Se si prevede di creare una distribuzione che offre anche siti dei team, sarà necessario includerli nel progetto iniziale dell'architettura, in modo da poterne pianificare l'hosting e la gestione. È ad esempio necessario pianificare i database del contenuto da utilizzare per ospitare il contenuto dei siti dei team, pianificare l'archiviazione e l'eliminazione dei siti dei team per i progetti a breve termine, in modo la liberare spazio per altri progetti, e monitorare i siti di comunicazione dei team per verificare che abbiano dimensioni gestibili ai fini delle attività di backup e ripristino.

In questo articolo sono disponibili suggerimenti per la progettazione dell'architettura logica per lo sviluppo dei siti dei team nell'ambito di una server farm. In questo articolo non viene illustrata l'architettura delle informazioni, ovvero la struttura interna, dei siti dei team. Per informazioni sulla progettazione dell'architettura delle informazioni, vedere Pianificare la struttura e la pubblicazione del sito Web (Office SharePoint Server). Per ulteriori informazioni sui siti dei team, vedere Pianificare siti di collaborazione.

Informazioni sui siti dei team in un ambiente di rete Intranet

In un ambiente di rete Intranet basato su Microsoft Office SharePoint Server 2007, per connettere i siti dei team al sito portale Intranet pubblicato è possibile elencarli nella directory dei siti. È possibile creare tali siti tramite la directory dei siti del sito pubblicato, in modo che condividano lo stesso nome host, oppure aggiungere siti esistenti alla directory dei siti per raggruppare in un'unica posizione tutti i siti dei team correlati. In questo modo tali siti verranno visualizzati come parte del portale Intranet pubblicato, indipendentemente dai relativi URL.

Poiché i siti dei team sono siti di SharePoint con lo stesso set di caratteristiche degli altri siti pubblicati nello stesso ambiente, possono utilizzare anche le funzionalità di business intelligence, i moduli e le altre caratteristiche disponibili nell'ambiente. Tali caratteristiche possono influenzare l'architettura dei siti dei team realizzati. Se ad esempio è necessario visualizzare dati business dal Catalogo dati business nel sito di un team, sarà necessario verificare che i membri di tale sito dispongano delle autorizzazioni di accesso necessarie per visualizzare i dati. Poiché le funzionalità di business Intelligence e la protezione sono configurate a livello di provider di servizi condivisi, tutti i siti dei team che si connettono agli stessi dati business dovranno utilizzare lo stesso provider di servizi condivisi ed essere inclusi nelle stesse applicazioni Web associate a tale provider di servizi condivisi.

Per ulteriori informazioni sulla pianificazione di funzionalità di business intelligence e moduli per il proprio ambiente, vedere le risorse seguenti:

Suggerimenti per la progettazione dei siti dei team

Nella maggior parte delle organizzazioni il numero e le dimensioni dei siti dei team aumentano continuamente, a volte molto in fretta. A mano a mano che i team vengono riorganizzati o che i progetti vengono completati e ne iniziano di nuovi, i vari team creano nuovi siti e abbandonano i precedenti oppure espandono i siti correnti in modo che possano contenere sempre più dati. Per gestire o controllare tale crescita, è necessario pianificare il supporto dei siti dei team con estrema attenzione.

Gli obiettivi di progettazione per i siti del team includono:

  • Ottimizzazione delle prestazioni di tutta la server farm.

  • Creazione di suddivisioni logiche dei database per i siti dei team ai fini della manutenzione ordinaria, ovvero delle attività di backup, ripristino e aggiornamento.

  • Possibilità di applicare impostazioni e criteri appropriati ai siti dei team senza influire sugli altri tipi di siti presenti nella rete Intranet.

Di seguito sono riportati alcuni suggerimenti per la progettazione dei siti del team, ognuno dei quali viene approfondito in dettaglio nelle sezioni successive:

  • Ospitare siti dei team in un'applicazione Web dedicata.

  • Applicare le impostazioni generali dell'applicazione Web, ad esempio le impostazioni di gestione delle quote e del ciclo di vita, a livello di applicazione Web, in modo da poter gestire la crescita dei siti di team e mantenere sempre aggiornato il contenuto.

  • Definire le impostazioni dei database del contenuto in modo da garantire livelli di scalabilità e quantità di spazio di archiviazione appropriati, oltre a consentire l'esecuzione delle attività di backup e ripristino di database con le dimensioni previste.

  • Eliminare automaticamente i siti inutilizzati.

  • Utilizzare percorsi per organizzare gli URL dei siti dei team.

  • Pianificare le autorizzazioni e i criteri appropriati.

Ospitare i siti dei team in un'applicazione Web dedicata

I siti dei team possono essere ospitati sia in un'applicazione Web dedicata che in un'applicazione Web condivisa tramite i siti personali. È consigliabile non ospitare i siti dei team nella stessa applicazione Web utilizzata per il sito portale Intranet pubblicato. Mantenendo i siti dei team separati dal sito portale Intranet, le attività di manutenzione e ripristino dei dati risulteranno più semplici. Se le dimensioni dei database del contenuto vengono gestite in modo appropriato, questo aspetto non costituisce tuttavia un grosso problema. Nella figura seguente è illustrata l'applicazione Web che contiene i siti dei team di una soluzione Intranet.

Architettura logica dei siti di collaborazione

In alcuni casi, per l'hosting dei siti dei team è consigliabile utilizzare più applicazioni Web dedicate, come illustrato negli esempi seguenti.

  • Un società che si occupa di intermediazione finanziaria e ricerche sui titoli ha l'esigenza di mantenere separati i siti dei servizi finanziari da quelli utilizzati per le ricerche sui titoli, secondo quanto previsto dalle normative della Commissione Nazionale per le Società e la Borsa (Consob). In questo esempio la società deve utilizzare due applicazioni Web con gruppi isolati di raccolte siti dei team per le due divisioni. La società deve inoltre utilizzare criteri distinti a livello di applicazione Web e provider di servizi condivisi per garantire che gli utenti di ogni divisione non possano visualizzare i contenuti prodotti dall'altra divisione.

  • Una società che si occupa di ricerca e produzione ha l'esigenza di mantenere sotto stretto controllo la proprietà intellettuale e i risultati delle ricerche. In questo caso, la società può ospitare i siti dei team di ricerca in un'applicazione Web separata e utilizzare criteri a livello di applicazione Web per imporre le autorizzazioni e garantire che il contenuto dei siti del team di ricerca sarà accessibile solo al personale addetto.

  • Un'organizzazione ospita siti dei team sia interni (Intranet) che esterni (Extranet), che desidera implementare e gestire in modi diversi. In questo caso l'organizzazione deve pianificare e implementare due applicazioni Web separate per ospitare i due gruppi di siti dei team, in modo da utilizzare metodi di autenticazione diversi, database diversi e registri di IIS diversi per ogni ambiente, da utilizzare in caso di problemi. Per ulteriori informazioni sulla pianificazione per le reti Extranet, vedere Progettare la topologia di una farm Extranet (Office SharePoint Server).

È in generale consigliabile utilizzare applicazioni Web dedicate per:

  • Separare il contenuto anonimo da quello autenticato.

  • Isolare gli utenti.

  • Applicare autorizzazioni.

  • Ottimizzare le prestazioni.

  • Ottimizzare la gestibilità.

Per ulteriori informazioni sui criteri da seguire per scegliere se utilizzare applicazioni Web dedicate o condivise, vedere Modello di architettura logica: distribuzione aziendale.

Considerazioni relative alle prestazioni

Quando si ospitano i siti dei team in un'applicazione Web dedicata vengono utilizzati numerosi database del contenuto che contengono solo raccolte siti dei team. Se i database del contenuto ospitano siti che utilizzano dati con caratteristiche simili, il software per database Microsoft SQL Server sarà in grado di gestirli in modo più efficiente, perché tale applicazione sceglie un piano di query basato sulle caratteristiche del database. Se invece il database ospita siti che utilizzano dati con caratteristiche molto diverse, SQL Server potrebbe non utilizzare il piano di query più efficiente per l'intero contenuto del database. Se ad esempio il database ospita sia siti dei team (ovvero numerosi siti di medie dimensioni) che siti portale (ovvero un numero limitato di siti con dimensioni molto grandi e volumi di richieste elevati), il piano di query utilizzato risulterà inefficiente per uno dei due tipi di siti. Inserendo il contenuto dei siti dei team in database dedicati è pertanto possibile ottimizzare le prestazioni di SQL Server, migliorando le prestazioni globali della server farm.

Considerazioni sulla gestibilità

L'hosting dei siti del team in un'applicazione Web dedicata consente di migliorare la gestibilità nei modi seguenti:

  • È possibile gestire separatamente gli elementi seguenti:

    • Impostazioni di database

    • Modelli quote

    • Impostazioni del Cestino

    • Azioni automatizzate per i siti inutilizzati

    • Autenticazione

    • Criteri

  • Separando la gestione dei siti dei team da quella degli altri tipi di siti, è possibile gestire in modo più efficiente la crescita dei siti dei team.

  • È possibile offrire la possibilità di stipulare contratti di servizio specifici. Oltre al contratto di servizio che prevede la creazione di backup completi settimanali e backup differenziali quotidiani per il database del contenuto, è ad esempio possibile offrire una soluzione più rapida per il recupero dei singoli elementi di contenuto utilizzando il Cestino secondario.

Scegliere un pool di applicazioni

In un ambiente aziendale i siti dei team possono condividere un pool di applicazioni con applicazioni Web che presentano requisiti di collaborazione e isolamento analoghi. Possono ad esempio condividere un pool di applicazioni con i siti personali, perché entrambi i tipi di siti vengono utilizzati per la collaborazione e l'archiviazione di informazioni e documenti e hanno in genere un ambito simile ai fini dell'isolamento, ovvero sono entrambi disponibili per l'intera organizzazione.

In generale, è necessario un pool di applicazioni dedicato quando si desidera eseguire una delle operazioni seguenti:

  • Per separare il contenuto autenticato dal contenuto anonimo.

  • Isolare le applicazioni che interagiscono con applicazioni aziendali esterne, ad esempio connessioni al Catalogo dati business, e archiviano le relative password.

  • Isolare le applicazioni in cui gli utenti sono liberi di creare e amministrare siti e di collaborare alla realizzazione dei contenuti.

Per ulteriori informazioni sull'utilizzo di pool di applicazioni dedicati, vedere Modello di architettura logica: distribuzione aziendale.

In un ambiente host in cui viene utilizzata una singola server farm per ospitare contenuto per più organizzazioni è consigliabile ospitare tutto il contenuto di una singola organizzazione nello stesso pool di applicazioni. Ciò consente infatti di aumentare la scalabilità (riducendo il numero dei pool di applicazioni si riduce il numero dei processi in esecuzione) e migliorare l'isolamento dei processi tra i vari pool di applicazioni (l'arresto del pool di applicazioni del Cliente A non influisce sui siti del Cliente B). La scelta dipende naturalmente dal numero di organizzazioni, dalla pianificazione delle prestazioni e dai requisiti di isolamento.

Pianificare le impostazioni generali dell'applicazione Web

Nella pagina Impostazioni generali applicazione Web sono disponibili numerose impostazioni che consentono di gestire l'aumento dei volumi di dati e lo stato di aggiornamento del contenuto nei siti dei team del proprio ambiente. Tali impostazioni vengono applicate a tutti i siti disponibili nell'ambito di un'applicazione Web. Pianificare come minimo l'implementazione delle impostazioni seguenti, ognuna delle quali verrà illustrata in dettaglio di seguito in questa sezione:

  • Definire e applicare un modello quote per limitare le dimensioni massime dei siti dei team.

  • Stabilire le dimensioni massime per il caricamento dei file. Specificare dimensioni che consentano di soddisfare abbondantemente i requisiti aziendali, in modo che gli utenti possano collaborare senza difficoltà.

  • Attivare i Cestini dei siti e utilizzare il Cestino secondario.

Oltre alle impostazioni elencate in precedenza, esaminare tutte le impostazione relative alle caratteristiche nella pagina Impostazioni generali applicazione Web per verificare che le caratteristiche disponibili siano appropriate ai siti dei team dell'organizzazione. Per impostazione predefinita, sono attivate le caratteristiche seguenti:

  • Smart tag nomi e disponibilità in linea (vengono visualizzate informazioni sulla presenza in linea)

  • Avvisi (per impostazione predefinita gli utenti possono creare un massimo di 500 avvisi)

  • Feed RSS (Really Simple Syndication)

  • API (Application Programming Interface) per blog (collegamento per creare un blog)

Determinare le impostazioni del modello quote

Per i siti dei team in un ambiente Microsoft Office SharePoint Server 2007 non è disponibile alcun modello quote predefinito. Come come punto di partenza è tuttavia consigliabile utilizzare le impostazioni seguenti:

  • Invio automatico di un messaggio di posta elettronica a un proprietario del sito quando le dimensioni del sito raggiungono i 450 MB.

  • Blocco del caricamento di ulteriori documenti da parte degli utenti quando le dimensioni del sito raggiungono i 500 MB.

Queste impostazioni sono appropriate per molte organizzazioni, ma è comunque consigliabile stimare il numero e le dimensioni degli elementi che si prevede verranno archiviati dagli utenti nei siti dei team e modificare le impostazioni come necessario per garantire il corretto utilizzo di tali siti.

Se ad esempio nell'organizzazione sono presenti team di ricerca e progettazione che collaborano producendo volumi elevati di contenuto da memorizzare e archiviare, è consigliabile aumentare i limiti di quota, ad esempio incrementando a 5 o 10 GB il limite per i siti. In uno scenario di questo tipo, ospitando il contenuto nei siti dei team è possibile garantire che verrà eseguito un backup regolare del contenuto e che tutti gli utenti avranno la possibilità di apportare il proprio contributo. Può essere inoltre consigliabile inserire ogni raccolta siti con dimensioni di 5-10 GB in un database del contenuto a parte, soprattutto se si prevede che le dimensioni aumenteranno rapidamente.

Se invece i siti dei team vengono utilizzati principalmente per progetti a breve termine o come siti di comunicazione per i membri dei team, è consigliabile utilizzare un limite di quota inferiore, per invitare i membri dei team a memorizzare solo le informazioni effettivamente necessarie per lo svolgimento dei progetti a breve termine. Tale limite non deve essere tuttavia ridotto eccessivamente, per evitare di aumentare i costi associati alle richieste di incremento della quota inviate all'helpdesk. In questo scenario è consigliabile invitare i membri dei team a memorizzare il contenuto generale per il team o il contenuto per i nuovi progetti in siti del team separati.

Se un gruppo o team specifico dell'organizzazione ha l'esigenza di memorizzare un volume di dati superiore nel proprio sito, sarà possibile modificare i limiti di quota a livello di singola raccolta siti. Per modificare i limiti di quota, nella pagina Quote e blocchi raccolta siti selezionare la raccolta siti che corrisponde al team o al gruppo desiderato, passare al modello quote Singola quota e quindi specificare i limiti appropriati.

Durante la pianificazione dei modelli quote impostare limiti appropriati alla maggior parte dei siti dei team dell'organizzazione. Per migliorare la gestibilità, regolare le quote a livello di singolo utente solo quando è effettivamente necessario per soddisfare le esigenze aziendali.

Determinare le dimensioni massime per il caricamento

Le dimensioni massime predefinite per i caricamenti sono di 50 MB. Si tratta di un limite abbondante, che offre agli utenti tutta la flessibilità necessaria per caricare documenti di dimensioni e tipi diversi senza influire negativamente sulle prestazioni. Se gli utenti dell'organizzazione hanno l'esigenza di memorizzare file di dimensioni superiori nei siti dei relativi team, è consigliabile modificare questa impostazione e se necessario monitorare le impostazioni di timeout di IIS per gli utenti che dispongono di connessioni lente.

Determinare le impostazioni del Cestino

Attivando il Cestino è possibile migliorare in modo semplice e rapido la gestibilità dei siti di team. Il Cestino consente ai proprietari dei siti di recuperare gli elementi eliminati senza richiedere un intervento amministrativo centrale, ovvero il ripristino dai nastri di backup.

Nell'elenco seguente sono illustrate le impostazioni predefinite per il Cestino che risultano appropriate per la maggior parte delle organizzazioni:

  • Stato Cestino: Attiva

  • Elimina elementi nel Cestino: Dopo 30 giorni

  • Cestino secondario: Aggiungi 50 percentuale delle quote sito attive per gli elementi eliminati del Cestino secondario

Nel Cestino secondario vengono memorizzati gli elementi che gli utenti hanno eliminato dai rispettivi Cestini. Solo gli amministratori della raccolta siti possono ripristinare elementi dal Cestino secondario. Le dimensioni specificate per il Cestino secondario vengono sommate alle dimensioni totali del sito del team. Se ad esempio il sito del team ha un limite di 500 MB e per il Cestino secondario è impostata una percentuale del 50%, per il sito sarà possibile utilizzare in totale 750 MB. È pertanto necessario pianificare la capacità del database di conseguenza.

Come avviene per il Cestino, anche gli elementi nel Cestino secondario vengono eliminati automaticamente allo scadere del periodo di tempo previsto per gli elementi eliminati, che per impostazione predefinita è di 30 giorni. Al raggiungimento delle dimensioni massime del Cestino secondario, tuttavia, gli elementi contenuti vengono eliminati automaticamente a partire dai meno recenti. Gli amministratori della raccolta siti possono inoltre svuotare il Cestino secondario manualmente.

Se si decide di utilizzare il Cestino, è essenziale stabilire se utilizzare o meno il Cestino secondario e determinare la quantità di spazio da allocare. È consigliabile allocare almeno una piccola quantità di spazio (ad esempio il 10%) per il Cestino secondario, per consentire il recupero nel caso in cui un utente elimini accidentalmente un documento importante, una cartella in una raccolta documenti o una colonna in un elenco.

Pianificare il metodo di creazione dei siti

È possibile decidere se creare centralmente le raccolte siti per i siti dei team o consentire agli utenti di creare le proprie raccolte siti tramite Gestione siti in modalità self-service. Entrambi gli approcci presentano vantaggi e svantaggi.

Se si consente la creazione di raccolte siti tramite Gestione siti in modalità self-service, i membri dei team potranno creare con facilità i siti necessari, senza richiedere l'intervento di un amministratore. Questo approccio presenta tuttavia numerosi svantaggi, ad esempio:

  • Si perde la possibilità di implementare una tassonomia ad-hoc.

  • L'applicazione può diventare difficile da gestire.

  • I siti vengono abbandonati facilmente.

  • Non è possibile condividere modelli e strutture di spostamento tra progetti o team che potrebbero invece condividere una raccolta siti.

Nota

Se si desidera utilizzare Gestione siti in modalità self-service limitando i modelli disponibili per la creazione di siti con tale metodo, è possibile modificare il file webtempsps.XML (disponibile in %programfiles%\File comuni\Microsoft Shared\Web server extensions\12\TEMPLATE\1033\XML) in modo da nascondere i modelli al processo di Gestione siti in modalità self-service.

Se invece si decide di creare le raccolte siti centralmente, in base alle modalità operative della propria organizzazione, sarà possibile implementare una tassonomia mirata che fornisca la struttura di base per la gestione e la crescita dei siti di team. Sono inoltre disponibili maggiori opportunità di condividere modelli e strutture di spostamento tra i progetti e i team che condividono una raccolta siti. Con questo approccio, dopo la creazione iniziale della raccolta siti i membri del team possono creare altri siti all'interno della raccolta in base alle proprie esigenze. È tuttavia necessario impegnare risorse IT ogni volta che un utente richiede la creazione di un sito.

Per esempi che illustrano quando utilizzare ciascun metodo, vedere Modello di architettura logica: distribuzione aziendale. Per ulteriori informazioni sulla pianificazione della creazione dei siti, vedere Processo di pianificazione per la creazione di siti (Office SharePoint Server).

Se nella propria organizzazione è stato scelto di creare raccolte siti per i siti dei team, anziché consentire agli utenti di creare le proprie raccolte siti dei team, utilizzare il foglio di lavoro Site paths worksheet (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=73149&clcid=0x410) (informazioni in lingua inglese) per determinare il livello in cui vengono creati i siti dei team, ovvero come siti principali nelle rispettive raccolte siti o come un'unica raccolta siti di grandi dimensioni con più siti secondari. Per ulteriori informazioni su come determinare se creare numerose raccolte siti o un numero limitato di raccolte siti con più siti secondari, vedere la sezione che illustra come decidere se utilizzare singole raccolte siti o più siti secondari all'interno di una raccolta siti nell'articolo Determine sites and subsites needed [Windows SharePoint Services] della Raccolta di documentazione tecnica di Microsoft Windows SharePoint Services 3.0. Per ulteriori informazioni sui tipi di siti disponibili in Microsoft Office SharePoint Server 2007, vedere Determinare siti e siti secondari.

Progettare le impostazioni dei database del contenuto per i siti dei team

Nel modello di architettura logica illustrato in Modello di architettura logica: distribuzione aziendale i siti dei team risiedono in database dedicati, uno per ogni raccolta siti. Questo approccio consente di gestire in modo indipendente le attività di backup, ripristino e migrazione dei database delle singole raccolte siti. Inoltre, al termine di un progetto è possibile archiviare facilmente il database associato. Questo approccio comporta la creazione di numerosi database, ma consente di controllare singolarmente i database delle varie raccolte siti.

Si noti tuttavia che le prestazioni di SQL Server potrebbero risultare inferiori, a causa dell'elevato numero di database presente per ogni istanza di SQL Server. In altre parole, se si prevedere di utilizzare più di 300 raccolte siti dei team, l'archiviazione di ognuna di esse in un database dedicato potrebbe comportare una notevole riduzione delle prestazioni di SQL Server. A ogni database corrisponde infatti una connessione tra il pool di applicazioni e SQL Server, e quando si aggiungono server Web e database il numero delle connessioni attive aumenta. Se si aggiungono troppe connessioni, SQL Server potrebbe smettere di rispondere.

Se pertanto si prevede di utilizzare più di 300 raccolte siti dei team, è consigliabile evitare di utilizzare database dedicati, ma archiviare più raccolte siti in ogni database. Si noti che 300 è il numero dei database utilizzati dal reparto IT di Microsoft. Non si tratta di un punto di errore, ma solo di una stima basata sui dati relativi a SharePoint Portal Server 2003. In base a tali dati, il reparto IT di Microsoft ritiene che 300 sia il numero massimo di database di raccolte siti che è possibile ospitare con sicurezza in ogni server. In ogni organizzazione tale limite può variare in base a diversi parametri, tra cui il numero di database. Per decidere se utilizzare o meno database dedicati è infatti necessario tenere conto anche di altri fattori, inclusi i seguenti:

  • Esistono contratti di servizio diversi per i vari team (ad esempio requisiti di backup diversi)?

  • È necessario utilizzare più di 8 GB di spazio di archiviazione per ogni team?

  • I vari team svolgono progetti con cronologie molto diverse? Se si utilizza uno stesso database per team con progetti a breve termine e team con progetti a lungo termine, sarà più difficile archiviare i siti e spostarli fuori dall'ambiente di produzione.

  • I team desiderano livelli di autonomia e indipendenza elevati per le operazioni eseguite a livello di database?

Se si è risposto affermativamente a una qualsiasi delle domande precedenti, è consigliabile utilizzare database dedicati per le raccolte siti.

Se si sceglie di archiviare più raccolte siti in ogni database, sarà possibile calcolare il numero di raccolte da archiviare in ogni database determinando le dimensioni massime di un database e le dimensioni massime di ogni raccolta siti (ottenute sommando il valore del limite di archiviazione del modello quote allo spazio allocato per il Cestino). Si noti che se si assegna una quota di 500 MB a ogni raccolta siti, non tutte le raccolte utilizzeranno completamente la propria quota e si rischia di creare un numero eccessivo di database del contenuto. Durante la fase di pianificazione dei database è possibile utilizzare le quote stimate, ma in seguito è necessario monitorare l'utilizzo reale e apportare le modifiche appropriate. Se si dispone di un ambiente precedente con SharePoint Portal Server 2003 o Windows SharePoint Services 2.0, anziché utilizzare le quote stimate sarà possibile verificare le dimensioni delle raccolte siti in tale ambiente e creare i database in base alle dimensioni effettive di tali raccolte.

In un ambiente gestito i limiti di dimensione del database sono spesso determinati dai due fattori seguenti:

  • Il tempo necessario per eseguire il backup di un database. Oltre a una determinata dimensione, le operazioni di backup diventano inefficienti, richiedono un tempo eccessivo e rischiano di produrre dati danneggiati. Tali dimensioni possono costituire il limite oltre il quale si rende necessaria l'aggiunta di ulteriori server database all'ambiente.

  • Il tempo di attesa per il ripristino del contenuto, come definito dal contratto di servizio. Se ad esempio il tempo di attesa per il ripristino del contenuto è di quattro ore, la dimensione del database viene limitata a un volume che possa essere ripristinato in questa quantità di tempo.

Per determinare le massime dimensioni gestibili per i database delle raccolte siti dei team, utilizzare i valori elencati nella tabella seguente.

Elemento Fattore Valore

A

Tempo di attesa per il ripristino del contenuto

ora

B

Volume di contenuto che è possibile ripristinare entro il tempo di attesa, utilizzando il metodo e gli strumenti di ripristino indicati

GB

C

Tempo di attesa di destinazione per il backup dei database

ora

D

Volume di contenuto di cui è possibile eseguire il backup entro il tempo di attesa indicato, a seconda del metodo e degli strumenti di backup scelti

GB

Dati i due valori per il volume del contenuto (B e D), la dimensione massima gestibile del database per l'organizzazione è il minore dei due valori.

Dopo avere determinato le dimensioni di destinazione per i database del contenuto, è possibile calcolare il numero di raccolte siti che è possibile supportare in ogni database. Nella tabella seguente è indicato il numero di raccolte siti per database, in base alle dimensioni massime dei database e delle raccolte siti. Le dimensioni massime delle raccolte siti includono lo spazio allocato al Cestino secondario.

Dimensione database Raccolte siti con dimensioni massime di 500 MB Raccolte siti con dimensioni massime di 750 MB Raccolte siti con dimensioni massime di 1 GB Raccolte siti con dimensioni massime di 2 GB Raccolte siti con dimensioni massime di 5 GB Raccolte siti con dimensioni massime di 10 GB

25 GB

50

33

25

12

5

2

50 GB

100

66

50

25

10

5

100 GB

200

133

100

50

20

10

200 GB

400

266

200

100

40

20

500 GB

800

533

500

250

100

50

1 terabyte

1.600

1.066

1.000

500

200

100

Nota

Se una raccolta siti si espande fino a superare i 10 GB, è consigliabile spostarla in un database dedicato per semplificarne la gestione, ad esempio per eseguire più rapidamente le operazioni di backup e ripristino.

Quando si crea l'applicazione Web per i siti dei team nella pagina Gestisci database del contenuto, modificare le impostazioni per il primo database del contenuto specificando il numero massimo di raccolte siti corrispondente alle dimensioni massime del database e delle raccolte siti (Numero massimo di siti). Specificare inoltre il valore di soglia per il numero di siti che determina la generazione di un avviso (Avviso numero siti). Quando viene raggiunto il numero di siti che determina la generazione di un avviso, creare un nuovo database con le stesse impostazioni. Quando viene raggiunto il numero massimo di raccolte siti non è più possibile creare nuove raccolte siti nel database. Se non è disponibile un altro database, non sarà possibile creare altri siti.

Eliminare automaticamente i siti inutilizzati

È possibile migliorare il livello di attualità del contenuto dei siti dei team eliminando automaticamente i siti inutilizzati. Ciò consente inoltre di controllare la crescita globale dei siti dei team. Se i siti dei team sono ospitati in un'applicazione Web separata, i siti dei team inutilizzati potranno essere gestiti in modo diverso dai siti personali, ad esempio attendendo per un periodo di tempo più lungo prima di iniziare a ricercare i siti Web inutilizzati.

Per impostazione predefinita, le impostazioni per l'eliminazione automatica dei siti non sono attivate. Per gestire le impostazioni relative all'eliminazione dei siti, nella sezione Gestione siti di SharePoint della pagina Gestione applicazioni fare clic su Conferma utilizzo siti ed eliminazione.

Se si attiva questa caratteristica, le impostazioni predefinite includono:

  • Le notifiche tramite posta elettronica vengono inviate ai proprietari di raccolte siti 90 giorni dopo la creazione della raccolta siti oppure dopo 90 giorni in cui il sito non viene utilizzato. In altre parole, se per 90 giorni un sito non viene confermato come utilizzato, il proprietario del sito riceve una notifica.

  • Il sistema cerca le raccolte siti non confermate e invia avvisi ogni giorno a mezzanotte.

  • L'opzione relativa all'eliminazione automatica delle raccolte siti non confermate non è selezionata. Se tale impostazione viene selezionata, i siti verranno eliminati automaticamente dopo l'invio di 28 avvisi. In alternativa, è possibile specificare il numero di avvisi.

In base alle impostazioni predefinite, una raccolta siti che rimane inutilizzata per 90 giorni viene eliminata dopo 28 avvisi, ovvero 118 giorni dopo l'ultima conferma dell'utilizzo del sito. È possibile modificare tali impostazioni specificando valori più appropriati per l'organizzazione. Poiché il funzionamento di questa caratteristica si basa sulle conferme, e non sul monitoraggio dell'utilizzo effettivo del sito, è necessario prevedere eventuali assenze non pianificate dei proprietari dei siti ed evitare di impostare gli intervalli di scadenza ed eliminazione per i siti di breve durata. È inoltre necessario scegliere più amministratori per ogni raccolta siti, in modo che sia sempre presente un sostituto in grado di confermare l'utilizzo del sito, se l'amministratore principale della raccolta siti rimane assente per un periodo di tempo prolungato.

L'eliminazione automatica dei siti semplifica il controllo dell'ambiente, ma può determinare l'eliminazione automatica di dati critici per l'azienda. Per attenuare tale rischio, è consigliabile:

  • Richiedere un contatto secondario per tutti i siti. In tal modo, se il proprietario del sito non è raggiungibile o lascia l'organizzazione sarà comunque disponibile un contatto in grado di confermare che il sito è ancora in uso. Se non è disponibile un contatto secondario e si riduce il numero dei giorni o degli avvisi inviati prima dell'eliminazione di un sito inutilizzato, si rischia di eliminare accidentalmente un sito necessario. Implementare questo consiglio quando si attiva Gestione siti in modalità self-service o come processo aziendale per la creazione di raccolte siti tramite Amministrazione centrale.

  • Archiviare i siti prima che vengano eliminati automaticamente. Molte organizzazioni che implementano l'eliminazione automatica dei siti inutilizzati investono anche nello sviluppo di uno strumento in grado di archiviare tutti i siti prima che vengano eliminati automaticamente, in modo che possano essere ripristinati facilmente nel caso in cui contengano informazioni critiche per l'azienda. In alternativa, è possibile pianificare l'archiviazione a lungo termine per i database del contenuto, per avere la possibilità di ripristinare i siti eliminati in un momento successivo.

Utilizzare percorsi o nomi host per organizzare gli URL dei siti dei team

A seconda dell'organizzazione e delle modalità di utilizzo dei siti dei team, per organizzare gli URL dei siti dei team può essere consigliabile utilizzare i percorsi. Se ad esempio si desidera utilizzare URL diversi per i siti dei team associati a divisioni diverse, sarà possibile utilizzare URL quali http://nome_società/nome_divisione/sites o http://nome_società/research/sites. In alternativa è possibile creare un'associazione a un sito Intranet pubblicato utilizzando URL quali http://nome_intranet/teamsites. Se si utilizza Gestione siti in modalità self-service, l'URL predefinito per i siti dei team è http://nome_server/sites, ma è possibile utilizzare anche un'inclusione di caratteri jolly per http://nome_server/team o per qualsiasi altro prefisso si desideri utilizzare per i siti dei team.

Nota

Se si decide di utilizzare un'inclusione di caratteri jolly diversa da quella predefinita (/sites), sarà necessario registrarla come personalizzazione per il piano di ripristino di emergenza. Poiché tali informazioni sono archiviate nel database di configurazione, non vengono ripristinate automaticamente e, per ripristinare l'intero ambiente, sarà necessario ricreare manualmente l'inclusione di caratteri jolly.

Per ulteriori informazioni sui percorsi, vedere le risorse seguenti:

Se sono presenti siti dei team utilizzati da un numero elevato di utenti dell'organizzazione, è inoltre possibile creare siti con nome basato sull'host. Se ad esempio il sito Web delle risorse umane è un sito di team e non fa parte del sito Intranet pubblicato, può essere consigliabile creare un sito di team con nome basato sull'host denominato http://hrsite o http://humanresources per tale sito.

Nota

Alcune caratteristiche, ad esempio i nomi host alternativi, non funzionano con le raccolte siti con nome basato sull'host.

Pianificare elementi personalizzati

Le personalizzazioni possono aumentare la complessità dell'ambiente, in particolare se si desidera testare più volte tutti i pacchetti di soluzioni, ovvero prima della distribuzione, quando è necessario applicare un aggiornamento e quando si è pronti ad aggiornare l'ambiente. È pertanto necessario definire i criteri dell'organizzazione in relazione all'utilizzo di caratteristiche, modelli, web part e altri elementi personalizzati, nonché pianificare tutti gli aspetti correlati alla gestione, al supporto e all'utilizzo di tali elementi nell'ambiente.

  • Gestione   Se si desidera eseguire il backup e il ripristino dell'intero ambiente (ad esempio in uno scenario di ripristino di emergenza o in caso di spostamento dell'hardware), sarà necessario creare i backup di tutti gli elementi personalizzati (ad esempio una web part personalizzata sviluppata per l'ambiente in uso o una definizione di sito personalizzato) e ricordare di riaggiungerli all'ambiente al momento del ripristino. Poiché non è possibile ripristinare il database di configurazione, che contiene tutti i riferimenti a tali elementi personalizzati, è infatti necessario riaggiungerli manualmente all'ambiente ripristinato. Può essere ad esempio necessario riaggiungere le definizioni dei siti personalizzati e installare le web part personalizzate. Se quando si passa a un nuovo server o si ripristina un server si dimentica un elemento personalizzato, è possibile che si verifichino errori nei siti dei team degli utenti e sarà necessario individuare il codice da utilizzare mentre gli utenti rimangono in attesa.

  • Supporto   La presenza di elementi personalizzati nell'ambiente può determinare un aumento del tempo necessario per la risoluzione dei problemi in caso di errore. Ogni file di codice personalizzato è unico, può essere semplice o complesso e può utilizzare memoria aggiuntiva durante l'esecuzione. È pertanto necessario considerare il numero di aree in cui viene utilizzato il codice personalizzato e il suo impatto sul sistema. È inoltre necessario determinare come escludere le personalizzazioni dalla causa principale di un errore durante la risoluzione dei problemi. Se si crea direttamente il codice personalizzato, progettarlo in modo che gli eventuali errori generati dalle personalizzazioni vengano registrati sia nel registro eventi (per gli eventi di Microsoft Operations Manager), sia in qualsiasi altro percorso utilizzato dall'organizzazione per la risoluzione dei problemi, in modo da poter risolvere tali errori.

  • Semplicità di utilizzo   È necessario considerare la semplicità di utilizzo di soluzioni, web part e modelli. Se per i siti dei team del proprio ambiente sono disponibili numerosi modelli personalizzati, al punto che per elencare tutti i modelli e le web part sono necessarie più schermate (ad esempio, 50 è un numero eccessivo per l'identificazione e la scelta dell'elemento da utilizzare), valutare se tutti gli elementi personalizzati nell'elenco sono effettivamente necessari, se è possibile suddividere l'elenco o se è possibile raggruppare più elementi in pacchetti di caratteristiche comuni per semplificarne la ricerca e l'individuazione.

Alcune organizzazioni scelgono di adottare più criteri in relazione alle personalizzazioni. È ad esempio possibile scegliere di utilizzare un sistema a due o tre livelli, in cui il livello 1 consente di utilizzare solo siti privi di personalizzazioni (basati solo su modelli standard), il livello 2 consente l'utilizzo di alcune personalizzazioni (con un contratto di servizio diverso) e il livello 3 consente ai proprietari dei siti dei team di eseguire e gestire propri ambienti personalizzati utilizzando l'hardware disponibile nell'organizzazione. Anche in questo caso è consigliabile ospitare i siti dei team in più applicazioni Web, con contratti di servizio diversi per ogni applicazione Web.

Pianificare le autorizzazioni da applicare ai siti dei team

Le autorizzazioni e i criteri applicati ai siti dei team determinano:

  • Gli utenti autorizzati a creare i siti dei team.

  • Gli utenti autorizzati a visualizzare i siti dei team e a collaborare alla realizzazione del contenuto.

  • Gli utenti non autorizzati ad accedere al contenuto dei siti dei team.

È consigliabile utilizzare i gruppi di protezione per gestire le autorizzazioni. La tabella seguente contiene informazioni per la configurazione delle autorizzazioni e indica dove si configurano le autorizzazioni.

Autorizzazione Informazioni Configuration

Creazione di raccolte siti dei team

Per impostazione predefinita, solo i membri del gruppo Amministratori farm possono creare raccolte siti per i siti dei team.

Se desidera estendere anche ad altri utenti l'autorizzazione a creare raccolte siti dei team, utilizzare la caratteristica Gestione siti in modalità self-service in Amministrazione centrale. Per ulteriori informazioni, vedere Processo di pianificazione per la creazione di siti (Office SharePoint Server).

In alternativa, è possibile attivare Gestione siti in modalità self-service per un sottoinsieme di utenti dell'organizzazione, attivando Gestione siti in modalità self-service ma limitando l'autorizzazione Creazione siti in modalità self-service a uno o più gruppi di protezione, oppure limitando a gruppi di protezione specifici l'accesso alla pagina Nuovo sito di SharePoint di (Scsignup.aspx).

Nella sezione Protezione applicazione della pagina Gestione applicazioni del sito Amministrazione centrale fare clic su Gestione siti in modalità self-service.

Gli utenti e i gruppi che dispongono dell'autorizzazione Creazione siti in modalità self-service possono creare raccolte siti quando la caratteristica Gestione siti in modalità self-service è attivata.

Creare siti secondari nelle raccolte siti

Per impostazione predefinita, i membri di un sito di team che dispongono dell'autorizzazione Creazione siti secondari (inclusa nel livello di autorizzazione Controllo completo) possono creare siti secondari nell'ambito di una raccolta siti. È consigliabile consentire ai proprietari dei siti di gestire le autorizzazioni relative alla creazione dei siti secondari, anziché impedire globalmente agli utenti di creare siti secondari.

Nella pagina Impostazioni sito aggiungere o eliminare membri nel gruppo dei proprietari.

Visualizzare i siti dei team e collaborare alla realizzazione del contenuto

Anche se un dipendente non è autorizzato a creare un sito di team, può comunque visualizzare e collaborare alla realizzazione dei documenti in altri siti del team, in base alle autorizzazioni applicate dai proprietari di tali siti. È consigliabile consentire ai proprietari dei siti di gestire le autorizzazioni relative al contenuto dei relativi siti, anziché impedire globalmente agli utenti di partecipare collaborando alla realizzazione dei documenti.

Nella pagina Impostazioni sito aggiungere o eliminare membri nel gruppo dei visitatori.

Impedire l'accesso al contenuto dei siti dei team

È possibile impedire l'accesso al contenuto dei siti dei team a tutti gli utenti dell'organizzazione contemporaneamente, creando un criterio per l'applicazione Web. Utilizzare questa opzione con attenzione, perché impedisce agli utenti bloccati qualsiasi tipo di collaborazione nei siti dei team. I criteri impostati a livello di applicazione Web sostituiscono tutte le altre autorizzazioni configurate all'interno dell'applicazione Web.

Nella sezione Protezione applicazione della pagina Gestione applicazioni fare clic su Criteri per l'applicazione Web. Nella pagina Criteri per l'applicazione Web selezionare gli utenti che si desidera bloccare, fare clic su Modifica autorizzazioni utenti selezionati e quindi nella sezione Livelli di criteri di autorizzazione della pagina Modifica utenti selezionare Nega tutto.

Scaricare il manuale

Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:

Per un elenco completo dei manuali disponibili che è possibile scaricare per Office SharePoint Server 2007, vedere Downloadable content for Office SharePoint Server 2007 (informazioni in lingua inglese).