Utilizzare un aggiornamento di prova per individuare possibili problemi (SharePoint Server 2010)

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

Prima di iniziare il processo di aggiornamento da Microsoft Office SharePoint Server 2007 a Microsoft SharePoint Server 2010, è opportuno testare il processo per accertarsi di conoscere tutte le operazioni che è necessario effettuare affinché l'aggiornamento abbia esito positivo. Eseguendo un aggiornamento di prova per testare il processo, è possibile determinare quanto segue:

• Le personalizzazioni di cui si dispone nell'ambiente in uso in modo da poter pianificare la modalità di gestione di tali personalizzazioni durante l'aggiornamento.

• L'eventuale necessità di aggiornare l'hardware in modo da poter eseguire l'aggiornamento in maniera più rapida ed efficiente.

• La frequenza con cui eseguire l'aggiornamento o la durata dell'aggiornamento per l'ambiente in uso.

• Gli elementi per cui eseguire la pianificazione da un punto di vista operativo, ad esempio le risorse da lasciare disponibili.

È inoltre possibile utilizzare l'aggiornamento di prova per acquisire familiarità con gli strumenti di aggiornamento e il processo, in modo da non avere imprevisti durante l'esecuzione del processo vero e proprio. Mediante questo test, è possibile determinare quanto segue:

• I casi speciali che si applicano all'ambiente in uso e il metodo di aggiornamento più efficiente in base alle proprie esigenze.

• L'aspetto dell'interfaccia utente, in modo da sapere esattamente quando termina una fase e ne inizia un'altra.

• Il percorso dei file di registro, la modalità con cui è possibile leggerli e le informazioni in essi contenute.

• Le tecniche che è possibile utilizzare per limitare i tempi di inattività.

In questo articolo vengono illustrate le operazioni di base per testare l'aggiornamento e vengono forniti suggerimenti su come esaminare i risultati e modificare i piani di aggiornamento in base alle informazioni apprese durante i test.

Contenuto dell'articolo:

• Allestire un ambiente di testing

• Identificare e installare le personalizzazioni

• Copiare dati reali nell'ambiente di testing e provare a eseguire l'aggiornamento

• Esaminare i risultati

• Modificare i piani ed eseguire di nuovo il test

Quando si testa il processo di aggiornamento, possono essere utili inoltre le risorse seguenti:

• Foglio di lavoro SharePoint Products 2010 Upgrade Worksheet

  Utilizzare questo foglio di lavoro per registrare le informazioni relative all'ambiente durante il test dell'aggiornamento. Scaricare il foglio di lavoro da https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x410 (le informazioni potrebbero essere in lingua inglese).

• Modello di testing del processo di aggiornamento per Prodotti Microsoft SharePoint 2010

  In questo poster sono rappresentate visivamente le informazioni per il testing del processo di aggiornamento. Scaricarlo da https://go.microsoft.com/fwlink/?linkid=166303&clcid=0x410 (le informazioni potrebbero essere in lingua inglese).

Allestire un ambiente di testing

Per testare il processo di aggiornamento è possibile utilizzare componenti hardware virtuali o fisici. Ogni ambiente è unico, pertanto non vi sono linee guida generali sulla durata dell'elaborazione o sul grado di difficoltà con cui una determinata personalizzazione verrà aggiornata. Il modo migliore per valutare come procederà l'aggiornamento nel proprio ambiente è quello di eseguire una serie di aggiornamenti di prova.

Quando si crea l'ambiente di testing:

• Impostare la farm di testing in modo che sia quanto più possibile simile a quella reale, ad esempio in termini di hardware, software e spazio disponibili.

• Utilizzare nella farm di testing gli stessi URL della farm reale, altrimenti si rischia di perdere tempo a diagnosticare problemi relativi a URL che non si ripresenteranno nell'aggiornamento vero e proprio.

• Fare attenzione a trasferire nell'ambiente di testing tutte le impostazioni e le personalizzazioni. Nella sezione Identificare e installare le personalizzazioni vengono fornite informazioni su come raccogliere tali dati.

Utilizzo di un ambiente di testing virtuale

Quando si esegue il test utilizzando un ambiente virtualizzato, non sono necessari molti componenti hardware. È possibile replicare il proprio ambiente utilizzando solo due server che eseguono Hyper-V. Un server dispone delle immagini per i server Web front-end e i server applicazioni, mentre l'altro server dispone delle immagini per i server database.

Utilizzo di un ambiente di testing fisico

Quando si esegue il test utilizzando un ambiente fisico, è necessario replicare nel modo più fedele possibile l'intero ambiente server farm. Se si riduce eccessivamente il numero dei server Web front-end, dei server applicazioni o dei server database, non sarà possibile stimare accuratamente quale sarà la durata del processo di aggiornamento e si rischia di non tenere conto delle complicazioni derivanti dalle interazioni tra server nello stesso ruolo, ad esempio per le transazioni di SQL Server. Se nella farm originale sono presenti più server in un determinato ruolo, utilizzare almeno due server per quel ruolo nella farm di testing in modo da poter controllare il verificarsi di problemi di questo tipo.

Ambienti di testing aggiuntivi per l'aggiornamento basato sul collegamento di database

Se si utilizza il metodo di aggiornamento basato sul collegamento di database, potrebbe essere necessario creare un ambiente di testing aggiuntivo, ovvero una farm a server singolo che esegue Office SharePoint Server 2007 e che può essere utilizzata per eseguire lo strumento di verifica pre-aggiornamento prima di tentare di aggiornare i dati.

È possibile evitare questo passaggio eseguendo lo strumento di verifica pre-aggiornamento sulla farm di produzione esistente.

Identificare e installare le personalizzazioni

Per testare il processo in modo accurato, è necessario individuare tutte le personalizzazioni presenti nell'ambiente corrente e copiarle nell'ambiente di testing. Per ulteriori informazioni sui tipi di personalizzazioni da identificare, vedere Determinare la modalità di gestione delle personalizzazioni (SharePoint Server 2010).

• Eseguire lo strumento di verifica pre-aggiornamento per identificare le definizioni di sito, i modelli di sito e le funzionalità dell'ambiente in uso.

  Lo strumento di verifica pre-aggiornamento analizza ogni raccolta siti e genera un report sullo stato di ogni sito. Salva inoltre le informazioni relative alle definizioni dei singoli elenchi. È possibile esaminare i report per individuare e risolvere i problemi prima che il processo di aggiornamento abbia inizio. A differenza dello strumento di analisi pre-aggiornamento per Office SharePoint Server 2007, questo strumento è di sola lettura e non apporta modifiche ai siti. Per ulteriori informazioni su questo strumento e sulla procedura di esecuzione, vedere Analisi pre-aggiornamento e segnalazione per le versioni future (Windows SharePoint Services) e Eseguire lo strumento di verifica pre-aggiornamento (SharePoint Server 2010).

• Eseguire l'operazione Stsadm -o enumallwebs su tutti i database del contenuto presenti nell'ambiente Office SharePoint Server 2007 per identificare personalizzazioni specifiche di siti secondari. Questa operazione restituisce un elenco contenente l'ID di ogni raccolta siti e sito secondario del proprio ambiente e i modelli su cui si basa il sito. Questa operazione è stata inizialmente introdotta in Office SharePoint Server 2007 con il Service Pack 2 (SP2). Per ulteriori informazioni, vedere Enumallwebs: operazione Stsadm (Office SharePoint Server).

• Utilizzare uno strumento quale WinDiff, fornito con la maggior parte dei sistemi operativi Microsoft, per confrontare i server dell'ambiente di produzione con quelli della farm di testing. È possibile eseguire questo strumento per vedere quali file sono presenti nei server e in cosa si differenziano.

• Verificare se i file web.config sono stati modificati e cercare nell'elemento SafeControls eventuali controlli personalizzati.

• Utilizzare lo strumento di diagnostica di SharePoint (SPDiag) per trovare le soluzioni distribuite. Per ulteriori informazioni, vedere Strumento di diagnostica di SharePoint (SPDiag).

• Creare un elenco di tutte le personalizzazioni trovate e, se possibile, identificarne l'origine. Stabilire ad esempio se si tratta di componenti aggiuntivi o modelli di terze parti personalizzati internamente. Dopo aver identificato l'origine, è quindi possibile verificare se sono disponibili versioni aggiornate delle personalizzazioni. È disponibile un foglio di lavoro da utilizzare per prendere nota delle informazioni sull'ambiente, in base ai dati risultanti dallo strumento di analisi pre-aggiornamento e dalla ricerca delle personalizzazioni. Scaricare il foglio di lavoro da https://go.microsoft.com/fwlink/?linkid=179928&clcid=0x410 (le informazioni potrebbero essere in lingua inglese) e personalizzarlo in base alle proprie esigenze.

Dopo aver identificato tutte le personalizzazioni, copiarle nei server appropriati della farm di testing. È possibile utilizzare il cmdlet test-spcontentdatabase di Windows PowerShell prima di collegare un database a SharePoint Server 2010 per stabilire se nell'ambiente mancano personalizzazioni. Eseguire questo comando per i singoli database dopo averli ripristinati nel server di database, ma prima di eseguire l'aggiornamento. Si noti che tale cmdlet viene eseguito automaticamente, pertanto non verrà restituito alcun output a meno che non si verifichi un errore.

Copiare dati reali nell'ambiente di testing e provare a eseguire l'aggiornamento

