Inside SharePointCome costruire un'infrastruttura SharePoint

Pav Cherny

Scarica il codice per questo articolo: SharePoint2008_05.exe (412KB)

Proprio come i messaggi di posta elettronica hanno trasformato le comunicazioni aziendali, la collaborazione basata sul Web sta cambiando il modo in cui le persone lavorano insieme e condividono le informazioni. Per avere un esempio, basta dare un'occhiata a cosa offre la tecnologia SharePoint. Con Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server

(MOSS) 2007, è possibile creare siti dedicati a team di lavoro, portali, soluzioni di gestione di contenuti Web, librerie di documenti e centri di ricerca, senza contare l'integrazione del sistema Microsoft® Office 2007, i moduli XML, i flussi di lavoro, il supporto per la mobilità e così via.

Ciononostante, non è sempre semplice iniziare a utilizzare SharePoint®. La terminologia può confondere. L'architettura di sistema può essere complessa e con SharePoint è necessario avere a che fare con più componenti, tra cui IIS, Miscrosoft .NET Framework, SQL Server® e anche altre tecnologie, come Business Intelligence, Infopath® Forms Services, Rights Management Services (RMS), Exchange Server e ForefrontTM Security.

Tra le integrazioni e le personalizzazioni è facile perdersi, considerati i numerosi approcci da scegliere per creare le soluzioni SharePoint, sia attraverso l'interfaccia utente incorporata che in modo programmatico. Senza contare che, quando un'applicazione di SharePoint non funziona, la risoluzione dei problemi può essere complicata. A volte, per capire quali sono i componenti coinvolti e come interagiscono, è necessaria la mentalità di uno sviluppatore di applicazioni Con tutti questi problemi, da dove bisogna cominciare per costruire un'infrastruttura SharePoint robusta, scalabile e gestibile?

In questa rubrica, vi mostrerò come iniziare, creando prima le basi con una discussione sull'architettura in generale, quindi passando ad approfondire la distribuzione di WSS, con alcune personalizzazioni molto semplici. Utilizzando la funzionalità Gestione siti in modalità self-service di WSS 3.0, sarà possibile vedere come delegare ai singoli utenti le autorizzazioni per creare e gestire i siti di SharePoint mantenendo il controllo amministrativo centralizzato sull'infrastruttura SharePoint.

Esaminando, come prima cosa, l'architettura di SharePoint, è facile capire meglio i passaggi di distribuzione e configurazione necessari per implementare un'infrastruttura flessibile e scalabile. Osserviamo, quindi, le dipendenze e passiamo direttamente alla distribuzione di WSS 3.0. Per le istruzioni di distribuzione dettagliate, vedere il materiale di riferimento che accompagna il prodotto. È possibile trovare questo materiale nella sezione dei download del sito Web di TechNet Magazine, all'indirizzo technetmagazine com.

Architettura di SharePoint

Nel caso di SharePoint, è utile pensare alla tecnologia dal punto di vista di un architetto di sistema. Non è necessario conoscere i dettagli di fondo, ma se si ha una certa familiarità con le dipendenze generali che derivano dall'architettura di SharePoint, è possibile arrivare più velocemente alle soluzioni, poiché si può prevedere cosa è necessario configurare e perché.

SharePoint è una tecnologia per il provisioning di siti e applicazioni Web. Si tratta di una soluzione per siti Web basata su IIS, che si integra con IIS tramite ASP.NET e utilizza il back-end di un database SQL Server per archiviare dati di configurazione e contenuti. In breve, SharePoint combina al suo interno tre architetture diverse (IIS, .NET e SQL Server), come mostrato nella figura 1.

Figura 1** Architettura WSS 3.0 basata su IIS 6.0 e ASP.NET 3.0 **(Fare clic sull'immagine per ingrandirla)

Non fatevi intimorire dal diagramma. Solo per il numero dei componenti, l'architettura potrebbe sembrare troppo imponente a un primo sguardo. Ma tutti questi i componenti sono inseriti in un framework logico che, se osservato in modo sistematico, permette di capire nel dettaglio le dipendenze tra i componenti.

Come illustrato, SharePoint si basa su IIS e ASP.NET per gestire le richieste e le risposte HTTP. I componenti IIS standard, come il driver HTTP in modalità kernel (http.sys) e il processo di lavoro (w3wp.exe), effettuano l'accodamento e il routing iniziali delle richieste fin quando queste non arrivano al filtro ISAPI di ASP.NET (aspnet_isapi.dll). Quando si installa .NET Framework, la routine di installazione registra aspnet_isapi.dll nella metabase IIS (C:\Windows\System32\Inetsrv\metabase.xml), come illustrato di seguito:

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

Una volta che IIS ha caricato il filtro ISAPI di ASP.NET, tutte le richieste in arrivo per un sito Web possono essere passate ad ASP.NET, che è importante perché SharePoint, alla fine, deve ricevere queste richieste attraverso ASP.NET. A questo scopo, SharePoint estende la configurazione del sito Web scelto aggiungendo una mappa delle applicazioni con caratteri jolly che instrada tutte le richieste in arrivo, indipendentemente dall'estensione del nome file, al filtro ISAPI di ASP.NET.

È possibile verificare questo comportamento in Gestione IIS dopo avere installato WSS 3.0 utilizzando l'opzione di installazione di base. La routine di installazione di WSS disattiva il sito Web IIS predefinito sul server e crea un nuovo sito Web predefinito sulla porta 80, con la mappa delle applicazioni ASP.NET con caratteri jolly definita, come mostrato nella figura 2.

Figura 2** Mappa delle applicazioni con caratteri jolly per il filtro ISAPI di ASP.NET **(Fare clic sull'immagine per ingrandirla)

Affinché ASP.NET sia in grado di passare a sua volta le richieste a SharePoint, è necessario che SharePoint estenda anche la base delle pipeline delle richieste HTTP tramite un oggetto HttpApplication personalizzato, che viene implementato per mezzo di una classe chiamata SPHttpApplication nell'assembly Microsoft.SharePoint. SharePoint definisce quest'oggetto applicazione personalizzata nel file applicazione di ASP.NET (global.asax), che si trova nel file system nella cartella principale dei siti Web estesi di SharePoint. Il codice che segue elenca il contenuto di questo file global.asax:

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

ASP.NET analizza e compila dinamicamente questo file per creare un'istanza dell'oggetto applicazione di SharePoint.

Per ogni richiesta ricevuta, ASP.NET attiva una serie di eventi che l'applicazione Web può elaborare, come BeginRequest, AuthenticateRequest, ProcessRequest ed EndRequest. I dettagli della gestione eventi non rientrano nella distribuzione e nella gestione di SharePoint, ma è importante sapere che, oltre a SPHttpApplication specificato in global.asax, SharePoint implementa dei gestori e dei moduli HTTP personalizzati definiti nel file web.config per il sito. Ad esempio, SharePoint utilizza un modulo HTTP basato sulla classe SPRequestModule, registrata come primo modulo HTTP prima dei moduli standard di ASP.NET. SPRequestModule inizializza l'ambiente runtime di SharePoint, ad esempio registrando un componente SPVirtualPathProvider in ASP.NET. SPRequestModule è per uso interno di SharePoint, ma gli sviluppatori di soluzioni SharePoint possono modificare il file web.config per registrare componenti aggiuntivi, come i gestori e i moduli HTTP personalizzati. Attraverso i moduli HTTP personalizzati e standard, SharePoint utilizza ASP.NET mentre mantiene uno stretto controllo su tutte le richieste alle applicazioni di SharePoint.

Notare che quando si crea un'applicazione Web utilizzando il sito Amministrazione centrale SharePoint 3.0, WSS aggiunge la mappa di applicazioni con caratteri jolly per il sito Web IIS selezionato e crea i file global.asax e web.config nella cartella principale del sito Web. Ogni applicazione Web utilizza il suo insieme di file global.asax e web.config.

Per elaborare le richieste e restituire informazioni significative ai browser, WSS 3.0 e MOSS 2007 si avvalgono del parser di pagine ASP.NET standard, che compila le pagine ASP.NET richieste o le elabora senza modalità di compilazione. Ma le pagine di ASP.NET che SharePoint passa al parser ASP.NET non sono necessariamente localizzate dove sembrano essere. Ad esempio, non sarà possibile trovare un file default.aspx nella cartella principale di un sito Web esteso di SharePoint, come il sito Amministrazione centrale SharePoint 3.0, ma viene comunque aperto il file default.aspx quando si visualizza la home page di questo sito Web. È il componente di SPVirtualPathProvider che virtualizza l'ambiente caricando il contenuto della pagina dal file system locale o da un database del contenuto SQL Server e passandolo come file virtuale al parser di pagine ASP.NET. Per il sito Amministrazione Centrale, SharePoint carica il file di default.aspx dalla cartella C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.

La home page, come pure la maggior parte delle pagine del sito SharePoint, è collegata a una pagina master di ASP.NET (default.master) che implementa un layout comune per controlli di navigazione e menu. Il file default.master risiede nella cartella C:\Programmi\File comuni\Microsoft Shared\Web Server Extensions\12\Template\Global e contiene dei segnaposti denominati per ulteriori pagine contenuto che possono anche risiedere sul file system locale o in un database del contenuto SQL Server. Il punto principale è che quando si apre un sito di SharePoint in un browser Web, di fatto si visualizzano le informazioni da una raccolta di pagine contenuto che non sono necessariamente ubicate sul server Web locale e sono disposte secondo un layout definito in una pagina master.

La regola generale è che le pagine non modificate (o non personalizzate, secondo la terminologia SharePoint) esistono come modelli di pagina sul file system locale di ogni server SharePoint, e le pagine personalizzate vengono scritte nel database del contenuto in modo che tutti i server SharePoint di una Web farm abbiano accesso allo stesso insieme di pagine (vedere la figura 3). Si presuppone che le pagine non personalizzate siano identiche su tutti i server e i siti della Web farm. Tuttavia, se si personalizza una pagina contenuto o una pagina master in un sito SharePoint, magari utilizzando Office SharePoint Designer 2007, SharePoint archivia automaticamente la pagina personalizzata nel database del contenuto.

Figura 3** Pagine ASP.NET personalizzate e non personalizzate in un'applicazione di SharePoint **(Fare clic sull'immagine per ingrandirla)

Oltre alle pagine personalizzate e ad altro contenuto del sito Web, SharePoint archivia anche i dati di configurazione in un database SQL Server. SharePoint tiene separati i dati di configurazione dal contenuto perché i dati di configurazione sono di natura globale mentre il contenuto è specifico di ogni singola applicazione Web e raccolta siti. In conseguenza, una Web farm può avere soltanto un database di configurazione ma può avere più database del contenuto.

Tutti i server WSS della Web farm utilizzano lo stesso database di configurazione per condividere i metadati, le impostazioni di configurazione e le informazioni su ogni sito Web IIS solo che è stato esteso con SharePoint nella Web farm. Le singole applicazioni Web, d'altra parte, possono essere associate a uno o più database del contenuto (sebbene ogni database del contenuto possa solo essere associato a un'applicazione Web).

