Distribuzione con SharePoint 2010: preparati per l'aggiornamento a SharePoint 2010
È facile essere tentati a eseguire immediatamente un aggiornamento a SharePoint 2010, ma in realtà è necessario una pianificazione attenta. In questo articolo, viene illustrata la procedura dettagliata di pianificazione dell'aggiornamento.
Brien Posey
L'aggiornamento a SharePoint 2010 si rivelerà un'operazione totalmente diversa da precedenti aggiornamenti. Prima di iniziare la procedura di pianificazione dell'aggiornamento, è necessario acquisire familiarità con i requisiti di sistema di SharePoint 2010. A differenza delle versioni precedenti, SharePoint 2010 è una versione solo a 64 bit. Pertanto, sarà necessario installare il software in una versione a 64 bit di Windows Server 2008 o Windows Server 2008 R2.
SharePoint richiede un database SQL Server, che non dovrà essere installato nello stesso server in cui è in esecuzione SharePoint. Anche SharePoint 2010 richiede SQL Server, ma Microsoft ha apportato alcune importanti modifiche. Per l'esecuzione di SharePoint 2010 è necessario che nel database sia in esecuzione un'edizione a 64 bit di SQL Server 2005 o 2008. Ciò vale a prescindere se il database è installato o meno in locale nel server SharePoint.
Benché non si tratti tecnicamente di un requisito di sistema, si consiglia di prendere in considerazione i browser Web utilizzati. SharePoint 2010 è progettato per sfruttare meglio gli standard Web. Ciò significa che gli utenti avranno un'esperienza simile a prescindere se utilizzano Internet Explorer o Firefox (3.x o versioni successive) con l'unica eccezione del supporto limitato per Internet Explorer 6. Gli utenti di Internet Explorer 6 non dovrebbero riscontrare problemi nel visualizzare il contenuto di SharePoint, ma per la modifica del contenuto è necessario disporre di Internet Explorer 7 o versioni successive (in alternativa, Firefox 3.x o versioni successive).
Aggiornamenti sul posto
Probabilmente sarà noto il fatto che SharePoint 2010 consente aggiornamenti sul posto da Microsoft Office SharePoint Server (MOSS) 2007. Tuttavia, poiché SharePoint 2010 è a 64 bit, è possibile eseguire un aggiornamento sul posto solo se l'installazione esistente di MOSS 2007 è in esecuzione in una versione a 64 bit di Windows Server 2008. Se i server SharePoint esistenti soddisfano i requisiti di sistema, sarà possibile eseguire un aggiornamento sul posto in ciascun server presente nella server farm SharePoint.
Benché SharePoint supporti completamente tali aggiornamenti, non è consigliabile un aggiornamento sul posto se si dispone una distribuzione semplice di SharePoint senza personalizzazioni. In ambienti più complessi, si consiglia di eseguire migrazioni complete per garantire un livello maggiore di controllo sulla procedura di aggiornamento. Sono inoltre consigliabili per ambienti in cui sono state applicate personalizzazioni che non si desidera sovrascrivere accidentalmente.
Una migrazione solitamente comporta la creazione di una server farm completamente nuova in cui eseguire SharePoint 2010. Dopo aver completato l'operazione, sarà possibile collegare i database SharePoint esistenti alla nuova server farm. È possibile inoltre adottare una strategia di migrazione ibrida in cui integrare aggiornamenti sul posto e server SharePoint 2010 completamente nuovi.
Verifica pre-aggiornamento
A prescindere se si stia eseguendo un aggiornamento sul posto o una migrazione, sarà necessario effettuare una pianificazione e una preparazione prima di poter effettivamente avviare la procedura. L'esecuzione dello strumento di verifica pre-aggiornamento rappresenta uno dei passaggi più importanti nella preparazione dell'aggiornamento a SharePoint 2010. Prima della pubblicazione di MOSS 2007, Microsoft rilasciò l'utilità Prescan.exe che consentiva di verificare l'integrità della distribuzione SharePoint prima dell'aggiornamento a MOSS 2007.
Benché Prescan.exe fosse allora un ottimo strumento, attualmente non è effettivamente adatto a un'analisi di pre-distribuzione di SharePoint 2010. A tale scopo, Microsoft ha rilasciato un nuovo strumento denominato verifica pre-aggiornamento. Lo strumento di verifica pre-aggiornamento rappresenta un miglioramento considerevole rispetto allo strumento Prescan.exe. Per i principianti, lo strumento di verifica pre-aggiornamento è in sola lettura, pertanto non comporta alcuna modifica ai server SharePoint esistenti.
Ciò che rende lo strumento utile è il fatto che è in grado di eseguire un'analisi molto più approfondita per il rilevamento di problemi rispetto al predecessore Prescan.exe ed è inoltre estensibile. Lo strumento di verifica pre-aggiornamento include un'insieme di regole utilizzate durante l'analisi dei server SharePoint in formato XML. Ciò significa che è possibile creare delle regole personalizzate in caso di necessità. L'utilizzo di regole basate su XML semplifica a Microsoft l'eventuale aggiornamento dello strumento di verifica pre-aggiornamento in caso di modificare delle procedure consigliate.
Indubbiamente, l'aspetto più interessante dello strumento di verifica pre-aggiornamento è rappresentato senz'altro dalle informazioni che è in grado di presentare. Benché Microsoft abbia progettato l'utilità di verifica di pre-aggiornamento come strumento per la preparazione di un aggiornamento a SharePoint 2010, alcune organizzazioni lo utilizzano per altri scopi. Un'azienda effettivamente lo utilizza nell'ambito del proprio piano di ripristino di emergenza. L'utilità non esegue in realtà alcuna operazione finalizzata al ripristino di un server SharePoint con errori, ma le informazioni raccolte possono risultare estremamente utili qualora si presentasse la necessità di ricreare una distribuzione di SharePoint (è sufficiente assicurarsi di eseguire lo strumento prima che si verifichi il guasto).
Analogamente, un'altra organizzazione ha utilizzato l'utilità di verifica pre-aggiornamento come strumento per verificare che i propri server SharePoint fossero configurati in modo coerente. Mediante l'esecuzione dello strumento di verifica pre-aggiornamento su ciascuno dei server SharePoint disponibili, l'organizzazione è in grado di confrontare i report relativi a ciascun server e di cercare tutti i singoli elementi di configurazione non conformi ai criteri aziendali.
Quindi, dove è possibile reperire lo strumento di verifica pre-aggiornamento? Probabilmente ne sarete già in possesso. Microsoft ha incluso lo strumento in MOSS 2007 SP2. Tuttavia, contrariamente a quanto ci si potrebbe aspettare, l'utilità di verifica pre-aggiornamento non è uno strumento indipendente, ma è integrato nell'utilità STSADM.EXE. Tuttavia, dopo aver applicato il Service Pack 2, è necessario riavviar il server di test per due volte prima di poter accedere alla nuova funzionalità di STSADM.EXE.
Ciò premesso, desidererei illustrarvi il funzionamento dello strumento di verifica pre-aggiornamento. Come menzionato in precedenza, lo strumento di verifica pre-aggiornamento funziona tramite un file di regole basate su XML che verranno utilizzate per l'analisi della distribuzione SharePoint. Lo strumento include un insieme di regole integrate basate sul Best Practice Analyzer e incluse in un file denominato OssPreUpgradeCheck.xml. Per informazioni sull'aspetto del file, fare riferimento alla Figura 1.
Figura 1 Lo strumento di verifica pre-aggiornamento utilizza un file di regole basato su XML.
Quando si richiama lo strumento di verifica pre-aggiornamento, non è necessario chiamare in modo esplicito questo file di regole, poiché verrà richiamato automaticamente per impostazione predefinita. È possibile utilizzare file di regole personalizzate rispettando la seguente sintassi completa:
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]
Da notare che gli unici parametri richiesti sono -O e PreUpgradeCheck. Il parametro –RuleFiles è facoltativo e viene solo utilizzato se si desidera manualmente specificare un file di regole da utilizzare. Analogamente, è possibile utilizzare il parametro –ListRuleFiles per visualizzare i file di regole disponibili. Infine, è possibile utilizzare il parametro –LocalOnly per eseguire le regole solo sul server SharePoint locale.
Per un quadro più dettagliato sul funzionamento dello strumento di verifica pre-aggiornamento, fare riferimento alla Figura 2. Come si nota nella figura, ho iniziato con la visualizzazione di una finestra del prompt dei comandi e sono passato al percorso C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\BIN. Da questa posizione, ho eseguito il seguente comando:
STSADMIN.EXE –O PreUpgradeCheck]
.jpg)
Figura 2 Lo strumento di verifica pre-aggiornamento controlla la distribuzione SharePoint.
Come è possibile notare nella Figura 2, lo strumento di verifica pre-aggiornamento esegue una serie di test diversi sulla distribuzione SharePoint. I risultati di ciascun test sono contraddistinti da colori. Il colore rosso indica un test non riuscito e il colore verde indica che il server ha superato il test. Gli elementi informativi sono contraddistinti dal colore giallo.
Ovviamente, l'output dello strumento di verifica pre-aggiornamento non è esattamente dettagliato. Nella schermata illustrata nella Figura 2 viene indicato se un test è stato superato o meno, ma senza informazioni dettagliate. Se osserviamo la parte inferiore della schermata, tuttavia, ci renderemo conto che viene visualizzato un messaggio che indica la possibilità di visualizzare i risultati esaminando un file HTML che si trova nella cartella C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\Logs.
Ogniqualvolta si esegue lo strumento di verifica pre-aggiornamento, vengono creati tre file di registro distinti. Uno di tali registri è il file HTML indicato alla fine della verifica di aggiornamento, ma sono presenti anche un file con estensione LOG e un file con estensione XML. È possibile utilizzare tutti i file di registro, ma il file HTML è il più semplice da consultare.
Come menzionato in precedenza, lo strumento di verifica pre-aggiornamento presenta un'elevata quantità di informazioni. Pertanto, non dovrebbe sorprendere il fatto che i registri generati sono troppo lunghi per essere illustrati integralmente in questa sede. Tuttavia, è possibile avere un'idea dei registri HTML nella Figura 3.
.jpg)
Figura 3 I risultati della verifica di pre-aggiornamento possono essere visualizzati in un browser Web.
Identificazione della personalizzazione
Un altro passaggio critico nella procedura di pianificazione dell'aggiornamento consiste nell'identificare le personalizzazioni applicate ai server SharePoint. A prescindere se si stia eseguendo un aggiornamento sul posto o una migrazione, è facile sovrascrivere accidentalmente le personalizzazioni. Pertanto, è necessario documentare le personalizzazioni ed eseguire un backup solo dei file da riapplicare dopo l'aggiornamento in caso di necessità.
È infatti auspicabile documentare completamente tutte le personalizzazioni applicate durante l'evoluzione dell'ambiente SharePoint. In uno scenario reale, potrebbe risultare difficile tenere traccia di tutte le modifiche. Pertanto, si consiglia di dedicare del tempo alla verifica del registro personalizzazioni anche se si ritiene che tutte le personalizzazioni siano state documentate in modo corretto. Sfortunatamente, SharePoint non contiene alcuno strumento integrato per l'identificazione delle personalizzazioni. Tuttavia, ciò non significa che sarà necessario verificare manualmente ciascun file nei server SharePoint.
Un modo per determinare le personalizzazioni applicate consiste nell'utilizzare una tecnica denominata controllo delle differenze o diffing. Alla base di questa tecnica è il fatto che è possibile configurare un server MOSS 2007 predefinito verificando che disponga delle stesse patch dei server di produzione, quindi utilizzare un programma per il controllo delle differenze per visualizzare le differenze tra i file presenti nei server di produzione e quelli presenti in un server SharePoint originario.
Microsoft consiglia di utilizzare WinDiff, ma esistono una vasta gamma di utilità per il controllo delle differenze, molte delle quali dispongono di un insieme più esteso di funzionalità rispetto a WinDiff.
Test della procedura di aggiornamento
Durante la preparazione della transizione a SharePoint 2010, alla fine si arriverà a un punto in cui si svilupperà un piano su come eseguire l'aggiornamento. Presupponendo di aver risolto tutte le problematiche segnalate dallo strumento di verifica pre-aggiornamento, la procedura di aggiornamento procederà in modo relativamente indolore. Tuttavia, non si dovrebbe lasciare nulla al caso.
È consigliabile distribuire MOSS 2007 in un ambiente di laboratorio isolato in cui provare un piano di aggiornamento prima di tentare l'aggiornamento di qualsiasi server di produzione. Un laboratorio di testi consente di acquisire familiarità con la procedura di aggiornamento, nonché identificare le problematiche che potrebbero presentarsi quando giunge il momento di eseguire l'effettivo aggiornamento.
Il migliore approccio per le aziende PMI (Piccole e Medie Imprese) consiste nel configurare alcuni server virtuali e ripristinare i backup dei server di produzione nei server di laboratorio. Ciò consentirà di provare il piano di aggiornamento in un ambiente pressoché identico all'ambiente di produzione.
Nelle organizzazioni più grandi, la creazione di un esatto duplicato della distribuzione del server di produzione SharePoint è probabilmente non praticabile. In questi tipi di situazioni, è possibile configurare un ambiente di piccole dimensioni configurato in un modo simile alla propria distribuzione di produzione. È possibile inoltre provare a ripristinare i backup da alcuni, ma non tutti, i server SharePoint in un ambiente di laboratorio. Benché tale approccio possa sembrare aperto a infinite possibilità, è necessario ricordarsi che probabilmente non si convertirò l'intera distribuzione di SharePoint 2010 in una singola sessione, ma è preferibile concentrarsi su un aspetto alla volta.
Verifica dei backup
L'ultimo passaggio prima di iniziare un aggiornamento a SharePoint 2010 consiste nel verificare il corretto funzionamento dei backup. Proprio questa settimana, ho dovuto personalmente offrire il mio supporto a clienti che ritenevano di aver eseguito un corretto backup dei propri server, ma mi sono reso conto che in realtà tali backup non erano adeguati. Una situazione non si dovrebbe mai verificare. Si consiglia di eseguire dei test dei propri backup e verificare che possano essere correttamente ripristinati.
.jpg)
Brien Posey,*** MVP, è autore freelance di migliaia di articoli e decine di testi tecnici. È possibile visitare il suo sito Web all'indirizzo: brienposey.com.*