Distribuzione degli aggiornamenti di SharePoint Server 2010 in siti critici

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo viene descritto un aggiornamento da build a build in cui viene utilizzato l'approccio basato sul collegamento di database per distribuire un aggiornamento software in una farm di Microsoft SharePoint Server 2010.

Contenuto dell'articolo:

• Introduzione

• Obiettivi della strategia di aggiornamento

• Panoramica concettuale del collegamento di database

• Fasi, indicazioni e attività chiave dell'aggiornamento

• Automazione come parte di una strategia di aggiornamento

• Approccio passo-passo logico per un aggiornamento basato sul collegamento di database in una singola farm

• Approccio passo-passo logico per un aggiornamento basato sul collegamento di database in una farm federata

• Appendice A. Opzioni di aggiornamento supportate

• Appendice B. Configurazione di un database SQL Server di sola lettura

• Appendice C. Indicazioni per la distribuzione di personalizzazioni

• Appendice D. Tecniche per la replica del contenuto e dei dati della farm

• Appendice E. Riferimento della migrazione di applicazioni di servizio

• Appendice F. Risorse di automazione

• Appendice G. Risorse aggiuntive

Introduzione

Nel corso della durata di un ambiente SharePoint Server 2010 tipico, sarà necessario installare uno o più aggiornamenti software, in genere sotto forma di un aggiornamento cumulativo o di un service pack. Attraverso la selezione del metodo di aggiornamento appropriato, la creazione di un piano di distribuzione dettagliato, l'automazione tramite script e l'esecuzione di test estesi è possibile garantire che la distribuzione di un aggiornamento software soddisferà i requisiti dell'organizzazione in termini di disponibilità, esperienza utente e rollback, se necessario.

In questo articolo viene illustrato come distribuire un aggiornamento software in una singola farm e in una farm federata utilizzando il metodo basato sul collegamento di database per un aggiornamento da build a build dei server della farm.

Informazioni sugli aggiornamenti software

È importante comprendere che la distribuzione di aggiornamenti in un ambiente SharePoint Server 2010 è un processo in due fasi, ovvero l'applicazione di patch e l'aggiornamento. In questo articolo viene utilizzato il termine patch per differenziare l'applicazione dell'aggiornamento del software dall'effettiva esecuzione dell'aggiornamento del software.

Per ogni fase sono previsti passaggi e risultati specifici. È possibile rimandare la fase di aggiornamento, ma se l'aggiornamento viene rimandato di diversi giorni potrebbe derivarne un comportamento incoerente della farm. Più si rimanda l'aggiornamento, più aumenta il rischio che si verifichino problemi di comportamento della farm.

Fase di applicazione delle patch

Questa fase prevede due passaggi, ovvero l'applicazione delle patch e la distribuzione. Durante il passaggio di applicazione delle patch, nuovi file binari vengono copiati nel server di Amministrazione centrale. I servizi che utilizzano file da sostituire vengono temporaneamente arrestati. Con tale arresto dei servizi, si evita di dover riavviare il server per sostituire i file in uso. Vi sono tuttavia alcuni casi in cui è necessario riavviare comunque il server.

Il secondo passaggio di questa fase è la distribuzione. Nel corso di tale passaggio il programma di installazione copia i file di supporto nelle directory appropriate del server che esegue Microsoft SharePoint Server. Questo passaggio garantisce che tutte le applicazioni Web eseguano i file binari corretti e che funzionino correttamente dopo l'installazione dell'aggiornamento. La fase di applicazione delle patch può considerarsi completata dopo il passaggio di distribuzione.

La fase successiva, nonché finale, della distribuzione degli aggiornamenti software è la fase di aggiornamento.

Fase di aggiornamento

Al termine della fase di applicazione delle patch, è necessario completare l'installazione degli aggiornamenti avviando la fase di aggiornamento. Questa fase prevede diverse attività, pertanto richiede la maggior parte del tempo. La prima operazione consiste nell'aggiornare tutti i processi di SharePoint Server in esecuzione. Dopo l'aggiornamento dei processi, i database vengono sottoposti a ricerca per indicizzazione e aggiornati. Poiché il processo di aggiornamento può essere eseguito in un solo server, gli altri server della farm possono continuare a gestire le richieste.

Obiettivi della strategia di aggiornamento

È consigliabile utilizzare la strategia di aggiornamento software descritta in questo white paper per le farm di SharePoint che supportano applicazioni critiche. Tali applicazioni sono in genere definite come quelle necessarie per il normale funzionamento di un'attività. La mancata disponibilità di un'applicazione o l'impossibilità di completare un aggiornamento entro un periodo di tempo specifico, anche detto obiettivo del tempo di ripristino (RTO, Recovery Time Objective), ha effetti significativi sull'attività di un'impresa. È possibile, ad esempio, che ne siano influenzati i guadagni, i requisiti normativi e gli obblighi contrattuali.

La strategia di aggiornamento presentata è progettata per soddisfare gli obiettivi seguenti, che sono anche indicatori chiave di un aggiornamento corretto.

• Ridurre e gestire il tempo di inattività: la strategia dovrebbe cercare di ripristinare il servizio completo agli utenti nel più breve tempo possibile per ridurre l'impatto sugli utenti, garantire un livello elevato di soddisfazione degli utenti e rispettare i contratti di servizio attraverso la gestione efficiente del tempo di inattività.

• Offrire la recuperabilità: se si verifica un errore irreversibile durante un aggiornamento, gli amministratori devono ripristinare la farm e le applicazioni allo stato precedente all'aggiornamento nel minor tempo possibile per ripristinare il servizio completo agli utenti.

• Fornire la coerenza: dopo l'aggiornamento, tutti i server in cui viene eseguito Microsoft SharePoint Server devono essere aggiornati allo stesso livello di versione e disporre della stessa configurazione. Un ambiente incoerente può avere come probabile conseguenza tempi di inattività, errori e problemi non pianificati.

• Fornire la funzionalità prevista: dopo l'aggiornamento, la farm deve trovarsi nello stato funzionale previsto, incluse le funzionalità esistenti prima dell'aggiornamento software e qualsiasi funzionalità nuova o migliorata prevista con l'installazione del service pack o dell'aggiornamento cumulativo.

Panoramica concettuale del collegamento di database

Per soddisfare gli obiettivi dichiarati, ovvero il tempo di inattività ridotto e gestito con efficienza, nonché la possibilità di recuperare uno stato precedente all'aggiornamento, è necessario utilizzare l'approccio basato sul collegamento di database. Questo approccio offre il livello più alto di disponibilità durante l'aggiornamento software e il minor grado di rischio rispetto all'altro metodo supportato, l'aggiornamento sul posto.

Per ulteriori informazioni sulle opzioni di aggiornamento, vedere Appendice A. Opzioni di aggiornamento supportate, in cui viene presentato un confronto dettagliato dei due metodi di aggiornamento e un diagramma di flusso che evidenzia le decisioni, utili per determinare quale approccio di aggiornamento sia più adeguato. Nel diagramma di flusso viene anche fornita una panoramica dei passaggi necessari per l'installazione di un aggiornamento software.

Descrizione

L'approccio basato sul collegamento di database prevede la creazione di un duplicato della farm di produzione che verrà aggiornata con il service pack e l'aggiornamento cumulativo. La nuova farm, che verrà denominata bNext (build successiva), include l'infrastruttura, le applicazioni e i dati della farm di produzione. La farm bNext viene aggiornata, senza contenuto, alla build desiderata e quindi i database del contenuto vengono collegati. Nel diagramma seguente viene illustrata una versione abbreviata dell'approccio basato sul collegamento di database, in cui bCurrent (build corrente) è la farm esistente e bNext è la copia della farm bCurrent.

Facendo riferimento all'illustrazione precedente, è importante notare che è possibile aggiornare più database in parallelo. Questa possibilità consente di ridurre notevolmente il tempo di inattività durante l'aggiornamento.

Fasi, indicazioni e attività chiave dell'aggiornamento

Il processo di aggiornamento basato sul collegamento di database è costituito dalle seguenti fasi principali:

• Test dell'aggiornamento in un ambiente di preproduzione

• Provisioning della nuova farm

• Blocco della farm di produzione

• Replica del contenuto e dei dati di produzione

• Aggiornamento della nuova farm con il contenuto e i dati di produzione

• Completamento dell'aggiornamento nella nuova farm

• Convalida dell'aggiornamento nella nuova farm

• Ripristino del servizio completo

Test dell'aggiornamento in un ambiente di preproduzione

Prima di iniziare l'aggiornamento completo, è importante testare tutti gli aspetti dell'aggiornamento e i risultati in un ambiente di preproduzione. Dopo la creazione dell'ambiente di preproduzione, è consigliabile testare gli aspetti e gli elementi seguenti dell'aggiornamento pianificato.

In teoria, la farm utilizzata nell'esempio di test di preproduzione è un duplicato della farm di produzione. Non si tratta tuttavia di un requisito obbligatorio. In genere, non è possibile applicare alle farm di preproduzione la stessa scalabilità orizzontale della farm di produzione. È possibile, ad esempio, che siano presenti solo due server Web front-end anziché tre o quattro e i database della farm non sono configurati per la disponibilità elevata. Ciò che è importante è disporre di un ambiente di test adeguato per eseguire test completi dell'aggiornamento e dei possibili effetti sull'ambiente di produzione.

