Sei sulla pagina 1di 40

` UNIVERSITA DEGLI STUDI DI TRIESTE

` Facolta di Ingegneria
Corso di Laurea Triennale in Ingegneria Informatica Dipartimento di Ingegneria Industriale e dellInformazione

PORTING EVOLUTIVO DI SITI WEB SU TECNOLOGIA SHAREPOINT PORTAL SERVER 2010


Laureando: Matteo ASERO Relatore: Prof. Maurizio FERMEGLIA

Anno Accademico 2010/2011

Ai miei genitori

Indice
1 Introduzione 1.1 Situazione generale . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Software utilizzato . . . . . . . . . . . . . . . . . . . . . . . . 2 Tipologie di siti 2.1 Siti WSS . . . . . . . . . . . . . . . . . . 2.2 Siti WSS con database di supporto . . . 2.2.1 Un sito WSS con due database . 2.2.2 Un sito WSS con sito di supporto 2.3 Siti non WSS . . . . . . . . . . . . . . . 3 Preparazione alla migrazione 3.1 Determinare il metodo di aggiornamento 3.2 Passaggi pre-aggiornamento . . . . . . . 3.2.1 Requisiti del sistema . . . . . . . 3.2.2 Strumento di verica . . . . . . . 4 Migrazione 4.1 Operazioni server database . . 4.2 Operazioni server web . . . . 4.3 Visual upgrade . . . . . . . . 4.4 Casi particolari . . . . . . . . 4.4.1 Mose . . . . . . . . . . 4.4.2 Nanotechnology School 4.4.3 Energia Ambiente . . . 4.5 Operazioni post migrazione . 1 1 1 2 3 3 3 4 4 4 5 5 6 6 6 9 11 13 17 18 18 19 21 24

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 Conclusioni 29 5.1 Risultati raggiunti . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 II

INDICE 5.3

III Problematiche riscontrate . . . . . . . . . . . . . . . . . . . . 31 32 33 35

A Organizzazione srv3 B Organizzazione srv4 Bibliograa

Elenco delle gure


1.1 3.1 3.2 3.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 5.1 5.2 Web application list dicampsrv1 . . . . . . . . . . . . . . . . . Esecuzione dello strumento di verica pre-aggiornamento . . . Report generato dalla verica pre-aggiornamento . . . . . . . Errore in fase di verica pre-aggiornamento . . . . . . . . . . . Schematizzazione del processo di migrazione . . . . Finestra di backup di un database . . . . . . . . . . Finestra di restore di un database . . . . . . . . . . Nuova web application . . . . . . . . . . . . . . . . Esecuzione a buon ne del Test-SPContentDatabase Attachment del database alla web application . . . Resoconto delle migrazioni eettuate . . . . . . . . Informazioni dettagliate di una migrazione . . . . . Ribbon introdotto con SharePoint 2010 . . . . . . . Creazione nuovo sito web dallIIS . . . . . . . . . . Missing web part . . . . . . . . . . . . . . . . . . . Aggiunta web part EnergiaAmbiente . . . . . . . . Impostazioni web part EnergiaAmbiente . . . . . . Web part EnergiaAmbiente . . . . . . . . . . . . . Creazione nuovo login in SQL Server . . . . . . . . Mapping dei database per un login . . . . . . . . . Lista dei login assegnati ad un database . . . . . . Aggiunta host name ad un sito dallIIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 7 8 8 10 11 12 13 14 15 16 16 17 20 21 22 23 23 24 25 26 27

Web application list srv4 . . . . . . . . . . . . . . . . . . . . . 29 Schematizzazione delle security . . . . . . . . . . . . . . . . . 30

IV

Capitolo 1 Introduzione
1.1 Situazione generale

Il lavoro svolto consiste nella migrazione di una serie di siti web del dipartimento, sviluppati con tecnologia Windows SharePoint Services 3.0, da un server ad un altro. Approttando del fatto di dover spostare questi siti, ` e stato anche deciso di eettuare un upgrade del software passando quindi allultima versione rilasciata, Microsoft SharePoint 2010, in modo da avere la possibilit` di sfruttarne le nuove caratteristiche. a Al momento nel server che si desidera staccare, denominato dicampsrv1 (nome completo dicampsrv1.ds.units.it), la situazione software comprende, come gi` accennato, uninstallazione di WSS 3.0 che si appoggia ad un DBMS di a tipo Microsoft SQL Server 2008 R2. Al suo interno sono quindi presenti una serie di siti WSS, con i relativi database, le cui tipologie e caratteristiche verranno approfondite nel corso di questa tesi. Si proceder` inizialmente a pensando ad un ordinamento dei siti web secondo un ordine ben preciso delle porte su cui essi saranno raggiungibili, imponendo di conseguenza altrettanto ordine sul lato database. Verr` poi determinato lapproccio pi` consono a u al processo di migrazione per poi arrivare allo spostamento vero e proprio dei siti e al cosiddetto visual upgrade per cercare di sfruttare alcune delle nuove funzionalit` introdotte. a

1.2

Obiettivi

Lobiettivo nale di questa tesi ` di riuscire a migrare tutti i siti presenti e nel server attuale verso la nuova struttura e di studiare una logica di organizzazione della nomenclatura e delle porte. Lesigenza di spegnere il server corrente ha aperto la possibilit` del passaggio alla nuova versione visto che a 1

CAPITOLO 1. INTRODUZIONE

le caratteristiche hardware e la capacit` di calcolo della nuova macchina lo a permettono; considerato che la situazione attuale non prevede alcuna logica nellorganizzazione dei siti web, ` stata colta loccasione per mettere un po e dordine al ne di facilitare la personalizzazione dei siti o eventuali modiche agli stessi che potrebbero rendersi necessarie in futuro.

Figura 1.1: Web application list dicampsrv1

1.3

Software utilizzato

La nuova struttura consiste in una macchina sica allinterno della quale sono state predisposte delle macchine virtuali con cui lavorare. La prima di queste, chiamata srv3 (nome completo srv3.di3.units.it), sar` a la macchina virtuale utilizzata per la parte database e dispone quindi di uninstallazione di Microsoft SQL Server 2008 R2; la seconda, srv4 (nome completo srv4.di3.units.it), sar` invece quella contenente i siti veri e propri: a in essa ` stata installata una copia di Microsoft SharePoint 2010 Foundation e e una di Microsoft SharePoint Designer.

Capitolo 2 Tipologie di siti


Possiamo suddividere tutti i siti che devono essere spostati in tre gruppi ben distinti, che determineranno degli accorgimenti particolari ai quali prestare attenzione al momento della migrazione.

2.1

Siti WSS

Questi siti sono stati creati con le procedure standard per la creazione di siti previste da Windows SharePoint Services 3.0, pertanto essi si appoggiano solamente al content database predenito di SharePoint dentro al quale sono presenti tutti i dati relativi ai siti. Tra questi troviamo: GreenBoatDesign - 41540 (http://dicampsrv1:41540/) StudentiDICAMP (http://studenti.di3.units.it/) DBD - 27994 (http://www.dbd.units.it/) VNPCF - 43550 (http://dicampsrv1:43550/) SharePoint - 80 (http://intranet.di3.units.it/)

2.2

Siti WSS con database di supporto

In questa seconda categoria troviamo, invece, quei siti internet che sono sempre stati creati con WSS, ma che al loro interno contengono delle web part che fanno riferimento ad un database diverso da quello predenito di SharePoint. Essi pertanto, per funzionare correttamente, necessitano di due database distinti in quanto una parte dei dati ` contenuta nel content database standard, e 3

CAPITOLO 2. TIPOLOGIE DI SITI mentre unaltra parte ` reperita da questaltro database di supporto. e A sua volta, questa categoria, pu` essere suddivisa in due parti. o

2.2.1

Un sito WSS con due database

I siti contenuti in questo gruppo sono stati creati con WSS e contengono al loro interno delle sezioni che vanno a reperire i dati da un database autonomo rispetto a quello di SharePoint. Tra questi troviamo: Mose (http://www.mose.units.it/) Energia Ambiente (http://dicampsrv1:47322/) In particolare il sito Energia Ambiente va ad interrogare il proprio database di supporto tramite una custom web part sviluppata appositamente per questo scopo.

2.2.2

Un sito WSS con sito di supporto

In questa sezione ricade un unico sito: Nano Technology School (http://nanotech.units.it/) la cui particolarit` ` quella di reperire le informazioni sul database di supporae to mediante la consultazione di un vero e proprio sito di supporto (NanotechSupport) reperibile alla porta 32211 del dicampsrv1. Nella pratica, quindi, il sito WSS non manipola in prima persona i dati sul database di supporto, ma carica allinterno di un frame di una sua pagina il sito di supporto che si occupa della gestione del database.

2.3

Siti non WSS

Questi siti sono quelli che potremmo denire classici, ossia creati senza lausilio di WSS. Tra questi ` giusto citare il NanotechSupport (del quale ` stata e e data spiegazione appena sopra, vedi 2.2.2), in quanto necessario al corretto funzionamento del sito Nano Technology School, ma non ci soermeremo sugli altri non essendo oggetto di questa tesi.

Capitolo 3 Preparazione alla migrazione


3.1 Determinare il metodo di aggiornamento

Prima di eseguire il processo di aggiornamento ` necessario determinare quale e sia lapproccio pi` consono alla nostra situazione. Vi sono di base due possiu bilit`: la prima ` detta aggiornamento sul posto con la quale ` possibile a e e installare SharePoint Foundation 2010 nello stesso hardware ed aggiornare il contenuto e le impostazioni della server farm come parte di un unico processo. I vantaggi di questa metodologia sono che le impostazioni a livello di farm vengono mantenute e aggiornate, le personalizzazioni sono disponibili nellambiente dopo laggiornamento; gli svantaggi, invece, sono che i server e le farm sono oine durante laggiornamento con conseguente irraggiungibilit` dei siti da parte degli utenti. a La seconda strada ` un aggiornamento basato sul collegamento di dae tabase che prevede di aggiornare il contenuto per lambiente in una farm separata e rende possibile laggiornamento dei database in qualsiasi ordine. I pro sono che ` possibile aggiornare pi` database del contenuto contempoe u raneamente, pertanto i tempi sono complessivamente pi` brevi rispetto a un u aggiornamento sul posto. I contro sono che le impostazioni di server e farm non vengono aggiornate, quindi ` necessario trasferire manualmente le ime postazioni e/o le eventuali personalizzazioni che si desidera mantenere dalla farm precedente a quella nuova. La mancanza di una o pi` personalizzazioni u pu` causare una perdita indesiderata di funzionalit` oppure problemi per o a ` lutente. E necessario inoltre disporre dellaccesso diretto ai server database. Essendo vincolati dal fatto di dover cambiare lhardware di destinazione ed avendo pieno controllo sui database, abbiamo deciso di adottare il secondo metodo di aggiornamento.

CAPITOLO 3. PREPARAZIONE ALLA MIGRAZIONE

3.2
3.2.1

Passaggi pre-aggiornamento
Requisiti del sistema

Prima di eseguire laggiornamento ` bene essere informati sulle caratteristie che necessarie anch` il passaggio da WSS 3.0 a SharePoint 2010 Foundation e possa avere luogo senza problemi: bisogna disporre sia di hardware che di versioni del sistema operativo e di Microsoft SQL Server a 64 bit. Nello specico per quanto riguarda il server web, deve disporre di processore a 64 bit (4 core), almeno 8 GB di RAM e disco sso da minimo 80 GB; il server di database invece, processore a 64 bit (8 core per distribuzioni di medie dimensioni), 8 GB di RAM per distribuzioni di dimensioni ridotte (16 GB per medie dimensioni) e disco sso da almeno 80 GB. Anche per quanto riguarda il software, come precedentemente accennato, le versioni di Microsoft SQL Server e di Windows Server devono essere a 64 bit. ` E importante che almeno i requisiti minimi siano soddisfatti perch`, se ad e esempio il server di database non disponesse di memoria suciente o di un processore con potenza adeguata, potrebbe non riuscire a sopportare il numero di transazioni che hanno luogo durante il processo di aggiornamento e questultimo potrebbe avere esito negativo.

3.2.2

Strumento di verica

Lo strumento di verica di pre-aggiornamento ` uno strumento che permette e di visualizzare un report sullo stato dellambiente e dei siti di SharePoint esistenti prima di eseguire laggiornamento a Microsoft SharePoint Foundation 2010. Questa verica ` eseguibile in un ambiente Windows SharePoint Sere vices 3.0 allo scopo di individuare potenziali problemi per laggiornamento ` ed esaminare indicazioni e procedure consigliate. E consigliabile che lo strumento di verica pre-aggiornamento venga eseguito dallamministratore del server e che questultimo provveda a risolvere il maggior numero di problemi possibile prima di pianicare laggiornamento. Il report generato dar` informazioni riguardo a: preparazione per laggiornaa mento e percorsi supportati, impostazioni di mapping di accesso alternativo, elementi installati, personalizzazioni non supportate, oggetti orfani, impostazioni di congurazione non valide, requisiti dei database. Per eseguire lo strumento di verica pre-aggiornamento ` necessario: e 1. Lanciare il Prompt dei comandi di Windows come amministratore.

CAPITOLO 3. PREPARAZIONE ALLA MIGRAZIONE 2. Navigare no alla seguente directory:

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin 3. Digitare il seguente comando e premere ENTER: STSADM.EXE -o preupgradecheck

Figura 3.1: Esecuzione dello strumento di verica pre-aggiornamento

Come possiamo vedere dalla gura 3.1, ad ogni voce viene assegnato un breve messaggio informativo: la voce Passed indica che ` tutto ok; Information e Only si riferisce a delle personalizzazioni che necessitano di essere migrate manualmente e per le quali si potrebbero trovare maggiori informazioni nel le di log; inne Failed signica che la voce corrispondente necessita di primaria attenzione, ` un problema che deve essere risolto per poter eettuare e un processo di migrazione. Dal le di log si possono ottenere informazioni pi` dettagliate in merito al u

CAPITOLO 3. PREPARAZIONE ALLA MIGRAZIONE

server analizzato, ai database, ai siti e ai metodi di aggiornamento supportati (gura 3.2). Nel nostro caso ci si presenta anche un errore (gura 3.3) che ci informa del fatto che larchitettura corrente non supporta la migrazione, ma la cosa non ci preoccupa aatto dal momento che siamo consci di doverci spostare in un server dierente (vedi 1.1).

Figura 3.2: Report generato dalla verica pre-aggiornamento

Figura 3.3: Errore in fase di verica pre-aggiornamento

Capitolo 4 Migrazione
In questo capitolo verr` trattata in dettaglio la migrazione vera e propria con a la quale si arriver` ad avere sulla nuova macchina unesatta copia funzionante a dei siti web di partenza, aggiornati alla nuova versione del software. Nella pratica, durante lo svolgimento di questa parte del lavoro, era stato creato un sito WSS di prova, senza particolari caratteristiche, con lo scopo di testare su di esso il processo di migrazione. Questo perch` la maggior parte dei e nostri siti appartiene alla prima categoria (vedi 2.1), quindi una volta capito il meccanismo di porting per il sito di prova, la procedura sar` analoga per a tutti gli altri. Prima di iniziare riportiamo una veloce panoramica del processo (vedi anche gura 4.1), con le principali operazioni che verranno eettuate per lo spostamento di un sito: backup del content database sul dicampsrv1 ; restore del database sul nuovo server srv3 ; creazione di una nuova web application in SharePoint 2010 Foundation nellsrv4 ; test di compatibilit` del database dei contenuti con la web application; a assegnazione del database alla web application se il precedente test ha avuto esito positivo. Specichiamo inoltre che, per quanto riguarda i siti del secondo gruppo (2.2), la procedura di porting rimarr` praticamente la stessa, le dierenze consia steranno in alcuni piccoli accorgimenti che dovranno essere adottati prima o dopo il processo di migrazione.

CAPITOLO 4. MIGRAZIONE

10

Figura 4.1: Schematizzazione del processo di migrazione

Prima di iniziare ad analizzare in dettaglio le varie operazioni, informiamo il lettore sulle decisioni prese in merito alla nomenclatura e alla logica delle porte. Per quanto riguarda le web application, i nomi saranno del tipo: NOMESITO NUMEROPORTA I relativi database dei contenuti: NOMESITO NUMEROPORTAdb Eventuali database di supporto saranno nella forma: NOMESITO NUMEROPORTAdbsup Inne, la logica decisa per lassegnazione delle porte stabilisce che i siti SharePoint siano raggiungibili sulle porte di numero 301xx e i siti classici sulle porte 302xx, entrambi in crescendo a partire da 00.

CAPITOLO 4. MIGRAZIONE

11

4.1

Operazioni server database

Le operazioni da eettuare per quanto concerne la parte database hanno lo scopo di spostare i dati dal primo al secondo server, consisteranno quindi in un backup ed un restore del database interessato. DallSQL Management Studio del dicampsrv1 bisogner` cliccare col tasto a destro sul database desiderato, sotto la voce Tasks troveremo il comando Backup: impostando tra le opzioni un backup di tipo Full, percorso e nome del le di output, verr` generato un le con estensione .bak contenente a una copia identica del nostro database.

Figura 4.2: Finestra di backup di un database

CAPITOLO 4. MIGRAZIONE

12

Questo le .bak dovr` essere spostato dal dicampsrv1 allsrv3, che ` la nostra a e macchina database, e nello stesso menu in cui avevamo trovato il comando di backup c` il relativo comando di Restore Database. Cos` facendo abe biamo predisposto il database su cui pogger` la web application una volta a che questa verr` collegata. a

Figura 4.3: Finestra di restore di un database

Nella nestra di restore sar` suciente indicare il percorso in cui ` situato il a e le .bak di backup e specicare il nome che si vuole assegnare al database che verr` creato. Nella scheda Options ` bene ricordarsi di cambiare i percorsi a e dentro ai quali verranno posizionati i le .mdf e .ldf associati al database, nel caso in cui si voglia posizionarli in cartelle diverse da quelle predenite.

CAPITOLO 4. MIGRAZIONE

13

4.2

Operazioni server web

Sul lato del server web ` necessario predisporre una nuova web application e che verr` collegata manualmente al database che ` stato ripristinato. a e Aprendo SharePoint 2010 Foundation: Central Administration > Application Management > Manage Web Applications Clicchiamo su New, nella nestra che apparir` andiamo ad impostare noa me e porta rispettando le regole spiegate precedentemente. Lasciamo tutte le altre opzioni sulle impostazioni predenite tranne Allow Anonimous che deve essere consentito in modo tale che il sito possa essere visitato anche da visitatori esterni senza che eettuino il login.

Figura 4.4: Nuova web application

Questa nuova web application avr` indirizzo: a http://srv4.di3.units:301xx dove 301xx corrisponde al campo Port delle opzioni al momento della creazione (vedi gura 4.4). Siamo ora pronti per collegare il database alla corrispondente applicazione web: prima di tutto ` necessario eettuare la verica dei componenti e personalizzati, ossia bisogna controllare che la web application disponga di tutte le caratteristiche che sono necessarie al database al quale la si vuole collegare. Per fare questo ` suciente avviare la SharePoint Management e

CAPITOLO 4. MIGRAZIONE Shell come amministratore e digitare il comando seguente:

14

Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL> Dove: <DatabaseName> ` il nome del database da vericare. e <URL> ` lindirizzo dellapplicazione web da collegare. e Questo comando simula il collegamento tra il database e la web application specicati come parametri e fornisce una lista di tutti problemi che sono stati riscontrati; nel caso in cui non dovesse esserci nessun errore verr` visualizzato a il classico cursore (vedi gura 4.5).

Figura 4.5: Esecuzione a buon ne del Test-SPContentDatabase

Una volta eettuato il test e risolte eventuali problematiche, si passa allattachment vero e proprio. Sempre dalla Management Shell di SharePoint digitare: Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> [-Updateuserexperience] Dove: <DatabaseName> ` il nome del database da collegare. e <ServerName> ` il nome del server in cui ` contenuto il database. e e <URL> ` lindirizzo dellapplicazione web da collegare. e

CAPITOLO 4. MIGRAZIONE

15

Updateuserexperience specica che deve essere eseguito laggiornamento alla nuova intefaccia graca; questo parametro pu` essere omesso se si o vuole eettuare il passaggio in un altro momento. Dopo un certo lasco di tempo, variabile a seconda delle dimensioni del database (una percentuale indica lavanzamento del processo), viene visualizzato un messaggio indicante i nomi dei parametri passati al comando e il numero dei siti che sono stati trovati allinterno del database che ora verranno ospitati dalla web application (vedi gura 4.6). Se dovessero esserci degli errori durante il processo, questi verranno visualizzati in rosso.

Figura 4.6: Attachment del database alla web application

Una volta portato a termine il processo di migrazione, dalla Central Administration di SharePoint, in Upgrade and Migration > Check Upgrade Status ` possibile vedere un resoconto di tutti i processi di porting intrapresi con e relativo esito positivo o negativo (gura 4.7): cliccando compare una tabella che fornisce informazioni pi` dettagliate (gura 4.8) come percorso del le di u log, che pu` contenere informazioni importanti per risolvere eventuali errori o riscontrati. Giunti a questo punto, il sito ` stato spostato sul nuovo server. Non resta e quindi che testare il suo corretto funzionamento.

CAPITOLO 4. MIGRAZIONE

16

Figura 4.7: Resoconto delle migrazioni eettuate

Figura 4.8: Informazioni dettagliate di una migrazione

CAPITOLO 4. MIGRAZIONE

17

4.3

Visual upgrade

Una volta che il sito ` stato spostato possiamo passare allaggiornamento e visuale, che ` una delle innovazioni introdotte con lultima versione di Sharee Point. Eettuare il passaggio alla nuova esperienza utente ` molto semplice e ed ` un processo reversibile: nel caso in cui ci si trovi meglio con la vecchia e interfaccia, una volta eettuato il passaggio, ` possibile tornare indietro. e Il primo metodo ` quello di includere lapposito parametro nel comando e Mount al momento del collegamento del database dei contenuti con lapplicazione web (vedi 4.2): con questa soluzione il sito verr` creato direttamente a con la nuova graca. Il secondo metodo ` quello di eettuare il porting del e sito normalmente e una volta che questultimo ` operativo si eettua il login e al sito, dal relativo menu a tendina troveremo tra le opzioni la possibilit` di a eettuare il passaggio. Lelemento che salta subito allocchio dopo il visual upgrade ` lintroduzione e del Ribbon (vedi gura 4.9), ossia quella barra degli strumenti che permette di avere accesso a tutte le funzioni pi` frequentemente utilizzate: ` u e molto simile a quella presente nelle pi` recenti versioni di Microsoft Oce e u velocizza non poco la personalizzazione del sito.

Figura 4.9: Ribbon introdotto con SharePoint 2010

Il procedimento di porting ` ora terminato ed i passaggi visti nora in questo e capitolo sono stati ripetuti per tutti i siti appartenenti alla prima categoria (vedi 2.1).

CAPITOLO 4. MIGRAZIONE

18

4.4

Casi particolari

Ora analizzeremo invece la migrazione di quei siti con alcune particolarit`, a che hanno reso le operazioni di spostamento un po meno standardizzabili.

4.4.1

Mose

Il Mose ` un sito del dipartimento che era stato creato utilizzando una cue stom master page. Una master page ` un metodo che permette di creare dei template che verrane no poi applicati al sito in questione: esse creano una pagina html suddivisa in diverse regioni editabili singolarmente. Sono queste le parti che, in ogni pagina, possono subire modiche. Esistono una serie di template predeniti di SharePoint che, ovviamente, non creano problemi durante il processo di migrazione in quanto sono stati implementati anche nella nuova versione; la nostra situazione per` vede lutilizzo o di un template creato appositamente per il sito in questione, che durante il porting pu` creare qualche problema di lieve entit`. o a Le master page personalizzate non possono essere migrate in quanto il sistema non ` in grado di riconoscere quali modiche siano state apportate. e Precisiamo che questo non rappresenta un limite per lutilizzo del sito in s`, e il quale viene migrato con successo ed ` accessibile e operativo in tutte le e sue parti, per` non ci ` permesso eettuare il visual upgrade per sfruttare la o e nuova interfaccia. Esistono dei comandi per forzare il passaggio tra le varie versioni della graca, ma dopo il primo tentativo ci si rende subito conto che non pu` essere un compromesso accettabile: tutte le proporzioni e le carato teristiche stilistiche del sito vengono sballate, con parti di testo che vengono spostate andando a sovrapporsi ad altre. Vengono a mancare le caratteristiche basilari che permettono un navigazione normale del portale. Le soluzioni concrete che si possono adottare per far fronte a questa situazione sono due: la prima consiste nel migrare il sito sul nuovo server (come eettuato nel nostro caso) e poi procedere ad una ristrutturazione della master page andando ad aggiungere manualmente le caratteristiche desiderate. Questo pu` essere eettuato utilizzando SharePoint Designer andando ad o agire direttamente sul codice sorgente della pagina. Si tratta di unoperazione molto lunga e laboriosa, bisogna inserire uno per volta gli elementi desiderati e testare come questi inuenzano il resto della pagina. La seconda possibilit` prevede di riportare il sito ad una situazione di tema plate predenito di WSS 3.0, eettuare la migrazione ed attivare la nuova interfaccia con gli strumenti forniti. Il sito sar` ora sicuramente aggiornato a alla nuova versione e si potr` procedere alla scrittura di una nuova master a

CAPITOLO 4. MIGRAZIONE

19

page. Entrambe le soluzioni richiedono un impiego di tempo e risorse non trascurabile e, nonostante non sia parte di questo lavoro di tesi, ` consigliabile e preferire la seconda soluzione alla prima in quanto rappresenta un rimedio pi` sicuro e meno dispendioso. u

4.4.2

Nanotechnology School

Le caratteristiche di questo sito sono gi` state esposte precedentemente (vedi a 2.2.2). Per la sua migrazione sono state seguite le procedure standard di porting descritte allinizio di questo capitolo, ma ` stato necessario agire anche su e altri fronti per renderlo completamente eciente. Il problema consiste nel fatto che, allinterno di un frame, viene visitato il sito di supporto con il quale ` possibile manipolare alcuni dei dati presenti sul e database di supporto: si tratta quindi di spostare sul nuovo server anche il sito di supporto che, come tutti gli altri, risiede sul dicampsrv1. Trattandosi di un sito classico, lo spostamento ` abbastanza immediato visto che tutti i e suoi le sono contenuti allinterno di ununica cartella. Dopo aver spostato i database sullsrv3 come gi` fatto in precedenza (vedi 4.1), copiamo nellsrv4 a la cartella relativa al sito nella destinazione desiderata e apriamo lIIS (Internet Information Services): espandendo il nostro server e cliccando col tasto destro sulla cartella Sites troviamo lopzione Add Web Site.... Da qui sar` suciente inserire il nome per il sito, impostare il percorso della cartella a contenente i le di congurazione e selezionare la porta su cui raggiungere sito (vedi gura 4.10). Il sito ` ora stato creato, ma non ` ancora congurato e e correttamente. Dalla cartella contenente i le di congurazione apriamo il le web.cong con il blocco note ed andiamo a cercare e modicare la stringa relativa al data source, che punta ancora al vecchio server, come segue: Data Source = srv3.di3.units.it Initial Catalog = NanoTechnologySchool 30107dbsup Con la prima facciamo puntare al nostro nuovo server database (prima era infatti dicampsrv1.ds.units.it) e con la seconda indichiamo su quale database andare a reperire i dati. Come ultima operazione, per rendere operativo il sito, ` necessario aprire e la porta che era stata scelta precedentemente al momento della creazione

CAPITOLO 4. MIGRAZIONE

20

Figura 4.10: Creazione nuovo sito web dallIIS dalle opzioni di sicurezza di Windows: quando viene creata una nuova web application con SharePoint 2010 viene automaticamente aggiunta la porta scelta ad un gruppo autorizzato allinterno del rewall di Windows; questo non accade quando si crea un sito dallIIS. Si ` scelto di mappare questo sito sulla porta 30107 (stabilendo uneccezione e alle regole stabilite essendo un sito essenziale al funzionamento di unapplicazione SharePoint) e una volta svolti tutti questi passaggi il sito ` reperibile e allindirizzo http://srv4.di3.units.it:30107. Ora, per completare il funzionamento del Nanotechnology School, bisogna modicare il link allinterno del frame che ridirige verso il sito di supporto: una volta inserito il nuovo url, quando si entrer` nellapposita sezione, non a verr` pi` visualizzato il sito Nanotech Support presente sul vecchio server, a u ma quello sul nuovo.

CAPITOLO 4. MIGRAZIONE

21

4.4.3

Energia Ambiente

La web part presente in questo sito ` stata scritta appositamente per andare e a reperire dei record allinterno di un database ma, non essendo tra quelle predenite, al momento del test di compatibilit` tra database e applicazione a web, vengono segnalati degli errori di missing web part siccome questultima non ` installata nella nuova macchina SharePoint (vedi gura 4.11). e

Figura 4.11: Missing web part

Per poter avere a disposizione la web part anche sul nuovo portale ` nee cessario ricompilare il codice con Visual Studio 2010 ed eettuare tutti i test necessari a vericarne il corretto funzionamento. Questo lavoro ` stato svolto e in separata sede e non fa parte di questa tesi. Una volta che ci ` stata fornita e la nuova web part abbiamo potuto procedere con il porting. Innanzitutto abbiamo cancellato dal sito la web part in questione, portandolo quindi ad essere un classico sito WSS senza alcuna caratteristica aggiuntiva; ` stato poi migrato seguendo le procedure standard e, una volta funzionante e

CAPITOLO 4. MIGRAZIONE

22

sul nuovo server, ` stata installata la nuova web part. Per linstallazione sono e state seguite le informazioni fornite dallo sviluppatore e una volta completato il processo, dopo aver attivato la relativa features, possiamo trovare la web part in lista con tutte le altre (vedi gura 4.12).

Figura 4.12: Aggiunta web part EnergiaAmbiente

CAPITOLO 4. MIGRAZIONE

23

Per renderla denitivamente operativa, tra le propriet` della web part, sotto a la voce Custom Property e SharePoint User Property, i campi vanno impostati come in Figura 4.13: nella schermata di sinistra vengono impostati il server database, le credenziali dellutente loggato al sito e il nome del database; in quella di destra, invece, il percorso in cui reperire le informazioni sullutente loggato per determinare se sia o meno autorizzato a visualizzare la web part.

(a)

(b)

Figura 4.13: Impostazioni web part EnergiaAmbiente

Figura 4.14: Web part EnergiaAmbiente

CAPITOLO 4. MIGRAZIONE

24

4.5

Operazioni post migrazione

Per concludere il lavoro nel modo migliore bisogna occuparsi di qualche ulteriore dettaglio per far si che tutto funzioni in maniera ottimale. Come prima cosa ` necessario creare dei nuovi login sul server database: quee sti servono a determinare i permessi dellutente che sta visitando il sito per vericare se questultimo sia o meno autorizzato a consultare i dati allinterno del database. Per fare un esempio, la web part del sito EnergiaAmbiente ` e visualizzabile solamente da quegli utenti che sono inseriti in un determinato gruppo del sito. Creare un nuovo login consiste, quindi, nellautorizzare un nuovo utente ad eettuare determinate operazioni su uno o pi` database: u ogni login ` individuato da uno username e una password che verranno ine viate dal sorgente del sito verso SQL Server per avere accesso ai dati. Nei nostri siti abbiamo bisogno solamente di un nuovo login che utilizzeremo

Figura 4.15: Creazione nuovo login in SQL Server

CAPITOLO 4. MIGRAZIONE

25

per tutti i database di supporto; di fatto ne verranno creati due, il secondo solo ed esclusivamente per questioni di test sul sito EnergiaAmbiente, ma in pratica identico a quello utilizzato in tutti gli altri siti. DallSQL Server della nostra macchina srv3, espandendo il motore e la cartella Security, cliccando con il tasto destro su Logins ci ` permesso crearne uno nuovo e (vedi gura 4.15). Nella prima scheda impostiamo a piacere login name e relativa password, poi spostandoci nella sezione User Mapping (vedi gura 4.16) abbiamo la possibilit` di selezionare i database che ci interessano ed a i ruoli che vogliamo assegnare al login corrente per quei determinati database.

Figura 4.16: Mapping dei database per un login

Una volta impostati i ruoli possiamo vericare che loperazione sia andata a buon ne: espandendo in uno dei database precedentemente mappati, le

CAPITOLO 4. MIGRAZIONE

26

cartelle Security e Users, dovremmo notare la presenza del login appena creato (vedi gura 4.17).

Figura 4.17: Lista dei login assegnati ad un database

Per le ultime due operazioni da eettuare ci spostiamo sullsrv4. La prima ` collegata ai login sopra citati in quanto nei siti sono presenti e alcune web part che necessitano di essere impostate manualmente da codice anch` funzionino in maniera corretta. e Da SharePoint Designer apriamo i siti interessati e cliccando nelle web part in questione dobbiamo modicare il data source facendolo puntare al nuovo database nel nuovo server. Lerrore veniva riscontrato in quanto le impostazioni reindirizzavano le query verso il vecchio server; per sapere esattamente quali sono le web part aette da questa problematica ` suciente visitare il e sito da un qualsiasi browser e ci si accorge che allinterno della pagina viene visualizzato un messaggio di errore al posto dei dati. Si tratta di unoperazione piuttosto lunga e tediosa, in quanto si rende necessario modicare da codice la stringa di connessione di ogni singola lista; sarebbe molto comodo poter creare una sorta di variabile globale assegnata

CAPITOLO 4. MIGRAZIONE

27

ad ogni web part, avendo cos` la possibilit` di modicare solamente quella a variabile per cambiare il puntamento di tutti gli oggetti interessati. Lultima impostazione da sistemare riguarda il raggiungimento dei siti: vanno aggiunti degli host name sulle porte corrette per far s` che, dopo un adeguato cambiamento a livello dns, i nostri siti vengano raggiunti sotto specici nomi. DallIIS, cliccando col tasto destro sul sito che si vuole modicare, si trova la voce Edit Bindings..., successivamente con il pulsante Add... ` possibile e aggiungere un nuovo host name su una determinata porta (vedi gura 4.18).

(a)

(b)

Figura 4.18: Aggiunta host name ad un sito dallIIS

CAPITOLO 4. MIGRAZIONE

28

Tutto ` stato impostato tale e quale a comera nel dicampsrv1, in modo e che, al cambio di dns eettuato dai sistemisti del dipartimento, i siti siano raggiungibili almeno sotto gli stessi nomi di prima. Vengono comunque riportati in appendice tutti i singoli siti trattati in questa tesi, con i relativi indirizzi internet (vedi B).

Capitolo 5 Conclusioni
5.1 Risultati raggiunti

Il lavoro ` stato portato a termine con successo e tutti gli obiettivi che erano e stati pressati sono stati raggiunti. Tutti i siti che erano presenti nel dicampsrv1 sono stati migrati nellsrv4 e funzionano correttamente. Ecco come si presenta la situazione nale delle web application sul nuovo server:

Figura 5.1: Web application list srv4

Dal punto di vista personale mi ritengo soddisfatto del lavoro svolto, sia per quanto riguarda il traguardo raggiunto, sia per il fatto di aver svolto un tirocinio utile alla mia universit`. Saranno di sicuro costruttive le conoscena ze che ho appreso in merito a questa tecnologia, con la quale non ero mai entrato in contatto. 29

CAPITOLO 5. CONCLUSIONI

30

5.2

Security

Un aspetto che pu` essere interessante da citare ` quello relativo alle security o e ed ai permessi sui siti che sono stati migrati. Quando larchitettura comprendeva sullo stesso server sia la parte web che la parte database, non avevamo il problema di dover accedere a macchine diverse per reperire i dati, in quanto essi si trovavano nella stessa posizione del sito che li utilizzava. La nostra situazione, invece, prevede due macchine distinte e separate, ma appartenenti allo stesso dominio, per gestire la parte dati e la parte web. Sharepoint si occupa in automatico di creare e gestire un account, che permette agli utenti dei vari siti di poter accedere alla macchina contenente lSQL Server per ottenere i record. Ci sono delle situazioni in cui non a tutti gli utenti ` permesso visualizzae re determinate web part. Dalle impostazioni di ciascun portale, ` possibile e creare dei gruppi e specicare dei permessi per tutti i membri appartenti allo stesso gruppo. Nel momento in cui un utente visita un sito ed eettua il login, Sharepoint sa automaticamente a che gruppo appartiene permettendogli di visualizzare solamente le parti del sito per le quali ` autorizzato. e Il sito EnergiaAmbiente ` un esempio dellapplicazione di questa metodoloe gia: un utente qualsiasi ha libero accesso a tutti i contenuti nelle varie pagine che fanno riferimento al database dei contenuti, ma solamente gli utenti ap-

Figura 5.2: Schematizzazione delle security

CAPITOLO 5. CONCLUSIONI

31

partenenti ad uno specico gruppo sono autorizzati alla visione, e quindi alla manipolazione, dei dati contenuti allinterno del database di supporto, accessibili mediante la custom web part della quale abbiamo parlato nelle pagine precedenti. La gura 5.2 mostra come questo concetto possa essere generalizzato e schematizzato.

5.3

Problematiche riscontrate

Durante tutto questo lavoro non sono stati riscontrati particolari problemi, quello che ho notato ` che SharePoint mette a disposizione moltissimi strue menti per ogni tipo di esigenza: si tratta quindi di un campo talmente vasto che ` molto semplice perdercisi allinterno. e Per quanto concerne la mia esperienza, i primi passi della migrazione sono molto semplici e veloci da imparare e si arriva in poco tempo ad appredere il processo di porting. La strada inizia a farsi in salita laddove compaiano delle personalizzazioni: quando si cerca di agire con degli elementi non standardizzati, come per esempio del codice scritto a mano, risolvere gli errori a cui si va incontro pu` essere molto dispendioso. Tutta la documentazione che si o trova nei manuali e reperibile online tratta, ovviamente, situazioni generali, quindi per la risoluzione di quelli che possono sembrare dei piccoli problemi, pu` essere necessario scavare molto a fondo. o Lultima cosa che avrei piacere a menzionare ` limportanza della documentae zione: molto spesso non si ha loccasione di iniziare un lavoro o un progetto da zero, ma si deve lavorare sul del materiale o strutture gi` esistenti nei a quali le basi sono state gettate gi` da tempo. Non ` inoltre sempre possibile a e confrontarsi o chiedere chiarimenti allideatore dellambiente in cui si lavora: ` quindi, a mio avviso, molto importante che tutte le congurazioni e ime postazioni utili quali indirizzi, directory, username, password, ecc. vengano chiaramente documentate, archiviate e messe a disposizione qualora si presentasse in futuro la necessit` di riutilizzarle. Questo farebbe risparmiare del a tempo prezioso a chi lavorer` un giorno al nostro stesso progetto. a

Appendice A Organizzazione srv3


Si riporta lorganizzazione dei le e delle impostazioni per quanto riguarda la macchina srv3. Il percorso dei le .mdf e .ldf dei database per i siti classici `: e E:\Data\database\Classic Mentre per i siti SharePoint `: e E:\Data\database\Sharepoint Per quanto riguarda le impostazioni dei login di SQL Server mappati per i database abbiamo: Login name: webuser Login name: energyuser Password: ****** Password: ******

Ricordiamo anche che la logica utilizzata per la nomenclatura dei database ` la seguente: e WEBAPPNAME_PORTAdb per i database predeniti di SharePoint e WEBAPPNAME_PORTAdbsup per i database di supporto. WEBAPPNAME ` il nome dellapplicazione web e PORTA ` la porta e e corrispondente.

32

Appendice B Organizzazione srv4


I le relativi ai siti web classici si trovano in: C:\inetpub\wwwroot\Siti Web Mentre quelli dei siti SharePoint in: C:\inetpub\wwwroot\wss\VirtualDirectories\PORTA dove PORTA indica la porta della web application in questione. Riportiamo inne tutti gli indirizzi dei siti web migrati: Intranet http://srv4.di3.units.it:30100 http://intranet.di3.units.it http://intranet.dicamp.units.it http://srv4.di3.units.it:30101 http://studenti.di3.units.it http://studenti.dicamp.units.it http://srv4.di3.units.it:30102 http://greenboat.units.it http://srv4.di3.units.it:30103 http://dbd.units.it http://www.dbd.units.it

StudentiDICAMP

GreenBoatDesign

DBD

33

APPENDICE B. ORGANIZZAZIONE SRV4

34

VNPCF

http://srv4.di3.units.it:30104 http://vnpcf.units.it http://srv4.di3.units.it:30105 http://energy.units.it http://srv4.di3.units.it:30106 http://www.nanotech.units.it http://srv4.di3.units.it:30107 http://srv4.di3.units.it:30108 http://mose.units.it http://www.mose.units.it

EnergiaAmbiente

Nano Technology School

Nanotech Support Mose

Bibliograa
[1] How to do everything - Microsoft SharePoint 2010, McGraw-Hill, 2010 [2] Microsoft SharePoint Designer 2010: step by step, OReilly Media, 2010 [3] SharePoint 2010 All-in-One For Dummies, Wiley Publishing, 2011 [4] Home page di Google http://www.google.it [5] Microsoft TechNet http://technet.microsoft.com/ [6] Blog di SharePoint http://www.peppedotnet.it/ [7] Supporto tecnico Microsoft http://support.microsoft.com/ [8] Italian SharePoint Community http://www.sharepointcommunity.it/ [9] Microsoft SharePoint Team Blog http://sharepoint.microsoft.com/

35