Utilizzare un aggiornamento di prova a SharePoint 2013 per individuare possibili problemi

SI APPLICA A:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Prima di avviare un aggiornamento da Prodotti SharePoint 2010 a SharePoint 2013, è necessario testare il processo di aggiornamento per assicurarsi di sapere esattamente cosa è necessario fare per avere un aggiornamento corretto. L'esecuzione di un aggiornamento di prova per testare il processo consente di verificare quanto segue:

• Funzionamento o meno del piano di aggiornamento ed eventuali modifiche da apportare.

• Personalizzazioni presenti nell'ambiente in uso per pianificarne le modalità di gestione durante l'aggiornamento.

• Eventuale necessità di aggiornare l'hardware in modo da poter eseguire un aggiornamento più rapido ed efficiente.

• Frequenza con cui eseguire l'aggiornamento o durata dell'aggiornamento per l'ambiente in uso.

• Motivi per cui è necessario pianificare a livello operativo, ad esempio, le risorse disponibili.

È inoltre possibile utilizzare l'aggiornamento di prova per acquisire familiarità con gli strumenti di aggiornamento e con il processo stesso, in modo che non vi siano imprevisti durante l'esecuzione dell'effettivo processo. Mediante il testing è possibile determinare quanto segue:

• Qual è l'aspetto dell'interfaccia utente di aggiornamento? Come fai a sapere quando hai finito una fase e stai passando attraverso un'altra?

• Dove sono i file di log e come li si legge? Quali informazioni forniscono?

• Eventuale necessità di apportare modifiche a script o comandi utilizzati durante il processo di aggiornamento, in particolare se si utilizzano script eseguiti per l'aggiornamento a SharePoint 2010 Products.

• Disponibilità o meno di un piano corretto per gestire eventuali interruzioni.

In questo articolo vengono descritti i passaggi di base necessari per testare l'aggiornamento e sono inclusi consigli su come esaminare i risultati e modificare qualsiasi piano di aggiornamento in base alle informazioni acquisite durante i test.

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

• SharePoint 2013: Come verificare l'aggiornamento

  Scaricare il poster del modello di testing del processo di aggiornamento per i prodotti SharePoint 2013 Preview per avere una visualizzazione grafica delle informazioni su come verificare il processo di aggiornamento.

• Vedere le procedure consigliate per il testing del processo di aggiornamento descritte in Procedure consigliate per l'aggiornamento da SharePoint 2010 a SharePoint 2013.

Allestire un ambiente di testing

Per testare il processo di aggiornamento è possibile utilizzare componenti hardware virtuali o fisici. Ogni ambiente è univoco. Pertanto, non sono disponibili linee guida generali per quanto tempo richiederà l'aggiornamento o per quanto sarà difficile eseguire una specifica personalizzazione. Il modo migliore per misurare il modo in cui verrà eseguito l'aggiornamento consiste nell'eseguire una serie di aggiornamenti di valutazione.

Di seguito sono indicati alcuni aspetti da tenere presenti 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 disponibile.

• Usare gli stessi URL nella farm di test come nella farm reale. In caso contrario, si perderanno tempo nella diagnosi dei problemi relativi agli URL che non si verificheranno nell'aggiornamento reale. A tale scopo, è possibile usare gli stessi URL e i test solo dai computer con modifiche ai file host.

• Utilizzare nomi di computer diversi per il server Web e il server applicazioni.

  In questo modo si eviteranno conflitti di Servizi di dominio Active Directory.

• Utilizzare server distinti in cui eseguire SQL Server per la farm di testing

  Se si usano gli stessi server che eseguono SQL Server per la farm di test e di produzione, è possibile influire sulle prestazioni della farm di produzione durante l'esecuzione dei test. È consigliabile usare computer SQL Server diversi (non solo istanze) per le farm di produzione e di test.

• Utilizzare gli stessi nomi di database nell'ambiente di testing.

  In questo modo, è possibile convalidare qualsiasi script utilizzato per gestire l'ambiente. Anche in questo caso, assicurarsi di usare server separati che eseguono SQL Server o si rischia di influire sull'ambiente di produzione.

• Assicurarsi di trasferire nell'ambiente di testing tutte le impostazioni e le personalizzazioni. Nella sezione Identificare e installare le personalizzazioni sono incluse le informazioni sulla raccolta di tali dati.

Verificare che le azioni adottate nell'ambiente di testing non influiscano sull'ambiente reale. Prestare attenzione agli elementi seguenti:

• Connessioni dati esterne

  Benché si utilizzi una copia dell'ambiente, il collegamento all'origine dati è reale. Le modifiche apportate ai dati nell'ambiente di testing influiscono sull'ambiente di produzione.

• Esecuzione di comandi su un database reale ancora presente nell'ambiente di produzione

  Assicurarsi di utilizzare copie dei database per il testing e non una versione reale dell'ambiente di produzione. Se, ad esempio, si esegue Test-SPContentDatabase su un database reale anziché su una copia, le prestazioni dell'ambiente di produzione possono risultare inferiori.

Utilizzo di un ambiente di testing virtuale

Quando si esegue il testing 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 include le immagini per i server Web front-end e i server applicazioni, mentre l'altro server include le immagini per i server di database.

Gli ambienti virtualizzati, tuttavia, potrebbero non utilizzare le stesse metriche di prestazioni degli ambienti fisici. Se l'ambiente di produzione è fisico, è necessario considerare questa differenza nel calcolare il tempo necessario per aggiornare l'ambiente di produzione. In genere, è possibile ottenere stime migliori delle prestazioni se si usa un server fisico per SQL Server. Assicurarsi che abbia specifiche di prestazioni simili al server che esegue SQL Server nell'ambiente di produzione.

Distribuzione di server in un ambiente di testing virtuale

Utilizzo di un ambiente di testing fisico

Quando si esegue il test usando un ambiente fisico, è necessario replicare l'ambiente della server farm di produzione proposto il più vicino possibile. Se si semplifica troppo il numero di server Web front-end, server applicazioni o server di database, non si avrà una stima accurata del tempo necessario per il processo di aggiornamento. Non è possibile tenere conto delle complicazioni che derivano dalle interazioni tra server nello stesso ruolo (ad esempio SQL Server transazioni). Se sono presenti più server in un ruolo nella farm di produzione proposta, usare almeno due server per tale ruolo nella farm di test per verificare tali problemi.

Distribuzione di server in un ambiente di testing fisico

Identificare e installare le personalizzazioni

Per utilizzare un processo di testing accurato, è necessario individuare tutte le personalizzazioni presenti nell'ambiente corrente e copiarle nell'ambiente di testing. Per altre informazioni sui tipi di personalizzazioni che è necessario identificare, vedere Creare un piano per le personalizzazioni correnti durante l'aggiornamento a SharePoint 2013.

• Usare l'operazione Stsadm -o enumallwebs su tutti i database del contenuto nell'ambiente Prodotti SharePoint 2010 per identificare personalizzazioni specifiche nei siti secondari. Questa operazione restituisce un elenco contenente l'ID di ogni raccolta siti e sito secondario dell'ambiente e i modelli su cui si basa il sito. Per ulteriori informazioni, vedere Operazione Enumallwebs: Stsadm.

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

• Creare un elenco di tutte le personalizzazioni trovate. Se possibile, identificare l'origine delle personalizzazioni. Determinare ad esempio se vi sono modelli o componenti aggiuntivi di terze parti personalizzati internamente. Dopo aver identificato l'origine, è possibile verificare la disponibilità di versioni aggiornate delle personalizzazioni.

Dopo aver identificato tutte le personalizzazioni, copiarle nei server appropriati nella farm di testing. Verificare che vengano distribuite le personalizzazioni seguenti:

• Soluzioni: per impostazione predefinita, le soluzioni legacy vengono distribuite nelle directory /14. Utilizzare il parametro CompatibilityLevel durante l'installazione delle soluzioni per distribuirle nelle directory /15. Per ulteriori informazioni, vedere Install-SPSolution.

• Pagine master personalizzate

• File JavaScript personalizzati

• File CSS personalizzati (inclusi quelli per i temi)

• Azioni del flusso di lavoro personalizzate (devono essere incluse nei file delle azione)

• Verificare le impostazioni di limitazione delle richieste di query agli elenchi di grandi dimensioni per assicurarsi che gli elenchi di grandi dimensioni vengano visualizzati nel modo previsto.

Quando si testano le personalizzazioni, utilizzare le linee guida seguenti:

• Controllare le modifiche visive.

• Controllare le modifiche di comportamento.

• Testare le raccolte siti in modalità 2010 e 2013.

• Identificare qualsiasi problema di caricamento di lingue o risorse.

  Questo problema può verificarsi quando sono presenti personalizzazioni in modalità 2010, sostituite da nuove personalizzazioni in modalità 2013. Poiché esiste solo una directory globale per le risorse di lingua, può verificarsi un problema di caricamento del file corretto. Assicurarsi che le personalizzazioni in modalità 2013 sostitutive includano le risorse in modalità 2010, in modo che le personalizzazioni possano continuare a funzionare correttamente in entrambe le modalità.

• Verificare che l'aggiornamento non abbia effetto sulle personalizzazioni. Assicurarsi che le personalizzazioni non blocchino l'aggiornamento della raccolta siti.

È possibile usare il cmdlet di Microsoft PowerShell Test-SPContentDatabase prima di collegare un database a SharePoint 2013 per determinare se nell'ambiente mancano personalizzazioni. Eseguire questo comando per ogni database dopo aver ripristinato i database nel server di database, ma prima di eseguire l'aggiornamento. Si noti che poiché questo comando viene eseguito automaticamente, non restituirà alcun output a meno che non venga rilevato un problema.

Copiare dati reali nell'ambiente di testing e aggiornare i database

Non è possibile soddisfare gli obiettivi di testing senza utilizzare i dati effettivi. Usare gli strumenti di backup e ripristino di Microsoft SQL Server per creare una copia dei database del contenuto e dei servizi.

Non esiste un modo migliore per indicare cosa può verificarsi durante l'aggiornamento che eseguire il test su una copia di tutti i dati. Tuttavia, questa potrebbe non essere sempre un'opzione realistica per i test iniziali. È possibile eseguire test in fasi testando un database alla volta (se i database sono di grandi dimensioni) in modo da assicurarsi di testare qualsiasi elemento univoco del set di dati. In alternativa, è possibile assemblare un subset di dati da siti rappresentativi nell'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 nell'ambiente.

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

Dopo avere copiato i dati, provare una prima volta il processo di aggiornamento per osservarne lo svolgimento. Questa è solo la fase preliminare. Seguire la procedura descritta in Aggiornare i database del contenuto da SharePoint 2010 a SharePoint 2013 per provare il processo di aggiornamento del collegamento di database.

Quando si testa il processo di aggiornamento, assicurarsi di testare i servizi condivisi tra farm. Considerare tutti gli stati, inclusi i seguenti:

• Una farm di SharePoint Server 2010 connessa a una farm di servizi di SharePoint 2013.

• Una farm di SharePoint 2013 connessa a una farm di servizi di SharePoint 2013.

• Farm di versioni diverse per servizi diversi.

Utilizzare l'ambiente di testing per individuare tutti i problemi di sicurezza, configurazione, compatibilità e prestazioni per le applicazioni di servizio.

Esaminare i risultati dopo aver aggiornato i database

Al termine dell'aggiornamento del test, è possibile esaminare i risultati e rivedere i piani. Esaminare i file di log, esaminare i siti aggiornati ed esaminare le personalizzazioni. Come è stato eseguito l'aggiornamento per l'ambiente? Cosa hai scoperto? Cosa è necessario ripensare al piano di aggiornamento?

Esaminare i file di registro

Esaminare il file di log di aggiornamento e il file di log degli errori di aggiornamento (generato durante l'esecuzione dell'aggiornamento). Il file di log di aggiornamento (con estensione log) e il file di log degli errori di aggiornamento (con estensione err) si trovano in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. I file di log sono denominati nel formato seguente: Upgrade- AAAAMMGG-HHMMSS-SSS.log, dove AAAAMMGG è la data e HHMMSS-SSS è l'ora (ore in formato orologio 24 ore, minuti, secondi e millisecondi).

Il formato dei file di log è conforme alle convenzioni ULS (Unified Logging System). Per esaminare i file di log 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 è possibile connettersi al database di configurazione, il processo di aggiornamento verrà tentato più volte (con esito negativo) e tutti i tentativi saranno elencati nel file di log.

Controllare i siti in modalità 2010

Controllare le raccolte siti che non sono state aggiornate nel modo previsto in modalità 2010. I siti devono avere un aspetto e un comportamento simili a quello dei prodotti SharePoint 2010. Alcune modifiche sono previste. Ad esempio, Office Online e le funzionalità di analisi Web sono state modificate in SharePoint 2013 e i siti che hanno usato queste funzionalità saranno interessati. Per informazioni su elementi specifici da cercare, vedere Panoramica del processo di aggiornamento da SharePoint 2010 a SharePoint 2013.

Se necessario, eseguire di nuovo l'aggiornamento

Se necessario, è possibile riavviare il processo di aggiornamento per un database usando il cmdlet Di Microsoft PowerShell Upgrade-SPContentDatabase . Per ulteriori informazioni su questo cmdlet, vedere Upgrade-SPContentDatabase. Per altre informazioni, vedere Riavviare un aggiornamento basato sul collegamento di database o un aggiornamento della raccolta siti a SharePoint 2013.

Aggiornare raccolte siti e Siti personali

Dopo aver testato e convalidato l'aggiornamento dei database di contenuto e dei servizi, è possibile testare il processo di aggiornamento per le raccolte siti. Seguire la procedura descritta in Aggiornare una raccolta siti a SharePoint 2013 per testare il processo di aggiornamento della raccolta siti. Se nell'ambiente sono presenti siti personali, vedere Panoramica del processo di aggiornamento da SharePoint 2010 a SharePoint 2013 per altre informazioni sul processo di aggiornamento.

Esaminare i risultati dopo aver aggiornato le raccolte siti

Controllare l'aspetto dei siti aggiornati per identificare eventuali problemi da risolvere prima di eseguire il processo di aggiornamento nell'ambiente di produzione. Per altre informazioni su elementi specifici da cercare, vedere Panoramica del processo di aggiornamento da SharePoint 2010 a SharePoint 2013.

Esaminare i file di log di aggiornamento della raccolta siti per verificare la presenza di eventuali problemi, a partire dall'alto verso il basso. Controllare la sezione di riepilogo verso la fine del file di log per visualizzare un conteggio dei problemi e lo stato effettivo dell'aggiornamento(se non è presente alcun stato, significa che il processo di aggiornamento non è riuscito e l'aggiornamento del sito deve essere ritentato). I file di log della raccolta siti vengono archiviati sia nella raccolta siti stessa (nella raccolta documenti _catalogs/Aggiornamento) che nel file system. Il file di log del file system contiene altre informazioni se si vogliono informazioni dettagliate sui problemi. La versione del file system del file di log dell'aggiornamento del sito si trova in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. I file di log sono denominati nel formato seguente: SiteUpgrade- AAAAMMGG-HHMMSS-SSS.log, dove AAAAMMGG è la data e HHMMSS-SSS è l'ora (ore in formato orologio 24 ore, minuti, secondi e millisecondi).

Modificare i piani ed eseguire di nuovo il test

Ripetere il testing finché non si è certi di aver individuato tutti i problemi possibili e di essere in grado di risolverli. L'obiettivo è quello di individuare il piano da adottare se, ad esempio, sono le 16.00 di domenica, il sistema deve essere di nuovo funzionante per lunedì mattina e sussistono ancora problemi. Identificare un eventuale punto di non ritorno. Testare il piano alternativo e verificare che funzioni prima di avviare l'aggiornamento effettivo.

Vedere anche

Ulteriori risorse

Procedure consigliate per l'aggiornamento da SharePoint 2010 a SharePoint 2013

Pianificare le prestazioni durante l'aggiornamento a SharePoint 2013

Aggiornare i database da SharePoint 2010 a SharePoint 2013

Upgrade a site collection to SharePoint 2013

Verificare e risolvere i problemi per un aggiornamento a SharePoint 2013