La relazione tra i siti Web IIS, le applicazioni Web, le raccolte siti, i siti e i database del contenuto possono confondere. Nella terminologia di SharePoint, per applicazione Web si intende un sito Web IIS esteso di SharePoint. Un'applicazione Web può contenere varie raccolte siti e ogni raccolta siti può includere un sito di livello superiore e altri siti di livello inferiore che condividono le stesse impostazioni di configurazione.

Fra le altre cose, la creazione di più raccolte siti permette di delegare l'amministrazione delle raccolte siti a diversi utenti e gruppi. Una singola raccolta siti non può essere suddivisa in più database del contenuto, ma un'applicazione Web può utilizzare più database del contenuto per più raccolte siti per aumentare la scalabilità e attenuare l'impatto sulle prestazioni di un grande sito che genera una quantità significativa di attività di database su altri siti SharePoint. Tuttavia, non è una buona idea collocare ogni sito SharePoint nella sua raccolta siti perché questa forma di distribuzione limita la funzionalità di interazione tra i vari siti.

WSS 3.0 non supporta ricerche di contenuto in più raccolte siti. Per queste ricerche è necessario MOSS 2007 o Microsoft Search Server 2008. Ad esempio, è possibile creare un'applicazione Web e un sito di livello superiore per http://contoso, mentre un amministratore di raccolte siti può creare i siti di livello inferiore utilizzando l'interfaccia utente di SharePoint, ad esempio http //contoso/info e http://contoso/events. Tutti i siti si trovano nello stesso database del contenuto perché appartengono alla stessa raccolta siti.