È possibile utilizzare nuovamente l'infrastruttura della farm di preproduzione per la farm bNext. Come procedura consigliata, è opportuno che i server utilizzati per i test di preproduzione siano cancellati, incluso il sistema operativo. Ricompilarli per la nuova farm. La pulizia dei server non è obbligatoria, tuttavia se si sceglie di riutilizzare la farm di preproduzione, verificare di avere rimosso tutti gli elementi dell'ambiente di test di preproduzione. Per ulteriori informazioni, vedere Pulizia dell'ambiente prima dell'aggiornamento (SharePoint Server 2010) (https://go.microsoft.com/fwlink/?linkid=225682&clcid=0x410).

Dopo la creazione dell'ambiente di preproduzione, è consigliabile testare gli aspetti e gli elementi seguenti dell'aggiornamento pianificato.

• Rivedere le istruzioni fornite con l'aggiornamento cumulativo o il service pack. Un aggiornamento software può prevedere passaggi aggiuntivi o soluzioni alternative richieste per l'aggiornamento.

• Rivedere il piano e gli elenchi di controllo per l'aggiornamento. Utilizzare il test di preproduzione per convalidare e modificare i documenti di pianificazione dell'aggiornamento. È consigliabile utilizzare l'articolo Elenco di controllo per l'aggiornamento basato sul collegamento di database (SharePoint Server 2010) come guida per la distribuzione di un aggiornamento software.

• Testare il comportamento della farm corrente in modalità di sola lettura. Durante il processo di spostamento del contenuto della farm e dei dati delle applicazioni di servizio nella farm bNext, la farm esistente si trova in uno stato di sola lettura. Completare i test funzionali nella farm esistente per verificare che l'esperienza utente sia accettabile durante l'aggiornamento. È consigliabile consultare l'articolo User experience on read-only sites (SharePoint Server 2010) prima di bloccare la farm di produzione come parte del processo di pianificazione dell'aggiornamento.

• Utilizzare l'automazione per il provisioning delle farm. È consigliabile sfruttare i vantaggi dell'automazione, quando possibile, anziché utilizzare i processi manuali per creare gli ambienti di preproduzione e bNext. Con l'automazione si garantisce la coerenza della configurazione tra i server della farm e si evitano gli errori che si possono verificare nel provisioning manuale dei server. Testare gli script, gli strumenti e i processi correlati all'automazione.

  Utilizzare le raccolte di script disponibile in Appendice F. Risorse di automazione come guide per lo sviluppo di un'automazione personalizzata per l'ambiente. In questi script viene utilizzato Windows PowerShell 2,0 per distribuire SharePoint Server e configurare una farm.

• Definire un benchmark per la finestra del tempo di inattività. È importante sapere quanto tempo richiederà l'aggiornamento. L'elemento più importante è il tempo durante il quale la farm di produzione sarà in modalità di sola lettura. Utilizzare queste informazioni per rivedere il piano di aggiornamento, se necessario.

• Verificare i risultati dell'aggiornamento. Verificare che i risultati dell'aggiornamento siano quelli previsti e individuare i bug di regressione che potrebbero richiedere una soluzione.

Provisioning della nuova farm

La farm bNext, con l'aggiornamento software installato, è la versione aggiornata della farm di produzione corrente. Quando si esegue il provisioning della farm bNext, crearla come duplicato dell'ambiente di produzione corrente. Ciò include, ad esempio, la topologia della farm, il numero di siti, le specifiche dei server (fisiche o virtuali), gli account di accesso e le impostazioni di sicurezza. È consigliabile non implementare alcuna modifica alla progettazione fisica perché le modifiche possono complicare l'aggiornamento e introdurre elementi sconosciuti, con un conseguente aumento del fattore di rischio per l'aggiornamento.

Come per l'ambiente di preproduzione, è consigliabile utilizzare l'automazione per creare e testare la farm bNext. Sfruttando i vantaggi dell'automazione della compilazione, è possibile ridurre la possibilità di errori di configurazione e ridurre i tempi di compilazione globali. I test automatici, inoltre, agevolano l'individuazione di configurazioni errate che potrebbero compromettere l'aggiornamento.

Prima di continuare, eseguire i test per verificare che la configurazione della farm sia corretta prima di collegare i database del contenuto e creare le applicazioni di servizio.

Blocco della farm di produzione

Dopo il test del processo di aggiornamento e la compilazione della farm bNext, è possibile portare l'ambiente di produzione in modalità di sola lettura per completare l'aggiornamento. Il blocco della farm garantisce la fedeltà del contenuto, impedendo la creazione, l'eliminazione o l'aggiornamento del contenuto nella farm di produzione durante l'aggiornamento.

È necessario impostare lo stato di sola lettura per i database del contenuto almeno durante l'aggiornamento della nuova farm allo stesso livello di build. È anche possibile configurare un'impostazione di sola lettura in qualsiasi database dell'applicazione di servizio che supporti l'esecuzione in modalità di sola lettura. Per ulteriori informazioni, vedere Appendice E. Riferimento della migrazione di applicazioni di servizio.

Per informazioni sulla configurazione di un database in sola lettura, vedere Appendice B. Configurazione di un database SQL Server di sola lettura.

Per informazioni sull'esecuzione di una farm di Microsoft SharePoint Server in sola lettura, vedere Run a farm that uses read-only databases (SharePoint Server 2010).

Replica del contenuto e dei dati di produzione

Per aggiornare la farm bNext utilizzando il metodo basato sul collegamento di database, è necessario installare copie di tutti i database del contenuto e delle applicazioni di servizio nel server di database bNext. Creare un backup dei database nella farm di produzione e quindi copiare le copie di backup in bNext. Nei passaggi successivi i backup verranno ripristinati in bNext e quindi verranno collegati al server di database.

Aggiornamento della nuova farm con il contenuto e i dati di produzione

Dopo avere copiato i backup dei database del contenuto e delle applicazioni di servizio e averli ripristinati nei server dell'ambiente bNext in cui viene eseguito SQL Server, può avere luogo l'effettivo processo di collegamento di database. I passaggi di collegamento e aggiornamento variano da database a database e richiedono tecniche leggermente diverse.

Aggiungere applicazioni di servizio alla nuova farm

Per aggiungere applicazioni di servizio della farm di produzione alla farm bNext, è necessario adottare più metodi. Ciò è dovuto al fatto che molte applicazioni di servizio hanno requisiti specifici per lo spostamento o il ripristino. Non esiste un solo metodo che funzioni per tutte le applicazioni di servizio. Per ulteriori informazioni, vedere Appendice E. Riferimento della migrazione di applicazioni di servizio. Con uno dei metodi seguenti sarà possibile aggiungere un'applicazione di servizio alla farm bNext.

• Collegamento di database: il database dell'applicazione di servizio viene creato ripristinando e collegando il database copiato dalla farm di produzione.

• Ricreazione: l'applicazione di servizio viene ricreata da zero nel nuovo ambiente bNext. È consigliabile utilizzare l'automazione per la migrazione delle impostazioni dalla farm di produzione alla farm bNext.

• Backup e ripristino di SharePoint: viene eseguito il backup dell'applicazione di servizio utilizzando Amministrazione centrale o Windows PowerShell e quindi viene effettuato il ripristino nella farm bNext.

Oltre ai database del contenuto e delle applicazioni di servizio, è necessario creare i database di configurazione seguenti nella farm bNext:

• WSS_Search

• Configurazione di SharePoint

• Contenuto di amministrazione di SharePoint

Aggiungere il database del contenuto alla nuova farm

Prima di collegare il database del contenuto alla nuova farm, verificare che l'applicazione Web di destinazione in cui verrà montato il database non contenga già raccolte siti con percorsi URL in conflitto con le raccolte siti nel database da ripristinare. Collegare il database attenendosi alla procedura seguente:

• Testare il database da montare utilizzando il cmdlet Test-SPContentDatabase.

• Montare il database del contenuto nell'applicazione Web di destinazione utilizzando il cmdlet Mount-SPContentDatabase.

Completamento dell'aggiornamento nella nuova farm

Alcune attività obbligatorie per l'aggiornamento possono avere luogo solo dopo il collegamento e l'attivazione dei database. Tra questi passaggi sono inclusi, ad esempio, i seguenti:

• Verificare la configurazione di SQL Server: verificare che i piani di manutenzione richiesti siano ripristinati e configurati correttamente per la farm bNext. Controllare, ad esempio, i processi di manutenzione per conservare statistiche e indici, processi di backup, mirroring del database e così via.

• Eseguire l'importazione dei profili: è consigliabile avviare un'importazione incrementale dei dati dei profili utente per assicurarsi che il database profili sia aggiornato e che la sincronizzazione dei profili funzioni correttamente nel nuovo ambiente.

• Ricerca per indicizzazione del contenuto: avviare una ricerca per indicizzazione incrementale per verificare che l'indice sia sincronizzato con il database del contenuto aggiornato e che la ricerca per indicizzazione funzioni correttamente.

Convalida dell'aggiornamento nella nuova farm

I test funzionali vengono eseguiti nella farm bNext come ultimo passaggio prima di reindirizzare gli utenti alla nuova farm di produzione. È possibile eseguirli manualmente, ma è consigliabile utilizzare l'automazione che permette test più rigorosi rispetto a quelli manuali. L'automazione, inoltre, garantisce la coerenza dei test in tutti i server della farm.

È consigliabile utilizzare le indicazioni e i passaggi di risoluzione dei problemi riportati negli articoli seguenti per convalidare l'aggiornamento:

• Verificare l'aggiornamento e controllare i siti aggiornati (SharePoint Server 2010)

• Risolvere i problemi relativi all'aggiornamento (SharePoint Server 2010)

Ripristino del servizio completo

Quando la farm bNext è completamente operativa e in grado di accettare le richieste utente, il traffico attualmente indirizzato alla farm di produzione di sola lettura deve essere reindirizzato alla farm bNext. È consigliabile configurare questo reindirizzamento nel bilanciamento del carico, se applicabile. Ciò consente di non modificare gli indirizzi IP virtuali delle applicazioni, aggirando il requisito di effettuare il push delle modifiche DNS nell'ambiente, operazione il cui completamento per tutti i client potrebbe richiedere ore.

Automazione come parte di una strategia di aggiornamento

L'automazione può avere un ruolo fondamentale nella distribuzione degli aggiornamenti software in ambienti SharePoint Server 2010 grandi o complessi. Il provisioning automatico ai server e alle farm consente di ottenere la coerenza delle build tra gli ambienti SharePoint Server correnti e il nuovo ambiente creato come parte dell'aggiornamento. Oltre alla coerenza delle build e alla riduzione degli errori, l'automazione consente di ridurre i tempi di compilazione della farm e, di conseguenza, il tempo di aggiornamento dell'ambiente globale.

In una soluzione di automazione devono essere inclusi gli elementi seguenti:

• Provisioning dell'infrastruttura: se si esegue SharePoint Server 2010 in un ambiente virtuale, questo passaggio include la creazione e il provisioning di macchine virtuali, dischi, reti virtuali e altri componenti dell'infrastruttura di un ambiente virtuale.

• Installazione e configurazione del sistema operativo: include l'installazione e la configurazione automatica di Windows Server e aggiornamenti importanti. È possibile utilizzare più tecniche di distribuzione, incluse le immagini preparate per la distribuzione tramite Utilità preparazione sistema (Sysprep), è possibile utilizzare Servizi di distribuzione Windows e la configurazione del sistema operativo tramite script per automatizzare il provisioning.

• Installazione e configurazione del server: dopo il provisioning del server, è possibile installare e configurare SQL Server e SharePoint Server 2010. È possibile utilizzare gli script di Windows PowerShell 2,0 per installare e configurare entrambi i prodotti. Ricordare di aggiornare i prodotti al livello di versione di aggiornamento corrente; questa operazione può anche essere eseguita tramite gli script.

• Migrazione e ripristino delle applicazioni: l'elemento finale dell'automazione della compilazione della farm bNext consiste nell'automazione della migrazione e dell'aggiornamento dei database, della configurazione dell'applicazione finale e dei test funzionali. Quando si pianificano e si implementano gli script di automazione, considerare gli script per le attività seguenti:

  • Impostazione della modalità di sola lettura per la farm corrente

  • Impostazione della modalità di lettura/scrittura della farm corrente (se è necessario il rollback dell'aggiornamento)

  • Configurazione del bilanciamento del carico

  • Installazione di soluzioni di SharePoint Server personalizzate

  • Spostamento di database dal server di database della farm corrente al server di database aggiornato

  • Montaggio di database nel server di database della farm bNext

  • Test funzionali

Architettura di automazione

Nel modello seguente viene illustrata un'architettura concettuale a più livelli di una soluzione di automazione SharePoint Server.

Al livello più elevato si trova il carico di lavoro di SharePoint Server. Un carico di lavoro rappresenta la funzione logica di un ambiente, ad esempio, un carico di lavoro di gestione del contenuto Web COM. I carichi di lavoro sono costituiti da una o più farm. Nello scenario di gestione del contenuto Web, queste potrebbero essere le farm di produzione e di gestione temporanea. Ogni farm avrà una topologia di server che dipende dal carico di lavoro e dall'ambiente. La configurazione dei server, infine, richiederà l'esecuzione corretta di una o più attività di compilazione. Ad esempio, un'attività di compilazione può essere l'aggiunta del server alla farm.

Se si riduce l'ambiente di destinazione ad attività di compilazione separate, è possibile progettare e compilare script di automazione con ambito limitato, semplificandone la progettazione, la compilazione e la determinazione. Dopo avere eseguito lo unit test di un set di script di attività di compilazione, è possibile utilizzarli in script di orchestrazione di livello superiore o in prodotti di orchestrazione come Opalis, che funziona con Microsoft System Center. Per ulteriori informazioni, vedere la pagina Microsoft Server e piattaforma cloud (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=186236&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Strumenti e risorse di automazione

È possibile automatizzare la distribuzione e la configurazione di un ambiente SharePoint Server con più opzioni di tecnologia. In genere, in una soluzione di automazione verrà utilizzata una combinazione delle tecniche seguenti.

Windows PowerShell 2,0

Windows Server 2008, SharePoint Server 2010 e SQL Server 2008 supportano l'automazione tramite Windows PowerShell. Windows PowerShell è costituito da un linguaggio di scripting e un runtime efficienti e solidi che ne fanno la tecnologia preferita per l'automazione. In Windows PowerShell è anche possibile utilizzare cmdlet specifici del prodotto, chiamate alle API .NET e strumenti da riga di comando.

Strumenti da riga di comando

Windows Server 2008, SharePoint Server 2010 e SQL Server 2008 includono anche strumenti da riga di comando per abilitare la distribuzione e la configurazione automatizzate. Molte opzioni della riga di comando per queste tecnologie, tuttavia, sono deprecate e sostituite con cmdlet di Windows PowerShell. Prima di utilizzare un altro strumento da riga di comando, verificare se è presente un'opzione di Windows PowerShell che sostituisce il comando.

API .NET

In Windows Server 2008, SharePoint Server 2010 e SQL Server 2008 sono utilizzate API supportate, la maggior parte delle quali è accessibile utilizzando Microsoft .NET Framework, per esporre le funzionalità del prodotto. Se la funzionalità di automazione di un determinato prodotto non esiste come cmdlet di Windows PowerShell o strumento da riga di comando, è possibile utilizzare le API del prodotto per ottenere il livello di automazione richiesta.

Raccolte di script esistenti

È possibile utilizzare le raccolte di script seguenti per distribuire SharePoint Server e configurare una farm. È possibile utilizzarle così come sono o come guida per lo sviluppo di script personalizzati per l'ambiente.

• SPModule.zip. Il file SPModule.zip è un esempio non supportato di un modulo di Windows PowerShell scritto dai membri del gruppo di prodotti per SharePoint. È possibile utilizzare il modulo per eseguire semplici attività amministrative correlate all'installazione di una farm di SharePoint. Download di SPModule.zip (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=229657&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

• AutoSPInstaller. Questo progetto è costituito da script di Windows PowerShell 2,0 , un file di input XML e un file batch Windows standard utilizzato per avviare il processo di distribuzione e configurazione. Download del progetto AutoSPInstaller (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=229659&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Run Book Automation

Run Book Automation (RBA) consente di automatizzare completamente il provisioning di un ambiente SharePoint Server. RBA consente di definire, compilare, orchestrare, gestire e creare report sui flussi di lavoro creati per i processi operativi di rete e di sistema. L'orchestrazione consente di eseguire attività di compilazione in un determinato ordine come parte di un flusso di lavoro che può includere una logica complessa di dipendenze e convalida. L'approccio consigliato per implementare l'orchestrazione consiste nell'utilizzare un prodotto come Opalis, ma è possibile utilizzare altri prodotti e tecniche a questo scopo.

Approccio passo-passo logico per un aggiornamento basato sul collegamento di database in una singola farm

La topologia della farm nell'illustrazione seguente mostra una tipica farm a tre livelli che offre disponibilità elevata.

Facendo riferimento all'illustrazione precedente, osservare quanto segue:

• I due server Web front-end (WEB-1 e WEB-2) hanno il carico bilanciato insieme e sono in rotazione con il bilanciamento del carico. In questi server è in esecuzione Windows Server 2008 R2, aggiornato allo stesso livello di versione della farm bCurrent.

• Vengono utilizzati due server applicazioni (APP-1 e APP-2) per fornire disponibilità elevata per la ricerca. Il terzo server, APP-3, ospita Amministrazione centrale e le applicazioni di servizio. In questi server viene eseguito Windows Server 2008 R2, aggiornato allo stesso livello di versione della farm bCurrent.

• Il server di database della farm (DB-1) dispone di mirroring (DB-2) per fornire disponibilità elevata. In questi server sono in esecuzione Windows Server 2008 R2 e Microsoft SQL Server 2008 R2, aggiornati allo stesso livello di versione della farm bCurrent.

Passaggi di aggiornamento per una singola farm

L'approccio passo-passo per distribuire un aggiornamento di SharePoint è diviso in due parti. La prima parte si applica all'ambiente di preproduzione. Le attività della seconda parte riguardano la creazione e la configurazione della nuova farm (bNext).

Farm di preproduzione

Nei passaggi seguenti viene illustrato come configurare la farm di test di preproduzione.

1. Creare una farm di test che contiene i componenti principali della topologia della farm di produzione. Considerare l'utilizzo dell'automazione per il provisioning del server e la distribuzione della farm. Le lezioni apprese possono agevolare l'implementazione dell'automazione per la farm bNext.

   Per i test di preproduzione, è sufficiente il numero minimo di server richiesti per l'esecuzione di test. Sulla base dello scenario della farm singola illustrato in precedenza, i server seguenti costituiscono il requisito minimo per i test di preproduzione:

   • Due server Web front-end. Si tratta del requisito minimo per il bilanciamento del carico.

   • Un server applicazioni. Se la ridondanza non è richiesta per i test, è possibile utilizzare questo server per Amministrazione centrale e tutti i servizi installati nella farm di produzione.

   • Un server di database. Se la ridondanza non è richiesta per i test, un server di database con mirroring non è necessario.

2. Configurare la farm di test in base alla configurazione della farm bCurrent. Utilizzare i passaggi seguenti come guida per il provisioning di una farm di test e quindi completare un set minimo di test di preproduzione.

   Importante

   È necessario personalizzare la topologia di test e i test in base all'ambiente di produzione.

   • Ripristinare un backup completo del contenuto della farm di produzione nella farm di test. Raccogliere informazioni benchmark, ad esempio i tempi richiesti per la copia di file o per il ripristino dei backup, che sarà possibile utilizzare per pianificare l'aggiornamento.

   • Installare una copia delle applicazioni e delle personalizzazioni presenti nella farm di produzione. Registrare eventuali dati benchmark che sarà possibile utilizzare per la pianificazione, l'aggiornamento e la risoluzione dei problemi. Per informazioni sulle personalizzazioni, vedere Determinare la modalità di gestione delle personalizzazioni (SharePoint Server 2010).

3. Scaricare una copia dell'aggiornamento software e preparare l'origine di installazione. Ottenere l'aggiornamento software e preparare l'origine di installazione (attività facoltativa). È possibile utilizzare questa origine di installazione per i test di preproduzione e per l'installazione dell'aggiornamento nella farm bNext.

4. Testare l'aggiornamento software. Verificare che le funzionalità di SharePoint Server previste siano presenti dopo l'installazione dell'aggiornamento software, ossia che non siano presenti bug di regressione.

5. Monitorare la funzionalità della farm di produzione. Monitorare la funzionalità della farm di produzione quando i database del contenuto e dell'applicazione di servizio sono impostati in sola lettura.

6. Convalidare processi e strumenti. Convalidare i processi per l'aggiornamento e testare gli strumenti utilizzati per automatizzare i test di aggiornamento o post-aggiornamento.

Farm bNext

Nei passaggi seguenti viene illustrato come eseguire il provisioning e la configurazione della farm bNext per poterla utilizzare in produzione come nuova farm bCurrent.

1. Utilizzare gli script di automazione per il provisioning dei server richiesti per la farm bNext. Nello scenario di questo articolo, sono inclusi i server seguenti: tre server Web front-end, tre server applicazioni e il server di database della farm, con mirroring.

   Il provisioning include l'aggiornamento del sistema operativo almeno allo stesso livello di service pack o di aggiornamento software dei server nella farm di produzione. Se applicabile e corretto, applicare gli ultimi aggiornamenti del sistema operativo ai server bNext.

2. Eseguire il provisioning del server di database bNext. Verranno descritte le attività seguenti:

   • Installare SQL Server e, durante l'installazione, configurarlo in base alle impostazioni della farm di produzione.

   • Aggiornare SQL Server almeno all'ultimo livello di versione della farm di produzione.

   • Copiare gli account di accesso e le autorizzazioni di bCurrent nel server di database bNext.

   • Configurare i servizi richiesti, le impostazioni del firewall e quindi verificare la funzionalità del database.

     Importante

     Non configurare il mirror del database primario finché non è stata eseguita la Configurazione guidata Prodotti e tecnologie SharePoint per completare l'aggiornamento software della farm.

3. Installare i binari di SharePoint Server nei server bNext.

   • Installare SharePoint Server, ma non eseguire la configurazione guidata.

   • Installare i binari dell'aggiornamento cumulativo o del service pack, ma non eseguire la configurazione guidata.

4. Eseguire la Configurazione guidata Prodotti e tecnologie SharePoint per creare una nuova farm.

   Importante

   Non creare alcuna applicazione di servizio. Tali applicazioni verranno create o ripristinate dai backup più avanti nel corso del processo.

   Completare le attività seguenti per preparare bNext come copia della farm di produzione:

   • Configurare le impostazioni generali della farm.

   • Creare e configurare le applicazioni Web.

   • Copiare le soluzioni personalizzate dalla farm bCurrent all'ambiente bNext. Tenere presenti eventuali dipendenze che possono influire sulla corretta distribuzione di queste soluzioni. È possibile, ad esempio, che una dipendenza in un'applicazione di servizio non esista a questo punto nella configurazione della farm. Per ulteriori informazioni, vedere Appendice C. Indicazioni per la distribuzione di personalizzazioni.

5. Eseguire un backup completo dei database della farm di produzione, inclusi i database del contenuto e i database delle applicazioni di servizio che supportano il backup e il ripristino di SQL Server.

6. Iniziare a effettuare backup dei registri delle transazioni descritti nel passaggio precedente. È consigliabile utilizzare i backup dei registri delle transazioni, anziché i backup differenziali per i motivi seguenti:

   • Riduzione dell'esposizione alla perdita del lavoro.

   • Poiché i file di backup sono più piccoli, richiedono meno tempo per il trasferimento nella rete. È inoltre possibile copiare i file di backup nella farm bNext ogni giorno, anziché tutti insieme contemporaneamente.

   • Le dimensioni e il progetto dei file consentono di ripristinare completamente i database di produzione nella farm bNext. Per ulteriori informazioni, vedere Utilizzo dei backup del log delle transazioni (https://go.microsoft.com/fwlink/?linkid=152194&clcid=0x410).

7. Ripristino dei backup completi dei database di produzione nell'ambiente SQL Server di bNext.

   Importante

   Utilizzare l'opzione NORECOVERY per ripristinare i backup in modo da poter ripristinare i backup completi dei registri delle transazioni. Per ulteriori informazioni, vedere Informazioni sul funzionamento dei processi di ripristino e recupero dei backup in SQL Server (https://go.microsoft.com/fwlink/?linkid=134473&clcid=0x410).

8. Impostazione del database del contenuto e database dell'applicazione di servizio appropriati della farm di produzione (bCurrent) in modalità di sola lettura. Tenere presenti i punti seguenti prima di bloccare la farm di produzione:

   • Alcune applicazioni di servizio non supportano la modalità di sola lettura e altre, ad esempio Microsoft SharePoint Server Search e Raccolta dati di utilizzo e integrità, non funzionano se i relativi database sono impostati in sola lettura. Per ulteriori informazioni, vedere Appendice E. Riferimento della migrazione di applicazioni di servizio.

   • Durante il blocco della farm, è possibile che vengano apportate modifiche alle impostazioni di configurazione e alle applicazioni di servizio. Ad esempio, il servizio di ricerca non funziona in modalità di sola lettura, pertanto è possibile che un amministratore modifichi le impostazioni. Questa modifica non verrà trasferita nella nuova farm. È necessario considerare questo punto nella pianificazione, per minimizzare la finestra del tempo di inattività e ridurre la potenziale perdita di dati.

   • Quando un database è impostato in sola lettura, vengono interrotte tutte le connessioni, tranne quella che imposta il flag di sola lettura. Dopo l'impostazione del flag di sola lettura, vengono abilitate altre connessioni.

   • Se la farm esistente dispone di mirroring, come la farm dell'esempio, è necessario sospendere il mirroring prima di impostare i database in sola lettura. Per ulteriori informazioni, vedere Procedure per l'amministrazione del mirroring del database (Motore di database) (https://go.microsoft.com/fwlink/?linkid=225804&clcid=0x410).

9. Completare le attività seguenti per preparare l'installazione di Microsoft SharePoint Server Search nella farm bNext:

   1. Utilizzare il backup di SharePoint per eseguire i backup dei database di ricerca e copiarli nella farm bNext.

   2. Copiare le partizioni dell'indice nei server applicazioni nella farm bNext.

   3. Esportare la topologia di ricerca in un file XML e quindi copiare il file nel server di database bNext.

10. Completare le attività seguenti per ripristinare Microsoft SharePoint Server Search nella farm bNext:

    • A meno che i server bNext non abbiano gli stessi nomi dei server bCurrent, è necessario modificare il file XML che contiene la topologia di ricerca esportata. Modificare il file e fornire nuovi nomi dei server.

    • Utilizzare il cmdlet Restore-SPEnterpriseSearchServiceApplication per ripristinare la ricerca.

11. Ricreare i servizi farm in bNext e, se applicabile, associare i servizi ai database dei servizi applicativi ripristinati dai backup di bCurrent.

12. Installare le soluzioni personalizzate di SharePoint nell'ambiente bNext.

    Importante

    È consigliabile installare le personalizzazioni dopo avere ricreato i servizi perché l'ampiezza e la natura delle personalizzazioni possono avere una dipendenza in un servizio.

13. Completare le attività seguenti dopo avere installato le soluzioni personalizzate:

    • Eliminare tutti i database del contenuto vuoti creati alla prima creazione delle applicazioni Web nella farm bNext.

    • Utilizzare il cmdlet Test-SPContentDatabase per testare i database del contenuto rispetto alle applicazioni Web appena create per verificare che siano state distribuite tutte le personalizzazioni richieste e che non siano presenti problemi.

14. Montare i database del contenuto nella farm bNext utilizzando il cmdlet Mount-SPContentDatabase.

    Importante

    Se sono presenti più database del contenuto, montare prima il database che contiene la raccolta siti radice.

15. Aggiornare i database del contenuto nella farm bNext utilizzando il cmdlet Upgrade-SPContentDatabase.

16. Al termine dell'aggiornamento, completare le seguenti attività del server di database:

    • Ristabilire il mirroring del database se abilitato nella farm bCurrent.

    • Ripristinare e testare tutti i processi di manutenzione del database.

17. Avviare i seguenti processi di SharePoint:

    • Ricerca per indicizzazione

    • Importazione profili

18. Verificare che tutti i servizi richiesti siano in esecuzione.

19. Eseguire test funzionali nella farm bNext per verificare la riuscita dell'aggiornamento. Per ulteriori informazioni, vedere Verificare l'aggiornamento e controllare i siti aggiornati (SharePoint Server 2010).

20. Reindirizzare le richieste utente alla farm bNext. Conservare la farm bCurrent in sola lettura, nel caso sia necessario il rollback dell'aggiornamento.

21. Continuare i test e il monitoraggio della nuova farm bCurrent (bNext) durante il periodo di stabilizzazione definito nel piano di aggiornamento. Quando si ha la certezza che non sia necessario il rollback alla build precedente, è possibile eliminare la farm bCurrent precedente e riciclare i server per utilizzarli per altri scopi.

22. Fare un inventario della configurazione della nuova farm per disporre di informazioni aggiornate da utilizzare per aggiornamenti software futuri.

Approccio passo-passo logico per un aggiornamento basato sul collegamento di database in una farm federata

L'installazione di un aggiornamento di SharePoint Server 2010 in una farm federata richiede una maggiore pianificazione preliminare rispetto all'installazione di un aggiornamento in una singola farm. La filosofia e l'approccio di base all'utilizzo del metodo basato sul collegamento di database per installare un aggiornamento in una farm federata, tuttavia, sono analoghi a quelli per una farm singola. A seconda dell'architettura dell'ambiente federato, possono essere presenti variazioni tra le farm nell'applicazione di patch e nell'aggiornamento dei server della farm.

Ordine di aggiornamento e compatibilità con le versioni precedenti

La domanda più frequente sull'aggiornamento di un ambiente di farm federata riguarda l'ordine di applicazione delle patch e la compatibilità con le versioni precedenti n-1 tra le farm. Per SharePoint Server 2010, è possibile aggiornare le farm di servizi federate in una delle sequenze riportate di seguito:

• Aggiornare prima la farm provider e quindi la farm consumer

• Aggiornare prima la farm consumer e quindi la farm provider

Problemi noti con Microsoft SharePoint Server 2010 con Service Pack 1 (SP1)

Possono verificarsi problemi di compatibilità n-1 nell'applicazione di patch prima alla farm consumer dei servizi senza eseguire la Configurazione guidata Prodotti e tecnologie SharePoint (psconfig.exe) per aggiornare la farm dei servizi provider. Tra i problemi potenziali sono inclusi: mancato funzionamento del servizio di ricerca di SharePoint Server; mancato funzionamento del servizio di indicizzazione di SharePoint Server; mancato funzionamento delle richieste di attestazioni per le soluzioni distribuite agli utenti.

Passaggi di aggiornamento per una farm federata

L'ambiente di farm federata presentato nell'illustrazione seguente viene utilizzato come esempio per mostrare la sequenza e i passaggi necessari per installare un aggiornamento di SharePoint Server in tre farm.

La farm federata dell'illustrazione precedente è costituita dai seguenti elementi:

• Una farm provider di servizi federata con ricerca federata ("Farm provider" nell'illustrazione)

• Due farm consumer federate ("Consumer A" e "Consumer B" nell'illustrazione)

Ai fini dell'illustrazione, la farm provider viene aggiornata prima, seguita dalle due farm consumer.

Prima di continuare con l'aggiornamento della farm provider di servizi, è consigliabile acquisire familiarità con le informazioni e le indicazioni sugli ambienti di preproduzione e il metodo basato sul collegamento del database già illustrati in questo articolo.

Farm provider bNext

Nei passaggi seguenti viene illustrato come eseguire il provisioning e la configurazione della farm provider bNext per poterla utilizzare in produzione come nuova farm provider bCurrent.

1. Utilizzare gli script di automazione per il provisioning dei server richiesti per la farm bNext. Nello scenario di questo articolo, sono inclusi i server seguenti: tre server Web front-end, tre server applicazioni e il server di database della farm, con mirroring.

   Il provisioning include l'aggiornamento del sistema operativo almeno allo stesso livello di service pack o di aggiornamento software dei server nella farm di produzione. Se applicabile e corretto, applicare gli ultimi aggiornamenti del sistema operativo ai server bNext.

2. Eseguire il provisioning del server di database bNext. Verranno descritte le attività seguenti:

   • Installare SQL Server e, durante l'installazione, configurarlo in base alle impostazioni della farm di produzione.

   • Aggiornare SQL Server almeno all'ultimo livello di versione della farm di produzione.

   • Copiare gli account di accesso e le autorizzazioni di bCurrent nel server di database bNext.

   • Configurare i servizi richiesti, le impostazioni del firewall e quindi verificare la funzionalità del database.

     Importante

     Non configurare il mirror del database primario finché non è stata eseguita la Configurazione guidata Prodotti e tecnologie SharePoint per completare l'aggiornamento software della farm.

3. Installare i binari di SharePoint Server nei server bNext.

   • Installare SharePoint Server, ma non eseguire la configurazione guidata.

   • Installare i binari dell'aggiornamento cumulativo o del service pack, ma non eseguire la configurazione guidata.

4. Eseguire la Configurazione guidata Prodotti e tecnologie SharePoint per creare una nuova farm.

   Importante

   Non creare alcuna applicazione di servizio. Tali applicazioni verranno create o ripristinate dai backup più avanti nel corso del processo.

   Completare le attività seguenti per preparare bNext come copia della farm di produzione:

   • Configurare le impostazioni generali della farm.

   • Creare e configurare le applicazioni Web.

   • Copiare le soluzioni personalizzate dalla farm bCurrent all'ambiente bNext. Tenere presenti eventuali dipendenze che possono influire sulla corretta distribuzione di queste soluzioni. È possibile, ad esempio, che una dipendenza in un'applicazione di servizio non esista a questo punto nella configurazione della farm. Per ulteriori informazioni, vedere Appendice C. Indicazioni per la distribuzione di personalizzazioni.

5. Eseguire un backup completo dei database della farm di produzione, inclusi i database del contenuto e i database delle applicazioni di servizio che supportano il backup e il ripristino di SQL Server.

6. Iniziare a creare backup dei registri delle transazioni descritti nel passaggio precedente. È consigliabile utilizzare i backup dei registri delle transazioni, anziché i backup differenziali per i motivi seguenti:

   • Ridurre al minimo l'esposizione alla perdita del lavoro.

   • Poiché i file di backup sono più piccoli, richiedono meno tempo per il trasferimento nella rete. È inoltre possibile copiare i file di backup nella farm bNext ogni giorno, anziché tutti insieme contemporaneamente.

   • Le dimensioni e il progetto dei file consentono di ripristinare completamente i database di produzione nella farm bNext. Per ulteriori informazioni, vedere Utilizzo dei backup del log delle transazioni (https://go.microsoft.com/fwlink/?linkid=152194&clcid=0x410).

7. Ripristino dei backup completi dei database di produzione nell'ambiente SQL Server di bNext.

   Importante

   Utilizzare l'opzione NORECOVERY per ripristinare i backup in modo da poter ripristinare i backup completi dei registri delle transazioni. Per ulteriori informazioni, vedere Informazioni sul funzionamento dei processi di ripristino e recupero dei backup in SQL Server (https://go.microsoft.com/fwlink/?linkid=134473&clcid=0x410).

8. Impostazione del database del contenuto e database dell'applicazione di servizio appropriati della farm di produzione (bCurrent) in modalità di sola lettura. Tenere presenti i punti seguenti prima di bloccare la farm di produzione:

   • Alcune applicazioni di servizio non supportano la modalità di sola lettura e altre, ad esempio Microsoft SharePoint Server Search e Raccolta dati di utilizzo e integrità, non funzionano se i relativi database sono impostati in sola lettura. Per ulteriori informazioni, vedere Appendice E. Riferimento della migrazione di applicazioni di servizio.

   • Durante il blocco della farm, è possibile che vengano apportate modifiche alle impostazioni di configurazione e alle applicazioni di servizio. Ad esempio, il servizio di ricerca non funziona in modalità di sola lettura, pertanto è possibile che un amministratore modifichi le impostazioni. Questa modifica non verrà trasferita nella nuova farm. È necessario considerare questo punto nella pianificazione, per minimizzare la finestra del tempo di inattività e ridurre la potenziale perdita di dati.

   • Quando un database è impostato in sola lettura, vengono interrotte tutte le connessioni, tranne quella che imposta il flag di sola lettura. Dopo l'impostazione del flag di sola lettura, vengono abilitate altre connessioni.

   • Se la farm esistente dispone di mirroring, come la farm dell'esempio, è necessario sospendere il mirroring prima di impostare i database in sola lettura. Per ulteriori informazioni, vedere Procedure per l'amministrazione del mirroring del database (Motore di database) (https://go.microsoft.com/fwlink/?linkid=225804&clcid=0x410).

9. Completare le attività seguenti per preparare l'installazione di Microsoft SharePoint Server Search nella farm bNext:

   1. Utilizzare il backup di SharePoint per eseguire i backup dei database di ricerca e copiarli nella farm bNext.

   2. Copiare le partizioni dell'indice nei server applicazioni nella farm bNext.

   3. Esportare la topologia di ricerca in un file XML e quindi copiare il file nel server di database bNext.

10. Completare le attività seguenti per ripristinare Microsoft SharePoint Server Search nella farm bNext:

    • A meno che i server bNext abbiano gli stessi nomi dei server bCurrent, è necessario modificare il file XML che contiene la topologia esportata. Modificare il file e fornire nuovi nomi dei server.

    • Utilizzare il cmdlet Restore-SPEnterpriseSearchServiceApplication per ripristinare la ricerca.

11. Ricreare i servizi farm in bNext e, se applicabile, associare i servizi ai database dei servizi applicativi ripristinati dai backup di bCurrent.

12. Installare le soluzioni personalizzate di SharePoint nell'ambiente bNext.

    Importante

    È consigliabile installare le personalizzazioni dopo avere ricreato i servizi perché l'ampiezza e la natura delle personalizzazioni può avere una dipendenza in un servizio.

13. Completare le attività seguenti dopo avere installato le soluzioni personalizzate:

    • Eliminare tutti i database del contenuto vuoti creati alla prima creazione delle applicazioni Web nella farm bNext.

    • Utilizzare il cmdlet Test-SPContentDatabase per testare i database del contenuto rispetto alle applicazioni Web appena create per verificare che siano state distribuite tutte le personalizzazioni richieste e che non siano presenti problemi.

14. Montare i database del contenuto nella farm bNext utilizzando il cmdlet Mount-SPContentDatabase.

    Importante

    Se sono presenti più database del contenuto, montare prima il database che contiene la raccolta siti radice.

15. Aggiornare i database del contenuto nella farm bNext utilizzando il cmdlet Upgrade-SPContentDatabase.

16. Al termine dell'aggiornamento, completare le seguenti attività del server di database:

    • Stabilire nuovamente il mirroring del database se abilitato nella farm bCurrent.

    • Ripristinare e testare tutti i processi di manutenzione del database.

17. Avviare i seguenti processi di SharePoint:

    • Ricerca per indicizzazione

    • Importazione profili

18. Verificare che tutti i servizi richiesti siano in esecuzione.

19. Eseguire test funzionali nella farm bNext per verificare la riuscita dell'aggiornamento. Per ulteriori informazioni, vedere Verificare l'aggiornamento e controllare i siti aggiornati (SharePoint Server 2010).

20. Reindirizzare le richieste utente alla farm bNext. Conservare la farm bCurrent in sola lettura, nel caso sia necessario il rollback dell'aggiornamento.

21. Continuare i test e il monitoraggio della nuova farm bCurrent (bNext) durante il periodo di stabilizzazione definito nel piano di aggiornamento. Quando si ha la certezza che non sia necessario il rollback alla build precedente, è possibile eliminare la farm bCurrent precedente e riciclare i server per utilizzarli per altri scopi.

22. Fare un inventario della configurazione della nuova farm per disporre di informazioni aggiornate da utilizzare per aggiornamenti software futuri.

Farm consumer bNext

Nei passaggi seguenti viene illustrato come eseguire il provisioning e la configurazione della farm consumer bNext, "Consumer A" nell'esempio, per poterla utilizzare in produzione come nuova farm consumer bCurrent.

1. Utilizzare gli script di automazione per il provisioning dei server richiesti per la farm bNext. Nello scenario di questo articolo, sono inclusi i server seguenti: tre server Web front-end, tre server applicazioni e il server di database della farm, con mirroring.

   Il provisioning include l'aggiornamento del sistema operativo almeno allo stesso livello di service pack o di aggiornamento software dei server nella farm di produzione. Se applicabile e corretto, applicare gli ultimi aggiornamenti del sistema operativo ai server bNext.

2. Eseguire il provisioning del server di database bNext (CADB-1, CADB-2). Sono incluse le attività seguenti:

   • Installare SQL Server e, durante l'installazione, configurarlo in base alle impostazioni della farm di produzione.

   • Aggiornare SQL Server almeno all'ultimo livello di versione della farm di produzione.

   • Copiare gli account di accesso e le autorizzazioni di bCurrent nel server di database bNext.

   • Configurare i servizi richiesti, le impostazioni del firewall e quindi verificare la funzionalità del database.

     Importante

     Non configurare il mirror del database primario finché non è stata eseguita la Configurazione guidata Prodotti e tecnologie SharePoint per completare l'aggiornamento software della farm.

3. Installare i binari di SharePoint Server nei server bNext.

   • Installare SharePoint Server, ma non eseguire la configurazione guidata.

   • Installare i binari dell'aggiornamento cumulativo o del service pack, ma non eseguire la configurazione guidata.

4. Eseguire la Configurazione guidata Prodotti e tecnologie SharePoint per creare una nuova farm.

   Importante

   Non creare alcuna applicazione di servizio. Tali applicazioni verranno ricreate o ripristinate dai backup più avanti nel corso del processo.

   Completare le attività seguenti per preparare bNext come copia della farm di produzione:

   1. Configurare le impostazioni generali della farm.

   2. Creare e configurare le applicazioni Web.

   3. Copiare le soluzioni personalizzate dalla farm bCurrent all'ambiente bNext. Tenere presenti eventuali dipendenze che possono influire sulla corretta distribuzione di queste soluzioni. È possibile, ad esempio, che una dipendenza in un'applicazione di servizio non esista a questo punto nella configurazione della farm. Per ulteriori informazioni, vedere Appendice C. Indicazioni per la distribuzione di personalizzazioni.

5. Eseguire un backup completo dei database della farm di produzione, inclusi i database del contenuto e i database delle applicazioni di servizio che supportano il backup e il ripristino di SQL Server.

6. Iniziare a creare backup dei registri delle transazioni descritti nel passaggio precedente. È consigliabile utilizzare i backup dei registri delle transazioni, anziché i backup differenziali per i motivi seguenti:

   • Ridurre al minimo l'esposizione alla perdita del lavoro.

   • Poiché i file di backup sono più piccoli, richiedono meno tempo per il trasferimento nella rete. È inoltre possibile copiare i file di backup nella farm bNext ogni giorno, anziché tutti insieme contemporaneamente.

   • Le dimensioni e il progetto dei file consentono di ripristinare completamente i database di produzione nella farm bNext. Per ulteriori informazioni, vedere Utilizzo dei backup del log delle transazioni (https://go.microsoft.com/fwlink/?linkid=152194&clcid=0x410).

7. Ripristino dei backup completi dei database di produzione nell'ambiente SQL Server di bNext.

   Importante

   Utilizzare l'opzione NORECOVERY per ripristinare i backup in modo da poter ripristinare i backup completi dei registri delle transazioni. Per ulteriori informazioni, vedere Informazioni sul funzionamento dei processi di ripristino e recupero dei backup in SQL Server (https://go.microsoft.com/fwlink/?linkid=134473&clcid=0x410).

8. Impostazione del database del contenuto e database dell'applicazione di servizio appropriati della farm di produzione (bCurrent) in modalità di sola lettura. Tenere presenti i punti seguenti prima di bloccare la farm di produzione:

   • Alcune applicazioni di servizio non supportano la modalità di sola lettura e altre, ad esempio Microsoft SharePoint Server Search e Raccolta dati di utilizzo e integrità, non funzionano se i relativi database sono impostati in sola lettura. Per ulteriori informazioni, vedere Appendice E. Riferimento della migrazione di applicazioni di servizio.

   • Durante il blocco della farm, è possibile che vengano apportate modifiche alle impostazioni di configurazione e alle applicazioni di servizio. Ad esempio, il servizio di ricerca non funziona in modalità di sola lettura, pertanto è possibile che un amministratore modifichi le impostazioni. Questa modifica non verrà trasferita nella nuova farm. È necessario considerare questo punto nella pianificazione, per minimizzare la finestra del tempo di inattività e ridurre la potenziale perdita di dati.

   • Quando un database è impostato in sola lettura, vengono interrotte tutte le connessioni, tranne quella che imposta il flag di sola lettura. Dopo l'impostazione del flag di sola lettura, vengono abilitate altre connessioni.

   • Se la farm esistente dispone di mirroring, come la farm dell'esempio, è necessario sospendere il mirroring prima di impostare i database in sola lettura. Per ulteriori informazioni, vedere Procedure per l'amministrazione del mirroring del database (Motore di database) (https://go.microsoft.com/fwlink/?linkid=225804&clcid=0x410).

9. Completare le attività seguenti per preparare l'installazione di Microsoft SharePoint Server Search nella farm bNext:

   • Utilizzare il backup di SharePoint per eseguire i backup dei database di ricerca e copiarli nella farm bNext.

   • Copiare le partizioni dell'indice nei server applicazioni nella farm bNext.

   • Esportare la topologia di ricerca in un file XML e quindi copiare il file nel server di database bNext.

10. Completare le attività seguenti per ripristinare Microsoft SharePoint Server Search nella farm bNext:

    • A meno che i server bNext abbiano gli stessi nomi dei server bCurrent, è necessario modificare il file XML che contiene la topologia esportata. Modificare il file e fornire nuovi nomi dei server.

    • Utilizzare il cmdlet Restore-SPEnterpriseSearchServiceApplication per ripristinare la ricerca.

11. Ricreare i servizi farm in bNext e, se applicabile, associare i servizi ai database dei servizi applicativi ripristinati dai backup di bCurrent.

12. Installare le soluzioni personalizzate di SharePoint nell'ambiente bNext.

    Importante

    È consigliabile installare le personalizzazioni dopo avere ricreato i servizi perché l'ampiezza e la natura delle personalizzazioni può avere una dipendenza in un servizio.

13. Completare le attività seguenti dopo avere installato le soluzioni personalizzate:

    • Eliminare tutti i database del contenuto vuoti creati alla prima creazione delle applicazioni Web nella farm bNext.

    • Utilizzare il cmdlet Test-SPContentDatabase per testare i database del contenuto rispetto alle applicazioni Web appena create per verificare che siano state distribuite tutte le personalizzazioni richieste e che non siano presenti problemi.

14. Montare i database del contenuto nella farm bNext utilizzando il cmdlet Mount-SPContentDatabase.

    Importante

    Se sono presenti più database del contenuto, montare prima il database che contiene la raccolta siti radice.

15. Aggiornare i database del contenuto nella farm bNext utilizzando il cmdlet Upgrade-SPContentDatabase.

16. Al termine dell'aggiornamento, completare le seguenti attività del server di database:

    • Stabilire nuovamente il mirroring del database se abilitato nella farm bCurrent.

    • Ripristinare e testare tutti i processi di manutenzione del database.

17. Avviare i seguenti processi di SharePoint:

    • Ricerca per indicizzazione

    • Importazione profili

18. Verificare che tutti i servizi richiesti siano in esecuzione.

19. Eseguire test funzionali nella farm bNext per verificare la riuscita dell'aggiornamento. Per ulteriori informazioni, vedere Verificare l'aggiornamento e controllare i siti aggiornati (SharePoint Server 2010).

20. Reindirizzare le richieste utente alla farm bNext. Conservare la farm bCurrent in sola lettura, nel caso sia necessario il rollback dell'aggiornamento.

21. Continuare i test e il monitoraggio della nuova farm bCurrent (bNext) durante il periodo di stabilizzazione definito nel piano di aggiornamento. Quando si ha la certezza che non sia necessario il rollback alla build precedente, è possibile eliminare la farm bCurrent precedente e riciclare i server per utilizzarli per altri scopi.

22. Fare un inventario della configurazione della nuova farm per disporre di informazioni aggiornate da utilizzare per aggiornamenti software futuri.

Al termine dei test della farm "Consumer A", ripetere i passaggi precedenti per il provisioning, l'aggiornamento e la configurazione della farm consumer bNext rimanente, "Consumer B" nell'esempio, per poterla utilizzare in produzione come nuova farm consumer bCurrent rimanente.

Conclusioni

Le indicazioni e i passaggi forniti in questo articolo sono applicabili a farm di diverse dimensioni e complessità. Possono inoltre essere utilizzati insieme all'aggiornamento sul posto in uno scenario a più farm. È possibile, e necessario, personalizzare questi passaggi in base all'ambiente. È consigliabile utilizzare questi passaggi e la documentazione dell'esperienza di aggiornamento come modello per l'installazione di aggiornamenti software futuri.

Appendice A. Opzioni di aggiornamento supportate

Come indicato nell'introduzione, sono disponibili due opzioni supportate per l'installazione di aggiornamenti software di SharePoint Server 2010 in uno scenario di aggiornamento da build a build: sul posto e con collegamento del database. Ciascuna opzione presenta vantaggi e svantaggi, che occorre considerare nel contesto dell'ambiente in cui si esegue l'aggiornamento.

Aggiornamento sul posto

Un aggiornamento sul posto ha luogo nello stesso hardware della versione corrente dell'installazione di SharePoint Server. L'aggiornamento software viene installato nei computer in un ambiente di produzione. Quando si utilizza un aggiornamento sul posto, tutti i server nella farm sono aggiornati a un nuovo livello di build come parte di un unico processo fisso.

Vantaggi dell'aggiornamento sul posto

L'aggiornamento sul posto presenta i seguenti vantaggi rispetto al metodo di aggiornamento basato sul collegamento del database:

• Non è necessaria un'infrastruttura aggiuntiva; l'infrastruttura dell'ambiente esistente continua a essere utilizzata dopo l'aggiornamento.

• Le impostazioni a livello di farm vengono mantenute e aggiornate.

• Le personalizzazioni sono disponibili nell'ambiente dopo l'aggiornamento, anche se potrebbero essere necessari alcuni interventi manuali per aggiornarle o modificarle.

Svantaggi dell'aggiornamento sul posto

L'aggiornamento sul posto presenta i seguenti svantaggi rispetto al metodo di aggiornamento basato sul collegamento del database:

• Prolungato tempo di inattività della produzione: l'aggiornamento viene eseguito in modo continuo, di conseguenza è necessario allocare tempo sufficiente per tutto il contenuto da aggiornare in sequenza. La farm di produzione, inoltre, deve essere arrestata per eseguire la parte di aggiornamento dell'installazione. Benché sia possibile utilizzare approcci di aggiornamento dei serve della farm che non prevedono l'interruzione di tutti i server, quando l'aggiornamento viene eseguito nella farm per aggiornare i database, l'intera farm non è disponibile per le richieste di servizio.

• Impossibilità di disinstallare: gli aggiornamento cumulativi e i service pack non possono essere disinstallati se si verifica un errore dell'aggiornamento. L'unico metodo supportato di rollback consiste nel ripristino delle immagini dei server della farm allo stato precedente all'aggiornamento o nella ricompilazione della farm di SharePoint. In entrambi i casi, i database del contenuto devono essere ripristinati dai backup precedenti all'aggiornamento.

• Coerenza tra gli ambienti: a meno che non si eseguano dell'aggiornamento in un ambiente di preproduzione, è possibile che le differenze e gli errori della configurazione causino l'esito negativo dell'aggiornamento. Anche con i test di preproduzione, è possibile riscontrare errori di aggiornamento a causa delle differenze che non sono state rilevate o di errori umani durante il processo di aggiornamento.

Per ulteriori informazioni sull'aggiornamento sul posto, vedere Installare un aggiornamento software (SharePoint Server 2010).

Aggiornamento basato sul collegamento di database

L'aggiornamento basato sul collegamento di database avviene in una nuova farm creata per l'aggiornamento. La farm è un duplicato della farm da aggiornare.

Vantaggi dell'aggiornamento basato sul collegamento di database

L'aggiornamento basato sul collegamento di database presenta i seguenti vantaggi rispetto al metodo di aggiornamento sul posto:

• Per i siti critici e di grandi dimensioni, è garantito un livello di disponibilità durante l'aggiornamento.

• Consente la gestione efficiente del tempo di inattività e quindi un aggiornamento più prevedibile.

• Se si verifica un errore irreversibile durante l'aggiornamento, l'ambiente di produzione esistente è ancora disponibile agli utenti.

Svantaggi dell'aggiornamento basato sul collegamento di database

L'aggiornamento basato sul collegamento di database presenta i seguenti svantaggi rispetto al metodo di aggiornamento sul posto:

• Costo. La strategia è basata sulla duplicazione dell'infrastruttura (fisica o virtuale) e la duplicazione dei dati che aumentano il costo globale dell'aggiornamento.

• Complessità. In termini di configurazione e operazioni, il processo è più complesso rispetto a un aggiornamento sul posto, ad esempio:

  • È necessario creare, aggiornare, configurare e convalidare un ambiente di produzione di SharePoint Server secondario.

  • È necessario ricreare completamente alcune applicazioni di servizio e riconfigurarne altre.

  • È necessario una soluzione di bilanciamento del carico o DNS per reindirizzare gli utenti da una farm a un'altra.

• Benché la farm originale sia disponibile durante l'aggiornamento, questa strategia non garantisce il 100% di disponibilità di lettura/scrittura agli utenti durante l'aggiornamento. La farm di produzione sarà nello stato di sola lettura durante l'aggiornamento. La durata di questo stato dipende dai singoli ambienti e include fattori quali le dimensioni e la complessità dei database e la possibilità di automazione.

Decisioni e processi per gli aggiornamenti software

Nel diagramma di flusso seguente sono illustrate le decisioni chiave da considerare nella pianificazione di un aggiornamento software. Vengono inoltre descritti i processi di alto livello e la relativa sequenza quando si installa un aggiornamento software.

Appendice B. Configurazione di un database SQL Server di sola lettura

L'impostazione di un database SQL Server in sola lettura per l'aggiornamento della farm richiede le azioni seguenti:

• Disabilitare AUTO_UPDATE_STATISTICS_ASYNC

• Arrestare tutti i processi di aggiornamento asincroni delle statistiche in esecuzione

• Impostare il database in modalità utente singolo

• Impostare il database nello stato desiderato (READ_ONLY)

Per ulteriori informazioni, vedere ALTER DATABASE (Transact-SQL) (https://go.microsoft.com/fwlink/?linkid=148619&clcid=0x410). In questo articolo vengono fornite informazioni sulla configurazione di un database in lettura/scrittura, che richiede l'impostazione del database in modalità multiutente e quindi la riabilitazione dell'opzione AUTO_UPDATE_STATISTICS_ASYNC.

Appendice C. Indicazioni per la distribuzione di personalizzazioni

Prestare particolare attenzione per verificare che le personalizzazioni vengano distribuite senza problemi durante l'aggiornamento. Utilizzare le indicazioni seguenti per distribuire le personalizzazioni nella farm di test:

• Testare le personalizzazioni in modalità di sola lettura. Verificare che le personalizzazioni continuino a funzionare o disabilitarle quando la farm viene impostata in sola lettura.

• Testare la distribuzione della soluzione e l'attivazione delle funzionalità. Verificare che le personalizzazioni possano essere distribuite correttamente senza contenuto. I pacchetti delle soluzioni vengono distribuiti come parte del processo di compilazione della farm prima del collegamento dei database. Testare la distribuzione e l'attivazione delle funzionalità dei pacchetti delle soluzioni senza dati.

• Risolvere gli errori prima di tentare l'aggiornamento. consigliabile occuparsi immediatamente dei problemi della personalizzazione riscontrati durante i test. Il metodo basato sul collegamento di database è un processo complesso. L'aggiunta di ulteriore complessità attraverso soluzioni alternative per distribuire le personalizzazioni potrebbe compromettere la riuscita dell'aggiornamento.

Appendice D. Tecniche per la replica del contenuto e dei dati della farm

È possibile utilizzare diverse tecniche per la replica del contenuto e dei dati della farm di produzione per poterli utilizzare in una nuova farm.

Copia di file

Copia tradizionale dei file di ogni database supportato nel nuovo ambiente.

Vantaggi	Svantaggi
Non è richiesto software aggiuntivo Facilità di utilizzo ed esecuzione	L'operazione di copia non viene avviata finché il database non è in modalità di sola lettura. Il tempo richiesto per una copia di file è generalmente maggiore perché è necessario copiare l'intero database in una sola operazione. Dato il tempo richiesto, questo metodo è quello più interessato dalla latenza di rete e dalla perdita di pacchetti.

Backup e ripristino di SQL Server

Questa operazione prevede l'utilizzo di una combinazione di backup completi, differenziali o incrementali di SQL Server per replicare il contenuto di produzione che viene quindi ripristinato nel nuovo ambiente.

Vantaggi

Svantaggi

Funzione intrinseca di SQL Server Un backup incrementale riduce la quantità di dati di cui eseguire il backup e la copia nel momento in cui i database sono in modalità di sola lettura Possibilità di utilizzare la compressione SQL per ridurre il volume di dati da copiare nel nuovo ambiente I backup dovrebbero essere già disponibili (se si seguono le procedure operative consigliate) È possibile un ripristino parziale del nuovo server di database prima di impostare la modalità di sola lettura per i database di produzione

Può richiedere più tempo di altri metodi di replica dei dati L'ultimo backup incrementale deve essere eseguito durante il blocco della produzione

Mirroring del database

Il mirroring del database è una funzionalità di SQL Server in base alla quale le scritture di SQL Server vengono eseguite in due database contemporaneamente. Nella maggior parte dei casi, si adotta questo approccio per la disponibilità elevata del server di database e dei dati. Questo approccio di replica del contenuto per l'aggiornamento richiede che una metà del mirror venga interrotta in modo da consentire la copia e l'aggiornamento dei database con mirroring. Per ulteriori informazioni sul mirroring dei database SQL Server, vedere Mirroring del database (https://go.microsoft.com/fwlink/?linkid=216767&clcid=0x410).

Vantaggi	Svantaggi
Funzione intrinseca di SQL Server Richiede meno tempo tra il blocco della farm di produzione e il ripristino del contenuto nella nuova farm Se lo si desidera, il server di database con mirroring può diventare il server SQL Server primario per la nuova farm. Ciò riduce ulteriormente il tempo di aggiornamento, benché influisca temporaneamente sulla disponibilità elevata	Viene impostato uno stato in cui la farm di produzione non è temporaneamente a disponibilità elevata (a livello SQL/dati) Richiede tempo per ristabilire il mirroring sia per l'aggiornamento riuscito sia per il failback

Log shipping

È possibile utilizzare il log shipping per replicare i registri delle transazioni e fornirli al nuovo ambiente affinché possano essere riprodotti per ricostituire i dati nei server di database. Per ulteriori informazioni, vedere Log Shipping (https://go.microsoft.com/fwlink/?linkid=149021&clcid=0x410)

Vantaggi

Svantaggi

Funzione intrinseca di SQL Server I registri possono essere forniti in più percorsi, ad esempio alla nuova farm e a un percorso di ripristino di emergenza Non ha effetti sulla disponibilità elevata dell'istanza di SQL Server di produzione per l'ambiente di produzione Consente la riproduzione dei registri delle transazioni per ricompilare la maggior parte del corpus dei dati di produzione prima di configurare il contenuto della farm in sola lettura

Richiede monitoraggio e gestione I tempi di replica dei registri possono variare e la latenza di rete ha un effetto notevole sui tempi di log shipping Colloca un carico continuo sul server di produzione

Data Protection Manager o backup e ripristino di terze parti

SQL Server supporta utilità di backup Microsoft e di terze parti che consentono di ridurre i tempi di backup e migliorare l'efficienza di archiviazione. Per informazioni su Microsoft System Center Data Protection Manager, vedere il sito Web Microsoft Server e piattaforma cloud (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=179139&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Vantaggi	Svantaggi
Operazioni di backup e ripristino più veloci del metodo di backup e ripristino nativo di SQL Server Efficienza di archiviazione migliorata	Richiede licenze aggiuntive Richiede infrastruttura aggiuntiva Non tutti gli scenari possono essere supportati dall'utilità, ad esempio i servizi remoti di .NET Framework

Appendice E. Riferimento della migrazione di applicazioni di servizio

Nella tabella seguente vengono descritti i metodi supportati per lo spostamento di ogni applicazione di servizio di SharePoint Server in un altro server di database.

Applicazione di servizio	Database	Approccio supportato	Supporta la modalità di sola lettura	Note
Access Services	Nessuna	non disponibile	non disponibile
Servizio di individuazione applicazioni e bilanciamento del carico	Nessuno	non disponibile	non disponibile
Servizio Registro applicazioni	Servizio Registro applicazioni	Ricreare	No
Integrazione applicativa dei dati	Integrazione applicativa dei dati	Collegamento di database Ricreare
Excel Services	nessuno	non disponibile	non disponibile
Impostazioni di sottoscrizione di Microsoft SharePoint Foundation	Sottoscrizione	Collegamento di database
Servizio metadati gestiti	Servizio metadati gestiti	Collegamento di database Ricreare
PerformancePoint Services	PerformancePoint Services	Ricreare
Servizio di PowerPoint	Nessuno	non disponibile	non disponibile
Applicazione del servizio Project Server	Draft Published Archive Reporting	Collegamento di database	No	Richiede la sincronizzazione tra i database È necessario configurare timestamp o contrassegno del registro Per ulteriori informazioni, vedere Aggiornamento completo basato sul collegamento di database a Project Server 2010
Ricerca di SharePoint Server	Amministrazione ricerca Ricerca per indicizzazione Proprietà	Ricreare Backup e ripristino di SharePoint	No	Le partizioni dell'indice vengono copiate nella nuova farm e quindi ripristinate nel nuovo server di database. La topologia di ricerca viene esportata e quindi ripristinata nel nuovo server.
Archiviazione sicura	Archiviazione sicura	Collegamento di database Ricreare		La passphrase per il nuovo database deve essere identica al database di origine.
Servizio token di sicurezza		Ricreare
Servizio informazioni sullo stato	Stato	Ricreare	No
Raccolta dati di integrità e utilizzo	Registrazione	Ricreare	No
Profili utente	Profilo Sincronizzazione Social tagging	Collegamento di database Ricreare		Il profilo richiede il ripristino di una chiave FIM crittografata
Servizio grafica di Visio	Nessuno	non disponibile	non disponibile
Servizio Web Analytics	Gestione temporanea Reporting	Collegamento di database Ricreare
Servizio automazione di Word	Servizio automazione di Word	Ricreare	non disponibile
Servizio di visualizzazione di Word	Nessuno	non disponibile	non disponibile

Appendice F. Risorse di automazione

Script

Le raccolte di script seguenti possono essere utilizzate per distribuire SharePoint Server e configurare una farm. È possibile utilizzarli così come sono o come guida per lo sviluppo di script personalizzati per l'ambiente.

• SPModule.zip. Il file SPModule.zip è un esempio non supportato di modulo di Windows PowerShell scritto dai membri del gruppo di prodotti per SharePoint. È possibile utilizzare il modulo per eseguire semplici attività amministrative correlate all'installazione di una farm di SharePoint. Download di SPModule.zip (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=229657&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

• AutoSPInstaller. Questo progetto è costituito da script di Windows PowerShell 2,0, un file di input XML e un file batch Windows standard utilizzato per avviare il processo di distribuzione e configurazione. Download del progetto AutoSPInstaller (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=229659&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Appendice G. Risorse aggiuntive

È consigliabile consultare le risorse seguenti prima e durante l'aggiornamento.

Articolo	Descrizione
Pianificare e preparare l'aggiornamento (SharePoint Server 2010)	Fornisce collegamenti ad articoli che agevolano la pianificazione e la preparazione dell'aggiornamento da Microsoft Office SharePoint Server 2007 a Microsoft SharePoint Server 2010.
Testing e risoluzione dei problemi relativi all'aggiornamento (SharePoint Server 2010)	Fornisce collegamenti ad articoli relativi al test di un aggiornamento e all'utilizzo delle informazioni del test per prevedere il tempo e lo spazio necessari per l'aggiornamento. Gli articoli includono anche passaggi da eseguire per effettuare la pulizia dell'ambiente prima di eseguire un aggiornamento effettivo.
Procedure consigliate per testare l'aggiornamento (SharePoint Server 2010)	Fornisce indicazioni sulle procedure consigliate per eseguire test accurati e utili del processo di aggiornamento.
Elenco di controllo per l'aggiornamento basato sul collegamento di database (SharePoint Server 2010)	Elenco di controllo per tutti i passaggi necessari richiesti per preparare ed eseguire un aggiornamento ed effettuare i passaggi post-aggiornamento.
Eseguire un aggiornamento a SharePoint Server 2010 basato sul collegamento di database	Fornisce collegamenti ad articoli in cui viene descritto come utilizzare il collegamento di database per eseguire un aggiornamento da versione a versione.
Eseguire passaggi di post-aggiornamento per l'aggiornamento basato su collegamento di database (SharePoint Server 2010)	Vengono descritti passaggi aggiuntivi per verificare che l'infrastruttura che supporta tale contenuto sia nuovamente in grado di avviare il servizio delle richieste utente.
Installation reference (SharePoint Server 2010)	Fornisce collegamenti alle informazioni di riferimento relative all'installazione di Microsoft SharePoint Server utilizzando lo strumento da riga di comando Psconfig, Config.xml e Windows PowerShell.