Luglio 2008 Luglio 2008
IIS: Come usare subito IIS 7.0
La versione 7.0 di Internet Information Services definisce nuovi standard, offre miglioramenti fondamentali e apporta nuove capacità per il consolidamento degli ambienti Web. In questo articolo vengono esaminati importanti miglioramenti e viene offerta una guida approfondita al test, alla preparazione e alla migrazione delle applicazioni Web in IIS 7.0. Fergus Strachan
Comunicazioni e Collaborazione: Pianificazione della migrazione alla messaggistica unificata
Passare da un sistema legacy di posta elettronica a una piattaforma di messaggistica unificata può essere piuttosto semplice e comportare pochi disagi agli utenti finali. A condizione che venga adottata una pianificazione chiare e coerente. Ecco quello che bisogna fare per pianificare la migrazione, testare i nuovi sistemi e implementare la messaggistica unificata nell'organizzazione. Jeff Goodwin
Comunicazioni e Collaborazione: L'importanza della voce in OCS 2007
Microsoft Office Communication Server rappresenta un'innovazione importante nel campo della telefonia aziendale. Scoprite come vengono effettuate le chiamate vocali, livello per livello, e come poter instradare le chiamate a vari endpoint ed esaminate l'importanza delle conversazioni nelle comunicazioni OCS. Rajesh Ramanathan
Comunicazioni e Collaborazione: Creazione di connessioni potenti con Groove e SharePoint
Microsoft Office Groove e SharePoint Server combinati forniscono potenti capacità di collaborazione. Confrontateli per rilevare le differenze e gli elementi che li rendono l'uno complementare per l'altro; scoprite inoltre in che modo è possibile integrare Groove e SharePoint per fornire una soluzione di collaborazione flessibile che supporti gli utenti in contesti differenti. Alan Maddison
Amministrazione di Windows: Introduzione a Clustering di failover di Windows Server 2008
Per anni gli utenti si sono lamentati perché in Windows Server il clustering era troppo complicato. Con il rilascio di Windows Server 2008, il clustering è stato sottoposto a una ristrutturazione completa. Esplora alcune delle innovazioni più rilevanti presenti in Clustering di failover di Windows Server 2008, per vedere come questa nuova implementazione rende molto più facili l'installazione e la gestione dei cluster. Chuck Timon
Columns
From the Editor: La stampa è morta: | Letters: La parola ai lettori: | Toolbox: Nuovi prodotti per professionisti IT:
Exchange Queue & A: Bilanciamento del carico, Trasporto Edge e altro: Hai domande su Exchange? In questo numero risponderemo alle domande sull'uso di Exchange con SharePoint, sull'uso della replica continua di standby, sull'installazione di server Cassetta postale Exchange 2007 in Windows Server 2008 e altro.Henrik Walther | Utility Spotlight: Microsoft SharedView: State cercando un modo per collaborare con qualcuno che vive in un'altra città? Date un'occhiata a Microsoft SharedView, un programma di utilità gratuito che vi consentirà di condividere facilmente documenti e schermate con tutti i membri di un piccolo gruppo, al di là dei confini fisici.Greg Steen | Inside SharePoint: Integrazione delle applicazioni di Microsoft Office: Scopri in che modo le applicazioni di Microsoft Office si integrano e comunicano con SharePoint ed esplora i diversi modi in cui, utilizzando gli stessi principi, è possibile integrare con SharePoint le applicazioni non Microsoft.Pav Cherny
Windows PowerShell: La scatola delle palline da ping-pong: Don Jones parla delle funzioni di filtro, della pipeline, degli oggetti personalizzati e di come in semplici palline da ping-pong si nasconda il segreto per capire Windows PowerShell.Don Jones | Hey, Scripting Guy!: La scarica di adrenalina: Gli Scripting Guy descrivono l'adrenalinica attività di scripting e mostrano come accedere al nuovo archivio dati di configurazione di avvio in Windows Vista e Windows Server 2008 utilizzando gli script.Microsoft Scripting Guys | The Desktop Files: Avvio da rete in Windows: Esplorate la cronologia di Servizi di installazione remota (RIS) e le altre tecnologie correlate a PXE e utilizzato in Microsoft.Wes Miller
Security Watch: Password e carte di credito, Parte 1: La prima di una serie in tre parti in cui si analizza l'inadeguatezza delle prassi più comuni e dei consigli più diffusi nell'ambito della sicurezza, che invece si rivelano di ostacolo ai molti sforzi che pure hanno lo stesso obiettivo.Jesper M. Johansson | Field Notes: Garantire la correttezza delle elezioni: In questo articolo vengono esaminate le vulnerabilità nell'attuale sistema elettorale degli Stati Uniti e viene illustrato come usare la crittografia per ottenere risultati elettorali completamente verificabili.Josh Benaloh | Windows Confidential: E la storia continua: Microsoft Bob è molto più diffuso di quanto si pensi. Raymond Chen spiega in che modo Microsoft Bob ha fatto il suo ingresso in milioni di abitazioni.Raymond Chen


IIS
Come usare subito IIS 7.0
Fergus Strachan
Panoramica:
  • Distribuzione di IIS 7.0 in un ambiente di Web farm
  • Miglioramenti della sicurezza e delle prestazioni
  • Migrazione delle applicazioni Web ASP.NET da IIS 6.0 a IIS 7.0
  • Migrazione delle applicazioni Web PHP a IIS 7.0

Indice
Preparazione, configurazione e test
Configurazione del test
Miglioramenti importanti per gli amministratori IT
Architettura IIS
Modalità classica e integrata
Moduli e funzionalità
Migrazione delle applicazioni Web
Conclusioni
Il team IIS di Microsoft sostiene che IIS (Internet Information Services) 7.0 è la versione migliore nella storia di IIS. Questa versione imposta nuovi standard, presenta miglioramenti sostanziali e
apporta nuove capacità per consolidare gli ambienti Web. IIS 7.0, inclusa in Windows Server® 2008 e Windows Vista® SP1, è già in forza a Microsoft.com e diverse società di hosting Web hanno già iniziato a fornire l'hosting di IIS 7.0 ai progettisti e agli sviluppatori Web che intendono trasportare le loro applicazioni Web esistenti alla nuova piattaforma per server Web.
In questo articolo esaminerò i miglioramenti principali di IIS 7.0 che sono essenziali per i professionisti IT ed approfondirò la migrazione ASP.NET e le applicazioni Web PHP. Ma prima di tutto voglio definire un laboratorio di test che assomiglia a un ambiente di produzione di base.
Si tratta di un'attività importante. Prima di distribuire IIS 7.0 ai server di produzione, è necessario dedicare del tempo al test in un ambiente di laboratorio per verificare che le applicazioni Web vengano eseguite senza problemi nel nuovo server Web.

Preparazione, configurazione e test
Il mio test di laboratorio include sistemi in cui sono in esecuzione Windows Server 2003 e IIS 6.0, che ospitano applicazioni ASP.NET e server in cui sono in esecuzione la distribuzione Ubuntu 7.10 Linux e Apache HTTP Server 2.2, che ospitano applicazioni Web basate su PHP. Il mio obiettivo finale è distribuire Windows Server 2008 in sistemi di gestione e produzione e quindi complesse applicazioni Web di transizione al fine di sostituire le istanze di IIS 6.0 e di Apache con IIS 7.0.
Dispongo di due applicazioni Web principali: DotNetNuke 4.7 e osCommerce 3.0a4. DotNetNuke è un framework di applicazione Web basato su ASP.NET 2.0 e Microsoft® SQL Server®. L'altra applicazione, osCommerce, è l'ultima versione alfa di una ricca soluzione di e-commerce creata in PHP in MySQL. Pertanto inseriamo queste applicazioni avanzate in IIS 7.0.
Voglio chiarire che non è mia intenzione fare confronti tra versioni, prodotti o piattaforme software. Tuttavia esistono diversi vantaggi nella standardizzazione di Windows Server 2008 e IIS 7.0 che devo sottolineare. Vale a dire, la ridotta complessità di gestione e la possibilità di ridurre al minimo il numero globale di server Web in esecuzione.
Nella Figura 1 viene fornita una panoramica del laboratorio di test che uso per questo articolo. Se si intende seguire le mie spiegazioni nel proprio ambiente di test, è possibile reperire collegamenti ai componenti software necessari e istruzioni dettagliate per l'installazione nel materiale di accompagnamento disponibile nella sezione Code Downloads del sito Web TechNet Magazine.
Figura 1 Ambiente di test per implementare IIS 7.0 (fare clic sull'immagine per ingrandirla)
Notare che, mentre stavo scrivendo questo articolo, Microsoft ha rilasciato uno strumento per la riga di comando (MSDeploy.exe) per supportare la distribuzione, la sincronizzazione e la migrazione di applicazioni Web in IIS 6.0 e 7.0 da parte dei clienti. Consiglio di prendere in considerazione questo strumento. Informazioni dettagliate sono reperibili presso il blog del team Microsoft Web Deployment all'indirizzo go.microsoft.com/fwlink/?LinkId=118272.

Configurazione del test
Al momento di scrivere questo articolo, Windows Server 2008 era ancora in fase di prerilascio, pertanto non ho potuto sostituire Windows Server 2003 nei server di database o controller di dominio. Con il rilascio ufficiale di Windows Server 2008, entra in ballo anche la migrazione dell'infrastruttura di Active Directory®. Anche la migrazione dei database SQL Server® 2005 e MySQL in SQL Server 2008 va oltre l'ambito di questo articolo.
Ho distribuito SQL Server 2008 nel mio server di gestione principalmente perché è più semplice che installare SQL Server 2005 con Service Pack 2. L'esecuzione di DotNetNuke con un database SQL Server 2008 non ha presentato problemi. Anche l'installazione di MySQL 5.0 in Windows Server 2008 è avvenuta senza complicazioni.
Sebbene IIS 7.0 sia disponibile in Server Core, non ho usato un'installazione Server Core per via di determinati requisiti per il mio test. Il server di gestione richiedeva un'installazione completa in quanto si trattava del sistema di test primario. Inoltre, Microsoft .NET Framework non è disponibile in Server Core.
PHP viene eseguito correttamente in Server Core, ma il mio obiettivo è consolidare le applicazioni ASP.NET e PHP, pertanto Server Core semplicemente non costituisce un'opzione. Finché .NET Framework non sarà supportato in Server Core, sarà necessario eseguire un'installazione completa per supportare le applicazioni ASP.NET. Per istruzioni dettagliate su come installare l'ambiente di test, esaminare il file 01_install_testlab.htm nel materiale di accompagnamento.
Ho optato per l'esecuzione di un'installazione pulita di Windows Server 2008 (invece di aggiornare i server esistenti). Tra le altre cose, l'installazione pulita facilita l'implementazione di uno scenario di migrazione gestita come quello della Figura 2. La strategia implicita è conservare le Web farm esistenti finché tutti i componenti delle applicazioni Web pertinenti non sono stati regolarmente verificati nel server di gestione e spostati nella nuova Web farm IIS 7.0.
Figura 2 Gestione del passaggio a IIS 7.0 (fare clic sull'immagine per ingrandirla)
È possibile spostare tutte le applicazioni Web esistenti in una sola volta o gradualmente, a seconda della complessità dell'ambiente. Per ogni applicazione o sito Web, dopo aver eseguito un test finale di accettazione nella nuova Web farm, è possibile effettuare il passaggio modificando i record DNS pertinenti in modo da indirizzare i browser alla nuova Web farm IIS 7.0. In questo modo si riducono al minimo i fermi e le interruzioni.

Miglioramenti importanti per gli amministratori IT
In MSDN® Magazine è pubblicato un articolo eccellente di Mike Volodarsky dal titolo "Esplorazione del server Web per Windows Vista e altro ancora" (disponibile all'indirizzo msdn2.microsoft.com/magazine/cc163453.aspx), che insegna subito a mettere a frutto i miglioramenti riscontrati in IIS 7.0.
Un'altra lettura utile è un articolo sul blog del team di Microsoft.com dal titolo "The Tasty Morsels Found in Dogfood", disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=117436 (in inglese). L'articolo riepiloga le esperienze iniziali del team in merito a IIS 7.0. In breve, classificano i principali miglioramenti come:
  1. Configurazione semplificata.
  2. Grande compatibilità.
  3. Non più metabase.
  4. Configurazione centralizzata per mezzo del file applicationHost.config che si trova in una condivisione UNC.
  5. Configurazione delegata per mezzo di file web.config nelle directory delle applicazioni.
  6. Strumenti di gestione migliorati.
  7. Traccia delle richieste non riuscite.
  8. Filtraggio delle richieste senza la necessità di URLScan.
  9. Semplificazione della disponibilità della sincronizzazione del contenuto per mezzo delle condivisioni UNC.
10. Cache di output del contenuto dinamico.
La semplificazione della configurazione è uno dei miei obiettivi principali. Nell'articolo sul blog, il team di Microsoft.com dimostra come è possibile distribuire tutte le funzionalità di IIS 7.0 (o, naturalmente, solo quelle che interessano) con una sola riga di comando. Ho incorporato questo approccio con entusiasmo nelle istruzioni per la configurazione del laboratorio di test; la riga di comando è mostrata nella Figura 3.
Dichiaratamente questo comando è piuttosto lungo (se si intende copiare questo comando, consiglio di copiarlo e incollarlo dal sito Web TechNet Magazine invece di ridigitarlo a mano). Sebbene questo comando inserisca tutti i moduli disponibili nel computer IIS 7.0, non include PHP. IIS 7.0 non include PHP e il concetto di scaricare e installare pacchetti Debian in Internet è estraneo a Windows® Package Manager (pkgmgr.exe). Accedere a Windows Automated Installation Kit (AIK).
Figura 3 Distribuzione delle funzionalità IIS 7.0 con una sola riga di comando
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
AIK consente di creare un DVD di installazione personalizzato per Windows Server 2008, contenente IIS 7.0 e PHP 5. È possibile includere anche MySQL, file di applicazioni Web e tutti gli altri componenti che sono necessari alla propria distribuzione. Tutti i componenti possono far parte dell'installazione di Windows Server 2008; in tal modo è possibile applicare personalizzazioni a tutti i server Web in modo coerente. Righe di comando o modifiche al file di configurazione non sono necessarie.
È possibile creare un DVD personalizzato anche per le installazioni completamente autonome. L'AIK include documentazione e strumenti per creare un file AutoUnattend.xml, che può essere quindi inserito nella cartella principale del DVD. Il file Custom Image Deployment.htm nel materiale di accompagnamento offre istruzioni dettagliate.
Molti amministratori concordano anche sul fatto che la compatibilità è un miglioramento essenziale. Procedendo mi aspettavo di incontrare alcuni problemi di compatibilità con DotNetNuke e osCommerce ma la transizione a IIS 7.0 è andata piuttosto liscia, nonostante il fatto che entrambe queste applicazioni Web includono funzionalità avanzate come l'autenticazione dei moduli e URL facili da trovare con i motori di ricerca.
Con DotNetNuke, non ho incontrato nessun problema finché non sono passato a uno scenario di Web farm complesso, con condivisione del contenuto in una piattaforma a 64 bit. Il problema era comunque di lieve entità. In definitiva, grazie a questa compatibilità migliorata, l'esecuzione delle applicazioni Web in IIS 7.0 richiede meno tempo.
Se si dovessero verificare problemi di compatibilità con le applicazioni Web, il supporto incorporato per la diagnostica e la traccia si rivelerà una delle nuove funzionalità più utili. Le informazioni dettagliate della diagnostica sono molto istruttive e i percorsi di soluzione sono utili ed efficaci.
Nella Figura 4 sono mostrate le informazioni di diagnostica ottenute quando si esegue DotNetNuke 4.7 in IIS 7.0 in modalità integrata. In questo esempio, ci sono tre opzioni (mostrate nella sezione "Possibili operazioni"). Modificare l'applicazione in modo da supportare la modalità integrata probabilmente è la scelta migliore per gli sviluppatori DotNetNuke. È invece una cattiva idea ignorare l'errore. Preferisco la terza scelta e attivare la modalità classica cambiando l'applicazione Web nella classica .NET AppPool, perché voglio che l'esecuzione di DotNetNuke 4.7 sia invariata in IIS 7.0.
Figura 4 Informazioni di diagnostica per l'esecuzione di DotNetNuke in modalità integrata (fare clic sull'immagine per ingrandirla)

Architettura IIS
È lecito chiedersi cosa siano queste modalità integrata e classica e perché influiscano sull'applicazione ASP.NET (DotNetNuke) ma non sull'applicazione PHP (osCommerce). Per una maggiore comprensione, è necessario innanzitutto dare uno sguardo all'architettura di IIS 7.0. Le versioni precedenti integrano il runtime ASP.NET nel server Web di base, principalmente attraverso un'estensione ISAPI (aspnet_isapi.dll). IIS 7.0, d'altro canto, consente ai moduli ASP.NET di collegarsi direttamente al server Web di base per mezzo di un modulo HTTP a livello globale chiamato ManagedEngine, che carica la DLL di supporto ASP.NET (webengine.dll) nella pipeline di elaborazione della richiesta di IIS 7.0.
I moduli nativi usano l'API del server Web principale di IIS per la registrazione per specifici eventi nella pipeline, ad esempio BeginRequest, AuthenticateRequest, AuthorizeRequest e ExecuteRequestHandler. ManagedEngine fornisce il supporto necessario a integrare anche i moduli ASP.NET nella pipeline di elaborazione della richiesta. Con questa nuova architettura, IIS 7.0 può richiamare i moduli nativi e ASP.NET in qualsiasi momento durante l'elaborazione della richiesta, indipendentemente dal tipo di contenuto della richiesta.
Prendiamo in considerazione, ad esempio, l'autenticazione utente ASP.NET. In IIS 6.0, un modulo HTTP basato su ASP.NET può registrarsi per eventi OnAuthenticate (ad esempio FormsAuthentication.OnAuthenticate e WindowsAuthentication.OnAuthenticate) per impostare l'identità dell'utente nel HttpContext corrente. Questo funziona benissimo all'interno del runtime ASP.NET ma non è possibile usare questo codice ASP.NET per proteggere le risorse esposte attraverso un'applicazione Web basata su PHP.
In base alla configurazione della scriptmap, IIS 6.0 inoltra le richieste per i tipi di contenuto ASP.NET a aspnet_isapi.dll ma non inoltra le richieste per i tipi di contenuto PHP all'estensione ISAPI per ASP.NET. Dopo tutto, ASP.NET non elabora il codice PHP ma ciò significa anche che il codice di autenticazione ASP.NET non viene eseguito se è richiesta una pagina PHP. Pertanto, con IIS 6.0, è necessario duplicare la logica di autenticazione perché le applicazioni PHP devono implementare i loro meccanismi di autenticazione.
IIS 7.0 usa un modello di elaborazione guidato da eventi che supporta la combinazione e l'associazione di singoli moduli nella pipeline di elaborazione della richiesta. Tra gli altri componenti, IIS 7.0 è dotato di moduli WindowsAuthentication e FormsAuthentication gestiti che generano eventi OnAuthenticate quando la pipeline di elaborazione della richiesta genera l'evento AuthenticateRequest. A questo punto è possibile che un modulo nativo, come RequestFilteringModule o IpRestrictionModule, gestisca l'evento BeginRequest in modo da rifiutare richieste critiche, quindi esegua il codice di autenticazione ASP.NET personalizzato in corrispondenza dell'evento AuthenticateRequest e che FastCgiModule esegua il motore di scripting di PHP (php-cgi.exe) in corrispondenza dell'evento ExecuteRequestHandler per elaborare le pagine PHP.
Il risultato di questa architettura integrata è che gli sviluppatori Web non devono duplicare il codice per implementare la comune logica aziendale. È possibile usare il codice di autenticazione ASP.NET personalizzato per proteggere tutte le risorse IIS, comprese le applicazioni PHP. È possibile anche eseguire altre attività di pre e post elaborazione per mezzo dei moduli ASP.NET, come la riscrittura di URL, la traccia personalizzata e la registrazione degli errori.

Modalità integrata e classica
L'effetto collaterale causato da questa nuova architettura è che le applicazioni ASP.NET esistenti potrebbero richiedere modifiche al codice e alla configurazione che dovrebbero essere eseguite dagli sviluppatori delle applicazioni, per garantire che le modifiche non comportino conflitti tra i moduli nella pipeline di elaborazione della richiesta. Ma se non è possibile trasferire immediatamente un'applicazione Web esistente, è possibile attivare la modalità classica nel pool di applicazioni usato dal processo di lavoro per eseguire l'applicazione Web. IIS 7.0 non carica ManagedEngine nei processi di lavoro in modalità classica, di conseguenza, in questo caso, la pipeline di elaborazione della richiesta non può risolvere o richiamare i moduli ASP.NET. IIS 7.0 invece attiva diversi gestori degli eventi che sono basati su IsapiModule (aspnet_isapi.dll), per elaborare i tipi di contenuto ASP.NET simili a IIS 6.0. Questo fatto è evidente dall'analisi della sezione dei gestori degli eventi in system.webServer nel file di configurazione applicationHost.config, che si trova per impostazione predefinita nella cartella %WinDir%\System32\InetSrv\Config.
Ad esempio, se si cerca la stringa aspx, si trova una voce che punta a PageHandlerFactory-Integrated (caricato nei processi di lavoro del pool di applicazioni in modalità integrata secondo l'impostazione preCondition="integratedMode") e si trovano altre voci che puntano a PageHandlerFactory-ISAPI-2.0 e PageHandlerFactory-ISAPI-2.0-64 (caricati nei processi di lavoro del pool di applicazioni in modalità classica secondo l'impostazione preCondition="classicMode").
Poiché la modalità della pipeline è impostata a livello di pool di applicazioni, IIS 7.0 può eseguire le applicazioni Web in modalità integrata e in modalità classica contemporaneamente. Quindi i processi di lavoro dovranno semplicemente essere eseguiti in diversi pool di applicazioni ma potranno essere ospitati nello stesso server.
Ricordare che la modalità integrata e la modalità classica influiscono solo su come IIS 7.0 integra ASP.NET nella pipeline di elaborazione della richiesta. Queste modalità della pipeline non influiscono direttamente sulle applicazioni PHP. Il modulo FastCgiModule e tutti gli altri moduli nativi vengono caricati senza precondizioni di modalità pipeline sia nella modalità integrata che in quella classica. FastCGI è l'interfaccia preferita per l'esecuzione del motore di scripting PHP in IIS 7.0. Invece di usare FastCGI, è possibile creare anche un mapping dei gestori per il motore di scripting PHP per mezzo di CGI oppure è possibile usare IsapiModule insieme a PHP-ISAPI (php4isapi.dll).
Tuttavia ritengo che queste alternative di configurazione degli stili IIS 6.0 siano superate ora che FastCGI offre sostanzialmente prestazioni e stabilità migliori. CGI è più lenta dato che IIS deve inizializzare un nuovo processo CGI per ogni richiesta HTTP mentre FastCGI riusa i processi CGI per più richieste. ISAPI richiede una build PHP thread-safe che comporta maggiore overhead rispetto all'esecuzione PHO non thread-safe.
Forse è ancora più importante notare che non tutte le estensioni PHP sono disponibili in una versione thread-safe e che l'esecuzione delle estensioni non thread-safe con ISAPI è una pessima idea in quanto può causare problemi di stabilità nel server. FastCGI, d'altro canto, è un ambiente a singola concorrenza come CGI. Usato per eseguire PHP non thread-safe, è stabile e veloce ed è chiaramente il modo migliore per usare PHP 5 in IIS 7.0. È anche disponibile in IIS 6.0 se non si è ancora pronti per una transizione a IIS 7.0.

Moduli e funzionalità
IIS 7.0 presenta un'architettura strutturata in moduli o, se gli sviluppatori IIS la inseriscono, una serie di funzionalità basate su componenti. Si tratta di una buona notizia per gli amministratori Web che intendono mantenere il footprint e la superficie di attacco della memoria di IIS 7.0 più piccoli possibili. Attivando diversi moduli o perfino sostituendo moduli standard con moduli personalizzati, è possibile avere il controllo completo delle funzionalità IIS 7.0 nei server Web.
Per eseguire ASP.NET in modalità integrata o classica nonché applicazioni PHP nello stesso server, è necessario installare almeno il ruolo di server Web e i moduli principali per supportare l'elaborazione delle richieste, la configurazione del server, ASP.NET, ISAPI e CGI (che include il modulo FastCGI). A questo scopo usare la seguente riga di comando:
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
In genere preferisco installare IIS 7.0 con tutte le opzioni disponibili nel mio server di gestione per garantire che tutti i componenti e gli strumenti amministrativi siano disponibili per attivare ed eseguire velocemente le applicazioni Web. La mia strategia consiste nell'assicurarmi che tutto funzioni e poi restringo la configurazione disinstallando i servizi di ruolo e disattivando i moduli. Quando un'applicazione Web inizia ad agire, aggiungo i servizi o i moduli che ho appena rimosso.
È possibile anche usare Package Manager (pkgmgr.exe) o lo strumento della riga di comando IIS 7.0 (appcmd.exe) oppure modificare la sezione globalModules direttamente nel file applicationHost.config ma trovo che gli strumenti grafici siano molto comodi. Tenere presente che alcuni moduli, come RequestFilteringModule e StaticCompressionModule, sono piuttosto utili anche se, a dire il vero, non sono necessari per l'esecuzione delle applicazioni Web. Se si disinstalla un modulo che è necessario per un pool di applicazioni, si riceve un errore HTTP quando si accede all'applicazione Web, come illustrato nella Figura 5.
Figura 5 Un'applicazione ASP.NET non verrà eseguita in modalità classica perché manca IsapiModule (fare clic sull'immagine per ingrandirla)
Nota: si consiglia di assicurarsi che su tutti i server IIS 7.0 sia installata e attivata la stessa serie di moduli. Per verificare i componenti installati, andare a HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ e controllare le chiavi del Registro di sistema. Un valore REG_DWORD pari a 0000 0001 per una chiave del Registro, ad esempio per NetFxEnvironment o CGI, indica che il componente corrispondente è installato.

Migrazione delle applicazioni Web
Finora ho fatto molta teoria ma è giunto il momento di rimboccarsi le maniche e spostare alcune applicazioni Web in IIS 7.0. Come accennato prima, il server di gestione esegue IIS 7.0 con tutti i componenti disponibili e PHP 5 non thread-safe registrato con FastCGI. Prima di iniziare, devo pormi alcune domande fondamentali:
  • L'applicazione Web richiede un sistema di gestione del database come, ad esempio, SQL Server o MySQL?
  • Devo installare o configurare altri componenti, ad esempio connessioni ODBC, oggetti COM o certificati SSL?
  • L'applicazione Web richiede speciali account di servizio ed elevate autorizzazioni di accesso in locale o in remoto alle condivisioni file e ad altre risorse?
  • Esistono dipendenze nelle funzionalità specifiche della piattaforma che non sono disponibili in IIS 7.0, ad esempio le dipendenze nel modulo Apache per la riscrittura di URL (mod_rewrite)?
Il porsi queste domande aiuta a fare in modo che le applicazioni Web vengano eseguite in IIS 7.0 più velocemente. Ad esempio, se si tenta di eseguire la migrazione di un'applicazione PHP da Apache 2.2 che usa mod_rewrite (diciamo per semplicità del motore di ricerca o per impedire il dirottamento della larghezza di banda tramite immagini collegate in linea), si verificheranno problemi finché non si implementa una soluzione di riscrittura di URL personalizzata e compatibile in IIS 7.0. Fortunatamente, osCommerce non richiede la funzionalità mod_rewrite in IIS 7.0, ma potrebbero richiederla alcuni pacchetti di ottimizzazione del motore di ricerca.
Ora che ho stabilito e installato gli altri componenti necessari nel server di gestione, sono pronto per attivare ed eseguire le applicazioni Web. Anche in questo caso, voglio pormi alcune domande:
  • Qual è la configurazione più semplice che posso usare per supportare l'applicazione Web?
  • Quale configurazione è attualmente usata nell'ambiente di produzione?
  • Posso ottimizzare la configurazione dell'applicazione Web nella nuova piattaforma?
  • Qual è la serie minima di servizi di ruolo e di moduli necessaria all'applicazione Web per funzionare nella configurazione desiderata?
Facendo in modo che l'applicazione Web venga eseguita nella configurazione più semplice ci si assicura subito che funzioni. Se tutto va bene, è ora di applicare una configurazione simile all'ambiente di produzione esistente e importare i dati di produzione nei database di test. Naturalmente, alcuni problemi potrebbero emergere solo nelle configurazioni avanzate.
È possibile notare possibilità di miglioramento quando si esegue il mirroring della configurazione di produzione in un laboratorio di test. Inserendo il file applicationHost.config in una configurazione UNC si centralizza la configurazione di più server Web. Per aumentare la tolleranza d'errore con la ridondanza e la sincronizzazione del contenuto, è possibile implementare la replica DFS (Distributed File System), che è un motore di replica multimaster basato sullo stato e disponibile con Windows Server 2003 R2 e Windows Server 2008. È possibile anche ridurre al minimo i requisiti di archiviazione dalla parte Web inserendo i file di contenuto delle applicazioni Web nelle condivisioni UNC.
Altre ottimizzazioni potenziali possono riguardare la sicurezza o la cache dinamica. Non ho affrontato le ottimizzazioni della sicurezza e delle prestazioni nel mio laboratorio di test in quanto sarebbero andate oltre l'ambito di questo articolo. Non ho nemmeno configurato DFS per evitare l'installazione di altri server. Le istruzioni dettagliate nel materiale di accompagnamento forniscono un esempio semplificato di come ospitare il file applicationHost.config e il contenuto Web nelle condivisioni UNC. Nella Figura 6 è illustrato come implementare una Web farm basata su UNC con DFS.
Figura 6 Distribuzione di una Web farm con il file applicationHost.config e il contenuto Web nelle condivisioni UNC (fare clic sull'immagine per ingrandirla)

Conclusioni
IIS 7.0 è un'eccezionale piattaforma server Web. Presenta un'architettura principale riprogettata mentre conserva circa il 100% della compatibilità con IIS 6.0. Dovrebbe essere in grado di eseguire la maggior parte delle applicazioni Web ASP.NET esistenti senza modifiche. Ma, data l'entità delle modifiche all'architettura, non è possibile dare per scontato che non si verificheranno problemi di compatibilità.
Sia nel caso della migrazione delle applicazioni Web ASP.NET che di quelle PHP in IIS 7.0, è meglio adottare un approccio graduale prestando particolare attenzione alla pianificazione, alla preparazione, al test e alla documentazione del codice e alle modiche delle configurazione.
IIS 7.0 vale tutto il lavoro che richiede. Esistono molti miglioramenti in aree quali la sicurezza, le prestazioni, la possibilità di configurazione e la flessibilità. Ci vorrebbe un libro intero per parlarne esaurientemente. La configurazione centralizzata e la condivisione del contenuto basato sulle condivisioni UNC, la configurazione delegata per mezzo di file web.config nelle directory delle applicazioni, gli strumenti di gestione migliorati, le informazioni dettagliate di diagnostica e la traccia delle richieste non riuscite e la cache di output dinamico sono metodi infallibili per conquistare gli amministratori Web.
La capacità di combinare moduli nativi e moduli gestiti nella pipeline di elaborazione della richiesta è un vantaggio per gli sviluppatori ASP.NET. I miglioramenti delle prestazioni e della stabilità inclusi in FastCGI in IIS 7.0 sono notizie eccellenti per gli sviluppatori di applicazioni PHP.
C'è un'altra cosa importante che aiuta i professionisti IT a sfruttare IIS 7.0: il portale Microsoft IIS Community Portal (www.iis.net). Vi sono contenute tutte le informazioni necessarie, compresi articoli dettagliati sulla nuova architettura, il codice sorgente per gli sviluppatori C++ e ASP.NET, dimostrazioni di come creare moduli IIS 7.0 e istruzioni dettagliate per attivare ed eseguire le applicazioni PHP. È un sito da non perdere in cui si trovano le risposte alle domande su IIS.

Fergus Strachan è fondatore e direttore di Maestra Ltd London, una società di consulenza specializzata nella progettazione di infrastrutture IT e nel supporto alla gestione dei progetti, che offre i suoi servizi a banche internazionali e istituti scolastici nel Regno Unito. Scrive articoli sulla tecnologia per server Microsoft ed è l'autore di Integrating ISA Server 2006 with Microsoft Exchange 2007. È anche coautore di Microsoft Exchange Server 2003 Resource Kit.

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


Comunicazione e collaborazione
Pianificazione della migrazione alla messaggistica unificata
Jeff Goodwin
Panoramica:
  • Breve storia della segreteria telefonica
  • Fattori da valutare nella pianificazione della migrazione
  • Strategie pratiche per la migrazione
  • Sfide multisito

Indice
Breve storia della segreteria telefonica
Fattori da valutare nella pianificazione della migrazione
Strategie pratiche per la migrazione
Procedura dettagliata per la migrazione
Importanza di attenersi a un piano
La migrazione da un sistema legacy di segreteria telefonica a una piattaforma di messaggistica unificata può costituire un progetto di complessa realizzazione. Tuttavia, un'accorta pianificazione consente non solo di eseguire la migrazione in modo semplice, ma anche di ridurre al minimo i disagi che gli utenti finali potrebbero subire. In effetti, quando si realizza un progetto di migrazione di questo tipo,
la riduzione al minimo dell'interruzione del servizio dovrebbe probabilmente essere l'obiettivo principale.
Per conoscere le operazioni che è necessario pianificare nel corso della migrazione, occorre innanzitutto capire perché le aziende ritengono che la segreteria telefonica sia un'applicazione di importanza fondamentale. Le informazioni di base riportate di seguito aiutano a comprendere quali funzionalità si devono implementare al momento della migrazione a Messaggistica unificata e perché gli amministratori le ritengono importanti.

Breve storia della segreteria telefonica
Poiché non è davvero possibile pianificare il modo di arrivare a destinazione senza sapere da dove inizia il viaggio, vorrei fare un passo indietro e offrire una breve panoramica dei sistemi di segreteria telefonica, illustrando sia la loro origine che il modo in cui sono architettati. L'identità dell'inventore del primo sistema di segreteria telefonica è ancora oggetto di discussione. Tuttavia, il primo sistema di segreteria telefonica sul mercato si chiamava VMX, un acronimo di Voice Message Exchange.
In origine, il VMX era stato progettato per fornire un tipo di comunicazione vocale con le altre persone all'interno dell'azienda, in modo del tutto analogo all'odierna posta elettronica. Il sistema offriva comandi che consentivano di inviare un messaggio, inoltrare un messaggio e rispondere a un messaggio. Quando veniva lasciato un messaggio, l'utente ne veniva avvisato tramite diversi metodi di notifica, tra cui la chiamata esterna (un telefonata alla persona usando un numero di telefono specifico) e la luce dei messaggi in attesa (un indicatore luminoso sul telefono della persona).
Man mano che il VMX aumentava la sua diffusione, le organizzazioni iniziarono a interconnettere in rete i vari sistemi di segreteria telefonica. Questo aveva il vantaggio di offrire una soluzione di segreteria telefonica a livello aziendale, grazie alla quale i dipendenti potevano inviare messaggi broadcast a elenchi di distribuzione che abbracciavano l'intera azienda.
Ovviamente, per fornire un modo di interagire con il sistema di segreteria telefonica, è stato necessario creare un'interfaccia utente telefonica basata sui toni. Nel corso degli anni, le interfacce telefoniche hanno subito modifiche e, purtroppo, non esiste un'interfaccia standard per la segreteria telefonica. Se il telefono cellulare offre una segreteria telefonica, con ogni probabilità sarà attivata da messaggi come "premere 1 per la segreteria telefonica". Ma da quando sono diventati sempre più diffusi i sistemi di segreteria telefonica gestiti con la voce, e che quindi utilizzano un'interfaccia vocale, l'interfaccia telefonica non è più così importante come un tempo. Tuttavia, non si deve sottovalutare l'attaccamento che gli utenti possono provare nei confronti di una determinata interfaccia.
I sistemi aziendali di segreteria telefonica utilizzati oggi si affidano a due architetture distinte: distribuita e centralizzata. Nella Figura 1, gli uffici di Seattle, New York e Austin condividono un'architettura distribuita, in cui i sistemi di segreteria telefonica sono collocati nella stessa posizione presso ognuna di queste sedi. Al contrario, gli uffici di Londra, Parigi e Glasgow hanno un modello centralizzato, in cui l'infrastruttura PBX è stata interconnessa in rete e tutte le chiamate vengono instradate alla sede centrale di Londra. Entrambi i modelli presentano vantaggi e svantaggi. Tuttavia, occorre notare che persino in un modello distribuito, i sistemi di segreteria telefonica possono essere interconnessi in rete per assicurare la consegna dei messaggi tra i vari siti.
Figura 1 Due modelli comuni di architettura di segreteria telefonica (fare clic sull'immagine per ingrandirla)
I motivi che spingono un'organizzazione a scegliere di utilizzare un modello distribuito sono principalmente tre: la necessità della disponibilità locale, l'uso di sistemi PBX diversi che non possono essere interconnessi in rete e le limitazioni dettate da un dial plan uniforme.
Alcune organizzazioni fanno uso del sistema di segreteria telefonica perché, in caso di interruzioni o guasti della rete, il PBX e il sistema di segreteria telefonica locali continuano a funzionare regolarmente, garantendo al sito la completa funzionalità del sistema. I sistemi di risposta vocale interattiva (IVR) continuano a funzionare e i chiamanti esterni possono comunque lasciare messaggi. In pratica, non si verifica nessun impatto sugli utenti finali e il lavoro può continuare normalmente. Lo scenario può risultare familiare, poiché questa è esattamente la ragione per cui molte organizzazioni decidono di localizzare i server che eseguono Microsoft® Exchange Server. L'organizzazione potrebbe voler eseguire una valutazione del rischio per stabilire se questo genere di capacità di sopravvivenza a livello locale sia necessaria.
Quando le dimensioni di un'organizzazione aumentano a seguito delle acquisizioni, spesso i siti remoti hanno piattaforme PBX che non possono essere interconnesse in rete con il resto dell'infrastruttura. In tal caso, le organizzazioni possono decidere di cambiare del tutto il PBX, progetto che potrebbe rivelarsi economicamente impegnativo, oppure lasciare il sito inalterato e interconnettere in rete la piattaforma di segreteria telefonica al fine di garantire uno scambio ininterrotto di messaggistica vocale. Anche i server di terze parti possono dare il loro contributo nell'interconnessione in rete dei diversi sistemi di segreteria telefonica.
Per eseguire l'interconnessione in rete dei PBX, è però necessario un dial plan uniforme (UDP). È infatti l'UDP a stabilire che gli interni telefonici e quelli della segreteria telefonica non possono sovrapporsi. Nella Figura 1, si può notare come Seattle, New York e Austin abbiano intervalli di interni sovrapposti. Questo avviene perché non esiste un UDP per i siti sul territorio statunitense. Si potrebbe creare un UDP ampliando gli intervalli degli interni fino a raggiungere 7 o 10 cifre, ma questo produrrebbe problemi di altro genere.
Si dovrebbero modificare i modelli di composizione di ogni telefono, cambiare tutti gli interni utente nel PBX e modificare tutte le applicazioni integrate nel sistema. Naturalmente, questo produrrebbe insoddisfazione da parte dei dipendenti che sarebbero costretti a ricordare e comporre numeri di 7 o 10 cifre per chiamare un collega dell'ufficio in fondo al corridoio.
Sebbene questi problemi di progettazione e funzionalità di base siano stati gradualmente risolti nel corso degli anni, i principi fondamentali della segreteria telefonica sono rimasti gli stessi. Scambio di messaggi, collegamento in rete, metodi di notifica, interfaccia utente e architettura sono tutti fattori importanti da tenere ben presenti quando si pianifica una migrazione.

Fattori da valutare nella pianificazione della migrazione
La messaggistica unificata produce cambiamenti in ogni settore dell'organizzazione, dal modo in cui gli utenti interagiscono con la segreteria telefonica, al modo in cui viene progettata l'architettura, fino al modo in cui gli amministratori organizzano la gestione. Sono tutte differenze che devono essere prese in considerazione nel momento della migrazione a un sistema di messaggistica unificata. Di seguito è riportato un elenco di controllo che descrive i fattori da valutare quando si pianifica la migrazione.
Rete di messaggi Qualsiasi organizzazione che esegua la transizione da una piattaforma legacy di segreteria telefonica a Messaggistica unificata di Microsoft Exchange deve adattarsi a un periodo di coesistenza. Se l'organizzazione ha già distribuito la rete di messaggi, ovvero un sistema che assicura l'interoperabilità di sistemi di segreteria telefonica diversi, sarà sufficiente aggiungere il sistema di messaggistica unificata all'elenco dei sistemi in uso. Consiglio vivamente l'adozione della rete di messaggi a tutte le organizzazioni con più sedi che utilizzano sistemi PBX o di segreteria telefonica separati.
Infrastruttura La progettazione dell'infrastruttura per Messaggistica unificata richiede l'adozione di decisioni riguardanti i requisiti di collegamento in rete, l'integrazione della telefonia, il posizionamento dei server e altre questioni correlate. A coloro che già non si conoscessero bene le strategie di base per la distribuzione, consiglio la lettura del mio precedente articolo, "Distribuzione della messaggistica unificata con Exchange Server 2007" (disponibile all'indirizzo technet.microsoft.com/magazine/cc137737).
Operatori automatici Molti sistemi offrono più operatori automatici; ad esempio, operatori diversi per il giorno, la notte e i vari reparti. Sarà necessario lavorare con il team di telecomunicazioni dell'organizzazione per creare il mirroring degli operatori automatici dei sistemi legacy di segreteria telefonica.
Indicatore di messaggio in attesa Forse sarebbe auspicabile che la soluzione potesse fare a meno degli indicatori di messaggio in attesa, ma con ogni probabilità gli utenti richiederanno questa funzionalità. Pertanto è bene non sottovalutare l'attaccamento degli utenti verso quella notifica dalla luce rossa. Per fortuna, numerose aziende hanno sviluppato applicazioni per indicatori di messaggio in attesa destinate a Exchange Server.
Supporto fax Molte piattaforme legacy di segreteria telefonica supportano la ricezione dei fax. Messaggistica unificata di Microsoft Exchange supporta anche funzionalità di ricezione dei fax, pertanto potrebbe essere opportuno pianificarne il supporto anche nella nuova distribuzione.
Supporto di IVR Alcune piattaforme legacy di segreteria telefonica supportano applicazioni IVR che Messaggistica unificata di Microsoft Exchange non è in grado di duplicare. Potrebbe essere opportuno mantenere in attività questi sistemi almeno finché non si trova un'alternativa valida.
Amministrazione Messaggistica unificata di Microsoft Exchange si avvale di Active Directory® e del ruolo di server per cassette postali di Exchange. Sarà necessario pianificare il modo in cui l'amministrazione, i requisiti di sistema e altri aspetti simili saranno influenzati dalla distribuzione di Messaggistica unificata.
Interfaccia utente Quando si introduce una nuova interfaccia utente, occorre fornire una formazione adeguata agli utenti. Messaggistica unificata di Microsoft Exchange utilizza un'interfaccia che è molto simile a quella della maggior parte dei provider di telefonia cellulare, pertanto dovrebbe risultare intuitiva per la maggioranza degli utenti. Inoltre, utilizza il riconoscimento vocale così che gli utenti non hanno bisogno di ricorrere alla composizione a toni. In Exchange Server, questa funzionalità si chiama Outlook® Voice Access.
Formazione Il passaggio a Messaggistica unificata comporta un cambiamento di paradigma nel modo in cui gli utenti comunicano tramite la segreteria telefonica e la utilizzano. Oltre a quella richiesta dalla nuova interfaccia utente, per gli utenti è necessaria una formazione che insegni loro le procedure consigliate e illustri i modi nuovi ed efficienti con i quali potranno comunicare. Ad esempio, gli utenti potrebbero non sapere come interagire con la segreteria telefonica nella casella di posta in arrivo oppure come configurare alcune impostazioni avanzate della messaggistica unificata.

Strategie pratiche per la migrazione
Indubbiamente, la migrazione a una soluzione di messaggistica unificata nel contesto di una grande organizzazione presenta sfide anche impegnative. Tuttavia, avendo lavorato per oltre 10 anni nel campo delle comunicazioni unificate, sono testimone del successo nella migrazione anche delle organizzazioni più complesse con requisiti molto specifici.
Sia che l'organizzazione abbia uno o più siti, sarà utile creare la strategia per la migrazione basandola sui cinque passaggi fondamentali seguenti:
  1. pianificare e progettare la soluzione;
  2. installare e configurare il ruolo di server di messaggistica unificata;
  3. eseguire la migrazione di un gruppo pilota;
  4. rivedere il progetto alla luce dei suggerimenti forniti dal gruppo pilota;
  5. eseguire la migrazione degli utenti.
Ovviamente, le organizzazioni multisito si confrontano con alcune sfide che in genere non si pongono negli scenari in cui è presente un unico sito. Di queste sfide mi occupo separatamente più avanti, nell'apposita sezione intitolata "Sfide multisito".
La pianificazione e la progettazione della soluzione è il passaggio più importante dell'intero processo di migrazione. Il mio consiglio è di assegnare il progetto a un apposito team Messaggistica unificata, che dovrebbe essere composto da rappresentanti di vari settori dell'organizzazione dotati della necessaria esperienza in campi quali telecomunicazioni, Active Directory, Microsoft Exchange, collegamenti in rete, sicurezza, formazione e gestione dei progetti. Inoltre, è utile recuperare un disegno dettagliato dell'architettura delle diverse infrastrutture di PBX, segreteria telefonica e posta elettronica esistenti nell'azienda.
Solo dopo che il progetto è a disposizione, si potrà installare e configurare il ruolo di server di messaggistica unificata. Non bisogna temere di installare un server di messaggistica unificata in parallelo al sistema legacy di segreteria telefonica esistente. Occorre soltanto attenersi accuratamente alle procedure consigliate e documentate.
A questo punto, si è pronti per mettere alla prova il server di messaggistica unificata. Individuare un piccolo gruppo di utenti pilota ed eseguirne la migrazione nel nuovo sistema. Sarà sufficiente un gruppo di una consistenza compresa tra 25 e 50 utenti. Sceglierli con cura, creando un gruppo composto da esponenti di vari settori, dal personale IT e telecomunicazioni ai dirigenti di reparto, fino al personale del reparto vendite. Coinvolgendo una gamma di persone così ampia, sarà possibile stabilire al meglio se il progetto ha raggiunto i suoi obiettivi, quali sono i requisiti specifici che occorre prendere in considerazione, che tipo di formazione è necessaria per gli utenti e così via.
Dopo aver ricevuto i commenti e i suggerimenti del gruppo pilota, si dovrà procedere alla revisione del progetto per porre rimedio agli eventuali problemi rilevati durante il periodo di prova. Più in particolare, rivedere i punti che ho analizzato in precedenza nella sezione "Fattori da valutare nella pianificazione della migrazione" e accertarsi di aver affrontato correttamente i diversi punti nell'ambito specifico dell'organizzazione. C'è da notare che molto spesso gli aggiustamenti più comuni riguardano la formazione.
Il passaggio conclusivo consiste nella migrazione degli utenti. Esistono molte opinioni e strategie diverse sui metodi di migrazione del sistema verso la produttività completa. Le due metodologie principali sono la migrazione graduale e il passaggio immediato.
Se si opta per una migrazione graduale della community di utenti nell'arco di settimane o mesi, si vengono a creare "isole" di segreteria telefonica tra gli utenti legacy e quelli di Messaggistica unificata. Questo impedisce agli utenti di inoltrare reciprocamente i messaggi attraverso la segreteria telefonica. E se il progetto non include una soluzione di rete di messaggi, una parte delle comunicazioni aziendali viene alterata. Se si decide in questo senso, consiglio di includere una soluzione di rete di messaggi nel progetto iniziale.
Nel caso di una migrazione con un passaggio immediato, tutti gli utenti vengono spostati con un passaggio unico. In genere, le organizzazioni eseguono questo genere di migrazione nell'arco di un fine settimana. Questo significa che hanno il tempo di testare il sistema, apportare modifiche alla configurazione ed eventualmente annullare la migrazione nel caso in cui si riscontri un blocco determinante.
Qualunque sia il metodo scelto, occorre fornire al personale del supporto tecnico una formazione adeguata sulle domande e le risposte più comuni raccolte grazie al gruppo pilota. Inoltre, occorre fare in modo che il personale del supporto tecnico abbiano dimestichezza nell'esecuzione delle attività principali, incluse l'attivazione di un utente, la convalida dell'attivazione di un utente e la modifica di una password.

Procedura dettagliata per la migrazione
Analizzando l'esempio di migrazione, tenere presente che l'obiettivo principale di una corretta migrazione è di trasferire la casella di segreteria telefonica di un utente da una piattaforma legacy di segreteria telefonica a Messaggistica unificata di Microsoft Exchange con la minore quantità possibile di disagi per gli utenti (sia interni che esterni).
Nella Figura 2 sono illustrati i dettagli dell'architettura di un'organizzazione. Non sono previsti piani per modificare questa architettura mista di Microsoft Exchange. Il centro dati degli uffici sul territorio statunitense si trova a Seattle. Tutte le applicazioni IT di Austin vengono servite da Seattle, mentre l'ufficio di New York garantisce i servizi localizzati di Microsoft Exchange. La segreteria telefonica delle sedi statunitensi è distribuita tramite un'infrastruttura PBX eterogenea. Dal punto di vista tecnico, l'infrastruttura PBX non può essere interconnessa in rete per fornire la centralizzazione della segreteria telefonica. Gli uffici europei, al contrario, dispongono di un centro dati centralizzato che si trova a Londra. In Europa, tutte le applicazioni IT e di telecomunicazione sono servite dal centro dati londinese.
Figura 2 Esempio di architettura prima della migrazione (fare clic sull'immagine per ingrandirla)
L'intera infrastruttura di segreteria telefonica è basata sulla piattaforma Octel (oggi conosciuta come Avaya). Tutti i sistemi di segreteria telefonica sono stati interconnessi in rete utilizzando il protocollo OAN (Octel Analog Networking), ovvero un protocollo di rete di proprietà esclusiva che utilizza le linee telefoniche analogiche e la telefonate interurbane per inviare messaggi di segreteria telefonica in rete. Questa architettura consente il funzionamento della messaggistica vocale a livello aziendale tra i diversi siti.
Sfide multisito
Quando distribuiscono Messaggistica unificata di Microsoft Exchange, le organizzazioni multisito si confrontano con numerose sfide. Per fortuna, è possibile imparare da alcune delle sfide già affrontate da altre organizzazioni. In questo articolo non potrò illustrarle tutte, ma posso descrivere le più comuni tra quelle che ho incontrato nel mio lavoro con varie organizzazioni.
"Ho un'architettura di Exchange Server centralizzata e un ambiente a telefonia mista".
È facile progettare un ambiente distribuito: si installa un server di messaggistica unificata e lo si integra con il PBX locale in ogni sito. Ma che succede in presenza di un ambiente centralizzato o persino misto? La domanda da porre è se nel sito è richiesta una capacità di sopravvivenza della messaggistica unificata a livello locale. In caso di risposta affermativa, il sito può perdere la connessione al server Exchange centralizzato e fornire comunque funzionalità di operatore automatico, nonché consentire ai chiamanti esterni (con ogni probabilità clienti) di lasciare messaggi. Probabilmente la risposta dipenderà dal livello di importanza strategica del sito specifico e dal grado di gestibilità della soluzione.
Se per il sito è richiesta una capacità di sopravvivenza, allora un server di messaggistica unificata remoto potrebbe rappresentare una scelta azzeccata; se, al contrario, non è un requisito, nel sito locale può essere installato un gateway SIP. Messaggistica unificata di Microsoft Exchange è talmente flessibile da non richiedere né l'interconnessione in rete dell'infrastruttura PBX, né un dial plan uniforme.
"Sono in procinto di aggiornare la mia architettura di architettura mista di Microsoft Exchange".
Molti clienti esitano prima di iniziare la migrazione a Messaggistica unificata mentre stanno per aggiornare la loro infrastruttura di Microsoft Exchange. Se la decisione di passare a Messaggistica unificata è già stata presa, il mio consiglio è di continuare con la migrazione anche mentre viene aggiornato il server Exchange. Basta seguire i piani di aggiornamento e al progetto non dovrebbero andare ad aggiungersi complessità sostanziali.
"Ho molti siti di piccole dimensioni con meno di 10 persone e alcuni di essi non dispongono di un PBX".
Nei siti più piccoli con un PBX residente localmente, tutto quello che bisogna fare è installare un gateway SIP nel sito locale. Per i siti privi di PBX in sede, esistono tecnologie di telefonia utilizzabili per inoltrare i numeri telefonici al PBX centrale per instradare le chiamate al sistema di messaggistica unificata. In breve, è possibile distribuire i servizi di Messaggistica unificata ai siti remoti dell'organizzazione a costi veramente ridotti.
È importante notare che i siti più piccoli costituiscono effettivamente un ottimo banco di prova per la migrazione. Una strategia di migrazione molto diffusa è di iniziare alla periferia della rete per spostarsi gradualmente verso il centro. All'inizio si esegue la migrazione dei siti più piccoli, quindi si esegue una valutazione a posteriori insieme al team Messaggistica unificata con l'obiettivo di stabilire cosa ha funzionato e quali problemi sono stati riscontrati. In seguito, si potranno applicare le lezioni imparate alla migrazione del sito successivo.
Il team Messaggistica unificata ha deciso di eseguire la migrazione dalla periferia della rete al centro. Per tutti i siti, il posizionamento del server di messaggistica unificata dovrà attenersi alla procedura consigliata di seguire l'architettura del server Exchange. Il team crea per ogni sito la documentazione della pianificazione, tenendo ben presenti i punti analizzati in precedenza nella sezione "Fattori da valutare nella pianificazione della migrazione". La documentazione verrà utilizzata nel corso dell'installazione e della configurazione dei server, durante la formazione degli utenti e nella pianificazione delle strategie per la migrazione.
Per ogni sito, il team dovrà pianificare il passaggio immediato degli utenti al sistema di messaggistica unificata, lasciando in attività la piattaforma legacy per supportare le applicazioni IVR che continueranno a essere utilizzate finché non si riuscirà a trovare una soluzione alternativa. Il team ha deciso di aspettare 30 giorni dopo la migrazione prima di occuparsi del sito successivo. Il periodo di attesa serve per accertarsi che l'adattamento di ogni sito sia riuscito, prima del passaggio di altri utenti e dell'aggiunta di più chiamate al supporto tecnico.
L'organizzazione stabilisce di eseguire per prima cosa la migrazione del sito di Austin. Dal momento che la posta elettronica di Austin viene servita da Seattle, il team installa a Seattle il ruolo di server di messaggistica unificata e fornisce un'integrazione PBX installando ad Austin un gateway SIP. Poiché la piattaforma legacy di segreteria telefonica è interconnessa in rete, il team deve soddisfare l'esigenza di connessione in rete della piattaforma di messaggistica unificata installando un server di rete di messaggi. Sia la formazione degli utenti sul nuovo sistema che la migrazione riescono senza problemi, perciò il team decide di eseguire la migrazione del sito di New York.
Il sito di New York dispone dei propri server cassette postali e di Trasporto Hub. Le procedure consigliate, perciò, stabiliscono che nel sito di New York dovrebbe essere installato un server di messaggistica unificata. Il team installa il server, consultando i documenti della pianificazione. Il server viene aggiunto all'elenco dei nodi nel server di rete di messaggi affinché venga incluso nella rete di segreteria telefonica. Si impartisce la formazione agli utenti, la cui migrazione a Messaggistica unificata avviene senza problemi.
Il sito di Seattle già dispone di un server di messaggistica unificata distribuito durante la fase di migrazione del sito di Austin. Il team stabilisce che il server contiene già un numero di porte di segreteria telefonica sufficiente per supportare i siti di Seattle e di Austin. Si impartisce la formazione agli utenti di Seattle, la cui migrazione a Messaggistica unificata avviene senza problemi.
L'architettura in Europa è molto più facile da progettare. L'infrastruttura PBX è interconnessa in rete e Microsoft Exchange è centralizzato. Un server di messaggistica unificata viene distribuito a Londra e si esegue la migrazione di ogni sito, iniziando dal più piccolo. La Figura 3 illustra l'architettura finale.
Figura 3 Esempio di architettura dopo la migrazione (fare clic sull'immagine per ingrandirla)

Importanza di attenersi a un piano
Mi è stato chiesto di risolvere molte migrazioni a Messaggistica unificata non riuscite. Molte delle organizzazioni coinvolte non avevano rispettato una o più regole fondamentali.
Per prima cosa, occorre ricordare sempre che non si tratta "soltanto" di un sistema di segreteria telefonica. È un'applicazione di importanza cruciale e dovrebbe essere trattata come tale. Gli utenti si affidano anche a questo tipo di tecnologie per scambiarsi le informazioni. Tenere presente che è un'applicazione aziendale e quindi bisogna pianificare la migrazione prendendo in considerazione tutti i fattori che ho analizzato in questo articolo.
In una migrazione a Messaggistica unificata deve assolutamente essere coinvolto il team di telecomunicazioni. È il team che dispone delle conoscenze più approfondite delle applicazioni di telefonia integrate nell'infrastruttura aziendale.
Quando si esegue la migrazione a Messaggistica unificata, è bene mettere a punto la pianificazione della soluzione a livello aziendale. Sebbene all'inizio l'implementazione possa riguardare un solo sito, non bisogna mai perdere di vista il quadro d'insieme. Ad esempio, l'implementazione di un solo sito senza la fornitura della rete di messaggi agli altri siti ha un profondo impatto sulle comunicazioni tra gli utenti. Ovviamente, questo può rappresentare un'attività notevole, perciò non si deve esitare a chiedere la consulenza di uno specialista per progettare un'architettura che tenga conto di tutte le applicazioni IT.
Infine, non sottovalutare mai l'importanza della formazione. Il passaggio a Messaggistica unificata comporta un cambiamento di paradigma nel modo in cui gli utenti comunicano e interagiscono con la segreteria telefonica. Ciò che per alcuni può sembrare intuitivo, per altri potrebbe non esserlo affatto. Una buona formazione è lo strumento migliore per assicurarsi una transizione senza problemi.

Jeff Goodwin è Senior Technologist presso The VIA Group, specializzato in progettazione e distribuzione di soluzioni Exchange e di messaggistica unificata. È possibile contattarlo all'indirizzo jgoodwin@theviagroup.com.


Comunicazione e collaborazione
L'importanza della voce in OCS 2007
Rajesh Ramanathan
Panoramica:
  • Esecuzione di chiamate in OCS 2007
  • Protezione delle chiamate
  • Conversazioni multimodali in OCS
  • Integrazione con Exchange UM per la segreteria telefonica

Indice
Chiamate vocali di base
Utilizzo dei numeri di telefono
Chiamate sicure
Attraversamento di NAT e firewall
Routing sui numeri di telefono
Routing in entrata
Report sulla qualità e risoluzione dei problemi
Combinazione di tutti gli elementi
Comportamento multimodale e conversazioni
Segreteria telefonica
Conclusioni
La prima parte in questa serie su Microsoft OCS (Office Communication Server) 2007 ha illustrato in che modo OCS è stato creato sui punti di forza di LCS (Live Communication Server) 2005 per offrire
capacità ottimizzate di presenza e messaggistica istantanea (MI) a livello aziendale, oltre che funzionalità avanzate per supporti e telefonica (vedere l'articolo di TechNet Magazine di febbraio 2008 in technet.microsoft.com/magazine/cc194409). In questo articolo si continua ad esaminare, con maggiore attenzione, l'aspetto VoIP (Voice over IP) della storia. Spiegherò come vengono effettuate semplici chiamate vocali nel sistema OCS e analizzerò la tecnologia, livello per livello, aggiungendo ogni componente con la corrispondente funzionalità.
Come riportato nell'articolo precedente, OCS può essere configurato per fornire la telefonia agli utenti in molte configurazioni differenti:
Enterprise Voice È una soluzione completa delle comunicazioni unificate, che utilizza OCS insieme al server Microsoft® Mediation senza richiedere PBX. Messaggistica unificata di Exchange (UM) fornisce funzioni di segreteria telefonica in questo sistema. Nella parte restante di questo articolo, farò riferimento agli utenti che dispongono di questo servizio come "utenti UC". Utilizzerò anche la definizione "endpoint UC" per fare riferimento ad un client in questa configurazione.
Enterprise Voice con integrazione PBX Questa configurazione consente agli utenti di conseguire i vantaggi delle comunicazioni unificate mantenendo i telefoni PBX esistenti sui propri desktop. Consente la configurazione di OCS e PBX in parallelo in modo che le chiamate in entrata possano giungere contemporaneamente a Office Communicator e PBX. PBX possiede, tuttavia, il routing di chiamata e fornisce i servizi di segreteria telefonica.
Controllo delle chiamate remote Questa funzione utilizza il telefono PBX come telefono primario e consente di controllare il telefono tramite il client Office Communicator.

Chiamate vocali di base
In questa sezione, porrò l'attenzione sulle attività degli utenti di Enterprise Voice. Le chiamate vocali semplici vengono configurate nel sistema OCS utilizzando il meccanismo SIP INVITE, come descritto nella RFC 3261. Il server OCS agisce come un proxy simile a un postmaster che inoltra i messaggi tra i client (o gli endpoint). Nuovi SIP INVITE vengono generati dai client ogni volta che viene creata una sessione in tempo reale, ad esempio una sessione di chiamata o di messaggistica istantanea. Se l'invito viene riconosciuto con una risposta (ovvero, se l'endpoint remoto invia una risposta 200 OK), la chiamata viene stabilita (vedere la Figura 1).
Figura 1 Formato INVITE e 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
Nella Figura 2, Alice chiama Roberto selezionando Chiamata Communicator da Comunicatore da OC (Office Communicator) 2007 e OC 2007 genera un invito (INVITE) all'URI (Uniform Resource Identifier) SIP di Roberto (sip:bob@example.com). L'invito (INVITE) genera a sua volta il descrittore della sessione audio (denominato SDP, ovvero Session Description Protocol) degli endpoint di supporti in cui Alice può ricevere l'audio. OCS devia l'invito (INVITE) agli endpoint SIP registrati di Roberto (ad esempio, Communicator Phone Edition e il desktop Communicator). L'invito contiene un'intestazione Mittente sip:alice@example.com che viene utilizzata dagli endpoint client di Roberto in una Ricerca inversa di nomi (RNL) per individuare il nome (Alice) da mostrare nella notifica di chiamata in entrata.
Figura 2 Routing di una chiamata a più endpoint (fare clic sull'immagine per ingrandirla)
Per ogni endpoint, viene mostrato il GRUU (Globally Routable User Agent URI). Il GRUU identifica in modo univoco un endpoint SIP e il server OCS lo ottiene durante il processo di registrazione. L'indirizzo GRUU fornisce supporto nel routing dei messaggi SIP, in modo che quando un endpoint risponde alla chiamata, è possibile effettuare una segnalazione SIP successiva per altre operazioni di interne alla chiamata tra gli endpoint utilizzando direttamente l'indirizzo GRUU.
Nella Figura 3 si continua il processo, in cui Roberto risponde dal desktop di Communicator. L'OC di Roberto invia un messaggio 200 OK in cui comunica dove può ricevere l'audio. Non appena il proxy OCS rileva che un endpoint ha risposto, annulla la chiamata agli altri endpoint di Communicator Phone Edition. Non appena la risposta 200 OK raggiunge l'endpoint Communicator di Alice, entrambi gli endpoint di Communicator dispongono di informazioni sufficienti (porte IP, parametri di crittografia e così via) per avviare i supporti.
Figura 3 Risposta da un endpoint (fare clic sull'immagine per ingrandirla)

Utilizzo dei numeri di telefono
Fino ad ora abbiamo esaminato uno scenario in cui l'utente fa clic su Chiamata Communicator per creare l'invito. Il processo è lievemente diverso quando l'utente seleziona o immette un numero di telefono:
  • Il client normalizza prima il numero di telefono e lo rappresenta come un URI TEL, che descrive risorse identificate dai numeri di telefono come indicato nella RFC 3966.
  • Poiché il server OCS riconosce soltanto URI SIP, i client convertono l'URI TEL in un URI SIP corrispondente aggiungendo il suffisso di dominio e una tag user=phone.
  • Se il numero corrisponde ad un utente interno, OCS instrada direttamente l'invito. Se il numero è esterno, l'invito viene instradato al gateway SIP-PSTN più vicino.
Alcune chiamate a un numero PSTN (Public Switched Telephone Network) richiedono che il percorso dei supporti venga configurato prima di rispondere alla chiamata per consentire la riproduzione degli annunci remoti o l'acquisizione di cifre aggiuntive per completare la chiamata. In tali scenari, il gateway PSTN invia un indicatore 183 di avanzamento sessione con un SDP audio. Communicator utilizza queste informazioni per configurare un percorso di supporti bidirezionale con un endpoint di destinazione prima che l'utente remoto risponda alla chiamata.
Una volta configurato il percorso dei supporti, Communicator abilita il tastierino DTMF o Dual-Tone Multi-Frequency (i toni di segnalazione del telefono) per consentire all'utente di inserire eventuali cifre aggiuntive richieste dal sistema remoto. Qualunque cifra DTMF inserita viene inviata al percorso dei supporti come pacchetto RFC 2833. Il gateway PSTN si occupa di generare i segnali di tono DTMF appropriati sul lato PSTN.
Tenere presente che, se Roberto ha abilitato lo squillo simultaneo sul suo telefono cellulare, il proxy OCS instraderà la chiamata al gateway e chiamerà contemporaneamente altri endpoint Communicator di Roberto. In tali scenari, il proxy OCS indica che la deviazione è attiva nella risposta 183 di avanzamento sessione e, di conseguenza, Communicator stabilisce un canale di supporti di sola ricezione con il gateway PSTN.

Chiamate sicure
Una delle funzioni principali delle chiamate vocali configurate da OC è crittografata per impostazione predefinita utilizzando SRTP (Secure Real-Time Transport Protocol), come definito nella RFC 3711. SRTP fornisce riservatezza, autenticazione dei messaggi e protezione delle risposte al traffico RTP. Durante la configurazione delle chiamate, i client negoziano le capacità di sicurezza tra di loro e scambiano chiavi crittografiche come parte del meccanismo INVITE.
L'impostazione di crittografia predefinita per OC è "facoltativa" e consente la configurazione di un canale di supporti crittografato da parte di due endpoint OC. Tale impostazione può essere modificata dall'amministratore per soddisfare le esigenze di conformità dell'organizzazione. Ad esempio, è possibile renderla più rigida per applicare la crittografia su tutte le chiamate o disattivarla completamente.

Attraversamento di NAT e firewall
I client nel sistema OCS utilizzano la tecnologia ICE (Interactive Connectivity Establishment) per fornire connettività dei supporti agli utenti protetti da firewall e dispositivi NAT (Network Address Translation), senza richiedere alcuna modifica ai componenti di NAT esistenti. La tecnologia ICE è attualmente standardizzata da IETF (Internet Engineering Task Force). Ogni client rileva l'A/V (audio/video) Edge Server che soddisfa le sue richieste tramite un meccanismo di provisioning in banda e mantiene un collegamento autenticato ad A/V Edge durante il sign-on.
Prima di effettuare una chiamata, il client assegna le risorse sui possibili percorsi di connettività (gli indirizzi e le porte, noti anche come candidati) sull'A/V Edge Server (per l'inoltro dei supporti), su NAT o sul client host stesso. Quando viene inviato SIP (Session Initiation Protocol ) INVITE, trasmette queste informazioni di connettività come parte dell'invito. La risposta 200 OK contiene informazioni simili sui candidati relative al peer. Quando ogni endpoint contiene un elenco di candidati peer, un elaborato meccanismo di classificazione e controllo seleziona il percorso ottimale tra i due peer in cui il supporto non presenterà problemi.

Routing sui numeri di telefono
Il routing sui numeri di telefono introduce alcune complessità nel meccanismo di chiamata di base, a causa dei seguenti fattori:
  • Le organizzazioni potrebbero avere piani di composizione distribuiti internamente per la composizione rapida.
  • I numeri potrebbero essere memorizzati in formati non standard (ad esempio, gli utenti potrebbero aver salvato stringhe a sette cifre in Microsoft Office Outlook®).
  • Potrebbero esistere criteri diversi associati ai differenti numeri in uscita. Ad esempio, è possibile che le chiamate internazionali siano bloccate per alcuni utenti.
Il sistema OCS richiede che i numeri di telefono abbiano il formato URI TEL della RFC 3966 per poter instradare tali numeri correttamente. I numeri che non presentano tale formato vengono convertiti prima che il client emetta un invito (INVITE). Nel diagramma della Figura 4 viene illustrata tale conversione all'interno del sistema OCS.
Figura 4 Routing di numeri di telefono (fare clic sull'immagine per ingrandirla)
I numeri disponibili sul client possono provenire da diverse fonti. I numeri pre-normalizzati provengono dal Servizio Rubrica, che può presentare regole di normalizzazione definite dall'amministratore per la conversione dei numeri in un formato E. 164 normalizzato. Quando il client emette un SIP INVITE al numero normalizzato, OCS applica un processo di conversione per associare il numero ad un utente interno.
  • Nel passaggio 1 viene illustrato che i numeri inseriti nel sistema sono univoci (normalizzati, seguendo il piano di numerazione E. 164) o con un contesto telefonico che identifica la posizione. Tali numeri vengono inviati al server all'interno del meccanismo SIP INVITE. OCS instrada l'invito ad un processo di conversione.
  • Il processo di conversione (Passaggio 2) tenta di associare il numero di telefono ad un endpoint UC tramite RNL dal lato server. La conversione può identificare un percorso per tale numero in un routing in uscita o per un utente UC o può impedire la chiamata con un codice 4xx se il numero non può essere convertito correttamente.
  • Se il numero viene convertito in un numero esterno o non UC, viene inviato al componente di routing in uscita che reindirizza l'invito (INVITE) al gateway SIP-PSTN appropriato per una ulteriore elaborazione, dopo avere applicato dei criteri per il numero correlato al chiamante (Passaggio 3A). Il routing in uscita si occupa di bilanciare il carico di chiamata tra i gateway o eseguendo il failover su gateway alternativi, se necessario. Il processo di routing in uscita può impedire o rifiutare la chiamata e restituire un codice di risposta SIP 403 se l'accesso viene vietato per un determinato numero. Tenere presente che il routing in uscita applica soltanto quando il chiamante è un utente UC. Negli altri casi, OCS tenta di utilizzare percorsi statici ai gateway configurati per tale URI.
  • Se il numero viene convertito in un numero dell'utente UC, l'invito (INVITE) viene instradato all'URI SIP di tale utente (Passaggio 3B). Il routing in entrata è una funzione di OCS che si applica soltanto agli utenti UC e a tutte le chiamate destinate all'URI SIP. Come mostrerò più avanti, il routing in entrata applica delle regole per i timeout di suoneria, l'inoltro di chiamate e l'inoltro della segreteria telefonica per l'utente UC.
Tenere presente che il numero derivante dal processo di normalizzazione può variare in base alla posizione del client. Gli amministratori possono configurare i profili località e assegnare regole di conversione numerica ad una determinata posizione per consentire, ad esempio, di comporre un numero a quattro cifre per tale posizione. Ad ogni utente UC è assegnato un profilo località e tutti i client nel sistema scaricano le regole specifiche per i relativi profili località utilizzando il provisioning in banda. Nella sezione successiva, esaminerò i dettagli del routing in entrata.

Routing in entrata
Le regole del routing in entrata specificano in che modo è necessario instradare le chiamate ad un utente in presenza o assenza di client registrati nel sistema. Il componente del routing in entrata si occupa anche di applicare regole basate sulla presenza alla chiamata in entrata; ad esempio, può inviare delle chiamate in entrata alla segreteria telefonica se l'utente ha impostato lo stato di presenza su Non disturbare. Il routing in entrata rileva i livelli del contenitore di presenze e respinge automaticamente le chiamate provenienti da utenti presenti in contenitori bloccati. Nella Figura 5 viene mostrato un riepilogo di opzioni supportate dal componente di routing in entrata OCS.
Figura 5 Capacità di routing in entrata
Capacità | Commento
Durata squillo | Il valore predefinito è 20 secondi. L'utente può modificare tale valore sul valore massimo di 60 secondi. Le chiamate vengono deviate alla destinazione di chiamate senza risposta dopo questa durata di timeout.
Instradamento delle chiamate senza risposta alla segreteria telefonica | Impostazione predefinita se l'utente è abilitato per la segreteria telefonica. La chiamata viene instradata in base alle regole di routing in entrata.
Generazione di notifiche di chiamate perse quando il chiamante riaggancia il telefono e prima che la chiamata raggiunga la segreteria telefonica | Notifica tali chiamate perse ad Exchange UM.
Blocco chiamate | Respinge le chiamate provenienti da chiamanti bloccati (è possibile bloccare soltanto le chiamate provenienti da utenti con identità SIP).
Non disturbare | Instrada le chiamate alla segreteria telefonica. Le destinazioni di squillo simultanee non sono attive se l'utente si trova in questa modalità.
Elenco delle interruzioni consentite | Consente le chiamate se il chiamante si trova nel contenitore Team, anche se l'utente è impostato su Non disturbare.
Squillo simultaneo | Configura le chiamate in entrata in modo che chiamino un numero di telefono PSTN oltre che Communicator e i client Communicator Phone Edition.
Inoltro delle chiamate immediato | Inoltra immediatamente una chiamata in entrata ad un altro utente, numero di telefono PSTN o alla segreteria telefonica.
Inoltro delle chiamate senza risposta | Inoltra una chiamata senza risposta ad un altro utente, numero di telefono PSTN o alla segreteria telefonica.
Ore lavorative | Utilizza le ore lavorative configurate nel Calendario di Outlook per attivare le impostazioni di inoltro delle chiamate per un utente.
Le regole di routing in entrata vengono caricate sul server come schema XML come parte delle informazioni di provisioning automatico di un utente. Nella Figura 6 viene illustrato il funzionamento del routing in entrata. Una chiamata in entrata per un utente nel sistema OCS chiama l'utente per impostazione predefinita (mostrato come "Me"). Se non si risponde alla chiamata entro la durata dello squillo, la chiamata senza risposta viene inviata alla segreteria telefonica per impostazione predefinita. L'utente può scegliere di modificare la configurazione predefinita selezionando l'inoltro immediato ad un numero, ad un'altra persona o direttamente alla segreteria telefonica.
Figura 6 Routing di chiamate (durante le ore lavorative) (fare clic sull'immagine per ingrandirla)
Qualunque chiamata immediatamente inoltrata ad un'altra persona o numero applicherà le regole di routing in entrata per tale persona o numero. L'utente può impostare anche un inoltro delle chiamate senza risposta ad un altro numero o persona.
Se l'utente seleziona l'opzione Applica soltanto durante le ore lavorative di Outlook nelle regole di inoltro, le regole illustrate nella Figura 6 vengono applicate durante le ore lavorative e il comportamento predefinito delle chiamate agli endpoint registrati viene applicato al di fuori di tali ore. Tenere presente che questo comportamento richiede che l'organizzazione abbia distribuito i client Microsoft Exchange Server 2007 ed Outlook 2007 perché Communicator utilizza le informazioni sulle ore lavorative provenienti dal servizio Web Exchange 2007 Availability e il supporto di rilevamento automatico di Outlook 2007 per ottenere la posizione del server.

Report sulla qualità e risoluzione dei problemi
Sebbene i client del sistema OCS 2007 utilizzino RTAudio, un codec audio di nuova generazione in grado di tollerare condizioni di rete imperfette come i tremolii, la perdita di pacchetti e così via, il monitoraggio è comunque essenziale per consentire agli amministratori di individuare e riparare le potenziali aree sensibili. I client nel sistema OCS 2007 riportano la qualità di ogni chiamata e forniscono statistiche dettagliate che includono la larghezza di banda, la latenza, i tremolii, il MOS o mean opinion score (una misura della percezione dell'utente), le periferiche utilizzate e molto altro in un server QoE (Quality of Experience) centrale alla fine di ogni chiamata. Tale risultato si ottiene inviando il payload in una richiesta SIP SERVICE al server QoE, il cui indirizzo è programmato utilizzando un meccanismo di provisioning in banda.
Tenere presente che tutti gli endpoint client riportano la qualità delle chiamate al server QoE in modo indipendente. Nel caso in cui una chiamata dovesse fallire a causa di un errore nella segnalazione, i client riportano tali dati anche ad OCS, che fornisce un repository di tutti gli errori creati dai client.﻿

Combinazione di tutti gli elementi
Dopo avere esaminato diversi aspetti della configurazione di una chiamata, incluso l'inserimento dei numeri, il routing in entrata e in uscita e i controlli di connettività, diamo un'occhiata al processo nella sua totalità. Nella Figura 7 viene riassunto l'intero processo dal momento in cui un utente effettua una chiamata. I client nel sistema OCS hanno un ruolo essenziale nella configurazione di una chiamata e gestiscono l'intero processo di configurazione della chiamata. OCS è coinvolto nel routing iniziale della chiamata, e i server edge aiutano i client a rilevare il percorso dei supporti ottimale. Diamo ora uno sguardo a ciò che succede dopo: la conversazione.
Figura 7 Flusso di chiamate end-to-end (fare clic sull'immagine per ingrandirla)

Comportamento multimodale e conversazioni
Il concetto di conversazioni è fondamentale nel sistema OCS. Una conversazione è una sessione multimodale tra due o più persone e può includere contemporaneamente voce, video e MI, oltre che elementi quali trasferimenti file durante la sessione, messaggi di posta elettronica in Outlook o note memorizzate in Microsoft Office OneNote®.
Diversi aspetti delle conversazioni possono influire sulla progettazione dei sistemi client OCS:
  • Tutte le modalità coinvolte in una conversazione utilizzano la stessa finestra. Se un messaggio immediato viene aggiunto ad una conversazione audio, viene associato alla stessa finestra.
  • Le conversazioni possono avvenire tra dispositivi. Gli utenti possono scegliere di avere l'audio sulla Communicator Phone Edition e la MI sul desktop di Communicator.
  • Tutte le modalità eseguono contemporaneamente l'escalation ad una conferenza: Se si verifica una escalation, tutte le modalità di una conversazione devono essere sottoposte contemporaneamente ad escalation, indipendentemente dal dispositivo su cui è attiva la modalità. Ad esempio, se è disponibile una modalità audio su Communicator Phone Edition ed una modalità MI per la stessa conversazione è disponibile sul desktop di Communicator l'escalation alla conferenza garantisce che sia l'audio che la MI dispongano della stessa serie di partecipanti per tale conversazione.
  • Le conversazioni e non le singole sessioni vengono registrate. I registri di chiamate contengono informazioni complete sulla conversazione, inclusi dettagli sulle note prese durante la conversazione, gli scambi di messaggi istantanei, la durata dell'audio durato e così via. Ciò fornisce una visione chiara e consolidata dell'intera conversazione agli utenti quando aprono il registro di chiamate in Outlook.
  • Le conversazioni possono continuare dai registri di conversazioni. I client OCS legano le conversazioni tra di loro utilizzando un ID conversazione (ossia un numero che identifica in modo univoco la conversazione su dispositivi e applicazioni. Esiste un meccanismo elaborato per calcolare i delta delle conversazioni vengono avviate nuove conversazioni da un registro cronologico di una precedente conversazione. Lo stesso ID conversazione viene memorizzato anche come ID messaggio di posta elettronica in Outlook.
L'ID conversazione viene trasmesso all'interno del SIP INVITE come proprietà personalizzata, ovvero Ms-Conversation-Id. Nella Figura 8 viene mostrata tale transazione in cui viene prima aggiunta la voce e poi la MI. Alla fine della conversazione multimodale, il registro cronologico memorizzato in Outlook ha lo stesso ID conversazione.
Figura 8 Conversazioni multimodali e ID conversazione (fare clic sull'immagine per ingrandirla)

Exchange UM è il sistema di segreteria telefonica per OCS 2007. OCS instraderà soltanto le chiamate per utenti che supportano UC per Exchange UM. OCS fornisce diverse funzioni per l'integrazione con Exchange UM:
  • L'opzione Chiama segreteria telefonica della UI del telefono di Communicator (vedere la Figura 9) consente all'utente di gestire la casella di posta UM, modificare i saluti e altro senza dover inserire il PIN perché è già autenticato.
  • L'indicatore di attesa messaggio nella UI di Communicator (vedere la Figura 10) consente all'utente aprire la cartella della segreteria telefonica in Outlook mentre la UI in Communicator Phone Edition consente all'utente di riprodurre i messaggi vocali direttamente dal telefono.
  • Le chiamate possono essere inoltrate alla segreteria telefonica dalla UI di Communicator.
  • Le chiamate rifiutate vengono instradate automaticamente alla segreteria telefonica.
  • L'opzione Ascolta al telefono della segreteria telefonica in Outlook chiama direttamente i client di Office Communicator.
Figura 9 Opzione Chiama segreteria telefonica in Communicator
Figura 10 Indicatore di attesa messaggio in Communicator
Il meccanismo con cui OC riceve la notifica della segreteria telefonica è diverso da quello di Communicator Phone Edition. OC registra le nuove notifiche di posta nella cartella di ricerca della segreteria telefonica in Outlook e riporta i nuovi messaggi in questa cartella. Communicator utilizza anche Conversazioni non effettuate e Registri chiamate.

Conclusioni
In questa sezione ho illustrato il funzionamento delle chiamate vocali in OCS 2007, un sistema creato su SIP che utilizza diverse RFC. Gli endpoint client hanno un ruolo centrale nella gestione delle chiamate in OCS. Tutte le chiamate vocali sono crittografate in modo sicuro per impostazione predefinita. OCS fornisce dei componenti flessibili per consentire la gestione dei numeri e del relativo flusso in tutto il sistema.
Le conversazioni sono un concetto fondamentale in OCS, poiché coinvolgono voce, MI e video. OCS si integra con Exchange UM e consente di inviare notifiche relative alla segreteria telefonica agli endpoint di Communicator e di accedere a tale segreteria da Outlook o direttamente dal server.

Rajesh Ramanathan lavora nelle comunicazioni da 14 anni e ha progettato protocolli vocali, procedure per l'utente e strumenti per voce e conferenze per Office Communicator 2007. È possibile contattarlo all'indirizzo rajeshra@microsoft.com.


Comunicazioni e Collaborazione
creazione di connessioni potenti con Groove e SharePoint
Alan Maddison
Panoramica:
  • Creazione di una libreria di documenti SharePoint
  • Creazione di un'area di lavoro Groove
  • Sincronizzazione di Groove e SharePoint
  • Come consentire l'accesso all'area di lavoro

Indice
Combinazione di Groove e SharePoint
Introduzione
Configurazione del controllo approvazioni
Creazione dell'area di lavoro Groove
Sincronizzazione di Groove e SharePoint
Come consentire l'accesso all'area di lavoro
Conclusioni
I professionisti dell'IT si meravigliano spesso della somiglianza apparente tra Microsoft Office Groove 2007 (Groove) e Microsoft Office Sharepoint Server 2007 (Sharepoint) e non sempre riescono a capire quale dei due
sia più adeguato nelle varie circostanze. A prima vista, i due prodotti sembrano molto simili, poiché entrambi forniscono funzionalità di collaborazione. Tuttavia, una volta esaminata con maggiore attenzione l'architettura, si iniziano a notare le differenze.
Sharepoint® offre una serie di strumenti di collaborazione ed un framework di gestione del contenuto robusto e scalabile con il supporto per flussi di lavoro strutturati. Groove™, invece, è una serie di strumenti di collaborazione che consente la rapida distribuzione delle aree di lavoro rapida con un overhead minimo o assente dell'IT. Con funzioni quali il supporto per la collaborazione dei documenti, le discussioni dei thread e il calendaring, Groove fornisce il framework ideale per una collaborazione dinamica, sicura e ad hoc. In sintesi, la maggior parte degli utenti finirà per utilizzare questi prodotti in modi diversi.
Inoltre, la versione di Groove 2007 aggiunge un supporto incorporato per l'integrazione di Sharepoint utilizzando lo strumento File di Sharepoint. Tale strumento consente la sincronizzazione delle aree di lavoro di Groove con le raccolte di documenti di Sharepoint e, come vedremo, l'integrazione incorporata consente di trarre i massimi vantaggi da entrambi prodotti. In effetti, combinando la flessibilità e la natura dinamica di Groove con la sofisticazione e la potenza di Sharepoint, sarà possibile offrire vantaggi significativi a molti utenti.
Combinazione di Groove e SharePoint
L'universo dell'IT attuale richiede una collaborazione in costante aumento tra le organizzazioni e i relativi partner e fornitori. Tuttavia, le potenti soluzioni di collaborazione implementate tramite prodotti come Sharepoint tendono a porre l'attenzione sui team interni e sulla necessità di rendere le informazioni largamente disponibili in ogni area dell'organizzazione. In tali casi, da una prospettiva di gestione e di sicurezza, le sfide per fornire accesso ad utenti esterni a un'organizzazione sono spesso significative. Di fronte a tali sfide, l'obiettivo consiste nel consentire agli utenti di raggiungere i partner esterni ad hoc, in base alle esigenze.
La combinazione di Groove e Sharepoint offre esattamente tale soluzione. Sharepoint fornisce una collaborazione interna all'organizzazione, una ricerca del contenuto ed un framework dei flussi di lavoro; l'aggiunta di Groove consente alle aziende di estendere tali funzionalità per includere una collaborazione semplice interna all'organizzazione. Con Groove, gli utenti possono configurare rapidamente aree di lavoro di collaborazione che vadano oltre i confini dell'azienda. Inoltre, il supporto per chiavi simmetriche Advanced Encryption Standard (AES) a 192 bit garantisce una collaborazione sicura. Infatti, la sicurezza di Groove è incorporata e sempre attiva, per evitare che gli utenti debbano preoccuparsi di configurarla.
L'architettura di sicurezza di Groove fornisce un elevato grado di protezione per queste aree di lavoro e per il relativo contenuto, poiché entrambi gli elementi vengono memorizzati in locale e durante la trasmissione di rete. Lo strumento File di SharePoint consente la sincronizzazione bidirezionale di tali informazioni con una libreria di documenti di SharePoint per garantire che le informazioni siano disponibili centralmente per un accesso interno semplice. Utilizziamo un esempio concreto per capire come funziona questo processo.
Introduzione
Le organizzazioni collaborano spesso con diverse aziende durante le attività commerciali quotidiane. In questo scenario sono coinvolte in genere non solo organizzazioni esterne ma anche individui di reparti che non collaborano necessariamente con frequenza regolare, come il reparto finanziario, legale e delle comunicazioni aziendali. In questo modo, tali organizzazioni hanno bisogno sia di creare un team interno di collaborazione ad hoc che di rendere disponibile il prodotto di tale collaborazione per coloro che non sono coinvolti nel processo di collaborazione ma che necessitano dell'accesso al prodotto finale. Utilizzando Sharepoint e Groove, è semplice raggiungere questi obiettivi.
Se non si dispone già di una libreria di documenti di Sharepoint da sincronizzare con la propria area di lavoro di Groove, è innanzitutto necessario crearla. A tale scopo, è sufficiente connettersi a Sharepoint e selezionare il collegamento Visualizza l'intero contenuto. Una volta caricata questa pagina, selezionare Create e quindi, come riportato nella Figura 1, selezionare Libreria di documenti nella colonna Librerie.
Figura 1 Creazione di una libreria di documenti di Sharepoint (fare clic sull'immagine per ingrandirla)
Nella nuova pagina della libreria di documenti, sono presenti diverse impostazioni da configurare: il nome e la descrizione della libreria, l'eventuale inclusione della libreria nella sezione Collegamenti rapidi, l'eventuale attivazione del versioning e il formato predefinito per i nuovi documenti creati direttamente nella libreria. La selezione di Cronologia versioni documento è disattivata per impostazione predefinita, ma è consigliabile attivare questa funzione se il versioning è adeguato per il proprio ambiente. È inoltre opportuno considerare anche una parte della funzionalità avanzata disponibile con Sharepoint e che è possibile utilizzare come parte dell'implementazione di Groove e Sharepoint. Questa funzionalità ottimizzata include:
  • Cronologia versioni
  • Controllo approvazioni
  • Procedure di controllo
  • Controllo del flusso di lavoro
  • Criteri di conservazione documenti
  • Controllo
  • Really Simple Syndication (RSS)
Queste funzioni aggiuntive disponibili tramite Sharepoint offrono un notevole valore aggiunto se si utilizza Groove. Nel mio esempio, questa funzionalità aggiuntiva, in particolare nel controllo approvazioni, risulterà molto utile. Supponiamo, ad esempio, che i membri del team collaborano all'interno di Groove per creare la bozza di un documento. Quando la bozza finale è pronta per la revisione, è possibile sincronizzarla con Sharepoint per sottoporla al processo di approvazione.

Configurazione del controllo approvazioni
Per configurare questa funzionalità, selezionare il menu Impostazioni dalla libreria di documenti e scegliere poi la voce Impostazioni. In questo modo, vengono visualizzate tutta le opzioni di configurazione e personalizzazione. Per configurare l'approvazione, selezionare il collegamento Impostazioni flusso di lavoro nella sezione Autorizzazioni e gestione per visualizzare la pagina Aggiungi flusso di lavoro. Selezionare il modello Flusso di lavoro, che nel nostro esempio sarà il modello Approvazione, quindi immettere un nome per il flusso di lavoro. In seguito, è necessario decidere se utilizzare un elenco di attività esistente o crearne uno nuovo. Un nuovo elenco di attività garantisce maggiore riservatezza ma, poiché questo non è un problema nel nostro esempio, è sufficiente selezionare l'elenco predefinito.
Dopo avere scelto l'elenco di attività, è necessario decidere come iniziare il processo di approvazione. Rendiamolo un processo manuale consentendo a qualunque utente autenticato con le adeguate autorizzazioni di avviare il processo. Altre opzioni consentono di automatizzare questo processo basato sul versioning, se è abilitato sulla libreria di documenti o ogni volta che si aggiunge un nuovo documento o si modifica un documento esistente.
Dopo avere premuto Avanti per accettare queste opzioni di configurazione, è necessario inserire alcune informazioni di configurazione finali. La prima opzione da configurare è la modalità di assegnazione delle attività. Poiché è possibile che siano presenti più persone nel processo di approvazione, è possibile assegnare i responsabili approvazione in serie, in cui una persona approva l'elemento e lo passa alla persona successiva, o in parallelo, in cui chiunque può approvarlo in qualsiasi momento. È inoltre necessario decidere se consentire ai responsabili approvazione di assegnare le attività ad altre persone e se tali responsabili approvazione possono richiedere una modifica prima del completamento dell'attività.
Il passaggio successivo è la scelta dei responsabili approvazione effettivi e del momento preciso in cui completare l'attività. Infine, occorre decide quando completare il flusso di lavoro. L'opzione predefinita prevede che il flusso di lavoro venga completato al termine di tutte le attività. Nell'opzione di configurazione finale, si specifica se aggiornare lo stato di approvazione una volta completato il flusso di lavoro. Dopo avere premuto il pulsante OK, viene creato il processo di approvazione ed è possibile iniziare il processo di approvazione documenti.

Creazione dell'area di lavoro Groove
Una volta creata la libreria di documenti Sharepoint, il passaggio successivo è la creazione di un'area di lavoro Groove. A tale scopo, verificare innanzitutto che si disponga di un account Groove e di almeno un'identità. Le identità costituiscono la base per la presenza e la comunicazione all'interno di Groove. Ogni account Groove può essere associato a più identità ed ogni identità è associata a un file di contatto unico per consentire la personalizzazione delle proprie informazioni di contatto per ogni identità utilizzata. È inoltre possibile esportare il proprio account Groove e le identità associate per utilizzarli su più computer.
Una volta creati un account e un'identità, apre la Finestra di avvio di Groove facendo doppio clic su sull'icona Groove nella barra delle applicazioni. Fare clic sull'opzione Nuova area di lavoro, immettere un nome appropriato per l'area di lavoro e scegliere un tipo standard di area di lavoro. L'area di lavoro standard di Groove facilita la presenza, gli avvisi e l'assegnazione di ruoli per i membri dell'area di lavoro. Quando si fa clic su OK, Groove crea l'area di lavoro e la apre. Nella Figura 2 viene mostrata una nuova area di lavoro con alcuni file aggiunti allo strumento File. A questo punto, l'area di lavoro è funzionale ed è possibile completarne l'impostazione configurando gli avvisi o aggiungendo gli strumenti desiderati.
Figura 2 Una nuova area di lavoro di Groove (fare clic sull'immagine per ingrandirla)
Gli avvisi possono essere configurati a livello di strumento, di area di lavoro o di singolo file. I quattro livelli di avvisi sono nessuno, medio, alto e automatico. L'impostazione di Medio evidenzia il nuovo contento, mentre l'impostazione di Alto o Automatico riprodurrà un file audio. È inoltre possibile configurare degli avvisi anche per ricevere una notifica quando un utente accede ad una specifica area di lavoro. Per configurare gli avvisi, selezionare Imposta avvisi nel menu Opzioni. Gli avvisi su singoli file vengono impostati sulle proprietà del file stesso; fare clic con il tasto destro del mouse su un file nell'area di lavoro e selezionare Proprietà.
Oltre allo strumento File per la collaborazione documenti e allo strumento Discussione per discussioni di thread cha fanno parte dell'area di lavoro predefinita Standard, esistono molti altri strumenti tra cui: Calendario, Moduli, Gestione problemi, Riunioni, Blocco schizzi e, ovviamente lo strumento File di Sharepoint. Ciascuno strumento fornisce ulteriori funzionalità utili di collaborazione. Per aggiungere uno strumento, selezionare il pulsante Aggiungi uno strumento all'area di lavoro nella parte inferiore destra dell'area di lavoro, quindi scegliere lo strumento desiderato, come mostrato nella Figura 3. È inoltre semplice eliminare uno strumento in qualsiasi momento.
Figura 3 Aggiunta di uno strumento all'area di lavoro Groove (fare clic sull'immagine per ingrandirla)

Sincronizzazione di Groove e SharePoint
Dopo avere aggiunto lo strumento File di Sharepoint, è necessario impostare l'URL del sito di Sharepoint contenente la libreria di documenti con cui si desidera eseguire una sincronizzazione. A tale scopo, è sufficiente premere il pulsante Impostazione nell'area di lavoro Groove, mostrata nella Figura 4, dopo avere selezionato la scheda Sharepoint nella parte inferiore della schermata dell'area di lavoro.
Figura 4 Configurazione dello strumento File di Sharepoint (fare clic sull'immagine per ingrandirla)
Una volta immesso l'URL, verranno visualizzate tutte le librerie disponibili su tale sito di Sharepoint. Come viene riportato nella Figura 5, occorre poi selezionare la libreria che lei desidera utilizzare. Groove si connetterà ed inizierà la sincronizzazione automatica. Ciò significa che qualunque documento attualmente presente nella libreria Sharepoint verrà scaricato e reso disponibile tramite l'area di lavoro Groove. Nella Figura 6 viene illustrato un esempio.
Figura 5 Dopo avere impostato l'URL, le di Sharepoint saranno disponibili in Groove (fare clic sull'immagine per ingrandirla)
Figura 6 Sincronizzazione di Groove e Sharepoint (fare clic sull'immagine per ingrandirla)
I documenti vengono visualizzati come non letti nell'area di lavoro Groove poiché sono stati appena scaricati. Tenere presente che tutti i file sincronizzati con Sharepoint possono usufruire della funzionalità di archiviazione/estrazione di Sharepoint. Inoltre, quando si estrae un file, si verifica che nessun altro utente possa apportare delle modifiche durante la modifica del documento.
È inoltre importante ricordare che lo strumento File di Sharepoint consente una sincronizzazione bidirezionale, per consentire la sincronizzazione dei file aggiunti tramite lo strumento File di Sharepoint tramite Groove nella libreria di documenti Sharepoint. Anche se, per impostazione predefinita, la sincronizzazione avviene automaticamente, è possibile avviarla manualmente premendo il pulsante Sincronizza ora. Se si esegue tale operazione, verrà visualizzato un riepilogo di modifiche per qualunque file che richiede la sincronizzazione ed un'azione associata, get (da Sharepoint) o send (verso Sharepoint), come illustrato nella Figura 7.
Figura 7 Dopo la sincronizzazione manuale, verrà visualizzato un riepilogo di modifiche (fare clic sull'immagine per ingrandirla)
Un punto importante da tenere a mente è che lo strumento File distribuito come parte dell'area di lavoro Standard di Groove è diverso dallo strumento File di Sharepoint. Lo strumento File di Groove non esegue la sincronizzazione con Sharepoint e, in base alle esigenze, può essere rimosso. Tuttavia, poiché non esegue la sincronizzazione con Sharepoint, lo strumento può essere utilizzato come percorso di archiviazione per file temporanei necessari al team nel corso di un progetto. I file memorizzati in tale percorso, tuttavia, verranno sincronizzati tra i membri dell'area di lavoro.

Come consentire l'accesso all'area di lavoro
Con l'infrastruttura di collaborazione di base appena distribuita, è possibile iniziare a consentire agli utenti l'accesso all'area di lavoro. In primo luogo, tuttavia, è necessario invitarli, operazione che è possibile eseguire tramite la posta elettronica o la messaggistica istantanea di Groove. In alternativa, Groove consente di esportare l'invito ad un file. Tale file, con estensione .grv, che per impostazione predefinita è associato all'applicazione Groove, può essere consegnato in un altro modo, ad esempio collocandolo su un sito Web e consentendo al destinatario di scaricare l'invito.
La messaggistica istantanea di Groove include controlli di sicurezza per garantire che l'invito possa essere letto solo dal destinatario. Quando si esegue un invito tramite posta elettronica o si utilizza un file di invito, accertarsi che l'opzione Richiedi conferma accettazione sia selezionata, per avere una ulteriore conferma che la persona che sta per accedere alla propria area di lavoro sia l'invitato desiderato. Questa opzione fornisce un ulteriore livello di sicurezza per l'area di lavoro. È bene sapere anche che è possibile annullare degli inviti in sospeso.
Quando si invitano degli utenti nell'area di lavoro, è necessario selezionare un ruolo per ogni destinatario. I ruoli includono Responsabile, Partecipante e Ospite; l'assegnazione predefinita è Partecipante. Ogni ruolo ha dei diritti specifici all'interno dell'area di lavoro e, come regola generale, è consigliabile limitare il ruolo di Responsabile a coloro che hanno realmente bisogno di tutti i diritti nell'area di lavoro, come la capacità di eliminare gli strumenti. I creatori dell'area di lavoro ottengono il ruolo di Responsabile per impostazione predefinita e i ruoli assegnati possono essere modificati in qualsiasi momento.
Considerata la natura ad hoc del progetto presentato in questo articolo, un'ultima attività potrebbe essere l'eliminazione dell'area di lavoro Groove una volta completate le altre attività. Dopo avere verificato l'avvenuta sincronizzazione dell'area di lavoro con la libreria Sharepoint, è possibile aprire l'area di lavoro, andare al menu File e selezionare Elimina area di lavoro. Selezionare poi l'opzione di eliminazione Da questo computer o Per tutti i membri. (Ogni utente ottiene una copia dell'area di lavoro sul proprio computer e tale copia permane per un tempo indefinito a meno che non venga eliminata per tutti i membri).
Il culmine del progetto sarebbe un'altra opportunità di utilizzare la natura complementare di Groove e Sharepoint. Una volta avvenuta sincronizzazione finale dei documenti, ci si trova in una posizione ideale per usufruire delle impostazioni di Criteri di gestione delle informazioni in Sharepoint. In particolare, è possibile abilitare la scadenza dei dati per fornire un metodo per la gestione automatica dei dati archiviati.
L'abilitazione della scadenza consente di specificare un periodo di tempo durante il quale conservare i dati. Alla fine di tale periodo di conservazione, Sharepoint può eliminare automaticamente i dati o avviare un processo del flusso di lavoro. Questa funzionalità fornisce una modalità valida per incorporare i dati di Groove nei criteri di gestione del ciclo di vita di informazioni della propria azienda. È possibile configurare i criteri di conservazione dei dati in qualsiasi momento. Infatti, se questa operazione non è stata eseguita al momento della configurazione iniziale della libreria, è possibile svolgerla ora.
Per abilitare la scadenza, selezionare il menu Impostazioni all'interno della libreria di documenti, quindi selezionare la voce di menu relativa alle impostazioni della libreria di documenti. È quindi possibile visualizzare l'opzione di menu Impostazioni dei criteri di gestione delle informazioni nella sezione Autorizzazioni e gestione della pagina. Dopo avere fatto clic sul collegamento Impostazioni dei criteri di gestione delle informazioni, è possibile specificare nuovi criteri personalizzati definiti oppure scegliere di abilitare la libreria di documenti per utilizzare i criteri definiti a livello di sito.
Tenere presente che ,se si definisce un criterio personalizzato, sarà necessario immettere alcune informazioni di configurazione. Quindi, nel mio esempio, abiliterò la scadenza, quindi selezionerò un periodo di conservazione e un'azione da eseguire una volta scaduto tale periodo.
Groove è un client di collaborazione ricco, progettato per fornire un framework dinamico, intuitivo e sicuro per una collaborazione ad hoc. Con una serie di strumenti completa al suo interno, Groove fornisce una piattaforma collaborativa lightweight e adattabile che può essere utilizzata senza problemi all'interno di un'organizzazione o tra le varie organizzazioni.
Se Sharepoint fornisce già una serie di strumenti collaborativa e un framework di gestione del contenuto solido e potente per la vostra azienda, ritengo che la combinazione di tale strumento con Groove rappresenti una soluzione ideale. I due prodotti sono estremamente complementari e, quando vengono utilizzati insieme, possono aggiungere significativi vantaggi di produttività per i team collaborativi.﻿

Alan Maddison è un Senior Consultant con Strategic Business Systems, una divisione di Brocade.


Amministrazione di Windows
Introduzione a Clustering di failover di Windows Server 2008
Chuck Timon
Panoramica:
  • Snap-in Gestione cluster di failover
  • Nuove funzionalità e miglioramenti
  • Funzionalità di backup e ripristino
  • Migrazione da Windows Server 2003

Indice
Nuova interfaccia di gestione
Miglioramento del processo di configurazione
Procedura di convalida incorporata
Nuovo modello quorum
Miglioramenti delle funzionalità di sicurezza
Estensione della funzionalità di connessione in rete
Maggiore affidabilità nell'interazione con l'archivio
Processi di ripristino incorporati
Nuova funzionalità di backup e ripristino
Migrazione dai cluster di server di Windows Server 2003
Fin da quando il clustering è stato introdotto la prima volta in Windows NT 4.0 Enterprise Edition, gli utenti si sono lamentati perché lo ritengono troppo difficile da configurare e persino più difficile da gestire. L'amministrazione di un cluster ha richiesto
all'amministratore di avere qualcosa di più della semplice conoscenza dell'elemento di clustering in sé: gli ha di fatto imposto di avere una conoscenza approfondita sia delle tecnologie di archiviazione sia del modo in cui il servizio cluster avrebbe interagito con le diverse soluzioni di archiviazione. All'interno di molte organizzazioni, il bagaglio completo di competenze necessario per rendere operativa una soluzione ad alta disponibilità, e in seguito gestirla, era davvero complicato da reperire.
Con il passare degli anni il clustering è stato migliorato, ma lasciava ancora molto a desiderare quando Microsoft iniziò a lavorare su Windows Server® 2008. Avendo ben presente il problema, il team iniziò a riprogettare il clustering cercando di raggiungere l'obiettivo principale della semplicità. In Windows Server 2008, Microsoft® Cluster Services (MSCS) è stato sottoposto a una ristrutturazione completa, con conseguente cambiamento del nome che ora è Clustering di failover.
Questo non significa che la semplicità sia l'unico contributo che l'implementazione di Clustering di failover ha da offrire. Con gli anni, Microsoft ha imparato molte lezioni, poiché le organizzazioni hanno fornito commenti e suggerimenti preziosi riguardo a quello che avrebbero voluto vedere in una soluzione di clustering. La nuova funzionalità Clustering di failover risolve molte delle questioni cruciali segnalate dagli utenti, oltre a introdurre alcune nuove funzionalità interessanti capaci di renderla una proposta davvero attraente. In questo articolo, vorrei presentare alcune delle nuove funzionalità che Clustering di failover di Windows Server 2008 mette a disposizione degli utenti.

Nuova interfaccia di gestione
Dopo aver installato Clustering di failover, è possibile accedere all'interfaccia Gestione cluster di failover tramite Strumenti di amministrazione oppure eseguendo Cluadmin.msc. Al pari di altre interfacce di gestione in Windows Server 2008, lo snap-in Gestione cluster di failover è un'utilità di Microsoft Management Console (MMC) 3.0. Per i veterani dei cluster, aprire per la prima volta lo snap-in Gestione cluster di failover sarà un po' come ritrovarsi in un paese straniero senza neanche avere una cartina stradale.
La nuova interfaccia è divisa in tre riquadri separati, come illustrato nella Figura 1. Nel riquadro di sinistra sono riportati tutti i cluster di failover di Windows Server 2008 presenti nell'organizzazione. Il riquadro centrale fornisce i dettagli relativi alla parte di configurazione del cluster selezionata nel riquadro di sinistra, mentre il riquadro di destra mostra le azioni che possono essere eseguite.
Figura 1 Snap-in Gestione cluster di failover (fare clic sull'immagine per ingrandirla)
Immaginiamo, ad esempio, di selezionare Archiviazione nel riquadro di sinistra. Il riquadro centrale riporterà i dettagli sul provisioning dell'archivio nel cluster, oltre a indicare quale archivio è eventualmente disponibile al momento. Come si può vedere nella Figura 1, il cluster contiene una parte di archivio che supporta un disco witness, un archivio che è stato predisposto per un file server e le risorse di archivio disponibili. Il riquadro di destra visualizza le azioni possibili, come ad esempio l'aggiunta di risorse per l'archiviazione. Tenere presente che lo snap-in Gestione cluster di failover non può essere utilizzato per amministrare versioni precedenti di Microsoft Clustering Services.

Miglioramento del processo di configurazione
Configurare un cluster di failover è davvero facile. Molte delle azioni necessarie per la configurazione, la riconfigurazione e la gestione dispongono di procedure guidate, grazie alle quali gli amministratori non devono più preoccuparsi di sapere se le risorse sono configurate correttamente o se si connettono nell'ordine giusto.
La Figura 2 mostra la Configurazione guidata disponibilità elevata. In questo esempio specifico, è stato configurato un file server. Sulla sinistra si vede l'elenco dei passaggi che la procedura guidata ha proposto all'amministratore. Una volta terminato il processo, viene visualizzata una pagina di riepilogo ed è possibile vedere un report.
Figura 2 Configurazione guidata disponibilità elevata (fare clic sull'immagine per ingrandirla)

Procedura di convalida incorporata
Nelle versioni precedenti di Windows Server, per essere considerate soluzioni cluster supportate, le configurazioni hardware dovevano essere elencate come soluzione cluster nel Catalogo di Windows Server . Questo riguardava anche i cluster multisito, che erano riportati separatamente nella categoria dei cluster geograficamente lontani. Per essere inseriti nel catalogo, i fornitori hardware dovevano eseguire una set di test WHQL (Windows Hardware Quality Lab) e inviare i risultati a Microsoft. Si trattava di una proposta onerosa per il fornitore e inoltre il database del Catalogo di Windows Server era difficile da gestire.
In Windows Server 2008, Clustering di failover include un processo di convalida che è incorporato. Il processo è composto da una serie di test raggruppati in quattro categorie principali, come illustrato nella Figura 3.
Figura 3 Categorie dei test di convalida di Clustering di failover (fare clic sull'immagine per ingrandirla)
Come si può vedere, la categoria Rete è espansa per mostrare i test che vengono eseguiti; ogni categoria contiene una a serie di test. La categoria Archiviazione, probabilmente la più importante delle quattro, include test che verificano la conformità delle soluzioni di archiviazione ai nuovi requisiti previsti per Cluster di failover di Windows Server 2008.
In particolare, oggi i fornitori hardware devono utilizzare driver basati sul driver Microsoft Storport e devono supportare le prenotazioni permanenti SCSI-3. Inoltre, se utilizzati, i moduli specifici per dispositivi Microsoft Multi-Path devono basarsi sullo standard I/O a percorsi multipli di Microsoft.
Grazie all'inclusione del processo di convalida, il modello di supporto è cambiato. Tutto l'hardware deve avere il logo Windows Server 2008 e tutti i test di convalida devono essere superati. Le uniche eccezioni sono costituite dai cluster multisito, che dispongono di due enclosure di archiviazione distinti e separati (uno per ogni sito) e l'implementazione della replica continua cluster di Exchange Server 2007, che non utilizza nessun archivio condiviso.

Nuovo modello quorum
In Clustering di failover di Windows Server 2008 è cambiato anche il modello quorum. Nei sistemi più vecchi, quando sentiva la parola quorum, un amministratore pensava immediatamente a un disco condiviso in cui risiedevano la configurazione del cluster e alcuni file replicati. Era il singolo punto di errore nel cluster. Se si verificava un errore del disco quorum, il servizio cluster si arrestava e la disponibilità elevata andava perduta.
I cluster di server di Windows Server 2003 offrivano un secondo tipo di quorum chiamato "maggioranza dei nodi". In genere, questo tipo di quorum veniva implementato nei cluster multisito e non richiedeva alcun archivio condiviso. Il quorum maggioranza dei nodi era composto da una condivisione file residente nell'unità di sistema di ogni nodo cluster. Le connessioni a questo tipo di quorum avvenivano tramite le connessioni SMB (Server Message Block). Ancora una volta, perché il cluster potesse funzionare era necessario che partecipasse una maggioranza di nodi.
Poi, grazie all'introduzione della replica continua dei cluster di Exchange Server 2007, ai cluster di server di Windows Server 2003 è stata aggiunta la funzionalità Witness di condivisione file. Questo ha fatto sì che un solo nodo cluster di replica continua cluster di Exchange 2007 (o qualunque cluster multisito) potesse continuare a fornire i servizi, a condizione che una connessione al witness di condivisione file raggiungesse una maggioranza.
In Clustering di failover di Windows Server 2008, l'idea di quorum significa veramente consenso. Il quorum, o consenso, oggi viene ottenuto con il raggiungimento di un numero sufficiente di voti per avviare il servizio del cluster e, a seconda della configurazione del quorum, i modi per ottenere il numero di voti necessario sono diversi. In un cluster di failover di Windows Server 2008 sono disponibili quattro modalità di quorum, come illustrato nella Figura 4. Dei quattro modi elencati, soltanto i primi due (Maggioranza dei nodi e Maggioranza dei nodi e dei dischi) possono essere selezionati automaticamente durante il processo di creazione del cluster. Questa è la logica da applicare:
  • se nel cluster si configura un numero dispari di nodi, selezionare la modalità Maggioranza dei nodi;
  • se nel cluster si configura un numero pari di nodi e l'archivio condiviso è connesso e accessibile, selezionare Maggioranza dei nodi e dei dischi.
Figura 4 Modalità dei quorum nella Configurazione guidata quorum del cluster (fare clic sull'immagine per ingrandirla)
Per selezionare un disco witness dall'archivio disponibile, selezionare il primo disco con dimensioni pari almeno a 500 MB e per il quale sia configurata una partizione NTFS. Le modalità quorum rimanenti possono essere selezionate solo manualmente eseguendo la Configurazione guidata quorum del cluster. In genere, l'opzione Maggioranza dei nodi e delle condivisioni file viene utilizzata in una configurazione di cluster multisito oppure in un cluster di replica continua cluster di Exchange 2007. L'ultima opzione, la modalità Non di maggioranza - solo disco, equivale al modello quorum condiviso nei cluster legacy. È un singolo punto di errore e in genere non andrebbe utilizzata.
Per contribuire al raggiungimento del consenso, esistono solo due tipi di risorsa witness che possono essere configurati nel cluster: un disco fisico e una condivisione file.
Un disco witness è una porzione di archivio di cui il servizio cluster può eseguire la connessione in linea. Questo disco si trova nel gruppo Risorse principali del cluster insieme al Nome rete del cluster e alle risorse di indirizzo IP associate. Quando si configura il disco witness, nel disco vengono inserite la cartella Cluster e una copia completa della configurazione del cluster (la replica o l'﻿hive del cluster).
Un witness di condivisione file è una condivisione di rete che, nella situazione ideale, si trova in un server nella rete che non fa parte del cluster. Viene eseguita una connessione SMB al witness di condivisione file, il quale mantiene una copia del file di registro witness, che contiene le informazioni sul controllo versioni della configurazione del cluster.
In un cluster può essere configurata soltanto una risorsa witness. Alla risorsa spetta il compito di fornire un voto in più nel caso in cui il cluster ne avesse bisogno per raggiungere il quorum. In altre parole, se al cluster manca un voto (e perciò un nodo) per raggiungere il consenso, la risorsa witness si connette al fine di ottenere il quorum. Nel caso in cui al cluster mancasse più di un voto per raggiungere il quorum, la risorsa witness non viene coinvolta e il cluster rimane in uno stato di inattività, nell'attesa che un altro cluster esegua l'accesso.

Miglioramenti delle funzionalità di sicurezza
Cluster di failover offre diversi nuovi miglioramenti della sicurezza. Di maggior rilievo è forse quello che riguarda l'eliminazione del requisito dell'account del servizio cluster (CSA). Nelle versioni precedenti di Servizio cluster di Microsoft, durante il processo di configurazione era necessario un account utente di dominio. Utilizzato per avviare il servizio cluster, l'account veniva aggiunto al gruppo di amministratori locale di ciascun nodo del cluster e gli venivano assegnati i necessari diritti utente locale per consentire al servizio cluster di funzionare correttamente. Come account utente di dominio, il CSA doveva rispettare numerosi criteri a livello di dominio che potevano essere applicati ai nodi del cluster. Erano criteri che potevano avere un impatto negativo sulla disponibilità elevata, provocando errori del servizio cluster.
Oggi il servizio cluster viene eseguito utilizzando un account di sistema locale, con un set specifico di diritti nel nodo cluster locale che gli permette di funzionare correttamente. Il contesto della sicurezza del cluster è passato all'oggetto nome cluster (CNO), ovvero l'oggetto computer creato per impostazione predefinita nel contenitore Computer di Active Directory® quando si crea il cluster. Una volta riuscita la creazione del cluster e in Active Directory esiste il CNO, l'account utente utilizzato per installare e configurare il cluster non è più necessario.
Gli ulteriori oggetti computer creati nel contenitore Computer di Active Directory vengono associati a un cluster di failover. Questi oggetti, detti oggetti computer virtuale (VCO), equivalgono alle risorse Nome rete create nel cluster come parte dei punti di accesso client. Il CNO, cui si deve la creazione di tutti i VCO di un cluster, viene aggiunto all'elenco di controllo di accesso di sistema (SACL) dell'oggetto in Active Directory (vedere la Figura 5).
Figura 5 Sicurezza per un VCO in Active Directory (fare clic sull'immagine per ingrandirla)
Il CNO è anche responsabile della sincronizzazione delle password di dominio di tutti i VCO che ha creato. Questo processo viene eseguito in conformità ai criteri di rotazione delle password configurati per il dominio. Inoltre, poiché il CNO è responsabile della creazione di tutti gli oggetti computer associati ai VCO in un cluster, il CNO (Account del computer) deve disporre a livello di dominio del diritto di creare oggetti computer nel contenitore in cui vengono creati i VCO (per impostazione predefinita, il contenitore Computer).
Ulteriore innovazione, Kerberos ora viene utilizzato come metodo di autenticazione predefinito. L'esistenza di account del computer in Active Directory tiene conto di questa funzionalità di sicurezza avanzata. Tuttavia, il cluster ha anche la possibilità di utilizzare l'autenticazione con il protocollo NTLM (NT LAN Manager), nel caso in cui un'applicazione non in grado di utilizzare Kerberos avesse la necessità di accedere alle risorse cluster.
Sono più sicure anche le comunicazioni tra i nodi di cluster che interagiscono direttamente con il processo cluster. Per impostazione predefinita, tutte le comunicazioni interne a un cluster sono firmate. Tramite l'interfaccia della riga di comando cluster.exe, questa proprietà del cluster può essere modificata per fare in modo che tutte le comunicazioni tra i nodi siano crittografate così da aggiungere un ulteriore livello di sicurezza.

Estensione della funzionalità di connessione in rete
Le nuove funzionalità di connessione in Cluster di failover assicurano una maggiore flessibilità durante la progettazione delle soluzioni a disponibilità elevata e per il ripristino di emergenza. Allo stesso tempo, i miglioramenti alla connessione forniscono una connettività più affidabile tra i nodi del cluster.
Probabilmente, la funzionalità personalizzata più richiesta è stata la possibilità di individuare i nodi del cluster nelle reti separate. Oggi questo è possibile. Il driver della rete di cluster è stato completamente riscritto, così da fornire comunicazioni estremamente affidabili e a tolleranza d'errore tra i nodi di un cluster, a condizione che ciascuno di essi sia connesso ad almeno due reti separate e instradate in modo distinto.
Il driver della rete di cluster crea la propria tabella di routing interna sulla base delle informazioni di connettività fornite durante il processo di avvio del cluster. Ciò include le informazioni di connettività locale, oltre alle informazioni fornite nel database di configurazione cluster (hive del registro del cluster).
Parte del processo di convalida del cluster include un processo di rilevamento della connettività di rete. Il fatto di poter individuare i nodi del cluster su reti diverse e instradate ha mitigato i requisiti di connessione per i cluster multisito. Questo renderà più facile e meno onerosa la loro distribuzione da parte delle organizzazioni. Inoltre, renderà più appetibile l'uso dell'archivio iSCSI come soluzione di archiviazione in Cluster di failover.
I nodi di cluster possono ottenere le informazioni sugli indirizzi IP anche tramite DHCP (Dynamic Host Configuration Protocol). Si tratta di un protocollo capace di alleviare il carico di lavoro degli amministratori di rete, qualora riescano ad accettare l'uso dell'indirizzamento dinamico per i server nel loro ambiente.
È la configurazione delle interfacce di rete di un nodo del cluster a stabilire quali reti utilizzeranno gli indirizzi IP statici o quelli dinamici. Anche se viene ricavata da un server DHCP, una risorsa indirizzo IP in un cluster può essere trasformata in indirizzo IP statico nello snap-in Gestione cluster di failover.
In passato, tutte le informazioni relative ai cluster utilizzavano il broadcast UDP (User Datagram Protocol) e, a volte, il multicast. La funzionalità Multicast è stata interrotta e le comunicazioni tra cluster ora si avvalgono della trasmissione unicast UDP. (La porta 3343 è ancora la porta comune utilizzata dai cluster Microsoft). Molti amministratori di rete saranno felici di scoprire che la trasmissione broadcast non viene più utilizzata. Tuttavia, il vero vantaggio in un cluster ha a che fare con i nuovi processi di messaggistica che sono interni al servizio cluster, un aspetto che però esula dall'argomento del presente articolo. Oggi, le comunicazioni interne a un cluster sono caratterizzate da comunicazioni TCP più affidabili, sebbene utilizzino UDP come meccanismo di trasporto.

Maggiore affidabilità nell'interazione con l'archivio
Il modo in cui Cluster di failover interagisce con l'archivio differisce in modo radicale. Il driver del disco cluster (clusdisk.sys) è stato completamente riscritto e ora è un driver PnP (Plug and Play) vero e proprio. Inoltre, è cambiato il modo in cui interagisce con l'archivio.
In Windows Server 2003, il driver del disco cluster si trovava in un percorso diretto per l'archivio. Ma in Windows Server 2008, per interagire con l'archivio, il driver del disco cluster comunica con il driver del Gestore partizioni (partmgr.sys). Questi due diversi approcci sono illustrati nella Figura 6.
Figura 6 Come è cambiato lo stack di archiviazione in Windows Server 2008 (fare clic sull'immagine per ingrandirla)
Al Gestore partizioni spetta il compito principale di proteggere le risorse del disco cluster. Tutti i dischi in un bus di archivio condiviso sono automaticamente messi non in linea quando vengono associati a un nodo di cluster. Questo consente all'archivio di essere associato simultaneamente a tutti i nodi di un cluster, anche prima che il cluster venga creato. Non è più necessario avviare i nodi uno alla volta, preparare i dischi in un nodo e poi arrestarlo, quindi avviare un altro nodo, verificare la configurazione dei dischi e così via.
Tuttavia, sono ancora presenti i test dell'archivio, che vengono eseguiti nel contesto del processo di convalida del cluster e richiedono l'inizializzazione dei dischi. Ciò può avvenire in uno dei nodi del cluster prima dell'esecuzione del processo di convalida. Una volta che l'archivio è stato aggiunto al cluster, nell'interfaccia Gestione disco i dischi mostrano lo stato Riservato e non sono mai lasciati in uno stato non protetto.
Un altro cambiamento riguarda i comandi SCSI. In Windows Server 2003, venivano utilizzati i comandi di prenotazione/rilascio SCSI-2 con il driver del disco cluster che scriveva in settori del disco stesso. In Windows Server 2008, sono necessari comandi di prenotazione permanente SCSI-3. I nodi di cluster devono registrarsi prima che sia consentito loro di effettuare una prenotazione dell'archivio e periodicamente devono difendere le prenotazioni utilizzando il protocollo RDP (Reservation and Defense Protocol).
Nell'ambito del processo di convalida, uno dei test verifica questa funzionalità. Se una soluzione di archiviazione non supporta i comandi di prenotazione permanente SCSI-3, non è supportata in un cluster di failover.
Per la ridondanza, quando si connettono all'archivio molte organizzazioni utilizzano software a percorsi multipli. Questa soluzione è non solo supportata ma persino promossa come procedura consigliata. Tuttavia, perché siano supportati in un cluster di failover, le soluzioni software a percorsi multipli di terze parti o i moduli specifici per dispositivi devono essere riscritti utilizzando lo standard I/O a percorsi multipli di Microsoft. Questo assicura che tutti i comandi di prenotazione permanente SCSI-3 siano inviati contemporaneamente in tutti i percorsi per l'archivio, indipendentemente dal fatto che il percorso sia attivo o meno. Anche questa funzionalità viene verificata nell'ambito del processo di convalida.
Tra gli altri miglioramenti dell'archivio sono da ricordare un processo avanzato di controllo del disco (chkdsk.exe), la funzionalità incorporata di ripristino dischi (in precedenza parte dell'utilità di ripristino del server) e i dischi con riparazione automatica. In Cluster di failover, quando si identifica una risorsa disco cluster, vengono utilizzati sia la firma del disco che l'ID LUN. Se uno dei due è cambiato, viene aggiornata la configurazione del cluster. Il risultato è una riduzione degli errori, semplicemente in virtù del fatto che la modifica di un attributo in una risorsa disco produce una maggiore disponibilità elevata.

Processi di ripristino incorporati
La riparazione automatica dei dischi è ovviamente una delle funzionalità di ripristino incorporate. Un'altra è la funzionalità Ripristina di Active Directory. Se l'oggetto computer che rappresenta il CNO viene eliminato, non è più possibile creare gli oggetti computer associati ai punti di accesso client del cluster. Tuttavia, con ogni probabilità il primo problema a verificarsi sarà l'impossibilità degli utenti o delle applicazioni a disponibilità elevata ad accedere alle risorse esterne al cluster, poiché non riescono a ottenere un token di protezione.
Per ripristinare un CNO eliminato è necessario eseguire un processo che richiede due passaggi. Innanzitutto, si deve richiedere a un amministratore di dominio di recuperare l'oggetto computer eliminato dal contenitore DeletedObjects di Active Directory. Quindi, dopo il ripristino e la riattivazione dell'oggetto, si dovrà eseguire il processo Ripristina oggetto Active Directory nello snap-in Gestione cluster di failover.
Nei cluster di server di Windows Server 2003, esisteva la possibilità che il file di configurazione cluster contenuto nella sottodirectory %systemroot%\cluster si potesse danneggiare e pertanto dovesse essere sostituito. In Cluster di failover, la funzionalità di riparazione automatica può risultare utile in questo senso. Se il servizio cluster viene avviato in un nodo e il database di configurazione è danneggiato, verrà caricato un modello di configurazione minima che utilizza le informazioni contenute nella chiave del registro di sistema HKLM\System\CCS\Services\ClusSvc\Parameters. Il nodo tenterà di accedere a un cluster già formato e, se il tentativo riesce, al nodo viene inviata una nuova copia dell'hive del registro del cluster. Al contrario, se il nodo non riesce ad accedere a un cluster, il servizio cluster sarà terminato.

Nuova funzionalità di backup e ripristino
Clustering di failover è dotato del proprio writer del servizio Copia Shadow del volume. Questo svolge un ruolo fondamentale nelle operazioni di backup e ripristino del database di un cluster e dei dati che risiedono nelle risorse del disco fisico. Il backup della configurazione del cluster è un'operazione piuttosto semplice. Purché lo stato del sistema faccia parte di un backup, la configurazione del cluster può essere ripristinata. Ma occorre tenere presente che si deve eseguire il backup di un cluster soltanto se ha il quorum. Questo assicura che il backup venga effettuato sulla configurazione più aggiornata del cluster.
Esistono due tipi principali di ripristino: autorevole e non autorevole. Da una parte, un ripristino non autorevole utilizza Windows Server Backup o un'applicazione di backup di terze parti per eseguire un ripristino da un backup selezionato. Dall'altra, un ripristino non autorevole di un nodo di cluster può essere effettuato soltanto utilizzando l'interfaccia della riga di comando di Windows Server Backup (wbadmin.exe).
In pratica, un ripristino autorevole riporta la configurazione del cluster "indietro nel tempo" fino al momento in cui è stato eseguito il backup. Per realizzare un ripristino di questo tipo, il servizio cluster si arresta in tutti i nodi ad eccezione di quello in cui viene eseguito il ripristino. Una volta terminato il ripristino e riavviato il servizio cluster nel nodo ripristinato, la configurazione ripristinata del cluster diventa la nuova configurazione definitiva. Successivamente, quando si riavvia il servizio cluster nei nodi rimanenti del cluster, la configurazione ripristinata viene trasferita durante il processo di accesso.
In alcuni scenari, questo consente di ottenere risparmi notevoli in termini di tempo e di denaro. Poniamo di avere un cluster di stampa che ospita più risorse di spooler di stampa, ognuna delle quali supporta 1.500 stampanti, e che accidentalmente venga eliminata una di tali risorse. Questo significa che un consistente numero di utenti non può stampare. Anziché aggiungere manualmente tutte le stampanti alla configurazione del cluster, sarebbe molto più veloce eseguire un ripristino autorevole di quella configurazione. Ma questo, naturalmente, dipende dalla disponibilità sia di un backup affidabile che di una strategia di ripristino.

Migrazione dai cluster di server di Windows Server 2003
A causa di tutte queste modifiche dell'architettura apportate in Clustering di failover di Windows Server 2008, non sono supportati gli aggiornamenti sul posto o in sequenza da Windows Server 2003. Quando si esegue l'aggiornamento dai cluster Windows Server 2000 a Windows Server 2003, molte organizzazioni rimuovevano sistematicamente ogni nodo del cluster, eseguivano un'installazione pulita del sistema operativo e quindi aggiungevano nuovamente il nodo nel cluster. Non è possibile utilizzare lo stesso approccio per la migrazione a Windows Server 2008, dal momento che i nodi di cluster di Windows Server 2003 e quelli di Windows Server 2008 non possono appartenere allo stesso cluster.
Fortunatamente, per facilitare le operazioni è stato incluso un processo di migrazione tramite procedura guidata. Tuttavia, la migrazione a Cluster di failover di Windows Server 2008 richiede comunque una pianificazione. Si presentano tre scenari di base per la migrazione:
  • uso degli stessi server e dello stesso archivio;
  • uso degli stessi server, ma con un archivio nuovo;
  • uso di nuovi server e di un nuovo archivio.
Tutti gli scenari richiedono che l'hardware abbia ottenuto la certificazione del programma Windows Logo Program di Windows Server 2008, che sia stato eseguito il processo di convalida di Cluster di failover e che tutti i test siano stati superati. Una volta completati questi passaggi, il processo di migrazione può procedere.
Non è possibile eseguire la migrazione di tutte le risorse in Windows Server 2003. La si può eseguire per nomi di rete, indirizzi IP, dischi fisici, condivisioni file, directory principali DFS (Distributed File Share), DHCP e WINS. Lo stesso vale, con qualche limitazione, per servizi generici, applicazioni generiche e risorse script generici.
Applicazioni quali Microsoft Exchange ed SQL Server® dispongono delle proprie procedure per la migrazione a Cluster di failover. Quanto alle stampanti, se ne può eseguire la migrazione a Windows Server 2008 utilizzando lo snap-in Gestione stampa (che è installato con il ruolo di server di stampa) prima per esportare e poi per importare le stampanti in un server di stampa a disponibilità elevata e recentemente configurato. Non è possibile eseguire la migrazione di nessun tipo di risorsa di terze parti.
Il processo di migrazione non trasferisce dati, bensì è riservato alla migrazione delle impostazioni di configurazione del cluster da Windows Server 2003 a Windows Server 2008.
All'inizio, tutte le risorse oggetto di migrazione vengono messe non in linea una volta completato il processo di migrazione. Questo perché potrebbero essere richiesti ulteriori passaggi. Pertanto, prima di mettere in servizio il cluster, è importante leggere il report post-migrazione per vedere i passaggi aggiuntivi richiesti (esclusa la migrazione dei dati se si esegue la migrazione a un nuovo archivio). Ad esempio, se si esegue la migrazione di un server DHCP, sarà necessario installare il ruolo di server DHCP in tutti i nodi del cluster. Se si esegue la migrazione di un server WINS, sarà necessario installare la funzionalità Server WINS in tutti i nodi del cluster.

Chuck Timon è Support Escalation Engineer per Microsoft a supporto delle tecnologie di clustering e installazione. Ha scritto il corso di formazione per Windows Server 2008 Failover Cluster e attualmente è al lavoro sul corso di formazione per Hyper-V.


From the Editor La stampa è morta
Joshua Hoffman

La stampa è morta. O almeno così ci vorrebbero far credere. Nell'era delle informazioni illimitate, disponibili in ogni forma, momento e luogo, su una miriade di fantastici dispositivi, che posto occupa ormai una raccolta di pezzi di carta tenuti insieme dalla colla? Hanno fatto il loro tempo? Le riviste e i giornali dovrebbero essere relegati nelle sale dei musei, in modo che un giorno potremo ricordare con nostalgia tutta quella carta che conteneva pezzi di alberi e inchiostro?
È una visione melodrammatica? Sì. Sono certo che vi siete accorti che sono in totale disaccordo con questa affermazione, e non solo per attaccamento al mio posto di lavoro, perché in Microsoft ci sono un'infinità di cose che potrei fare. Sono assolutamente convinto che il mondo della carta stampata offra un'esperienza incredibilmente profonda e intensa, nonostante la sua semplicità (o forse grazie ad essa). Quando mi siedo a leggere un lungo articolo, vorrei sempre avere la versione stampata in mano piuttosto che la schermata del computer. Per me è semplicemente più affascinante. È un punto di vista antiquato? Forse, ma stando al nostro ultimo sondaggio sui lettori, il 90 percento la pensa proprio allo stesso modo.
Non sto suggerendo di nascondere la testa sotto la sabbia. Sono sempre stato un fanatico del computer fin dall'inizio e amo la tecnologia. Ma una pubblicazione come la nostra, può, e dovrebbe, essere un'esperienza olistica, un'esperienza che assume molte forme: online, offline e di persona. Se mi accingo a leggere un articolo lungo e molto tecnico di Mark Russinovich, preferisco la versione stampata. Ma voglio anche ascoltare la lezione di Mark e osservarlo mentre dimostra la tecnica di cui sta parlando.
Questo concetto è diventato un principio conduttore di TechNet Magazine. Sebbene siamo sempre orgogliosi della pubblicazione che mandiamo alle stampe ogni mese, tutti i contenuti che abbiamo pubblicato su carta da sempre sono disponibili anche nel sito. Nel prossimo futuro, assisteremo all'aumento dei contenuti che si avvalgono della nostra esclusiva piattaforma disponibile in Internet. Ad esempio, nel nostro ultimo numero, abbiamo lanciato la serie screencast con Don Jones e la sua rubrica Windows PowerShell. Ora è possibile guardare il video di Don mentre si scorre l'argomento della rubrica di quel mese. Sul nostro sito Web c'è anche una nuova rubrica, chiamata Sustainable Computing, dedicata interamente all'impatto ambientale dell'IT e alle azioni che i professionisti IT possono intraprendere per comportarsi da cittadini responsabili.
Come, sempre i tuoi commenti sono essenziali per continuare a fare di TechNet Magazine un'esperienza multimediale. Puoi scriverci all'indirizzo tnmag@microsoft.com.
-Joshua Hoffman

Si ringraziano i seguenti esperti tecnici Microsoft: Ed Banti, Avronil Bhattacharjee, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Elden Christensen, Trina Gorman, Scott Landry, Michael Murgolo, Sanjeev Nair, Hugh Pyle, Amritansh Raghav, Jez Sadler e Jim Truher.


Letters La parola ai lettori

Servizi di dominio Active Directory
Ho apprezzato moltissimo il numero di marzo 2008 di TechNet Magazine. Penso di averlo letto circa una dozzina di volte. In particolare, mi è davvero piaciuto l'articolo "Novità in Servizi di dominio Active Directory" di Gil Kirkpatrick. Nell'articolo Gil cita un prodotto chiamato Microsoft® Audit Collection Services. Questo prodotto è disponibile e funziona come applicazione autonoma?
—Erasmo M.

Microsoft ACS (Audit Collection Services) fa parte di SCOM (System Center Operations Manager), il software di gestione conosciuto prima con il nome di MOM (Microsoft Operations Manager). Non è disponibile come prodotto autonomo ma solo come parte di SCOM.
—Gil Kirkpatrick, NetPro CTO e collaboratore di TechNet Magazine

Firme
Nel secondo paragrafo della rubrica Windows PowerShell del numero di aprile 2008 di TechNet Magazine ("Firmare qui, prego" technet.microsoft.com/magazine/cc434702), l'autore Don Jones afferma: "La parola firma è il termine tecnicamente corretto per indicare l'argomento dell'articolo, ma non è una descrizione davvero soddisfacente di ciò che succede quando si utilizza una firma. Apporre una firma a uno script non significa che lo si approva o autorizza, come accade con un contratto o con una ricevuta della carta di credito".
Potrei sostenere che firmare un contratto o una ricevuta della carta di credito non implica necessariamente un'approvazione o un'autorizzazione. L'azione eseguita ha senso solo nel contesto di una visione più allargata dell'ambiente. Ad esempio, quando ero più giovane, giocavo con le ricevute delle carte di credito alla stazione di servizio di mio padre e nessuno tentò mai di riscuotere i debiti che avevo contratto in quelle transazioni.
Nel contesto di un'implementazione di rete Active Directory® "configurata appropriatamente" la firma è esattamente ciò che autorizza lo script a funzionare. La presenza della firma indica che la persona che sta firmando accetta la responsabilità di ciò che sottoscrive e la presenza della firma può dar luogo a ulteriori attività: emissione del conto della carta di credito da parte della società emittente o accettazione del codice come autentico da parte della rete.
Tenetevi stretta la gente che collabora: TechNet Magazine è davvero utile.
—Jeremy P.

Grazie per il tuo commento, Jeremy. Fa piacere sapere che i nostri lettori sono così attenti e critici su ciò che ha da dire TechNet Magazine.

SharePoint Services
Nell'esecuzione di WSS (Windows® SharePoint® Services), non Microsoft Office SharePoint Server, sono necessarie altre licenze CAL per gli utenti che vi accedono tramite l'interfacci/URL di un sito Web?
—Douglas M.

Esistono alcuni documenti circa questo argomento. Ecco alcuni collegamenti utili (in inglese): msmvps.com/blogs/cgross/archive/2005/04/02/40723; microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx e windowsserver/sharepoint/bb684457.
-Pav Cherny, giornalista di Inside SharePoint, TechNet Magazine

Un'idea su Inside SharePoint
Ho letto recentemente la rubrica Inside SharePoint del numero di maggio 2008 di TechNet Magazine (technet.microsoft.com/magazine/cc462809). Hai chiesto ai lettori di inviare suggerimenti circa gli argomenti trattati. Sarebbe bello poter leggere un articolo sull'integrazione di SharePoint con Project/Project Server.
—Phil H.

Project/Project Server è un'ottima idea. Prenderemo in considerazione questo argomento per un numero futuro. Grazie per aver risposto.

Altre idee su Inside SharePoint
Il Web nel complesso contiene moltissimi documenti riguardanti la personalizzazione del sito usando o la UI standard di SharePoint o SharePoint Designer, ma c'è veramente molto poco sulle definizioni dei siti (e gli articoli disponibili sono così elementari che sono di poca utilità quando si devono affrontare problemi pratici). Siccome questa è un'area che molte persone stanno iniziando a esplorare, poter disporre di molte procedure può solo che aiutare l'adozione di SharePoint. In particolare, nella mia azienda ci siamo scontrati con gli argomenti seguenti:
  1. Impostazione delle autorizzazioni personalizzate in elenchi all'interno della definizione di un sito.
  2. Form di voci di elenchi personalizzati all'interno della definizione di un sito.
  3. Connessioni alla parte Web dall'interno della definizione di un sito.
  4. Come la definizione di un sito dovrebbe essere distribuita in modo incrementale.
—Adam C.

Grazie per i suggerimenti. Questo è proprio il tipo di commento dei lettori che prenderemo in considerazione proseguendo nello sviluppo di questo contenuto.


Toolbox Nuovi prodotti per professionisti IT
Greg Steen

Automazione delle attività amministrative
Automise 2
automise.com/automise.aspx
Le attività ripetitive che non richiedono uno sforzo concettuale sono noiose, laboriose e soggette a errori. L'automazione di questi tipi di attività è un fattore essenziale per ottimizzare l'amministrazione e può migliorare la soddisfazione nel lavoro. Oltre all'uso di deprimenti file batch e VBScript personalizzati per automatizzare le attività, esistono diverse utilità simili a macro per Windows® e alcune utilità che costringono a imparare una specie di linguaggio di scripting personalizzato. Ma c'è un'altra opzione. Automise 2, di VSoft Technologies, consente di generare routine di automazione per mezzo di una GUI di tipo selezione, trascinamento e personalizzazione.
L'interfaccia dell'applicazione è molto simile a un semplice IDE di programmazione e offre opzioni familiari. Sono disponibili una casella degli strumenti da cui è possibile trascinare gli elementi nella superficie di progettazione, controlli di debugging che consentono di entrare nel codice, una vista dei vari progetti, registri di output delle esecuzioni, finestre di cronologia e proprietà. Con Automise, il codice è davvero una rappresentazione visiva del flusso di lavoro delle attività automatizzate.
La casella degli strumenti di Automise è composta da azioni, ognuna delle quali esegue una singola fase nel processo di automazione. Nell'applicazione sono incluse 380 azioni che coprono la gamma delle operazioni possibili, dalla creazione di file zip al riavvio di IIS.
Quando si progetta l'attività, è possibile strutturare gerarchicamente queste azioni in modo da coprire molti dei processi amministrativi compiuti normalmente. Inoltre, è possibile collegare le azioni per mezzo di azioni di controllo del flusso quali blocchi try/catch, generazione di eccezioni, istruzioni if-then-else, loop, switch, ritardi e gruppi di azioni asincrone.
Ogni progetto di automazione può includere anche altri progetti, pertanto è possibile separare il flusso principale di controllo dalle attività secondarie. Sono disponibili anche azioni per manipolare le stringhe e i dati XML, per impostare le variabili, per l'attesa di processi e comandi e altre ancora. Grazie a tutte queste opzioni del flusso di controllo, possono essere automatizzate anche operazioni complesse.
Automise consente di creare, eseguire, modificare ed eliminare attività pianificate. Ciò significa che è possibile usare Automise anche per gestire i processi esistenti. Non ho spazio sufficiente per elencare tutte le azioni ma vorrei sottolinearne alcune degne di nota: azioni per registrare una DLL nella GAC (Global Assembly Cache), ricostruire gli indici SQL Server®, eseguire chkdsk, modificare il Registro di sistema, eseguire il backup del registro degli eventi, modificare gli utenti di Active Directory®, installare volumi, creare punti di ripristino e creare una directory virtuale. Se le azioni incorporate non sono in grado di soddisfare le proprie esigenze, in Automise sono presenti anche azioni per l'esecuzione personalizzata di script, comandi e SQL.
È un pratico strumento da tenere sempre a disposizione. Se si intende automatizzare solo la propria workstation Windows, invece di automatizzare l'infrastruttura di rete, è possibile usare Automise Lite, che non include diverse funzionalità ma gestisce la maggior parte delle esigenze dell'utente.
Prezzo: licenza per singolo utente a partire da 195 dollari (diretto).
Automazione visiva di attività con Automise 2 (fare clic sull'immagine per ingrandirla)

Monitoraggio dei registri in tempo reale
BareTailPro
baremetalsoft.com/baretailpro
I file di registro sono diffusissimi ma il problema è come usarli. È importante che la propria applicazione produca un registro delle transazioni. Ma oltre a usare gli strumenti di aggregazione dei registri, come è possibile osservare veramente ciò che avviene in tempo reale? La nostra soluzione è l'utilità collaudata BareTailPro di Bare Metal Software. Sebbene non sia stata aggiornata dal 2006, questa semplice utilità è ancora uno strumento avanzato di Windows simile alla vecchia console *nix command 'tail -f'.
Grazie alla semplicità della GUI, è possibile osservare più file di registro di qualsiasi dimensione contemporaneamente, vedendo in modo trasparente ciò che vi viene scritto in tempo reale. Per passare da un file a un altro è sufficiente fare clic sulla scheda. Ogni scheda visualizza un'icona per segnalare lo stato di ogni file di registro, indicando che è in corso una scrittura o che la coda è stata interrotta.
Il modo in cui molte applicazioni registrano è piuttosto diverso. Per fortuna, BareTailPro è in grado di leggere i file Unicode, UTF-8, ANSI e ASCII e la fine delle righe con una coppia di caratteri CR/LF, singoli caratteri LF e caratteri nulli. È possibile configurare facilmente sia il ritorno a capo del testo che l'espansione delle tabulazioni in modo da avere la vista migliore di un tipo particolare di file di registro. Inoltre, è possibile migliorare la leggibilità del file di registro configurando la dimensione del carattere, il tipo di carattere, la spaziatura e l'altezza della riga.
Un'altra grande funzionalità è la possibilità di configurare l'evidenziazione da applicare alla vista di un registro. È possibile definire un numero qualsiasi di regole di codifica dei colori per lo sfondo e il primo piano, in base a una stringa di testo. Ad esempio, è possibile evidenziare un errore in rosso e un avviso in giallo oppure scegliere di evidenziare tutte le righe che hanno un determinato indirizzo IP o riferimento all'host. È possibile specificare il grassetto o il corsivo nelle righe e scegliere di ignorare le maiuscole o minuscole nella stringa di testo.
Anche con l'evidenziazione del testo, un file di registro pesante può coprire la vista della coda, rendendo difficile l'individuazione degli eventi che si stanno cercando. BareTailPro offre un'altra funzionalità che può aiutare. Espressioni regolari e ricerca del testo consentono di ridurre subito la vista del registro, isolando le istanze delle righe in un sottoinsieme gestibile. La sintassi dell'espressione regolare usata da BareTailPro è costituita da un sottoinsieme della notazione standard usata da Java, Perl e PHP. Nel caso quest'uso non sia familiare, il sito Web del prodotto fornisce un riferimento rapido.
L'utilità mostra i risultati filtrati in formato tabellare, aggiungendo alcune colonne utili come la data e l'ora, il numero di riga e i risultati di qualsiasi gruppo di acquisizione definito insieme all'origine della riga. Nella vista filtrata, è anche possibile cambiare l'ordinamento di queste colonne.
Non riesco mai a ricordare la sintassi dell'espressione regolare che mi ha dato i risultati di cui avevo bisogno. Per questo apprezzo davvero la funzionalità di salvataggio del modello dello strumento. Questa funzionalità consente di denominare, modificare e salvare i modelli per poterli riutilizzare. Una volta che le righe importanti si trovano nella vista filtrata, BareTailPro consente anche di esportare questi risultati in un file o negli Appunti con un formato personalizzato, permettendo di impostare ad esempio larghezza, allineamento, prefisso e suffisso per ogni colonna dei risultati.
Questa minuscola utilità è contenuta in un solo e piccolo eseguibile, pertanto può essere portata in un altro ambiente con un basso impatto. Notare che, se è necessario solo osservare i file di registro e non sono necessari il filtraggio dell'espressione regolare, il salvataggio dei modelli di ricerca e l'esportazione dei risultati della ricerca e del filtro, è possibile cavarsela con la versione gratuita chiamata BareTail.
Prezzo: a partire da 35 dollari per una licenza individuale.
Monitoraggio della rete con BareTailPro (fare clic sull'immagine per ingrandirla)

Inventario dei sistemi
Total Network Inventory
softinventive.com
Poter accedere velocemente alle informazioni dettagliate sulle macchine in tutto l'ambiente è una componente essenziale di una gestione dei sistemi efficiente. È facile perdere la traccia delle informazioni contenute nei fogli di calcolo e negli elenchi di fornitori così come è difficile completare e tenere aggiornate tali informazioni.
Può essere molto utile usare uno strumento dinamico che presenta le informazioni così come servono, raccogliendo i dati su quale installazione è stata fatta e da chi e che tipo di hardware usa. Uno strumento come questo consente anche di tenere traccia di cosa altri utenti possono aver messo nelle loro macchine (ciò è possibile se, naturalmente, i criteri di gruppo non hanno già posto dei limiti ai diritti di installazione o fornito conteggi veloci del numero di licenze necessarie in base all'installazione per un particolare pacchetto software). Uno strumento che svolge questo compito è Total Network Inventory di Softinventive Lab.
Dopo aver installato Total Network Inventory, è possibile avviare il processo di inventario usando la procedura Scan Wizard che guida all'individuazione dei nodi nella rete. È possibile scegliere di eseguire l'analisi subito, per mezzo di un determinato intervallo di indirizzi IP o sfogliando la struttura ad albero dei computer, oppure è possibile usare l'analisi dello script di accesso che consente di raccogliere informazioni nel momento in cui una macchina accede al dominio.
Per eseguire l'analisi, Total Network Inventory si basa su WMI (Windows Management Instrumentation), IPC$\ADMIN$ o RPC/DCOM, e sulla condivisione classica per gli account locali. Pertanto è necessario eseguirlo nel contesto di un account di amministratore.
Una volta completata l'analisi, è quindi possibile scorrere le macchine o cercare specifici computer per fare l'inventario delle loro risorse. Total Network Inventory raggruppa i dati di inventario raccolti in queste aree: hardware, software e altre informazioni. La sezione sull'hardware include dettagli sul processore, la scheda madre e il chipset, la memoria, il sottosistema video, l'archiviazione (compresi dispositivi fisici e logici), i tipi e le configurazioni degli adattatori di rete, le periferiche e altri dispositivi installati nel sistema.
La sezione sul software fornisce informazioni sul sistema operativo, compresi codici "product key", numeri di serie, directory di sistema e pacchetti di servizi installati. Ci sono dettagli sugli hotfix (con i rispettivi numeri di articoli della Knowledge Base) e su applicazioni antivirus e per database eventualmente installate. È disponibile anche l'elenco dei programmi che sono installati (insieme a una vista della directory Programmi, che consente di vedere le applicazioni che possono essere state nascoste dall'elenco standard Installazione applicazioni) e l'elenco delle applicazioni a esecuzione automatica.
Infine la sezione "altre informazioni" racchiude dettagli sull'ambiente di sistema, ad esempio variabili utente e di sistema, risorse condivise, esecuzione di processi, servizi installati e account utente locali.
Total Network Inventory fornisce proprio quelle informazioni che sono necessarie a eseguire verifiche delle risorse, controlli delle licenze, calcoli sugli aggiornamenti e valutazioni delle prestazioni. Uno dei componenti migliori di questo strumento è Report Builder che fornisce rapporti multipli, bene organizzati e dettagliati per tutto, da un riferimento rapido a un procedimento di controllo cartaceo. I rapporti possono essere aggregati o relativi a una singola macchina. Una funzionalità che trovo particolarmente utile è la vista della scheda Software and Licenses Accounting. Visualizza il totale aggregato di ogni tipo di software installato nell'ambiente per garantire la conformità con i contratti con i fornitori.
Prezzo: a partire da 95 dollari per una licenza di 25 nodi.
La procedura Scan Wizard guida gli utenti alla scoperta dei nodi nella rete (fare clic sull'immagine per ingrandirla)

Recensione
Mastering Microsoft Exchange Server 2007
sybex.com
Che ci piaccia o no, la posta elettronica è un fattore essenziale del perfetto funzionamento di un'organizzazione (sebbene debba ammettere che a volte vorrei che gli utenti fossero costretti a prendere lezioni sulla comunicazione scritta prima di essere autorizzati a usare la posta elettronica). Nel corso degli anni, il desiderio di integrare comunicazioni vocali, sistemi di calendari, pianificazione delle risorse, accesso client uniforme e filtraggio della posta (antispamming, antivirus e simili) è diventato fin troppo evidente. È qui che Microsoft® Exchange Server 2007 entra in scena.
L'ultima versione di Exchange integra perfettamente tutti questi componenti in una soluzione scalabile e solida. Ma con tutte queste funzionalità, l'amministratore, l'architetto e lo staff di supporto devono disporre di alcuni validi libri di riferimento che li aiutino a distribuire, gestire e manutenere una soluzione dinamica di messaggistica elettronica come questa.
Nell'ultimo numero della rubrica Toolbox, avevo parlato di Microsoft Exchange Server 2007 Administrator's Companion. Un'altra risorsa utile che merita attenzione è Mastering Microsoft Exchange Server 2007 di Barry Gerber e Jim McBee (Sybex, 2007). Si tratta di una guida scritta in modo molto chiaro relativa al ciclo di vita di Exchange Server.
I primi tre capitoli del libro, una sezione chiamata "Understanding and Planning" parlano dei componenti di base e dei requisiti di implementazione di Exchange Server 2007. Coloro che già conoscono le versioni precedenti di Exchange apprezzeranno la sezione sulle funzioni che non sono più implementate o messe in evidenza. Ad ogni modo tutti apprezzeranno la descrizione dei diversi ruoli dei server e dei componenti che fanno parte di una distribuzione di Exchange Server 2007. La distribuzione di un server così complesso richiede una certa prudenza, pertanto consiglio di prestare particolare attenzione alle sezioni sulla pianificazione della crescita, sui requisiti dello spazio su disco e sull'integrazione di Active Directory.
La sezione successiva approfondisce l'installazione vera e propria, sia nel caso di un'installazione pulita che in quello di un aggiornamento da Exchange Server 2000 o Exchange Server 2003 (non è possibile eseguire l'aggiornamento direttamente da Exchange Server 5.5). Sono descritti in dettaglio anche i ruoli diversi svolti da ogni server Exchange, compresi Trasporto Edge, Accesso client, Trasporto Hub, Cassetta postale, Messaggistica unificata e Strumenti di gestione.
Il libro passa poi a esaminare la scalabilità, mostrando come monitorare le prestazioni, aggiungere più memoria per la cassetta postale e così via. È possibile esaminare la nuova eccezionale funzionalità Replica continua locale, che consente di tenere aggiornato il backup locale dell'archivio della posta. Se succede qualcosa al database principale, è possibile passare subito al backup senza dover eseguire ripristini da altri backup meno disponibili o aggiornati.
La sezione successiva del libro fornisce panoramiche dettagliate delle diverse attività di gestione e degli strumenti disponibili con una distribuzione di Exchange Server 2007. Sono inclusi strumenti quali Exchange Management Shell (basato su Windows PowerShell™) e la GUI di Exchange Management Console (anch'essa basata sul motore Windows PowerShell). In questa sezione, viene spiegato come gestire le cassette postali, gli elenchi di indirizzi e gli account utente. Sono trattati anche la gestione dei record di messaggistica, la classificazione dei messaggi, il journaling e le regole di trasporto.
La quarta sezione fornisce informazioni più approfondite sulla disponibilità e sull'affidabilità. Questa sezione merita una particolare attenzione vista la dipendenza delle aziende dalla messaggistica elettronica.
Vengono insegnati i fondamenti del bilanciamento del carico, della ridondanza di server, memoria e rete e del clustering. Vengono insegnate in breve le procedure consigliate per la manutenzione pianificata, l'esecuzione di backup e il recupero da disastri, cioè gli argomenti che è necessario conoscere affinché i sistemi di messaggistica elettronica dell'azienda funzionino in modo efficiente anche in caso di problemi.
Le due sezioni successive del libro trattano dell'accesso e di Microsoft Office Outlook® 2007, Outlook Web Access, IMAP e POP3. Il libro si conclude con una sezione, fin troppo importante per l'amministratore Exchange, che riguarda la sicurezza e il controllo, mostrando le pratiche e le precauzioni fondamentali per la sicurezza insieme ai diversi strumenti di controllo a disposizione. Tutto considerato, questa guida approfondita consente di essere subito operativi e di eseguire la distribuzione di Exchange nel modo giusto.
Prezzo: $49.99 (diretto).

Greg Steen è un professionista IT, un imprenditore e un entusiasta. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni, il controllo della qualità e lo sviluppo per i professionisti IT.


Utility Spotlight Microsoft SharedView
Greg Steen

Lavoro spesso con colleghi che vivono dall'altra parte del pianeta e incontro costantemente situazioni in cui, se chiunque potesse consultare e interagire con lo stesso desktop, tutti potremmo illustrare e comunicare le nostre opinioni in modo molto più efficace.
Supponete che il vostro team addetto alle vendite non sia in ufficio e debba riunirsi rapidamente per condividere le informazioni, verificare i preventivi e ridurre le attività di sovrapposizione. Pensate quanto sarebbe più produttivo l'intero processo se tutti i membri del team potessero esaminare e modificare lo stesso foglio di calcolo Microsoft® Office Excel® o documento Word quasi simultaneamente, piuttosto che inviare per posta elettronica un "documento in fase di elaborazione" che potrebbe non essere sempre sincronizzato. Attualmente esiste uno strumento di collaborazione lightweight che offre esattamente tale funzionalità: Microsoft SharedView 1.0.
Microsoft SharedView consente di riunire fino a 15 persone e di condividere contemporaneamente il desktop dell'host di riunione, come se si stesse consultando lo stesso desktop. Il vostro primo pensiero potrebbe essere che, se il controllo dello stesso desktop è affidato contemporaneamente a 15 persone, l'unico risultato plausibile sarebbe il caos, ma in realtà tale controllo del desktop può essere passato da un membro ad un altro.
Mentre voi assumete il controllo, potete esaminare i movimenti del mouse dei vostri collaboratori (tutti dispongono di un puntatore personalizzato), che possono quindi indicare degli elementi in un documento o applicazione. Sfortunatamente, SharedView non dispone di funzionalità audio integrate, ma è possibile utilizzare il client audio di Windows Live™ Messenger o il client VoIP (Voice over IP) per effettuare una conferenza durante la condivisione del desktop.
Microsoft SharedView consente di condividere contemporaneamente il desktop di un host di riunione (fare clic sull'immagine per ingrandirla)
L'installazione di SharedView è semplice e il client è intuitivo al punto che anche gli utenti meno esperti dal punto di vista tecnico possono imparare ad utilizzarlo rapidamente. Dopo avere effettuato l'accesso con il vostro account Windows Live, potete avviare una sessione SharedView con un paio di clic. La partecipazione ad una sessione è molto semplice: è sufficiente immettere il nome della sessione (di solito l'ID Live dell'host) a cui ci si desidera connettere e una password. Gli inviti vengono inviati tramite un messaggio di posta elettronica o incollando il testo di invito generato nel vostro client di MI.
Le altre opzioni di SharedView includono l'abilitazione o disabilitazione del Copia e Incolla remoto (per consentire agli utenti della sessione di aggiungere un testo dalla loro workstation locale al computer dell'host); l'abilitazione diretta delle modifiche di traccia in Word per esaminare le eventuali modifiche apportate al documento condiviso e un elenco di blocchi esplicito per escludere la partecipazione di alcuni ID Windows Live. L'applicazione dispone inoltre di una pratica funzione Stampato che consente di rendere disponibili dei file supplementari per i partecipanti della sessione; è possibile utilizzare fino a 25 file o un totale di 200 MB per sessione.
In più, è possibile immettere messaggi di trasmissione per i partecipanti; tali messaggi verranno visualizzati all'inizio della relativa sessione connessa. Si può scegliere di condividere ogni elemento o, se si preferisce mantenere privati alcuni dati nel corso della riunione, è possibile avviare e arrestare rapidamente e facilmente la condivisione delle finestre dal proprio computer host. In fondo, se cercate uno strumento di collaborazione rapido e semplice, Microsoft SharedView probabilmente farà al caso vostro.
Per iniziare, vi consiglio di continuare a leggere e di scaricare Microsoft SharedView dalla sezione Download di codice del sito Web TechNet Magazine all'indirizzo technetmagazine com.

Greg Steen è un professionista IT, un imprenditore e un entusiasta. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni, il controllo della qualità e lo sviluppo per i professionisti IT.


Inside SharePoint Integrazione delle applicazioni di Microsoft Office
Pav Cherny

Indice
Integrazione delle applicazioni di Microsoft Office
Estensione dell'interfaccia utente di SharePoint
Uso del controllo OpenDocuments di Microsoft Office
Comunicazione con SharePoint
Implementazione di una soluzione OpenControl personalizzata
Conclusioni
Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 si integrano perfettamente con le applicazioni desktop presenti in Microsoft Office System 2007, favorendo la collaborazione su documenti, fogli di calcolo, calendari, informazioni sui contatti e altro ancora. Di fatto, l'integrazione è così perfetta che
si può dire che Office System 2007 sia una piattaforma unificata di soluzioni per l'ufficio.
Questo è un vantaggio straordinario per le organizzazioni che puntano sulla tecnologia Microsoft® Office per incrementare la produttività degli information worker. Tuttavia, le organizzazioni con un portafoglio diversificato di applicazioni di Microsoft Office non possono godere dello stesso livello di interoperabilità immediata. Office System 2007 fornisce le funzionalità di integrazione necessarie, eppure le interfacce e i componenti dispongono solo di una documentazione minima e non funzionano in ogni circostanza. Questo fa sì che per i fornitori di terze parti risulti difficile integrare la tecnologia SharePoint® nelle applicazioni prodotte, mentre è ancora più difficile per i loro clienti assicurare un'esperienza unificata agli information worker.
In questa rubrica, mostrerò come le applicazioni di Microsoft Office possano integrarsi e comunicare con SharePoint e come, in base agli stessi principi, sia possibile integrare con SharePoint le applicazioni non Microsoft. Innanzitutto, però, illustrerò brevemente le impostazioni di configurazione del server, i componenti del lato client e i protocolli di comunicazione utilizzati per ottenere un'integrazione perfetta.
Una volta chiariti questi dettagli, potrò affrontare la discussione dell'integrazione delle applicazioni che non sono dotate di supporto di SharePoint incorporato. In questo contesto, andrò oltre il tradizionale livello che solitamente si concentra sull'implementazione di componenti IFilter per estendere le funzionalità di ricerca e aggiungere le icone personalizzate ai server SharePoint. L'estensione della ricerca e la restituzione dei risultati con le icone appropriate non riescono a produrre un'integrazione completa delle applicazioni; gli utenti potrebbero anche voler aprire i documenti direttamente dall'interfaccia utente di SharePoint.
E questo è il punto in cui la questione si complica. Se nelle workstation non è stato distribuito Microsoft Office, è necessario disporre di un componente lato client che non sia prontamente disponibile. Ma anche se Microsoft Office è stato distribuito, potrebbe accadere che il componente non funzioni in modo affidabile, a seconda della configurazione e della topologia del sito SharePoint.
Per risolvere il problema, ho creato una soluzione personalizzata che consente l'integrazione di qualsiasi applicazione, come ad esempio Blocco note, Adobe Reader o Autodesk AutoCAD, senza i requisiti di distribuzione di Microsoft Office. La soluzione personalizzata spiega anche perché, in alcune situazioni, l'integrazione delle applicazioni basata sui componenti standard di Microsoft Office non riesce. La soluzione, insieme alle istruzioni dettagliate per la distribuzione e la configurazione, si trova nel materiale di accompagnamento di questa rubrica, disponibile nella sezione Code Downloads di questo sito.

Integrazione delle applicazioni di Microsoft Office
Dal punto di vista dell'utente, i menu di SharePoint sembrano funzionare come il menu Start di Microsoft Windows®. La creazione di un nuovo documento in una raccolta documenti è semplice: si fa clic su Nuovo, quindi su Nuovo documento e viene avviato Microsoft Office Word 2007. Anche la modifica di un documento esistente è altrettanto facile: si passa il puntatore del mouse sul nome del documento, si apre il menu a discesa ECB (Edit Control Box), quindi si fa clic su Modifica in Microsoft Office Word. Raramente si pensa che Microsoft Office Word 2007 è stato avviato da una pagina Web tramite JavaScript, che l'applicazione viene eseguita localmente, mentre il documento risiede molto lontano in un database SQL Server® e che esiste un server Web all'interno del percorso di accesso ai dati, come illustrato nella Figura 1.
Figura 1 Lavorare in SharePoint con un documento di Microsoft Office Word (fare clic sull'immagine per ingrandirla)
Malgrado la complessità, l'esperienza dell'utente al lavoro su una workstation Windows in cui è installato Office System 2007 risulta perfetta. Lavorare con i documenti in una raccolta SharePoint è molto simile a lavorare con file locali o file in una condivisione di rete.
Tuttavia in una workstation Windows priva di Microsoft Office 2003 o di Office System 2007, l'interfaccia utente è diversa. Quando si fa clic su Nuovo documento o Modifica in Microsoft Office Word viene soltanto visualizzata una finestra di dialogo che informa che non è disponibile un'applicazione compatibile con Windows SharePoint Services.
Non è certo una sorpresa. Sono diversi i fattori che devono concorrere per fornire all'utente di Microsoft Office quell'esperienza unificata così tanto gradita. Per poter eseguire il rendering dei comandi desiderati nei menu Nuovo ed ECB, SharePoint deve disporre delle informazioni riguardanti i tipi di contenuto presenti nella raccolta documenti. In risposta ai clic del mouse su questi comandi, deve essere eseguito il codice JavaScript per avviare l'applicazione associata, avvalendosi del percorso per il documento. Questa parte non è indipendente dalla configurazione della workstation, dal momento che il codice JavaScript viene eseguito localmente. Inoltre, l'applicazione associata deve comunicare con SharePoint per leggere e, forse, scrivere i file. Per integrare le applicazioni con SharePoint, sono questi gli elementi da riunire.
D'altra parte, le comunicazioni tra SharePoint e il server database è trasparente per l'applicazione, così come lo sono i processi di indicizzazione sul server Web per favorire le ricerche. Per questa ragione, nel presente articolo non mi dilungherò oltre su questi aspetti, consigliando invece la consultazione del pacchetto Microsoft Filter documentato nell'articolo della Microsoft Knowledge Base "How to Register Microsoft Filter Pack with Windows SharePoint Services 3.0", disponibile all'indirizzo support.microsoft.com/kb/946338 (in inglese). A questo punto, concentreremo l'attenzione sull'aggiunta dei comandi, l'implementazione dei componenti lato client necessari e la definizione delle comunicazioni tra le applicazioni.

Estensione dell'interfaccia utente di SharePoint
Sono disponibili moltissime opzioni per estendere la funzionalità e l'interfaccia utente di SharePoint. Per avviare direttamente le applicazioni, è possibile cambiare il progetto dei siti, personalizzare le pagine ASP.NET, sviluppare le web part oppure modificare il codice JavaScript in WSS e MOSS.
Niente impedisce di aprire il file Ows.js in un editor di testo (il file si trova nella cartella COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 nei server front-end di SharePoint) e di cambiare il modo in cui funzionano le funzionalità createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI e DispDocItem. Tuttavia, esiste un metodo migliore che non richiede la modifica della base di codice WSS in modi non supportati: usare le associazioni tra tipi di contenuto e tipi di documento.
Nel mio articolo "Standardizzazione della gestione dei dati con tipi di contenuto personalizzati" (vedere TechNet Magazine, febbraio 2008, disponibile all'indirizzo technet.microsoft.com/magazine/cc194408.aspx), ho spiegato come creare tipi di contenuto globali e specifici del sito per gestire i documenti e altro contenuto negli elenchi e nelle raccolte documenti di SharePoint. Si può anche consultare il foglio di lavoro Content Type.pdf disponibile nel materiale di accompagnamento del presente articolo, in cui viene descritto come creare un nuovo tipo di contenuto per i file txt e associarlo con una raccolta documenti. Il risultato è che diventa possibile selezionare il comando Contenuto testo nel menu Nuovo, allo stesso modo in cui si seleziona il comando Documento per i documenti di Microsoft Office Word (vedere la Figura 2).
Figura 2 Tipo di contenuto personalizzato nell'interfaccia utente di SharePoint (fare clic sull'immagine per ingrandirla)
Anche il menu ECB può essere esteso. Ci si potrebbe aspettare che il menu ECB fosse in grado di riconoscere il tipo di contenuto, ma con la versione corrente di WSS il menu non è implementato in questo modo. Al contrario, si deve registrare il tipo di documento nel file Docicon.xml, che si trova nella cartella %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml in ogni server front-end di SharePoint.
Ad esempio, aggiungendo la seguente associazione al tipo di documento nella sezione <ByExtension> di Docicon.xml, SharePoint visualizzerà il comando Modifica in Blocco note (per ulteriori informazioni, vedere il file Text Content Type.pdf):
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Il parametro Key identifica l'estensione del nome del file, il parametro Value definisce l'icona del documento da visualizzare nell'interfaccia utente, il parametro EditText definisce la stringa che SharePoint aggiunge al comando "Modifica in", mentre il parametro OpenControl specifica il ProgID di un componente COM del lato client. È il ProgID che le funzioni JavaScript di SharePoint passano alla chiamata ActiveXObject (per ulteriori informazioni, vedere Ows.js) per creare un'istanza dell'oggetto COM, che potrà essere l'applicazione stessa oppure un controllo helper che avvia l'applicazione in base al tipo di file associato.
Sito Web di Prodotti e tecnologie SharePoint

  • Sito Web SharePoint Products and Technologies (in inglese)
  • Windows SharePoint Services TechCenter (in inglese)
  • Windows SharePoint Services Developer Center (in inglese)
  • Blog del team Microsoft SharePoint Products and Technologies (in inglese)
Tenere presente che il parametro OpenControl denominato SharePoint.OpenDocuments fa riferimento a un controllo ActiveX® fornito con le versioni più recenti di Microsoft Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Se questo file è già presente nelle workstation e se l'icona specificata per il documento (tramite il parametro Value) si trova nella cartella %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images dei server SharePoint, il lavoro di integrazione richiesto potrebbe già essere a buon punto.
L'SDK di Windows SharePoint Services 3.0 contiene alcune informazioni sulle API del lato client fornite con Office System 2007, incluso il controllo OpenDocuments. Per informazioni, vedere la sezione "Client-Side API Reference" disponibile all'indirizzo msdn2.microsoft.com/ms440037 (in inglese).

Uso del controllo OpenDocuments di Microsoft Office
Il controllo OpenDocuments soddisfa le esigenze più critiche dell'integrazione delle applicazioni, ma richiede Microsoft Office 2003 oppure Office System 2007 e le sue funzionalità sono piuttosto limitate. I comandi presenti nel menu Nuovo potrebbero non funzionare sempre e, a volte, visualizzano notifiche che possono essere fuorvianti.
Come illustrato nella Figura 3, il controllo OpenDocuments informa l'utente che l'applicazione richiesta non è installata correttamente oppure che è impossibile aprire il file modello, ma questo non è vero in nessuno dei due casi. Anche la funzionalità Modifica in presenta dei problemi. Viene visualizzato spesso il secondo messaggio di errore mostrato in primo piano nella Figura 3. Tra i diversi problemi è quello che in assoluto mi affascina di più, perché mette fuori strada anche gli esperti di SharePoint, come spiegherò più avanti.
Figura 3 Messaggi di errore fuorvianti prodotti dal controllo OpenDocuments (fare clic sull'immagine per ingrandirla)
Tuttavia, il controllo OpenDocuments risulta utile negli ambienti in cui su tutte le workstation sono installate versioni recenti di Microsoft Office. Tra l'altro, per fare in modo che agli utenti non sia visualizzato il primo messaggio di errore, è possibile nascondere i tipi di contenuto dal menu Nuovo; a questo scopo, visualizzare le impostazioni della raccolta documenti, fare clic su Modifica ordine pulsante Nuovo e tipo di contenuto predefinito, quindi deselezionare la casella di controllo Visibile di tutti i tipi di contenuto in questione. Inoltre, si può cercare di semplificare al massimo la topologia del sito, al fine di evitare i problemi di comunicazione WebDAV (Web-Based Distributed Authoring and Versioning). Così facendo, si elimina il secondo messaggio di errore.

Comunicazione con SharePoint
Fin qui sono riuscito a estendere l'interfaccia utente di SharePoint e forse avviare un'applicazione tramite il controllo OpenDocuments, ma la mia applicazione ha ancora bisogno di un modo per comunicare con SharePoint per accedere ai dati. Come sempre, SharePoint supporta più metodi per ottenere questo risultato, come ad esempio le Estensioni del server di Microsoft Office FrontPage®, le chiamate RPC (Remote Procedure Call) di WSS, i servizi Web e WebDAV. Di fatto, le applicazioni di Microsoft Office, come ad esempio Word 2007, potrebbero utilizzare uno o tutti questi metodi di comunicazione, a seconda di come si accede a un documento, se tramite le cartelle Web, le unità di rete mappate oppure l'interfaccia utente di SharePoint.
I metodi di comunicazione client/server di SharePoint si basano su HTTP come protocollo sottostante. Ad esempio, FrontPage e le chiamate RPC di WSS utilizzano tutti le richieste HTTP POST e HTTP GET dirette alle estensioni ISAPI residenti nei server SharePoint all'interno della cartella %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI e di tutte le relative sottocartelle.
Una delle estensioni ISAPI più importanti è Owssvr.dll, che implementa, tra l'altro, la funzionalità necessaria per lavorare con gli elenchi e le raccolte documenti. Nella Figura 4 viene mostrata la finestra di dialogo Salva di SharePoint in Office Word 2007 (a sinistra) e in un browser (a destra) aperta direttamente tramite la richiesta URL http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. Le somiglianze tra le due schermate acquisite sono evidenti.
Figura 4 Finestra di dialogo Salva di SharePoint in Office Word 2007 e in Internet Explorer (fare clic sull'immagine per ingrandirla)
Altre estensioni ISAPI importanti sono Author.dll, che implementa FrontPage e le chiamate RPC di WSS per le operazioni di modifica dal lato client (ad esempio, caricamento, ridenominazione ed eliminazione di documenti); Admin.dll per gestire i siti ed eseguire varie altre attività amministrative; Shtml.dll per supportare l'invio di moduli HTML.
In genere è impossibile aggiungere il supporto di FrontPage e delle chiamate RPC di WSS alle applicazioni esistenti, come ad esempio Blocco note o Adobe Reader, senza dover accedere al codice sorgente. Tuttavia, si può fornire la necessaria funzionalità per le comunicazioni utilizzando la funzionalità Web Client di Windows.
SharePoint supporta anche WebDAV attraverso Httpext.dll, che risiede nella cartella %WINDIR%\System32\Inetsrv\, ma continuiamo a rimanere dal lato client. Nei computer che eseguono Windows Server® 2008 o Windows Vista®, la funzionalità Web Client è installata per impostazione predefinita. Un servizio WebClient corrispondente si trova nella applet Servizi in Strumenti di amministrazione del Panello di controllo. In Windows XP e Windows Server 2003, è necessario installare il client Web in modo esplicito. In ogni caso, accertarsi che il servizio WebClient sia avviato e che il tipo Avvio sia impostato su Automatico.
Nella Figura 5 viene mostrata l'architettura del client Web. Il servizio WebClient viene implementato in una DLL in modalità utente (Webclnt.dll) che Gestione controllo servizi carica nel processo host Svchost.exe. Webclnt.dll fornisce l'interfaccia Provider di rete per le operazioni diverse da quelle di I/O (ad esempio, l'autenticazione dell'utente per l'accesso a WebDAV; il montaggio dei siti SharePoint come unità di rete; l'enumerazione di siti, elenchi e raccolte documenti di SharePoint come risorse di rete; la disconnessione delle unità montate).
Figura 5 Architettura del redirector del client WebDav (fare clic sull'immagine per ingrandirla)
Per eseguire questo lavoro, Webclnt.dll comunica con un driver del file system in modalità kernel che fornisce la funzionalità redirector effettiva. Il driver del redirector del client WebDav (Mrxdav.sys) è basato sul sottosistema RDBSS (Redirected Drive Buffering Subsystem), che viene integrato con I/O Manager e altri componenti kernel al fine di fornire i servizi di un file system remoto. Con Mrxdav.sys viene implementata la funzionalità di comunicazione WebDAV per supportare l'accesso a livello di file system ai siti e alle raccolte documenti di SharePoint.
Disporre dell'accesso ai siti e alle raccolte documenti di SharePoint tramite un redirector di rete significa eliminare la necessità del supporto di FrontPage e delle chiamate RPC di WSS nelle applicazioni dell'utente. Le unità di rete possono essere associate alle raccolte documenti (come, ad esempio, net use x: http://wss/doclib/Shared%20Documents) ed è anche possibile accedere alle risorse di SharePoint tramite i percorsi UNC.
L'URL http://wss/doclib/Shared%20Documents è associato a \\wss\doclib\Documenti%20condivisi. Pertanto, sono disponibili diverse scelte per aprire un documento in un'applicazione. Ad esempio, si può aprire un documento in Blocco note con il percorso HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt oppure il percorso UNC \\wss\doclib\Documenti%20condivisi\New%20Text%20Document.txt.
Purtroppo, la funzionalità Web Client evidenzia diversi limiti. Ad esempio, non è possibile accedere alle proprietà personalizzate o alle applicazioni Web che utilizzano porte TCP personalizzate. Anche l'esecuzione del client Web fornito con Windows Vista non riesce se l'utente non dispone dell'accesso a un sito padre nella gerarchia, come spiegato nel file WebDAV Access.pdf (vedere il materiale di accompagnamento).
Il percorso http://sharepoint/HR/Administration/Shared%20Documents/ include un sito principale (ovvero http://sharepoint) che non esiste, eppure senza accesso alla radice il client Web non riesce a stabilire le funzionalità del server Web. Il server Web respinge la richiesta OPTIONS del client Web con il codice di stato 401, indicante che l'accesso non è autorizzato e, di conseguenza, il client Web continua a richiedere le credenziali utente, come illustrato nella Figura 6, anche se l'utente dispone dell'accesso amministrativo alla raccolta di siti SharePoint/HR e a tutti i siti che contiene.
Figura 6 Accesso non riuscito a WebDAV (fare clic sull'immagine per ingrandirla)
Quando si utilizza il controllo OpenDocuments, se il client Web non riesce ad aprire un documento viene visualizzato il messaggio di errore mostrato nella Figura 3. L'applicazione è disponibile e l'associazione al tipo di documento è corretta. Ma è al documento che non è possibile accedere tramite il redirector WebDAV.

Implementazione di una soluzione OpenControl personalizzata
In genere, due sono le opzioni che consentono di risolvere le limitazioni del client Web. Si può attendere che Microsoft fornisca una versione aggiornata del client Web oppure si può implementare una soluzione OpenControl personalizzata in grado di risolvere la situazione corrente. L'implementazione di una soluzione OpenControl personalizzata non è un'impresa da poco, ma elimina la necessità di disporre di Microsoft Office nella workstation, consente di gestire in modo utile i comandi Nuovo e Modifica in, nonché di porre rimedio alle situazioni in cui il client Web non riesce.
Se una qualunque di queste eventualità dovesse risultare interessante, allora è il caso di dare un'occhiata al codice sorgente AppStart incluso nel materiale di accompagnamento. AppStart consente di esporre le interfacce COM di OpenControl in un assembly Microsoft .NET Framework, a cui il codice JavaScript di SharePoint può effettuare una chiamata. Inoltre, il codice sorgente AppStart offre la dimostrazione di uno dei modi di verificare l'accessibilità ai file e di scaricare un file nel computer locale tramite HTTP nel caso in cui l'accesso diretto tramite WebDAV non fosse possibile. Infine, il codice sorgente AppStart risponde al comando Nuovo scaricando nel computer locale il modello associato al tipo di contenuto, di modo che l'utente possa iniziare a lavorare sul documento. I fogli di lavoro Text Content Type.pdf e Adobe Reader Support.pdf descrivono come distribuire la soluzione OpenControl.
Il diagramma contenuto nella Figura 7 mostra l'architettura di AppStart. Il mio componente OpenControl (chiamato Biblioso.dll) espone due interfacce COM identiche che il codice JavaScript di SharePoint chiama per creare nuovi documenti o per aprire documenti esistenti da modificare (Biblioso.AppStart.2 e Biblioso.AppStart.3).
Figura 7 Architettura di AppStart (fare clic sull'immagine per ingrandirla)
Se si apre un documento per modificarlo, Biblioso.dll verifica l'esistenza del file e avvia l'applicazione associata seguendo il percorso al documento, se il file è accessibile direttamente tramite WebDAV. In caso contrario, Biblioso.dll avvia un server COM esterno al processo che, a sua volta, carica OpenDocsUtility.dll per scaricare il file tramite HTTP e avviare l'applicazione seguendo il percorso al documento scaricato.
Il server COM esterno al processo consente alla soluzione di sottrarsi al processo di Internet Explorer®, che limita i download alla cartella dei file temporanei Internet in Modalità protetta. Gli utenti devono poter scaricare i file senza i limiti imposti dalla Modalità protetta e un server COM esterno al processo che funziona come broker di applicazioni fornisce esattamente questa opzione.
Lo sviluppo di server COM esterni al processo non è supportato in .NET, pertanto per questo eseguibile ho preferito C/C++. In C++ ho implementato soltanto il minimo indispensabile, ovvero la finestra di dialogo Salva con nome. Per mantenere la soluzione quanto più semplice possibile e limitare il sovraccarico di sviluppo, ho inserito il codice di download vero e proprio in un assembly .NET (OpenDocsUtility.dll), che successivamente richiamo tramite un'altra interfaccia COM.
Per semplificare la distribuzione, ho aggiunto alla soluzione un progetto di installazione. Tra le altre cose, la routine di installazione registra tutti i componenti COM e scrive le impostazioni specifiche dell'applicazione in HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. I parametri più importanti sono AllowedApps e AllowedFileTypes. La soluzione AppStart funziona soltanto con le applicazioni e i tipi di file che devono essere specificati esplicitamente in questi parametri.
Inoltre, la routine di installazione crea un criterio di elevazione per il server COM esterno al processo, di modo che Biblioso.dll nel processo di Internet Explorer possa avviare AppBrokerEngine.exe senza attivare avvisi di protezione. Per ulteriori informazioni sulla Modalità protetta di Internet Explorer e sul modo di gestirla durante lo sviluppo delle applicazioni, consiglio vivamente di leggere l'articolo di Marc Silbey e Peter Brundrett "Understanding and Working in Protected Mode Internet Explorer", disponibile all'indirizzo msdn2.microsoft.com/bb250462 (in inglese).
Quando si prendono in esame i componenti di AppStart, tenere presente che questa soluzione è stata sviluppata soltanto per mostrare ciò che è possibile fare, pertanto non è ancora pronta per gli ambienti di produzione. Non c'è stato il tempo sufficiente per ottimizzare il codice e testare a fondo la soluzione oppure per documentarne le funzionalità, a parte i commenti del codice sorgente.
L'utilizzo della soluzione è perciò completamente sotto la responsabilità dell'utente. Per chi fosse interessato a studiare il codice sorgente per creare una soluzione personale, il consiglio è di iniziare con AppStart.cs nel progetto di codice Biblioso. È un file che implementa l'interfaccia COM di OpenControl e i punti di ingresso delle chiamate JavaScript da Ows.js.
Conclusioni
WSS 3.0 e MOSS 2007 forniscono ampie funzionalità di integrazione delle applicazioni capaci di creare un'esperienza utente perfetta quando si lavora con documenti e altri elementi negli elenchi e nelle raccolte documenti di SharePoint. Le applicazioni desktop in Office System 2007 ne sono una dimostrazione lampante ed è possibile raggiungere lo stesso livello di integrazione e usabilità anche con applicazioni non contenute in Office.
Il nucleo dell'architettura dell'integrazione delle applicazioni è costituito dai componenti COM, utilizzati dalle funzioni JavaScript di SharePoint per avviare l'applicazione, seguendo il percorso dei documenti. Office System 2007 fornisce alcuni di questi componenti COM, ottimizzati per esigenze specifiche delle applicazioni di Microsoft Office, sebbene sia possibile anche riutilizzare il controllo OpenDocuments di Office per integrare applicazioni non Microsoft. Il controllo OpenDocuments riesce a soddisfare le esigenze più elementari. In caso di requisiti più avanzati per l'integrazione delle applicazioni, occorre implementare un controllo personalizzato.
L'integrazione completa di un'applicazione con SharePoint comporta non solo l'installazione di componenti IFilter e di icone dei documenti per estendere le funzionalità di ricerca e visualizzazione, ma anche la creazione di tipi di contenuto e di associazioni a tipi di documento personalizzati nei server SharePoint, così da fornire gli appositi comandi Nuovo e Modifica in nell'interfaccia utente di SharePoint. Questi comandi chiamano funzioni JavaScript che richiamano metodi esposti attraverso un componente OpenControl, il quale deve essere anch'esso disponibile nella workstation.
Un'altra tessera importante del puzzle è rappresentata dal client Web, incluso e installato per impostazione predefinita in Windows Vista. Il client Web implementa un redirector WebDAV e un driver di file system remoto, di modo che tutte le applicazioni possano accedere alle risorse presenti negli elenchi e nelle raccolte documenti di SharePoint, analogamente a quanto avviene con le condivisioni file nella rete. Sebbene presenti degli inconvenienti, il client Web fornito con Windows Vista è un capitolo fondamentale della storia dell'integrazione delle applicazioni.
Anche il supporto di WebDAV colma il divario tra le applicazioni eseguite in workstation non Windows e SharePoint. In genere, la tecnologia dei controlli COM e ActiveX non è disponibile in questi sistemi operativi, pertanto non è possibile avviare automaticamente le applicazioni. Tuttavia, la maggior parte dei sistemi operativi include redirector WebDAV che consentono agli utenti almeno di accedere direttamente ai documenti contenuti nelle raccolte documenti senza dover ricorrere al download dei file nelle workstation locali.
WSS 3.0 e MOSS 2007 sono due capisaldi della storia del successo di Office System 2007 e gli utenti di applicazioni di terze parti basate su Microsoft Office possono sfruttare i vantaggi offerti da SharePoint allo stesso modo. Le funzionalità di integrazione vanno ben oltre Microsoft Office. Sfruttando al meglio SharePoint, è possibile creare una piattaforma unificata di soluzioni per l'ufficio capace di offrire la medesima esperienza utente sia per il software di Microsoft Office che per quello di terze parti, con il conseguente aumento della produttività degli information worker.

Pav Cherny è un esperto e un autore in materia di IT, 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, un'azienda specializzata in servizi di localizzazione e documentazione gestita.

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


Windows PowerShell La scatola delle palline da ping-pong
Don Jones

Indice
Impersonare il cmdlet
La funzione di filtro
Pensare in termini di oggetti fisici
Applicazioni pratiche
Trovare il tempo per giocare
In una delle ultime lezioni su Windows PowerShell che ho tenuto, alcuni degli studenti hanno avuto serie difficoltà a raffigurarsi la pipeline della shell. Riconosco che il concetto di pipeline non è del tutto intuitivo, pertanto può risultare alquanto difficile immaginare cosa faccia esattamente la pipeline. Quando sono passato al
concetto di funzioni di filtro, che operano direttamente nella pipeline, le cose sono peggiorate e ho potuto leggere lo smarrimento totale nei visi degli studenti.
Per aiutarli, il giorno dopo ho mostrato una scatola, alcune etichette adesive e alcune palline da ping-pong (nessuno può dire che Windows PowerShell® non è divertente). Avevo deciso di fare una dimostrazione usando la riga di comando seguente:
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

Impersonare il cmdlet
Usando etichette adesive da attaccare agli abiti, ho assegnato un nome cmdlet a ogni studente. Ho spiegato che le palline da ping-pong rappresentavano oggetti processo di Windows® (più nello specifico, oggetti di tipo System.Diagnostics.Process), quindi ho chiesto agli studenti di indicarmi quale nome cmdlet suonava come il più adatto a generare oggetti processo.
Guardandosi intorno, hanno concordato sulla scelta ovvia di Get-Process. Questo spiega una delle ragioni principali per cui apprezzo i nomi cmdlet usati in Windows PowerShell: sono davvero molto intuitivi.
Così lo studente che rappresentava Get-Process ha afferrato tutte le palline da ping-pong e le ha tirate nella scatola di cartone. La scatola rappresentava la pipeline della shell e quello che hanno fatto gli studenti non è stato altro che quello che fa un cmdlet. Un cmdlet genera uno o più oggetti e poi li lancia nella pipeline.
Il prossimo cmdlet nella pipeline prende il comando. In questo esempio, lo studente che rappresentava il cmdlet Where-Object ha preso tutte le palline da ping-pong e le ha esaminate tutte, una alla volta, per vedere se la proprietà VM di una pallina era maggiore di 1.000. Nella shell, "VM" indica la memoria virtuale e per questo esercizio avevo scritto col pennarello le varie quantità di memoria virtuale su ogni pallina.
Ogni pallina (altrimenti detta processo) che aveva una VM maggiore o uguale a 1.000 tornava nella scatola (talvolta chiamata pipeline), mentre tutte quelle con un valore inferiore venivano buttate definitivamente nel cestino (in realtà non è vero perché le ho recuperate per usarle in altre lezioni).
Quindi, lo studente che rappresentava Sort-Object ha messo in ordine le palline da ping-pong nella scatola in base alla proprietà VM. Devo ammettere che questa parte dell'esercizio era quella meno studiata: tenere ferme le palline è stato alquanto difficile! Sembra che dovrò trovare palline da ping-pong di forma cubica per la prossima lezione o quei pratici cartoni per le uova.
Infine, lo studente che rappresentava Export-CSV ha preso le palline e ha scritto le informazioni in un file CSV. In pratica, ciò si è tradotto nello scrivere le proprietà del processo su una lavagna a fogli che abbiamo fatto finta fosse un file CSV.

La funzione di filtro
Dopo aver visto una semplice pipeline, abbiamo deciso di esaminare le funzioni di filtro che sono un poco più complicate. Ho proposto la funzione di filtro e la riga di comando mostrate nella Figura 1.
Figura 1 Esempio di funzione di filtro e riga di comando
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
Innanzitutto voglio dare un rapido sguardo a cosa ci si aspetta che facciano le funzioni di filtro. L'idea di fondo è che la funzione contenga tre blocchi di script, chiamati BEGIN, PROCESS e END.
Quando la funzione viene usata nella pipeline, viene eseguito per primo il blocco di script BEGIN. Lo script potrebbe fare qualsiasi attività di impostazione come, ad esempio, aprire una connessione con il database.
Quindi viene eseguito il blocco di script PROCESS una volta per ogni oggetto che era stato inserito nella pipeline della funzione. Nel blocco di script PROCESS, la variabile $_ viene automaticamente riempita con l'oggetto della pipeline corrente. Pertanto, se nella pipeline ci sono 10 oggetti, il blocco di script PROCESS viene eseguito 10 volte.
Infine, dopo che sono stati eseguiti tutti gli oggetti nella pipeline, viene eseguito il blocco di script END che compie tutte le attività di pulizia necessarie, come la chiusura della connessione con un database.
All'interno di questi blocchi di script, tutto quello che viene scritto usando Write-Output si risolve nella pipeline per il prossimo cmdlet. Tutto quello che non è scritto usando Write-Output viene eliminato.
Poiché il nostro comando cominciava con Get-Process, uno degli studenti ha raccolto tutte le palline da ping-pong (abbiamo fatto una breve pausa e in qualche modo le palline sono state allegramente lanciate per tutta la stanza, vedere la figura) e le ha fatte cadere nella scatola della pipeline. Terminato il suo compito, è toccato allo studente che rappresentava la funzione di filtro "Do-Something".
Prima ha eseguito il blocco di script BEGIN. Essendo vuoto, non ha richiesto molta fatica. Quindi ha afferrato tutti gli oggetti della pipeline (le palline da ping-pong) e ha iniziato a guardarli una alla volta. È stato divertente, perché c'erano circa una dozzina di palline e lui cercava di tenerle tutte in grembo!
Ad ogni modo, ha preso un oggetto processo alla volta e ha eseguito il relativo blocco di script PROCESS. Questo blocco di script gli ha fatto creare un oggetto del tutto nuovo (a questo scopo ho usato speciali palline da ping-pong gialle, che possono essere reperite in un negozio di articoli sportivi). Su queste nuove palline, lo studente ha scritto la data e l'ora corrente insieme al nome dell'oggetto processo che stava esaminando al momento.
Questo nuovo oggetto personalizzato è stato scritto poi nella pipeline, cioè lo studente ha messo la pallina da ping-pong gialla nella scatola ed è stata eliminata la pallina dell'oggetto processo originale. Lo studente ha fatto questa operazione per ogni pallina da ping-pong che stava nella scatola, circa 12 in totale. Al termine, ogni pallina da ping-pong bianca è stata sostituita da una pallina gialla relativa a un oggetto personalizzato. Infine, lo studente ha eseguito il proprio blocco di script END che, essendo vuoto, non ha richiesto nemmeno un minuto.
Per concludere, è toccato alla studentessa "Format-Table". Ha preso tutto il contenuto della scatola, che a questo punto erano tutti gli oggetti "personalizzati" gialli, e ha iniziato a costruire una tabella usando entrambe le proprietà scritte su ogni palla. Il risultato è stato una tabella, scritta sulla nostra lavagna a fogli, con due colonne, TimeStamp e ProcessName, e una dozzina circa di righe.

Pensare in termini di oggetti fisici
Grazie a questo esercizio, la pipeline e le funzioni di filtro sono diventate familiari a tutta la classe. Le palline da ping-pong hanno avuto un ruolo decisivo nel rappresentare gli oggetti, ovvero qualcosa che tende a essere astratta quando si parla semplicemente di shell.
Ognuno ha potuto vedere come i cmdlet manipolavano questi oggetti, come i risultati venivano inseriti nella pipeline e come il cmdlet successivo prendeva questi risultati e manipolava ulteriormente gli oggetti. La sequenza di eventi in una funzione di filtro è sembrata più ovvia, come lo è stata la tecnica del blocco di script PROCESS di lavorare con un oggetto di input alla volta.
Ciò ha mostrato anche i mezzi con cui è possibile creare un nuovo oggetto personalizzato e inserirlo nella pipeline. Inoltre, ha aiutato a evidenziare i vantaggi di produrre oggetti personalizzati invece di semplice testo: altri cmdlet, come Format-Table, hanno potuto elaborare i nuovi oggetti personalizzati, mostrando una grande flessibilità nel modo in cui è stato possibile usare e manipolare i dati.

Applicazioni pratiche
La domanda ovvia posta dagli studenti era come fosse possibile usare la pipeline e queste funzioni di filtro in applicazioni pratiche. Per me è stato facile rispondere, in quanto ho prodotto diversi esempi di una recente conferenza, che è possibile scaricare all'indirizzo scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples (in inglese).
Un esempio ha l'obiettivo di elencare diverse proprietà dalla classe Win32_UserAccount in WMI (Windows Management Instrumentation) da diversi computer. Presupponendo che questi nomi di computer siano elencati in C:\Computers.txt, questo semplice comando farà il lavoro:
Gwmi win32_useraccount –comp (gc c:\computers.txt)
Il problema è che la classe Win32_UserAccount non include una proprietà che indica da quale computer proviene ogni istanza, pertanto l'elenco ottenuto sarà un inutile miscuglio di account di molti computer. Risolvo il problema creando un nuovo oggetto personalizzato che include il nome del computer di origine e seleziona le proprietà della classe che mi interessano. Il codice per questo oggetto personalizzato è mostrato nella Figura 2.
Figura 2 Uso di un oggetto personalizzato per raccogliere i nomi dei computer e selezionare le proprietà
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
La riga di comando finale passa tutti i nomi dei computer alla funzione di filtro, producendo oggetti personalizzati. Successivamente filtro tutti gli utenti tranne quelli la cui proprietà PasswordRequired è False (l'intento è generare un rapporto di controllo degli account problematici). Quindi tengo semplicemente le proprietà Computer e Name in modo che il rapporto finale sia un elenco di nomi di computer e nomi di account che richiedono attenzione in quanto hanno password senza scadenza. La funzione di filtro consente la creazione di questo rapporto di più computer perché aggiunge il nome del computer di origine all'output lasciando solo le proprietà che mi interessa vedere.
Sebbene ci siano altri modi simili per compiere questa attività, questo approccio forse è il più semplice. Serve anche a illustrare concetti e tecniche importanti.

Trovare il tempo per giocare
Anche se si conosce la pipeline, pensare in termini di oggetti fisici può aiutare a immaginarsi cosa si sta cercando di fare.
Pertanto, la prossima volta che ci si trova in difficoltà con un concetto di Windows PowerShell, provare ad allontanarsi dal computer e a replicare l'attività usando oggetti d'uso quotidiano. Consiglio umilmente di tenere sempre a disposizione un sacchetto di palline da ping-pong (o di cubetti se non si riesce a trovarle) proprio per questo scopo.
Cmdlet del mese: Out-File
Quante volte l'output di un cmdlet è stato indirizzato a un file usando il simbolo >? Qualcosa di simile a Get-Process > Processes.txt. Quanti sono a conoscenza del fatto che stanno usando proprio il cmdlet Out-File sotto mentite spoglie? Ecco un comando che esegue esattamente la stessa funzione: Get-Process | Out-File Processes.txt.
Naturalmente richiede un po' più di digitazione, pertanto perché preoccuparsi di digitare per intero il cmdlet Out-File? Un motivo è che Out-File risulta molto più chiaro da leggere. Qualcuno che arrivasse tra sei mesi, ad esempio, potrebbe guardare questo script e chiedersi cosa rappresenti il simbolo > (dopo tutto è una specie di retaggio del passato).
Al contrario, con Out-File sembra piuttosto ovvio che si sta creando un file in cui verrà scritto l'output. Inoltre, Out-File prevede il parametro -append (molto simile a >>), insieme ai parametri -force e -noClobber, e quindi consente di controllare se i file esistenti vengono sovrascritti. Infine, digitando Out-File si ha accesso anche al parametro -whatif. Questo comodo parametro mostra cosa farà Out-File senza farlo nella realtà. Si tratta di un metodo eccezionale per verificare una riga di comando complicata con poco o nessun pericolo.
Video
Osserviamo come Don Jones mette in pratica i cmdlet.

Don Jones è coautore di Windows PowerShell: TFM e insegna Windows PowerShell (www.ScriptingTraining.com).


Hey, Scripting Guy! La scarica di adrenalina
Microsoft Scripting Guys

Nella nostra testa non c'è dubbio che scrivere per TechNet Magazine sia il lavoro più prestigioso e gratificante che si possa fare. (Naturalmente, sarebbe ancora più gratificante se venissimo veramente pagati, ma questa è tutta un'altra storia). Quanto può essere prestigioso questo lavoro? Mettiamola così: proprio in questo momento, in tutto il mondo, i bambini che stanno andando a letto guardano la mamma che rincalza le loro coperte e le dicono, "Mamma, da grande voglio scrivere per una rubrica mensile di scripting su TechNet Magazine".
Nota Inutile dire che, in tutto il mondo, ci sono persone che pensano che la rubrica sia già tenuta da bambini. Ma anche questa è tutta un'altra storia.
Ormai tutti sanno che gli Scripting Guy amano crogiolarsi nell'ammirazione che deriva dallo scrivere per TechNet Magazine; abbiamo persino imparato a sopportare i paparazzi e i cacciatori di autografi. Ma la verità è che non facciamo questo lavoro per l'onore e la gloria. Lo facciamo per la scarica di adrenalina pura che accompagna la scrittura degli script di amministrazione del sistema.
Certo, non capita spesso di vedere le espressioni "scarica di adrenalina pura" e "script di amministrazione del sistema" nella stessa frase. (A meno che, ovviamente, la scarica di adrenalina pura non sia preceduta da una sua assenza assoluta).
Le persone comuni possono considerare la scrittura di script di amministrazione del sistema estremamente utile, ma difficilmente la riterranno un'attività entusiasmante. Al contrario, la riterranno con ogni probabilità una cosa abbastanza noiosa. E il motivo è questo: queste persone non hanno mai provato a scrivere script per i dati di configurazione di avvio in Windows Vista® o Windows Server® 2008.
Saperlo non vi ha fatto aumentare le pulsazioni di uno o due battiti? Come sapranno molti di quelli che stanno leggendo questo articolo, in Windows Vista e Windows Server 2008, il vecchio file boot.ini è stato messo da parte a favore di un nuovo archivio dati di configurazione di avvio che, quando si tratta di gestire il processo di avvio, assicura maggiore flessibilità (e funzionalità).
È tutto molto bello. Ma quello che fa davvero la differenza è che grazie al nuovo provider di Strumentazione gestione Windows® (WMI), tramite gli script oggi è possibile accedere e gestire completamente l'archivio dati di configurazione di avvio (BCD).
Non bisogna preoccuparsi troppo di quella sensazione di formicolio che ha appena passeggiato su e giù lungo la schiena: quello è esattamente il sintomo prodotto da una scarica di adrenalina pura. Basta iniziare a lavorare con gli script BCD e ci si fa presto l'abitudine.
Prima di continuare, ci corre l'obbligo di avvertire che nello spazio di questa rubrica non riusciremo a fare altro che iniziare appena ad accennare a tutto ciò che è possibile fare utilizzando il provider BCD. (A dire il vero, abbiamo inviato alla redazione della rivista un messaggio di posta elettronica in cui chiedevamo se fosse possibile pubblicare un numero doppio speciale interamente dedicato alla scrittura di script per i dati di configurazione di avvio, ma ancora non ci hanno risposto).
Per ottenere informazioni più esaustive, consigliamo di consultare la documentazione relativa al provider WMI di BCD disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=116953 (in inglese). Nel frattempo, abbiamo pensato di proporre alcuni esempi di codice progettati per computer ad avvio multiplo, ovvero computer in cui è installato più di un sistema operativo.
Sono script che funzionano soltanto in Windows Vista e Windows Server 2008. Questo perché, come ricordato prima, sono gli unici due sistemi operativi che attualmente supportano i BCD.
Iniziamo col dare un'occhiata a uno script che indica quale sistema operativo è al momento utilizzato in un computer. Di certo non si tratta dell'uso più entusiasmante che si possa fare del provider BCD; dopo tutto, possiamo già utilizzare la classe WMI Win32_OperatingSystem per stabilire quale sia il sistema operativo attualmente in uso in un computer. Tuttavia, questo è uno script abbastanza semplice (almeno in fatto di script BCD), che offre un buon modo per descrivere le tecniche necessarie quando si lavora con i BCD. (Tecniche che, a dire il vero, sono un tantino … insolite).
D'altra parte, la nostra rubrica non può trattare temi che suscitano troppe emozioni: TechNet Magazine ha già avvertito che ci ritiene responsabili di tutti i danni provocati dai fan sovraeccitati e troppo zelanti di Hey, Scripting Guy! Considerando il marasma generale esploso nel mondo a seguito della nostra rubrica sulle espressioni regolari, non possiamo proprio permetterci di scrivere di nuovo cose altrettanto destabilizzanti.
Nota Qualcuno ricorda quei filmati in cui si vedono i Beatles assaliti dai loro fan e tutte quelle immagini di ragazze che svenivano e piangevano ogni volta che John, Paul, George e Ringo si facevano vedere? Più o meno è quello che succede a noi ogni volta che pubblichiamo una nuova rubrica.
OK, d'accordo, forse è un'esagerazione. Ma non c'è dubbio che molte persone, sia uomini che donne, iniziano a singhiozzare dopo aver letto uno dei nostri articoli.
Ad ogni modo, diamo uno sguardo allo script mostrato nella Figura 1, in cui il provider BCD viene utilizzato per stabilire quale sistema operativo sia al momento usato in un computer. Prima di tentare di eseguire lo script, è bene sapere che deve essere attiva l'esecuzione come amministratore, altrimenti lo script non riesce.
Figura 1 Individuazione del sistema operativo corrente
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
Questo non significa che si deve soltanto eseguire l'accesso a un account con privilegi di amministratore. Significa che è necessario aprire una finestra del prompt dei comandi facendo clic con il pulsante destro del mouse su Prompt dei comandi nel menu Start e selezionando Esegui come amministratore. Solo a questo punto si può eseguire lo script dal prompt dei comandi.
Come funziona lo script? Temevamo che qualcuno ce l'avrebbe chiesto. Ma va bene lo stesso, tenteremo di spiegarlo meglio che possiamo (cosa che, se non altro, dovrebbe riuscire a tenere a bada l'emozione, almeno per un po').
Iniziamo con la definizione di due costanti: BcdLibraryString_Description e Current. BcdLibraryString_Description fa riferimento all'oggetto da recuperare; in questo caso, l'oggetto contiene la proprietà Description (il nome) del sistema operativo corrente.
Per inciso, questa è una delle simpatiche stravaganze prodotte dal lavoro con il provider BCD. In genere, non si recupera soltanto il valore di una proprietà; al contrario, si usa uno dei valori delle costanti (e il metodo GetElement) per recuperare un altro oggetto, quindi si restituisce il valore di una proprietà che appartiene all'oggetto. È di certo un po' sciocco, ma sapete come si dice: arrivare è la metà del divertimento.
Nota Cosa che comunque ti fa chiedere dove stessero andando, no?
Quanto alla costante Current, si tratta soltanto di un GUID che rappresenta il sistema operativo utilizzato al momento. Il valore
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
viene considerato un GUID "noto a tutti" (cosa che, se non altro, prova che le persone che lavorano in Microsoft sono davvero dotate di senso dell'umorismo).
Benché si tratti di un GUID noto a tutti, siamo andati avanti e ne abbiamo comunque incluso il valore, nel caso in cui qualcuno dei nostri lettori avesse problemi nel ricordare quale dei due valori seguenti è quello corretto:
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
Nota In caso qualcuno si ponesse il quesito, GUID può essere pronunciato sia "gwid" sia "guu-aidi". Possiamo dire di più, come il fatto che il GUID di cui sopra deve essere un GUID V1, visto che il terzo gruppo di cifre inizia con 4. Ma abbiamo promesso di non esagerare con le emozioni. E noi le promesse le manteniamo.
Come si può immaginare, quando si lavora con il provider BCD è necessario utilizzare costanti, valori esadecimali e GUID praticamente ovunque. Non possiamo trattare tutti questi argomenti nella rubrica di questo mese, ma per un approfondimento consigliamo la consultazione della pagina di MSDN® sui BCD già citata in precedenza (disponibile all'indirizzo go.microsoft.com/fwlink/?LinkId=116953, in inglese). Questo sempre che riusciate a sopportare le emozioni forti.
Dopo aver definito le due costanti, stabiliamo la connessione al servizio WMI nel computer locale. Si può utilizzare lo script per recuperare i dati configurazione di avvio di un computer remoto? Certo che si può.
A dire il vero, se la cosa non fosse possibile questo affare dei BCD non varrebbe granché. Per recuperare i dati configurazione di avvio di un computer remoto (nel quale, ripetiamo, devono essere installati Windows Vista o Windows Server 2008), è sufficiente assegnare il nome del computer alla variabile strComputer:
strComputer = "atl-fs-001"
Vale anche la pena sottolineare un paio di elementi fondamentali nella stringa di connessione a WMI. Per prima cosa, qualcuno avrà notato che nella stringa di connessione sono stati inclusi i privilegi Backup e Restore; questo è ciò che avviene con la costruzione {(Backup,Restore)}. È qualcosa di importante? Per chi vuole che lo script funzioni è una cosa molto importante: se i due privilegi non vengono esplicitamente inclusi, lo script non riesce.
Secondo, notare che non è stato connesso lo spazio dei nomi root\cimv2, ovvero lo spazio dei nomi più comunemente utilizzato negli script di amministrazione del sistema. Piuttosto, abbiamo stabilito la connessione allo spazio dei nomi root\WMI e l'associazione direttamente alla classe BCDStore. Ecco a cosa serve questa parte di codice:
"\root\wmi:BcdStore"
E no, la parte emozionante non era questa; quella deve ancora venire.
Sebbene da qualche parte potrebbero esserci una o due eccezioni, nella maggior parte dei casi uno script BCD viene avviato con gli stessi tre passaggi: definizione delle costanti, definizione della connessione al servizio WMI e quindi apertura dell'archivio BCD. I Passaggi 1 e 2 li abbiamo già completati e la seguente riga di codice si occupa del Passaggio 3:
objStoreClass.OpenStore "", objStore
Come già detto, qui viene aperto l'archivio BCD, ovvero l'entità del sistema operativo in cui sono archiviate tutte le informazioni sulla configurazione di avvio. Per aprire l'archivio è sufficiente chiamare il metodo OpenStore, passando al metodo due parametri:
  • una stringa vuota (""), che serve per indicare allo script che vogliamo aprire l'archivio predefinito;
  • objStore. Si tratta di un parametro "esterno" che forniamo allo script. Diamo al metodo il nome di una variabile e, come segno di gratitudine, il metodo restituisce un oggetto (in questo caso, un oggetto che rappresenta l'archivio BCD) che utilizza il nome della variabile come riferimento a un oggetto.
Non appena l'archivio è aperto, possiamo utilizzare il metodo OpenObject per recuperare un altro oggetto ancora (archiviato nel parametro esterno objDefault):
objStore.OpenObject Current, objDefault
Qual è questo nuovo oggetto? Proprio così: è il sistema operativo attualmente in uso. Questo lo sappiamo perché abbiamo passato a OpenObject la costante Current, il GUID noto a tutti che rappresenta il sistema operativo corrente.
OK, ora sappiamo qual è il sistema operativo attualmente in uso nel computer, giusto? Quasi, non proprio. Per ottenere quella informazione, dobbiamo ancora utilizzare GetElement per recuperare un oggetto che rappresenti la proprietà Description del sistema operativo:
objDefault.GetElement _
  BcdLibraryString_Description, objElement
Ora, promettete di non esaltarvi troppo e di non lasciarvi andare a qualche genere di scorribanda collettiva? Bene. In tal caso, è tempo di rivelare che possiamo definire la restituzione del valore della proprietà String e, finalmente, stabilire qual è il sistema operativo attualmente in uso nel computer:
Wscript.Echo "Current operating system: " _
  & objElement.String
Per favore, bisogna rimanere calmi. E ricordare le promesse: niente scorribande collettive. Sì, lo sappiamo che è difficile, ma bisogna provarci lo stesso. Ad esempio respirando profondamente: è un sistema che con noi funziona sempre quando scriviamo gli script BCD.
Come già detto, si tratta di un'attività di scrittura complessa soltanto per stabilire il sistema operativo attualmente in uso in un computer; ci sono senz'altro modi più facili per raggiungere lo stesso risultato. Tuttavia, il lato positivo della questione è che abbiamo avuto occasione di chiarire il funzionamento di uno script BCD. Il che significa che i lettori ora possono fare alcune cose che gli autori di script non hanno mai potuto fare. (Calma, bisogna continuare a mantenere la calma). Ad esempio, in un computer ad avvio multiplo, uno dei sistemi operativi è sempre etichettato come quello "predefinito"; perciò, in caso di riavvio, se nessuno indica al computer un'azione diversa verrà caricato automaticamente il sistema operativo predefinito. Prima di Windows Vista (e del provider BCD), un autore di script non aveva modo di stabilire il sistema operativo predefinito di un computer. Oggi, invece, per farlo è sufficiente eseguire uno script come quello mostrato nella Figura 2.
Figura 2 Determinazione del sistema operativo predefinito
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
È vero: questo è un motivo sufficiente per una piccola scorribanda collettiva. Va bene, ma solo un po', OK? Stavolta non scenderemo troppo nei dettagli per illustrare questo script; partendo dal presupposto che nessuna parte dei precedenti 10 o 12 paragrafi sia stata ignorata, non dovrebbe essere impossibile seguire la logica che lo caratterizza. Si noterà, tuttavia, che per ottenere il sistema operativo predefinito dobbiamo avvalerci di un passaggio intermedio: dobbiamo utilizzare il metodo OpenObject per aprire un'istanza dell'oggetto Boot Manager. Una volta aperto Boot Manager, possiamo utilizzare la costante DefaultType per recuperare un oggetto che rappresenti il sistema operativo predefinito.
E questo, bisogna ammetterlo, è abbastanza emozionante: possiamo determinare il sistema operativo corrente e possiamo anche determinare il sistema operativo predefinito. Ma la cosa più bella di tutte sarebbe recuperare un elenco di tutti i sistemi operativi installati in un computer. Quello sì che sarebbe emozionante! Allora, è tempo di allacciare le cinture di sicurezza e osservare la Figura 3.
Cosa stiamo facendo? Tanto per iniziare, stiamo definendo due costanti nuove: WindowsImages, che consente di recuperare le istanze di tutti i sistemi operativi che supportano i BCD (cioè, Windows Vista and Windows e 2008); e LegacyImages, che consente di recuperare le istanze di tutti i sistemi operativi "legacy" presenti nel computer. Dopo la connessione all'archivio BCD, utilizziamo il metodo EnumerateObjects per recuperare tutte le istanze dei sistemi operativi dotati di supporto dei BCD installati nel computer:
objStore.EnumerateObjects _
  WindowsImages, colObjects
Figura 3 Rilevamento di tutti i sistemi operativi in un computer
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Una volta che EnumerateObjects ha completato il suo lavoro, impostiamo un ciclo For Each per scandire tutti i sistemi operativi presenti nella raccolta. All'interno del ciclo utilizziamo le due righe di codice seguenti per recuperare e visualizzare la proprietà Description del sistema operativo:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
Quindi ripetiamo il processo con tutti i sistemi operativi legacy installati nel computer:
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Nota Capiamo bene l'eccitazione che questo comporta, ma si devono eseguire gli script BCD con prudenza; con ogni probabilità esiste solo un determinato numero di scariche di adrenalina che il corpo umano può sopportare. Le donne incinta, o che possono rimanere incinta, o che non potrebbero mai rimanere incinta, o che una volta sono rimaste incinta, o che in fondo non sono neanche donne perché di fatto sono uomini non dovrebbero eseguire gli script BCD senza prima consultare il proprio medico curante.
Va bene, d'accordo, si può fare a meno di consultare il medico. Però sarebbe interessante sapere che ne pensa un medico a proposito dell'esecuzione degli script BCD. O no?
Ora cercheremo di fare qualcosa di veramente pazzo: vediamo se riusciamo a modificare il sistema operativo predefinito. Ad esempio, supponiamo di avere un computer ad avvio doppio in cui sono installati sia Windows Vista che Windows Server 2008. E supponiamo di voler impostare Windows Vista come sistema operativo predefinito. Come si fa? Basta osservare la Figura 4, in cui viene mostrato come eseguire questa attività.
Figura 4 Modifica del sistema operativo predefinito
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
Con questo script apriamo di nuovo l'archivio BCD, quindi utilizziamo EnumerateObjects per recuperare una raccolta di tutti i sistemi operativi che riconoscono i BCD installati nel computer. A quel punto, impostiamo un ciclo For Each per scandire tutti gli elementi della raccolta, utilizzando la riga di codice seguente (e ormai familiare) per recuperare la proprietà Description di ciascun sistema operativo:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Non appena disponiamo del nome di un dato sistema operativo, utilizziamo la funzione InStr per vedere se all'interno del valore compare la parola Vista:
If Instr(objElement.String, "Vista") Then
È vero, sembra un po' goffo. Il modo elegante sarebbe quello di utilizzare il GUID di Windows Vista per poi aprirne direttamente il sistema operativo, senza dover enumerare e scandire tutti i sistemi operativi nel computer.
Purtroppo, il modo elegante richiede la conoscenza del GUID di Windows Vista. Invece, in questo modo non è necessario sapere niente (cosa sempre gradita agli Scripting Guy); tutto ciò che dobbiamo fare è continuare a cercare fino a trovare un sistema operativo contenente la parola Vista nel titolo.
Nota Che fare se nel computer sono installate più istanze di Windows Vista? In quel caso, sarà necessario cercare stringhe come Vista Ultimate o Vista Enterprise.
Non appena troviamo Windows Vista, utilizziamo le due righe di codice seguenti per aprire Windows Boot Manager e impostare il sistema operativo predefinito su Windows Vista, appunto:
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
È finito il tempo a disposizione, per questo mese. Dopo tutto, neanche gli Scripting Guy riescono a sopportare le emozioni continue, 24 al giorno per 7 giorni la settimana. Ma non c'è da preoccuparsi: torneremo il mese prossimo con una nuova esaltante puntata di Hey, Scripting Guy! Con un po' di fortuna, per allora tutti si saranno ripresi.
Il rompicapo di script del Dottor Scripto
La sfida mensile che verifica non solo l'abilità nella risoluzione dei puzzle, ma anche le competenze di scripting.

Luglio 2008: i quadrati di VBScript
D'accordo, probabilmente sono rettangoli, non quadrati, ma non è questo il punto. Per risolvere il puzzle, inserire ognuno dei quadrati incolonnati sulla destra in uno dei quadrati vuoti sulla sinistra per creare i nomi di funzioni VBScript. Ogni quadrato dovrà essere utilizzato una sola volta. Ecco un esempio:
Per risolvere correttamente l'esempio, si deve spostare il quadrato (rettangolo) OU nel quadrato vuoto della prima parola e i quadrati MS e OX nei quadrati vuoti della seconda parola. Il risultato è rappresentato dalle funzioni VBScript UBound e MsgBox, come mostrato qui di seguito:
Ora prova tu:

RISPOSTA:
Il rompicapo di script del Dottor Scripto
Risposta: Quadrati di VBScript, luglio 2008

Gli Scripting Guy lavorano o, per meglio dire, sono stipendiati da Microsoft. Quando non si dedicano al baseball (o a varie altre attività) da giocatori, allenatori o semplici spettatori, gestiscono il TechNet Script Center. È possibile consultarne la pagina all'indirizzo www.scriptingguys.com (in inglese).


The Desktop Files Avvio da rete in Windows
Wes Miller

Indice
Funzionamento di PXE
Esplorazione di RIS
WDS: gli esordi
Altri componenti in gioco
Conclusioni
Nei prossimi pochi mesi intendo parlare dei Servizi di Distribuzione di Windows (WDS), disponibili per Windows Server 2003 e creati in Windows Server 2008. WDS può essere un componente molto importante nella vostra infrastruttura di distribuzione, quindi desidero accertarmi che disponiate di buone basi per la discussione. Questo
primo articolo esplorerà a fondo l'architettura di Pre-boot eXecution Environment (PXE; pronunciato pixie), la cronologia dei Servizi di installazione remota (RIS) e le altre tecnologie correlate a PXE utilizzate in Microsoft.
Quando sono passato al gruppo OS principale di Windows nel 2001, RIS era una delle tecnologie che ho ereditato (ed ero piuttosto terrorizzato di possederla, a causa della sua complessità e dipendenza dalle implementazioni di BIOS e dall'hardware). Ma era, oltre a Windows® PE, una delle tecnologie che ho apprezzato di più nel mio ruolo di Program Manager.
Ricordo quando ho installato per la prima volta Windows 3.0, utilizzando una serie di dischetti da 3,5". Con il tempo, l'installazione è diventata più semplice grazie ai CD avviabili (inclusi in alcune versioni di Windows 98). Ma il problema era che l'installazione richiedeva sempre dei supporti locali di qualche tipo e di un disco fisso locale.
Con il passare degli anni, la capacità di eseguire un avvio da rete in Windows, ovvero la possibilità di avviare tale sistema completamente sulla rete senza che fosse necessario un disco fisso, è stata una richiesta frequente dei clienti. A differenza di alcune versioni iniziali di Windows, Windows NT® non ha mai posseduto questa capacità. E mentre le versioni attuali di Windows Server® 2003 e Windows Server 2008 possono essere avviate tramite un initiator iSCSI, il processo è abbastanza diverso nel senso che non è realmente locale, ma comporta una dipendenza continua su un unità remota come l'unità di avvio.
Gestione dei client
  • Valutazione del processo di gestione client RIS
  • Pianificazione di un miglioramento della sicurezza di rete utilizzando client gestiti
  • Gestione di computer client
  • Installazione remota di un sistema operativo
A partire da Windows 2000, Microsoft ha iniziato a sviluppare la tecnologia che è oggi nota con la sigla RIS e che ha consentito un'installazione basata su rete. Lo scopo di RIS era relativamente semplice: inserire un'immagine del sistema operativo sul disco locale del computer di destinazione tramite PXE.

Funzionamento di PXE
Nella Figura 1 viene mostrata la sequenza di avvio di PXE. PXE è un protocollo relativamente semplice sviluppato da Intel e da altri fornitori all'interno dell'iniziativa Wired for Management. PXE deriva da Dynamic Host Configuration Protocol (DHCP), a sua volta derivato da BootP ed è generalmente implementato nella propria Network Interface Card (NIC). In parole povere, ecco cosa succede:
Figura 1 Sequenza di avvio di PXE (fare clic sull'immagine per ingrandirla)
Passaggio 1 Il BIOS di sistema esegue un avvio e determina l'ordine di avvio.
Passaggio 2 Se l'ordine di avvio colloca PXE prima dei dischi fissi, delle unità flash o dei CD-ROM o se nessuno di tali dispositivi è presente, la Universal Network Driver Interface (UNDI) viene caricata da NIC. NIC include un driver di periferica di rete dalle dimensioni estremamente contenute e un'implementazione Trivial File Transfer Protocol (TFTP). (Alcune implementazioni di BIOS richiedono che gli utenti finali premano il tasto F12 per l'avvio PXE. Questa opzione non è standard e consiglio di disabilitarla).
Passaggio 3 Il sistema inizia ad eseguire una semplice trasmissione User Datagram Protocol (UDP), ricercando un server DHCP. Questo è in realtà il primo passaggio della sequenza di avvio PXE e viene indicato con il termine Rilevamento. Tenere presente che il protocollo è UDP, il che significa che è necessario spendere del tempo prezioso con i propri router e switch per garantire che le comunicazioni PXE possono passare per tale protocollo.
Passaggio 4 Se un server DHCP percepisce la trasmissione, risponde di conseguenza con un indirizzo IP. Questo passaggio viene indicato con il termine Offerta. Il punto importante da ricordare in questo caso è che PXE è stateless e la quantità di informazioni di stato univoche del sistema che il client deve offrire a questo punto è piuttosto limitata (l'indirizzo MAC e, se disponibile, il System Management BIOS GUID, noto anche come GUID SMBIOS).
Passaggio 5 Il client, dopo avere ricevuto il pacchetto con l'indirizzo IP, rileva di avere effettivamente bisogno di ulteriori informazioni, ovvero dell'indirizzo del server PXE. Si verifica un'altra trasmissione, che include le informazioni dal server DHCP che ha risposto originariamente, In questo punto, il client comunica al server DHCP di avere bisogno di ulteriori informazioni, ovvero del percorso di un Network Boot Program (NBP). Questo passaggio è denominato Richiesta.
Passaggio 6 Il server PXE risponde con l'indirizzo del server PXE e con il percorso dell'NBP, un eseguibile di avvio estremamente piccolo le cui dimensioni devono essere inferiori a 32 KB. Questo passaggio è denominato Riconoscimento. Se si affronta questo processo come una sorta di gioco, si noterà probabilmente l'acronimo DORA (Discover, Offer, Request, Acknowledge) dei termini inglesi, un buon modo per ricordare la sequenza.
Tenere presente che, se sono stati installati Microsoft DHCP e WDS (o sono state utilizzate tecnologie di altri fornitori), il passaggio della richiesta non si verifica e, in effetti, il pacchetto Offerta originale del server DHCP contiene già il percorso del server PXE e del programma NBP (rimuovendo così due passaggi e del tempo prezioso).
Passaggio 7 Il client, che presenta lo stack del protocollo TFTP citato prima, scarica NBP dal percorso di rete specificato dal server PXE. TFTP è un protocollo obsoleto, estremamente piccolo e stateless. Non è stato scelto per la sua sicurezza o per le sue prestazioni e, infatti, molti amministratori di router lo disattivano per impostazione predefinita. Deve essere abilitato per consentire il funzionamento di PXE.
Molte implementazioni di PXE (tra cui RIS) includono la capacità di chiedere all'utente di premere F12 per continuare a questo punto, ma in genere questa opzione può essere disattivata dall'amministratore del server PXE. Il prossimo mese quando esaminerò più a fondo WDS, darò un'occhiata anche ad alcuni dei miglioramenti apportati da Microsoft in TFTPD (TFTP Daemon) di WDS per Windows Server 2008 con lo scopo di migliorare le prestazioni.
Passaggio 8 NBP viene inizializzato. Nel caso di RIS, questa operazione avvia un programma di caricamento avvio di Windows che inizia il processo di distribuzione. PXE (almeno il protocollo a livello di rete effettivo) non è più un componente del processo.
È importante ricordare che PXE (sia esso RIS, WDS o qualunque altra infrastruttura) non funziona correttamente su collegamenti lenti (può trasferire delle quantità considerevoli di dati) o su collegamenti ad elevata latenza come i satelliti (la comunicazione non viene eseguita adeguatamente e potrebbe venire interrotta).
Nel processo di avvio PXE si potrebbe notare che, quando il client invia la richiesta, non viene indicato in alcun modo da dove proviene tale richiesta. In realtà, non sono presenti dati di stato sufficienti che consentano al server PXE di rilevare tali informazioni. Ciò che generalmente accade è di solito una race condition, in cui il primo server a rispondere alla richiesta del client ha la meglio. Un paio di elementi possono aiutare a ridurre questo problema:
  • Modificare la velocità di risposta di un server PXE o dell'altro. La potenza del server e la latenza di rete avranno un impatto sulla rapidità di risposta dei server. In effetti, i server utilizzati da Microsoft IT erano talmente validi che anche se il server PXE era presente nell'ufficio, i server aziendali in alcuni casi avrebbero avuto la meglio. In questo caso, è sufficiente impostare il proprio server PXE locale su un valore di timeout pari a zero per i client gestiti.
  • Gestire i client. Questo aspetto è molto importante se si modifica il proprio server PXE per rispondere prima di altri server IT aziendali. Tramite la gestione dei propri client, si consentirà ad Active Directory® di comunicare a WDS o RIS che la richiesta proviene esattamente dal server in questione. Tenere presente che l'uso dello SMBIOS GUID è preferito come identificativo univoco per i propri sistemi in Active Directory ma, se uno SMBIOS GUID non viene implementato nei sistemi (probabile in presenza di un hardware relativamente obsoleto), è possibile (e sarà necessario) utilizzare un GUID basato sull'indirizzo MAC. Per ulteriori informazioni, vedere l'intestazione laterale "Gestione dei client".
  • Non consentire che le comunicazioni di PXE attraversino switch o router; collocare un server PXE su ogni lato. Questa operazione ha lo svantaggio di essere piuttosto costosa da implementare e da gestire (ogni server deve disporre della propria immagine gestita).
I server RIS (e ora WDS), come i server DHCP di Microsoft, devono essere autenticati rispetto all'implementazione di Active Directory a cui sono associati. Lo scopo è ridurre gli eventuali problemi causati dai server PXE non adeguati (come nel caso di tempeste di trasmissione PXE) lasciando che Active Directory acquisisca tutte le informazioni su tali server.
Tenere presente che questa operazione protegge soltanto contro i server su cui Active Directory ha acquisito informazioni. Se si configura il proprio dominio o un server PXE non Microsoft, la situazione è diversa.
Una volta, alla Microsoft, un dipendente eccessivamente zelante ha configurato un server PXE non RIS per una distribuzione "zero-touch". Tale implementazione ha cancellato completamente i dati del disco fisso creando una nuova immagine. Ciò sarebbe stato utile se la distribuzione si fosse verificata in un laboratorio isolato (non collegato in rete), ma sfortunatamente non è andata così e il risultato è stata la cancellazione dei dati del disco di un dirigente Microsoft sul cui computer PXE precedeva il disco fisso nell'ordine di avvio.
Il problema non era poi così grave, poiché Microsoft dispone dell'opzione per richiedere sempre di premere F12 all'avvio di PXE, ma il server PXE in questione non disponeva di un ritardo, un prompt F12 né di alcun tipo di notifica. Di conseguenza, il dirigente ha perso realmente tutte le informazioni presenti sul suo computer e tutti i dati non protetti dal suo profilo utente mobile.
Questo episodio evidenzia l'importanza di isolare i propri server PXE in caso di utilizzo dell'opzione "zero-touch" o, per lo meno, la necessità di impostare il prompt F12.

Esplorazione di RIS
Ho ereditato RIS dopo la distribuzione di Windows 2000. Windows 2000 non ha avuto molta fortuna relativamente a RIS e i test, le prestazioni e altri vincoli limitarono l'utilizzo di RIS per Windows Server 2000 esclusivamente alla distribuzione di Windows 2000 Professional. Purtroppo, non è stato possibile distribuire i prodotti server tramite RIS. Windows 2000 era disponibile unicamente per computer x86, quindi è risultato essere un ottimo campo di test per RIS poiché ha coinvolto un prodotto su un'unica architettura. RIS includeva (e richiedeva) l'integrazione completa con Active Directory, si integrava bene nel server Microsoft DHCP e includeva il proprio TFTPD.
RIS utilizza NBP per continuare il download di TFTP e ridurre a sufficienza il kernel di Windows per iniziare il processo di configurazione. (A un certo punto, non appena Windows è passato da TFTPD ad una connessione al server basata su Server Message Block o SMB, il percorso del codice letterale viene in realtà condiviso con una tradizionale installazione di Windows 2000 o Windows XP avviata da un dischetto). Una volta inizializzata la modalità nativa di Windows, la configurazione di Windows inizia la procedura guidata RIS OS Chooser (OSC).
Le schermate di OSC sono pagine simili ad HTML 2.0 abbastanza configurabili. Tali pagine sono limitate in modo molto rigido e non possono contenere immagini o simili e, infatti, non possono contenere caratteri non ANSI (che hanno reso complessa la distribuzione di alcune lingue di Windows).
Il prodotto finale di RIS è un file txtsetup.sif sul server RIS. Al termine della procedura guidata OSChooser, il client viene riavviato in modo logico, ma il percorso del server RIS e del filetxtsetup.sif vengono conservati e ricaricati dopo tale riavvio. Questo file txtsetup.sif è essenzialmente uguale al file unattend.txt, con diversi campi aggiuntivi inclusi per semplificare il completamento del processo di configurazione di RIS.
RIS poteva eseguire anche una configurazione molto simile ad una tradizionale configurazione non presidiata (RISetup) e disponeva di un'infrastruttura basata su clonazione simile a Sysprep (RIPrep) con cui, infatti, condivideva il codice. Ma RIPrep consentiva anche il caricamento della propria immagine su un server RIS.
Tuttavia, RIS presentava alcune limitazioni fondamentali che sono diventate evidenti. La prima era la mancanza di supporto per la distribuzione server. Alcuni attacchi, tra cui Code Red e Sasser, combinati con le complessità dell'IT che diversi clienti principali hanno sperimentato direttamente in occasione della tragedia dell'11 settembre 2001, ci ha obbligato a individuare rapidamente una soluzione per i server RIS Windows 2000 esistenti per consentire la distribuzione di Windows Server. A questa soluzione stavamo lavorando da tempo per Windows Server 2003 ma non la avevamo ancora rilasciata formalmente.
Ulteriori informazioni sulle tecnologie correlate a PXE
  • Descrizione dell'interazione PXE tra il client PXE, DHCP e il server RIS
  • Pianificazione per distribuzioni del sistema operativo avviate da PXE
  • Architettura PXE
  • Servizi di installazione remota
  • Installazione remota del sistema operativo
  • Guida dettagliata all'installazione del sistema operativo
  • Provider di PXE WDS
  • Informazioni sui Servizi di installazione remota
  • Servizi di distribuzione automatizzata di Windows Server 2003
In secondo luogo, in RIS mancava la capacità di automatizzare completamente la procedura guidata OSChooser, che fu successivamente abilitata con l'elemento <META ACTION="AUTOENTER"> in Windows Server 2003. Infine, OSChooser non poteva funzionare correttamente con caratteri non ANSI, un punto debole importante evidenziato da numerosi clienti residenti al di fuori degli Stati Uniti.
Di conseguenza, non era possibile completare un'installazione RIS con una tastiera francese, ad esempio. Il corretto funzionamento dei caratteri non ANSI a livello di BIOS su computer di tutto il mondo era estremamente complicato e non era semplice da realizzare.
Con la versione di Windows Server 2003, abbiamo aggiunto formalmente il supporto per l'architettura Intel Itanium e tutte le varianti server di Windows 2000 e Windows Server 2003. In Windows Server 2003 è stato inoltre aggiunto il supporto per l'architettura x64.
Per aumentare le prestazioni di RIS, è inoltre stato riscritto il relativo TFTPD. Windows Server 2003 supportava l'avvio simultaneo di un numero massimo di 75 client; tenete a mente che il limite superiore in questo caso viene raggiunto con il riempimento del pipe SMB a causa del traffico di rete verso i client.

WDS: gli esordi
Quando abbiamo iniziato a lavorare su RIS per "Longhorn" (il nome in codice per quello che è diventato Windows Server 2008), ci siamo subito resi conto che dovevamo fare un passo indietro. Come ho illustrato nelle sezioni precedenti nel mio articolo, avevamo già fatto grandi scommesse sulla configurazione basata sull'immagine (WIM) da Windows PE. Di conseguenza, il principio chiave su cui si basava WDS era la distribuzione basata su immagine da un'istanza di Windows PE avviata da PXE.
Sapevamo che Windows Server 2003 sarebbe stata la piattaforma comune per la distribuzione Windows Vista® e che avremmo avuto bisogno di una soluzione "fuori banda" per il downlevel di WDS. Di conseguenza, siamo riusciti a rendere possibile l'esecuzione di WDS su Windows Server 2003 SP1 e a creare WDS in Windows Server 2003 SP2.
Poiché può operare come server RIS (modalità legacy), server ibrido (modalità mista) o server esclusivo WDS (modalità nativa), WDS consente di eseguire la migrazione alle distribuzioni formali in stile WDS, come garantito. Ho sentito i clienti chiedere se esiste un modo per installare RIS su un sistema Windows Server 2003 SP2. Sì, esiste: è sufficiente installare WDS e attivare la modalità legacy. Nella Figura 2 vengono riportati i sistemi operativi supportati.
Figura 2 Piattaforme supportate per la distribuzione
Sistema operativo | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 e IA64)*** | X | X
Windows Server 2003 |  | X (x86 e IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* In support.microsoft.com/kb/308508 e support.microsoft.com/kb/313069 è stato aggiunto un supporto per Windows 2000 Server tramite RIS. ** La modalità mista e legacy WDS supportano questa stessa matrice per installazioni legacy. *** In Windows Server 2003 SP1 è stato aggiunto un supporto per sistemi basati su x64. I sistemi IA64 supportavano soltanto un'installazione basata su RISetup. **** Supporto modalità nativa.
WDS in Windows Server 2003 SP1 e SP2 ha cercato di iniziare il processo di migrazione a WDS. Come ho indicato prima, le funzioni principali di WDS in Windows Server 2008 erano un TFTPD rivisto, un supporto di avvio Extensible Firmware Interface (EFI) e, ovviamente, la distribuzione basata su multicast.

Altri componenti in gioco
I Servizi di distribuzione automatizzata (ADS) sono stati creati da un altro team interno a Microsoft, principalmente con l'obiettivo di un provisioning server rapido. ADS offriva un imaging formale basato sul settore, il relativo agent di avvio (più piccolo di Windows PE ma non ugualmente completo a livello di funzionalità), il relativo TFTPD e un multicast estremamente avanzato. La funzionalità creata in ADS è diventata disponibile fino ad un certo punto in System Center Configuration Manager (SCCM), nonostante non vi sia una parità di funzioni completa.﻿
Windows XP incorporava un avvio PXE completo di tutte le funzioni tramite il relativo TFTPD in un RAMDisk, ma non consentiva la distribuzione remota in quel modo. La tecnologia è progettata per supportare l'avvio simultaneo di numerosi sistemi dalla stessa immagine disco tramite PXE.

Conclusioni
E questa è la storia, in sintesi. Per ulteriori informazioni, consultare l'intestazione laterale "Ulteriori informazioni sulle tecnologie correlate a PXE". Il prossimo mese esaminerò i principi di base di WDS, a cui seguiranno articoli sulla funzionalità avanzata di WDS (multicast e molto altro) e, infine, sull'utilizzo di WDS senza utilizzare WDS, da cui intendo partire per andare oltre l'esperienza attuale di configurazione/WDS con lo scopo di far funzionare le vostre tecniche di distribuzione personalizzate.

Wes Miller è un Senior Technical Product Manager di CoreTrace (www.CoreTrace.com) di Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.


Security Watch Password e carte di credito, Parte 1
Jesper M. Johansson

Indice
Consigli impraticabili sulla sicurezza
Consigli impraticabili e inesatti
Consigli incomprensibili
Insidie dell'autenticazione dei siti basata sulle immagini
Recentemente sono stato contattato dalla University of Minnesota per un'intervista da pubblicare sulla rivista universitaria. A quanto pare, volevano pubblicare un numero su alcuni dei loro ex studenti di successo e, non avendone trovato nessuno, si erano accontentati di me. L'intervistatrice mi ha chiesto quale fosse il mio lavoro e io sono andato avanti per alcuni minuti tentando di descrivere il
software dell'infrastruttura di sicurezza. A un certo punto la sento esclamare: "Sembra tutto così complicato! Io ho sempre pensato che la sicurezza riguardasse le password e le carte di credito".
Per alcuni minuti ho riflettuto sulla sua reazione, poi ho capito che la sua osservazione era tutt'altro che ovvia. La sicurezza riguarda davvero le password e le carte di credito. Almeno, questa è la percezione che ne ha l'utente finale. Quelli di noi che lavorano nel campo pensano che la sicurezza sia una questione di algoritmi di crittografia, di Kerberos che può essere o meno una scelta migliore rispetto a TLS o NTLMv2, dei vantaggi offerti da WS*, di hash password da utilizzare con o senza sale e di tutte le altre questioni esoteriche di cui ci piace così tanto discutere. Godiamo senz'altro di una prospettiva diversa e più dettagliata rispetto agli utenti finali, ma è altrettanto sicuro che abbiamo perso di vista un aspetto fondamentale: per coloro che in teoria usufruiscono dei frutti del nostro lavoro, la sicurezza riguarda le password e le carte di credito.
Non c'è dubbio che tutti gli esoterismi di cui ci piace così tanto parlare e le nuove tecnologie che amiamo inventare siano tutti pensati per proteggere i dati dell'utente finale. Eppure, sono convinto che in qualche modo abbiamo smarrito la strada. Noi, la sottocultura della sicurezza nel mondo IT, esistiamo per soddisfare un'esigenza specifica dei nostri clienti: la necessità di mantenere i dati al sicuro. Ovviamente, ciò include la garanzia che le risorse IT possano essere utilizzate in tutta sicurezza. Il punto è davvero questo.
In alcuni precedenti articoli della rubrica, ho affermato che nessuno va ad acquistare un computer per avere la possibilità di eseguirci un software antivirus. L'utente acquista un computer per effettuare operazioni di online banking, distrarsi con i giochi, scambiare messaggi di posta elettronica, fare i compiti o qualche altra attività di importanza primaria. Analogamente, nessuna azienda ha creato un gruppo addetto alla sicurezza IT così da poter implementare NTLMv2. Le aziende finanziano i gruppi per la sicurezza IT perché questi riescano a proteggere le risorse dell'organizzazione, consentendo all'azienda nel suo insieme di utilizzare in modo sicuro le proprie risorse IT e raggiungere gli obiettivi aziendali.
Esistiamo esclusivamente per fornire un servizio.
Allora devo veramente porre l'interrogativo se in questi tempi stiamo assolvendo bene il nostro compito di "servire". Oppure se noi, la sottocultura della sicurezza, siamo diventati di intralcio più che di aiuto. E se i legislatori e gli enti di vigilanza non stiano in realtà dandoci una mano a essere di intralcio. Non sono affatto convinto che tutta la tecnologia che stiamo adottando aiuti davvero gli utenti finali. Perciò vorrei esplorare alcuni degli ambiti nei quali noi, i provider IT del mondo, stiamo effettivamente producendo più danni che vantaggi.
In certi giorni sembra che la maggior parte dei consigli sulla sicurezza e molte delle tecnologie di sicurezza che infliggiamo ai nostri utenti siano impraticabili, inesatti, incomprensibili o (in molti casi) una qualche combinazione di questi tre difetti. In questa serie di tre articoli, analizzerò alcuni dei modi in cui riusciamo a confondere gli utenti offrendo consigli e distribuendo tecnologie che possono essere deplorevolmente classificati con una o più di queste tre "I".

Consigli impraticabili sulla sicurezza
Uno dei modi migliori per confondere le persone è offrire consigli sulla sicurezza che risultano impraticabili. Si può anche riuscire nell'impresa di aggiungere al danno dell'impraticabilità la beffa dell'inesattezza. La Figura 1 illustra un consiglio molto diffuso, collaudato negli anni, teoricamente valido e totalmente inutile.
Figura 1 Consiglio impraticabile sulla sicurezza (fare clic sull'immagine per ingrandirla)
Si riesce a vedere la parte che suggerisce di servirsi di una password diversa per ogni account di cui si dispone? Trenta anni fa era un consiglio che ancora aveva senso. Allora il numero delle persone collegate a quella rete che alla fine sarebbe diventata Internet si aggirava intorno alle poche centinaia. Ed erano tutte persone brillanti che tuttavia non sceglievano password particolarmente buone. Purtroppo, il consiglio è sopravvissuto al passare degli anni e viene ancora oggi ripetuto in continuazione, senza che ci sia stato nessuno sforzo evidente di riconciliarlo con il modo in cui vengono attualmente utilizzati i computer.
Ad esempio, tu quanti account in linea hai? Personalmente, ne ho 115, più o meno qualche altro di cui non riesco a tenere il conto. Il consiglio nella Figura 1 suggerisce non solo che dovrei avere 115 password diverse, ma anche che le dovrei cambiare tutte a intervalli variabili dai 30 ai 60 giorni. In altre parole, ogni giorno dovrei cambiare dalle 2 alle 4 password. (È facile fare i conti: significa anche che avrei dalle 690 alle 1380 password l'anno).
Mentre il personale tecnico di alcuni dei siti che offrono questo consiglio può essere in grado di inventare quattro buone password al giorno e conservare 115 password correnti nella memoria a breve termine, si può stare certi che il 99,99% degli utenti che naviga in rete non è in grado di farlo.
Da un punto di vista puramente teorico, il consiglio di utilizzare ovunque delle password diverse è corretto e sensato, così come lo è quello di cambiare tutte le password a intervalli compresi tra 30 e 60 giorni. Ma sono consigli impraticabili. Dato il numero di password di cui dispongono oggigiorno, gli utenti semplicemente non riescono a tradurre in pratica il consiglio senza un qualche genere di supporto, come ad esempio un foglio di carta o un software. Il che introduce l'esempio successivo.

Consigli impraticabili e inesatti
Il consiglio mostrato nella Figura 2, tratto dal sito Web di una delle più grandi banche del mondo, rientra in due categorie: è impraticabile e inesatto. Le informazioni fornite sotto l'intestazione rossa che invita a leggere i consigli sulla sicurezza sono un'imitazione della riga che suggerisce di utilizzare ovunque delle password diverse di cui abbiamo parlato sopra. Inoltre, consigliano anche di non prenderne mai nota per iscritto.
Figura 2 Consiglio impraticabile e inesatto sulla sicurezza (fare clic sull'immagine per ingrandirla)
Allora vediamo, ho 115 password diverse, ne devo creare quattro nuove ogni giorno e non posso annotarle. Per qualche tempo ho pensato di essere stupido, visto che non riuscivo a ricordare tutte le password. Poi ho scoperto che anche tutti gli altri si trovavano esattamente nella mia stessa condizione. Più semplicemente, il punto è che gli esseri umani non riescono a ricordare 115 password. Riusciamo a ricordare ed elaborare circa sette blocchi di informazioni - siamo programmati in questo modo. Stando alla maggior parte dei consigli sulle password presenti in Internet, questo non sarebbe neanche sufficiente per una sola password (vedere il famoso saggio "Il magico numero sette più o meno due" di George A. Miller, disponibile in rete nella sua versione originale in inglese all'indirizzo musanim.com/miller1956).
Il fatto spiacevole è che quando si tratta di consigli sulle password, il nostro settore fornisce informazioni fuorvianti agli utenti, in modo molto ricorrente. Se la sottocultura della sicurezza intende dire agli utenti che devono utilizzare ovunque password diverse, allora dobbiamo anche spiegare loro come fare, ovvero come registrare e conservare quelle password in un luogo sicuro. Scriverle su un foglio di carta, utilizzare un documento protetto o avvalersi di uno strumento specializzato, come ad esempio PasswordSafe (è possibile consultarne la pagina Web all'indirizzo sourceforge.net/projects/passwordsafe; in inglese). Ammettiamolo, tutti annotiamo le nostre password oppure utilizziamo la stessa password ovunque. Di fatto, un'indagine recente ha rilevato che l'88% degli utenti ha la stessa password in tutti i sistemi nei quali deve eseguire un'autenticazione (a questo proposito, vedere l'articolo disponibile all'indirizzo msnbc.msn.com/id/24162478; in inglese).
I consigli che scoraggiano l'abitudine di annotare le password sono sicuramente tra i fattori che contribuiscono a favorire questa tendenza. Ciò che invece dovremmo fare è insegnare agli utenti come gestire efficacemente le password (e gli altri dati sensibili), anziché insegnare loro a non gestire affatto questo tipo di informazioni. Solo allora diventeranno molto meno disposti a compromettere i loro dati personali.

Consigli incomprensibili
Nelle prime due figure vengono ripetuti consigli vecchissimi che potevano funzionare negli anni Sessanta, Settanta e Ottanta. Cioè prima che la massa degli utenti comuni si collegasse in linea per utilizzare i servizi Web. A tutt'oggi, ancora nessuno si è lamentato apertamente di questo tipo di consigli perché è ormai entrato a far parte del bagaglio del buonsenso comune.
Ma è un tipo di consigli che confonde gli utenti e può farli sentire colpevoli di dover conservare le password da qualche parte. Offrendo consigli del genere, anziché aiutare gli utenti a fare quello che devono, i professionisti della sicurezza provocano danni. Dopo tutto, non rientra nelle responsabilità di un utente immaginare il modo per gestire la sicurezza. Quello è il compito dei professionisti della sicurezza, appunto. Dobbiamo riuscire a pensare a modi accettabili da indicare agli utenti per gestire tutti i loro account in linea. Ma dal momento che la maggior parte delle guide offerte dagli esperti ripete gli stessi consigli antiquati, gli utenti finiscono per ricorrere ai foglietti adesivi e ai fogli di calcolo per tenere traccia delle molte password di cui dispongono.
Come meccanismo di autenticazione, le password hanno molto da offrire. Tuttavia, il problema principale delle password è che gli esseri umani incontrano difficoltà enormi quando si tratta di ricordarle. Anziché tentare di risolvere un problema insito nella natura umana, il mondo IT continua a inventare ogni genere di nuovo meccanismo per sostituire le password o, peggio ancora, per aumentarne il numero. Questo non fa altro che confondere gli utenti ancora di più.
È facile immaginare la mia sorpresa l'ultima volta che ho eseguito l'accesso a un certo sito di servizi finanziari e mi sono visto presentare una schermata di accesso che conteneva soltanto una casella di testo per il nome utente (vedere la Figura 3).
Figura 3 Dove digito la password?
Sulle prime ho pensato di aver aperto un qualche sito Web dal contenuto dannoso. Non ci è voluto molto per convalidare il sito. Era un passaggio facile perché il sito era dotato di certificato e così ho constatato che mi trovavo davvero nel posto giusto. Il problema è che, quando eseguono l'accesso a un sito, le persone sono abituate a vedere due campi di testo insieme, uno per il nome utente e uno per la password. Questo deriva da anni di applicazione dello stesso flusso di lavoro. Perciò quando per accedere a un sito viene richiesto soltanto di immettere il nome utente, tutto si blocca. Poi si scopre che in quel caso specifico il provider, nel tentativo di prevenire il phishing, aveva implementato una tecnologia che utilizza le immagini per l'identificazione del sito da parte degli utenti. Nella pratica, quando si immette il nome utente, nel sito viene visualizzata una schermata contenente un'immagine identificabile, come mostrato nella Figura 4.
Figura 4 Oggi alcuni siti utilizzano le immagini per l'identificazione da parte dell'utente (fare clic sull'immagine per ingrandirla)
In teoria, l'utente dovrebbe conoscere l'immagine associata a ogni sito. Se non viene visualizzata l'immagine giusta, il sito può essere riconosciuto come sito contraffatto. In sé per sé, l'idea è valida. Presumendo che l'utente conosca l'immagine da associare ai diversi siti, la strategia sembra avere una certa dose di ragionevolezza.
Ovviamente, il lettore più attento avrà notato la barra degli indirizzi verde nella Figura 4. Questo significa che il sito utilizza i certificati SSL e di convalida estesa, motivo per cui la barra degli indirizzi è verde. Significa anche che l'intera premessa basata sull'uso dell'immagine per identificare il sito di fatto non fornisce alcun valore aggiunto. Al contrario, l'immagine fa poco più che aggiungere confusione, almeno per alcuni utenti finali. L'utente ha già avuto modo di identificare il sito, che infatti ha fornito un certificato contenente il nome dell'azienda, l'indirizzo del sito Web e il nome di un'autorità di emissione attendibile. E il fatto che la barra degli indirizzi sia verde mi conferma che l'azienda ha persino fatto uno sforzo ulteriore per la sicurezza, pagando un importo tre volte maggiore per ottenere un certificato di convalida estesa.
Senza contare poi che, ovviamente, anche le immagini possono essere contraffatte. Se l'utente può inviare la sua immagine, probabilmente ci saranno anche modi in cui l'hacker può immaginare quale immagine venga utilizzata. È anche molto probabile che l'utente possa utilizzare la stessa immagine in ogni sito, perciò tutto quello che l'hacker dovrà fare è creare un sito con un contenuto interessante per l'utente (lascio ai lettori il compito di trovare gli esempi del caso) e chiedergli un'immagine da utilizzare per la convalida del sito. Se l'utente usa la stessa immagine per tutti i siti, il sito nuovo avrà accesso all'immagine che l'utente utilizza, ad esempio, anche in quello della banca.
Sebbene alcuni siti consentano di scegliere l'immagine preferita, altri si avvalgono di una raccolta di fotografie stereotipate. Ad esempio, il sito mostrato nella Figura 4 offre 318 foto da cui scegliere. Il trucco descritto sopra non funziona nei siti che non consentono all'utente di inviare la propria foto. Tuttavia, è anche vero che la probabilità che l'utente ricordi l'associazione sito-immagine è molto ridotta nel caso dei siti non visitati di frequente. Onestamente non saprei dire quale immagine io utilizzi nel sito mostrato nella Figura 4, sebbene possa assicurare che non è quella riportata nella schermata.
Il problema dell'approccio basato sulle immagini è che un hacker potrebbe mostrarne praticamente una qualunque delle 318, o semplicemente sceglierne una a caso da Flickr, e molti utenti presumerebbero trattarsi di quella giusta. Se per la maggior parte delle persone fosse possibile ricordare cose come l'immagine da associare ai diversi siti, oggi non ci troveremmo a dover fronteggiare tutti i ben noti problemi legati al phishing e alla sicurezza.
Allora perché servirsi di un'immagine per l'autenticazione del sito da parte dell'utente quando il sito ha già ricevuto un'autenticazione tramite il certificato? Perché non utilizzare soltanto i certificati e insegnare agli utenti come convalidarli? I certificati già comprovano l'identità del sito.
Il processo per procurarsi un certificato è di certo molto più sicuro di quello necessario per ottenere dall'utente un'immagine per l'autenticazione del sito. Se il certificato è uno di quelli di convalida estesa e se si utilizza Internet Explorer® 7 o Firefox 3, il browser evidenzierà le apposite informazioni relative al certificato nella barra degli indirizzi. Purtroppo, però, l'evidenziazione funziona soltanto con i certificati di convalida estesa, che sono molto costosi.

Insidie dell'autenticazione dei siti basata sulle immagini
La tecnologia di autenticazione tramite le immagini presenta svariati problemi. Per prima cosa, diventa molto facile "mietere" i nomi utente da un sito. Difatti, se il nome utente immesso è sbagliato, nel sito mostrato nella Figura 4 viene visualizzata la finestra riportata nella Figura 5. Dopo aver immesso il nome utente corretto di un utente che ha scelto un'immagine segreta, si riesce a vederla. Ovviamente, si tratta di una forma di conoscenza estremamente preziosa per un hacker che tenti di raccogliere informazioni su un utente.
Figura 5 I siti autenticati tramite immagini consentono di raccogliere facilmente i nomi utente
Il tipo di implementazione mostrato qui non ha praticamente alcun valore ai fini della sicurezza. All'hacker è sufficiente duplicare lo stesso flusso di lavoro per l'accesso all'interno di un sito contraffatto. Questo sito richiederà un nome utente e lo passerà al sito vero. Per assicurare un aspetto ancora più attraente, è persino possibile utilizzare AJAX nel client per aggiornare il modulo in tempo reale. Inoltre, se per il modulo di accesso il sito autentico non dispone di prevenzioni dagli attacchi con contraffazione delle richieste intersito, il codice AJAX potrà persino inviare la richiesta direttamente al sito vero, a meno che il browser non disponga di prevenzioni per le richieste XML-HTTP intersito.
A questo punto, quando vengono restituiti i risultati, l'hacker può analizzare i dati, estrarre l'immagine e visualizzarla all'utente finale. In altre parole, qualunque hacker in grado di presentare all'utente un sito con accesso contraffatto è anche capace di visualizzare l'immagine segreta dell'utente. Il risultato ultimo è che l'uso dell'autenticazione dei siti basata sulle immagini non offre alcun valore aggiunto. L'immagine viene visualizzata prima dell'autenticazione dell'utente nel sito e, pertanto, l'immagine è disponibile per un hacker che disponga, o possa ottenere, il nome utente necessario.
Presumendo che all'utente non sia mai stato insegnato a cercare un certificato prima di inviare i moduli (è questa è un'ipotesi alquanto realistica, considerato il fatto che anche l'uso dell'autenticazione del sito tramite un'immagine la assume come fondamento), ottenere il nome utente dall'utente è davvero semplice. Inoltre, poiché molti schemi di autenticazione dei siti tramite le immagini rispondono in modo diverso all'immissione di un nome utente valido oppure non valido, anche la raccolta dei nomi utente è davvero semplice. L'hacker può persino effettuarla "fuori banda", prima ancora che inizi l'attacco.
Alla fine, ci ritroviamo con utenti che credono di essere più protetti o che sono soltanto più confusi. Abbiamo speso quantità notevoli di utili degli azionisti per implementare l'autenticazione dei siti basata sulle immagini e non siamo minimamente riusciti a rendere un po' più difficile la vita agli utenti malintenzionati che convincono gli utenti finali a inviare le loro credenziali a siti Web contraffatti.
Ho finito lo spazio a disposizione per questo numero della rubrica Security Watch. L'appuntamento è per il mese prossimo, con la Parte 2 della serie, nella quale illustrerò altri esempi di regole di sicurezza fuorvianti e implementazioni dell'autenticazione inefficaci.

Jesper M. Johansson, Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito un dottorato in gestione dei sistemi informatici, vanta un'esperienza più che ventennale sul tema della sicurezza ed è Microsoft MVP per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.


Field Notes Garantire la correttezza delle elezioni
Josh Benaloh

In questo anno elettorale per le presidenziali negli Stati Uniti, l'attenzione dell'opinione pubblica si è concentrata sul voto tecnologico. Le scelte sono molteplici: schede cartacee contate a mano, scomode e facili a danneggiarsi; macchine a leva, che possono essere manipolate da addetti ai lavori bene informati; schede perforate con gli ormai celebri "hanging chad" (i coriandoli che spesso non si staccano bene dalla scheda); voti acquisiti otticamente, che possono essere facilmente male interpretati da scanner scarsamente calibrati; sistemi touch-screen, che possono essere compromessi da software deboli o dannosi; vari ibridi, che spesso creano più problemi di quanti ne risolvano.
Questi sono solo alcuni esempi della vulnerabilità di tali sistemi. Inoltre, le tecniche comunemente usate nel mondo dipendono dall'onestà e dalla preparazione degli addetti allo scrutinio per garantire l'integrità delle elezioni.
Ma esiste un metodo migliore grazie al quale l'integrità delle elezioni non dipende né dagli addetti né dell'attrezzatura usata. È possibile svolgere le elezioni facendo in modo che la loro correttezza venga verificata end-to-end da funzionari, singoli elettori e osservatori interessati.
Immaginiamo, ad esempio, che agli elettori vengano dati dei codici che permettano loro di pubblicare i voti accanto ai nomi in un sito Web a cui tutti possono accedere. Gli elettori possono controllare nel sito Web che i loro voti siano stati registrati esattamente e chiunque può fare un controllo indipendente e verificare che tutti gli elettori siano legittimi e il totale corrisponda ai conteggi annunciati.
Ma il problema è che in questo sistema trasparente manca la privacy. Per colmare questa lacuna, è possibile usare la crittografia garantendo così elezioni a scrutinio segreto completamente verificabili. Invece di pubblicare i voti così come sono, i voti pubblicati vengono crittografati con chiavi pubbliche le cui chiavi di crittografia sono condivise dai funzionari addetti alle elezioni in modo che per la decifrazione occorra la collaborazione di tutti. Una volta completato il voto, i funzionari si mettono all'opera in un processo cooperativo per produrre sia un conteggio che una prova crittografica che il conteggio corrisponde esattamente all'insieme pubblicato delle schede crittografate.
I singoli elettori possono controllare che i loro voti crittografati corrispondano alle loro intenzioni e chiunque può esaminare la prova crittografata per verificare che i voti crittografati siano stati correttamente conteggiati. In questo modo, il conteggio dei voti può essere verificato end-to-end.
È davvero così semplice? No. Quella che ho dato è una panoramica fedele ma ci sono numerosi dettagli che devono essere gestiti con attenzione affinché tutto vada bene. Ad esempio, dobbiamo ancora dipendere dai metodi tradizionali per garantire che i dispositivi di voto garantiscano un'adeguata privacy dell'elettore. E come ci si può aspettare che gli elettori convertano le loro intenzioni di voto in voti crittografati? Gli elettori devono fidarsi del fatto che i valori crittografati imperscrutabili, pubblicati accanto ai loro nomi, corrispondono effettivamente alle loro intenzioni, senza dover mostrare a terzi la corrispondenza (affinché non siano soggetti a coercizione o al voto di scambio). Dobbiamo fare tutto questo senza costringere gli elettori a operazioni più complesse dei tradizionali sistemi di voto a cui sono abituati.
I processi elettorali end-to-end vengono studiati nella letteratura crittografica da più di 25 anni e ora costituiscono un modo valido e pratico per fornire una prova crittografica dell'esattezza del conteggio. Di recente la comunità di ricerca ha posto l'attenzione sull'interfaccia presentata all'elettore e anche in questo caso di registrano notevoli progressi.
La domanda nel mercato della tecnologia per le elezioni è grande ma non enorme. Si può guardare con sospetto a grandi agglomerati con interessi diffusi in questo mercato, dato che potrebbero beneficiare di determinati risultati delle elezioni. Pertanto, questo mercato potrebbe essere soddisfatto meglio da attori di nicchia più piccoli, i cui affari dipendono interamente dalla correttezza delle elezioni. Per ulteriori informazioni e collegamenti ai metodi di voto verificabili end-to-end, visitare research.microsoft.com/crypto/voting.

Josh Benaloh è Senior Cryptographer in Microsoft Research. È stato per otto anni nel consiglio di amministrazione di International Association for Cryptologic Research e tra le sue numerose pubblicazioni si segnala la tesi di dottorato del 1987 dal titolo "Verifiable Secret-Ballot Elections" (Elezioni a scrutinio segreto verificabili).


Windows Confidential E la storia continua
Raymond Chen

Ricordate Microsoft Bob? Era concepito come un'interfaccia utente semplice da utilizzare in Windows® 3.1, ma invece si rivelò un flop clamoroso, guadagnando il dubbioso merito di essere uno dei peggiori prodotti tecnologici mai creati da PC World. Negli anni successivi alla scomparsa di Bob, il prodotto è stato relegato allo stato di scherzo e il solo accenno al suo nome provocava ilarità.
Tra l'altro, il nome in codice interno di Microsoft® Bob era "Utopia", un nome ambizioso per poter essere sicuro, ma almeno ricco di brio e slancio. Quando abbiamo appreso che i responsabili commerciali avevano deciso di chiamare il prodotto Bob, abbiamo tutti scosso la testa con scetticismo.
Ma il potenziale di Bob era molto più elevato di quanto potesse sembrare. In realtà, Bob è attualmente più presente che mai.
Quando si intende distribuire il proprio software su un CD, il primo aspetto di cui preoccuparsi è garantire che il proprio prodotto possa essere contenuto in un unico CD. Fortunatamente, è successo che anche dopo avere tenuto conto dello spazio su disco richiesto per conversioni, strumenti di supporto e altri elementi da inserire nel CD di Windows XP, erano rimasti circa 30 megabyte di capacità di archiviazione. Le persone che si occupano di questo genere di cose pensarono che, dal momento che avevamo pagato tutta la capacità di archiviazione sul CD, avremmo dovuto utilizzarla.
Il nome in codice interno di Microsoft® Bob era "Utopia", un nome ambizioso per poter essere sicuro, ma almeno ricco di brio e slancio. (Fare clic sull'immagine per ingrandirla)
Il risultato fu un tentativo piuttosto debole di dissuadere gli autori di copie illegali di Windows. Qualcuno ha deciso di riempire quella capacità extra sul CD con dati fittizi e di fare in modo che il programma di configurazione di Windows verificasse che tali dati fossero presenti. Questo, a logica, avrebbe obbligato gli utenti a scaricare una copia dell'immagine CD per scaricare altri 30 megabyte di dati. Questo scenario si è ripresentato quando la banda larga non era ancora una parola familiare e gli utenti mainstream utilizzavano connessioni remote. Il trasferimento di altri trenta megabyte di dati su un modem da 56 Kb rappresentava un ostacolo imponente per dissuadere gli utenti, anche se oggi non costituirebbe più un problema considerati gli standard attuali.
La persona a cui venne richiesto di implementare questa verifica aveva bisogno di un'origine per i dati fittizi. Avrebbe potuto chiamare la funzione CryptGenRandom per generare 30 megabyte di dati casuali protetti da crittografia, ma non ci sarebbe stato alcun divertimento! Esaminò quindi a fondo gli archivi e trovò una copia di Microsoft Bob. Così prese tutte le immagini del dischetto combinandole in un unico grande file. Il contenuto delle immagini del disco di Microsoft Bob non è particolarmente casuale, quindi il suddetto sviluppatore decise di rendere indecifrabili i dati codificandoli. Quando fu il momento di inserire la chiave di crittografia, posò casualmente la mano sulla tastiera e il risultato fu una copia codificata di Microsoft Bob. Questo è ciò che è andato a finire nello spazio inutilizzato come dati fittizi sul CD di Windows XP.
Alla fine, Windows XP è diventato lo strumento di distribuzione più efficace di Microsoft Bob mai sviluppato. E se scavate nel vostro armadio, provate a riesumare la vostra copia di Windows XP e posate le mani sulla tastiera in modo casuale invocando gli spiriti giusti, il risultato del vostro programma di codifica sarà una copia di Microsoft Bob.

Sul sito Web di Raymond Chen, The Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e la programmazione in Win32. Raymond si domanda se la fusione nucleare diventerà realizzabile nel corso della sua vita.

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