L'amministratore della farm può anche utilizzare un percorso gestito, ad esempio /sites, e definire poi le raccolte siti aggiuntive, come http://contoso/sites/IT e http://contoso/sites/HR, in Amministrazione centrale SharePoint 3.0. Queste raccolte siti (http://contoso, http://contoso/sites/IT, e http://contoso/sites/HR) possono avere amministratori di raccolta siti, impostazioni di configurazione e database del contenuto diversi, ma in ogni caso l'accesso a tutte e tre avviene attraverso lo stesso sito Web IIS (http://contoso) e tutte utilizzano la stessa identità di pool di applicazioni dell'applicazione Web.

Dettagli a parte, questa relazione fra IIS, ASP.NET ed SQL Server è molto importante da capire se si desidera avere un rapporto soddisfacente con SharePoint. Se siete interessati a saperne di più sull'architettura di SharePoint, consiglio l'articolo di Ted Pattison pubblicato su MSDN® Magazine, dal titolo "Discover Significant Developer Improvements in SharePoint Services," disponibile all'indirizzo msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.

Elementi dell'infrastruttura SharePoint

A questo punto, convertiamo la nostra breve discussione sull'architettura in un'infrastruttura SharePoint flessibile. Come avrete certamente notato, sono necessari Windows Server®, IIS, .NET Framework 3.0 (sia per ASP.NET che per Windows® Workflow Foundation), WSS 3.0 o MOSS 2007 e SQL Server. Anche se sarebbe possibile utilizzare IIS 7.0 su Windows Server 2008, utilizzeremo IIS 6.0 su Windows Server 2003 per i nostri scopi, perché al momento è questa la versione più diffusamente distribuita. Resteremo nell'ambito di WSS 3.0 perché non abbiamo bisogno di alcuna funzionalità specifica di MOSS 2007 per un progetto SharePoint pilota.

Per un approccio minimalista, è possibile installare WSS 3.0 con tutti i componenti richiesti su un computer solo (come delineato nel pdf su WSS 3.0 installato su un computer solo, disponibile come materiale di accompagnamento a questa rubrica), una buona soluzione sia per un server di laboratorio che per un piccolo ambiente per gruppo di lavoro. Tuttavia, se si intende concentrarsi sulla flessibilità dell'infrastruttura SharePoint, non si dovrebbe iniziare con una distribuzione autonoma in un ambiente di produzione. Per questioni di disponibilità e scalabilità future, è meglio iniziare con un'infrastruttura multilivello e aggiunge i server nel momento in cui servono.

Nella figura 4 è mostrata l'infrastruttura SharePoint consigliata se si desidera una configurazione di sistema più semplice e flessibile. Questa infrastruttura contiene una Web farm di due server SharePoint e un computer a parte che esegue SQL Server. Questa configurazione elimina l'overhead di elaborazione del database sui server Web, aumenta la disponibilità, la scalabilità e facilita la manutenzione di sistema. Notate che Active Directory® è necessario perché è un requisito software di WSS 3.0 in una distribuzione di Web farm. Per la procedura di distribuzione, è possibile consultare il pdf sull'infrastruttura SharePoint di base nel materiale di accompagnamento.

Figura 4** L'infrastruttura SharePoint di base che agevola la crescita futura **(Fare clic sull'immagine per ingrandirla)

L'account di dominio utilizzato per distribuire SharePoint in questa configurazione richiede le autorizzazioni di amministratore locale sui server Web. È anche necessario aggiungere questo account ai ruoli dbcreator e securityadmin di SQL Server come pure al ruolo db_owner per il database master di SQL Server 2005, come illustrato nel pdf sull'infrastruttura SharePoint di base. A questo punto, è possibile utilizzare Configurazione guidata Prodotti e tecnologie SharePoint durante l'installazione di WSS 3.0 per creare il database di configurazione necessario per la Web server farm e un database del contenuto per il sito Amministrazione centrale SharePoint 3.0. In alternativa, è possibile ottenere questi database da un amministratore SQL Server e poi aggiungere gli account di sistema di SWW al ruolo db_owner.

È importante tenere a mente che l'account utente utilizzato per installare SharePoint non è l'account che SharePoint utilizza per accedere al database di configurazione o al database del contenuto del sito Amministrazione Centrale. SharePoint, infatti, utilizza l'account di sistema configurato come identità del pool di applicazioni per il sito Amministrazione centrale SharePoint 3.0.

La Configurazione guidata Prodotti e tecnologie SharePoint richiederà le informazioni sull'account. È buona norma utilizzare un account utente di dominio dedicato a questo scopo, ad esempio CONTOSO\WssConfigAdmin. Personalmente, come prassi generale, utilizzo singoli account utente dedicati per ogni applicazione Web che creo successivamente. Utilizzando un pool di applicazioni separato per ogni applicazione Web aiuta ad assicurare l'isolamento dei processi e utilizzando un account utente diverso per ogni pool di applicazioni aiuta a mantenere l'isolamento di protezione. Questo, però, è solo un approccio, e la facilità di gestione e il potenziale impatto sulle prestazioni che può avere deve essere valutato a fronte dei vari ambienti e requisiti aziendali.

Un altro account di sistema importante che un amministratore del dominio dovrebbe creare per voi è l'account del servizio di ricerca. È possibile utilizzare l'account di Amministrazione centrale ma, per avere una maggiore sicurezza, è meglio utilizzare un account di ricerca dedicato, ad esempio CONTOSO\WssSearch, che non dispone di autorizzazioni amministrative e non può modificare alcun contenuto. L'autorizzazione di scrittura nei database del contenuto non è necessaria perché il servizio di ricerca effettua ricerche nei contenuti solo a scopo di indicizzazione e conserva i dati della ricerca in un database a parte.

Quando si crea un'applicazione Web in una server farm, è possibile associare il database del contenuto a un server di ricerca, che aggiunge implicitamente l'account del servizio di ricerca corrispondente al criterio Lettura completa dell'applicazione Web. I server di ricerca sono server SharePoint che eseguono il servizio di ricerca di Windows SharePoint Services. Se è stata seguita la procedura riportata nel pdf sull'infrastruttura SharePoint di base, entrambi i server Web sono stati configurati come server di ricerca in modo che possa essere distribuito il carico di lavoro di ricerca e indicizzazione di più database del contenuto. Tuttavia, è anche possibile configurare un server di ricerca dedicato in una Web farm, escluso dal bilanciamento del carico di rete e dalle connessioni client, in modo che le connessioni di client non vengano interessate dalle attività di ricerca per indicizzazione.

Gestione dei siti self-service

Una volta preparata l'infrastruttura SharePoint di base, è possibile delegare l'amministrazione di raccolte siti e siti ai singoli reparti e utenti, senza decentralizzare il controllo amministrativo su Active Directory, la Web server farm o i database SQL Server. L'amministratore della farm collabora con gli amministratori di Active Directory e SQL Server per fornire gli account del pool di applicazioni e i database del contenuto per le applicazioni Web. In queste applicazioni Web è possibile creare raccolte siti e designare gli amministratori delle raccolte siti con il diritto di creare siti di livello inferiore. In questo modo, gli amministratori delle raccolte siti dei singoli reparti possono gestire le loro risorse SharePoint con il minimo coinvolgimento del reparto IT, come mostrato nella figura 5.

Figura 5** L'amministrazione decentralizzata dei siti in un'infrastruttura SharePoint centralizzata **(Fare clic sull'immagine per ingrandirla)

È anche possibile offrire agli utenti la capacità di creare raccolte siti sotto percorsi gestiti (ad esempio, il percorso /sites o altri percorsi gestiti con inclusioni di caratteri jolly creati in Amministrazione centrale SharePoint 3.0). Se si attiva la funzionalità Gestione siti in modalità self-service in un'applicazione Web, gli utenti possono creare le loro raccolte siti e gestire i gruppi di siti e le autorizzazioni nell'interfaccia utente di SharePoint. Diversamente dai siti di livello inferiore, le raccolte siti non ereditano autorizzazioni da un sito padre.

La Gestione siti in modalità self-service non è adatta a ogni ambiente SharePoint ed è disattivata per impostazione predefinita. Se la si attiva, si può causare la presenza di un numero molto elevato di raccolte siti raramente utilizzate nei database del contenuto. Tuttavia, questa funzionalità dimostra molto chiaramente la flessibilità di amministrazione di SharePoint, e io consiglio di provarla nella distribuzione pilota. (In SharePoint sono disponibili alcune opzioni per notificare a utenti e/o amministratori i siti inattivi che, così, possono essere rimossi). È necessario attivare la Gestione siti in modalità self-service per un'applicazione Web, come illustrato nel pdf sull'attivazione della gestione dei siti self-service, disponibile nel materiale di accompagnamento.

Personalizzazioni e branding di SharePoint

Risorse SharePoint

• Windows SharePoint Services TechCenter
• Centro per sviluppatori di Windows SharePoint Services
• Blog del team Prodotti e tecnologie Microsoft SharePoint
• I componenti logici dell'architettura
• Progettare server farm e topologie

A questo punto, è naturale voler includere il logo, il nome e i colori aziendali nell'interfaccia utente di SharePoint. L'unica cosa da sapere a proposito è che si sta per portare il progetto SharePoint al livello di sviluppo ASP.NET. Come minimo, si ha bisogno di un sistema di sviluppo, ad esempio un server WSS autonomo con Microsoft Office 2007 SharePoint Designer (è possibile consultare il pdf sull'installazione di SharePoint Designer, disponibile nel materiale di accompagnamento) in modo da poter creare e testare le personalizzazioni senza interessare l'ambiente di produzione. Inoltre, è necessario visitare il Centro per sviluppatori di Windows SharePoint Services all'indirizzo msdn2.microsoft.com/SharePoint per saperne di più sulla ricchezza di opzioni di personalizzazione che SharePoint offre.

Anche se lo sviluppo SharePoint non rientra nell'ambito di questa rubrica, vorrei far notare alcuni aspetti da prendere in considerazione. SharePoint archivia le pagine personalizzate nel database del contenuto della raccolta siti corrispondente. In altre parole, qualunque personalizzazione applicata alle pagine del sito, alle pagine delle applicazioni, alle pagine master, ai fogli di stile, e così via, in un sito SharePoint viene applicata soltanto a livello di raccolta siti o sito. Questo è un vantaggio per gli amministratori delle singole raccolte siti che vogliono regolare l'aspetto dei loro siti con SharePoint Designer 2007, ma non per un amministratore di farm che vuole applicare l'identità aziendale in tutte le applicazioni Web, le raccolte siti e i siti di una Web farm.

È possibile creare temi sito personalizzati o definizioni sito personalizzate partendo dalla copia di un tema o una definizione sito standard di SharePoint. È anche possibile creare pagine master personalizzate e aggiungerle alla Raccolta pagine master. Tuttavia, nessuna di queste opzioni permette di imporre il branding globale se è attiva la Gestione siti in modalità self-service, poiché un utente con le autorizzazioni per creare raccolte siti o siti può selezionare un modello di sito standard che non riporta l'identità aziendale.

Il branding globale richiede di sostituire i componenti SharePoint predefiniti per utilizzare al loro posto i componenti personalizzati. Gli sviluppatori hanno fatto molti progressi per arrivare a effettuare questa attività senza modificare i file originali. Un approccio consiste nel modificare la configurazione delle directory virtuali in Gestione IIS e creare puntamenti tra queste e nuove cartelle con i file personalizzati. Un altro metodo consiste nell'implementare un filtro ISAPI o un modulo HTTP personalizzato che riscrive gli URL per reindirizzare le richieste di specifiche pagine predefinite alle versioni personalizzate.

Conclusioni

Ci siamo concentrati sui punti fondamentali per creare un'infrastruttura SharePoint con WSS 3.0. Non ho coperto altre funzionalità, quali flussi di lavoro, indagini, integrazione della messaggistica e antivirus, né funzionalità specifiche di MOSS 2007, quali portali, directory di siti e cataloghi dati business. Le personalizzazioni per l'amministrazione del sito e il branding aziendale hanno toccato solo in parte le possibilità offerte da SharePoint. È possibile effettuare ulteriori personalizzazioni con WSS 3.0 programmando delle applicazioni personalizzate in Visual Studio®.

L'infrastruttura è abbastanza robusta per gestire la crescita futura, nel caso vengano aggiunti altri server Web o server di database. Con il lancio pilota di alcune personalizzazioni, gli utenti possono creare singoli siti e acquisire familiarità con SharePoint. In questo modo, è possibile stabilire i componenti di base che gli utenti possono adottare, nonché l'hardware e il software, che sono abbastanza flessibili da consentire eventuali modifiche e servire come base per un vero e proprio lancio in produzione.

Pav Cherny è un esperto IT e un autore specializzato in tecnologie Microsoft per la collaborazione e le comunicazioni unificate. Le sue pubblicazioni includono white paper, manuali di prodotti e libri su amministrazione del sistema e operazioni IT. Pav è Presidente di Biblioso Corporation.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.