Non è possibile realizzare gli obiettivi del test senza utilizzare dati effettivi. Per creare una copia dei propri dati, è possibile utilizzare i metodi seguenti:

• Per un aggiornamento sul posto, creare un backup della farm e quindi ripristinarlo nell'ambiente di testing. Per ulteriori informazioni, vedere Eseguire il backup e il ripristino di un'intera farm (Office SharePoint Server 2007) (le informazioni potrebbero essere in lingua inglese).

• Per un aggiornamento basato sul collegamento di database, è necessario utilizzare gli strumenti di backup e ripristino di Microsoft SQL Server per creare una copia dei database del contenuto e di tutti gli altri database che si desidera aggiornare. Per ulteriori informazioni, vedere Eseguire il backup e il ripristino dei database (Office SharePoint Server) (le informazioni potrebbero essere in lingua inglese).

Il modo migliore per comprendere ciò che può accadere durante l'aggiornamento è quello di eseguire il test su una copia di tutti i dati, anche se questa può non essere sempre una possibilità realistica per le fasi di test iniziali. È possibile scaglionare il test eseguendolo singolarmente sui diversi database, se di grandi dimensioni, in modo da poter verificare tutti gli aspetti specifici del set di dati in questione oppure è possibile assemblare un sottoinsieme di dati provenienti da siti rappresentativi dell'ambiente. Se per il test si desidera iniziare con un sottoinsieme dei propri dati, tenere presente che tale sottoinsieme deve avere le caratteristiche seguenti:

• Il sottoinsieme di dati deve contenere siti analoghi ai siti supportati nel proprio ambiente.

• Le dimensioni e la complessità del sottoinsieme di dati devono essere molto simili alle dimensioni e alla complessità effettive del proprio ambiente.

Dopo avere copiato i dati, provare una prima volta il processo di aggiornamento per vedere come si svolge. Questa è solo la fase preliminare.

Provare a eseguire un aggiornamento sul posto

Se si desidera provare con il metodo di aggiornamento sul posto, utilizzare la procedura seguente per testare il processo di aggiornamento:

1. Creare un backup della farm.

2. Ripristinare il backup nella farm di testing.

   Per ulteriori informazioni, vedere Eseguire il backup e il ripristino di un'intera farm (Office SharePoint Server 2007) (le informazioni potrebbero essere in lingua inglese).

3. Eseguire lo strumento di verifica pre-aggiornamento e prendere nota degli eventuali problemi rilevati, in modo da poterli risolvere nell'ambiente originale prima di eseguire l'aggiornamento vero e proprio nella farm di produzione. Per ulteriori informazioni, vedere Eseguire lo strumento di verifica pre-aggiornamento (SharePoint Server 2010).

4. Eseguire la procedura illustrata in Eseguire un aggiornamento sul posto (SharePoint Server 2010) per provare l'aggiornamento sul posto.

5. Esaminare i risultati.

Provare a eseguire un aggiornamento basato sul collegamento di database

1. Creare un backup con SQL Server dei database del contenuto e dei database del provider di servizi condivisi.

2. Utilizzare SQL Server per ripristinare i backup nella farm di testing a server singolo e collegare i database del contenuto a tale ambiente.

   Per ulteriori informazioni, vedere Eseguire il backup e il ripristino dei database (Office SharePoint Server) (le informazioni potrebbero essere in lingua inglese).

3. Eseguire lo strumento di verifica pre-aggiornamento e prendere nota degli eventuali problemi rilevati e delle modifiche apportate, in modo da poter risolvere tali problemi e apportare tali modifiche nell'ambiente originale prima di eseguire l'aggiornamento vero e proprio nella farm di produzione. Per ulteriori informazioni, vedere Eseguire lo strumento di verifica pre-aggiornamento (SharePoint Server 2010).

4. Eseguire la procedura illustrata in Preparare il nuovo ambiente di SharePoint Server 2010 per un aggiornamento basato sul collegamento di database per configurare l'ambiente di testing per un aggiornamento basato sul collegamento di database.

5. Eseguire la procedura illustrata in Allegare database ed eseguire l'aggiornamento a SharePoint Server 2010 per provare a eseguire il processo di aggiornamento basato sul collegamento di database.

Esaminare i risultati

Al termine dell'esecuzione del test, è possibile esaminare i risultati dell'aggiornamento e modificare di conseguenza i propri piani. A tale scopo, controllare i file di registro, i siti aggiornati e le personalizzazioni in modo da verificare come l'aggiornamento abbia funzionato per l'ambiente in uso e da stabilire come sia necessario riconcepire il piano di aggiornamento sulla base dei comportamenti osservati.

Esaminare i file di registro

Esaminare i file di registro seguenti:

• Il file di registro dello strumento di verifica pre-aggiornamento.

  I file di registro dello strumento di verifica pre-aggiornamento (stsadm -o preupgradecheck) sono disponibili in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. Il nome di tali file di registro è nel formato seguente: PreUpgradeCheck_AAAAMMGG-HHMMSS-SSS-numero-casuale.log, dove AAAAMMGG corrisponde alla data, HHMMSS-SSS corrisponde all'orario nel formato a 24 ore con minuti, secondi e millisecondi e il numero casuale viene utilizzato per differenziare i possibili tentativi contemporanei di esecuzione dello strumento di verifica pre-aggiornamento.

• Il file di registro della Configurazione guidata Prodotti SharePoint (Psconfig.exe), generato durante l'esecuzione di tale procedura guidata nell'ambito dell'aggiornamento di prova sul posto.

  I file di registro di PSCDiagnostics sono disponibili in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS.

• Il file del registro di aggiornamento e il file del registro degli errori di aggiornamento, generati durante l'esecuzione dell'aggiornamento.

  Il file del registro di aggiornamento (con estensione log) e il file del registro degli errori di aggiornamento (con estensione err) sono disponibili in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. Il nome di tali file di registro è nel formato seguente: Upgrade-AAAAMMGG-HHMMSS-SSS.log, dove AAAAMMGG rappresenta la data e HHMMSS-SSS rappresenta l'orario in formato a 24 ore con minuti, secondi e millisecondi.

Per esaminare i file di registro allo scopo di individuare e risolvere i problemi, partire dall'inizio dei file. Gli errori o gli avvisi possono ricorrere più volte se si verificano per diverse raccolte siti dell'ambiente oppure se bloccano l'intero processo di aggiornamento. Se ad esempio non si riesce a connettersi al database di configurazione, verrà tentata più volte (con esito negativo) l'esecuzione del processo di aggiornamento e tutti questi tentativi verranno elencati nel file di registro.

Cercare oppure individuare visivamente le voci seguenti:

• Finished upgrading SPFarm Name= <Nome del database di configurazione>

• In-place upgrade session finishes. Root object = SPFarm= <Nome del database di configurazione> , recursive = True. 0 errors and 0 warnings encountered.

Se queste voci sono presenti, l'installazione è stata eseguita correttamente.

Se le voci indicate al passaggio precedente non sono presenti, è possibile identificare problemi specifici che possono aver impedito la corretta installazione cercando oppure individuando visivamente nel file Upgrade.log i termini seguenti:

• Nei file di registro cercare ERROR per individuare gli eventuali errori, ad esempio componenti guasti o connessioni di database non funzionanti.

• Cercare WARNING per individuare eventuali problemi quali funzionalità o componenti mancanti.

Per individuare gli eventuali problemi di aggiornamento, può essere utile avvalersi di un parser per eseguire query sui file di registro.

Riavviare l'aggiornamento, se necessario

Durante un aggiornamento basato sul collegamento di database, i siti non aggiornabili verranno ignorati. Durante un aggiornamento sul posto, se il server si riavvia oppure se l'aggiornamento ha esito negativo, sarà necessario riavviare il processo di aggiornamento per aggiornare i siti restanti.

Per verificare se durante il processo di aggiornamento è stato ignorato qualche sito, eseguire l'operazione Stsadm stsadm -o localupgradestatus su tutti i server Web front-end della server farm di SharePoint Server 2010. Per ulteriori informazioni su questa operazione, vedere Localupgradestatus: operazione Stsadm (Office SharePoint Server) (le informazioni potrebbero essere in lingua inglese).

Se durante l'aggiornamento sono state ignorate una o più raccolte siti, sarà possibile riavviare il processo di aggiornamento per il database contenente la raccolta siti eseguendo il cmdlet di Windows PowerShell seguente: upgrade-spcontentdatabase -id <GUID>. Per ulteriori informazioni su questo cmdlet, vedere Upgrade-SPContentDatabase.

Per ulteriori informazioni, vedere Riprendere l'aggiornamento (SharePoint Server 2010).

Controllare i siti aggiornati

Esaminare i siti aggiornati per identificare eventuali problemi da risolvere prima di eseguire il processo di aggiornamento nell'ambiente di produzione. Per ulteriori informazioni su aspetti specifici a cui prestare attenzione, vedere Verificare l'aggiornamento e controllare i siti aggiornati (SharePoint Server 2010).

Modificare i piani ed eseguire di nuovo il test

Ripetere il test finché non si è certi di aver individuato tutti i problemi che potrebbero verificarsi e di avere compreso come risolverli. L'obiettivo è quello di sapere quale piano adottare se sono le 16.00 di domenica, il sistema deve essere di nuovo funzionante per lunedì mattina e ancora presenta problemi. Identificare un eventuale punto di non ritorno. Testare il piano di ripristino e verificare che funzioni prima di avviare l'aggiornamento effettivo.