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

 

Si applica a: SharePoint Foundation 2010

Ultima modifica dell'argomento: 2016-11-30

Prima di iniziare il processo di aggiornamento da Windows SharePoint Services 3.0 a Microsoft SharePoint Foundation 2010, è consigliabile testare il processo per comprendere tutte le operazioni necessarie per la corretta esecuzione dell'aggiornamento. 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:

Le risorse che seguono possono inoltre rivelarsi utili durante il test del processo di aggiornamento:

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.

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.

Ambiente di testing virtuale per un aggiornamento di prova

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.

Farm di testing fisica per un aggiornamento di prova

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 Windows SharePoint Services 3.0 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.

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 individuare, vedere Determinare la modalità di gestione delle personalizzazioni (SharePoint Foundation 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 Windows SharePoint Services 3.0, 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 (Windows SharePoint Services).

  • Eseguire l'operazione Stsadm –o enumallwebs su tutti i database del contenuto presenti nell'ambiente Windows SharePoint Services 3.0 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 Windows SharePoint Services 3.0 con Service Pack 2 (SP2). Per ulteriori informazioni, vedere Enumallwebs: operazione Stsadm (Windows SharePoint Services).

  • 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 la presenza di modifiche nei file web.config ed esaminare l'elemento SafeControls per individuare eventuali controlli personalizzati.

  • Utilizzare lo strumento di diagnostica di SharePoint (SPDiag) per trovare le soluzioni distribuite. Per ulteriori informazioni sullo strumento di diagnostica di SharePoint, vedere SharePoint Diagnostics Tool (SPDiag) (le informazioni potrebbero essere in lingua inglese).

  • Creare un elenco di tutte le personalizzazioni trovate e, se possibile, individuarne l'origine. Stabilire ad esempio se si tratta di componenti aggiuntivi o modelli di terze parti personalizzati internamente. Dopo aver individuato l'origine, sarà possibile verificare se sono disponibili versioni aggiornate delle personalizzazioni. È disponibile un foglio di lavoro nel quale è possibile inserire informazioni sull'ambiente in uso, basate sui dati raccolti dallo strumento di verifica pre-aggiornamento e durante la ricerca delle personalizzazioni. Scaricare il foglio di lavoro da http://go.microsoft.com/fwlink/?linkid=179928&clcid=0x410 (le informazioni potrebbero essere in lingua inglese) e personalizzarlo in base alle proprie esigenze.

SuggerimentoTip
A chi rivolgersi per le personalizzazioni non create personalmente
  • In caso di problemi con un modello scaricato dal sito Web Microsoft, ad esempio i modelli di applicazioni di Windows SharePoint Services 3,0, rivolgersi a Microsoft.

  • In caso di problemi con un modello o un componente di terze parti, rivolgersi al fornitore di soluzioni da cui si è avuta la versione precedente del modello o del componente. Potrebbe disporre di una versione aggiornata.

Dopo avere individuato 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 Foundation 2010 per stabilire se nell'ambiente mancano personalizzazioni. Eseguire questo comando per i singoli database dopo averli ripristinati nel server database, ma prima di eseguire l'aggiornamento. Si noti che tale cmdlet viene eseguito in modo invisibile all'utente, pertanto non verrà restituito alcun output a meno che non si verifichi un errore.

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

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.

ImportanteImportant
L'esecuzione del test su un sottoinsieme di dati non fornisce un riscontro valido per stabilire quanto tempo richiederà l'elaborazione dell'intero volume di dati 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.

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 (Windows SharePoint Services 3.0) (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 (Windows SharePoint Services).

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

  5. Esaminare i risultati.

  1. Creare un backup con SQL Server dei database del contenuto.

  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 del contenuto (Windows SharePoint Services 3.0).

  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 (Windows SharePoint Services).

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

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

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

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 Foundation 2010. Per ulteriori informazioni su questa operazione, vedere Localupgradestatus: operazione Stsadm (Windows SharePoint Services).

Se durante l'aggiornamento sono state ignorate alcune raccolte siti, è possibile riavviare il processo di aggiornamento per i database contenenti queste raccolte 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 Foundation 2010).

Esaminare i siti aggiornati per individuare 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 Foundation 2010).

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.

Mostra: